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 <ma...@isc.org> Sent: Wednesday, October 30, 2024 3:26 PM To: Michael Martinell <michael.martin...@itccoop.com> Cc: bind-users <bind-users@lists.isc.org> 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 > <bind-users@lists.isc.org> 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.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: > 256f28637718668401000000671f8f58815467759394f32c (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 AAAA 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 > n=lists.isc.org 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 > n=lists.isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- 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
