Internal hosts always have addresses in the local address block. At this time, that block is 172.0.0.0/8. This block is subdivided into subnets with 16 bit subnet masks according to security level, however this fact has no relevance for name resolution (using DNS).
The main concept of split dns is that internal hosts are directed to an internal domain name server for name resolution, external hosts are directed to an external domain name server for name resolution.
| | |
zone: servers | lab | public | outside
| | |
| | |
DNS server: sherman | lee | jackson |
| | | | | | | | | |
| | | | | | |
| +--<=========>--+ | | | +--<========> cs.miami.edu name resolution
| primary/secondary | | |
| | | |
+------->------------+-->----+ +--<==========> math.miami.edu servers
forward non-local resolution primary/secondary
The cs department controls two additional local zones, which are not linked to the global Internet infrastructure:
It is customary to provide more than one domain name server for any domain, since the inability to contact a domain name server effectively removes hosts from the Internet. These backups are called secondary name servers, and the automatically download the names database from the primary name server. Since the secondaries download from the primary, a change in the name database takes some time to propagate.
At this time, lee and sherman are the name servers for local machines, and serve only the local zone, with some exceptions. Other queries are fowarded to global Internet name servers. Jackson, hurricane and ibis are the name servers for machine outside the local naming zone.
DNS servers giving local answers: sherman.cs.miami.edu 172.20.0.2 lee.cs.miami.edu 172.19.0.2 DNS servers giving global answers: jackson.cs.miami.edu 192.31.89.2 hurricane.math.miami.edu 129.171.34.4 ibis.math.miami.edu 192.70.171.3 domain.cs.miami.edu CNAME for jackson.cs.miami.edu
In all unix derivatives, a host learns its domain servers from the file /etc/resolv.conf. Here is a sample such file:
> cat /etc/resolv.conf domain cs.miami.edu nameserver 172.20.0.2 nameserver 172.19.0.2Users of DHCP can receive nameserver information from the DHCP server, and the local DHCP client can edit /etc/resolv.conf to include this information. Problems finding a nameserver can often be diagnosed by looking at this file.
Resolution of names outside of the local domain proceed normally: the Internet's bind tree is traversed to find the name server responsible for the name. Under certain circumstances it is possible that a local name is forced to resolve as if it were queried globally. For instance, www.cs.miami.edu could resolve as either 172.18.0.2 (local) or 192.31.89.3 (global), with the same effect. However this is controlled by the local name server and need not concern the client software.
I have noticed intermittant problems mailing to aol.com, with error message faulting the MX record look up. The current theory is that the MX record was returning to sherman in some manner outside the PIX UDP policy. The solution was to forward non-local naming requests to jackson for resolution. Jackson's DNS policy is clear: the domain port is allowed. This is accomplished with forwarders in named.conf.
It might be a problem of UDP policy time-out, in which case even jackson's help is not sufficient, since the policy still intercedes between jackson and sherman. query-source can fix the source port number, and this port number can be allowed from jackson to sherman.
The dns system has been setup so that understanding of split dns is optional for users. Internal host, those with a 172.0.0.0/8 address, will have an /etc/resolv.conf directing the host to the internal DNS servers. External hosts, those traversing the Internet DNS tree, will find the external DNS server.
The local cs.miami.edu zone does need certain global names. Names in the cs.miami.edu domain which are not known to sherman will be unresolved. Sherman will not ask jackson for a matching global name, failing a matching local name.
For instance, www.cs.miami.edu could be considered a global name. One way or the other, the local zone server must know this name, or it will not be possible to reference www.cs.miami.edu internally. The perferred method to do this has not been determined. The most straightforward is an A record for www.cs.miami.edu straight to the global IP address of jackson. There are other possibilities.
We have had some problem with jackson, since it lies in the intersection of internal and external name domains. This is of no interest to anyone but system administrators, since this machine is isolated in the public zone. The resolution to the problem is to create the following /etc/host.conf file:
hosts bindThis sends local resolution first to the /etc/hosts file, where it finds internal IP addresses, and then failing that, to the bind system (a.k.a. DNS) for external IP addresses. This feature is largely undocumented before FreeBSD 4.6.
Split DNS allows a machine name to bind to two different addresses. For instance, jackson is both 172.18.0.2 internally and 192.31.89.3 externally. This can be considered more of a fault than a virtue, and is not the justification for Split DNS. Split DNS allows the minimal functionality required for external operation to be placed in the public zone, and a fully functional DNS server placed internally. For instance, the internal DNS supports Dynmaic DNS, the external DNS does not.
As a general rule, it should never be that a name gives two different behaviors unless at least one of the behaviors is that of no-response. For example, internally there are local bindings for www.cs.miami.edu and web.cs.miami.edu. The first gives the public web server the second gives the private web server. Therefore the name web.cs.miami.edu should be undefined in the global zone. Internally, web.cs.miami.edu gives a web pages, externally web.cs.miami.edu gives a no-response.
Burt Rosenberg, 1 july 2002
update: 1 august 2002
update: 2 august 2002