[dnsext] Fwd: RFC 2308 & RFC 4035

Edward Lewis <Ed.Lewis@neustar.biz> Fri, 25 February 2011 19:40 UTC

Return-Path: <Ed.Lewis@neustar.biz>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6663A6831 for <dnsext@core3.amsl.com>; Fri, 25 Feb 2011 11:40:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwnGUE0mqslU for <dnsext@core3.amsl.com>; Fri, 25 Feb 2011 11:40:31 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 099DE3A6A16 for <dnsext@ietf.org>; Fri, 25 Feb 2011 11:40:30 -0800 (PST)
Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p1PJfHQb056302; Fri, 25 Feb 2011 14:41:18 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz)
Received: from [10.31.200.114] by Work-Laptop-2.local (PGP Universal service); Fri, 25 Feb 2011 14:41:23 -0500
X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 25 Feb 2011 14:41:23 -0500
Mime-Version: 1.0
Message-Id: <a06240805c98db61801c2@[10.31.200.114]>
Date: Fri, 25 Feb 2011 14:41:15 -0500
To: dnsext@ietf.org
From: Edward Lewis <Ed.Lewis@neustar.biz>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4
Cc: ed.lewis@neustar.biz
Subject: [dnsext] Fwd: RFC 2308 & RFC 4035
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Feb 2011 19:40:32 -0000

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!"