[dns-operations] DNSSec validation issue for .se (missing denial of existence for *.se)
Mats Dufberg
mats.dufberg at internetstiftelsen.se
Mon Jan 17 15:20:50 UTC 2022
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<http://example.com>. TXT “wildcard”
0.example.com<http://0.example.com>. TXT “zero”
test.a.example.com<http://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<mailto: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<mailto: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://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
_______________________________________________
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
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20220117/3da8311d/attachment.html>
More information about the dns-operations
mailing list