<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi again,</p>
<p>I had some luck in making this setup work. So far, so good ...
However, there's no telling how the DHCP DDNS will function with
the new 186.198.193.dhcp. zone before Monday morning when the
subsidiary computers power up.</p>
<p>However, I have an odd behavior which I cannot explain: without
any change to zone a reverse resolution stopped working. The setup
just doesn't seem stable enough to work with DHCP-updated dynamic
DNS in our organization, with a lot of smartphones and wireless
devices frequently signing on and off.</p>
<p>The zone is:</p>
<p><font face="monospace">$ORIGIN 192/27.186.198.193.in-addr.arpa.<br>
<br>
@ IN NS domac.alu.hr.<br>
;@ IN NS bjesomar.srce.hr.<br>
<br>
195 IN PTR test-record.slava.alu.hr.<br>
<br>
200 IN CNAME 200.186.198.193.dhcp.<br>
201 IN CNAME 201.186.198.193.dhcp.<br>
</font><br>
; MT 20211211:<br>
; Here's the magic:<br>
<br>
$GENERATE 202-222 $ CNAME $.186.198.193.dhcp.<br>
<br>
The command output shows that resolution succeeds, but nslookup
can't finish it for some unknown spurious reason.</p>
<p><font face="monospace">root@domac:~# nslookup -query=any
195.192/27.186.198.193.in-addr.arpa.<br>
Server: 161.53.235.3<br>
Address: 161.53.235.3#53<br>
<br>
195.192/27.186.198.193.in-addr.arpa name =
test-record.slava.alu.hr.<br>
<br>
root@domac:~# nslookup -query=ptr 193.198.186.195<br>
Server: 161.53.235.3<br>
Address: 161.53.235.3#53<br>
<br>
** server can't find 195.186.198.193.in-addr.arpa: NXDOMAIN<br>
<br>
root@domac:~#<br>
</font></p>
<p>This kind of setup that sometimes works and sometimes doesn't
will make me look incompetent.<br>
I know that BIND 9 is great open source server with lots of bells
and whistles. But right now I can't study all those and I just
want to survive, providing a solution fast enough for our uplevel
sysadmins.</p>
<p>The /etc/bind/named.conf.local part looks like:</p>
<p><font face="monospace">zone "192/27.186.198.193.in-addr.arpa" in
{<br>
type master;<br>
file
"/etc/bind/zones/192-27.186.198.193.in-addr.arpa.db";<br>
};<br>
<br>
zone "186.198.193.dhcp" in {<br>
type master;<br>
file "/var/cache/bind/186.198.193.dhcp.db";<br>
allow-update { key DDNS_UPDATE; };<br>
};<br>
</font><br>
</p>
<p>What possibly could be killing the name resolution between
resolving 195.192/27.186.198.193.in-addr.arpa to
test-record.slava.alu.hr. and resolving 193.198.186.195 that
apparently fails?</p>
<div class="moz-cite-prefix">Is there a way to see more interim
debugging output?</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Thank you very much.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Kind regards,<br>
Mirsad Todorovac</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 12/11/2021 10:25 AM, Mirsad Goran
Todorovac wrote:<br>
</div>
<blockquote type="cite"
cite="mid:a00fe853-b0db-b803-f2e7-994dccc6dbf1@alu.unizg.hr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi Crist,</p>
<p>Thank you for your reply and the information provided.</p>
<p>I have roughly implemented this workaround. I was hoping there
was a way to instruct BIND to masquerade a delegated domain with
data from another (dynamically updated from ISC DHCP) zone.<br>
</p>
<p>More accurately, my (from upper level) mandated delegation is
the literal 192/27.186.198.193.in-addr.arpa, using
192-27.186.198.193.in-addr.arpa says "ignoring records outside
of the origin" or something like that.</p>
<p>I have used the following records in the zone:</p>
<p>$ORIGIN 192/27.186.198.193.in-addr.arpa.<br>
<br>
@ IN NS domac.alu.hr.<br>
@ IN NS bjesomar.srce.hr.<br>
<br>
195 IN PTR test-record.slava.alu.hr.<br>
<br>
$GENERATE 200-222 $ CNAME $.186.198.193.dhcp.<br>
</p>
<p>/etc/dhcp/dhcpd.conf has this:</p>
<p> ddns-domainname "slava.alu.hr";<br>
ddns-rev-domainname "dhcp";<br>
zone slava.alu.hr. {<br>
primary 127.0.0.1;<br>
key DDNS_UPDATE;<br>
}<br>
zone 186.198.193.dhcp. {<br>
primary 127.0.0.1;<br>
key DDNS_UPDATE;<br>
}<br>
<br>
However, don't I have to convince people managing
bjesomar.srce.hr to be a slave server for the "186.198.193.dhcp"
zone? Or the dynamically updated reverse PTR record will have
effect only in my local domain (which I had even before the
entire setup), won't it?</p>
<p>Also, I get spurious REFUSED or NXDOMAIN errors, some pass with
time, so there must be some TTL or timeout.<br>
</p>
<p>Kind regards,</p>
<p>Mirsad<br>
</p>
<div class="moz-cite-prefix">On 12/11/2021 6:04 AM, Crist Clark
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAAcrURKpskSBStTS-+_ZFaZQ_3OQX6fb4Rc0O7m+DWMC8HkyqA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div dir="auto">No idea if this is the best way. It is a way.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Do you control any other zone? Let’s say you own
“example.com.” You can tell ISC DHCP to build the reverse zone
at an arbitrary base name instead of in-addr.arpa.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Configure DHCP to put the reverse records at
say, “rev.example.com.” So you’ll get records at,</div>
<div dir="auto"><br>
</div>
<div dir="auto"><a href="http://193.186.198.193.rev.example.com"
moz-do-not-send="true">193.186.198.193.rev.example.com</a></div>
<div dir="auto"><a href="http://194.186.198.193.rev.example.com"
moz-do-not-send="true">194.186.198.193.rev.example.com</a></div>
<div dir="auto">…</div>
<div dir="auto"><br>
</div>
<div dir="auto">And in your RFC 2317-style delegation, you then
enumerate another CNAME layer,</div>
<div dir="auto"><br>
</div>
<div dir="auto">$ORIGIN 192-27.186.198.193.in-addr.arpa.</div>
<div dir="auto">193 IN CNAME <a
href="http://193.186.198.193.rev.example.com"
moz-do-not-send="true">193.186.198.193.rev.example.com</a>.</div>
<div dir="auto">194 IN CNAME <a
href="http://194.186.198.193.rev.example.com"
moz-do-not-send="true">194.186.198.193.rev.example.com</a>.</div>
<div dir="auto">…</div>
<div dir="auto"><br>
<div class="gmail_quote" dir="auto">
<div dir="ltr" class="gmail_attr">On Fri, Dec 10, 2021 at
2:51 PM Mirsad Goran Todorovac <<a
href="mailto:mirsad.todorovac@alu.unizg.hr"
moz-do-not-send="true" class="moz-txt-link-freetext">mirsad.todorovac@alu.unizg.hr</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<div>
<p><font style="font-family:monospace;color:rgb(0,0,0)"
face="monospace">Hello,</font></p>
<p><font style="font-family:monospace;color:rgb(0,0,0)"
face="monospace">I have a problem with DHCP DDNS
update to BIND 9 reverse PTR zone subnet that is
owned by several organizations, so I can't get a
direct DHCP DDNS update access with a key or with
hostname.</font></p>
<p><font style="font-family:monospace;color:rgb(0,0,0)"
face="monospace">I have been delegated domain name <code
style="font-family:monospace">192-27.186.198.193.in-addr.arpa
from the upper level admins, and that appears to
be immutable.</code></font></p>
<p><code style="font-family:monospace">However, my
subnet is <a href="http://193.198.186.192/27"
target="_blank" style="font-family:monospace"
moz-do-not-send="true">193.198.186.192/27</a>, and
DHCP only knows how to perform DDNS update to
186.198.193.in-addr.arpa. (See here: <a
href="https://serverfault.com/questions/806875/how-to-tell-isc-dhcp-correct-zone-for-reverse-zone-ddns-update"
target="_blank" style="font-family:monospace"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://serverfault.com/questions/806875/how-to-tell-isc-dhcp-correct-zone-for-reverse-zone-ddns-update</a>
and here: <a
href="https://lists.isc.org/mailman/htdig/dhcp-users/2006-August/001422.html"
target="_blank" style="font-family:monospace"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.isc.org/mailman/htdig/dhcp-users/2006-August/001422.html</a>
).<br>
</code></p>
<p><code style="font-family:monospace">(This setup is
because we have DHCP addresses that are not over
NAT, but /24 subnet is shared with other
organizations, even under another Minstry.)</code></p>
<p><code style="font-family:monospace">I want to have
the effect of delegating the same database to upper
level under their zone name, while updating the same
database under my DHCP-understood zone name.</code></p>
<p><code style="font-family:monospace">I tried this
/etc/bind/named.conf.local:</code></p>
<pre style="font-family:monospace"><code style="font-family:monospace">zone "192-27.186.198.193.in-addr.arpa" in {
type master;
file "/var/cache/bind/192-27.186.198.193.in-addr.arpa.db";
};
zone "186.198.193.in-addr.arpa" in {
type master;
file "/var/cache/bind/192-27.186.198.193.in-addr.arpa.db";
allow-update { key DDNS_UPDATE; };
};
</code></pre>
<font style="font-family:monospace;color:rgb(0,0,0)"
face="monospace"> </font>
<p><font style="font-family:monospace;color:rgb(0,0,0)"
face="monospace">(Two zones with the same file.)</font></p>
<font style="font-family:monospace;color:rgb(0,0,0)"
face="monospace"> </font>
<p><font style="font-family:monospace;color:rgb(0,0,0)"
face="monospace">What I got was:</font></p>
<font style="font-family:monospace;color:rgb(0,0,0)"
face="monospace"> </font>
<pre style="font-family:monospace"><code style="font-family:monospace">root@domac:/etc/bind# named-checkconf
/etc/bind/named.conf.local:49: writeable file '/var/cache/bind/192-27.186.198.193.in-addr.arpa.db': already in use: /etc/bind/named.conf.local:44
root@domac:/etc/bind#
Can you please tell me is there a way to achieve the effect of the above (illegal) setup?
I can't change DHCP nor I know an option to tell it to accept update to </code><code style="font-family:monospace"><code style="font-family:monospace">192-27.186.198.193.in-addr.arpa</code>
(it is a syntax error).
The DHCP dhcpd.conf subnet configuration is:
</code><code style="font-family:monospace"><code style="font-family:monospace">subnet 193.198.186.192 netmask 255.255.255.224 {
range 193.198.186.200 193.198.186.222; # MT 20211210
option subnet-mask 255.255.255.224;
option domain-name-servers 161.53.235.3, 161.53.2.70;
option domain-name "<a href="http://slava.alu.hr" target="_blank" style="font-family:monospace" moz-do-not-send="true">slava.alu.hr</a>";
ddns-domainname "<a href="http://slava.alu.hr" target="_blank" style="font-family:monospace" moz-do-not-send="true">slava.alu.hr</a>";
zone <a href="http://slava.alu.hr" target="_blank" style="font-family:monospace" moz-do-not-send="true">slava.alu.hr</a>. {
primary 127.0.0.1;
key DDNS_UPDATE;
}
zone 186.198.193.in-addr.arpa. {
primary 127.0.0.1;
key DDNS_UPDATE;
}
option broadcast-address 193.198.186.223;
option routers 193.198.186.193;
default-lease-time 43200;
max-lease-time 86400;
}
</code>
Thank you very much for your time reading this mail and help.
Kind regards,
--
Mirsad Goran Todorovac
Academy of Fine Arts | Faculty of Graphic Arts
University of Zagreb
</code></pre>
</div>
_______________________________________________<br>
Please visit <a
href="https://lists.isc.org/mailman/listinfo/bind-users"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.isc.org/mailman/listinfo/bind-users</a>
to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid
support subscriptions. Contact us at <a
href="https://www.isc.org/contact/" rel="noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.isc.org/contact/</a>
for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bind-users@lists.isc.org</a><br>
<a
href="https://lists.isc.org/mailman/listinfo/bind-users"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote>
</div>
</div>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Please visit <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list
ISC funds the development of this software with paid support subscriptions. Contact us at <a class="moz-txt-link-freetext" href="https://www.isc.org/contact/">https://www.isc.org/contact/</a> for more information.
bind-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a>
</pre>
</blockquote>
</body>
</html>