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 <ma...@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....@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: ma...@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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
