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

[Shumon Huque]

On Mon, Jan 17, 2022 at 9:04 AM Ulrich Wisser via dns-operations <
dns-operations at dns-oarc.net> wrote:

>
> ---------- Forwarded message ----------
> From: Ulrich Wisser <ulrich at wisser.se>
> 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>
> Bcc:
> Date: Mon, 17 Jan 2022 15:01:36 +0100
> 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?
>

Actually, no Ulrich, a query for "a.example.com" in your example will not
match the wildcard, since the node "a.example.com"
positively exists (as an empty non-terminal with a descendant node,
test.a.example.com, that has data). The DNS name
matching algorithm is label by label inspection from the top down (see RFC
1034, Section 4.3.2).

          c. If at some label, a match is impossible (i.e., the
            corresponding label does not exist), look to see if a
            the "*" label exists.

(At this stage in your example, a match is found)

Hence, no wildcard non-existence proof is needed. Those are needed only for
NXDOMAIN responses, where we you
have to additionally prove that although the name did not explicitly exist,
a response for it could not have been synthesized
by a wildcard.

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