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

From: RFC Errata System <[email-masked]>
Date: Mon, 29 Nov 2021 11:07:11 -0800 (PST)

The following errata report has been submitted for RFC7686,
"The ".onion" Special-Use Domain Name".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6761

--------------------------------------
Type: Technical
Reported by: Peter van Dijk <[email-masked]>

Section: 2

Original Text
-------------
   5.  Authoritative DNS Servers: Authoritative servers MUST respond to
       queries for .onion with NXDOMAIN.

   6.  DNS Server Operators: Operators MUST NOT configure an
       authoritative DNS server to answer queries for .onion.  If they
       do so, client software is likely to ignore any results (see
       above).

Corrected Text
--------------
   5.  Authoritative DNS Servers: Authoritative servers MUST respond non-authoritatively to
       queries for names in .onion.

   6.  DNS Server Operators: Operators MUST NOT configure an
       authoritative DNS server to answer authoritatively to queries for names in .onion.  If they
       do so, client software is likely to ignore any results (see
       above).

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

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7686 (draft-ietf-dnsop-onion-tld-01)
--------------------------------------
Title               : The ".onion" Special-Use Domain Name
Publication Date    : October 2015
Author(s)           : J. Appelbaum, A. Muffett
Category            : PROPOSED STANDARD
Source              : Domain Name System Operations
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

---

From: Paul Wouters <[email-masked]>
Date: Mon, 29 Nov 2021 14:16:38 -0500 (EST)

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

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?

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.

Paul

---

From: Peter van Dijk <[email-masked]>
Date: Mon, 29 Nov 2021 20:25:19 +0100

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

?

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

---

From: Joe Abley <[email-masked]>
Date: Mon, 29 Nov 2021 14:48:14 -0500

Hi Peter,

> root servers) MUST respond non-authoritatively to queries for names in

Yes, the root servers respond with an authoritative name error for QNAMEs under .ONION. For them to do otherwise would arguably break the commitment they have made many times to serve precisely the root zone provided to them by the IANA.

I do see the problem that the proposed erratum is trying to address. However, I don't see much difference between clients of a resolver receiving a non-authoritative name error (e.g. a negative response from a root server that has been cached) vs. an authoritative name error (e.g. a negative response from a resolver that has been configured to answer in such a fashion). And I don't really see the point in any RFC suggesting that they can MUST operators into acting in any particular way, regardless of whether the servers they administer are acting as recursive or authoritative.

The idea of modifying the protocol to accommodate namespaces outside the DNS is causing me to throw up in my mouth a bit, to be honest. Perhaps the DNS could just concentrate on being the DNS and other namespaces can fight their own battles?

Joe

---

From: Paul Wouters <[email-masked]>
Date: Mon, 29 Nov 2021 14:54:38 -0500 (EST)

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

> root servers) MUST respond non-authoritatively to queries for names in

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 ?

> NXDOMAINs would be very confusing. In particular, resolvers would not

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 29 Nov 2021 19:56:04 +0000

> The idea of modifying the protocol to accommodate namespaces outside the DNS is causing me to throw up in my mouth a bit, to be honest. Perhaps the DNS could just concentrate on being the DNS and o…

This bit of wrong text originates with RFC 6761:
   5.  Authoritative DNS Servers:

       Are developers of authoritative domain name servers expected to
       make their implementations recognize these names as special and
       treat them differently?  If so, how?

   6.  DNS Server Operators:

       Does this reserved Special-Use Domain Name have any potential
       impact on DNS server operators?  If they try to configure their
       authoritative DNS server as authoritative for this reserved name,
       will compliant name server software reject it as invalid?  Do DNS
       server operators need to know about that and understand why?
       Even if the name server software doesn't prevent them from using
       this reserved name, are there other ways that it may not work as
       expected, of which the DNS server operator should be aware?

#5 explicitly talks about expectations on developers of authoritative *DNS* servers dealing with names that are not in the DNS. In retrospect, this was probably a mistake. (In retrospect, that mistake was probably caused by exhaustion from the discussion.)

Despite the nausea-inducing of Peter's suggestion, I think folks here need to deal with it, if for no other reason than RFC 6761 still being a standard.

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Mon, 29 Nov 2021 15:24:24 -0500

On 29 Nov 2021, at 14:56, Paul Hoffman <[email-masked]> wrote:

> [...]

6761 surely doesn't require any particular answers to those questions, thoug; it just requires the respective issues to be considered. Perhaps an alternative approach in this case is to update the answer to (5) to be "no" and update the answer to (6) accordingly?

Joe

---

From: "John R. Levine" <[email-masked]>
Date: 29 Nov 2021 18:19:18 -0500

>>>>      queries for .onion with NXDOMAIN.

I think this text is correct.

The whole point of .onion and other special use domain names is that they 
are resolved outside of the DNS.  RFC 6761 says they should be caught at 
a recursive server if not earlier.

If a query for a special use name, whether it's foo.onion or 
7.8.9.10.in-addr.arpa, leaks to an authoritative server, NXDOMAIN is the 
right answer.

R's,
John

> The idea of modifying the protocol to accommodate namespaces outside the DNS is causing me to throw up in my mouth a bit, to be honest. Perhaps the DNS could just concentrate on being the DNS and o…

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "libor.peltan" <[email-masked]>
Date: Tue, 30 Nov 2021 10:11:53 +0100

Hi John,
> 7.8.9.10.in-addr.arpa, leaks to an authoritative server, NXDOMAIN is 
> the right answer.
>
not really. First of all, in-addr.arpa. zone is normal part of DNS tree 
and various authoritative (depends for which zone) servers answer with 
proper delegations on it. Sure, 9.10.in-addr.arpa. is already an 
NXDOMAIN (according to auth servers for 10.in-addr.arpa. , but none 
others!) since 10.0.0.0/8 is a private address space.

On the other hand, onion. zone does not exist in DNS, therefore, the 
root servers (authoritative for ".") answer such queries as NXDOMAIN, 
whereas all other authoritative servers (for example, authoritative for 
zone example.com.) answer it with REFUSED, because it's out of their scope.

The requirement that all authoritative servers must answer onion. (or 
any subdomains) with NXDOMAIN does not make sense:
1) all (AFAIK) auth server implementations to date do not comply
2) would be an unnecessary exceptional behavior, possibly confusing things
3) would be probably in conflict with other DNS RFCs
4) it's not clear how such answers would be DNSSEC'ed

I suggest to remove any specific errcode (NXDOMAIN, REFUSED) mentions 
from such requirement. In the future, those errcodes and their names may 
be altered. I quite like the Peter's original proposal, though any 
wording can always be slightly improved. I don't dare to suggest any 
wording though.

Libor

---

From: Paul Vixie <[email-masked]>
Date: Tue, 30 Nov 2021 07:43:47 -0800

libor.peltan wrote on 2021-11-30 01:11:
> ...

a query for example.onion or even "onion" has no business being sent to 
an authority server to which this domain has not been delegated. so 
there is a right answer and it is generally not NXDOMAIN since that 
would be a knowledge signal (end to end) and the server can have no 
knowledge. obviously the root servers have and can signal such knowledge 
so NXDOMAIN would be the right answer from them.

the right answer is likewise not REFUSED since that's a policy signal 
and we won't be asking that server implementers hard code "onion" or 
other special-use names, nor that server operators configure such names. 
there are too many servers, and the list of special-use domains will 
change over time. a policy signal for special-use names cannot scale. 
this also rules out "don't answer at all" which is also a policy signal.

for any non-root server, an RD=0 question for example.onion should be 
answered with SERVFAIL. this is a condition signal, and the condition is 
"since i'm hearing this query, someone thinks i'm holding a delegation, 
and i'm not, so i might be lame for some zone, so the server (me, this 
authority server) has failed."

vixie

---

From: Robert Edmonds <[email-masked]>
Date: Tue, 30 Nov 2021 11:51:33 -0500

> That all said, I can certainly see that other texts than my suggestion

If the goal is to avoid mandating extra code paths in typical
authoritative servers, I would suggest something like the following
which narrowly answers only the questions asked in 6761 ("Are developers
of authoritative domain name servers expected to make their
implementations recognize these names as special and treat them
differently?  If so, how?"):

Original Text
-------------

Corrected Text
--------------
   5.  Authoritative DNS Servers: Authoritative servers SHOULD NOT
       recognize .onion names as special and MUST NOT treat queries for
       .onion names differently from other queries.

Splitting the "recognize ... treat" conjunction between "SHOULD NOT"
and "MUST NOT" would, for instance, allow an authoritative server to
log a warning message if an operator intentionally configured an
"onion." zone in the server.

A slight expansion of the text might read:

Corrected Text
--------------
   5.  Authoritative DNS Servers: Authoritative servers SHOULD NOT
       recognize .onion names as special and MUST NOT treat queries for
       .onion names differently from other queries.  By default,
       authoritative servers MUST NOT respond authoritatively to
       queries for .onion names.

The "By default" qualifier covers the case of a non-default
configuration (such as being configured to serve the root zone) where an
authoritative server would need to respond authoritatively for .onion
names.

-- 
Robert Edmonds

---

From: "libor.peltan" <[email-masked]>
Date: Tue, 30 Nov 2021 21:06:10 +0100

Hi Paul,
> answered with SERVFAIL. this is a condition signal, and the condition 
> is "since i'm hearing this query, someone thinks i'm holding a 
> delegation, and i'm not, so i might be lame for some zone, so the 
> server (me, this authority server) has failed."
>
from what I've observed so far, there seem to be a consensus among the 
authoritative servers out there :) They all answer out-of-bailiwick 
queries with REFUSED. I haven't met any that would say SERVFAIL or 
NOTAUTH or anything else. If you propose to normatively change this, 
with the idea that it would make more sense, then OK, but dunno if it 
has any benefit.

$ kdig @d.in-addr-servers.arpa. nonexistent-tld. +nordflag +noall +header
;; ->>HEADER<<- opcode: QUERY; status: REFUSED; id: 2834
;; Flags: qr; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0
$ kdig @a.ns.nic.cz. nonexistent-tld. +nordflag +noall +header
;; ->>HEADER<<- opcode: QUERY; status: REFUSED; id: 63681
;; Flags: qr; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0
$ kdig @a0.org.afilias-nst.info. nonexistent-tld. +nordflag +noall +header
;; ->>HEADER<<- opcode: QUERY; status: REFUSED; id: 45946
;; Flags: qr; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0

If you propose that onion. TLD (non-existing) and its subtree shall be 
an exception (for very all auth servers) and answered differently than 
other non-existent TLDs, then OK, but I simply don't like the idea.

Libor

---

From: Ted Lemon <[email-masked]>
Date: Tue, 30 Nov 2021 19:04:50 -0600

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.

On Tue, Nov 30, 2021 at 15:06 libor.peltan <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Paul Vixie <[email-masked]>
Date: Tue, 30 Nov 2021 17:10:33 -0800

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.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 1 Dec 2021 12:40:16 +1100

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.

Recursive servers are a different kettle of fish.

Mark

> On 1 Dec 2021, at 12:10, Paul Vixie <paul=[email-masked]> wrote:
> 
> 
> 
>> 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.
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]