Subject: Re: Q-21: Can NSEC records in the cache be re-used?

From: Daniel Massey <[email-masked]>
Date: Wed, 19 Nov 2003 16:49:32 -0500

On Nov 19, 2003, at 2:05 PM, Paul Vixie wrote:

>> ...
>> off topic for Q21 (re: dnssec rrs):
>> In a way, yes.  NSEC RRs could be queried for the information they do
>> contain, since they contain more non-security information than 
>> RRSIGs.  I
>> can imagine a scenario where a application may want to issue NSEC 
>> queries
>> instead of "name.  IN  ANY"  queries, for example.  An RRSIG isn't 
>> that
>> informative without the RR set it covers.  A NSEC RR contains some
>> information that could be used in a non-DNSSEC manner.
>
> let me emphasize what i mean by metadata.  i'd like to see NSEC, RRSIG,
> and DNSKEY treated more like AXFR and IXFR, such that one could never
> query for them directly.  their only existence should be as part of 
> zone
> transfers or responses containing signed data.

This is appropriate for the RRSIG and an explicit query for RRSIG has 
the subtyping problem (and related TTL problem, etc.)

This NSEC RR as metadata also makes sense to me.  Note that if an NSEC 
RR is missing from a response, the resolver doesn't usually what QNAME 
to query anyway.   So calling this metadata that could never be queried 
directly is not much of a loss.

Note however this view directly contradicts the current protocol draft 
text and says explicit query for NSEC is a MUST. Section 4 of protocol 
says:  A security-aware resolver MUST attempt to retrieve a missing 
NSEC RR which the resolver needs to authenticate a NODATA response.  In 
general it is not possible for a resolver to retrieve missing NSEC RRs, 
since the resolver will have no way of knowing the owner name of the 
missing NSEC RR, but in the specific case of a NODATA response, the 
resolver does know the name of the missing NSEC RR, and must therefore 
attempt to retrieve it.

I disagree that DNSKEY should be treated as metadata.  There are times 
when an explicit query for a DNSKEY is required and there is no 
ambiguity about subtyping/query name/whatever.   Explicit queries for 
DNSKEY and DS are needed in my view.

Dan

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 19 Nov 2003 22:41:09 -0500 (EST)

> directly is not much of a loss.

I'm forgetting how we resolved the RRSIG(NSEC) truncation problem:
is it still possible to get an NSEC but not the RRSIG(NSEC)?  If so,
then querying for NSEC is the most efficient way (presumably) to get
RRSIG(NSEC).  Either way, you'd need to query for RRSIG or NSEC. (This
is why I wanted the NSEC included, even if RRSIG(NSEC) didn't fit --
at least then you know what NSEC to ask for.)

>   Explicit queries for DNSKEY and DS are needed in my view.

Concur.

If one server is authoritative for both parent and child, a DS record
will not be returned in response to a random query in the child zone.
Will it be returned in response to an NS query for the zone cut?  If
not, then explicit DS queries are needed

And if we want to change that, section 2.2.1.2 of the DS draft, which
discusses the grandparent problem, includes a QTYPE=DS example.

-- Sam

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 20 Nov 2003 07:38:13 -0500

----- Original Message ----- 
From: "Samuel Weiler" <[email-masked]>

> at least then you know what NSEC to ask for.)

Are you talking about the NSEC and RRSIG(NSEC) in the authority section in a
negative response?  The protocol document states that they MUST be included
together.  If the RRSIG caused truncation, the TC bit is set, and the
message is truncated like traditional DNS.  I think we eliminated almost
every case where a resolver would have the RRset but not the RRSIG.  This
was on purpose to avoid a query for type RRSIG.

Scott