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