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

Warren Kumari <warren@kumari.net> Thu, 02 December 2021 00:02 UTC

Return-Path: <warren@kumari.net>
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 75AF33A0D20 for <dnsop@ietfa.amsl.com>; Wed, 1 Dec 2021 16:02:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net
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 r4pCIhIhJVvU for <dnsop@ietfa.amsl.com>; Wed, 1 Dec 2021 16:02:50 -0800 (PST)
Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF143A0D16 for <dnsop@ietf.org>; Wed, 1 Dec 2021 16:02:50 -0800 (PST)
Received: by mail-il1-x129.google.com with SMTP id h16so26423946ila.4 for <dnsop@ietf.org>; Wed, 01 Dec 2021 16:02:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pjWi5Uasfaa0EGb4GBv60xwvTjkx+Ez+AirH3TXiCm8=; b=SAGvta7OKb4urE5WLqJBaJSOSD5bRg+EMC7IQPdjsSf2+Wmw625wpvuC/kzW0+43Jv v6x+n63BKvIlAmYXpxxTtpzQCLXYztr7z//gzPA+8YfHbYAPaGDJDBjDd+pfv2kgYDNn 7XJtPQzrDzhvCzAnMWzocNyHbTgzIR4Jja43gjKIrYbowcpCrqYN9wMkZJNLCjbQQs1A fYyOaASCKvwzqPrX/rfNCQWm0C1VECLjfA7zH/UEnIpaZAZ6B6hn8yfZeLsizn+bCJ1U n3AE3XjQub1gbAx5kHkW2BL6tVa1kgSdsqCtA/GdYpqMeHdxKnTSDGnVvKDxLDvMUdJK ckAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pjWi5Uasfaa0EGb4GBv60xwvTjkx+Ez+AirH3TXiCm8=; b=cn84RL6grdQnco6Uo4YEIIdG/rZPoJBEfqHqSwzIOLDqnFqNRHjmfLVI/QQgERb4mB iClU3TL0ou2GZiZlqJggJiMucK7SZj2LsmZMlvF3M64S39tP62PCI2VlzDRxU4gzlXyW Kfp6xX6SBEk+ZPYTZ62Qn81PZ9mIZ83Oq8P7arbONPn6WQijJrxtm8BWsGuyDDUrG/sq Z378MgsLkhZDbpqFFC5MwcalzXwWtg5q9niq3uraoV8xYZmUKUdUl+v9EfpEK/TeahDF KRjH2AG+h58yut4UM6ER45lpMBceWp2tSFLH4ciAGQn3pJEkcOpKHHu9+/bHKm1wKyua Sc0Q==
X-Gm-Message-State: AOAM531u1fiosMj5mwgHGpAekhSqI5rE6kehgKs+10uMhKjNSRfLIlNB QJwp8/Y481tb5h+NVvctHI9Ws1LDosHMdHyJ7prglA==
X-Google-Smtp-Source: ABdhPJw4sOwiIbKczV5gTmuTFJIGeJhTrSAbTodfnBmu2sVBBqSP2YW0c+lflzxl0UKwcfLGr5lvIejCdF4kiTzhVBQ=
X-Received: by 2002:a05:6e02:b22:: with SMTP id e2mr12026249ilu.304.1638403367586; Wed, 01 Dec 2021 16:02:47 -0800 (PST)
MIME-Version: 1.0
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> <28d5129a-b543-7d65-6d91-c87b421bbe1c@nic.cz> <d666dd21-10b2-c8d2-16b8-c5c723712613@redbarn.org> <9dacfae6-0dca-8687-466a-6ce20b7d9e88@nic.cz> <CAPt1N1nei=QUcXji9XqD5q75XQnNYkn5ZEWMoJs6k_OahdOSUA@mail.gmail.com> <b149b55e-1385-9907-0695-f780b469464c@redbarn.org> <AEE90C9C-0575-44E3-9D51-1B0FCE7D484F@isc.org>
In-Reply-To: <AEE90C9C-0575-44E3-9D51-1B0FCE7D484F@isc.org>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 1 Dec 2021 19:02:11 -0500
Message-ID: <CAHw9_i+xcQJgsC=E4Ga+JL-4eR+_Wzkb-G4bgxEH1Ta-xOCSDA@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Cc: Paul Vixie <paul=40redbarn.org@dmarc.ietf.org>, "libor.peltan" <libor.peltan@nic.cz>, dnsop@ietf.org, Ted Lemon <mellon@fugue.com>
Content-Type: multipart/alternative; boundary="000000000000b9652705d21e820b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PYdIrrDysIo5aLrIY19COp9iipE>
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: Thu, 02 Dec 2021 00:02:56 -0000

draft-ietf-dnsop-onion-tld
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-onion-tld-01>


On Tue, Nov 30, 2021 at 8:40 PM Mark Andrews <marka@isc.org> wrote:

> Authoritative servers should take NO SPECIAL BEHAVIOUR for .onion.
>
> The default behaviour of an authoritative server is fine be it REFUSED,
> NOTAUTH, NXDOMAIN (when they have a copy of the root zone) or a referral
> to the root.
>
>
I suspect that I'm about to make myself fairly unpopular here...

I personally agree with the above, but note that 6761 says things like (e.g
for .invalid):
"   4.  Caching DNS servers SHOULD recognize "invalid" names as special
       and SHOULD NOT attempt to look up NS records for them, or
       otherwise query authoritative DNS servers in an attempt to
       resolve "invalid" names.  Instead, caching DNS servers SHOULD
       generate immediate NXDOMAIN responses for all such queries.  This
       is to avoid unnecessary load on the root name servers and other
       name servers.

   5.  Authoritative DNS servers SHOULD recognize "invalid" names as
       special and handle them as described above for caching DNS
       servers.
"
It would be nice to have a succinct answer as to why the behavior for
.onion is different. I have a horrible feeling that this succinct answer is
"Well, let's change that when we write the much promised rfc6761bis", but
perhaps it is actually "Well, .invalid in a DNS name and so we can add it
to locally-served zones. .onion isn't a DNS name and so we cannot..." (note
that I'm using "a DNS name" in a hand-wavey way...

If we do think that .onion is different to .invalid (or we don't want to
fix the above for .invalid in the -bis), then:
OLD:
5.  Authoritative DNS Servers: Authoritative servers MUST respond to
       queries for .onion with NXDOMAIN.

NEW:
5. Authoritative DNS Servers: Authoritative servers SHOULD NOT recognize
these
       names as special and SHOULD NOT treat them differently.

(I'm stealing the above "SHOULD NOT recognize..." text from other bits of
RFC6761 for consistency).

Whatever the case (and here is where I potentially make myself unpopular),
we have a principle that "Errata are meant to fix "bugs" in the
specification and should not be used to change what the community meant
when it approved the RFC." -- I **think** that the consensus when
published was that there should not be special handling by authoritative
servers, but there was actually a fair bit of discussion on this point, and
I haven't (yet) found clear evidence of consensus.

As I'm sure y'all remember, there were many, many emails on this whole
topic, and some of them became a little, um, fraught. I've done a fair bit
of archeology and the best / clearest I've found so far is Ted Lemon's
http://mailarchive.ietf.org/arch/msg/ietf/qmR4eRTwaXoeYTbnWZRE-Ixj_-w .
Sadly, this seems to be somewhat wrapped up in the discussions around
getting an insecure delegation, and then the thread morphs into other
discussions.  So, while I agree that there shouldn't be special handling by
auths, or if there is special handling, it should be of the same form as
the handling of e.g .invalid / .test (basically, locally-served-zone), I'd
really like a clear thing that I can point to that says that that was the
consensus then...

I will continue to dig through mail, but would appreciate it if someone
could point me at where we made the decision...


The larger issue is that this whole "Special Use Domain Names / RFC6761 /
Alternative Naming Systems /  Explicit Internet Naming System (remember
ENAME?!) / Private Naming / Alternative Naming Systems / Multiple
Namespaces / What's in a name" topic continues to fester.
We published RFC 8244 - "Special-Use Domain Names Problem Statement" (
https://datatracker.ietf.org/doc/html/rfc8244) in 2017. This document
provides a list of 21+ known issues with SUDNs, and that doesn't even cover
"other" namespaces.
The reason that RFC8244 is a "problem statement" was so that we could
document the problems AND THEN FIX THEM!
Sadly, by the time we had published this, we were all so sick and tired of
the topic that we no longer had the stomach to do anything about this, and
so it continues to lurk at us (and mix other metaphors too!)

I think that enough time has now passed that we might be strong enough to
address this whole topic again and start fixing the identified issues as
well as tackling the larger "what is a namespace, and how do multiple
resolution systems co-exist?!" topic.

Who's with me? It promises to be an exciting journey -- "Once more unto the
breach, dear friends, once more"...

W


> Recursive servers are a different kettle of fish.
>
> Mark
>
> > On 1 Dec 2021, at 12:10, Paul Vixie <paul=40redbarn.org@dmarc.ietf.org>
> wrote:
> >
> >
> >
> > Ted Lemon wrote on 2021-11-30 17:04:
> >> I don’t see how any answer from an authoritative server other than
> REFUSED really makes sense for a domain for which that server is not
> authoritative. It hasn’t failed. It’s been asked a bogus question. It
> doesn’t make sense for it to theorize that it might be misconfigured.
> >
> > i only use REFUSED if the same question from some other query source (by
> IP) or signed differently (with TSIG or SIG(0)) could possibly work. for
> out-of-authority requests, the server must fail to answer.
> >
> > _______________________________________________
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra