Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)

"John R. Levine" <johnl@iecc.com> Mon, 29 November 2021 23:19 UTC

Return-Path: <johnl@iecc.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 D4EF13A0B10 for <dnsop@ietfa.amsl.com>; Mon, 29 Nov 2021 15:19:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=iecc.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 3LKHDiMKjeUg for <dnsop@ietfa.amsl.com>; Mon, 29 Nov 2021 15:19:23 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 2991E3A0B09 for <dnsop@ietf.org>; Mon, 29 Nov 2021 15:19:22 -0800 (PST)
Received: (qmail 16546 invoked from network); 29 Nov 2021 23:19:20 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=409b.61a55ff8.k2111; bh=PCf2mRXRHHGK8BZFPllt4yOGEewq5eqSSeo2cbirWS8=; b=KCoqdT2ap704v0C+RKdAULcEE+eVBkypuZNWGaFC3czKnV1dYLvjApl2USd8kCRDMdcwCA9l6Obr/KLUt6GFubLsNJaDnn1dWDtIS2YJ/xNHyW3cvUQT566KsgHE8sDV2g03XUWIddOF8FYk1jJQoQbh0fXTV0AcH4fQwdYZGzGthrhHRb+8CRC6bBaxe0YFxxMjI2m/S9RtKi39xCZVb5AbIy508Mwnouo8lpPbLQPPo6iv8GrrfP7BdSO55AjFkX2EZViAXmf1a4rxDIN8Hldiv9+q5QCGVgldjk62okibxJiKBdVtBfVuRPjFo33T8fwnHCQUNNjjiDF6CKWKbw==
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 29 Nov 2021 23:19:19 -0000
Received: by ary.qy (Postfix, from userid 501) id 4B20A30C177B; Mon, 29 Nov 2021 18:19:18 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id B07D430C175D; Mon, 29 Nov 2021 18:19:18 -0500 (EST)
Date: Mon, 29 Nov 2021 18:19:18 -0500
Message-ID: <d3957532-33e8-f79f-a94f-8775948c886b@iecc.com>
From: "John R. Levine" <johnl@iecc.com>
To: Joe Abley <jabley@hopcount.ca>, Peter van Dijk <peter.van.dijk@powerdns.com>
Cc: dnsop <dnsop@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>
X-X-Sender: johnl@ary.qy
In-Reply-To: <198228F8-F970-47E3-8690-5B13FB324231@hopcount.ca>
References: <20211129190711.E4E9B36417@rfc-editor.org> <19c96ba9-a582-a24-b73-8e86a08c7b68@nohats.ca> <794d45f4b9093a019b94aee4730161d358b5ba79.camel@powerdns.com> <198228F8-F970-47E3-8690-5B13FB324231@hopcount.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7KMbGCA5mzaBhLRuy_NfhRhbhgY>
Subject: Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
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: Mon, 29 Nov 2021 23:19:29 -0000

>>>>  5.  Authoritative DNS Servers: Authoritative servers MUST respond to
>>>>      queries for .onion with NXDOMAIN.

I think this text is correct.

The whole point of .onion and other special use domain names is that they 
are resolved outside of the DNS.  RFC 6761 says they should be caught at 
a recursive server if not earlier.

If a query for a special use name, whether it's foo.onion or 
7.8.9.10.in-addr.arpa, leaks to an authoritative server, NXDOMAIN is the 
right answer.

R's,
John

>>>> Corrected Text
>>>> --------------
>>>>  5.  Authoritative DNS Servers: Authoritative servers MUST respond non-authoritatively to
>>>>      queries for names in .onion.
>>>> The original text for 5 and 6 is conflicting. A name server cannot respond with NXDOMAIN (which is an authoritative answer) without having a zone configured to serve that NXDOMAIN from. Clearly the intent of the text is that clients will not find authoritative answers to .onion queries anywhere in the DNS.
>>>
>>> The corrected text does not describe what to return though. I guess the
>>> text implies REFUSED, but perhaps the WG reasoned this was not good as
>>> it would lead to more queries to other servers or instances of the
>>> authoritative server set?
>>
>> Yes, it implies REFUSED. I was unsure REFUSED was standardised, or
>> whether it is still a convention that almost all auths happen to
>> follow. REFUSED would indeed lead to resolvers trying other auths
>> (although that seems a bit theoretical - where did the resolver even
>> come up with the idea to ask a bunch of auths about .onion names?).
>>
>> I also now realise that the root servers do not honour my new text, and
>> their behaviour -is- correct, so perhaps:
>>
>> 5. Authoritative DNS Servers: Authoritative servers (other than the
>> root servers) MUST respond non-authoritatively to queries for names in
>> .onion.
>
> Yes, the root servers respond with an authoritative name error for QNAMEs under .ONION. For them to do otherwise would arguably break the commitment they have made many times to serve precisely the root zone provided to them by the IANA.
>
> I do see the problem that the proposed erratum is trying to address. However, I don't see much difference between clients of a resolver receiving a non-authoritative name error (e.g. a negative response from a root server that has been cached) vs. an authoritative name error (e.g. a negative response from a resolver that has been configured to answer in such a fashion). And I don't really see the point in any RFC suggesting that they can MUST operators into acting in any particular way, regardless of whether the servers they administer are acting as recursive or authoritative.
>
> The idea of modifying the protocol to accommodate namespaces outside the DNS is causing me to throw up in my mouth a bit, to be honest. Perhaps the DNS could just concentrate on being the DNS and other namespaces can fight their own battles?
>
>
> Joe

Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly