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

Edward Lewis <Ed.Lewis@neustar.biz> Fri, 25 February 2011 20:23 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 D3B7A3A6A28 for <dnsext@core3.amsl.com>; Fri, 25 Feb 2011 12:23:52 -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 9zRfdCsYqo99 for <dnsext@core3.amsl.com>; Fri, 25 Feb 2011 12:23:51 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 64B543A6A26 for <dnsext@ietf.org>; Fri, 25 Feb 2011 12:23:51 -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 p1PKOaPg056701; Fri, 25 Feb 2011 15:24:36 -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 15:24:43 -0500
X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 25 Feb 2011 15:24:43 -0500
Mime-Version: 1.0
Message-Id: <a06240806c98dbfdd4bc4@[10.31.200.114]>
In-Reply-To: <976A5FBE345E43FDA7A17D7148B96189@local>
References: <a06240805c98db61801c2@[10.31.200.114]> <976A5FBE345E43FDA7A17D7148B96189@local>
Date: Fri, 25 Feb 2011 15:24:33 -0500
To: George Barwood <george.barwood@blueyonder.co.uk>
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: Edward Lewis <Ed.Lewis@neustar.biz>, dnsext@ietf.org
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:23:52 -0000

At 20:08 +0000 2/25/11, George Barwood wrote:

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

Good observation.  Question to those who've written caches, what 
strategy seemed best.

It's passages like the quoted that should be firmed up when and if 
DNSSEC is ever a Draft Standard/Full Standard.

And getting back to the resimprove draft, I'd wager that a BCP 
shouldn't disagree with a Standards Track document.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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!"