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