Overview of DNS

Overview of DNS

The Domain Name Service (DNS) is a distributed database that maps human friendly fully qualified hostnames, like paulwatters.com, to a numeric IP address like In the early days of the Internet, a single file was distributed to various hosts (called the HOSTS.TXT file), which contained an address to hostname mapping for known hosts. Administrators would periodically upload a list of any new hosts added to their networks, after which they would download the latest version of the file. However, as the Internet grew, maintaining this text database became impossible. A new system for mapping addresses to names was proposed in RFCs 882 and 883, based around information about local networks being sourced from designated servers for each network. It should be noted that Solaris retains a variant of the HOSTS.TXT file in the form of the /etc/hosts file, which is typically used to map IP addresses to domain names for the localhost, as well as key network servers such as the local domain name server. This is very useful in situations where the DNS server is not responding, or while the system is being booted. The /etc/hosts file is consulted by some applications, such as the syslog daemon (syslogd) to determine which host (the “loghost”) should be used for system logging. A typical /etc/hosts file looks like this:          localhost       bryce       bryce.paulwatters.com      loghost       wasatch     wasatch.paulwatters.com

Of course, only key servers and the localhost should be defined in the /etc/hosts file; otherwise, any change in IP address for that server will not be reflected in the value resolved from /etc/hosts.

Exercise 26-1 Checking Hosts Entries  Check the entries in your /etc/hosts. Are there entries for localhost and loghost?

DNS works on a simple client/server principle: if you know the name of a DNS server for a particular network, you will be able to retrieve the IP address of any host within that network. For example, if I know that the name server for the domain paulwatters.com is dns20.register.com, I can contact dns20.register.com to retrieve the address for any host within the paulwatters.com domain (including www.paulwatters.com, or Of course, this leads us to a classic “chicken and egg” problem—how would we know in the first instance that the DNS server dns20.register.com was authoritative for paulwatters.com? The answer is that, in the same way that the addresses of all hosts under paulwatters.com are managed by its DNS server, the address of the DNS server is managed by the next server along the chain—in this case, the DNS server for the “.com” domain.

There are many such top-level domains now in existence, including the traditional .edu (educational organizations), .com (commercial organizations), and .net (network) top-level domains. Most countries now have their own top-level domains, including .au (Australia), .ck (Cook Islands), and .ph (Philippines). Underneath each top-level domain are a number of second-level domains: for example, Australia has .com.au (Australian commercial organizations), .edu.au (Australian educational organizations), and .asn.au (Australian nonprofit associations).


The organizations that manage each top-level and second-level domain can also be quite different.

As an example, let’s look at how the hostname www.finance.saltlake.com is resolved: the client resolver needs to determine which DNS server is authoritative for .com domains, followed by the DNS server that is authoritative for saltlake.com domains, potentially followed by the DNS server that is authoritative for the finance.saltlake.com domain, if all mappings for saltlake.com are not stored on a single server. The .com resolution is taken care of by the list of root servers provided by the Whois database (ftp://ftp.rs.internic.net/domain/named.root):

>>> Last update of whois database: Mon, 9 Oct 2000 09:43:11 EDT <<<
The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and
;       This file holds the information on root name servers needed to
;       initialize cache of Internet domain name servers
;       (e.g. reference this file in the "cache  .  <file>"
;       configuration file of BIND domain name servers).
;       This file is made available by InterNIC registration services
;       under anonymous FTP as
;           file                /domain/named.root
;           on server           FTP.RS.INTERNIC.NET
;       -OR- under Gopher at    RS.INTERNIC.NET
;           under menu          InterNIC Registration Services (NSI)
;              submenu          InterNIC Registration Archives
;           file                named.root
;       last update:    Aug 22, 1997
;       related version of root zone:   1997082200
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A
.                        3600000      NS    C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000      A
.                        3600000      NS    D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.      3600000      A
.                        3600000      NS    E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.      3600000      A
.                        3600000      NS    F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.      3600000      A
.                        3600000      NS    G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.      3600000      A
.                        3600000      NS    H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.      3600000      A
.                        3600000      NS    I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.      3600000      A
.                        3600000      NS    J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.      3600000      A
.                        3600000      NS    K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.      3600000      A 
.                        3600000      NS    L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.      3600000      A
.                        3600000      NS    M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.      3600000      A

The named.root file shown previously can be used by systems to resolve IP addresses for root DNS servers. After obtaining an IP address for a root server for the .com domain, a query is then made to the DNS server authoritative for saltlake.com for the address www.finance.saltlake.com. Two possible scenarios can occur at this point: either the DNS server that is authoritative for the entire saltlake.com domain can resolve the address, or the query is passed to a DNS server for the finance.saltlake.com domain if the root server has delegated authority to another server. In the latter situation, the saltlake.com DNS server does not know the IP address for any hosts within the finance.saltlake.com domain, except for the address of the DNS server. DNS is therefore a very flexible system for managing the mapping of domain names to IP addresses.

The software that carries out the client request for, and server resolution of, IP addresses is typically the Berkeley Internet Daemon (BIND).


Although most vendors, including Sun, ship their own customized version of BIND, it is possible to download, compile, configure, and install your own version of BIND (available for download from http://www.isc.org/).

Part I: Solaris 9 Operating Environment, Exam I