If you look up “onion”, you have revealed that the user is trying to use tOR, even if you haven’t revealed where they are going.
What’s the motivation behind this proposal? Sent from my iPhone > On Aug 16, 2019, at 05:30, Vladimír Čunát <vladimir.cunat+i...@nic.cz> wrote: > > > Hello, > > I've been wondering what's best to do around these TLDs: invalid, local, > onion, test. The RFCs say that resolvers SHOULD recognize them as special > and answer NXDOMAIN without any interaction with nameservers (by default). > What do you think about NOT following this "advice", subject to some > conditions that I explain below? > > 1. QNAME minimization (in the root at least), so that if e.g. foo.bar.test.. > query arrives and the cache is empty, the resolver only asks the root for > test. and the rest does not leak. > 2. RFC 8020 -style caching (in the root at least), so that we keep the goal > of reducing load on root servers. Note that this is subsumed by aggressive > caching (RFC 8198), which should work for the root zone in some commonly used > resolvers for about a year already (I believe: Unbound, BIND, Knot Resolver). > > This pair of conditions seem quite reasonable defaults regardless of special > TLDs, in which case I'd argue it's better not to special-case these four > TLDs. One advantage is that this allows supplying the denials with DNSSEC > proofs, which e.g. avoids problems in case the client is missing some of > these special cases and wants to validate. Well, that's arguably a > relatively unlikely combination, but my motivation is mainly that it feels > nicer to remove them :-) > > Reference RFCs for these TLDs, respectively: 6761.6.4.4, 6762.22.1.4, > 6762..2.4, 6761.6.2.4 > > --Vladimir > > > _______________________________________________ > 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
