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

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

Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75DC13A6A4F; Fri, 25 Feb 2011 13:23:35 -0800 (PST)
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 C544E3A6A51 for <dnsext@core3.amsl.com>; Fri, 25 Feb 2011 13:23:29 -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 8fKi0FL8E0aM for <dnsext@core3.amsl.com>; Fri, 25 Feb 2011 13:23:20 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 26F7D3A6A43 for <dnsext@ietf.org>; Fri, 25 Feb 2011 13:23:09 -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 p1PLNsap057163; Fri, 25 Feb 2011 16:23:55 -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 16:24:00 -0500
X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 25 Feb 2011 16:24:00 -0500
Mime-Version: 1.0
Message-Id: <a06240807c98dc9437fad@[10.31.200.114]>
In-Reply-To: <AANLkTimZAd3CcN8rvgsdvS1HfqWHzmQ8hTBq4Cp8dM9n@mail.gmail.com>
References: <a06240805c98db61801c2@10.31.200.114> <976A5FBE345E43FDA7A17D7148B96189@local> <a06240806c98dbfdd4bc4@10.31.200.114> <AANLkTimZAd3CcN8rvgsdvS1HfqWHzmQ8hTBq4Cp8dM9n@mail.gmail.com>
Date: Fri, 25 Feb 2011 16:14:07 -0500
To: dnsext@ietf.org
From: Edward Lewis <Ed.Lewis@neustar.biz>
X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4
Cc: Edward Lewis <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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

At 16:48 -0400 2/25/11, Brian Dickson wrote:

>Does it matter which order the two responses arrive? (If it does, I
>think that indicates that there's a protocol problem....)

Order does matter, but that is not a problem in the protocol.  The 
DNS, prior to DNSSEC, had no concept of absolute (wall-clock) time 
for any reason.  Using UDP furthers the problem of trying to sequence 
the actions that occur in the system.

There was a conversation during the DNSSEC development years on 
whether the expiration/inception times could be used to try to 
sequence the values in an RRset, but this failed to come to fruition, 
partly because there is no guarantee that, for instance 
InceptionTime1>InceptionTime2 ==> ExpirationTime1>ExpirationTIme2.

Since then we've been wary of letting wall-clock time creep into DNS. 
To stop replay attacks, we need it but that's as far as it should 
really go.  This is why I once barked when someone did a survey of 
the clocks on authority servers - they shouldn't need to know the 
time of day.

What I meant to say is that the DNS protocol has the property that it 
is impossible to determine the sequence of messages in the system. 
If we built in some way to "make order unimportant" we'd severely 
crimp the protocol's scalability.  (All that locking and 
synchronization and all.)

The topic I am trying to tease out here is the question of how much 
"authority" is given to caches in generating answers.  The protocol 
is very conservative on this, as evidenced in RFC 2308's description 
of negative caching.  Again DNSSEC has tempted us to open this up, as 
quoted in the passages in the thread.

>Should it trigger discarding or non-caching of the NSEC record? (I
>think not, modulo the question on re-generation/re-signing NSEC/NSEC3
>data)

In the sense that code rules and specs walk, it would be good to get 
opinions from those who have written caches.  (I asked before, this 
isn't another nudge, I just want to emphasize this isn't mean to be a 
discussion over words in a static 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!"
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext