IETF Logo Mail Archive

Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors

Edward Lewis <edward.lewis@icann.org> Wed, 01 November 2017 16:48 UTC

Return-Path: <edward.lewis@icann.org>
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 AD44213F7CD for <dnsop@ietfa.amsl.com>; Wed, 1 Nov 2017 09:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Lj7A57FOow9f for <dnsop@ietfa.amsl.com>; Wed, 1 Nov 2017 09:48:09 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD89A13F474 for <dnsop@ietf.org>; Wed, 1 Nov 2017 09:48:09 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 1 Nov 2017 09:48:07 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 1 Nov 2017 09:48:07 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: Ólafur Guðmundsson <olafur@cloudflare.com>, Paul Wouters <paul@nohats.ca>
CC: Moritz Muller <moritz.muller@sidn.nl>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [Ext] Re: [DNSOP] Resolver behaviour with multiple trust anchors
Thread-Index: AQHTUiwiqVxvIHBV0Uun1GqDhxVA26L+vEmAgAABTICAAVxiAIAAGWoA
Date: Wed, 01 Nov 2017 16:48:07 +0000
Message-ID: <FBC2CDA3-30DF-4494-AB9E-3AAA889D6841@icann.org>
References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <CAN6NTqxy4SWxsUNZyBA=1TZxdhWtVxaTDYLoA1qO2nKf202g9w@mail.gmail.com> <E94AE36A-CA69-47DB-A2B7-41D0C3644855@nohats.ca> <CAN6NTqxmhBkdp_Ku43JJGc5XLmZY3d7YoTeparebzz1pp_r5ag@mail.gmail.com>
In-Reply-To: <CAN6NTqxmhBkdp_Ku43JJGc5XLmZY3d7YoTeparebzz1pp_r5ag@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.27.0.171010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3592385286_960282567"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ejdaqNmGc3DnLawxYtPaqO21Exk>
Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors
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: Wed, 01 Nov 2017 16:48:12 -0000

On 11/1/17, 11:17, "DNSOP on behalf of Ólafur Guðmundsson" <dnsop-bounces@ietf.org on behalf of olafur@cloudflare.com> wrote:

>Thus the question is twofold 
>
>a) is there need for clarification in how protocol works possibly with recommendation for resolver "tunable" settings. 
>

This is something that might be fit into -validator-requirements-.  (Which is perhaps another motivation of mine to dig into this.)

But the idea of more knobs to turn and switches to flip runs counter to my perceived need to simplify the operation of the DNS.  The battlefield is defined by software developers, who are pushed to add more functionality into simpler to run packages.

Many operators use "off-the-shelf" components and do not write their own code, which is what shifts this on to the shoulders of the software developers.

>b) is there need for operational guidance for "split DNS" DNSSEC

There was an attempt to document split DNS more than 10 years ago, which died a death of disinterest.  (Last version expired 10 years, 1 month, 25 days ago. ;)  Lucky guess.)

https://tools.ietf.org/html/draft-krishnaswamy-dnsop-dnssec-split-view-04

Perhaps start there.  (Last time I saw the author was in a children's swimming school lobby just last year.  Odd.)

v2.23.0 | Report a Bug | By Email