W.C.A. Wijngaards via Unbound-users wrote: > It is not a particularly heavy root server load to mitigate, less code > is better and easier, the unblock-lan-zones statement is a frequently > asked question from our users. That said, we could add new code for > this (and .onion?).
Hi, Wouter: I would guess that the .test and .invalid zones are much less used in private networks than the .in-addr.arpa ones, so much less likely to be a FAQ. And most of the code to setup default empty zones has been written already. Here are the caching DNS considerations for the zones that Unbound currently doesn't handle: [ "test." ] Caching DNS servers SHOULD recognize test names as special and SHOULD NOT, by default, attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve test names. Instead, caching DNS servers SHOULD, by default, generate immediate negative responses for all such queries. This is to avoid unnecessary load on the root name servers and other name servers. Caching DNS servers SHOULD offer a configuration option (disabled by default) to enable upstream resolving of test names, for use in networks where test names are known to be handled by an authoritative DNS server in said private network. [ "invalid." ] 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. [ "onion." ] Caching DNS Servers: Caching servers, where not explicitly adapted to interoperate with Tor, SHOULD NOT attempt to look up records for .onion names. They MUST generate NXDOMAIN for all such queries. I notice the .onion Special-Use registration has a MUST while the other two only have SHOULDs. Probably there will be a few more additions to the Special-Use Domain Names registry, and even if they only generate a trivial amount of root server load now, that means it's easy to prevent them from becoming a problem later :-) -- Robert Edmonds edmo...@debian.org