Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 17 October 2011 14:04 UTC

Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1299921F8B8A; Mon, 17 Oct 2011 07:04:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1318860286; bh=xLrR0vXGp4hfe8JXF4Bhu7q7YMq7uBASsuH+8wvffuo=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=zDx1htQmhjj4hoFVA7oLcPPkWcKH3wL0OjJNGv4lRi3gKsu/BpkLZGGnx1XvczctB ZYCsC9jF+pg8EmDgmhEuNFkZ/qF85lHlh718Up55qNChDZj1TqvFQ9rAdxt0Anyr7n OludI2tlu4gfGTkJlhi4sv5rARe2pbENigxFn8pk=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32A621F87F0 for <dnsext@ietfa.amsl.com>; Mon, 17 Oct 2011 07:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level:
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GPVHOw-Ee7M for <dnsext@ietfa.amsl.com>; Mon, 17 Oct 2011 07:04:44 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 64ACD21F8B72 for <dnsext@ietf.org>; Mon, 17 Oct 2011 07:04:44 -0700 (PDT)
Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 21A2F1ECB41D for <dnsext@ietf.org>; Mon, 17 Oct 2011 14:04:35 +0000 (UTC)
Date: Mon, 17 Oct 2011 10:04:38 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsext@ietf.org
Message-ID: <20111017140437.GA7743@shinkuro.com>
References: <20111008212432.GB82710@shinkuro.com> <20111008223820.F09F314DF5E1@drugs.dv.isc.org> <20111009135505.GA85221@shinkuro.com> <20111009213431.4756314E0BDE@drugs.dv.isc.org> <CACU5sD=-pJUVKG1QmwBX9d-MZJp6_AYkXWDxh_CTAXO=x7+Juw@mail.gmail.com> <20111010051725.3A95214E5206@drugs.dv.isc.org> <CACU5sDnd49zbLxqLFOebFfm6UqJ7qZiQuCqY4DeEA4rHiia8GQ@mail.gmail.com> <20111010220027.F1E2614EB649@drugs.dv.isc.org> <4E9C2413.3030000@nlnetlabs.nl> <20111017134650.816981569E8F@drugs.dv.isc.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111017134650.816981569E8F@drugs.dv.isc.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dnsext] Why are we re-opening this topic? Was: Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

No hat

On Tue, Oct 18, 2011 at 12:46:50AM +1100, Mark Andrews wrote:
> 
> And when the stub retries there is no state to prevent the recursive
> server asking the same broken upstream again and again and again

This is true of any breakage.  If the authoritative servers are under
DoS, you have the same problem, no?  DoS on authoritative servers is
at least as common as DNSSEC misconfiguration.

The plain fact is that DNSSEC makes the DNS more fragile.  Why is this
news, and why do you think that your recommendation is the only
sensible response to this?  I still don't understand that.
 
> There is no requirement for a recursive server to attempt to validate
> a response to a CD=1 query from downstream or if it attempts to
> validate the response to retry a different upstream if the validation
> fails.

Of course not. 

Best,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext