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

Paul Wouters <paul@nohats.ca> Mon, 29 November 2021 19:54 UTC

Return-Path: <paul@nohats.ca>
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 A741D3A0864 for <dnsop@ietfa.amsl.com>; Mon, 29 Nov 2021 11:54:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 yCWrN-qzAIid for <dnsop@ietfa.amsl.com>; Mon, 29 Nov 2021 11:54:45 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::85]) (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 C8C313A085F for <dnsop@ietf.org>; Mon, 29 Nov 2021 11:54:44 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4J2wzj0TQFz1rr; Mon, 29 Nov 2021 20:54:41 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1638215681; bh=d+GuaIAjhmBAf2frL70/PIevknR8kcyrHhdHr/SC/pE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=t2uTJyQRzQYc48mbaPn4lte69V7T9dQMeIfu94lW9Xhxo/2unQmaGWZyi8OwlM2ez OebXMm6YEFAHY4BcYSuUXm7JkKdBNj5v48SuFT4/JY0rWNL50XrLGX9wT54E0Q9LrJ 636AT2DQpyVXrPudQxPDr46jk+cgfYDyLKKNkGYQ=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id xNismqCtOAD9; Mon, 29 Nov 2021 20:54:39 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 29 Nov 2021 20:54:39 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id B4459181800; Mon, 29 Nov 2021 14:54:38 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B10AA1817FF; Mon, 29 Nov 2021 14:54:38 -0500 (EST)
Date: Mon, 29 Nov 2021 14:54:38 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: Peter van Dijk <peter.van.dijk@powerdns.com>
cc: dnsop <dnsop@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>
In-Reply-To: <794d45f4b9093a019b94aee4730161d358b5ba79.camel@powerdns.com>
Message-ID: <b6e7c32-671-cd31-a0c6-4efa7f67c4ea@nohats.ca>
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; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/dyk5Dv8U5FOTkNlhufTOMeYhkxg>
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 19:54:50 -0000

On Mon, 29 Nov 2021, Peter van Dijk wrote:

>> 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?).

Right, But it is not different for different domains. Note though that
for example .com nameservers return NOERROR and .ca nameservers return
REFUSED but the difference in behaviour is the same for any non-existing
TLD (eg not "onion" specific).

> 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.

That is I guess because we are talking about the "real authoritative
servers" versus "a random not for the root authoritative nameserver".

Maybe the term "authoritative nameserver" in this context is not the
best to use ?

>> So I agree the Original text has an issue. I haven't been convinced yet
>> the suggested solution is the right one. After all, we are talking about
>> "special domains", so perhaps it does warrant an NXDOMAIN despite that
>> normally being used only within an authoritative context.
>
> 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.

Well, proper resolvers would never these servers. Perhaps it should say
"authoritative servers for the root MUST return NXDOMAIN". All other
authoritative servers should not have the .onion site configured as
authoritative zone, and should handle the query as they do for other
domains they are not configured for" ?

But that's kinda wordy. I'm sure others can do better.

Paul