On Wed, Oct 27, 2021 at 04:09:01PM -0700, Joey Deng wrote:
> Thanks for the detailed response. I think the 'closest encloser’ proof
> is what I am missing here. It is weird that none of the DNSSEC RFCs
> talk about the closest encloser of NSEC (or maybe I am not aware about
> it).
Perhaps it was
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
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"
> On 27 Oct 2021, at 17:25, Mark Andrews wrote:
>
> For a given QNAME there is exactly one possible wild card name it can match
> depending
> on all the other names that exist. See the rules for when a QNAME matches a
> wildcard.
>
> NXDOMAIN proves that a QNAME does not exist. The NSEC
For a given QNAME there is exactly one possible wild card name it can match
depending
on all the other names that exist. See the rules for when a QNAME matches a
wildcard.
NXDOMAIN proves that a QNAME does not exist. The NSEC record that proves that
a QNAME
does not exist also proves the
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), it says:
>o If the requested RR name matches the
