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 <libor.pel...@nic.cz> wrote: > Hi Paul, > > > > 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." > > > 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 > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop