[opensuse] ISC bind/dhcpd with dyn updates -- deletes RR but then doesn't add a new one??
All, This is another strange one. (slightly long message with config and logs -- but just one simple issue) I have run bind 9.9 and dhcpd with dynamic zone updates (using TSIG) for nearly 20 years (18 to be exact, and with the TSIG whenever they came along). I'm now seeing funny behavior (and this may be related to how the DHCID TXT has is calculated). What is happening is my sever hands out the IP to the client, and then searches and deletes the record for both forward and reverse zone -- and then doesn't add a forward or reverse zone so name resolution of the client getting the address fails (I see that same behavior in some Linux and some Windows hosts -- but others work fine??) -- that's a new one. (of course all this shows up After a power-outage today that exhausting the UPS so everything came down, server + ~ 25 mixed windows/Linux/phone/tablet hosts) After the server was up and running, take the recent boot of a win7 box hostname sffxe, The TSIG authorization works fine and the zone files are updated removing the IP (which if the IP changed is fine) -- but then doesn't add a new record to the forward or reverse zone. For instance: Apr 20 17:04:42 nirvana named[660]: client 127.0.0.1#11463/key nirvana.mydomain.com: signer "nirvana.mydomain.com" approved Apr 20 17:04:42 nirvana named[660]: client 127.0.0.1#11463/key nirvana.mydomain.com: updating zone 'mydomain.com/IN': deleting an RR at sffxe.mydomain.com A Apr 20 17:04:42 nirvana dhcpd: DHCPREQUEST for 192.168.6.203 from 18:03:73:16:a3:37 (sffxe) via eth0 Apr 20 17:04:42 nirvana dhcpd: DHCPACK on 192.168.6.203 to 18:03:73:16:a3:37 via eth0 Apr 20 17:04:42 nirvana dhcpd: Removed forward map from sffxe.mydomain.com to 192.168.6.203 Apr 20 17:04:42 nirvana named[660]: client 127.0.0.1#11463/key nirvana.mydomain.com: signer "nirvana.mydomain.com" approved Apr 20 17:04:42 nirvana named[660]: client 127.0.0.1#11463/key nirvana.mydomain.com: updating zone 'mydomain.com/IN': deleting an RR at sffxe.mydomain.com TXT Apr 20 17:04:42 nirvana named[660]: client 127.0.0.1#11463/key nirvana.mydomain.com: signer "nirvana.mydomain.com" approved Apr 20 17:04:42 nirvana named[660]: client 127.0.0.1#11463/key nirvana.mydomain.com: updating zone '6.168.192.in-addr.arpa/IN': deleting rrset at '203.6.168.192.in-addr.arpa' PTR Apr 20 17:04:42 nirvana dhcpd: Removed reverse map on 203.6.168.192.in-addr.arpa. Apr 20 17:04:43 nirvana dhcpd: DHCPREQUEST for 192.168.6.203 from 18:03:73:16:a3:37 via eth0 Apr 20 17:04:43 nirvana dhcpd: DHCPACK on 192.168.6.203 to 18:03:73:16:a3:37 via eth0 The only option for dhcpd.conf that I have played with is "update-conflict-detection off;" which I enabled for a day or so after the DHCID TXT records calculation changed on a box or two causing dhcpd to claim the RR in the zone files were "not mine." and refuse to update the record. The "update-conflict-detection off;" setting just tells dhcpd to ignore conflicts in the DHCID TXT record and update the record anyway. I gave it a day and then commented it out. The dhcpd.conf file is: dhcpd.conf option domain-name "mydomain.com"; option domain-name-servers 192.168.6.17; option routers 192.168.6.11; option ntp-servers 192.168.6.17; option netbios-name-servers 192.168.6.17; default-lease-time 28800; # Enable DDNS Update ddns-update-style interim; ddns-updates on; # fix not mine for DHCID TXT mismatch # update-conflict-detection off; ignore client-updates; include "/etc/named.keys"; authoritative; subnet 192.168.6.0 netmask 255.255.255.0 { option domain-name "mydomain.com"; ddns-domainname "mydomain.com"; option subnet-mask 255.255.255.0; range dynamic-bootp 192.168.6.110 192.168.6.224; default-lease-time 28800; max-lease-time 86400; zone mydomain.com. {primary 127.0.0.1; key nirvana.mydomain.com; } zone 6.168.192.in-addr.arpa. { primary 127.0.0.1; key nirvana.mydomain.com; } } The named.conf hasn't changed at all, and for completeness it is: named.conf include "/etc/rndc.key"; include "/etc/named.keys"; controls { inet 127.0.0.1 allow { localhost; } keys { rndc-key; }; }; options { directory "/var/named"; pid-file "/var/run/named/named.pid"; dump-file "/var/log/named_dump.db"; statistics-file "/var/log/named.stats"; forwarders { 208.180.42.100; 66.76.175.100; 8.8.4.4; }; forward first; listen-on-v6 { none; }; edns-udp-size 512; }; zone "localhost" { type master; file "localhost.zone"; }; zone "0.0.127.in-addr.arpa" { type master; file "127.0.0.zone"; }; zone "mydomain.com" { type master; file "dyn/mydomain.com"; allow-update{ key nirvana.mydomain.com; }; }; zone "6.168.192.in-addr.arpa" { type master; file "dyn/192.168.6.zone"; allow-update{ key nirvana.mydomain.com; }; }; What is odd is that some clients are working just fine, e.g. Apr 20 22:30:28 nirvana dhcpd: DHCPDISCOVER from c0:e4:34:8f:c4:13 via eth0 Apr 20 22:30:29 nirvana dhcpd: DHCPOFFER on 192.168.6.202 to c0:e4:34:8f:c4:13 (SHPw10) via eth0 Apr 20 22:30:29 nirvana named[3963]: client 127.0.0.1#43640/key nirvana.mydomain.com: signer "nirvana.mydomain.com" approved Apr 20 22:30:29 nirvana named[3963]: client 127.0.0.1#43640/key nirvana.mydomain.com: updating zone 'mydomain.com/IN': adding an RR at 'SHPw10.mydomain.com' A Apr 20 22:30:29 nirvana named[3963]: client 127.0.0.1#43640/key nirvana.mydomain.com: updating zone 'mydomain.com/IN': adding an RR at 'SHPw10.mydomain.com' TXT Apr 20 22:30:29 nirvana dhcpd: DHCPREQUEST for 192.168.6.202 (192.168.6.17) from c0:e4:34:8f:c4:13 (SHPw10) via eth0 Apr 20 22:30:29 nirvana dhcpd: DHCPACK on 192.168.6.202 to c0:e4:34:8f:c4:13 (SHPw10) via eth0 Apr 20 22:30:29 nirvana dhcpd: Added new forward map from SHPw10.mydomain.com to 192.168.6.202 Apr 20 22:30:29 nirvana named[3963]: client 127.0.0.1#43640/key nirvana.mydomain.com: signer "nirvana.mydomain.com" approved Apr 20 22:30:29 nirvana named[3963]: client 127.0.0.1#43640/key nirvana.mydomain.com: updating zone '6.168.192.in-addr.arpa/IN': deleting rrset at '202.6.168.192.in-addr.arpa' PTR Apr 20 22:30:29 nirvana named[3963]: client 127.0.0.1#43640/key nirvana.mydomain.com: updating zone '6.168.192.in-addr.arpa/IN': adding an RR at '202.6.168.192.in-addr.arpa' PTR Apr 20 22:30:29 nirvana dhcpd: Added reverse map from 202.6.168.192.in-addr.arpa. to SHPw10.mydomain.com What is going on here? Has dhcpd/named lost their frigging mind?? Old dhcpd.leases screwing this up (since you can nuke them). What's more, attempting a manual nsupdate times out: # nsupdate -d -L 3 -k /etc/Knirvana.mydomain.com.+157+16510.key 20-Apr-2020 22:10:25.646 dns_requestmgr_create 20-Apr-2020 22:10:25.646 dns_requestmgr_create: 0x7fca4e180010 Creating key...
server localhost 53 zone mydomain.com update add sffxe.mydomain.com 86400 A 192.168.6.203 show Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 ;; ZONE SECTION: ;mydomain.com. IN SOA
;; UPDATE SECTION: sffxe.mydomain.com. 86400 IN A 192.168.6.203
send Sending update to ::1#53 20-Apr-2020 22:11:17.725 dns_request_createvia 20-Apr-2020 22:11:17.725 request_render 20-Apr-2020 22:11:17.725 requestmgr_attach: 0x7fca4e180010: eref 1 iref 1 20-Apr-2020 22:11:17.725 mgr_gethash 20-Apr-2020 22:11:17.725 req_send: request 0x7fca4e189010 20-Apr-2020 22:11:17.725 dns_request_createvia: request 0x7fca4e189010 Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 28965 ;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1 ;; ZONE SECTION: ;mydomain.com. IN SOA
;; UPDATE SECTION: sffxe.mydomain.com. 86400 IN A 192.168.6.203 ;; TSIG PSEUDOSECTION: nirvana.mydomain.com. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1587438677 300 16 <stuff>== 28965 NOERROR 0 20-Apr-2020 22:11:17.725 req_senddone: request 0x7fca4e189010 20-Apr-2020 22:11:20.728 req_timeout: request 0x7fca4e189010 20-Apr-2020 22:11:20.728 req_send: request 0x7fca4e189010 20-Apr-2020 22:11:20.728 req_senddone: request 0x7fca4e189010 20-Apr-2020 22:11:23.731 req_timeout: request 0x7fca4e189010 What do you mean req_timeout?? I don't know, this has been bewildering. The only thing I can think of is that on startup dhcpd shows 52 leases written: Apr 20 22:12:38 nirvana dhcpd: Wrote 0 deleted host decls to leases file. Apr 20 22:12:38 nirvana dhcpd: Wrote 0 new dynamic host decls to leases file. Apr 20 22:12:38 nirvana dhcpd: Wrote 52 leases to leases file. I don't know why there are so many leases -- though one thing that is now a challenge that wasn't before is all the mobile devices that may leave for less than the lease time, go somewhere, get a new IP and lease, and then return while their lease from my server is still active (which may account for more leases than devices by a factor of 2). But the hosts that are have their RR removed and no new ones written are actual computers -- not mobile devices, and the computers haven't gone anywhere. So I kick this to the brain trust to see if anybody has better insight to how this can happen than I do -- I'm obviously not doing too well with this one :) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/20/2020 11:21 PM, David C. Rankin wrote:
All,
This is another strange one. (slightly long message with config and logs -- but just one simple issue)
I have run bind 9.9 and dhcpd with dynamic zone updates (using TSIG) for nearly 20 years (18 to be exact, and with the TSIG whenever they came along). I'm now seeing funny behavior (and this may be related to how the DHCID TXT has is calculated).
What is happening is my sever hands out the IP to the client, and then searches and deletes the record for both forward and reverse zone -- and then doesn't add a forward or reverse zone so name resolution of the client getting the address fails (I see that same behavior in some Linux and some Windows hosts -- but others work fine??) -- that's a new one.
Okay, I think we found the culprit. The dhcpd.leases file had 113 entries, of that one IP was duplicated 47 times (with a number of different IPs) and there were others duplicated a lesser number of times. So I backed up the leases file and stopped the server and pulled-out the big guns... :>dhcpd.leases (sometimes, you just gotta start fresh -- I'll let you know how it goes :) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin wrote:
Okay,
I think we found the culprit. The dhcpd.leases file had 113 entries, of that one IP was duplicated 47 times (with a number of different IPs) and there were others duplicated a lesser number of times. So I backed up the leases file and stopped the server and pulled-out the big guns...
:>dhcpd.leases
(sometimes, you just gotta start fresh -- I'll let you know how it goes :)
David, I also had some issue like that, maybe in the last 5-6 weeks - I also had to fiddle with dhcpd.leases which I've never had to before, ever. My dhcpd is quite old, 4.1 I think - in mid-March, I discussed it with someone off-line, he said there was an issue with the way the client-id is being generated. I have not looked into any further. -- Per Jessen, Zürich (10.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/21/2020 02:27 AM, Per Jessen wrote:
David C. Rankin wrote:
Okay,
I think we found the culprit. The dhcpd.leases file had 113 entries, of that one IP was duplicated 47 times (with a number of different IPs) and there were others duplicated a lesser number of times. So I backed up the leases file and stopped the server and pulled-out the big guns...
:>dhcpd.leases
(sometimes, you just gotta start fresh -- I'll let you know how it goes :)
David, I also had some issue like that, maybe in the last 5-6 weeks - I also had to fiddle with dhcpd.leases which I've never had to before, ever.
My dhcpd is quite old, 4.1 I think - in mid-March, I discussed it with someone off-line, he said there was an issue with the way the client-id is being generated. I have not looked into any further.
All appears to be working normally. I went ahead and added the "update-conflict-detection off;" option to dhcpd.conf to clear out the records with no corresponding TXT (that I added to the zone files). I'll check back in a few days and if needed, I'll really start from scratch (shutdown both dhcpcd and named, truncate the dhcpd.leases file and removal all entries from the zones except the static entries and let it all rebuild as host ask for a new lease) I also have never had this issue before. I have had some funkynes with some of the kids devices, but never really any problem with a host forward or reverse entry being added. I guess it finally got bad enough and the conflicts too great for the system to handle. All good now. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
This sort of craziness is why I dropped this and started using dnsmasq. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/21/2020 06:49 AM, Anton Aylward wrote:
This sort of craziness is why I dropped this and started using dnsmasq.
Chuckling... ISC dhcpd and bind9 are kind of like a comfortable pair of house-shoes... If I only have to worry with the leases file once every 15 years or so -- I'm good with that :p I have been tempted to look at dnsmasq a time or two, but I never looked hard enough to determine whether it could provide the same primary/secondary dns capability with automatic failover if the primary goes down. Once you make friends with cobbling together the zone files, the dhcpd with dynamic update to dns is a fire-and-forget solution. (except about once a decade if something like this TXT record calculation pops up) Aside from that, once configured -- it's just a make copy your config sure you enable the services during install of a new system and you are done. (here's to hoping it stays that way...) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin wrote:
On 04/21/2020 06:49 AM, Anton Aylward wrote:
This sort of craziness is why I dropped this and started using dnsmasq.
Chuckling...
ISC dhcpd and bind9 are kind of like a comfortable pair of house-shoes...
Nice one David. <GRIN>
I have been tempted to look at dnsmasq a time or two, but I never looked hard enough to determine whether it could provide the same primary/secondary dns capability with automatic failover if the primary goes down.
I actually use dnsmasq, but only for my openSUSE VPN connection. I cannot imagine replacing bind+dhcp site-wide - just no need. -- Per Jessen, Zürich (15.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 21/04/2020 14:18, Per Jessen wrote:
David C. Rankin wrote:
On 04/21/2020 06:49 AM, Anton Aylward wrote:
This sort of craziness is why I dropped this and started using dnsmasq.
Chuckling...
ISC dhcpd and bind9 are kind of like a comfortable pair of house-shoes... Nice one David. <GRIN>
Flash-reading that i first thought he said "HORSE-shoes" and wondered about 'technological sophistication'. After all, how many blacksmiths/farriers are there in the city? Well OK, here the RCMP have a mounted division, though I sometimes wonder if it isn't mostly for show, so they do have their own (private) farrier. But, yes, riding horses is a hobby in many cities though it is a necessity in many farming regions. For many of us the closest we'll come to a blacksmith is a hardware store, "Rona", "Home Hardware" or similar. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 21/04/2020 13:53, David C. Rankin wrote:
I have been tempted to look at dnsmasq a time or two, but I never looked hard enough to determine whether it could provide the same primary/secondary dns capability with automatic failover if the primary goes down.
I'm assured it has but never tried it myself. GoGoogle for yourself :-) The way I'm running at the moment my cable router-to-the-internet does a first level of DHCP to a variety of devices and one of them is a switch. Things hang off the switch, such as this computer and the printer beside it, and the switch has its own level of DHCP. As a result there is no need for this computer to run DHCP. Just make sure that each hands out proper routing information in its DHCP packets :-) :-) :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (3)
-
Anton Aylward -
David C. Rankin -
Per Jessen