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

From: Matt Larson <[email-masked]>
Date: Wed, 19 Nov 2003 09:44:32 -0500

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

Section 3.2, second paragraph, of
draft-ietf-dnsext-dnssec-protocol-03.txt refers to the re-use of NSEC
records from the cache:

  A security-aware recursive name server MUST NOT use NSEC RRs from
  one negative response to synthesize a response for a different
  query.

Some reviewers have suggested that this language is overly
restrictive.  The editors propose this additional text immediately
following the above sentence to allow for a specific case of re-use:

  A security-aware recursive name server MAY use an NSEC RR from a
  previous response to generate a NODATA response to a current query,
  provided that the QNAME and QCLASS of the current query match the
  owner name and class, respectively, of the cached NSEC RR.

Does the working group have any objection to this added text?

--
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: Paul Vixie <[email-masked]>
Date: Wed, 19 Nov 2003 17:30:50 +0000

> ...

i think so but i'm not sure.  dnssec pseudo-rr's are really just metadata
and i'm uncomfortable with anything that unbinds them from their carrier
primary data.  if the above wording makes dnssec metadata atomic with
respect to its the data it pertains to then i have no objection.  but, i
can't tell from here.

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 19 Nov 2003 13:07:36 -0500

----- Original Message ----- 
From: "Paul Vixie" <[email-masked]>
> respect to its the data it pertains to then i have no objection.  but, i

another thing to think about is if it is safe to use cached data to form a
negative reply out of RRs from a previous negative reply.

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.

---

From: David Blacka <[email-masked]>
Date: Wed, 19 Nov 2003 13:32:51 -0500

>   one negative response to synthesize a response for a different

I'm not even sure this sentence accomplishes what was originally intended.  
What about NSEC RRs that were part of a positive response (i.e., a 
referral)?

> following the above sentence to allow for a specific case of re-use:

While this sentence may be too restrictive, the previous sentence in that 
paragraph certainly is:

   A security-aware recursive name server MUST NOT attempt to answer a
   query by piecing together cached data it received in response to
   previous queries that requested different QNAMEs, QTYPEs, or
   QCLASSes.

> Does the working group have any objection to this added text?

One of my issues is that I (and perhaps the WG as a whole) don't really 
understand the issue well enough to judge.

Ultimately, what I would like to see is language describing what the 
caching nameserver MUST NOT do with cached NSEC records, and have that 
MUST NOT be defined as narrowly as possible.  Additonally, I would like to 
see language describing WHY caches MUST NOT use NSEC records in that 
fashion.

But I think the first step is making sure we understand the problem in the 
first place.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Nov 2003 19:05:17 +0000

> 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.

---

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

> 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

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Nov 2003 22:18:57 +0000

> 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.

ok by me.

---

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

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 27 Nov 2003 10:18:13 +0100

Q21: Caching and reuse of NSEC RRs

      Default action, based on sense of the room at IETF58, is to
      change the text not to strongly prohibit any reuse of cached
      NSEC RRs, but to allow, and not encourage, (MAY language) reuse
      to synthesize negative answers for which QNAME, QLASS has an
      NSEC RR of same ONAME and CLASS in cache that proves the non
      existance of QTYPE.

      If there is no further prohibitive objections by December 8 this 
      will be taken as consensus of the working group.

-- Olaf
   DNSEXT co-chair
---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC