Hi, The short answer is "find the closest encloser and determine the source of synthesis.
I can recommend reading RFC 4592 "The Role of Wildcards in the Domain Name System" to understand better how wildcards work. I can recommend reading RFC 7129 "Authenticated Denial of Existence in the DNS" to understand how NSEC proofs work. On 10/27/21 7:21 AM, Joey Deng wrote: > Hi Folks, > > I have a very basic question about NSEC record in DNSSEC validation: > > How does NSEC record(s) prove the Name Error? > > In [RFC 4035 5.4. Authenticated Denial of > Existence](https://datatracker.ietf.org/doc/html/rfc4035#section-5.4 > <https://datatracker.ietf.org/doc/html/rfc4035#section-5.4>), it says: > >> o If the requested RR name matches the owner name of an >> authenticated NSEC RR, then the NSEC RR's type bit map field lists >> all RR types present at that owner name, and a resolver can prove >> that the requested RR type does not exist by checking for the RR >> type in the bit map. If the number of labels in an authenticated >> NSEC RR's owner name equals the Labels field of the covering RRSIG >> RR, then the existence of the NSEC RR proves that wildcard >> expansion could not have been used to match the request. >> >> o If the requested RR name would appear after an authenticated NSEC >> RR's owner name and before the name listed in that NSEC RR's Next >> Domain Name field according to the canonical DNS name order >> defined in [RFC4034 <https://datatracker.ietf.org/doc/html/rfc4034>], >> then no RRsets with the requested name exist >> in the zone. However, it is possible that a wildcard could be >> used to match the requested RR owner name and type, so proving >> that the requested RRset does not exist also requires proving that >> no possible wildcard RRset exists that could have been used to >> generate a positive response. >> > > I can understand the first point, because it is an exact name matching. > However, what makes me feel confused is the second one: > > 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. > > But it does not describe how to prove it, > > What are possible wildcard RRsets for a given name? For a given name, find the closest encloser and calculate the source of synthesis: *.<closest encloser>. The resource records for the source of synthesis in the zone give you the possible wildcard RRsets. > 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 <http://wwwwww.ietf.org> AAAA are: > *.ietf.org <http://ietf.org> > *.org > * (but I think root can never be a wildcard, so this is impossible) > > Is my understanding correct? No, in this example it can only answer for *.ietf.org, as "ietf.org" is the closest encloser for "www.ietf.org". > ———————————————————————————————————————————————————————————————————————— > > For example, if I send a DNS query for wwww.ietf.org > <http://wwwwww.ietf.org> with DO/CD bit set, there will be two NSEC > records returned: ... > > The two returned NSEC records are: > wwwtest.ietf.org <http://wwwtest.ietf.org>. -> xml2rfc.ietf.org > <http://xml2rfc.ietf.org>. > ietf.org <http://ietf.org>. -> _dmarc.ietf.org <http://dmarc.ietf.org>. > > If we follow the steps described by [RFC 4035 5.4. Authenticated Denial > of Existence](https://datatracker.ietf.org/doc/html/rfc4035#section-5.4 > <https://datatracker.ietf.org/doc/html/rfc4035#section-5.4>), we will > find that: > > wwwtest.ietf.org <http://wwwtest.ietf.org>. -> xml2rfc.ietf.org > <http://xml2rfc.ietf.org>. tells us that the exact name match for > wwww.ietf.org <http://wwww.ietf.org> does not exist, since it appears > in-between the two names. Therefore, the remaining ietf.org > <http://ietf.org>. -> _dmarc.ietf.org <http://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 <http://wwww.ietf.org>. > > Therefore, my question is: > *How can ietf.org <http://ietf.org>. -> _dmarc.ietf.org > <http://dmarc.ietf.org> NSEC be used to prove that there is no wildcard > record for the name wwww.ietf.org <http://wwww.ietf.org>?* Do we need to > prove that all the possible sources of synthesis for wwww.ietf.org > <http://wwww.ietf.org> appear in-between ietf.org <http://ietf.org>. and > _dmarc.ietf.org <http://dmarc.ietf.org>? The NSEC record ietf.org -> _dmarc.ietf.org proves that there is no source of synthesis for "wwww.ietf.org" so we could not have generated a wildcard response (note there is only ever one source of synthesis for a given name). > Or do we only need to prove that *.ietf.org <http://ietf.org> appears > in-between ietf.org <http://ietf.org>. and _dmarc.ietf.org > <http://dmarc.ietf.org>? If so why do we choose *.ietf.org > <http://ietf.org> instead of *.org or *? Because "*.ietf.org" is the source of synthesis (the other names are above the closest encloser. Hope this clarifies things. Best regards, Matthijs _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
