On Mon, 29 Nov 2021, Peter van Dijk wrote:
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?).
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).
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.
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 ?
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.
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
