Using the default named.conf on Gentoo, there's tons of stuff for which BIND will send queries outside of local network but those will inevitably fail, because the address space is reserved, so it just produces useless traffic and load on third-party DNS servers. FreeBSD, e.g., has nice default named.conf to prevent this from happening, see http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/namedb/ (the default named.conf) and http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/namedb/master/ (the default empty.db stub zone) Would you consider this worth including? ;)
(In reply to comment #0) > Would you consider this worth including? ;) > Why are you not submitting a patch that adds this configuration? btw: You might have a look at bug #302361 if you want a better configuration. I have used in that named.conf parts from the FreeBSD named.conf.
Simply wanted to hear from the maintainer first before I start patching anything here. (Plus, creating patches that patch so far non-existant files is confusing at best.)
(In reply to comment #2) > Simply wanted to hear from the maintainer first before I start patching > anything here. (Plus, creating patches that patch so far non-existant files is > confusing at best.) > What do you want to patch? If you look at bug #302361 then you will see that it is nothing more then just 4 new files + one 1 to 1 copy but with a new name (instead of named.ca I used named.cache). Making patches for something like that is ultra pointless IMHO.
(In reply to comment #3) > What do you want to patch? ... Making patches for something like > that is ultra pointless IMHO. Maybe you could figure out what you are after here before asking such as this one in (Comment #1) > Why are you not submitting a patch that adds this configuration? Marking this as WONTFIX since I don't have time for similar pointless debate.
(In reply to comment #4) > (In reply to comment #3) > > What do you want to patch? ... Making patches for something like > > that is ultra pointless IMHO. > > Maybe you could figure out what you are after here before asking such as this > one in (Comment #1) > I don't understand this sentence. > > Why are you not submitting a patch that adds this configuration? > > Marking this as WONTFIX since I don't have time for similar pointless debate. > Good. Thanks for your time.
REOPEN to allow further discussion
(In reply to comment #6) > REOPEN to allow further discussion > I am a little bit unsure what to post here. Do you want me to post patches or can I go on and post full files and you make quickly the diff files by comparing them to stock Gentoo Portage files? I think I start with posting the diff right here in the comments box. If you need me to attach whole files or patches then let me know. Patch for the Ebuild: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- --- a/bind-9.7.0_p1.ebuild 2010-05-14 13:06:39.000000000 +0200 +++ b/bind-9.7.0_p1-r1.ebuild 2010-05-14 23:27:21.810135329 +0200 @@ -1,6 +1,6 @@ # Copyright 1999-2010 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/net-dns/bind/bind-9.7.0_p1.ebuild,v 1.4 2010/05/14 11:04:47 idl0r Exp $ +# $Header: Exp $ EAPI="3" @@ -209,15 +209,17 @@ use geoip && dodoc "${DISTDIR}"/${GEOIP_P}-readme.txt insinto /etc/bind - newins "${FILESDIR}"/named.conf-r4 named.conf || die + newins "${FILESDIR}"/named.conf-r5 named.conf || die + newins "${FILESDIR}"/empty-zone.cfg-r1 empty-zone.cfg || die # ftp://ftp.rs.internic.net/domain/named.cache: insinto /var/bind doins "${FILESDIR}"/named.cache || die insinto /var/bind/pri - newins "${FILESDIR}"/127.zone-r1 127.zone || die + newins "${FILESDIR}"/127.zone-r2 127.zone || die newins "${FILESDIR}"/localhost.zone-r3 localhost.zone || die + newins "${FILESDIR}"/empty.zone-r1 empty.zone || die newinitd "${FILESDIR}"/named.init-r7 named || die newconfd "${FILESDIR}"/named.confd-r3 named || die =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Allow me quickly to tell you why I have changed the 127.zone file. In the other bug report I have mentioned that you should include that localhost for IPv6 and point it to 127.zone. Remember? Well... for that to work right you need to add the IPv6 equivalent of localhost to the 127.zone file. That line is however missing in the original 127.zone-r1 file. The line is: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 1D IN PTR localhost. Patch for named.conf-r5: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- --- a/files/named.conf-r4 2010-05-14 13:06:39.000000000 +0200 +++ b/files/named.conf-r5 2010-05-14 23:22:44.810134392 +0200 @@ -103,7 +103,6 @@ inet 127.0.0.1 port 953 allow { 127.0.0.1/32; ::1/128; } keys { "rndc-key"; }; }; - view "internal" in { /* * Our internal (trusted) view. We permit the internal networks @@ -135,6 +134,11 @@ notify no; }; + /* If you wish to silence your BIND to not send spurious traffic to the root + * name servers then enable the line below. + */ + //include "/etc/bind/empty-zone.cfg" + /* * NOTE: All zone blocks for "public" view should be listed here in "internal" * too! Otherwise you'll have trouble to resolv the public zones properly. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Patch for 127.zone-r2: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- --- a/files/127.zone-r1 2008-12-26 23:27:38.000000000 +0100 +++ b/files/127.zone-r2 2010-05-07 11:14:39.190133623 +0200 @@ -9,4 +9,5 @@ @ 1D IN NS localhost. 1.0.0 1D IN PTR localhost. +1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 1D IN PTR localhost. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Full empty.zone-r1 file: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- $TTL 3h @ IN SOA @ root.localhost. ( 2008122601 ; Serial 28800 ; Refresh 14400 ; Retry 604800 ; Expire - 1 week 10800 ) ; Minimum @ IN NS @ @ IN A 127.0.0.1 @ IN AAAA ::1 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Full empty-zone.cfg-r1 file: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- // These zones are already covered by the empty zones listed below. If you // remove the related empty zones below, comment these lines out. disable-empty-zone "255.255.255.255.IN-ADDR.ARPA"; disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; // Serving the following zones locally will prevent any queries for these // zones leaving your network and going to the root name servers. This has // two significant advantages: // 1. Faster local resolution for your users // 2. No spurious traffic will be sent from your network to the roots // RFC 1912 zone "255.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; // "This" Network (RFCs 1912 and 3330) zone "0.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; // Private Use Networks (RFC 1918) zone "10.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "16.172.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "17.172.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "18.172.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "19.172.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "20.172.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "21.172.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "22.172.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "23.172.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "24.172.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "25.172.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "26.172.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "27.172.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "28.172.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "29.172.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "30.172.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "31.172.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "168.192.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; // Link-local/APIPA (RFCs 3330 and 3927) zone "254.169.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; // TEST-NET-[1-3] for Documentation (RFC 5737) zone "2.0.192.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "100.51.198.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "113.0.203.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; // IPv6 Range for Documentation (RFC 3849) zone "0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa" IN { type master; file "pri/empty.zone"; }; // Domain Names for Documentation and Testing (BCP 32) zone "test" IN { type master; file "pri/empty.zone"; }; zone "example" IN { type master; file "pri/empty.zone"; }; zone "invalid" IN { type master; file "pri/empty.zone"; }; zone "example.com" IN { type master; file "pri/empty.zone"; }; zone "example.net" IN { type master; file "pri/empty.zone"; }; zone "example.org" IN { type master; file "pri/empty.zone"; }; // Router Benchmark Testing (RFC 3330) zone "18.198.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "19.198.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; // IANA Reserved - Old Class E Space zone "240.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "241.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "242.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "243.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "244.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "245.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "246.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "247.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "248.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "249.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "250.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "251.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "252.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "253.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; zone "254.in-addr.arpa" IN { type master; file "pri/empty.zone"; }; // IPv6 Unassigned Addresses (RFC 4291) zone "1.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "3.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "4.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "5.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "6.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "7.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "8.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "9.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "a.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "b.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "c.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "d.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "e.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "0.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "1.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "2.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "3.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "4.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "5.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "6.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "7.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "8.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "9.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "a.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "b.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "0.e.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "1.e.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "2.e.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "3.e.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "4.e.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "5.e.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "6.e.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "7.e.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; // IPv6 ULA (RFC 4193) zone "c.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "d.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; // IPv6 Link Local (RFC 4291) zone "8.e.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "9.e.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "a.e.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "b.e.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; // IPv6 Deprecated Site-Local Addresses (RFC 3879) zone "c.e.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "d.e.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "e.e.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; zone "f.e.f.ip6.arpa" IN { type master; file "pri/empty.zone"; }; // IP6.INT is Deprecated (RFC 4159) zone "ip6.int" IN { type master; file "pri/empty.zone"; }; =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Is that okay with you? Can I now go on and post the full files? Or do you want patches?
Regarding the empty zones.. bind adds the following empty zones automatically: 0.IN-ADDR.ARPA 127.IN-ADDR.ARPA 254.169.IN-ADDR.ARPA 2.0.192.IN-ADDR.ARPA 255.255.255.255.IN-ADDR.ARPA 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA D.F.IP6.ARPA 8.E.F.IP6.ARPA 9.E.F.IP6.ARPA A.E.F.IP6.ARPA B.E.F.IP6.ARPA See also http://www.isc.org/files/arm96.html#server_statement_grammar and scroll a bit up until "Built-in Empty Zones". "these cover the reverse namespace for addresses from RFC 1918 and RFC 3330." So far as I understand is that enough, isn't it?
Some other empty zones are there too but they're not enabled for some reason, see bin/named/server.c. So it would be interesting to know why they're not enabled yet...
(In reply to comment #8) > Regarding the empty zones.. > bind adds the following empty zones automatically: > 0.IN-ADDR.ARPA > 127.IN-ADDR.ARPA > 254.169.IN-ADDR.ARPA > 2.0.192.IN-ADDR.ARPA > 255.255.255.255.IN-ADDR.ARPA > 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA > D.F.IP6.ARPA > 8.E.F.IP6.ARPA > 9.E.F.IP6.ARPA > A.E.F.IP6.ARPA > B.E.F.IP6.ARPA > > See also http://www.isc.org/files/arm96.html#server_statement_grammar and > scroll a bit up until "Built-in Empty Zones". > "these cover the reverse namespace for addresses from RFC 1918 and RFC 3330." > So far as I understand is that enough, isn't it? > I understood the documentation as follow: Those empty zones are added by default BUT if you use a forwarding setup then they are NOT automatically active. I have quickly tested a lookup against a BIND that has forwarders set BUT NOT set those empty zones like in the patch that I purpose and I can confirm that BIND is NOT resolving them locally. Instead it forwards those zones to the forwarders. And I have done the same test against a BIND that has forwarders set BUT DOES have those additional empty zones set (like I have purposed in the patch) and the response is different. The BIND version that has NOT those additional zones I get a response from my forwarders (several 100 ms response time) while on the BIND where I have those additional empty zones I get a response in 0 ms pointing me to 127.0.0.1. I think the speed is not an issue. I mean that in that sense, that the additional empty zones purposed by this bug report is not about speed. It is about preventing your BIND to send useless traffic out to root servers and/or your forwarders. And for that I can confirm that adding those additional zones is a big benefit and does prevent your local BIND to send that kind of traffic leaving your local network. You can actually test that very easy on your own setup. If you query any of those empty zones against your BIND, do you get a response? Does your BIND send that request out to a root server and/or to a forwarder? In my case it did set the traffic out to root/forward servers if I had not that additional empty zones included in named.conf. Can you test on your end if you get the same result?
(In reply to comment #8) > Regarding the empty zones.. > bind adds the following empty zones automatically: > 0.IN-ADDR.ARPA > 127.IN-ADDR.ARPA > 254.169.IN-ADDR.ARPA > 2.0.192.IN-ADDR.ARPA > 255.255.255.255.IN-ADDR.ARPA > 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA > D.F.IP6.ARPA > 8.E.F.IP6.ARPA > 9.E.F.IP6.ARPA > A.E.F.IP6.ARPA > B.E.F.IP6.ARPA > > See also http://www.isc.org/files/arm96.html#server_statement_grammar and > scroll a bit up until "Built-in Empty Zones". > "these cover the reverse namespace for addresses from RFC 1918 and RFC 3330." > So far as I understand is that enough, isn't it? > Reading now the source code I see that all those build in empty zones are not always enabled. Try setting recursion to no and then look what happens. Looks like that disabling recursion is disabling as well those empty zones. But enabling recursion AND setting allow-recursion to none enables has again another result. Check that out...
(In reply to comment #9) > Some other empty zones are there too but they're not enabled for some reason, > see bin/named/server.c. > > So it would be interesting to know why they're not enabled yet... > Try compiling BIND with "-D notyet" and look at the result.
I just tried your ipv6 suggestion: 23-May-2010 17:50:47.098 zone 127.in-addr.arpa/IN/internal: loaded serial 2010052301 23-May-2010 17:50:47.098 pri/127.zone:3: ignoring out-of-zone data (127.in-addr.arpa) 23-May-2010 17:50:47.098 pri/127.zone:10: ignoring out-of-zone data (127.in-addr.arpa) 23-May-2010 17:50:47.098 pri/127.zone:11: ignoring out-of-zone data (1.0.0.127.in-addr.arpa) 23-May-2010 17:50:47.098 pri/127.zone:12: ignoring out-of-zone data (1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.127.in-addr.arpa) 23-May-2010 17:50:47.098 zone 0.ip6.arpa/IN/internal: has 0 SOA records 23-May-2010 17:50:47.098 zone 0.ip6.arpa/IN/internal: has no NS records 23-May-2010 17:50:47.098 zone 0.ip6.arpa/IN/internal: not loaded due to errors. Unfortunately I have no IPv6 here :( but I'll try to find a solution anyway.
Seems that bind doesn't like: zone "0.ip6.arpa" IN { type master; file "pri/127.zone"; allow-update { none; }; notify no; };
Some more suggestions based on the changes in this bug report: 1. allow-query { } should be set to YES for the public view, but with "recursion no;" directly underneath it. Justification: for zones we are hosting we must permit everyone to be able to query those zones, but we must NOT do recursive queries except for trusted clients so as to avoid the masses to use our server as an all purpose resolver 2. allow-trusted {} should include the link-local IPv6 range as well as arguably all private IP ranges, with a warning that this ought to be customised, but at least by default it is functional and reasonably secure. Justification: we want a working config that is secure but yet works for the common case, so adding the RFC1918 IP ranges and IPv6 link local in here makes sense 3. dnssec-validation yes; Should be the default now that the root hints are signed, although more configuration is required for full DNSSEC validation to work (possibly more documentation be added for this). 4. empty-zones-enable no; I am in favour of having this option off. I don't think it's reasonable behaviour that bind create "empty" zones including this data when I have already defined a zone myself for my own internal network.
seems a bit irrelevant now.
