Re: [DNSOP] Resolver behaviour with multiple trust anchors

Ólafur Guðmundsson <olafur@cloudflare.com> Wed, 01 November 2017 15:17 UTC

Return-Path: <olafur@cloudflare.com>
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 8C53B13FD45 for <dnsop@ietfa.amsl.com>; Wed, 1 Nov 2017 08:17:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com
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 NfeI2ionxlzr for <dnsop@ietfa.amsl.com>; Wed, 1 Nov 2017 08:17:11 -0700 (PDT)
Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61FE13FCAD for <dnsop@ietf.org>; Wed, 1 Nov 2017 08:17:10 -0700 (PDT)
Received: by mail-wr0-x235.google.com with SMTP id y39so2224222wrd.4 for <dnsop@ietf.org>; Wed, 01 Nov 2017 08:17:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/qQllioozdZbMb9gkGMIrnUf0toEQDFmWdhBQXyrFhY=; b=jRCVA+xUhZR+sPvHjXwY3eYFVUwleWzE2iYMD8n/Oas8bHimhcuBY4b7k5102vFLf4 LPM+QlVpmRA6N7UraIBS/iHWUNzfyW0ahYoC+BxBOpWnF698Uc4nuWEsPNljhtt9gdMc hUwnuj+4f6CplEBD27uOXNvY5Ni8SsA8mc2xw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/qQllioozdZbMb9gkGMIrnUf0toEQDFmWdhBQXyrFhY=; b=Q4nL7Ge05kMHdi3x5Z7HNC5S38rqmjYhYw3R8OsO7w35IyZvfv0skA8q5a0F2kHaZy ILU5imHFURs2fJz0StvYcndx88PqgsKMqu36frsjyLVscH4RyCWemgppK485FwI4tm75 k2tH3NmY7HZtENc+MrcieVz8OxBQ42kIH70vSqCrNUXrchBDw9bOBIILz+lBkO7qvtjW ZsxQde5UTn9Gj0RtOBYM0xj+Fqc+NXv4CM7DE2/zEMXRgQGPUZQqHJy7YQVeg8uNLLxM m6VOO7Bip/oT1DJVi3aDjaRr738kUyY6AFc3P49hIHz3Z0c1Vtgd8apxqLafVG+qym/R Uw/Q==
X-Gm-Message-State: AMCzsaUHN6mV/+WAyaDHlG0pmPvG8SOtcieqoQc2OMrzAd/zQRpeOIXu nh/Yz4KW8AcPl1SSV2G7N/PdnwzPj/aiG0DLnInrvUw2
X-Google-Smtp-Source: ABhQp+SstaNejAXxGfV/GTnbkoN8YsGod615nDXczDIIq0UizrPV8s4qkQF+afkSX1y6SOfWtyK++2C6B5ZuwMnOyKc=
X-Received: by 10.223.139.85 with SMTP id v21mr163067wra.70.1509549429197; Wed, 01 Nov 2017 08:17:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.201.10 with HTTP; Wed, 1 Nov 2017 08:17:08 -0700 (PDT)
In-Reply-To: <E94AE36A-CA69-47DB-A2B7-41D0C3644855@nohats.ca>
References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <CAN6NTqxy4SWxsUNZyBA=1TZxdhWtVxaTDYLoA1qO2nKf202g9w@mail.gmail.com> <E94AE36A-CA69-47DB-A2B7-41D0C3644855@nohats.ca>
From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <olafur@cloudflare.com>
Date: Wed, 1 Nov 2017 08:17:08 -0700
Message-ID: <CAN6NTqxmhBkdp_Ku43JJGc5XLmZY3d7YoTeparebzz1pp_r5ag@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: Moritz Muller <moritz.muller@sidn.nl>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="f403045e9c927fa60a055ced5da8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2mCBw3qrL0C_9oUdX8mQnsXsAQs>
Subject: Re: [DNSOP] 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 15:17:12 -0000

On Tue, Oct 31, 2017 at 11:30 AM, Paul Wouters <paul@nohats.ca>; wrote:

>
>
> > On Oct 31, 2017, at 22:25, Ólafur Guðmundsson <olafur@cloudflare.com>;
> wrote:
> >
> >
> > There are three ways to treat this case:
> > Any-TruestedKey-works
> > ConfiguredKey-trumps-DS
> > DS-trumps-configuredKey
> >
> > I think the Last one is the "most" correct from an operational
> expectation,
>
> Not really, as that would mean you cannot have internal only zones in
> split-dns view, unless you are
> building in weird assumptions like ConfiguredKeyTrumpsNSECbutNotDS
>
> > But I suspect the middle one is implemented
>
> It better, it is the only working solution :)
>
> The question is that what the "users" expect?
I  agree that first two have the best operational behaviors, and the third
one blocks "split-DNS with different KEY"
if Internal domains use the same key as External "equivalent" ones then
there is no issue
Thus the question is twofold
a) is there need for clarification in how protocol works possibly with
recommendation for resolver "tunable" settings.
b) is there need for operational guidance for "split DNS" DNSSEC

I think the answer on both is yes.

Olafur