[dnsext] caches, validating resolvers, CD and DO

Mark Andrews <marka@isc.org> Wed, 30 March 2011 06:22 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 7ABB13A6A9A for <dnsext@core3.amsl.com>; Tue, 29 Mar 2011 23:22:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.425
X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_NO_MORE_ADS=1.174]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id qp1jivj+Zmyi for <dnsext@core3.amsl.com>; Tue, 29 Mar 2011 23:22:02 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 11D673A6A87 for <dnsext@ietf.org>; Tue, 29 Mar 2011 23:22:02 -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.pao1.isc.org (Postfix) with ESMTPS id 074A2C9423 for <dnsext@ietf.org>; Wed, 30 Mar 2011 06:23:38 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown []) (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 C69BA216C33 for <dnsext@ietf.org>; Wed, 30 Mar 2011 06:23:37 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost []) by drugs.dv.isc.org (Postfix) with ESMTP id BA8C9DAC3C4 for <dnsext@ietf.org>; Wed, 30 Mar 2011 17:23:35 +1100 (EST)
To: dnsext@ietf.org
From: Mark Andrews <marka@isc.org>
Date: Wed, 30 Mar 2011 17:23:35 +1100
Message-Id: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org>
Subject: [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 06:22:06 -0000

I don't think we have the sematics of these bits quite right
yet.  In normal operations a validating resolver taking to
a cache should just set DO.  This will result in DNSSEC records
being returned and in most cases these will validate.  This
also permits caches to do their jobs correctly.

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.  This
option is initially empty.  The cache will then behave as a proxy
for this query (excluding the EDNS option) adding the responding
server's address to the EDNS option.  If there are no more addresses
to try, SERVFAIL (new rcode?) is returned along with the EDNS option
from the query.

If the cache is using another cache the entire query/response is
proxied.  The intent is for the validating client to talk through
intermediate caches to the cache talk directly to the authoritative
servers.  The EDNS option maintains a list of authoritative server
addresses for the zone that have been tried.  This list is passed
back and forth between the validating resolver and the cache talking
to the authoritative server.

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