[dns-operations] DNSSec validation issue for .se (missing denial of existence for *.se)

[Ulrich Wisser]

This is of course very interesting for us (at .se).
I tried this with all our dns servers and all give the same answer.
But I tend to agree that a proof for the non existence of the wildcard should be there.

I am thinking of a domain setup as:

*.example.com <http://example.com/>. TXT “wildcard”
0.example.com <http://0.example.com/>. TXT “zero”
test.a.example.com. TXT “test.a”

What answer should “dig +dnssec a.example.com <http://a.example.com/> txt” give?

I would say “wildcard”. And if that is the case, shouldn’t it then send an extra sec in case there is no wildcard record?

/Ulrich


> On 11 Jan 2022, at 21:34, Mark Andrews <marka at isc.org> wrote:
> 
> 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 <shreyas at technitium.com> 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 <http://acem.a.se/>" which is a sub domain for the qname "a.se <http://a.se/>", its sufficient proof that the "a.se <http://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 <hannes at mehnert.org <mailto:hannes at mehnert.org>> 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://github.com/mirage/ocaml-dns> // https://mirageos.org <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 <http://a.se/> results in the 
>> following:
>> 
>> $ dig +dnssec a.se <http://a.se/>
>> 
>> se.                     5363    IN      SOA catcher-in-the-rye.nic.se <http://catcher-in-the-rye.nic.se/>. 
>> registry-default.nic.se <http://registry-default.nic.se/>. 2022010921 1800 1800 864000 7200
>> se.                     5363    IN      RRSIG   SOA 8 1 172800 
>> 20220122054639 20220109191050 30015 se.  [...]
>> _nicname._tcp.se <http://tcp.se/>.       6694    IN      NSEC    acem.a.se <http://acem.a.se/>. SRV RRSIG NSEC
>> _nicname._tcp.se <http://tcp.se/>.       6694    IN      RRSIG   NSEC 8 3 7200 
>> 20220121191006 20220108001053 30015 se. [...]
>> 
>> Which provides a non-existence proof for everything between 
>> _nicname._tcp.se <http://tcp.se/> and acem.a.se <http://acem.a.se/>, but nothing for *.se (which according to 
>> the order of canonical domain names, is before _nicname._tcp.se <http://tcp.se/> -- even 
>> before 0.se <http://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.                     4353    IN      NSEC    0.se <http://0.se/>. NS SOA TXT RRSIG 
>> NSEC DNSKEY
>> se.                     4353    IN      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 at lists.dns-oarc.net <mailto:dns-operations at lists.dns-oarc.net>
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations <https://lists.dns-oarc.net/mailman/listinfo/dns-operations>
>> _______________________________________________
>> dns-operations mailing list
>> dns-operations at lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20220117/efafd2f6/attachment.html>