IETF Logo Mail Archive

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-chain-query-05.txt

Paul Wouters <paul@nohats.ca> Tue, 17 November 2015 09:58 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B781B2E02 for <dnsop@ietfa.amsl.com>; Tue, 17 Nov 2015 01:58:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level:
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.585] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ar5mibkAGhC for <dnsop@ietfa.amsl.com>; Tue, 17 Nov 2015 01:58:27 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4DB01B2E07 for <dnsop@ietf.org>; Tue, 17 Nov 2015 01:58:26 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3p0N4w3V8Yz1J7; Tue, 17 Nov 2015 10:58:24 +0100 (CET)
Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=ISho1Bsn
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id l7t3K4K-KSgP; Tue, 17 Nov 2015 10:58:23 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 17 Nov 2015 10:58:23 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPS id 9B12E8009F; Tue, 17 Nov 2015 04:58:21 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1447754301; bh=6Fogc2Enf7Ka6WxcVtSp7cqAk3CMNT6Sji8wUc3UBbo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ISho1BsnQOio0zC0lv4Mb6Pmheux5YNZtL0KVdBWk5P46DIX43jCiYzqBOngwuTjy mRELl/jFVMJ0S+0M9rFNtP6If6ZS8V/W0yj2VI6LL+NEptdYS9anNEx0oq+nOmCVqM 3glGAQu2lh1SPp/FT7YOLhQo9UmXuR7YpgQDVyKo=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id tAH9wKhQ007194; Tue, 17 Nov 2015 04:58:21 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Tue, 17 Nov 2015 04:58:20 -0500
From: Paul Wouters <paul@nohats.ca>
To: Mark Andrews <marka@isc.org>
In-Reply-To: <20151117080444.728DD3CDD50A@rock.dv.isc.org>
Message-ID: <alpine.LFD.2.20.1511170455010.7136@bofh.nohats.ca>
References: <20151117070537.8572.17899.idtracker@ietfa.amsl.com> <20151117080444.728DD3CDD50A@rock.dv.isc.org>
User-Agent: Alpine 2.20 (LFD 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/Y23OJB9RTJTkFm_6Kx3JOtY863E>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-chain-query-05.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Nov 2015 09:58:28 -0000

On Tue, 17 Nov 2015, Mark Andrews wrote:

>   A DNS query that contains the CHAIN option MUST also have the DNSSEC
>   OK ("OK") bit set.  If this bit is not set, or if the Checking
>   Disabled ("CD") bit is set, the CHAIN option received MUST be
>   ignored.
>
> Why disabled on CD=1?  If you have the contents cached and validated
> already what does it hurt to send the trust chain?  If you don't
> have a element of the trust chain you can still fetch it and return
> it unvalidated just using the signer names.

If you ask for www.toronto.redhat.com with CD=1 and redhat.com's RRSIG's
are missing, do you still traverse down the chain to www.toronto.redhat.com?

Also, the upstream resolver might not want to serve any data below it.
How could it fetch a (bogus) chain for the answer without mixing up
these known bad records in its cache?

I thought it better to just not support it. But I could be convinced
otherwise.

Paul

v2.23.0 | Report a Bug | By Email