Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

Ted Lemon <mellon@fugue.com> Thu, 18 June 2020 17:22 UTC

Return-Path: <mellon@fugue.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 E1D173A0CF6 for <dnsop@ietfa.amsl.com>; Thu, 18 Jun 2020 10:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 8YNDtm3zPJio for <dnsop@ietfa.amsl.com>; Thu, 18 Jun 2020 10:22:34 -0700 (PDT)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 ECCA63A0CA7 for <dnsop@ietf.org>; Thu, 18 Jun 2020 10:22:33 -0700 (PDT)
Received: by mail-qk1-x72c.google.com with SMTP id q2so6345748qkb.2 for <dnsop@ietf.org>; Thu, 18 Jun 2020 10:22:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=BWXDck6hbk2xO6I7vEtQBYEfnyObQCbnQjzUGNOnKxg=; b=Kw7ErAU3h8AOxTOoM0e0ZPI8eI+ZFLD7uhvhvFxwNnq3cxTqkXzu7JSYFiXpU8F3h6 HF3704zRE7whtGGT4Kcr5gy5tskKpyfFn4KOzE3mL+6gjxg7rtGtJlL0RXjYx+vqYJ5e myV4ElAgT1WBc3SsDT8zskA+ow7c76my9UHbWFkAK8DtXCqQ2QDD3VHTG6+Ybl2GohDA a94iPwEDlTVHnjSLhTgcJPqyAdA1DolKvmVfglC3MY2Llurfa0QukrCAckCROaWG7WGy Q1Ee4nZnTqw6gpL8XPZrbQt6jfyZJkSjxn35gAPLSCuepxh/btbuHtnLCJid0DLyUu2e J6RA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=BWXDck6hbk2xO6I7vEtQBYEfnyObQCbnQjzUGNOnKxg=; b=P2HNKCoJJPG+HfdQfyXSLWn4yqJLvV1L76vfEo69nPu9VI+sIjO4g5bwFU0HeABHvq 9/5u2+cToVgO2C1VnmihOvT9oP6Y1XdpWhhQALKmeVEg0T/0c2CoNUtAFiUQ7Ou3SJTa Ump3b35PrZqSwfY0OD0HzZdx+0b6yf2i9IEJctBn/wzlH1Bpy9b4B2fbeRAEcQiSstJD /OMz328homiQ6OzU4PmxAR1NPEoE++JZJEUuQbJAN+TIl1J52ATbBgPtgT8NBsWlJocw Qha/d7ZVKqKa0QJdYMuT7XPsqGUK6gtqiddUraKg8P1CKtNqBtpsNUR7/IsDTL29muME bJDg==
X-Gm-Message-State: AOAM5321vIwLOVbdVhnEXD3yfatsfLeVvPGeZe3zFq6F3n/rQGi7580p oeFMcoom5irCQ31EPXTNDk6VBQ==
X-Google-Smtp-Source: ABdhPJyaHWcszeowVxB+rhugTSc8vcRjQLQ63STGU7+OHNwGTpYTC/7yDf8uyrviDYrJSIl2o0QiOA==
X-Received: by 2002:a37:9cc7:: with SMTP id f190mr4880644qke.236.1592500952972; Thu, 18 Jun 2020 10:22:32 -0700 (PDT)
Received: from ?IPv6:2601:18b:300:36ee:48ca:bd69:ffe9:aecb? ([2601:18b:300:36ee:48ca:bd69:ffe9:aecb]) by smtp.gmail.com with ESMTPSA id u76sm3476443qka.79.2020.06.18.10.22.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2020 10:22:31 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <78631416-983E-4C33-BF48-28DAC6E7DA23@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D275F78D-424A-4230-BE28-F2A6D6C6376E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Thu, 18 Jun 2020 13:22:30 -0400
In-Reply-To: <78261BF7-ACD4-4F6E-A513-0DB72FE45E46@hopcount.ca>
Cc: Roy Arends <roy@dnss.ec>, dnsop@ietf.org
To: Joe Abley <jabley@hopcount.ca>
References: <B3109CA9-AF2E-4444-B89D-163ED1BC4D64@fugue.com> <78261BF7-ACD4-4F6E-A513-0DB72FE45E46@hopcount.ca>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3TM5Y-Ut2ZZhV53fNWQVeVMxXzE>
Subject: Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 18 Jun 2020 17:22:36 -0000

On Jun 18, 2020, at 12:10 PM, Joe Abley <jabley@hopcount.ca> wrote:
> 
> [As an aside, I have some concerns about RFC 8375 and I wish I was paying more attention at the time it was discussed. Although I can understand some of the technical arguments for the delegation, I'm not especially convinced by them in practice, and the decision to make the unsigned delegation also a *lame* unsigned delegation whilst simultaneously directing all leaked queries with potential information about private networks to be sent to nameservers that by design are intended to have anonymous operators is a poor one, I think. I note that the security considerations section doesn't even address the potential for information leakage.]

Ouch. That’s a depressing observation.  I’m can’t think of a way to completely mitigate this risk, however, unfortunately.  Any mitigation requires new code on the edge router for the provisioning domain in which the locally-served domain is being used.

>> Also, what do you think the operational effect of this will be? Given that these domains are currently provably nonexistent, this means that a resolver looking up names in these domains will have to special-case them.
> 
> I suspect it will work like every other locally-served domain or every other private namespace that exists today, i.e. just fine with no configuration changes expected or required on dependent (downstream) DNS clients. And if there are new species of resolver that need to be accommodated (e.g. validating, hybrid stub/full service resolvers embedded in applications), whatever configuration or auto-discovery mechanisms are required to support those other locally-served zones can surely be easily extended to these ISO-3166-2 codes if they are used in any particular private network.

What I’m getting at is that the secure denial of existence will mean that a DNSSEC-aware resolver, when asked to look up a name under .xa, for example, will always return NXDOMAIN.

> This draft describes an existing consequence of existing policy. It may be that Ed and Roy are the first ones to think about using them to anchor private namespaces, but in some sense any corner cases that need special handling today also needed special handling before this draft was written; we just didn't know it yet.

I suspect that a discussion of the DNSSEC issue is in-scope. :)