Re: [dns-operations] DNSSec validation issue for .se (missing denial of existence for *.se)
NSEC prove there are no names with records between the two names. Note the qualifier “with records”. Clarifying this was one of the early corrections to the DNSSEC specification. -- Mark Andrews > On 12 Jan 2022, at 03:31, Shreyas Zare wrote: > > > Hi, > > I was implementing DNSSEC just last month and came across this same issue and > didn't find any specific documentation on it. > > However, I came to the conclusion that since the NSEC record that was > returned has the next domain name "acem.a.se" which is a sub domain for the > qname "a.se", its sufficient proof that the "a.se" name is NODATA and so no > wildcard proof is required here. > > Regards, > Shreyas Zare > Technitium > >> On Tue, Jan 11, 2022, 21:26 Hannes Mehnert wrote: >> Hi DNS operators, >> >> since this is my first mail here, I first would like to thank you all >> for the constructive discussions and technical expertise. I'm developing >> a DNS suite in OCaml, a statically typed functional programming language >> [see https://github.com/mirage/ocaml-dns // https://mirageos.org if >> interested], and have learned a lot from lurking on this list. My >> current work item is a recursive resolver. >> >> When I just implemented the denial of existence for DNSSec (with NSEC), >> I stumbled upon the TLD .se that uses NSEC. I mailed earlier to >> registry-default at nic dot se (the hostmaster in the SOA of .se), but >> didn't get a reply. >> >> Of course, I may be wrong with my analysis, if this is the case please >> help me to understand how this should work. >> >> I'm wondering how other validators (public resolvers) deal with the >> following issue, which is a missing denial of existence for *.se: So, a >> request for resource record type A, domain name a.se results in the >> following: >> >> $ dig +dnssec a.se >> >> se. 5363IN SOA catcher-in-the-rye.nic.se. >> registry-default.nic.se. 2022010921 1800 1800 864000 7200 >> se. 5363IN RRSIG SOA 8 1 172800 >> 20220122054639 20220109191050 30015 se. [...] >> _nicname._tcp.se. 6694IN NSECacem.a.se. SRV RRSIG NSEC >> _nicname._tcp.se. 6694IN RRSIG NSEC 8 3 7200 >> 20220121191006 20220108001053 30015 se. [...] >> >> Which provides a non-existence proof for everything between >> _nicname._tcp.se and acem.a.se, but nothing for *.se (which according to >> the order of canonical domain names, is before _nicname._tcp.se -- even >> before 0.se that seems to be the first registered domain name). >> >> The NSEC record missing from the reply above is the following NSEC and >> RRSIG ($ dig +dnssec ns \!.se). >> >> se. 4353IN NSEC0.se. NS SOA TXT RRSIG >> NSEC DNSKEY >> se. 4353IN RRSIG NSEC 8 1 7200 >> 20220121132017 20220108061050 30015 se. >> jzWI5l5Sxyb2sOLzCWNX06nwmCtZuFdS3PvmivnyOPVZ3cw+blBXNYwN >> cFCYFdMC7R31W0ABBuT587mAm7Ae5NJX2GnXGcNgaVcD9VhKWAjJHpqf >> +NJcLOF9771m/BKPC7dKTwt/zVdKJSwFjaYTr0streS9OMCnJXbiWaQc >> CMDmzko2WiWdBNDAbZ8H/OfKymYjgJz1hZynMdl5LyWcGgxlOksuLKSv >> 4xg4Ey07r4ZCy5XTQwfHG74qWa+61BVjfP3KEEEB42B0rZX8lT15B9MS >> Cg9RmBObNC5FYjXGkbeik6iXrdOGzUUURHay+th9SJ4BGIFIV8fyyDTd oxOc5w== >> >> >> Thank you for reading, >> >> Hannes Mehnert >> ___ >> dns-operations mailing list >> dns-operations@lists.dns-oarc.net >> https://lists.dns-oarc.net/mailman/listinfo/dns-operations > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Trouble resolving .by TLD due to circular dependency?
It appears that Sascha E. Pollok via dns-operations said: >-=-=-=-=-=- > >Hello nice people, > >for a few days I have worked on an issue we see with our Bind resolvers of >different >versions regarding resolving addresses under .by. I assume it is not Bind's >fault at all >but the result of a circular dependency in .by after a change of the Auth NS >beginning of >January but let me explain what I see. ... You are correct, they have a NS dependency loop that will cause all sorts of problems. As you note the results can be very inconsistent depending on the TTL of the glue records and how different DNS software handles the expiring glue. >by. 130511 IN NS dns1.tld.becloudby.com. >becloudby.com. 172800 IN NS u1.hoster.by. >becloudby.com. 172800 IN NS u2.hoster.by. >Does this analysis seem correct and are there maybe any .BY ccTLD people on >this list to >take a look at this? I have worked on this together with Anand Buddhdev so I >want to thank >him for working with me. Always a pleasure. The solution, of course, is "don't do that." A simple fix would be to move the NS for becloudby.com to a name under .com. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNSSec validation issue for .se (missing denial of existence for *.se)
Hi, I was implementing DNSSEC just last month and came across this same issue and didn't find any specific documentation on it. However, I came to the conclusion that since the NSEC record that was returned has the next domain name "acem.a.se" which is a sub domain for the qname "a.se", its sufficient proof that the "a.se" name is NODATA and so no wildcard proof is required here. Regards, Shreyas Zare Technitium On Tue, Jan 11, 2022, 21:26 Hannes Mehnert wrote: > Hi DNS operators, > > since this is my first mail here, I first would like to thank you all > for the constructive discussions and technical expertise. I'm developing > a DNS suite in OCaml, a statically typed functional programming language > [see https://github.com/mirage/ocaml-dns // https://mirageos.org if > interested], and have learned a lot from lurking on this list. My > current work item is a recursive resolver. > > When I just implemented the denial of existence for DNSSec (with NSEC), > I stumbled upon the TLD .se that uses NSEC. I mailed earlier to > registry-default at nic dot se (the hostmaster in the SOA of .se), but > didn't get a reply. > > Of course, I may be wrong with my analysis, if this is the case please > help me to understand how this should work. > > I'm wondering how other validators (public resolvers) deal with the > following issue, which is a missing denial of existence for *.se: So, a > request for resource record type A, domain name a.se results in the > following: > > $ dig +dnssec a.se > > se. 5363IN SOA catcher-in-the-rye.nic.se. > registry-default.nic.se. 2022010921 1800 1800 864000 7200 > se. 5363IN RRSIG SOA 8 1 172800 > 20220122054639 20220109191050 30015 se. [...] > _nicname._tcp.se. 6694IN NSECacem.a.se. SRV RRSIG NSEC > _nicname._tcp.se. 6694IN RRSIG NSEC 8 3 7200 > 20220121191006 20220108001053 30015 se. [...] > > Which provides a non-existence proof for everything between > _nicname._tcp.se and acem.a.se, but nothing for *.se (which according to > the order of canonical domain names, is before _nicname._tcp.se -- even > before 0.se that seems to be the first registered domain name). > > The NSEC record missing from the reply above is the following NSEC and > RRSIG ($ dig +dnssec ns \!.se). > > se. 4353IN NSEC0.se. NS SOA TXT RRSIG > NSEC DNSKEY > se. 4353IN RRSIG NSEC 8 1 7200 > 20220121132017 20220108061050 30015 se. > jzWI5l5Sxyb2sOLzCWNX06nwmCtZuFdS3PvmivnyOPVZ3cw+blBXNYwN > cFCYFdMC7R31W0ABBuT587mAm7Ae5NJX2GnXGcNgaVcD9VhKWAjJHpqf > +NJcLOF9771m/BKPC7dKTwt/zVdKJSwFjaYTr0streS9OMCnJXbiWaQc > CMDmzko2WiWdBNDAbZ8H/OfKymYjgJz1hZynMdl5LyWcGgxlOksuLKSv > 4xg4Ey07r4ZCy5XTQwfHG74qWa+61BVjfP3KEEEB42B0rZX8lT15B9MS > Cg9RmBObNC5FYjXGkbeik6iXrdOGzUUURHay+th9SJ4BGIFIV8fyyDTd oxOc5w== > > > Thank you for reading, > > Hannes Mehnert > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNSSec validation issue for .se (missing denial of existence for *.se)
Hannes, This is a NODATA response for an empty non-terminal, so no wildcard non-existence proof is needed. The following NSEC record demonstrates that "a.se" is an empty non-terminal: _nicname._tcp.se. 6694IN NSECacem.a.se. SRV RRSIG NSEC Shumon. On Tue, Jan 11, 2022 at 10:58 AM Hannes Mehnert wrote: > Hi DNS operators, > > since this is my first mail here, I first would like to thank you all > for the constructive discussions and technical expertise. I'm developing > a DNS suite in OCaml, a statically typed functional programming language > [see https://github.com/mirage/ocaml-dns // https://mirageos.org if > interested], and have learned a lot from lurking on this list. My > current work item is a recursive resolver. > > When I just implemented the denial of existence for DNSSec (with NSEC), > I stumbled upon the TLD .se that uses NSEC. I mailed earlier to > registry-default at nic dot se (the hostmaster in the SOA of .se), but > didn't get a reply. > > Of course, I may be wrong with my analysis, if this is the case please > help me to understand how this should work. > > I'm wondering how other validators (public resolvers) deal with the > following issue, which is a missing denial of existence for *.se: So, a > request for resource record type A, domain name a.se results in the > following: > > $ dig +dnssec a.se > > se. 5363IN SOA catcher-in-the-rye.nic.se. > registry-default.nic.se. 2022010921 1800 1800 864000 7200 > se. 5363IN RRSIG SOA 8 1 172800 > 20220122054639 20220109191050 30015 se. [...] > _nicname._tcp.se. 6694IN NSECacem.a.se. SRV RRSIG NSEC > _nicname._tcp.se. 6694IN RRSIG NSEC 8 3 7200 > 20220121191006 20220108001053 30015 se. [...] > > Which provides a non-existence proof for everything between > _nicname._tcp.se and acem.a.se, but nothing for *.se (which according to > the order of canonical domain names, is before _nicname._tcp.se -- even > before 0.se that seems to be the first registered domain name). > > The NSEC record missing from the reply above is the following NSEC and > RRSIG ($ dig +dnssec ns \!.se). > > se. 4353IN NSEC0.se. NS SOA TXT RRSIG > NSEC DNSKEY > se. 4353IN RRSIG NSEC 8 1 7200 > 20220121132017 20220108061050 30015 se. > jzWI5l5Sxyb2sOLzCWNX06nwmCtZuFdS3PvmivnyOPVZ3cw+blBXNYwN > cFCYFdMC7R31W0ABBuT587mAm7Ae5NJX2GnXGcNgaVcD9VhKWAjJHpqf > +NJcLOF9771m/BKPC7dKTwt/zVdKJSwFjaYTr0streS9OMCnJXbiWaQc > CMDmzko2WiWdBNDAbZ8H/OfKymYjgJz1hZynMdl5LyWcGgxlOksuLKSv > 4xg4Ey07r4ZCy5XTQwfHG74qWa+61BVjfP3KEEEB42B0rZX8lT15B9MS > Cg9RmBObNC5FYjXGkbeik6iXrdOGzUUURHay+th9SJ4BGIFIV8fyyDTd oxOc5w== > > > Thank you for reading, > > Hannes Mehnert > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] DNSSec validation issue for .se (missing denial of existence for *.se)
Hi DNS operators, since this is my first mail here, I first would like to thank you all for the constructive discussions and technical expertise. I'm developing a DNS suite in OCaml, a statically typed functional programming language [see https://github.com/mirage/ocaml-dns // https://mirageos.org if interested], and have learned a lot from lurking on this list. My current work item is a recursive resolver. When I just implemented the denial of existence for DNSSec (with NSEC), I stumbled upon the TLD .se that uses NSEC. I mailed earlier to registry-default at nic dot se (the hostmaster in the SOA of .se), but didn't get a reply. Of course, I may be wrong with my analysis, if this is the case please help me to understand how this should work. I'm wondering how other validators (public resolvers) deal with the following issue, which is a missing denial of existence for *.se: So, a request for resource record type A, domain name a.se results in the following: $ dig +dnssec a.se se. 5363IN SOA catcher-in-the-rye.nic.se. registry-default.nic.se. 2022010921 1800 1800 864000 7200 se. 5363IN RRSIG SOA 8 1 172800 20220122054639 20220109191050 30015 se. [...] _nicname._tcp.se. 6694IN NSECacem.a.se. SRV RRSIG NSEC _nicname._tcp.se. 6694IN RRSIG NSEC 8 3 7200 20220121191006 20220108001053 30015 se. [...] Which provides a non-existence proof for everything between _nicname._tcp.se and acem.a.se, but nothing for *.se (which according to the order of canonical domain names, is before _nicname._tcp.se -- even before 0.se that seems to be the first registered domain name). The NSEC record missing from the reply above is the following NSEC and RRSIG ($ dig +dnssec ns \!.se). se. 4353IN NSEC0.se. NS SOA TXT RRSIG NSEC DNSKEY se. 4353IN RRSIG NSEC 8 1 7200 20220121132017 20220108061050 30015 se. jzWI5l5Sxyb2sOLzCWNX06nwmCtZuFdS3PvmivnyOPVZ3cw+blBXNYwN cFCYFdMC7R31W0ABBuT587mAm7Ae5NJX2GnXGcNgaVcD9VhKWAjJHpqf +NJcLOF9771m/BKPC7dKTwt/zVdKJSwFjaYTr0streS9OMCnJXbiWaQc CMDmzko2WiWdBNDAbZ8H/OfKymYjgJz1hZynMdl5LyWcGgxlOksuLKSv 4xg4Ey07r4ZCy5XTQwfHG74qWa+61BVjfP3KEEEB42B0rZX8lT15B9MS Cg9RmBObNC5FYjXGkbeik6iXrdOGzUUURHay+th9SJ4BGIFIV8fyyDTd oxOc5w== Thank you for reading, Hannes Mehnert OpenPGP_signature Description: OpenPGP digital signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] Trouble resolving .by TLD due to circular dependency?
--- Begin Message --- Hello nice people, for a few days I have worked on an issue we see with our Bind resolvers of different versions regarding resolving addresses under .by. I assume it is not Bind's fault at all but the result of a circular dependency in .by after a change of the Auth NS beginning of January but let me explain what I see. If I start on an empty cache I query the Root NS for .by and get back these Auth NS with originally 2d TTL: by. 130511 IN NS dns1.tld.becloudby.com. by. 130511 IN NS dns3.tld.becloudby.com. by. 130511 IN NS dns2.tld.becloudby.com. by. 130511 IN NS dns5.tld.becloudby.com. by. 130511 IN NS dns4.tld.becloudby.com. They come with Glue A records: dns5.tld.becloudby.com. 172800 IN A 54.180.35.203 dns4.tld.becloudby.com. 172800 IN A 184.72.17.94 dns2.tld.becloudby.com. 172800 IN A 93.125.25.73 dns1.tld.becloudby.com. 172800 IN A 93.125.25.72 dns3.tld.becloudby.com. 172800 IN A 185.98.83.4 The becloudby.com is maintained by two nameservers: ;; QUESTION SECTION: ;dns1.tld.becloudby.com.IN A ;; AUTHORITY SECTION: becloudby.com. 172800 IN NS u1.hoster.by. becloudby.com. 172800 IN NS u2.hoster.by. These machines u1+u2.hoster.by have these IP addresses: ;; QUESTION SECTION: ;u1.hoster.by. IN A ;; AUTHORITY SECTION: hoster.by. 3600IN NS dns2.hoster.by. hoster.by. 3600IN NS dns1.hoster.by. Asking one of them for the IP of u1.hoster.by: ;; QUESTION SECTION: ;u1.hoster.by. IN A ;; ANSWER SECTION: u1.hoster.by. 3600IN A 93.125.30.201 These nameservers are again under the .by TLD. If we query them for the IP of the .by TLD servers, we get a TTL of 600 and an IP: ~$ dig +norec dns1.tld.becloudby.com a @93.125.30.201 # Asking u1.hoster.by for dns1.tld.becloudy.com ;; ANSWER SECTION: dns1.tld.becloudby.com. 600 IN A 93.125.25.72 Which now has a TTL of 600 as opposed to the TTL that the Root NS gave us (2 days). This entry overwrites the previously received Glue A record for dns1.tld.becloudby.com which TTL is now 600. If this cache entry expires, the following steps happen: - We need to ask again u1.hoster.by for this IP address. This works as its TTL is longer (3600s) and we still know that IP. - Once the cache entry of u1.hoster.by expires also, we need to go back to dns1.hoster.by and ask for the IP of u1.hoster.by. This entry is also 3600s and would expire now or later. - Once dns1.hoster.by is expired, we still had the 2 days TTL entry for .by in our cache but without the Glues as the 2d glues have been overwritten by the 600s responses for dns1.tld.becloudby.com (reminder: the Auth NS for .BY). So what we have left in cache are NS entries for the .BY nameservers but without IP addresses which causes a SERVFAIL in Bind. Seems to me like there is a circular dependency between those servers which is not obvious to a lot of users if e.g. their resolvers use the glues parent-centric like Google's 8.8.8.8 NS). Does this analysis seem correct and are there maybe any .BY ccTLD people on this list to take a look at this? I have worked on this together with Anand Buddhdev so I want to thank him for working with me. Always a pleasure. Thank you! Cheers Sascha --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
