Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-12.txt

Christian Huitema <huitema@huitema.net> Sun, 25 August 2019 18:50 UTC

Return-Path: <huitema@huitema.net>
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 243741200B4 for <dnsop@ietfa.amsl.com>; Sun, 25 Aug 2019 11:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 Up3qNqT1lIkj for <dnsop@ietfa.amsl.com>; Sun, 25 Aug 2019 11:50:46 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 2081D120026 for <dnsop@ietf.org>; Sun, 25 Aug 2019 11:50:46 -0700 (PDT)
Received: from xse58.mail2web.com ([66.113.196.58] helo=xse.mail2web.com) by mx105.antispamcloud.com with esmtp (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1i1xb6-0004E1-CX for dnsop@ietf.org; Sun, 25 Aug 2019 20:50:43 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 46GkjV5lVSz4sHG for <dnsop@ietf.org>; Sun, 25 Aug 2019 11:50:38 -0700 (PDT)
Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1i1xb4-00048g-M3 for dnsop@ietf.org; Sun, 25 Aug 2019 11:50:38 -0700
Received: (qmail 4502 invoked from network); 25 Aug 2019 18:50:38 -0000
Received: from unknown (HELO [192.168.1.108]) (Authenticated-user:_huitema@huitema.net@[172.58.43.232]) (envelope-sender <huitema@huitema.net>) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for <dnsop@ietf.org>; 25 Aug 2019 18:50:37 -0000
To: Paul Wouters <paul@nohats.ca>, dnsop <dnsop@ietf.org>
References: <156659505868.25095.3137353213257219967@ietfa.amsl.com> <CAAedzxoWnN0CEp53_MO0Ct-iX-91PD46gj9TEJSKL-KArZoGkw@mail.gmail.com> <alpine.LRH.2.21.1908251137300.24518@bofh.nohats.ca>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <f43360a6-5882-7f42-4649-01202067259c@huitema.net>
Date: Sun, 25 Aug 2019 11:50:38 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <alpine.LRH.2.21.1908251137300.24518@bofh.nohats.ca>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.196.58
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.58/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.58/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0ZMJr/TGkEWvNJbVmORegSypSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDwMrZRqsFCjz8E32pWQuD5pj9 EvBvwu01uVCaGVBWGqsb4KyqtyM4Bvb8ueZuA9/h2rBNMmEsKEibQwSU1xBeOHButNDpi1WUXRkr He1vFsZaZad0VL/QynhFAlbT36L827A0We4Px3ZtIg26LaXLKAZ6weYgSzquK2hxskqXvy8woCTx LKweTbuJ+19zsyHVGVmhMAaQ/AfCRwRe7yHm5oY+NYmsSGn+svMubxnbgm1cr18FZBEPC2/c16Xd 7sC9aC4xteE1WLqGS9YoqrsZ2DyteN0e+ECCv9/f+GPymkgDVo7QBKA4MctKq4ifYPcXFRL2K3LA EfDXVOdt7wDbuhdxf5Dwg9wMBX5ckCo48ayVGvgdM/14NhEhsQ0jllqEE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ilWEbX+OBfQvZ a2Z4uSB28NLsVfldh9QC5asKXSds+jxTKJeG0cAP2I16UCM8WsZcxzUSPCqkIyyoDZ72hv/Vgjz0 lSfuxANzRU5MAZzTOSGBYfVOjkou/1Xrs00iK3J96vKY2AXNZGS5G93aGyH8MqMNONNOB63tZ91H 4Bn0Oix6KWDRtf6HJAeNdm4/n62X9JxMPnetLBJMh51NiRRoHICTRKq/jXzEb6kbqZCiyJojmiK7 x42VjdzChZMe6O/DiWiiIzuXMTE3l4bIsk+O50sSb7DLwUyExrL04iJcS+/F08QV3No+S2msRDep v5w/kkG0v17AmegcpQ0tml/sN9lmMy/o83jVXTcfb9k0nLWblJy7uxV6dw8jzlsaNZe6hynMJcjx DydxsJEju76A7X1QIVydqXpZ6MHhiKws9Iiut28r9wo4SqUIg8Yh9hAM0n3LLzx/F2gT3wl8JQJv Bho=
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-kVkKQnfX7NdzmcfQZg5cH3uD2E>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-12.txt
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: Sun, 25 Aug 2019 18:50:48 -0000

On 8/25/2019 9:21 AM, Paul Wouters wrote:
>
>
> On Fri, 23 Aug 2019 at 14:18, <internet-drafts@ietf.org>; wrote:
>
>>       A New Internet-Draft is available from the on-line
>> Internet-Drafts directories.
>>       This draft is a work item of the Domain Name System Operations
>> WG of the IETF.
>>
>>               Title           : The ALT Special Use Top Level Domain
>>               Authors         : Warren Kumari
>>                                 Andrew Sullivan
>>               Filename        : draft-ietf-dnsop-alt-tld-12.txt
>>               Pages           : 11
>>               Date            : 2019-08-23
>
> I am not a big fan, and I don't think many alternative projects will
> pick .alt even if just for cosmetic reasons, but I don't have any
> reason to object either. It's cheap and if it remains unused, that
> is okay.
>
> And one advantage is that if people want to claim a TLD, we can point
> them to .alt, so it should decrease the pressure on using RFC 6761 which
> will prevent more bureaucratic time used up in dnsop meetings.

The expected advantage is that any resolver could respond to a DNS query
for names under .alt with an NX domain error code, unless they have
specific code to handle the 2LD under .alt. This provides a semantic of
"won't leak by default", which is nice. This is reasonably well
explained in section 3.1, and is indeed a significant difference from
constructs like ".home.arpa", in which the name leaks by default unless
the resolver has special knowledge of the 2LD.

On the other hand, resolvers should by now have implemented a filter for
".local" similar from the one planned for ".alt". Yet leaked requests
for names in ".local" represent over 3% of requests sent to the root, so
there are clearly a bunch of resolvers out there that did not bother
with RFC 6761. I would not bet that these same resolvers would program
anything special for .alt.

>
> Has Issues:
>
> I think the document is contradicting and not clear at all on what to do
> with queries. It mixes up "should not be resolved" with "should not be
> handled specially" based on some assumed difference of stub resolver and
> resolver and Caching Server. On top of that, a stub resolver and caching
> server are likely to use the same underlying library calls, so asking
> for different behaviour is unrealistic for implementors.
>
> It would also be good to stick to the DNS Terminology, which I think it
> does not do with the list of different players in the resolving chain.
>
>
>
>     Writers of name resolution APIs and libraries which operate in
>     the DNS context should not attempt to look these names up in the
>     DNS.
>
> vs:
>
>     Caching DNS servers SHOULD NOT recognize these names as special
>
> These two cannot both be true. The latter is also really false since the
> ..alt is marked as Special Domain, so caching resolvers _should_
> handle it
> specially.

+1

I find it rather confusing that the advice to implementers is in the
IANA section.

I understand that RFC 6761 prescribes a checklist, but I would rather
see a "deployment considerations" section of its own, and then quote
that section from the RFC 6761 checklist.

The deployment section should basically say something like "DNS Servers
MUST recognize the .alt names as special and reply to any request with a
No Such Domain error." This has two rationales:

- It ensures that requests that are meant to be private to a specific
domain cannot be observed on the global Internet, which is good for privacy.

- It ensures that requests that are meant for a different resolution
method do not create extra load for DNS servers after the first
resolver, which reduces operation overhead.

It is pretty clear that not all servers will be updated overnight. By
default, the requests will progress all the way to the root, which will
issue an NX Domain response, just like it does for requests to .local or
.home today. If recursive resolvers cache the negative responses, they
will end up with an "almost correct" behavior.

The main point of contention is probably DNSSEC. Recursive resolvers
that recognize ".alt" as special can issue an NX Domain response, but
secure denial requires caching a negative response signed by the root.
What if the client requires DNSSEC? Should there be some guidance in the
deployment considerations?

>
> Likely the best advise to implementors is to use a Query Minimization
> based answer of the non-existence of .alt that prevents further leakage
> of the specific name within .alt that was used. I would like to see this
> very prominently stated instead of the scattered bullet list on what to
> do.
>
>     Authoritative DNS servers SHOULD NOT recognize these names as
>     special
>
> Why not? I think they should refuse to load any .alt zones. It is
> supposed to be Special Use for non-DNS protocols. Why let it be abused
> as "real" DNS zones? Do we want to support "almost DNS like" protocols
> that would re-use authoritative DNS server code? That seems very
> dangerous.

Yes. Authoritative servers should never load anything in the .alt zone,
period. Specifically, root servers should not have any entry for .alt,
ensuring that any request generates an error response. That should be
explained in a well formed deployment consideration section.

-- Christian Huitema