ISC-DHCP and BIND 9 DNS: DDNS update fails for /27 subnet
Mirsad Goran Todorovac
mirsad.todorovac at alu.unizg.hr
Sun Dec 12 09:19:59 UTC 2021
Hi Crist,
Thank you for your explanation. It was much appreciated.
However, as I previously asserted, it is impossible to know how the
system will behave without testing it with real life production load on
Monday :-)
On 12/11/2021 11:18 PM, Crist Clark wrote:
> Looks like you're trying to use the setup in that serverfault link.
> That example only works on an internal network.
I thought the 186.198.193. part was enough to make the zone unique. But
your assertion is correct: I would collide if any other administrators
on other subnets in range 193.198.186.0/24 decide to make reverse DHCP
DDNS update in the future. Thanks for the thought!
> The point of the example I gave is that you are going to build your
> own reverse zone inside of a zone you control on the Internet. Now
> that you've given some examples, I can perhaps make it more obvious
> what I'm suggesting. Your DNS zone would look something like,
>
>> $ORIGIN 192-27.186.198.193.in-addr.arpa.
>>
>> @ IN NS domac.alu.hr <http://domac.alu.hr/>.
>> @ IN NS bjesomar.srce.hr <http://bjesomar.srce.hr/>.
>>
>> 195 IN PTR test-record.dhcp.slava.alu.hr
>> <http://test-record.slava.alu.hr/>.
>>
>> $GENERATE 200-222 $ CNAME $.186.198.193.dhcp.slava.alu.hr
>> <http://186.198.193.dhcp.slava.alu.hr>.
>>
>
> And your DHCP configuration,
>>
>> ddns-domainname "slava.alu.hr <http://slava.alu.hr/>";
>> ddns-rev-domainname "dhcp.slaval.alu.hr <http://dhcp.slaval.alu.hr>";
>> zone slava.alu.hr <http://slava.alu.hr/>. {
>> primary 127.0.0.1;
>> key DDNS_UPDATE;
>> }
>>
> NOT TESTED. NO GUARANTEES. NOT SUITABLE FOR ANY GIVEN PURPOSE. YOUR
> MILEAGE MAY VARY. PLEASE CONSULT YOUR PERSONAL PHYSICIAN BEFORE
> STARTING ISC PRODUCTS.
Noted. :-) I am not afraid of experimenting. But failures of the
experimental setup are perceived as my incompetence, and success taken
for granted the very next day ;-)
> One other odd thing, sometimes you refer to a
> "192/27.186.198.193.in-addr.arpa" zone and sometimes
> "192-27.186.198.193.in-addr.arpa." Those are different names and are
> not interchangeable. Both are totally fine for use in DNS, but a lot
> of administrators don't like the '/' in zone names since they often
> use the zone name in file names. Slashes present a problem in
> file names on *nix flavored OSes. I used the dash, '-', version in my
> example.
This setup is mandated from the upper level sysadmins and I cannot
control it, I can only beg them to use a hyphen as in RFC 2317 chapter 4
last paragraph, but I cannot guarantee that they will change it. It is
their arbitrary decision. :-/
Frankly, /27 is more readable, but if it creates havoc in Linux
resolver, then what the heck ...
Thank you very much again for your advice. I will post back here on the
results with your recommended zone setup.
Kind regards,
Mirsad Todorovac
> Hi again,
>
> 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.
>
> 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.
>
> The zone is:
>
> $ORIGIN 192/27.186.198.193.in-addr.arpa.
>
> @ IN NS domac.alu.hr <http://domac.alu.hr>.
> ;@ IN NS bjesomar.srce.hr <http://bjesomar.srce.hr>.
>
> 195 IN PTR test-record.slava.alu.hr
> <http://test-record.slava.alu.hr>.
>
> 200 IN CNAME 200.186.198.193.dhcp.
> 201 IN CNAME 201.186.198.193.dhcp.
>
> ; MT 20211211:
> ; Here's the magic:
>
> $GENERATE 202-222 $ CNAME $.186.198.193.dhcp.
>
> The command output shows that resolution succeeds, but nslookup
> can't finish it for some unknown spurious reason.
>
> root at domac:~# nslookup -query=any 195.192/27.186.198.193.in-addr.arpa.
> Server: 161.53.235.3
> Address: 161.53.235.3#53
>
> 195.192/27.186.198.193.in-addr.arpa name =
> test-record.slava.alu.hr <http://test-record.slava.alu.hr>.
>
> root at domac:~# nslookup -query=ptr 193.198.186.195
> Server: 161.53.235.3
> Address: 161.53.235.3#53
>
> ** server can't find 195.186.198.193.in-addr.arpa: NXDOMAIN
>
> root at domac:~#
>
> This kind of setup that sometimes works and sometimes doesn't will
> make me look incompetent.
> 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.
>
> The /etc/bind/named.conf.local part looks like:
>
> zone "192/27.186.198.193.in-addr.arpa" in {
> type master;
> file "/etc/bind/zones/192-27.186.198.193.in-addr.arpa.db";
> };
>
> zone "186.198.193.dhcp" in {
> type master;
> file "/var/cache/bind/186.198.193.dhcp.db";
> allow-update { key DDNS_UPDATE; };
> };
>
> 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 <http://test-record.slava.alu.hr>. and
> resolving 193.198.186.195 that apparently fails?
>
> Is there a way to see more interim debugging output?
>
> Thank you very much.
>
> Kind regards,
> Mirsad Todorovac
>
>
>
> On 12/11/2021 10:25 AM, Mirsad Goran Todorovac wrote:
>>
>> Hi Crist,
>>
>> Thank you for your reply and the information provided.
>>
>> 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.
>>
>> 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.
>>
>> I have used the following records in the zone:
>>
>> $ORIGIN 192/27.186.198.193.in-addr.arpa.
>>
>> @ IN NS domac.alu.hr <http://domac.alu.hr>.
>> @ IN NS bjesomar.srce.hr <http://bjesomar.srce.hr>.
>>
>> 195 IN PTR test-record.slava.alu.hr
>> <http://test-record.slava.alu.hr>.
>>
>> $GENERATE 200-222 $ CNAME $.186.198.193.dhcp.
>>
>> /etc/dhcp/dhcpd.conf has this:
>>
>> ddns-domainname "slava.alu.hr <http://slava.alu.hr>";
>> ddns-rev-domainname "dhcp";
>> zone slava.alu.hr <http://slava.alu.hr>. {
>> primary 127.0.0.1;
>> key DDNS_UPDATE;
>> }
>> zone 186.198.193.dhcp. {
>> primary 127.0.0.1;
>> key DDNS_UPDATE;
>> }
>>
>> However, don't I have to convince people managing
>> bjesomar.srce.hr <http://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?
>>
>> Also, I get spurious REFUSED or NXDOMAIN errors, some pass with
>> time, so there must be some TTL or timeout.
>>
>> Kind regards,
>>
>> Mirsad
>>
>> On 12/11/2021 6:04 AM, Crist Clark wrote:
>>> No idea if this is the best way. It is a way.
>>>
>>> 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.
>>>
>>> Configure DHCP to put the reverse records at say,
>>> “rev.example.com.” So you’ll get records at,
>>>
>>> 193.186.198.193.rev.example.com
>>> <http://193.186.198.193.rev.example.com>
>>> 194.186.198.193.rev.example.com
>>> <http://194.186.198.193.rev.example.com>
>>> …
>>>
>>> And in your RFC 2317-style delegation, you then enumerate
>>> another CNAME layer,
>>>
>>> $ORIGIN 192-27.186.198.193.in-addr.arpa.
>>> 193 IN CNAME 193.186.198.193.rev.example.com
>>> <http://193.186.198.193.rev.example.com>.
>>> 194 IN CNAME 194.186.198.193.rev.example.com
>>> <http://194.186.198.193.rev.example.com>.
>>> …
>>>
>>> On Fri, Dec 10, 2021 at 2:51 PM Mirsad Goran Todorovac
>>> <mirsad.todorovac at alu.unizg.hr> wrote:
>>>
>>> Hello,
>>>
>>> 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.
>>>
>>> I have been delegated domain name
>>> |192-27.186.198.193.in-addr.arpa from the upper level
>>> admins, and that appears to be immutable.|
>>>
>>> |However, my subnet is 193.198.186.192/27
>>> <http://193.198.186.192/27>, and DHCP only knows how to
>>> perform DDNS update to 186.198.193.in-addr.arpa. (See here:
>>> https://serverfault.com/questions/806875/how-to-tell-isc-dhcp-correct-zone-for-reverse-zone-ddns-update
>>> and here:
>>> https://lists.isc.org/mailman/htdig/dhcp-users/2006-August/001422.html
>>> ).
>>> |
>>>
>>> |(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.)|
>>>
>>> |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.|
>>>
>>> |I tried this /etc/bind/named.conf.local:|
>>>
>>> |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; }; }; |
>>>
>>> (Two zones with the same file.)
>>>
>>> What I got was:
>>>
>>> |root at 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 at 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 |||192-27.186.198.193.in-addr.arpa| (it is a syntax error).
>>> The DHCP dhcpd.conf subnet configuration is: |||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 "slava.alu.hr
>>> <http://slava.alu.hr>"; ddns-domainname "slava.alu.hr
>>> <http://slava.alu.hr>"; zone slava.alu.hr
>>> <http://slava.alu.hr>. { 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; } | 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 |
>>>
>>> _______________________________________________
>>> Please visit
>>> https://lists.isc.org/mailman/listinfo/bind-users to
>>> unsubscribe from this list
>>>
>>> ISC funds the development of this software with paid support
>>> subscriptions. Contact us at https://www.isc.org/contact/
>>> for more information.
>>>
>>>
>>> bind-users mailing list
>>> bind-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>>>
>>
>> _______________________________________________
>> Please visithttps://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>>
>> ISC funds the development of this software with paid support subscriptions. Contact us athttps://www.isc.org/contact/ for more information.
>>
>>
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20211212/ca156bf9/attachment-0001.htm>
More information about the bind-users
mailing list