On Tue, Oct 26, 2021 at 10:21:29PM -0700, Joey Deng wrote:
> If the question name appears in-between the current owner name and the
> next owner name of the NSEC record, which means that there is no exact
> name matching: We should prove that no possible wildcard RRset exists
> that could have been used to generate a positive response.
This is accomplished via a 'closest encloser' proof, in the case of NSEC
this takes up to two records:
1. An NSEC record that excludes the shortest non-existent ancestor
of the qname. The closest encloser is then the longest domain
equal to or containing both endpoints of the NSEC pair.
2. An NSEC record showing non-existence of a wildcard below that
closest encloser (which may be the same as (1) in some cases.
> What are possible wildcard RRsets for a given name?
The label count of the wildcard response must then match the number of
labels in the closest encloser. That is, the "*" domain would have to
have been an immediate child of the closest encloser (1).
> My understanding about possible wildcard RRsets for a given name are
> all the possible sources of synthesis. For example, the possible
> wildcard RRsets that can be used to answer question wwww.ietf.org
> AAAA are:
>
> *.ietf.org
That would be the only one, because 'ietf.org' is known to exist.
[ There's presently no "*.ietf.org" wildcard domain. ]
> *.org
No, this lies above the closest encloser.
> * (but I think root can never be a wildcard, so this is impossible)
No, this lies above the closest encloser. A "*" node in the root zone
is technically possible, but none is likely to ever be published. If it
were to exist it would become the source of truth for all invalid and
typoed TLDs, which would be rather suboptimal.
> Is my understanding correct?
No.
> For example, if I send a DNS query for wwww.ietf.org with DO/CD bit
> set, there will be two NSEC records returned:
>
> ```
> $ dig "wwww.ietf.org" AAAA +dnssec +cdflag +tcp @1.1.1.1
>
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34013
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
This is an NXDOMAIN answer, not a NODATA or wildcard sythesised answer.
> wwwtest.ietf.org. 1800 IN NSEC xml2rfc.ietf.org. CNAME RRSIG
> NSEC
This record proves the non-existence of the qname, and also "ietf.org"
as the closest encloser.
> ietf.org. 1800 IN NSEC _dmarc.ietf.org. A NS SOA MX
> TXT AAAA RRSIG NSEC DNSKEY SPF
This record proves that "*.ietf.org" does not exist, and we're done.
> wwwtest.ietf.org. -> xml2rfc.ietf.org. tells us that the exact name
> match for wwww.ietf.org does not exist, since it appears in-between
> the two names.
Correct.
> Therefore, the remaining ietf.org. -> _dmarc.ietf.org. NSEC should be
> used to prove that “no possible wildcard RRset exists that could have
> been used to generate a positive response” for the name wwww.ietf.org.
Which it does, since the only potential wildcard is '*.ietf.org', given
"ietf.org" as the closest encloser. "*.ietf.org" would be between these
if it existed.
> How can ietf.org. -> _dmarc.ietf.org NSEC be used to prove that there
> is no wildcard record for the name wwww.ietf.org?
By virtue of the fact that wildcards never apply at or below sibling
names that exist. If foo.example.com exists, then wildcards at
"*.example.com", "*.com", or "*" can never apply to any query at or
below "foo.bar.example.com". The "*.example.com" wildcard can only
apply to names ending in a non-existent sibling of the wildcard
label (<missing>.example.com).
> Do we need to prove that all the possible sources of synthesis for
> wwww.ietf.org appear in-between ietf.org. and _dmarc.ietf.org?
There is only ever one such possible source. The "*" label under
the closest encloser.
> Or do we only need to prove that *.ietf.org appears in-between
> ietf.org. and _dmarc.ietf.org?
Since there's only one possible source, this is the one to
disprove.
> If so why do we choose *.ietf.org instead of *.org or *?
See above.
--
VIktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
