Digital Elephant
DNS: Being a Local Authority
A simple cacheing nameserver is good enough when a Private Network contains only a couple of machines that want to share a common Internet access line, but have little need to communicate with each other. We can configure each system so that it can refer to any of the others by name, by making use of the /etc/hosts facility on Linux machines, or the equivalent c:\windows\hosts file on Microsoft systems. But if the number of machines on the Private Network is at all large, keeping all the hostname lists consistent quickly becomes a major pain.
Fortunately, Linux is sufficiently flexible that we can improve this situation without too much difficulty. One addition is needed to the configuration of the previously-described cacheing-only nameserver: authoritative name and address data for the local network. (A good host for this nameserver is the boundary Linux machine recommended throughout these pages.)
Then, all local systems are configured so that they make DNS requests only to this name server. If the named daemon can resolve the name, it returns the IP address; otherwise, it will pass the request out onto the Internet for resolution in the normal way.
There is one disadvantage to this arrangement, however. If an external machine makes a request for DNS resolution from the Internet side of the boundary, the name server will cheerfully send back a response, since it is authoritative for the local network. The resolved address data will not be immediately useful to the requestor, since the address will be the Private Network address that cannot be used on the public Internet, but it does expose the hidden topology to an attacker, who may be able to use the information to plan a more complete takeover of a local network. To eliminate this information leak, it is necessary to establish two named daemons; one that fields external requests (and is authoritative for only the DNS names that you want to advertise on the Internet), and one that fields requests from the boundary machine and the Private Network (which is authoritative for the larger set of DNS names that you want to make available to private-side machines). Such a scheme is called a split-horizon configuration. To keep the two daemons out of each other's way, some special configuration is needed.
If the Private Network is not part of a registered domain, then a good practice is to make up a local domain name that could not conflict with any of the registered domains. For example, we might call the private domain neptune. Then each of our local machines would have names like bozo.neptune or gabby.neptune.
If the Private Network has a registered domain, and we want to supply authoritative answers to the Internet, a separate public-side named daemon fields any incoming DNS requests, and supplies the necessary address translation info. This is only necessary if you are your own authority; otherwise, DNS requests of this type should be fielded by your ISP, and your boundary system should never handle them. For efficiency, this daemon should probably run on the boundary machine in all cases.
Configuring the Private DNS daemon
I recommend the O'Reilly book DNS and BIND for definitive advice on configuring, maintaining, and running a DNS daemon. The example configuration here assumes a great deal: that you are running the latest DNS version, that your boundary machine is the final authority for a legal published domain (one that is registered), and that you have only one private network interface on the boundary machine.
Here is a sample set of configuration files for the local named.
Forward Zone File
$TTL 86400
@ IN SOA yourdomain. root.foo.yourdomain. (
2006110701 ; Serial
28800 ; Refresh - 8 hr
14400 ; Retry - 4 hr
3600000 ; Expire - 1000 hr
86400 ) ; Default TTL - 1 day
@ IN NS foo.yourdomain.
@ IN MX 10 foo.yourdomain.
foo IN A 192.168.1.1
bar IN A 192.168.1.2
etaoin IN A 192.168.1.3
shrdlu IN A 192.168.1.4
This file supplies the name-to-address mapping information for machines on the Private Network 192.168.1.x. It is the final authority for yourdomain, so requests for other hostnames within that domain will be rejected immediately, rather than forwarded out onto the Internet.
Reverse Zone File
$TTL 86400
@ IN SOA yourdomain. root.foo.yourdomain. (
2006110701 ; Serial
28800 ; Refresh - 8 hr
14400 ; Retry - 4 hr
3600000 ; Expire - 1000 hr
86400 ) ; Minimum - 1 day
IN NS foo.yourdomain.
1 IN PTR foo.yourdomain.
2 IN PTR bar.yourdomain.
3 IN PTR etaoin.yourdomain.
4 IN PTR shrdlu.yourdomain.
This file supplies the reverse mapping (address-to-name) for yourdomain. It must be kept consistent with the forward mapping file so that DNS services on other machines that expect to be able to translate back and forth will be able to do so.
Local Daemon Configuration File
//YourDomain local nameserver config. This
// listens only to queries from behind the firewall.
options {
directory "/var/named/lcl";
recursion yes;
listen-on {192.168.1.1; 127.0.0.1; 216.39.145.64;};
pid-file "/var/run/named/named-lcl.pid";
};
zone "." {
type hint;
file "../named.ca";
};
zone "yourdomain" {
type master;
file "forward.zone";
};
zone "1.168.192.in-addr.arpa" {
type master;
file "reverse.zone";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "../named.local";
};
This central configuration file specifies how everything fits together. The daemon listens to DNS requests from the Internet, from the local network, and from loopback, which is where resolution requests appear from programs on the boundary machine itself. Hints about how to contact the DNS root servers are in the first zone. Authoritative information for forward and reverse mappings of yourdomain are in the files forward.zone and reverse.zone. Note that the zone name for the reverse mapping contains the text of your private network address range, in reverse octet order.
In order to configure a split-horizon arrangement, you will need to create two instances of named, setting the local one to listen on the private network and on the loopback address 127.0.0.1. Then set the public named to listen on the public IP address only. It only will handle queries from outside your network, and only give useful replies for resolution of names that you specify in its zone file, which may have a (small) subset of the DNS names available to your Private Network machines.