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

Mon Jan 17 21:49:31 UTC 2022

For a NXDOMAIN response you need to prove that the QNAME does not exist and there is no matching wildcard.  This will take 1 or 2 NSEC records or 1, 2, or 3 NSEC3 records.

For a NODATA response you need to prove the QNAME exists and there are no records of the desired type.  This takes 1 NSEC record or 1 NSEC3 record. In a NSEC3 signed there there is an NSEC3 record with an empty type map for every empty non terminal node (ENT) in a correctly signed zone. In a NSEC signed zone the ENT proofs, if any, are found by looking at the relationships between two names in the covering NSEC record.

		left.name.common NSEC right.ent.ent.ent.ent.ent.common

Mark

> On 18 Jan 2022, at 02:20, Mats Dufberg via dns-operations <dns-operations at dns-oarc.net> wrote:
> 
> 
> From: Mats Dufberg <mats.dufberg at internetstiftelsen.se>
> Subject: Re: [dns-operations] DNSSec validation issue for .se (missing denial of existence for *.se)
> Date: 18 January 2022 at 02:20:50 AEDT
> To: "dns-operations at dns-oarc.net" <dns-operations at dns-oarc.net>
> 
> 
> The name servers for .se seem to return two NSEC record, one of which covers the wildcard (*), if the response is an NXDOMAIN response, but not if it is a NODATA response for an empty non-terminal label.
>  
> dig +dnssec 000000000.se +mult @x.ns.se
>  
> (...)
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46328
> (...)
> 000000.se.      7200 IN    NSEC 00046.se. NS RRSIG NSEC
> se.             7200 IN    NSEC 0.se. NS SOA TXT RRSIG NSEC DNSKEY
> (...)
>  
> dig +dnssec a.se +mult @x.ns.se
>  
> (...)
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 103
> (...)
> _nicname._tcp.se.     7200 IN    NSEC acem.a.se. SRV RRSIG NSEC
> (...)
>  
>  
> Is this really correct?
>  
>  
>  
> Mats
>  
> -- 
> ---
> Mats Dufberg
> mats.dufberg at internetstiftelsen.se
> Technical Expert
> Internetstiftelsen (The Swedish Internet Foundation)
> Mobile: +46 73 065 3899
> https://internetstiftelsen.se/
>  
>  
> From: Ulrich Wisser <ulrich at wisser.se>
> Date: Monday, 17 January 2022 at 15:01
> To: Mark Andrews <marka at isc.org>
> Cc: Shreyas Zare <shreyas at technitium.com>, Greg Choules via dns-operations <dns-operations at dns-oarc.net>
> Subject: Re: [dns-operations] DNSSec validation issue for .se (missing denial of existence for *.se)
>  
> 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. TXT “wildcard”
> 0.example.com. TXT “zero”
> test.a.example.com. TXT “test.a”
>  
> What answer should “dig +dnssec 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" 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 <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://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.                     5363    IN      SOA catcher-in-the-rye.nic.se. 
> registry-default.nic.se. 2022010921 1800 1800 864000 7200
> se.                     5363    IN      RRSIG   SOA 8 1 172800 
> 20220122054639 20220109191050 30015 se.  [...]
> _nicname._tcp.se.       6694    IN      NSEC    acem.a.se. SRV RRSIG NSEC
> _nicname._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 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.                     4353    IN      NSEC    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
> 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
>  
> 
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org