--- Begin Message ---
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
[email protected]
Technical Expert
Internetstiftelsen (The Swedish Internet Foundation)
Mobile: +46 73 065 3899
https://internetstiftelsen.se/
From: Ulrich Wisser <[email protected]>
Date: Monday, 17 January 2022 at 15:01
To: Mark Andrews <[email protected]>
Cc: Shreyas Zare <[email protected]>, Greg Choules via dns-operations
<[email protected]>
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 <[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
_______________________________________________
dns-operations mailing list
[email protected]<mailto:[email protected]>
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
_______________________________________________
dns-operations mailing list
[email protected]<mailto:[email protected]>
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
--- End Message ---
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
