Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
"libor.peltan" <libor.peltan@nic.cz> Tue, 30 November 2021 09:12 UTC
Return-Path: <libor.peltan@nic.cz>
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 C25083A118C for <dnsop@ietfa.amsl.com>; Tue, 30 Nov 2021 01:12:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.752
X-Spam-Level:
X-Spam-Status: No, score=-3.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.852, 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 lSnHZr3FOdRM for <dnsop@ietfa.amsl.com>; Tue, 30 Nov 2021 01:11:59 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 12B4D3A11A2 for <dnsop@ietf.org>; Tue, 30 Nov 2021 01:11:58 -0800 (PST)
Received: from [172.16.60.22] (81-18-208-198.static.chello.pl [81.18.208.198]) by mail.nic.cz (Postfix) with ESMTPSA id 9AD79140432 for <dnsop@ietf.org>; Tue, 30 Nov 2021 10:11:54 +0100 (CET)
Message-ID: <28d5129a-b543-7d65-6d91-c87b421bbe1c@nic.cz>
Date: Tue, 30 Nov 2021 10:11:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1
Content-Language: en-US
To: dnsop@ietf.org
References: <20211129190711.E4E9B36417@rfc-editor.org> <19c96ba9-a582-a24-b73-8e86a08c7b68@nohats.ca> <794d45f4b9093a019b94aee4730161d358b5ba79.camel@powerdns.com> <198228F8-F970-47E3-8690-5B13FB324231@hopcount.ca> <d3957532-33e8-f79f-a94f-8775948c886b@iecc.com>
From: "libor.peltan" <libor.peltan@nic.cz>
In-Reply-To: <d3957532-33e8-f79f-a94f-8775948c886b@iecc.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.102.4 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lpCptjTY8eyihvNRdtFV0aed9yI>
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 09:12:13 -0000
Hi John, > 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. > not really. First of all, in-addr.arpa. zone is normal part of DNS tree and various authoritative (depends for which zone) servers answer with proper delegations on it. Sure, 9.10.in-addr.arpa. is already an NXDOMAIN (according to auth servers for 10.in-addr.arpa. , but none others!) since 10.0.0.0/8 is a private address space. On the other hand, onion. zone does not exist in DNS, therefore, the root servers (authoritative for ".") answer such queries as NXDOMAIN, whereas all other authoritative servers (for example, authoritative for zone example.com.) answer it with REFUSED, because it's out of their scope. The requirement that all authoritative servers must answer onion. (or any subdomains) with NXDOMAIN does not make sense: 1) all (AFAIK) auth server implementations to date do not comply 2) would be an unnecessary exceptional behavior, possibly confusing things 3) would be probably in conflict with other DNS RFCs 4) it's not clear how such answers would be DNSSEC'ed I suggest to remove any specific errcode (NXDOMAIN, REFUSED) mentions from such requirement. In the future, those errcodes and their names may be altered. I quite like the Peter's original proposal, though any wording can always be slightly improved. I don't dare to suggest any wording though. Libor
- [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