Re: rfc6761 compliance
On Tue, 22 Sep 2015, Robert Edmonds via Unbound-users wrote: 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?). Here are the caching DNS considerations for the zones that Unbound currently doesn't handle: [ "test." ] [ "invalid." ] [ "onion." ] While I don't see much harm in test and valid, there is a stronger case for onion not to leak out. I hope upstream will block it per default. If not, I might add a conf file to do so in the default unbound configuration for Fedora. Paul
Re: rfc6761 compliance
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
Re: rfc6761 compliance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Robert, Andreas, On 11/09/15 17:54, Robert Edmonds via Unbound-users wrote: > A. Schulze via Unbound-users wrote: >> Hello, >> >> the RFC 6761 give some advise how caching DNS servers SHOULD >> handle queries for reserved domains. Mostly it say "do not send >> queries to the root name servers" >> >> ... point 4 in any case ... >> http://tools.ietf.org/html/rfc6761#section-6.2 ( domain "test." >> ) http://tools.ietf.org/html/rfc6761#section-6.4 ( domain >> "invalid." ) >> >> looks like unbound don't follow that "SHOULD" recommendations. it >> this a miss-configuration on my side ? > > I am also curious why these domains are not handled specially by > Unbound as RFC 6761 recommends. Interestingly, BIND has the exact > same behavior as Unbound for these two domains. (See > https://bugs.debian.org/55032 for details.) > 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?). Best regards, Wouter -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWAP6FAAoJEJ9vHC1+BF+N0acP/izkFs3pdDv0OMXqIC2p6I7e Qfbo+FfHawVfA8u58AaWJIcO7mdCiSDmzj7vzr3pnTWvdIuOZRKNuZphtzTwKuuV H/+bB9oeFwXef61uX3hepjihKmpoCY7l/UOhDlLRVIyQvYV5hmN1HJ3yHRkIXXCH lNxl0i4upEF7pBtVvnhl9jr/mYmPz4+6T7yKs4FV63RaQAXezRJyt/qmpBXDdvuf it82RdF0HmWNXegMiW7oV3iwZW5xrOpHYUPmbhYw4t85y1VkOHz4lbpdVZL9lDCs 33SySG1fgXSRe5LS4MHWnUJVTE1byAkZ1Hl5nK6D5MvEt9B/3utYiLjKDmBQrCLP bGsFesWcGf0OzA3OyVYgS24Vhs9pSJhzTke7B1g6Tmxc5PSZhUJS6STE6SWlI6XL 9Crd8VKyb4pNwq44ZHMzwu90vCshLAsOaKWpdj4iq00l8zxudZiGRmBj7Lz3qTRv ui/U9RtDVx2QQ+EyArgrzynrTTlg7LJan80/yhH7qohfRKffcy8DyqLKchujt+Wf RkhxrJtN/DlZvWqnqSGKAXt1Ah7fHnyqmbNuuPh82eiADyD9tw9uJt3K9bbiVUyN 1OdfgfbOK+xs/gxWUHHj4kfwhFR1DSGqs/eZoc5YFfJIDja/zGT8ftnZ/rmy9ScA bKFLzSWsptRIQKkH45TH =xeKM -END PGP SIGNATURE-
Re: rfc6761 compliance
A. Schulze via Unbound-users wrote: > Hello, > > the RFC 6761 give some advise how caching DNS servers SHOULD > handle queries for reserved domains. Mostly it say > "do not send queries to the root name servers" > > ... point 4 in any case ... > http://tools.ietf.org/html/rfc6761#section-6.2 ( domain "test." ) > http://tools.ietf.org/html/rfc6761#section-6.4 ( domain "invalid." ) > > looks like unbound don't follow that "SHOULD" recommendations. > it this a miss-configuration on my side ? I am also curious why these domains are not handled specially by Unbound as RFC 6761 recommends. Interestingly, BIND has the exact same behavior as Unbound for these two domains. (See https://bugs.debian.org/55032 for details.) -- Robert Edmonds edmo...@debian.org
rfc6761 compliance
Hello, the RFC 6761 give some advise how caching DNS servers SHOULD handle queries for reserved domains. Mostly it say "do not send queries to the root name servers" ... point 4 in any case ... http://tools.ietf.org/html/rfc6761#section-6.2 ( domain "test." ) http://tools.ietf.org/html/rfc6761#section-6.4 ( domain "invalid." ) looks like unbound don't follow that "SHOULD" recommendations. it this a miss-configuration on my side ? my unbound.conf: server: ip-address: ::1 chroot: /chroot/unbound do-daemonize: no val-log-level: 2 trust-anchor: ". DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5" # other options adding local-zone statements make unbound fixes the "un-conformance" here. server: local-zone: "test." static local-zone: "invalid." static Andreas