Internal DNS

If your organization uses TCP/IP on its internal networks - a very common situation nowadays - they will also need a method to locally resolve hostnames into IP addresses and vice versa. In smaller organizations whose infrastructure typically does not change much over time they might use static files (hostfiles), but given the low break-even point between the costs of maintaining such an infrastructure and the costs of installing and maintaining your own DNS most organizations run an internal DNS system.

In simpler setups, only one nameserver may suffice, though given the low costs involved nameservers will often be installed in pairs. Resolvers aware of more than one nameserver will query the other server if the primary server does not respond. If you have a number of divisions and various interconnected networks your setup will start resembling the Internet. But there are important differences.

Suppose your division is located outside the firm’s main building. The workgroup will have its own name servers. Internally, hosts will be members of the exworks (short for exampleworks) domain, that is, directly under the root (.) domain. To prevent accidental routing on the Internet the company chooses the use of one of the non-routable (private) IP networks: 192.168.72.

This implies we need to maintain both the domain zone and the reverse lookup zone 72.168.192.in-addr.arpa.

We can’t use the Internet infrastructure as their root name servers don’t know anything about the exworks and 72.168.192.

in-addr.arpazones, nor should they: we chose to use a private network after all. If we also like to be able to resolve real Internet hostnames and addresses, we can use what is known as a split-level DNS setup. Two split-level DNS setups will be shown.

7.3.9.1 Limiting negotiations

We can use a feature introduced into BIND in the days of dial-up connections. BIND behind a dial-up connection can be a nuisance: every time a DNS wants to communicate with a root name server, an automatic dialer sets up a connection. This is expensive. You can stop BIND from doing this by putting

// prevent dialup access heartbeat-interval 0;

dialup yes; // Actually disables dialup!

inside the options statement of the named.conf file. It is a bit counterintuitive to have to put dialup yes in a configura-tion actually meant to prevent dialups, but that’s the way to do it.

This trick can also be used to limit communication from an internal zone like exworks. The exworks and 72.168.192.

in-addr.arpazones are implemented as conventional master zones as described earlier in this chapter. The fundamental problem with this is that the real root servers still don’t delegate the exworks (and corresponding reverse) domain.

Therefore we should pull the internal zones together with the root name server definition into a separate DNS implementation.

This requires at least two independent name servers, and they can be set up in two different ways, as will be described below.

7.3.9.2 Split DNS: stand-alone internal master

The first approach consists of a stand-alone name server (that is, master for the internal zones) and another name server on another host that can be used to resolve names from both the outside world and the internal zones.

The figure below presents the exworks domain that is used as an example.

224.123.240.10 liongate

192.168.72.1 LAN

192.168.72.0/24

laptop_1 192.168.72.128

laptop_2 192.168.72.129

develop 192.168.72.3

unstable 192.168.72.4

privdns 192.168.72.2 Internet

The exworks network.

The two name servers in this example will be on different hosts. The first name server runs on privdns and will provide internal zone information. The other name server is on liongate, which will be a forwarding name server for both the internal zones and the outside world.

The host privdns (for private DNS) will contain the DNS for both the exworks and 72.168.192.in-addr.arpa zones.

This name server will have the following characteristics:

• it will be master for the root domain, but no DNS except itself will be able to access this information

• it will be master for the the exworks and 72.168.192.in-addr.arpa domains. Only other name servers inside the building will be able to access this information

On the other hand, liongate will do the following:

• do forwarding for the internal zones (this should be done first)

• do forwarding for the outside world

7.3.9.2.1 Configuring the master onprivdns

First, prepare a master file for the internal root zone. For example:

$TTL 25h

. IN SOA privdns.exworks. postmaster.privdns.exworks. ( 2001121000 ; yyyymmhhee (ee == ser/day start 00)

28800

Note the glue records that delegate the exworks and 72.168.192.in-addr.arpa zones as being hosted on nameserver 192.168.72.2.

Next, add a zone statement in named.conf that points to the master file for the root zone:

// ROOT MASTER zone for internal DNS server zone "." IN {

Using the type master tells the DNS that this really is a master server for the root zone. The root zone should not be known to any other name servers, therefore the allow-transfer and allow-query are set to none.

Note

The root zone definition typehint, as present in a default caching-only server, should be turned off (by not including it in the named.conffile).

Now, prepare zone files for the exworks and 72.168.192.in-addr.arpa zones, and add the corresponding zone entries in the named.conf file. The entry for exworks should look like this:

zone "exworks" IN {

The name server on liongate is the one providing names to the other hosts, so the IP address of liongate must be listed in the allow-query field.

The same must be done for the corresponding reverse zone.

Make sure the options statement contains recursion no;

fetch-glue no;

These statements tell the name server it should not accept queries for zones other than the ones it knows about.

Hosts in the exworks zone should point their resolv.conf to liongate. That is, the file should contain the line:

nameserver 192.168.72.1

where 192.168.72.1 is the IP address of liongate. On liongate itself, however, nameserver 127.0.0.1

ensures that local queries are run over the local loop interface, which is more efficient than using the outside IP address.

Note

The entries inresolv.confonprivdnsshould not point to the name server onprivdnsitself. If the host is to be used for purposes that require name resolving, it is better to point the entries to the name server onliongate.

7.3.9.2.2 Configuring DNS onliongate

The functionality of the DNS is twofold: first it should resolve names of the exworks zone (and corresponding reverse zone), secondly, it should resolve names from the outside world.

With the following forwarders statement queries to this name server are being forwarded to one on the listed IP addresses (remember that forwarders is part of the options statement):

forwarders {

192.168.72.2; // privdns 224.121.121.99; // ISP’s DNS };

The name servers are tried in the order in which they are listed. Requests are forwarded to privdns first. If that one does not have the answer, the DNS of the ISP is contacted instead.

Note that the IP address of privdns should be mentioned first: we don’t want requests for internal names be sent to the ISP.

Alternatively, the name server on liongate can be configured as slave for the exworks domain and corresponding reverse domain. We will discuss this in the next section.

7.3.9.2.2.1 Alternatives

There are two alternatives to this setup. Both require two separate name servers.

The first alternative is to use two nameserver statements in resolv.conf:

nameserver 192.168.72.2 nameserver 192.168.72.1

The first IP address points to privdns, the second to liongate. In this situation, privdns should also accept queries from 192.168.72.0/24and the forwarders statement on liongate should not contain the 192.168.72.2 (the IP address of privdns). The downside of this is that there is no single name server entry-point.

The second alternative is to use a slave setup for the exworks (plus corresponding reverse) domain. This situation is required when two name servers are running on the same host. This will be elaborated below, so it will not be discussed here. For this to work, the forwarders statement on liongate should not contain the IP address of privdns.

7.3.9.3 Split DNS: two DNS servers on one machine

We assume the same network again but with one important difference: host privdns is not available. This implies that the internalname server must now run on one of the other hosts, which also needs access to the outside world.

Both name servers will run on the same host. At least one of the name servers must run chrooted.