Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
Robert Edmonds <edmonds@mycre.ws> Tue, 30 November 2021 16:51 UTC
Return-Path: <edmonds@mycre.ws>
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 10A4B3A0BEB for <dnsop@ietfa.amsl.com>; Tue, 30 Nov 2021 08:51:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 DpUsaH8nfoK8 for <dnsop@ietfa.amsl.com>; Tue, 30 Nov 2021 08:51:36 -0800 (PST)
Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E26D3A0BE9 for <dnsop@ietf.org>; Tue, 30 Nov 2021 08:51:36 -0800 (PST)
Received: by chase.mycre.ws (Postfix, from userid 1000) id EB99E12C1127; Tue, 30 Nov 2021 11:51:33 -0500 (EST)
Date: Tue, 30 Nov 2021 11:51:33 -0500
From: Robert Edmonds <edmonds@mycre.ws>
To: Peter van Dijk <peter.van.dijk@powerdns.com>
Cc: dnsop <dnsop@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>
Message-ID: <YaZWlevhnYT1ABCu@mycre.ws>
References: <20211129190711.E4E9B36417@rfc-editor.org> <19c96ba9-a582-a24-b73-8e86a08c7b68@nohats.ca> <794d45f4b9093a019b94aee4730161d358b5ba79.camel@powerdns.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <794d45f4b9093a019b94aee4730161d358b5ba79.camel@powerdns.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/tpULhyHguU_DFJVdasHTmgDZpu4>
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: Tue, 30 Nov 2021 16:51:38 -0000
Peter van Dijk wrote: > I don't think we should be prescribing extra code paths in > authoritative servers in this document, and I think non-authoritative > NXDOMAINs would be very confusing. In particular, resolvers would not > believe them anyway. > > That all said, I can certainly see that other texts than my suggestion > could make sense. If the goal is to avoid mandating extra code paths in typical authoritative servers, I would suggest something like the following which narrowly answers only the questions asked in 6761 ("Are developers of authoritative domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?"): Original Text ------------- 5. Authoritative DNS Servers: Authoritative servers MUST respond to queries for .onion with NXDOMAIN. Corrected Text -------------- 5. Authoritative DNS Servers: Authoritative servers SHOULD NOT recognize .onion names as special and MUST NOT treat queries for .onion names differently from other queries. Splitting the "recognize ... treat" conjunction between "SHOULD NOT" and "MUST NOT" would, for instance, allow an authoritative server to log a warning message if an operator intentionally configured an "onion." zone in the server. A slight expansion of the text might read: Corrected Text -------------- 5. Authoritative DNS Servers: Authoritative servers SHOULD NOT recognize .onion names as special and MUST NOT treat queries for .onion names differently from other queries. By default, authoritative servers MUST NOT respond authoritatively to queries for .onion names. The "By default" qualifier covers the case of a non-default configuration (such as being configured to serve the root zone) where an authoritative server would need to respond authoritatively for .onion names. -- Robert Edmonds
- [DNSOP] [Technical Errata Reported] RFC7686 (6761) RFC Errata System
- Re: [DNSOP] [Technical Errata Reported] RFC7686 (… Paul Wouters
- Re: [DNSOP] [EXT] Re: [Technical Errata Reported]… Peter van Dijk
- Re: [DNSOP] [EXT] Re: [Technical Errata Reported]… Joe Abley
- Re: [DNSOP] [EXT] Re: [Technical Errata Reported]… Paul Wouters
- Re: [DNSOP] [EXT] Re: [Technical Errata Reported]… Paul Hoffman
- Re: [DNSOP] [EXT] Re: [Technical Errata Reported]… Joe Abley
- Re: [DNSOP] [EXT] Re: [Technical Errata Reported]… John R. Levine
- Re: [DNSOP] [EXT] Re: [Technical Errata Reported]… libor.peltan
- Re: [DNSOP] [EXT] Re: [Technical Errata Reported]… Paul Vixie
- Re: [DNSOP] [EXT] Re: [Technical Errata Reported]… Robert Edmonds
- Re: [DNSOP] [EXT] Re: [Technical Errata Reported]… libor.peltan
- Re: [DNSOP] [EXT] Re: [Technical Errata Reported]… Ted Lemon
- Re: [DNSOP] [EXT] Re: [Technical Errata Reported]… Paul Vixie
- Re: [DNSOP] [EXT] Re: [Technical Errata Reported]… Mark Andrews
- Re: [DNSOP] [EXT] Re: [Technical Errata Reported]… Ted Lemon
- Re: [DNSOP] [EXT] Re: [Technical Errata Reported]… Paul Vixie
- Re: [DNSOP] [EXT] Re: [Technical Errata Reported]… Warren Kumari
- Re: [DNSOP] [EXT] Re: [Technical Errata Reported]… Paul Hoffman
- Re: [DNSOP] [EXT] Re: [Technical Errata Reported]… George Michaelson
- Re: [DNSOP] [EXT] Re: [Technical Errata Reported]… Bob Bownes -Seiri
- Re: [DNSOP] [Technical Errata Reported] RFC7686 (… Peter van Dijk
- Re: [DNSOP] [Technical Errata Reported] RFC7686 (… John Levine