I inherited an evironment that has a BIND server for our internal LAN. I noticed it doesn't have any forwarders for external request (i.e. google.com). How the heck does my laptop know that google.com is outside our LAN? My DHCP scope has the BIND server listed as it's primary DNS server.
BIND DNS forwarding for external domain
bind
Related Solutions
The best method is via the response policy zone in Bind 9.8.1 or newer. It allows you to override single records in arbitrary zones (and there's no need to create a whole subdomain for that, only the single record you want to change), it allows you to override CNAMEs, etc. Other solutions such as Unbound cannot override CNAMEs.
https://www.redpill-linpro.com/sysadvent/2015/12/08/dns-rpz.html
EDIT: Let's do this properly then. I will document what I've done based on the tutorial linked above.
My OS is Raspbian 4.4 for Raspberry Pi, but the technique should work without any changes on Debian and Ubuntu, or with minimal changes on other platforms.
Go to where your Bind config files are kept on your system - here it's in /etc/bind
. Create in there a file called db.rpz
with the following contents:
$TTL 60
@ IN SOA localhost. root.localhost. (
2015112501 ; serial
1h ; refresh
30m ; retry
1w ; expiry
30m) ; minimum
IN NS localhost.
localhost A 127.0.0.1
www.some-website.com A 127.0.0.1
www.other-website.com CNAME fake-hostname.com.
What does it do?
- it overrides the IP address for
www.some-website.com
with the fake address127.0.0.1
, effectively sending all traffic for that site to the loopback address - it sends traffic for
www.other-website.com
to another site calledfake-hostname.com
Anything that could go in a Bind zone file you can use here.
To activate these changes there are a few more steps:
Edit named.conf.local
and add this section:
zone "rpz" {
type master;
file "/etc/bind/db.rpz";
};
The tutorial linked above tells you to add more stuff to zone "rpz" { }
but that's not necessary in simple setups - what I've shown here is the minimum to make it work on your local resolver.
Edit named.conf.options
and somewhere in the options { }
section add the response-policy
option:
options {
// bunch
// of
// stuff
// please
// ignore
response-policy { zone "rpz"; };
}
Now restart Bind:
service bind9 restart
That's it. The nameserver should begin overriding those records now.
If you need to make changes, just edit db.rpz
, then restart Bind again.
Bonus: if you want to log DNS queries to syslog, so you can keep an eye on the proceedings, edit named.conf.local
and make sure there's a logging
section that includes these statements:
logging {
// stuff
// already
// there
channel my_syslog {
syslog daemon;
severity info;
};
category queries { my_syslog; };
};
Restart Bind again and that's it.
Test it on the machine running Bind:
dig @127.0.0.1 www.other-website.com. any
If you run dig on a different machine just use @the-ip-address-of-Bind-server instead of @127.0.0.1
I've used this technique with great success to override the CNAME for a website I was working on, sending it to a new AWS load balancer that I was just testing. A Raspberry Pi was used to run Bind, and the RPi was also configured to function as a WiFi router - so by connecting devices to the SSID running on the RPi I would get the DNS overrides I needed for testing.
This looks like a mismatch in the firewall's NAT state-table timeouts and the DNS server's own timeouts.
ICMP Port Unreachable is being returned by your DNS server, probably in response to a late received packet. BIND picks a random(ish) port for each outbound query, and it's possible for a long-delayed response to arrive long after BIND stopped listening for the response on that port.
That does beg the question of why the firewall happily allows the (late) returned packet in, without subsequently letting the ICMP error back out.
Related Topic
- How to set up multiple DNS servers on an intranet
- Setting up a bind forwarder, except for a domain
- BIND as secondary DNS to Windows Server 2012. Windows complains that BIND is “not authoritative”
- Bind DNS – Using views External zones fail transfer to slave
- DNS Forwarders based on Source IP Addresses(Bind 9)
Best Answer
BIND has what is called a "root hints" list pre-installed inside the binary. It lists where root servers are, or at least were when that specific version of BIND was released. Luckily, they rarely move, although more addresses may be added. Usually these are IPv6 addresses.
When BIND first starts up, it will use these hints to find what the current address set really is. This is called "priming" and is done entirely behind the scene.
So, once this is done, and you configure some local zones for your own use, it knows enough to answer questions for your zones and for any other domain out there. In this case, google.com is not a local zone in your file, so it asks a root server for google.com, gets sent to servers for .com, and then those send BIND off to google.com's name servers. They answer, and you get your answer.
As an author of BIND, I'm happy it appears to be magic. :)