DNS Client Tools

Configuring a DNS client in Solaris is very easy, and can be accomplished in a few easy steps. First, you must have installed the Berkeley Internet Daemon (BIND) package during system installation to use the DNS client tools. Secondly, you must configure the name service switch (/etc/nsswitch.conf) to consult DNS for domain name resolution, in addition to checking the /etc/hosts file and/or NIS/NIS+ maps or tables for hostnames. The following line must appear in /etc/nsswitch.conf for DNS to work correctly:

/etc/nsswitch.conf hosts:  dns [NOTFOUND=return] files

If you have NIS+ running, the line would look like this:

/etc/nsswitch.conf hosts:  dns nisplus nis [NOTFOUND=return] files

Next, the name of the local domain should be entered into the file /etc/defaultdomain. For example, the /etc/defaultdomain file for the host www.paulwatters.com should have the following entry:

paulwatters.com

Finally, the /etc/resolv.conf file needs to contain the name of the local domain, as well as the IP addresses of the local primary DNS server, as well as a secondary (off-site) DNS server. This means that even if your local DNS server goes down you can rely on the secondary to provide up-to-date information about external hosts, instead of relying on data within the /etc/hosts file to resolve local addresses. In the following example, we demonstrate how the /etc/resolv.conf file might look for the host www.finance.saltlake.com:

domain finance.saltlake.com
domain saltlake.com
nameserver 204.168.12.1
nameserver 204.168.12.16
nameserver 64.58.24.1

Here, there are two domains to which the host belongs: the subdomain finance .saltlake.com, as well as the domain saltlake.com. Thus, there are two primary DNS servers listed within the local domain (204.168.12.1 and 204.168.12.16). In addition, an external secondary is also listed, corresponding to ns.utahisp.com, or 64.58.24.1.

Once the client resolver is configured in this way, we can use a number of tools to test whether DNS is working, and also to further examine how IP addresses are resolved. The most important tool for performing DNS resolutions is nslookup, which can be used in a simple command-line mode to look up fully-qualified domain names from IP addresses, and vice versa. However, nslookup also features an interactive mode that is very useful for retrieving name server characteristics for a particular domain, and to determine which DNS servers are authoritative for a specific host or network.

Let’s look at a simple example—if we wanted to determine the IP address of the host www.paulwatters.com, using a client on the host provo.cassowary.net, we would use the following command:

$ nslookup www.paulwatters.com

The following response would be returned:

Server:  provo.cassowary.net
Address:  206.68.216.16

Name:    paulwatters.com
Address:  209.67.50.203
Aliases:  www.paulwatters.com

This means that the primary DNS server for the local (cassowary.net) domain is provo.cassowary.net (206.68.216.16). This server then makes a connection through to the DNS server, which is authoritative for the domain paulwatters.com (dns19.hostsave.com). This server then returns the canonical (actual) name for the host (paulwatters.com), the alias name (www.paulwatters.com), and the desired IP address. If we reversed the process, and instead supplied the IP address 209.67.50.203 on the command line, we would be able to perform a reverse lookup on that address, which would resolve to the domain name paulwatters.com.

Exercise 26-2 Using nslookup Use nslookup to determine the IP address of www.sun.com.

If you want to verify that your DNS server is returning the correct IP address, or if you want to verify an address directly yourself, then running nslookup in interactive mode allows you to set the name of the DNS server to use for all lookups. For example, if we wanted to resolve the domain name for the web server of the University of Sydney, we could use the following command:

$ nslookup www.usyd.edu.au

The following response would then be returned:

Server:  provo.cassowary.net
Address:  206.68.216.16

Name: solo.ucc.usyd.edu.au
Address:  129.78.64.2
Aliases:  www.usyd.edu.au

However, we could verify that this IP address was indeed correct by setting our DNS server to be the DNS server that was authoritative for the ucc.usyd.edu.au domain:

$ nslookup
Default Server:  provo.cassowary.net
Address:  206.68.216.16

Here, we enter the name of the DNS server that is authoritative for the target domain:

> server metro.ucc.su.oz.au
Default Server:  metro.ucc.su.oz.au
Address:  129.78.64.2

Next, we enter the name of the host to resolve:

> www.usyd.edu.au
Server:  metro.ucc.su.oz.au
Address:  129.78.64.2

And the IP address is returned correctly:

Name:    solo.ucc.usyd.edu.au
Address:  129.78.64.24
Aliases:  www.usyd.edu.au

If you wanted to determine some of the key characteristics of the DNS entry for www.usyd.edu.au, such as the DNS server that is authoritative for the host and the mail address of the administrator who is responsible for the host, it is possible to retrieve the Start of Authority (SOA) record through nslookup:

$ nslookup
Default Server:  provo.cassowary.net
Address:  206.68.216.16

> server metro.ucc.su.oz.au
Default Server:  metro.ucc.su.oz.au
Address:  129.78.64.2
> set q=soa
> www.usyd.edu.au
Server:  metro.ucc.su.oz.au
Address:  129.78.64.2

www.usyd.edu.au canonical name = solo.ucc.usyd.edu.au
ucc.usyd.edu.au
        origin = metro.ucc.usyd.edu.au
        mail addr = root.metro.ucc.usyd.edu.au
        serial = 316
        refresh = 3600 (1 hour)
        retry   = 1800 (30 mins)
        expire  = 36000 (10 hours)
        minimum ttl = 43200 (12 hours)

This SOA record indicates the following:

The canonical name of www.usyd.edu.au is solo.ucc.usyd.edu.au.
The origin of the DNS record is metro.ucc.usyd.edu.au (and this server is authoritative for the host solo.ucc.usyd.edu.au).
The serial number for the current record is 316. Next time a change is made to the record, the serial number should be incremented.
The refresh rate is 1 hour.
The retry rate is 30 minutes.
The expiry rate is 10 hours.
The TTL is 12 hours.

EXAM TIP
You should be able to identify the different fields in a SOA record for the exam.

We further examine the meaning of each field, when we discuss how to create DNS records for the server. The use of nslookup to determine which servers are authoritative for a particular query is not limited to individual hosts—in fact, the authoritative servers for entire networks can be determined by using nslookup. For example, if we wanted to determine which servers were authoritative for the Cook Islands top-level domain (.ck), we would use the following command:

$ nslookup
> set type=ns
> ck.
Server:  provo.cassowary.net
Address:  206.68.216.16

Non-authoritative answer:
ck      nameserver = DOWNSTAGE.MCS.VUW.AC.NZ
ck      nameserver = NS1.WAIKATO.AC.NZ
ck      nameserver = PARAU.OYSTER.NET.ck
ck      nameserver = POIPARAU.OYSTER.NET.ck
ck      nameserver = CIRCA.MCS.VUW.AC.NZ

Authoritative answers can be found from:
DOWNSTAGE.MCS.VUW.AC.NZ internet address = 130.195.6.10
NS1.WAIKATO.AC.NZ       internet address = 140.200.128.13
PARAU.OYSTER.NET.ck     internet address = 202.65.32.128
POIPARAU.OYSTER.NET.ck  internet address = 202.65.32.127
CIRCA.MCS.VUW.AC.NZ     internet address = 130.195.5.12

Some servers that are authoritative for the top-level domains of the Cook Islands are located in New Zealand. This geographic separation may seem strange, but it makes sense if you’ve ever lived through a tropical storm in Rarotonga—if the power to the OYSTER.NET.ck network was disrupted, hostnames could still be resolved through the backup servers at WAIKATO.AC.NZ.

It’s also possible to obtain a list of all the networks and hosts within a particular top-level domain by using the ls command—but be warned, the output can be verbose:

$ nslookup
> set type=ns
> ls ck.
[DOWNSTAGE.MCS.VUW.AC.NZ]
 ck.                            server = parau.oyster.net.ck
 parau.oyster.net               202.65.32.128
 ck.                            server = poiparau.oyster.net.ck
 poiparau.oyster.net            202.65.32.127
 ck.                            server = downstage.mcs.vuw.ac.nz
 ck.                            server = circa.mcs.vuw.ac.nz
 sda.org                        server = parau.oyster.net.ck
 parau.oyster.net               202.65.32.128
 sda.org                        server = poiparau.oyster.net.ck

The final tool that is often useful for resolving hostnames is the whois command. This uses InterNIC servers to perform all of the resolutions for you, and includes useful information like the registrar of the domain name (useful when making complaints about SPAM or harassment on the net!). Here’s the whois entry for paulwatters.com:

$ whois paulwatters

Whois Server Version 1.3

Domain names in the .com, .net, and .org domains can now be
registered with many different competing registrars. Go to
http://www.internic.net for detailed information.

   Domain Name: PAULWATTERS.COM
   Registrar: REGISTER.COM, INC.
   Whois Server: whois.register.com
   Referral URL: www.register.com
   Name Server: DNS19.REGISTER.COM
   Name Server: DNS20.REGISTER.COM
   Updated Date: 30-may-2000