This is an updated version of the 2002 edition
Burt Rosenberg
June 2013
Internal hosts always have addresses in the local address block. At this time, that block is 172.16.0.0/12. This block is subdivided into subnets with 4 bit subnet masks according to security level, making a /16 address, 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: mcclellan | brag | pickett | | | | | | | | | | | | | | | | | | | +--<=========>--+ | | | +--<========> cs.miami.edu name resolution | primary/secondary | | | | | | | +------->------------+-->----+ +--<==========> math.miami.edu servers forward non-local resolution primary/secondary
The cs department controls 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.
The commands dig
NS cs.miami.edu
and dig NS math.miami.edu
lists the
authoritative name servers for the cs and math domains,
respectively.
========================================== global$ dig ns cs.miami.edu ... ;; QUESTION SECTION: ;cs.miami.edu. IN NS ;; ANSWER SECTION: cs.miami.edu. 720 IN NS ns-1596.awsdns-07.co.uk. cs.miami.edu. 720 IN NS ns-350.awsdns-43.com. cs.miami.edu. 720 IN NS phantom.math.miami.edu. cs.miami.edu. 720 IN NS ns-641.awsdns-16.net. cs.miami.edu. 720 IN NS ns-1425.awsdns-50.org. cs.miami.edu. 720 IN NS ns1.cs.miami.edu. ========================================== local$ dig ns cs.miami.edu ... ;; QUESTION SECTION: ;cs.miami.edu. IN NS ;; ANSWER SECTION: cs.miami.edu. 3600 IN NS davis.cs.miami.edu. cs.miami.edu. 3600 IN NS mcclellan.cs.miami.edu. ========================================== global-and-local$ dig ns cs.miami.edu ... ;; QUESTION SECTION: ;math.miami.edu. IN NS ;; ANSWER SECTION: math.miami.edu. 223 IN NS miavax.ir.miami.edu. math.miami.edu. 223 IN NS umigw.miami.edu. math.miami.edu. 223 IN NS phantom.math.miami.edu. math.miami.edu. 223 IN NS ns1.cs.miami.edu. ========================================== global-and-local$ dig ns -x 129.171.34 ... ;; QUESTION SECTION: ;34.171.129.in-addr.arpa. IN NS ;; ANSWER SECTION: 34.171.129.in-addr.arpa. 3600 IN NS miavax.ir.miami.edu. 34.171.129.in-addr.arpa. 3600 IN NS ns1.cs.miami.edu. 34.171.129.in-addr.arpa. 3600 IN NS phantom.math.miami.edu. 34.171.129.in-addr.arpa. 3600 IN NS umigw.miami.edu. global-and-local$ dig ns -x 192.70.171 ... ;; QUESTION SECTION: ;171.70.192.in-addr.arpa. IN NS ;; ANSWER SECTION: 171.70.192.in-addr.arpa. 3600 IN NS miavax.ir.miami.edu. 171.70.192.in-addr.arpa. 3600 IN NS ns1.cs.miami.edu. 171.70.192.in-addr.arpa. 3600 IN NS umigw.miami.edu. 171.70.192.in-addr.arpa. 3600 IN NS phantom.math.miami.edu. global-and-local$ dig ns -x 192.31.89 ... ;; QUESTION SECTION: ;89.31.192.in-addr.arpa. IN NS ;; ANSWER SECTION: 89.31.192.in-addr.arpa. 720 IN NS phantom.math.miami.edu. 89.31.192.in-addr.arpa. 720 IN NS ns1.cs.miami.edu. 89.31.192.in-addr.arpa. 720 IN NS miavax.ir.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.
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 Dynamic 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
update: 22 june 2013