ISC-DHCP and BIND 9 DNS: DDNS update fails for /27 subnet P.S.
Mirsad Goran Todorovac
mirsad.todorovac at alu.unizg.hr
Mon Dec 13 14:08:23 UTC 2021
Hello Crist,
This problem you have spotted in your troubleshooting was fixed by the
uplevel sysadmins.
Now I have added bjesomar.srce.hr as the secondary (I don't like the
expressions "master" and "slave") NS for 193.198.186.192/27.
It appears to work. There seem to be more DHCP problems than I
anticipated, but this is off topic for the BIND-users list I suppose.
Thank you very much for all the help!
I thought of writing some dissemination on the problem, maybe a web page
or something people could Google up so you do not always reply to the
same questions?
I dismayed at the scarcity of documentation on dynamic DDNS updates from
DHCP for reverse PTR sub-/24 subnets ...
Kind regards,
Mirsad Todorovac
On 13.12.2021. 7:10, Crist Clark wrote:
> First, for troubleshooting, do not use nslookup(1). If you have BIND,
> use dig(1) and host(1).
>
> Since these names are out there on the Internet, we can troubleshoot too!
>
> I'm noticing a problem with the delegation for the
> 192/27.186.198.193.in-addr.arpa zone. The servers for
> 186.198.193.in-addr.arpa,
>
> dns1.CARNet.hr
> dns2.CARNet.hr
>
> Return these two DNS servers,
>
> $ dig -x 193.198.186.192/27 ns @dns1.carnet.hr
>
> ; <<>> DiG 9.16.22 <<>> -x 193.198.186.192/27 ns @dns1.carnet.hr
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8342
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;192/27.186.198.193.in-addr.arpa. IN NS
>
> ;; AUTHORITY SECTION:
> 192/27.186.198.193.in-addr.arpa. 14400 IN NS bjesomar.srce.hr.
> 192/27.186.198.193.in-addr.arpa. 14400 IN NS domac.alu.hr.
>
> ;; Query time: 182 msec
> ;; SERVER: 2001:b68:ff:2::2#53(2001:b68:ff:2::2)
> ;; WHEN: Sun Dec 12 22:03:39 PST 2021
> ;; MSG SIZE rcvd: 114
>
> However, if I check that against those servers, domac.alu.hr works
> (although it only returns itself as authoritative for the domain), and
> bjsomar.srce.hr sends a REFUSED response,
>
> dig -x 193.198.186.192/27 ns @bjesomar.srce.hr
>
> ; <<>> DiG 9.16.22 <<>> -x 193.198.186.192/27 ns @bjesomar.srce.hr
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 43941
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 341626673209a23b4777d39761b6e2f9656e01a40d454dcd (good)
> ;; QUESTION SECTION:
> ;192/27.186.198.193.in-addr.arpa. IN NS
>
> ;; Query time: 181 msec
> ;; SERVER: 2001:b68:c:2::70:0#53(2001:b68:c:2::70:0)
> ;; WHEN: Sun Dec 12 22:06:50 PST 2021
> ;; MSG SIZE rcvd: 88
>
>
>
> On 2021-12-12 06:45, Mirsad Goran Todorovac wrote:
>> Hello Crist,
>>
>> I have implemented the recommended changes. It works forward and
>> reverse for the test record, from out domain or others, or for almost
>> all of the test records.
>>
>> There are still some spurious failures, such as this one:
>>
>> 200 IN CNAME 200.186.198.193.dhcp.slava.alu.hr.
>> 201 IN CNAME 201.186.198.193.dhcp.slava.alu.hr.
>>
>> nslookup 193.198.186.200 works and .201 doesn't, despite the symmetric
>> definition:
>>
>> root at domac:/etc/bind/zones# nslookup 193.198.186.200
>> 200.186.198.193.in-addr.arpa canonical name =
>> 200.192/27.186.198.193.in-addr.arpa.
>> 200.192/27.186.198.193.in-addr.arpa canonical name =
>> 200.186.198.193.dhcp.slava.alu.hr.
>> 200.186.198.193.dhcp.slava.alu.hr name =
>> test-record1.slava.alu.hr.
>>
>> Authoritative answers can be found from:
>> 186.198.193.dhcp.slava.alu.hr nameserver = domac.alu.hr.
>> domac.alu.hr internet address = 161.53.235.3
>>
>> root at domac:/etc/bind/zones# nslookup 193.198.186.201
>> ** server can't find 201.186.198.193.in-addr.arpa: NXDOMAIN
>>
>> root at domac:/etc/bind/zones#
>>
>> I can't get to the bottom of this, I don't know enough BIND9
>> internals.
>>
>> It will take real-life production load tomorrow to see how this will
>> behave with DHCP DDNS updates. :-)
>>
>> You said ABSOLUTELY NO WARRANTY but I am an open source fan and I can
>> live with that ;-)
>>
>> Until tomorrow, then ...
>>
>> Kind regards,
>> Mirsad Todorovac
>> On 12/12/2021 10:33 AM, Mirsad Goran Todorovac wrote:
>>
>>> Hi Crist,
>>>
>>> Now the resolution from the problematic record started working again
>>> without any change in zones or BIND9 options, also without the
>>> server process restart ... :-/
>>>
>>> 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.
>>>
>>> root at domac:~# nslookup -query=ptr 193.198.186.195
>>> Server: 161.53.235.3
>>> Address: 161.53.235.3#53
>>>
>>> Non-authoritative answer:
>>> 195.186.198.193.in-addr.arpa canonical name =
>>> 195.192/27.186.198.193.in-addr.arpa.
>>> 195.192/27.186.198.193.in-addr.arpa name =
>>> test-record.slava.alu.hr.
>>>
>>> Authoritative answers can be found from:
>>> 192/27.186.198.193.in-addr.arpa nameserver = domac.alu.hr.
>>> domac.alu.hr internet address = 161.53.235.3
>>>
>>> root at domac:~#
>>>
>>> I guess this was something with timeouts. Suppose this will work
>>> satisfactory on desktops that usually keep the same IP address
>>> assigned by DHCP across the lease renewals, but not for laptops,
>>> Android and iPhone devices that connect and disconnect, and change
>>> network ...
>>>
>>> Why I want smartphones to have reverse PTRs is to see in logs if
>>> something becomes virus infected or even spambot, and not have to
>>> browse DHCP leases in forensic analysis, which my fellow
>>> administrator probably would not know how to do ...
>>>
>>> Kind regards,
>>> Mirsad Todorovac
>>> On 12/12/2021 10:19 AM, Mirsad Goran Todorovac wrote:
>>>
>>> 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 [1].
>>> @ IN NS bjesomar.srce.hr [2].
>>>
>>> 195 IN PTR test-record.dhcp.slava.alu.hr [3].
>>>
>>> $GENERATE 200-222 $ CNAME $.186.198.193.dhcp.slava.alu.hr [4].
>>>
>>> And your DHCP configuration,
>>>
>>> ddns-domainname "slava.alu.hr [5]";
>>> ddns-rev-domainname "dhcp.slaval.alu.hr [6]";
>>> zone slava.alu.hr [5]. {
>>> 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 [8].
>>> ;@ IN NS bjesomar.srce.hr [9].
>>>
>>> 195 IN PTR test-record.slava.alu.hr [10].
>>>
>>> 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 [10].
>>>
>>> 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
>>> [10]. 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 [8].
>>> @ IN NS bjesomar.srce.hr [9].
>>>
>>> 195 IN PTR test-record.slava.alu.hr [10].
>>>
>>> $GENERATE 200-222 $ CNAME $.186.198.193.dhcp.
>>>
>>> /etc/dhcp/dhcpd.conf has this:
>>>
>>> ddns-domainname "slava.alu.hr [7]";
>>> ddns-rev-domainname "dhcp";
>>> zone slava.alu.hr [7]. {
>>> 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
>>> [9] 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 [11]
>>> 194.186.198.193.rev.example.com [12]
>>> …
>>>
>>> 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 [11].
>>> 194 IN CNAME 194.186.198.193.rev.example.com [12].
>>> …
>>>
>>> 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 [13], 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 [7]";
>>> ddns-domainname "slava.alu.hr [7]";
>>> zone slava.alu.hr [7]. {
>>> 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 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 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 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
>>
>>
>>
>> Links:
>> ------
>> [1] http://domac.alu.hr/
>> [2] http://bjesomar.srce.hr/
>> [3] http://test-record.slava.alu.hr/
>> [4] http://186.198.193.dhcp.slava.alu.hr
>> [5] http://slava.alu.hr/
>> [6] http://dhcp.slaval.alu.hr
>> [7] http://slava.alu.hr
>> [8] http://domac.alu.hr
>> [9] http://bjesomar.srce.hr
>> [10] http://test-record.slava.alu.hr
>> [11] http://193.186.198.193.rev.example.com
>> [12] http://194.186.198.193.rev.example.com
>> [13] http://193.198.186.192/27
--
Mirsad Todorovac
CARNet sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu
More information about the bind-users
mailing list