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

[Shumon Huque]

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.       6694    IN      NSEC    acem.a.se. SRV RRSIG NSEC

Shumon.

On Tue, Jan 11, 2022 at 10:58 AM 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20220111/c397e094/attachment.html>