Subject: [dnsext] RFC 2308 & RFC 4035

From: Edward Lewis <[email-masked]>
Date: Fri, 25 Feb 2011 13:28:02 -0500

I have a question referring to two sections in two RFCs, prompted by 
the resimprove draft.

RFC 4035:
5.4.  Authenticated Denial of Existence
...
    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.  ...

And in RFC 2308:
5 - Caching Negative Answers
...
    A negative answer that resulted from a no data error (NODATA) should
    be cached such that it can be retrieved and returned in response to
    another query for the same <QNAME, QTYPE, QCLASS> that resulted in
    the cached negative response.

Let's aay this happens:

at 10am a cache receives a response to a query for example.tld./IN/A that says

example.tld.   3600    NSEC3   a.example.tld.  SOA NS DNSKEY RRSIG NSEC

at 10:15am the cache gets a query for example.tld./IN/AAAA.

Should the cache rely with a NoData response or should it try to 
query for the AAAA?

If the answer to the previous is "it should rely on the cached NSEC:" 
What if I said that at 10:10am, the authority was updated with a new 
zone that had an AAAA RRset at the apex?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"

---

From: Francis Dupont <[email-masked]>
Date: Sun, 27 Feb 2011 19:36:25 +0100

In your previous mail you wrote:

=> +1 about this question which should put in a FAQ (:-).

The answer is "MUST NOT synthesize an answer from a cached NSEC"
and I got it from one of the authors of a referenced RFC...
so at least a yes doesn't follow the spirit of specs.

Regards

[email-masked]

PS: IMHO the only safe/conservative abuse of a cached NSEC/NSEC3 is
about a NXDOMAIN for the same name but a different type/class, i.e.,
about a proof of non-existence of a name.