Bind9 Views for DNS Zones

Bind 9 has the ability to answer queries from internal hosts with different responses than external hosts get. For example, lets say, that our internal network is 192.168.0.0/24, and our external DMZ is 172.16.10.0/24. Access to things such as web services from the internet, are via NATs to internal servers. Lets also say, that our web server is 192.168.0.50, and that the NAT on the firewall is 172.16.10.50. Internal users need to be able to look up this server as 192.168.0.50, and external people need to look it up as 172.16.10.50. This can be accomplished with 2 totally seperate DNS servers, or, with a single Bind 9 server that serves views of the same zone.

So, lets start looking at the configuration of our DNS server. Bind 9, running on your favorite flavor of a Unix-like operating system, and we will set our DNS server’s IP address as 192.168.0.40. Since we have only 1 DNS server, the firewall also forwards UDP port 53 to our DNS server, and we will be able to answer queries from the internet as well.

Now lets jump right into the Bind 9 configuration file, the named.conf. The top section might look like this:

The first line defines an ACL (access control list) for who a set of computers will be, and in this case, they will be called “internal”. For sanity, we also add the loopback address (127.0.0.1) so that the DNS server will be able to answer itself when it asks. The ‘options’ section is pretty self explanitory, and are pretty much filled with the default options that came in the named.conf file, except the ‘listen-on’ line. It originally only had the loopback address, so we have to add the ip address of our DNS server, so that queries can be answered by other computers.

Next we have the beginning of our zone files configuration. These first 2 zones are the basis of Bind, and I’ve never seen a server that didnt come with them. These set up your cacheing DNS, and just the configuration above would allow your internal computers to find their way around the internet successfully. However, notice that instead of just starting with a standard ‘zone’ statement, we start with ‘view “internal”‘. This is what is going to give our DNS server the ability to say one thing to internal people, and another to external. Now, lets add a zone to our named.conf file.

Ok, now we have the same configuration file as before, but this time we have added a zone into the configuration. Pretty much the only thing that I do differently on a views type of configuration, is to name the zone files in such a way as to be able to tell by the file name, that the zone file is an internal or external. notice, that my zone file is called domainexample.com.i.hosts, with an i in the middle of the name.This is just what I use for my own designation, what ever way you want to designate your files is fine, the filename of the zone is purely cosmetic. Note that for the internal version of our zone, we have the line ‘allow-transfer’ set to any. This acceptable being that only hosts that match the internal ACL will be allowed to make a zone transfer.

Now we need a copy of the zonefile domainexample.com.i.hosts. Here is what it might look like:

In the above eample, we have a basic zone file for internal use.

The third line that says ‘2006100701’ is the zones serial number, and it basically translates to year-month-day-revision’. This number is incremented each time you make a change, otherwise servers that are cacheing your domain will not recognize your changes (but if they see a newer zone serial number, they will update). This zone file also has one line for a NS record (to desginate the DNS servers for this domain), three A records (also known as ‘host records’), and one CNAME record (also known as an alias). The three A records specify the IP addresses of our DNS server, our Web server and another server called ‘internal’. I added this internal server to the example, because nearly all organizations have internal resources that are not accessable from the internet, and for all practical purposes, hosts on the internet dont even need to know about its existance. More on that, in a while.

Ok, now that we have internal DNS working, lets take a look at how we can get a copy of thise zone to the outside world, but have it use the correct public IP addresses, and do it all from the same server. Let’s go back to our named.conf file:

Now we have our external view. The ACL comes into play here, designating ‘any’. In this case, any query not matchine the first ACL will be serviced by this zone file. For sanity on external zone, recursion is not allowed, and transfers are not allowed. As before, notice the zone file has an e in the name, to designate that this is the external copy of the zone. From the beginning of this article, we said that our outside IP addresses are on the 172.16.10.0/24 network, and that our firewall is going to NAT the IP addresses 172.16.10.40 and 172.167.10.50 to our DNS server and Web servers, respectively. So assuming all that is already in place, lets look at what our external zone file might look like:

Notice that this zone file is almost identical to the previous, save the IP addresses specified for hosts, and the omission of the host named ‘internal’. Remember, the ACL allows internal hosts to resolve ‘internal’ to 192.168.0.45. That same ACL also forces any internet hosts to resolve only information in the external zone. If someone on the internet were to lookup the ip address ‘internal.domainexample.com’, they would be returned with ‘host not found’.

So, in the end, the actual host names and their aliases are the same for both internal and external users. This allows road warriors to work more seemlessly, while at the same time, hosts that have no business “being public knowledge” (and are also not available through a NAT on thefirewall) are hidden from public view by our zone file.

Originally posted on : http://www.openaddict.com/node/30