This chapter describes how to administer the Domain Name System (DNS).
The chapter covers the following topics.
A simple example resolv.conf file for a server in the doc.com domain is shown below.
; ; /etc/resolv.conf file for dnsmaster (sirius) ; domain doc.com nameserver 192.168.0.0 nameserver 192.168.0.1 |
The first line of the /etc/resolv.conf file lists the domain name in the form:
domain domainname |
Where domainname is the name that is registered with InterNIC.
No spaces or tabs are permitted at the end of the domain name. Make sure that you press return immediately after the last character of the domain name.
The second line identifies the server in the form:
nameserver 192.168.0.0 |
The next lines list the IP addresses of one or more slave or cache-only name servers that the resolver should consult to resolve queries. Name server entries have the form:
nameserver IP_address |
IP_address is the IP address of a slave or cache-only DNS name server. The resolver queries these name servers in the order the servers are listed until the resolver obtains the information it needs.
With BIND 8.3.3, the DNS client can connect to IPv6 DNS servers using an IPv6 transport. To enable such a connection, enter an IPv6 address after nameserver in the resolv.conf file.
An example /etc/resolv.conf file with IPv6 name servers would look like the following.
domain doc.com nameserver 2000::100:a00:20ff:de8a:643a nameserver 2000::55:a00:20ff:dec1:5ade nameserver 192.168.0.1 |
There can be any combination of IPv4 and IPv6 addresses for name servers in the resolv.conf file.
To configure a network for DNS, you must set up a client and a server.
Set up the clients prior to setting up the DNS server.
Become superuser.
Create the /etc/resolv.conf file.
A simple example resolv.conf file for a client (non-server) machine in the doc.com domain is shown below.
; Sample resolv.conf file for the machine polaris domain doc.com ; try local name server nameserver 127.0.0.1 ; if local name server down, try these servers nameserver 2000::16:a:a00:20ff:de8a:643a nameserver 192.168.16.7 ; sort the addresses returned by gethostbyname(3c) sortlist 130.155.160.0/255.255.240.0 130.155.0.0 |
The first line of the /etc/resolv.conf file lists the domain name in the following form.
domain domainname |
Where domainname is the name that is registered with InterNIC.
No spaces or tabs are permitted at the end of the domain name. Make sure that you enter a hard carriage return immediately after the last character of the domain name.
The second line identifies the name server in the form
nameserver 127.0.0.1 |
The next lines list the IP addresses of up to three DNS master, slave, or cache-only name servers that the resolver should consult to resolve queries. Do not list more than three servers, master or slave. Name server entries have the following form.
nameserver IP_address |
IP_address is the IP address of a master or slave DNS name server. IP_address can be either an IPv4 or an IPv6 address. The resolver queries these name servers in order until the resolver obtains the information it needs.
The fifth line of the /etc/resolv.conf file lists the address sortlist in the form:
sortlist addresslist |
addresslist specifies the sort order of the addresses returned by gethostbyname(). In our example, gethostbyname returns the netmask pair 130.155.160.0/255.255.240.0 ahead of the IP address 130.155.0.0.
Modify the /etc/nsswitch.conf file.
NIS. If your master enterprise-level naming service is NIS, with proper configuration, NIS is already DNS-enabled.
Files-based. If your master enterprise-level naming service is based on /etc files, or if your master enterprise-level naming service is NIS+, do the following.
Open the /etc/nsswitch.conf file.
DNS can be the only source or an additional source for the hosts information. Locate the hosts line and use DNS as shown below.
hosts: files dns |
or
hosts: nis dns [NOTFOUND=return] files |
or
hosts: dns nis [NOTFOUND=return] files |
Do not use the above syntax for NIS clients, or else the clients will search for unresolved names twice in DNS.
Specify DNS as a source of hosts information.
Save the file and reboot.
Become superuser.
Set the server up as a DNS client, which would include setting up the server's resolv.conf file). See How to Set Up a DNS Client.
Set up the configuration file. See Example Configuration Files.
Set up the data files. You need to set up four data files.
named.ca
hosts
hosts.rev
named.local
Initialize the server. See How to Initialize the Server.
Test the server. See How to Test Your Installation.
The most common use of DNS is to connect your network to the Internet. To connect to the Internet, your network IP address must be registered with whomever is administering your parent domain. Who that administrator is varies according to your geographic location and the type of parent domain. This manual does not describe how to register networks with domain administrators.
The two types of master server are as follows.
Zone master server. Each zone has one server that is designated as the master server for that zone. A zone's master server is the authoritative server for that zone.
Zone slave server. A zone can have one or more slave master servers. Slave master servers obtain their DNS data from the zone's master server.
To specify a server as the master server for a given zone, add the following statements in that server's named.conf file.
Create a directory for the zone files.
The following line tells the DNS name server to look for the zone data files in the specified directory. It is recommended that the directory be owned by root and have 0700 permissions. It is also recommended that the directory be on a file system that is accessible to the name server when it starts up.
options { directory "/var/named"; }; |
Statements in the options section are globally applicable configuration options and defaults for the name server. See the named.conf(4) man page for further details.
Create the master record for the zone.
The following lines designate the DNS name server as a master server for the zone. The zone definition begins with the keyword zone followed, in order, by the domain and the class. “in” denotes the Internet class and can be omitted as it is the default. The record also tells the server where to find the SOA record (Start of Authority) that makes the server authoritative for the zone. The file "db.doc.sun.com" should be in the directory specified in the options statement.
zone "doc.sun.com" in { type master; file "db.doc.sun.com"; }; |
Create a master record for the zone's reverse maps.
The following lines designate the server as a master server for the zone's reverse address map. The reverse address zone contains the zone's IP address in reverse order followed by in-addr.arpa. For example, assuming doc.sun.com zone's IP address is 10.0.0, the reverse address zone would be 0.0.10.in-addr-arpa.
zone "0.0.10.in-addr.arpa" in { type master; file "db.10.0.0"; }; |
Create a master record for the local loopback interface.
The following lines designate the server as a master server for the loopback interface.
Loopback hosts are always identified as 0.0.127.in-addr.arpa.
Thus, the following line in a configuration file specifies that the server is the master server for the reverse address domain of the loopback host using authoritative data from the file named.local.
zone "0.0.127.in-addr.arpa" in { type master; file "db.127.0.0"; }; |
Create a “root hints” file.
zone "." in { type hint; file "named.ca"; }; |
The file named.ca contains the location of the name servers for the root zone. For the doc.sun.com zone above, it would be the name servers for the sun.com domain.
A slave server maintains a copy of the data for the zone. The master server sends its data and delegates authority to the slave server. Clients can query a slave server for DNS information. By using slave servers, you can improve response time by spreading the load over multiple machines. Slave servers also provide backup when the master server crashes.
When in.named starts, the daemon requests all the data for the given zone from the master. The slave server then periodically checks with the master to see if the master needs to update its database. The process of sending the most recent zone database from the master to the slave is called a zone transfer. Therefore, you do not modify data files on a slave server. You modify the data files on the zone's master server. The slave servers then update their files from the master.
To specify that a server is to be the slave server for a given zone, you create slave records in that server's named.conf file. Separate records can designate the server as a slave server for the zone, the zone's reverse address domain, and the loopback host. A slave zone definition has a similar format as the master zone definition. The type is changed to slave and a line with the keyword masters along with the IP address(es) of the master server(s) is added.
For example, the following lines in a configuration file specify that the server is the slave server for the doc.sun.com zone and its reverse address domain. The lines also specify that the slave server obtains its authoritative data from the master server at 172.16.0.1 and initially loads its data from the file tmp.db.doc.sun.com:
zone "doc.sun.com" in { type slave; file "tmp.db.doc.sun.com"; masters { 172.16.0.1; }; }; |
A server can act as the master server for one or more zones, and as the slave server for one or more zones. The mixture of entries in the configuration file determines whether a server is a master or slave server for a given zone.
All servers are caching servers as all servers maintain a cache of DNS data. A cache-only or stub server is a server that is not a master server for any zone other than the reverse loopback zone in the in-addr.arpa. domain.
A cache-only server handles queries but does not maintain any authoritative data. The cache-only server handles queries by asking the hosts that are listed in the named.ca file for the needed information.
The following is a sample configuration file for a cache-only server. Note that the class (in) has been omitted as it is the default
; ; Sample named.conf file for caching only name server ; options { directory "/var/named"; }; zone "0.0.127.in-addr.arpa" { type master; file "db.127.0.0"; }; zone "." { type hint; file "named.ca"; }; |
This section describes how to use the +/- syntax when you use either NIS or NIS+ as your master naming service.
Become superuser.
Open the /etc/nsswitch.conf file.
Change the passwd and groups sources to compat.
For use with NIS, enter:
passwd: compat group: compat |
For NIS+, enter:
passwd: compat passwd_compat: nisplus group: compat group_compat: nisplus |
This provides the same syntax as in the Solaris 1.x release. It looks up /etc files and NIS maps as indicated by the +/- entries in the files.
Add -+ or -+ netgroup to the /etc/passwd, /etc/shadow, and /etc/group files.
You must add the -+ or -+ netgroup entries to /etc/shadow and /etc/passwd. Otherwise, you can not log in.
Save the file and reboot the system.
Some library routines do not check the nsswitch.conf file for updates. Therefore, you must reboot the machine to make sure those routines get the updated information.
To initialize a server, do the following.
Become superuser.
Install the named.conf configuration file and the required data files, as described in the previous sections.
Run in.named.
#/usr/sbin/in.named
Instead of running in.named from the command line, you can reboot.
After your configuration and data files are set up and in.named is running, test your installation.
Become superuser.
Check your syslog file for error messages.
See Chapter 6, DNS Troubleshooting (Reference) for common DNS error messages and troubleshooting information.
Look up a host name in the local domain using the nslookup command.
dnsmaster% nslookup altair Server: dnsmaster.doc.com Address: 192.146.168.5 Name: altair.doc.com Address: 192.146.168.10 |
If your lookup is successful, your name server is probably functioning correctly.
If you get a Can't find, can't initialize address, or a non-existent domain type message, your server might not be listed correctly in the configuration file or hosts files.
If you get a can't find name non-existent domain message, the host might not be in the server's hosts file. The error message could also mean that the domain is incorrectly set in resolv.conf. Additionally, the error message might indicate a general server problem.
Look up a remote domain name with nslookup.
If your network is connected to the Internet, look up the name of a remote domain. If your network is not connected to the Internet, look up the name of a subdomain in another zone, if you have another zone.
For example, to look up the name of the remote internic.net Internet domain, you would enter the following.
dnsmaster% nslookup internic.net Server: dnsmaster.doc.com Address: 192.168.168. Name: internic.net Addresses: 192.168.0.9, 192.168.0.6, 192.168.0.5, 192.168.0.8 |
If you are successful, your name server is probably functioning correctly.
If the remote domain name is not found, check your network connection.
Another possible cause is that your named.ca file is not properly installed or set up.
The second time that you use nslookup to find a domain, the answer gets returned as non-authoritative. The answer is now coming from your cache, not the remote name server.
Look up a host name in your domain from a remote domain.
If your network is connected to the Internet, look up the name of a host in your domain from a remote domain. If your network is not connected to the Internet, look up the name of a host in your domain from another zone.
For example, to look up the name of a host in your domain from a remote Internet domain, enter two arguments after the nslookup command. The first argument is the host name. The second argument is the name of the name server that you are testing.
remotemachine9% nslookup altair remotemaster.foo.org. Server: remotemaster.foo.org Address: 192.168.0.1 Name: altair.doc.com Addresses: 192.168.1.2 |
If you are successful, your name server is probably functioning correctly.
If the above command does not find the machine that you are searching for, your domain might not be registered properly.
You can add primary and secondary DNS servers to your network.
Become superuser.
Set up the server as a DNS client. See How to Add a Client.
Set up the configuration file and any zone data files specified in the configuration file.
See Setting Up DNS Servers for details.
Whenever you modify one of the DNS data files in the master DNS server, you must also do the following.
Change the serial number in the SOA resource record so the slave servers modify their data accordingly. See How to Change the SOA Serial Number.
Inform in.named on the master server that the daemon should reread the data files and update its internal database. See How to Force in.named to Reload DNS Data.
Every DNS database file begins with a Start of Authority (SOA) resource record. Whenever you alter any data in a DNS database file, you must increment the SOA serial number by one integer.
For example, if the current SOA Serial Number in a data file is 101, and you make a change to the file's data, you must change 101 to 102. If you don't change the SOA serial number, the domain's slave servers do not update their copy of the database files with the new information. The master and slave servers would then be out of sync.
A typical SOA record of a sample hosts file looks like the following.
$TTL 5h ; sample hosts file @ IN SOA nismaster.doc.com. root.nismaster.doc.com. ( 109 ; Serial 10800 ; Refresh 1800 ; Retry 3600000 ; Expire 86400 ) ; Minimum |
Therefore, if you made a change to this hosts file, you would change 109 to 110. The next time that you change the file, you would change 110 to 111.
When in.named successfully starts, the daemon writes its process ID to the file /etc/named.pid. To have in.named reread named.conf and reload the database do the following.
The above procedure eliminates all of the existing cache. The caching process then restarts.
Do not attempt to run in.named from inetd. Doing so continuously restarts the name server, which defeats the purpose of having a cache.
When you add or delete a client, always make your changes in the data files stored on your master DNS server. Do not edit the files on your slave servers. The files are automatically updated from the master server when you change the SOA serial number.
To add a client to a DNS domain, set the new machine up as a DNS client. Then, add records for the new machine to the appropriate hosts and hosts.rev files.
For example, to add the host rigel to the doc.com domain, do the following.
Become superuser.
Create a /etc/resolv.conf file on rigel.
Add dns to the hosts line of rigel's /etc/nsswitch.conf file
Add an address (A) record for rigel to the master server's hosts file.
rigel IN A 192.168.112 |
Add any additional optional records for rigel to the master server's hosts file.
Optional records could include the following.
Alias (CNAME)
Mail exchange (MX)
Well known services (WKS)
Host information (HINFO)
Add a PTR record for rigel to the hosts.rev file.
Increment the SOA serial number in the master server's hosts and hosts.rev files.
Reload the server's data.
Either reboot the server or type the following.
# kill -HUP `cat /etc/named.pid`
To remove a client from a DNS domain do the following.
Become superuser.
Remove dns from the hosts line of the machine's nsswitch.conf file.
Remove the machine's /etc/resolv.conf file.
Delete the records for that machine from the master server's hosts and hosts.rev files.
Check to see if the machine has CNAME records that point to the machine. If so, delete the CNAME records from the hosts file.
Set up replacements for services supported by the removed machine.
If the machine is a master server or a host for any other necessary process or service, set up another machine to perform those services.
You can enable a client to use IPv6 by using the following procedure.
Become superuser.
Edit the /etc/nsswitch.conf file.
Add the new ipnodes source and specify the naming service, such as LDAP.
ipnodes: ldap [NOTFOUND=return] files |
ipnodes defaults to files. During the transition from IPv4 to IPv6, where all naming services are not aware of IPv6 addresses, you should accept the files default. Otherwise, unnecessary delays might result during the resolution of addresses.
Save the file and reboot the machine.
Because the nscd daemon caches this information, you must reboot the machine.
As your network grows, you might want to divide the network into DNS subdomains. See The DNS Namespace Hierarchy for a discussion of DNS domain hierarchy and structure.
When you divide your network into a parent domain and subdomains, you reduce the load on individual DNS servers by distributing responsibility across multiple domains. Network performance then improves.
By dividing your network into geographic or organizational subdomains, the DNS domain names indicate where a given machine or email address fits into your structure. For example, rigel@alameda.doc.com implies that the machine rigel is located at your Alameda site. The email address barnum@sales.doc.com implies that the user barnum is part of your Sales organization.
The division of a network into multiple domains requires more set up work. And, you have to maintain the delegation data that ties your domains together. On the other hand, when you have multiple domains, you can distribute domain maintenance tasks among different domain administrators.
The following points are to be considered before dividing your network into a parent and subdomains.
Number of subdomains. More subdomains means more setup work and more ongoing coordination work for the parent domain administrators in the parent domain. On the other hand, fewer domains mean larger domains. The larger a domain is, the more server speed and memory is required for support.
Network divisions. You can divide your network into multiple domains however you see fit. Remember that administration is easier if your domain structure follows a consistent, logical, and self-evident pattern.
Future considerations. The most confusing domain structures have subdomains that are added haphazardly to accommodate new sites and new departments. Try to take future growth into account when designing your domain hierarchy. Take into account stability. Base your subdomains on what is most stable. For example, if your geographic sites are relatively stable but your departments frequently reorganize, base your subdomains on geography rather than organizational function. On the other hand, if your structure is stable but you frequently add sites, base your subdomains on your organizational hierarchy.
Wide area network (WAN) links. Performance will be better and reliability greater if your domains do not span the WAN. In most cases, WAN links are slower than contiguous network connections and more prone to failure. When servers support machines that can only be reached over a WAN link, more network traffic is funneled through the slower link. If there is a power failure or other problem at one site, machines at the other sites could be affected. The same performance and reliability considerations apply to DNS zones. As a general rule of thumb, zones should not span WAN links.
NIS+ compatibility. If your enterprise-level naming service is NIS+, administration is easier if your DNS and NIS+ domain and subdomain structures match.
Subdomain names. Establish and follow a consistent policy for naming your subdomains. When domain names are consistent, users are more apt to remember and correctly specify the names. Domain names are an important element in all of your DNS data files. If a subdomain name is changed, every file in which the old name appears must be edited. Therefore, choose subdomain names that are stable and unlikely to need changing. Use either full words, such as manufacturing, or abbreviations, such as manf, as subdomain names. However, users might be confused if some subdomains are named with abbreviations and others with full names. If you decide to use abbreviations, use enough letters to clearly identify the name because short cryptic names are hard to use and remember. Do not use reserved top-level Internet domain names as subdomain names. org, net, com, gov, edu, and any of the two-letter country codes such as jp, uk, ca, and it should never be used as a subdomain name.
In most cases, new subdomains are usually created from the start with a new network and new machines, or split off from an existing domain. The process is essentially similar in both cases.
Once you have planned your new subdomain, do the following.
Make sure all of the machines in the new subdomain are properly set up as DNS clients.
If you are carving a new subdomain out of an existing domain, most of the machines are probably already set up of DNS clients. If you add new machines to an existing network, you must install properly configured resolv.conf and nsswitch.conf files on each machine.
Install properly configured configuration and DNS zone data files on the subdomain's master server.
/etc/named.conf
/var/named/named.ca
/var/named/hosts
/var/named/hosts.rev
/var/named/named.local
The server host files must have an Address (A) record along with any necessary CNAME records for each machine in the subdomain. The server hosts.rev files must have a pointer (PTR) record for each machine in the subdomain. HINFO and WKS records can also be added.
If you are splitting a domain, remove the new subdomain machines records from the master server hosts and hosts.rev files.
You must delete the A records for the machines that are now in the new subdomain from the hosts files of the old domain's servers. You must also delete the PTR records for those machines from the old domain's hosts.rev files. Any optional HINFO and WKS records for the moved machines should also be deleted.
If you divide an existing domain, add the new subdomain name to CNAME records in the master server's hosts file.
For example, suppose you use the machine aldebaran as a fax server. The fax server has the following CNAME record in the hosts file of the parent domain's servers.
faxserver IN CNAME aldebaran |
You would create a faxserver CNAME record for aldebaran in the new master server's hosts file. You would also change this CNAME record in the parent domain's hosts file to include aldebaran's subdomain:
faxserver IN CNAME aldebaran.manf.doc.com |
Add NS records for the new subdomain's servers to the parent domain's hosts file.
For example, say your parent domain is doc.com. You create a new manf.doc.com subdomain with the machine rigel as manf's master server. aldebaran is the slave server. You would add the following records to the hosts file of doc.com's master server.
manf.doc.com 99999 IN NS rigel.manf.doc.com 99999 IN NS aldebaran.manf.doc.com |
Add A records for the new subdomain's servers to the parent domain's hosts file.
You would then add the following records to the hosts file of doc.com's master server.
rigel.manf.doc.com 99999 IN A 1.22.333.121 aldebaran.manf.doc.com 99999 IN A 1.22.333.136 |
Start up in.named on the subdomain's servers.
# /usr/sbin/in.named
Instead of running in.named from the command line, reboot. See in.named and DNS Name Servers.
For your convenience, the Solaris operating environment supplies a compiled version of Berkeley Internet Name Domain (BIND) version 8.3.3. The version of BIND includes security fixes that are part of BIND version 8.3.4. In compiling this software, options and choices were made to meet the needs of the greatest number of sites. If the pre-compiled version of BIND does not meet your requirements, you can recompile your own version of BIND from the publicly available source code.
In compiling the BIND version supplied with the Solaris operating environment, the following choices were made.
RFC1535. Not implemented because doing so would remove implicit search lists.
Inverse Queries. Enabled because SunOS 4 nslookup does not work otherwise.
Default Domain Name. If the DNS domain name is not set in /etc/resolv.conf, or through the LOCALDOMAIN
environment variable, libresolv() derives the DNS domain name from the NIS or NIS+
domain name.
Utility Scripts. The BIND utility scripts are not included in this Solaris release.
Test Programs. The BIND test programs dnsquery and host are not included in this Solaris release because their purpose is similar to the purposes of nslookup and dig.
As of the Solaris 9 release, the named.boot file is ignored.
Become superuser.
Convert the DNS configuration file.
Run the Korn shell script, /usr/sbin/named-bootconf, to convert a BIND 4.9.x named.boot file to a BIND 8.3.3 named.conf file.
The nsswitch.conf file controls DNS forwarding and Interent access for clients. NIS clients have implicit forwarding capabilities. NIS+ clients do not. See below.
Become superuser.
Properly configure the hosts line in the /etc/nsswitch.conf file to read: hosts: nisplus dns files.
In this implementation of NIS, if a /etc/resolv.conf file exists on the server, ypstart automatically starts the ypserv daemon with the -d option to forward requests to DNS. To stop forwarding to DNS, edit the /usr/lib/netsvc/yp/ypstart script to remove the -d option from the ypserv command. You must then reboot the machine.
Become superuser.
Set the YP_INTERDOMAIN key in the hosts.byname map. Set the hosts.byaddr map by modifying the following lines in the Makefile.
#B=-b B= |
to
B=-b #B= |
Now makedbm starts with the -b flag when making the maps, and inserts the YP_INTERDOMAIN into the ndbm files.
Rebuild the maps.
# /usr/ccs/bin/make hosts |
Make sure that all NIS servers have an /etc/resolv.conf file that points to valid name server(s).
Stop each server with the ypstop script.
# /usr/lib/netsvc/yp/ypstop |
Restart each server with the ypstart script.
# /usr/lib/netsvc/yp/ypstart |
If you have NIS servers that are not running the Solaris 2 release or higher, make sure that the YP_INTERDOMAIN key is present in the host maps. In addition, problems might arise if the master server and slave server are running different versions of Solaris. The following table summarizes the commands to issue to avoid such problems. The notation “4.0.3+” means “release 4.0.3 of SunOS or later.” The command makedbm -b is a reference to the “-B” variable in the Makefile.
SLAVE |
MASTER |
||
---|---|---|---|
|
4.0.3+ |
Solaris NIS |
|
4.0.3+ |
Master: makedbm -b Slave: ypxfr |
Master: makedbm -b Slave: ypxfr -b |
Master: ypserv -d Slave: ypxfr -b |
Solaris NIS |
Master: makedbm -b Slave: ypxfr |
Master: makedbm -b Slave: ypxfr |
Master: ypserv -d Slave: ypxfr with resolv.conf or ypxfr -b |
The Solaris operating environment includes the dynamic library routines that make up the resolver.