IETF Logo Mail Archive

Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record

Paul Wouters <paul@nohats.ca> Tue, 14 November 2017 02:15 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFB4129AFE for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 18:15:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 0ZKgaPfp2zfQ for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 18:15:33 -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 38633129ADF for <dnsop@ietf.org>; Mon, 13 Nov 2017 18:15:33 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ybWLm4P4Fz2n; Tue, 14 Nov 2017 03:15:28 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1510625728; bh=TNOSBWu8k1NZR85q1W558QpA4y7vCVKc7CaXgrVlosI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=U7U/MHzFhdzBLiYeRkU0MMuRZ2P+slVlXvNwa9vR0kbeVZG7SFVTRCs0aTh3huLMz r9mBZPTOxANXXuCZILCB8D6+1i9aXsLTz8DnbJOAKP2aR0z7zoO2pSSgcThWj/5YkL oDNo1f98xBaRUlf798DzkrrOygQhfTI0TtYzsTgg=
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 sA3xfGdvcgEu; Tue, 14 Nov 2017 03:15:27 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 14 Nov 2017 03:15:27 +0100 (CET)
Received: from [31.133.130.95] (dhcp-825f.meeting.ietf.org [31.133.130.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 14BD362D29; Mon, 13 Nov 2017 21:15:26 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 14BD362D29
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Paul Wouters <paul@nohats.ca>
X-Mailer: iPhone Mail (15A432)
In-Reply-To: <3440AE65-DE72-4AAE-8A93-2D698CEF79C4@icann.org>
Date: Tue, 14 Nov 2017 10:15:22 +0800
Cc: Evan Hunt <each@isc.org>, Petr Špaček <petr.spacek@nic.cz>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <463C4A1E-D189-4A0D-9814-D215F930B0D4@nohats.ca>
References: <5C194845-AB79-47DE-B936-97560D071C5D@icann.org> <b21647d7-a710-e5f7-048f-d90eccc79c0f@nic.cz> <20171109174804.GA63012@isc.org> <3440AE65-DE72-4AAE-8A93-2D698CEF79C4@icann.org>
To: Edward Lewis <edward.lewis@icann.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hOe2T7GIFnfYTQHYN9L1x7TcGLs>
Subject: Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 14 Nov 2017 02:15:35 -0000


> 
> I'm not sure that the need for robustness outweighs the expectation of someone explicitly adding a trust anchor anymore.

But that’s not your call to make, but the call of the entity deciding to put in that hard coded trust anchor.

We just ask you not to block us from doing as we have been doing for years.

> OTOH, in the sense "I am not sure" there's the example of split-DNS and poor query path management (i.e., leaks).  I'm not sure if robustness helps here, or is a bad-behavior enabler.

I would like split-DNS to die too but I dont think that’s happening soon.

Paul

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