Re: BIND9: one zone is not up to date
Dear Roberto, It is hard to say without seeing the named.conf.local, but are you sure you have incremented the serial? Kind regards, Mirsad On 12/13/2021 7:24 PM, Roberto Carna wrote: Dear all, I have BIND 9 and Webmin. One master and one slave using zne ransfer with TSIG Everything was Ok till today. When I add or modify a record for zone1.com in the master, the record in the slave is up to date. But when I add or modify a record for zone2.com in the master, the record is not updated in the slave, however the log in /var/log/bind/bind.log tell me the update operation was OK: 13-Dec-2021 14:46:24.558 notify: info: client @0x7fe8ec5532f0 172.17.1.2#56011/key xxx: received notify for zone 'zone2.com': TSIG 'xxx' 13-Dec-2021 14:46:24.558 general: info: zone zone2.com/IN: notify from 172.17.1.2#56011: zone is up to date What can be the problem? I see everything well defined. Special thanks ! ___ 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@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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND9: one zone is not up to date
Dear all, I have BIND 9 and Webmin. One master and one slave using zne ransfer with TSIG Everything was Ok till today. When I add or modify a record for zone1.com in the master, the record in the slave is up to date. But when I add or modify a record for zone2.com in the master, the record is not updated in the slave, however the log in /var/log/bind/bind.log tell me the update operation was OK: 13-Dec-2021 14:46:24.558 notify: info: client @0x7fe8ec5532f0 172.17.1.2#56011/key xxx: received notify for zone 'zone2.com': TSIG 'xxx' 13-Dec-2021 14:46:24.558 general: info: zone zone2.com/IN: notify from 172.17.1.2#56011: zone is up to date What can be the problem? I see everything well defined. Special thanks ! ___ 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
re: insecurity proof failed for a domain
If you update your resolver to 9.16, I think you can do exactly what you
want with the "validate-execpt" option.
{rolls eyes} been there. done that. for exactly the same reason :/
--
--
Do things because you should, not just because you can.
John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC-DHCP and BIND 9 DNS: DDNS update fails for /27 subnet P.S.
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@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@domac:/etc/bind/zones# nslookup 193.198.186.201 ** server can't find 201.186.198.193.in-addr.arpa: NXDOMAIN root@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@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@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 addr
insecurity proof failed for a domain
Hello,
I need to internaly forward domain to different nameserver:
zone "x.local" {
type forward;
forward only;
forwarders {
100.1.2.3;
};
};
when I do this with bind 9.11 (debian 10), I get these messages:
Dec 13 14:26:55 mail named[13112]: validating x.local/A: got insecure
response; parent indicates it should be secure
Dec 13 14:26:55 mail named[13112]: insecurity proof failed resolving
'x.local/ANY/IN': 100.1.2.3#53
Dec 13 14:26:55 mail named[13112]: validating x.local/NS: got insecure
response; parent indicates it should be secure
Dec 13 14:26:55 mail named[13112]: validating x.local/SOA: got insecure
response; parent indicates it should be secure
looks like I could avoig this by disabling dnssec but is there any way to
disable this checking only for domain "local" or "x.local"?
I have tried to create empty "local" domain but then I only received empty
responses for any requests.
(I know .local is for mdns, but I can't do anything with that).
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Saving Private Ryan...
Private Ryan exists. Overwrite? (Y/N)
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC-DHCP and BIND 9 DNS: DDNS update fails for /27 subnet P.S.
Hello Crist, P.S. Thank you again for your time and effort. Your expertise is very much appreciated. The thingy appears to work snappy 😎! It is true that domac.alu.hr recognizes only itself as the authoritative NS for 193.198.186.192/27 zone. I had to comment out the bjesomar.srce.hr delegation as NS because it caused spurious failures in reverse resolution. Now you have made clear why. The error was made upstream, out of my possibility to fix. I have discretely requested that the zone is enabled on bjesomar.srce.hr, but I can't do anything else. RFC 2317 chapter 5.1 says the name resolution is more stable with the secondary (slave) servers for the zone. Kind regards, Mirsad Todorovac On 13.12.2021. 9:25, Mirsad Goran Todorovac wrote: Hello Crist, The good news is that it seems that the dynamic DDNS update from DHCP works! See here a snap from /var/log/syslog: Dec 13 07:36:20 domac dhcpd[26031]: DHCPDISCOVER from 1c:66:6d:90:0b:f7 (ALU-ZAG-14) via 193.198.186.193 Dec 13 07:36:20 domac dhcpd[26031]: DHCPOFFER on 193.198.186.219 to 1c:66:6d:90:0b:f7 (ALU-ZAG-14) via 193.198.186.193 Dec 13 07:36:20 domac dhcpd[26031]: DHCPREQUEST for 193.198.186.219 (161.53.235.3) from 1c:66:6d:90:0b:f7 (ALU-ZAG-14) via 193.198.186.193 Dec 13 07:36:20 domac dhcpd[26031]: DHCPACK on 193.198.186.219 to 1c:66:6d:90:0b:f7 (ALU-ZAG-14) via 193.198.186.193 Dec 13 07:36:20 domac dhcpd[26031]: Added new forward map from ALU-ZAG-14.slava.alu.hr to 193.198.186.219 Dec 13 07:36:20 domac dhcpd[26031]: Added reverse map from 219.186.198.193.dhcp.slava.alu.hr to ALU-ZAG-14.slava.alu.hr The test shows this: root@domac:~# dig ALU-ZAG-14.slava.alu.hr ; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> ALU-ZAG-14.slava.alu.hr ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17082 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 0e131d851cc6d9b1c609407461b6ee098db47da23e5ea971 (good) ;; QUESTION SECTION: ;ALU-ZAG-14.slava.alu.hr. IN A ;; ANSWER SECTION: ALU-ZAG-14.slava.alu.hr. 3600 IN A 193.198.186.219 ;; AUTHORITY SECTION: slava.alu.hr. 600 IN NS domac.alu.hr. ;; ADDITIONAL SECTION: domac.alu.hr. 86400 IN A 161.53.235.3 ;; Query time: 0 msec ;; SERVER: 161.53.235.3#53(161.53.235.3) ;; WHEN: Mon Dec 13 07:54:01 CET 2021 ;; MSG SIZE rcvd: 132 root@domac:~# dig -x 193.198.186.219 ; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> -x 193.198.186.219 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59076 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: c733edf748fdf3e2b91eb45761b6ee172d4cf73a7033ec4e (good) ;; QUESTION SECTION: ;219.186.198.193.in-addr.arpa. IN PTR ;; ANSWER SECTION: 219.186.198.193.in-addr.arpa. 13398 IN CNAME 219.192/27.186.198.193.in-addr.arpa. 219.192/27.186.198.193.in-addr.arpa. 900 IN CNAME 219.186.198.193.dhcp.slava.alu.hr. 219.186.198.193.dhcp.slava.alu.hr. 3600 IN PTR ALU-ZAG-14.slava.alu.hr. ;; AUTHORITY SECTION: 186.198.193.dhcp.slava.alu.hr. 600 IN NS domac.alu.hr. ;; ADDITIONAL SECTION: domac.alu.hr. 86400 IN A 161.53.235.3 ;; Query time: 0 msec ;; SERVER: 161.53.235.3#53(161.53.235.3) ;; WHEN: Mon Dec 13 07:54:15 CET 2021 ;; MSG SIZE rcvd: 218 root@domac:~# Thank you for all the help. I didn't really see it coming that our reverse network will become globally visible immediately when I put it under slava.alu.hr! (I planned to request adding by the upstream administrators.) Thank you again for all the help. As for the problem you mentioned, can I forward this email to our CARNet sysadmins? I have requested that they add bjesomar.srce.hr as the secondary server for the 193.198.186.192/27 reverse zone. I suppose that could resolve the problem as well. So far they said they would do it, but with nslookup -query=any 192/27.186.198.193.in-addr.arpa I see only domac.alu.hr as NS for the zone. I hope that will go away with this change. I was surprised how nslookup can connect 193.198.186.201 to 201.192/27.186.198.193.in-addr.arpa to 201.186.198.193.dhcp.slava.alu.hr, and 201.186.198.193.dhcp.slava.alu.hr to test-record2.slava.alu.hr, but not 193.198.186.201 to test-record2.slava.alu.hr. It was unable to sum up the things together? Thanks again, I will happy that the reverse /27 subnet DDNS DHCP setup works. 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
Re: ISC-DHCP and BIND 9 DNS: DDNS update fails for /27 subnet P.S.
Hello Crist, The good news is that it seems that the dynamic DDNS update from DHCP works! See here a snap from /var/log/syslog: Dec 13 07:36:20 domac dhcpd[26031]: DHCPDISCOVER from 1c:66:6d:90:0b:f7 (ALU-ZAG-14) via 193.198.186.193 Dec 13 07:36:20 domac dhcpd[26031]: DHCPOFFER on 193.198.186.219 to 1c:66:6d:90:0b:f7 (ALU-ZAG-14) via 193.198.186.193 Dec 13 07:36:20 domac dhcpd[26031]: DHCPREQUEST for 193.198.186.219 (161.53.235.3) from 1c:66:6d:90:0b:f7 (ALU-ZAG-14) via 193.198.186.193 Dec 13 07:36:20 domac dhcpd[26031]: DHCPACK on 193.198.186.219 to 1c:66:6d:90:0b:f7 (ALU-ZAG-14) via 193.198.186.193 Dec 13 07:36:20 domac dhcpd[26031]: Added new forward map from ALU-ZAG-14.slava.alu.hr to 193.198.186.219 Dec 13 07:36:20 domac dhcpd[26031]: Added reverse map from 219.186.198.193.dhcp.slava.alu.hr to ALU-ZAG-14.slava.alu.hr The test shows this: root@domac:~# dig ALU-ZAG-14.slava.alu.hr ; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> ALU-ZAG-14.slava.alu.hr ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17082 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 0e131d851cc6d9b1c609407461b6ee098db47da23e5ea971 (good) ;; QUESTION SECTION: ;ALU-ZAG-14.slava.alu.hr. IN A ;; ANSWER SECTION: ALU-ZAG-14.slava.alu.hr. 3600 IN A 193.198.186.219 ;; AUTHORITY SECTION: slava.alu.hr. 600 IN NS domac.alu.hr. ;; ADDITIONAL SECTION: domac.alu.hr. 86400 IN A 161.53.235.3 ;; Query time: 0 msec ;; SERVER: 161.53.235.3#53(161.53.235.3) ;; WHEN: Mon Dec 13 07:54:01 CET 2021 ;; MSG SIZE rcvd: 132 root@domac:~# dig -x 193.198.186.219 ; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> -x 193.198.186.219 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59076 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: c733edf748fdf3e2b91eb45761b6ee172d4cf73a7033ec4e (good) ;; QUESTION SECTION: ;219.186.198.193.in-addr.arpa. IN PTR ;; ANSWER SECTION: 219.186.198.193.in-addr.arpa. 13398 IN CNAME 219.192/27.186.198.193.in-addr.arpa. 219.192/27.186.198.193.in-addr.arpa. 900 IN CNAME 219.186.198.193.dhcp.slava.alu.hr. 219.186.198.193.dhcp.slava.alu.hr. 3600 IN PTR ALU-ZAG-14.slava.alu.hr. ;; AUTHORITY SECTION: 186.198.193.dhcp.slava.alu.hr. 600 IN NS domac.alu.hr. ;; ADDITIONAL SECTION: domac.alu.hr. 86400 IN A 161.53.235.3 ;; Query time: 0 msec ;; SERVER: 161.53.235.3#53(161.53.235.3) ;; WHEN: Mon Dec 13 07:54:15 CET 2021 ;; MSG SIZE rcvd: 218 root@domac:~# Thank you for all the help. I didn't really see it coming that our reverse network will become globally visible immediately when I put it under slava.alu.hr! (I planned to request adding by the upstream administrators.) Thank you again for all the help. As for the problem you mentioned, can I forward this email to our CARNet sysadmins? I have requested that they add bjesomar.srce.hr as the secondary server for the 193.198.186.192/27 reverse zone. I suppose that could resolve the problem as well. So far they said they would do it, but with nslookup -query=any 192/27.186.198.193.in-addr.arpa I see only domac.alu.hr as NS for the zone. I hope that will go away with this change. I was surprised how nslookup can connect 193.198.186.201 to 201.192/27.186.198.193.in-addr.arpa to 201.186.198.193.dhcp.slava.alu.hr, and 201.186.198.193.dhcp.slava.alu.hr to test-record2.slava.alu.hr, but not 193.198.186.201 to test-record2.slava.alu.hr. It was unable to sum up the things together? Thanks again, I will happy that the reverse /27 subnet DDNS DHCP setup works. 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 ;;
