dnssec not automatically updating on 1 server
Anybody have any ideas on why my dnssec records don't always automatically
update on my NS2 authoritative server? On my NS1 authoritative server the
records update without issue.
NS2 is an exact copy of NS1. We SCP all of the config files from the first
server to the second server and do "rndc reconfig && rndc reload && systemctl
restart bind" on both servers.
They are both Centos 7 running Bind 9.16.40.
When it fails, I get this message:
[root@ns2 ~]# delv itctel.com @ns2.itctel.com
;; validating itctel.com/A: verify failed due to bad signature (keyid=3593):
RRSIG has expired
;; validating itctel.com/A: no valid signature found
;; RRSIG has expired resolving 'itctel.com/A/IN': 75.102.160.231#53
;; validating itctel.com/A: verify failed due to bad signature (keyid=3593):
RRSIG has expired
;; validating itctel.com/A: no valid signature found
;; RRSIG has expired resolving 'itctel.com/A/IN':
2607:d600:9000:300:75:102:160:231#53
;; resolution failed: RRSIG has expired
I have this policy in named.conf
dnssec-policy "itc-no-rotate" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
I have this set up in a custom includes file:
zone "itctel.com" in {
type master;
file "forward/itctel.com.zone";
dnssec-policy itc-no-rotate;
inline-signing yes;
};
No changes to my actual zone files. The inline signing takes care of everything.
Here is a list of my files for this domain
/var/named/forward/itctel.com.zone /var/named/forward/itctel.com.zone.jnl
/var/named/forward/itctel.com.zone.signed
/var/named/forward/itctel.com.zone.jbk /var/named/forward/itctel.com.zone.new
/var/named/forward/itctel.com.zone.signed.jnl
Michael Martinell
Network/Broadband Technician
Interstate Telecommunications Coop., Inc.
312 4th Street West * Clear Lake, SD 57226
Phone: (605) 874-8313
michael.martin...@itccoop.com
www.itc-web.com
--
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
9.18 BIND not iterated over all authoritative nameservers
Hello, At this point I am hoping that somebody might have a workaround so that we can exclude domains from this behavior if they are broken on the far end. Does anybody have a workaround for this? We are a small ISP and run BIND compiled from source. We currently run 9.16.x Every time we try to move forward with 9.18 customers start to complain that they are unable to reach certain websites. This includes banks, universities, and other organizations. I understand the goal is to get all DNS to RFC 6891, but from a practical standpoint, this isn't working for customers, so we are prevented from upgrading either. Related website: https://gitlab.isc.org/isc-projects/bind9/-/issues/3152 Our source code compile options: ./configure --with-gnu-ld --with-libxml2 --with-json-c --with-openssl=/usr/local/openssl && make && make install && ldconfig When I do a dig against a server running 9.18 I get the following: dig @dns1.itctel.com view.bankeasy.com ; <<>> DiG 9.16.42 <<>> @dns1.itctel.com view.bankeasy.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46906 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: d8ce8161641fbfdf0100653bcf9ad1fff99d24914278 (good) ;; QUESTION SECTION: ;view.bankeasy.com. IN A ;; Query time: 8 msec ;; SERVER: 2607:d600:1000:330:75:102:161:227#53(2607:d600:1000:330:75:102:161:227) ;; WHEN: Fri Oct 27 09:56:26 CDT 2023 ;; MSG SIZE rcvd: 74 The same command resolves just fine when I run it against 9.16 dig @dns2.itctel.com view.bankeasy.com ; <<>> DiG 9.16.42 <<>> @dns2.itctel.com view.bankeasy.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30969 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: b0ec30c4ddfeacd30100653bcf9ff140c249344242e0 (good) ;; QUESTION SECTION: ;view.bankeasy.com. IN A ;; ANSWER SECTION: view.bankeasy.com. 3133 IN CNAME view.gtm.bankeasy.com. view.gtm.bankeasy.com. 300 IN A 96.2.250.200 ;; Query time: 11 msec ;; SERVER: 2607:d600:9000:330:75:102:160:227#53(2607:d600:9000:330:75:102:160:227) ;; WHEN: Fri Oct 27 09:56:31 CDT 2023 ;; MSG SIZE rcvd: 125 [root@brkr-dns2 bind-9.18.12]# Michael Martinell Network/Broadband Technician Interstate Telecommunications Coop., Inc. 312 4th Street West * Clear Lake, SD 57226 Phone: (605) 874-8313 michael.martin...@itccoop.com www.itc-web.com -- 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: 9.18 BIND not iterated over all authoritative nameservers
Thanks to all who responded. Putting qname-minimization disabled; in named.conf resolves the issue in my testing. I did try specifying relaxed (which appears to be the default), but that didn’t work either. I agree it would be great if the far ends would make sure what they publish is correct, but it will take a large company to push them to do so. Michael Martinell Network/Broadband Technician Interstate Telecommunications Coop., Inc. From: bind-users On Behalf Of Paul Stead Sent: Saturday, October 28, 2023 11:35 AM Cc: bind-users@lists.isc.org Subject: Re: 9.18 BIND not iterated over all authoritative nameservers I wasn't On Sat, Oct 28, 2023, 5:23 PM Ondřej Surý mailto:ond...@isc.org>> wrote: Please don’t use Postel’s Law as excuse for implementations that break standards: https://datatracker.ietf.org/doc/html/rfc9413<https://datatracker.ietf.org/doc/html/rfc9413> -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. On 28. 10. 2023, at 17:50, Paul Stead mailto:paul.st...@gmail.com>> wrote: As a previous ISP admin I too have come across similar situations and frustrations. I can only say that Google and Cloudflare seem to follow Postel's Law moreso than BIND. I agree this perpetuates bad practices but end users aren't interested in technical reasoning, especially when "it works everywhere else, you must be broken" Paul On Sat, Oct 28, 2023, 3:56 PM Rick Frey mailto:grib...@gmail.com>> wrote: As Mark mentions, the NS records gtm.bankeasy.com<http://gtm.bankeasy.com> need to be corrected and failure is not due to lack of iterating through all auth nameservers (all of the auth nameservers have the bad NS record anyway). Not sure how many other domains you are running into similar problem, but you could disable qname-minimization in 9.18 to mimic previous behavior of 9.16 if that number is large. I believe qname-minimization is a global directive so it would remove privacy benefits of QNAME minimization for all recursive queries from your nameserver. As DNS admin of another ISP, I sympathize dealing with failures caused by non-compliant authoritative nameservers. These non-compliant auth nameservers can have little motivation to fix, especially when other large ISPs or public resolvers (looking at you Google and Cloudflare) don’t enforce DNS standards. Many non-compliant nameservers/records would be cleaned up if public/centralized DNS providers such as Google/Cloudflare would enforce since it would inflict those failures on a much larger user base. - Rick On Oct 27, 2023, at 6:31 PM, Mark Andrews mailto:ma...@isc.org>> wrote: Named now uses NS lookups to perform QNAME minimisation. If one puts garbage in the NS records then they should expect lookups to fail. The NS records on both sides of a zone cut are supposed to be IDENTICAL. This is not a new requirement. It has been this way since the very beginning. The bank needs to fix what they publish. Mark On 28 Oct 2023, at 02:36, Michael Martinell via bind-users mailto:bind-users@lists.isc.org>> wrote: Hello, At this point I am hoping that somebody might have a workaround so that we can exclude domains from this behavior if they are broken on the far end. Does anybody have a workaround for this? We are a small ISP and run BIND compiled from source. We currently run 9.16.x Every time we try to move forward with 9.18 customers start to complain that they are unable to reach certain websites. This includes banks, universities, and other organizations. I understand the goal is to get all DNS to RFC 6891, but from a practical standpoint, this isn’t working for customers, so we are prevented from upgrading either. Related website: https://gitlab.isc.org/isc-projects/bind9/-/issues/3152<https://gitlab.isc.org/isc-projects/bind9/-/issues/3152> Our source code compile options: ./configure --with-gnu-ld --with-libxml2 --with-json-c --with-openssl=/usr/local/openssl && make && make install && ldconfig Interstate Telecommunications Coop., Inc. 312 4th Street West • Clear Lake, SD 57226 Phone: (605) 874-8313 michael.martin...@itccoop.com<mailto:michael.martin...@itccoop.com> www.itc-web.com<http://www.itc-web.com> -- Visit https://lists.isc.org/mailman/listinfo/bind-users<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/<https://www.isc.org/contact/> for more information. bind-users mailing list bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> https://lists.isc.org/mailman/listinfo/bind-users<https://lists.isc.org/mailman/listinfo/bind-users> -- Visit https://lists.isc.org/mailman/lis
dnnsec ipv6 reverse zone configuration
Hello, hoping somebody might have some insight into the errors I am seeing on
ipv6 dnssec records.
I am just starting to roll out dnssec on my reverse zones and have started with
IPv6 on the record that contains just our ns2.itctel.com and dns2.itctel.com
records. Our IPv4 forward zones are working fine and without error. This is our
first reverse zone. I am currently using the same policy as the forward zone,
but if necessary can create a separate policy for the reverse zone.
When I query
https://dnssec-debugger.verisignlabs.com/3.0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa
it looks like the 0.0.6.d.7.0.6.2.ip6.arpa section is having issues with
DNSKEY; however, the sections both above and below that section successfully
returns green checkmarks.
Do I need to separate out all of the smaller sections below into their own
zones? My full zone of 3.0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa is successful, but
the smaller portions are failing.
I get these successful messages:
Found 1 DS records for 0.0.6.d.7.0.6.2.ip6.arpa in the
0.6.2.ip6.arpa zone
DS=3283/SHA-256 has algorithm ECDSAP256SHA256
Found 1 RRSIGs over DS RRset
RRSIG=42693 and DNSKEY=42693 verifies the DS RRset
Then I see errors at the dnssec-debugger: (in the 0.0.6.d.7.0.6.2.ip6.arpa
section)
ns2.itctel.com returns REFUSED for 0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY
ns1.itctel.com returns REFUSED for 0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY
Failed to get DNSKEY RR set for zone 0.0.6.d.7.0.6.2.ip6.arpa
ns2.itctel.com returns REFUSED for 9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY
ns1.itctel.com returns REFUSED for 9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY
ns1.itctel.com returns REFUSED for 0.9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY
ns2.itctel.com returns REFUSED for 0.9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY
ns1.itctel.com returns REFUSED for 0.0.9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY
ns2.itctel.com returns REFUSED for 0.0.9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY
ns2.itctel.com returns REFUSED for 0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY
ns1.itctel.com returns REFUSED for 0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY
ns2.itctel.com returns REFUSED for 0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY
ns1.itctel.com returns REFUSED for 0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY
No DS records found for 3.0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa in the
0.0.6.d.7.0.6.2.ip6.arpa zone
Then the next section is a success again
Found 2 DNSKEY records for 3.0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa
Found 1 RRSIGs over DNSKEY RRset
DIG successfully returns without error
dig +dnssec 3.0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa DNSKEY @ns1.itctel.com
; <<>> DiG 9.11.9 <<>> +dnssec 3.0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa DNSKEY
@ns1.itctel.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33233
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 256f2863771866840100671f8f58815467759394f32c (good)
;; QUESTION SECTION:
;3.0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa. IN DNSKEY
;; ANSWER SECTION:
3.0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa. 3600 IN DNSKEY 256 3 13
BCg6PxA7axei2rIO9i7nKcmLR+atxJrNILLYOhxqQjJPHNgB66Llms9G
VsHVouZNj2F9FN8r/1yqeGIPaTwwJA==
3.0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa. 3600 IN DNSKEY 257 3 13
HuSoT3TZwpQphIZOauDjS72tSNZPLMWho9IhgB05xMiRgtTeMi87n+el
2ZAKkwDMkPvdWMIWEdCp1Vh48CyhwQ==
3.0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa. 3600 IN RRSIG DNSKEY 13 16 3600
20241107184719 20241024174719 14995 3.0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa.
0MCAIJnPjB/wvq47z7xcY5xejdNOGIRWFL+TYo+kqK1tU1DcUboUZc3b
Bkyeaq5g64DiBgJzHwVZuDUtR/l24A==
;; Query time: 2 msec
;; SERVER: 75.102.161.234#53(75.102.161.234)
;; WHEN: Mon Oct 28 08:19:20 CDT 2024
;; MSG SIZE rcvd: 385
I did register the DS record for this block of IPs that matches the zone with
ARIN last week.
Network solutions still does not support glue records for nameservers, so
I am unable to add those.
My configuration is very simple and pretty much follows the bind documentation.
Running BIND 9.18.30
DNSSEC Policy
dnssec-policy "itc-no-rotate" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
Zome record for this zone
zone "3.0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa" in {
type master;
file "reverse/2607.d600.9000.300.rev";
dnssec-policy itc-no-rotate;
inline-signing yes;
};
Any idea on what I need to do to resolve this issue?
Michael Martinell
Network/Broadband Technician
Interstate Telecommunications Coop., Inc.
312 4th Street West * Clear Lake, SD 57226
Phone: (605) 874-8313
michael.martin...@itccoop.com
www.itc-web.com
--
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/contac
RE: dnnsec ipv6 reverse zone configuration
Thanks! This did the trick for me, once I built the missing zone and got the DS records in the correct spots everything is now reporting green. Michael Martinell Network/Broadband Technician Interstate Telecommunications Coop., Inc.-Original Message- From: Mark Andrews Sent: Wednesday, October 30, 2024 3:26 PM To: Michael Martinell Cc: bind-users Subject: Re: dnnsec ipv6 reverse zone configuration Create the zone 0.0.6.d.7.0.6.2.ip6.arpa and delegate 3.0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa from it. The ARIN servers delegate 0.0.6.d.7.0.6.2.ip6.arpa to ns1.itctel.com and ns2.itctel.com which are not configured to serve it or they have an overly restrictive ACL (it should be open to the world). 0.0.6.d.7.0.6.2.ip6.arpa. 86400 IN NS ns2.itctel.com. 0.0.6.d.7.0.6.2.ip6.arpa. 86400 IN NS ns1.itctel.com. 0.0.6.d.7.0.6.2.ip6.arpa. 86400 IN DS 3283 13 2 2FA5DF2E9D49B5707921FEA0C1506988F0221E91E654D684149A2F47 4AD561ED 0.0.6.d.7.0.6.2.ip6.arpa. 86400 IN RRSIG DS 8 10 86400 20241113152812 20241030142812 42693 0.6.2.ip6.arpa. HmHen78HWXDa/8lSt1ju+ZXcIdfd3ChKjjb2z6Sxs8PYmUceEp//RndH AOfy6Arx88a3fypq83oh3/V1NhPwpvrByIgcYus+wESqe92ZRumAxDLb PscAOECw52MgOY/wWR/U4LOk7X34CuPZnxiSq1Y+3Rvjthl7gqb2UkFB 7y8= ;; Received 333 bytes from 192.82.134.30#53(y.arin.net) in 228 ms You will need to update the DS record for 0.0.6.d.7.0.6.2.ip6.arpa at ARIN if you need to recreate 0.0.6.d.7.0.6.2.ip6.arpa. $ORIGIN 0.0.6.d.7.0.6.2.ip6.arpa. @SOAns1.itctel.com. hostmaster.itctel.com. 2022012114 3600 3600 604800 3600 @NSns1.itctel.com. @NSns2.itctel.com. @DNSKEY… @DNSKEY… ; securely delegate 3.0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa 3.0.0.0.0.9NSns1.itctel.com. 3.0.0.0.0.9NSns2.itctel.com. 3.0.0.0.0.9DS14995 13 2 A456A61C85301154FDE0A9465100810BACF91D08C91D7C5FAF3C813EB27638C9 With DNSSEC or QNAME minimisation you cannot miss intermediate zones. Mark > On 31 Oct 2024, at 00:31, Michael Martinell via bind-users > wrote: > > Hello, hoping somebody might have some insight into the errors I am seeing on > ipv6 dnssec records. > I am just starting to roll out dnssec on my reverse zones and have started > with IPv6 on the record that contains just our ns2.itctel.com and > dns2.itctel.com records. Our IPv4 forward zones are working fine and without > error. This is our first reverse zone. I am currently using the same policy > as the forward zone, but if necessary can create a separate policy for the > reverse zone. > When I query > https://dnssec-debugger.verisignlabs.com/3.0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa > it looks like the 0.0.6.d.7.0.6.2.ip6.arpa section is having issues with > DNSKEY; however, the sections both above and below that section successfully > returns green checkmarks. > Do I need to separate out all of the smaller sections below into their own > zones? My full zone of 3.0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa is successful, > but the smaller portions are failing. > I get these successful messages: > Found 1 DS records for 0.0.6.d.7.0.6.2.ip6.arpa in the > 0.6.2.ip6.arpa zone > DS=3283/SHA-256 has algorithm ECDSAP256SHA256 > Found 1 RRSIGs over DS RRset > RRSIG=42693 and DNSKEY=42693 verifies the DS RRset > Then I see errors at the dnssec-debugger: (in the > 0.0.6.d.7.0.6.2.ip6.arpa section) ns2.itctel.com returns REFUSED for > http://0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY > n=0.0.6.d.7.0.6.2.ip6.arpa ns1.itctel.com returns REFUSED for > http://0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY > n=0.0.6.d.7.0.6.2.ip6.arpa Failed to get DNSKEY RR set for zone > 0.0.6.d.7.0.6.2.ip6.arpa ns2.itctel.com returns REFUSED for > http://9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY > n=9.0.0.6.d.7.0.6.2.ip6.arpa ns1.itctel.com returns REFUSED for > http://9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY > n=9.0.0.6.d.7.0.6.2.ip6.arpa ns1.itctel.com returns REFUSED for > http://0.9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY > n=0.9.0.0.6.d.7.0.6.2.ip6.arpa ns2.itctel.com returns REFUSED for > http://0.9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY > n=0.9.0.0.6.d.7.0.6.2.ip6.arpa ns1.itctel.com returns REFUSED for > http://0.0.9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY > n=0.0.9.0.0.6.d.7.0.6.2.ip6.arpa ns2.itctel.com returns REFUSED for > http://0.0.9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY > n=0.0.9.0.0.6.d.7.0.6.2.ip6.arpa ns2.itctel.com returns REFUSED for > http://0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY > n=0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa > ns1.itctel.com returns REFUSED for > http://0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY > n=0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa > ns2.itctel.com returns REFUSED for > http://0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY > n=0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa > ns1.itctel.com returns REFUSED for > http://0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa/DNSKEY > n=0.0.0.0.9.0.0.6.d.7.0.6.2.ip6.arpa > No DS records found for 3.0.0.0.0.9.0.0.
