IETF Logo Mail Archive

Re: [dnsext] caches, validating resolvers, CD and DO

Mark Andrews <marka@isc.org> Wed, 30 March 2011 07:09 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 C04253A6B20 for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 00:09:48 -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 pVlpbmT-HPd3 for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 00:09:47 -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 B0C793A6B1D for <dnsext@ietf.org>; Wed, 30 Mar 2011 00:09:47 -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 AE1CE5F984C; Wed, 30 Mar 2011 07:11:10 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:32: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 E1DF9216C22; Wed, 30 Mar 2011 07:11:08 +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 72604DAC915; Wed, 30 Mar 2011 18:11:05 +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>
In-reply-to: Your message of "Wed, 30 Mar 2011 07:42:32 -0000." <0CAE569785C163CFE87B957E@nimrod.local>
Date: Wed, 30 Mar 2011 18:11:05 +1100
Message-Id: <20110330071105.72604DAC915@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 07:09:48 -0000

In message <0CAE569785C163CFE87B957E@nimrod.local>, Alex Bligh writes:
> 
> 
> --On 30 March 2011 17:23:35 +1100 Mark Andrews <marka@isc.org> wrote:
> 
> > When these do not validate or SERVFAIL is returned, the validating
> > resolver should then re-issue the query with CD set and a EDNS
> > option indicating which upstream servers have been tried.
> 
> Why "should"? Effectively the validating resolver is handing off
> DNSSEC validation to the upstream server here isn't it? It might not
> want to trust the upstream server, particularly if it's already
> got records that don't validate.

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.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

v2.29.0 | Report a Bug | By Email | System Status