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

Peter van Dijk <peter.van.dijk@powerdns.com> Mon, 29 November 2021 19:25 UTC

Return-Path: <peter.van.dijk@powerdns.com>
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 680F43A0803 for <dnsop@ietfa.amsl.com>; Mon, 29 Nov 2021 11:25:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 qxkG4P9qeJFt for <dnsop@ietfa.amsl.com>; Mon, 29 Nov 2021 11:25:24 -0800 (PST)
Received: from mx3.open-xchange.com (mx3.open-xchange.com [87.191.57.183]) (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 72E793A07FE for <dnsop@ietf.org>; Mon, 29 Nov 2021 11:25:24 -0800 (PST)
Received: from imap.open-xchange.com (imap.open-xchange.com [86.85.149.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPSA id A25536A0D6; Mon, 29 Nov 2021 20:25:20 +0100 (CET)
Received: from plato ([86.85.149.247]) by imap.open-xchange.com with ESMTPSA id tuyrJiAppWHFeQAA3c6Kzw (envelope-from <peter.van.dijk@powerdns.com>); Mon, 29 Nov 2021 20:25:20 +0100
Message-ID: <794d45f4b9093a019b94aee4730161d358b5ba79.camel@powerdns.com>
From: Peter van Dijk <peter.van.dijk@powerdns.com>
To: dnsop <dnsop@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>
Date: Mon, 29 Nov 2021 20:25:19 +0100
In-Reply-To: <19c96ba9-a582-a24-b73-8e86a08c7b68@nohats.ca>
References: <20211129190711.E4E9B36417@rfc-editor.org> <19c96ba9-a582-a24-b73-8e86a08c7b68@nohats.ca>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.5-1.1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ASbbfDiv4plLo0fjoCAYHmvVJsc>
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:25:29 -0000

On Mon, 2021-11-29 at 14:16 -0500, Paul Wouters wrote:
> On Mon, 29 Nov 2021, RFC Errata System wrote:
> 
> > Original Text
> > -------------
> >   5.  Authoritative DNS Servers: Authoritative servers MUST respond to
> >       queries for .onion with NXDOMAIN.
> > Corrected Text
> > --------------
> >   5.  Authoritative DNS Servers: Authoritative servers MUST respond non-authoritatively to
> >       queries for names in .onion.
> > The original text for 5 and 6 is conflicting. A name server cannot respond with NXDOMAIN (which is an authoritative answer) without having a zone configured to serve that NXDOMAIN from. Clearly the intent of the text is that clients will not find authoritative answers to .onion queries anywhere in the DNS.
> 
> 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?).

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.

?

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

That all said, I can certainly see that other texts than my suggestion
could make sense.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/