Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16

Mark Andrews <marka@isc.org> Fri, 20 January 2012 07:23 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 34D0421F85F8; Thu, 19 Jan 2012 23:23:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327044192; bh=6OzePQZfcRFxDComCCvU68zM+ZeCPBBGbFB6W1oBlyM=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=CsN2XNhyCo9U2amLMxl0QoURKq19IQSxT8XAoEltD23EUPYXk1+zPfnx1FYzWpTrE UzDfY1AL4aIdCpTWHU/FYA0CdBsY3P6US8yuXAnZpXwXvY3ENvNgh3H+HX+Ld8lQ/n XC9P2t60e9ylyu/wqwpOcGLhrMyWY8me/HsVK0xg=
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 468A021F85F8 for <dnsext@ietfa.amsl.com>; Thu, 19 Jan 2012 23:23:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.473
X-Spam-Level:
X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 JvqIP-HIB3y1 for <dnsext@ietfa.amsl.com>; Thu, 19 Jan 2012 23:23:10 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id AB65421F85F6 for <dnsext@ietf.org>; Thu, 19 Jan 2012 23:23:10 -0800 (PST)
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 07A735F98B1; Fri, 20 Jan 2012 07:22:50 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:902a:92d4:e011:46b7]) (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 164CF216C6B; Fri, 20 Jan 2012 07:22:49 +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 931F31BB343E; Fri, 20 Jan 2012 18:22:44 +1100 (EST)
To: Andrew Sullivan <ajs@anvilwalrusden.com>
From: Mark Andrews <marka@isc.org>
References: <20120120054939.GD4365@mail.yitter.info>
In-reply-to: Your message of "Fri, 20 Jan 2012 00:49:39 CDT." <20120120054939.GD4365@mail.yitter.info>
Date: Fri, 20 Jan 2012 18:22:44 +1100
Message-Id: <20120120072244.931F31BB343E@drugs.dv.isc.org>
Cc: dnsext@ietf.org
Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

	5.9.  Always set the CD bit on Queries  

	This is demonstratively *bad* advice.  The discussion to do
	with always setting CD bit on queries centered around
	different sets of trust anchors.

	If you take two validating recursive server in series with
	the *same* trust anchors.  If you always set CD then the
	downstream server is vulnerable to a accidental denial of
	service attack if any of the authoritative servers for the
	zone is returning stale (will fail validation) data.

		C -> VR1 -> VR2 -> {A1, A2, A3 .... AN }

	VR1 should make CD=0 as it has no control over which of A1
	... AN, VR2 queries.  By making a CD=0 query, VR2 will
	filter out responses from the stale server.  If the response
	from VR2 to the CD=0 is SERVFAIL then VR1 it should make a
	CD=1 query in case there is a mis-configured trust anchor
	or bad clock.

	Yes, Andrew it is re-opening this subject.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext