IETF Logo Mail Archive

Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness

Tony Finch <dot@dotat.at> Mon, 21 February 2011 21:28 UTC

Return-Path: <fanf2@hermes.cam.ac.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 EF9213A717B for <dnsext@core3.amsl.com>; Mon, 21 Feb 2011 13:28:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.203
X-Spam-Level:
X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
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 cZur8KAHlDSk for <dnsext@core3.amsl.com>; Mon, 21 Feb 2011 13:28:33 -0800 (PST)
Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id C10C13A7159 for <dnsext@ietf.org>; Mon, 21 Feb 2011 13:28:33 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from 69.91.125.91.rb4.adsl.brightview.com ([91.125.91.69]:49459 helo=[192.168.0.5]) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1PrdJg-00019q-sX (Exim 4.72) (return-path <fanf2@hermes.cam.ac.uk>); Mon, 21 Feb 2011 21:29:13 +0000
References: <4D622624.90303@ogud.com> <BF79BE89-20B2-4897-B07C-1426745C4AA9@verisign.com>
In-Reply-To: <BF79BE89-20B2-4897-B07C-1426745C4AA9@verisign.com>
Mime-Version: 1.0 (iPhone Mail 8C148)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"
Message-Id: <5E260AAB-89BD-4A17-BE0B-BC42BFB7E43C@dotat.at>
X-Mailer: iPhone Mail (8C148)
From: Tony Finch <dot@dotat.at>
Date: Mon, 21 Feb 2011 21:28:53 +0000
To: David Blacka <davidb@verisign.com>
Sender: Tony Finch <fanf2@hermes.cam.ac.uk>
Cc: "dnsext@ietf.org" <dnsext@ietf.org>, Olafur Gudmundsson <ogud@ogud.com>
Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness
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: Mon, 21 Feb 2011 21:28:35 -0000

On 21 Feb 2011, at 18:58, David Blacka <davidb@verisign.com> wrote:.
> 
> (A) is (I think) trying to solve issues caused by "cache pinning" when moving a zone from one set of nameservers to another.  Actually, it goes further than that (if I understand the draft correctly, which I very well may not) by effectively removing entire delegation chains when the ancestor NS RRset expires.  So, e.g., every time the com NS RRset expires, all delegations below it effectively expire.  I have no idea what problem this overall behavior solves, although I suspect that it defeats a great deal of the value of a cache.

There are a couple of other things that worry me about this section of the draft.

Firstly, it suggests that there can be multiple different TTLs on the delegation NS RR set - it talks about the minimum TTL. It needs fixing to understand that the whole RR set has the same TTL.

Secondly, it is basically suggesting that the TTL of the non-authoritative spoofable delegation NS RR set should override the TTL of the authoritative signed apex NS RR set. This seems to me to be contrary to DNS and DNSSEC authority semantics.

Tony.
--
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/

v2.23.0 | Report a Bug | By Email