Re: [dnsext] Fwd: RFC 2308 & RFC 4035

"George Barwood" <george.barwood@blueyonder.co.uk> Fri, 25 February 2011 20:07 UTC

Return-Path: <george.barwood@blueyonder.co.uk>
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 2074B3A67FB for <dnsext@core3.amsl.com>; Fri, 25 Feb 2011 12:07:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.745
X-Spam-Level:
X-Spam-Status: No, score=0.745 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753]
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 L-73frec8K3r for <dnsext@core3.amsl.com>; Fri, 25 Feb 2011 12:07:02 -0800 (PST)
Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by core3.amsl.com (Postfix) with ESMTP id 141853A6A1E for <dnsext@ietf.org>; Fri, 25 Feb 2011 12:07:01 -0800 (PST)
Received: from [172.23.170.144] (helo=anti-virus03-07) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1Pt3xB-0007B2-Vm; Fri, 25 Feb 2011 20:07:53 +0000
Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from <george.barwood@blueyonder.co.uk>) id 1Pt3wy-00060a-Cu; Fri, 25 Feb 2011 20:07:40 +0000
Message-ID: <976A5FBE345E43FDA7A17D7148B96189@local>
From: George Barwood <george.barwood@blueyonder.co.uk>
To: dnsext@ietf.org, Edward Lewis <Ed.Lewis@neustar.biz>
References: <a06240805c98db61801c2@[10.31.200.114]>
Date: Fri, 25 Feb 2011 20:08:24 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994
Cc: ed.lewis@neustar.biz
Subject: Re: [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 20:07:03 -0000

----- Original Message ----- 
From: "Edward Lewis" <Ed.Lewis@neustar.biz>
To: <dnsext@ietf.org>
Cc: <ed.lewis@neustar.biz>
Sent: Friday, February 25, 2011 7:41 PM
Subject: [dnsext] Fwd: RFC 2308 & RFC 4035


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

I think this is addressed by

http://tools.ietf.org/html/rfc4035#section-4.5

<<
   In theory, a resolver could use wildcards or NSEC RRs to generate
   positive and negative responses (respectively) until the TTL or
   signatures on the records in question expire.  However, it seems
   prudent for resolvers to avoid blocking new authoritative data or
   synthesizing new data on their own.  Resolvers that follow this
   recommendation will have a more consistent view of the namespace.
>>

George


> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 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!"
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext