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

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Dec 2021 16:06:45 -0500

On Tue, Nov 30, 2021 at 8:10 PM Paul Vixie <paul=
[email-masked]> wrote:

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

I have to confess that that really doesn't make sense to me. If you don't
return an answer, aren't you going to get hammered with retransmissions?

---

From: Paul Vixie <[email-masked]>
Date: Wed, 1 Dec 2021 13:22:14 -0800

Ted Lemon wrote on 2021-12-01 13:06:
> On Tue, Nov 30, 2021 at 8:10 PM Paul Vixie 
> <paul=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> I have to confess that that really doesn't make sense to me. If you 
> don't return an answer, aren't you going to get hammered with 
> retransmissions?

yikes.

s/fail to answer/signal a failure/

-- 
Sent from Postbox
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Warren Kumari <[email-masked]>
Date: Wed, 1 Dec 2021 19:02:11 -0500

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 <[email-masked]> 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=[email-masked]>
> 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.
> >
> > _______________________________________________
> > DNSOP mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dnsop
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: [email-masked]
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> 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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Dec 2021 00:55:47 +0000

On Dec 1, 2021, at 4:02 PM, Warren Kumari <[email-masked]> wrote:
> 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?

If we have the support of the Area Director to work on and finish this work, I'm definitely up for it, particularly if it doesn't bork the current queue of work in DNSOP.

--Paul Hoffman

---

From: George Michaelson <[email-masked]>
Date: Thu, 2 Dec 2021 11:42:05 +1000

Two instances of 'if' there.

Only one appears to me to be certain.

(Now we can disagree about which one)

G

On Thu, 2 Dec 2021, 10:56 am Paul Hoffman, <[email-masked]> wrote:

> > 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
> If we have the support of the Area Director to work on and finish this
> work, I'm definitely up for it, particularly if it doesn't bork the current
> queue of work in DNSOP.
>
> --Paul Hoffman_______________________________________________
> DNSOP mailing list
> [email-masked]

---

From: Bob Bownes -Seiri <[email-masked]>
Date: Wed, 1 Dec 2021 21:14:32 -0500

I’m all for addressing our past mistakes if we have consensus.   

> On Dec 1, 2021, at 19:56, Paul Hoffman <[email-masked]> wrote:
>