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:
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 126.96.36.199 nameserver 188.8.131.52 nameserver 184.108.40.206
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 (220.127.116.11 and 18.104.22.168). In addition, an external secondary is also listed, corresponding to ns.utahisp.com, or 22.214.171.124.
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: 126.96.36.199 Name: paulwatters.com Address: 188.8.131.52 Aliases: www.paulwatters.com
This means that the primary DNS server for the local (cassowary.net) domain is provo.cassowary.net (184.108.40.206). 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 220.127.116.11 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: 18.104.22.168 Name: solo.ucc.usyd.edu.au Address: 22.214.171.124 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: 126.96.36.199
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: 188.8.131.52
Next, we enter the name of the host to resolve:
> www.usyd.edu.au Server: metro.ucc.su.oz.au Address: 184.108.40.206
And the IP address is returned correctly:
Name: solo.ucc.usyd.edu.au Address: 220.127.116.11 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: 18.104.22.168 > server metro.ucc.su.oz.au Default Server: metro.ucc.su.oz.au Address: 22.214.171.124 > set q=soa > www.usyd.edu.au Server: metro.ucc.su.oz.au Address: 126.96.36.199 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.
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: 188.8.131.52 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 = 184.108.40.206 NS1.WAIKATO.AC.NZ internet address = 220.127.116.11 PARAU.OYSTER.NET.ck internet address = 18.104.22.168 POIPARAU.OYSTER.NET.ck internet address = 22.214.171.124 CIRCA.MCS.VUW.AC.NZ internet address = 126.96.36.199
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 188.8.131.52 ck. server = poiparau.oyster.net.ck poiparau.oyster.net 184.108.40.206 ck. server = downstage.mcs.vuw.ac.nz ck. server = circa.mcs.vuw.ac.nz sda.org server = parau.oyster.net.ck parau.oyster.net 220.127.116.11 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