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 on each machine 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.
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.
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.
All is well so far, as long as the only clients for this nameserver are members of the Local Network. But, if the Private Network has a registered domain, and we want to supply authoritative answers to the Internet, named fields any incoming DNS requests, and supplies the necessary address translation info.
There is one disadvantage to this arrangement, however. If a computer outside the local net makes a request for DNS resolution from the Internet side of the boundary, the nameserver will cheerfully send back a response, since it is authoritative for the local network. The resolved address might not be immediately useful to the requestor, since the address may be a 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 a public view and a private view of the DNS information. This can be done either by configuring a single named daemon to offer multiple views of the DNS information, or by running 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). Either of these scheme is called a split-horizon configuration.