Re: [dnsext] caches, validating resolvers, CD and DO
Mark Andrews <marka@isc.org> Wed, 30 March 2011 08:44 UTC
Return-Path: <marka@isc.org>
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 C92973A6AFB for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 01:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 1y3QU8SkYUFC for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 01:44:41 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id DAA6E3A6919 for <dnsext@ietf.org>; Wed, 30 Mar 2011 01:44:40 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 3404D5F984C; Wed, 30 Mar 2011 08:46:05 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:96:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 2B2E9216C22; Wed, 30 Mar 2011 08:46:02 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 401CADAD6B8; Wed, 30 Mar 2011 19:46:00 +1100 (EST)
To: Alex Bligh <alex@alex.org.uk>
From: Mark Andrews <marka@isc.org>
References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local> <20110330071105.72604DAC915@drugs.dv.isc.org><1CA2585509A7CF3EC32560F8@nimrod.local>
In-reply-to: Your message of "Wed, 30 Mar 2011 09:34:36 -0000." <1CA2585509A7CF3EC32560F8@nimrod.local>
Date: Wed, 30 Mar 2011 19:46:00 +1100
Message-Id: <20110330084600.401CADAD6B8@drugs.dv.isc.org>
Cc: dnsext@ietf.org
Subject: Re: [dnsext] caches, validating resolvers, CD and DO
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: Wed, 30 Mar 2011 08:44:41 -0000
In message <1CA2585509A7CF3EC32560F8@nimrod.local>, Alex Bligh writes: > > > --On 30 March 2011 18:11:05 +1100 Mark Andrews <marka@isc.org> wrote: > > > You can have different clocks and different sets of trust anchors. > > The upstream could be treating a zone as insecure but you have a > > trust anchor. The upstream won't filter stale responses for you > > so it won't cope with a authoritative server with stale data and a > > number of other operational errors that you can work around with > > direct access to the authoritative servers. > > Hmmm. I think I understand. > > And none of these errors that you can work around with "direct" > access to the authoritative servers are ones that > will end up in the BAD cache? As you'll still see these I think. > RFC4035 s3.2.2 > > If the CD bit is set, > > the name server side SHOULD return the data from the BAD cache; > > Isn't the real answer here just to be a full recursive resolver > and *really* access the authoritative nameservers directly? There are plenty of sites that only allow the recursive server talk to the world. As much as I would like to say "go direct to the source" it is not practical. As for the "bad cache" the only reason for that is we provided bad advice of "set the CD if you intend to validate". CD really needs to be set less often. > I take it you are suggesting that the reissued query should always > have DO set as well as CD. > > -- > Alex Bligh -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
- Re: [dnsext] caches, validating resolvers, CD and… Mark Andrews
- [dnsext] caches, validating resolvers, CD and DO Mark Andrews
- Re: [dnsext] caches, validating resolvers, CD and… Alex Bligh
- Re: [dnsext] caches, validating resolvers, CD and… Paul Vixie
- Re: [dnsext] caches, validating resolvers, CD and… Paul Vixie
- Re: [dnsext] caches, validating resolvers, CD and… Mark Andrews
- Re: [dnsext] caches, validating resolvers, CD and… Michael Richardson
- Re: [dnsext] caches, validating resolvers, CD and… Alex Bligh
- Re: [dnsext] caches, validating resolvers, CD and… Mark Andrews
- Re: [dnsext] caches, validating resolvers, CD and… Paul Vixie
- Re: [dnsext] caches, validating resolvers, CD and… Tony Finch
- Re: [dnsext] caches, validating resolvers, CD and… Mark Andrews
- Re: [dnsext] caches, validating resolvers, CD and… Mark Andrews
- Re: [dnsext] caches, validating resolvers, CD and… Jelte Jansen
- Re: [dnsext] caches, validating resolvers, CD and… Marc Lampo
- Re: [dnsext] caches, validating resolvers, CD and… Mark Andrews
- Re: [dnsext] caches, validating resolvers, CD and… Edward Lewis
- Re: [dnsext] caches, validating resolvers, CD and… Nicholas Weaver
- Re: [dnsext] caches, validating resolvers, CD and… Mark Andrews
- Re: [dnsext] caches, validating resolvers, CD and… Marc Lampo
- Re: [dnsext] caches, validating resolvers, CD and… Nicholas Weaver
- Re: [dnsext] caches, validating resolvers, CD and… Derek Atkins
- Re: [dnsext] caches, validating resolvers, CD and… Nicholas Weaver
- Re: [dnsext] caches, validating resolvers, CD and… bmanning