This part gives an overview of the Domain Name System (DNS) and describes how to setup DNS clients and servers. It has two chapters.
Chapter 12, Setting Up DNS Clients, Setting Up DNS Clients
Chapter 13, Setting Up DNS Servers, Setting Up DNS Servers
This chapter describes how to set up Domain Name System (DNS) service on client machines.
One of the most common, and important, uses of DNS is connecting your network to the global Internet. In order 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 type of parent domain. This manual does not describe how to register networks with domain administrators.
For more detailed information, see DNS and Bind, by Cricket Liu and Paul Albitz (O'Reilly, 1992).
For your convenience, the Solaris 2.6 releasesupplies a compiled version of Berkeley Internet Name Domain (BIND) version 4.9.4, Patch-Level 1. In compiling this software, options and choices were made to meet the needs of the greatest number of sites. If this 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 2.6 release, the following choices were made:
RFC1535. Not implemented since because doing so would remove implicit search lists.
Inverse Queries. Enabled because SunOS 4.x nslookup will not work without them.
Bogus Name Logging. Logging of bogus name servers is not implemented because it produces too many unimportant messages.
Default Domain Name. If the DNS domain name is not set in /etc/resolv.conf, or via the LOCALDOMAIN
environment variable, libresolv derives it from the NIS or NIS+ domain name provided that the /etc/nsswitch.conf file contains nisplus or nis as the first element in the hosts line.
Utility Scripts. The BIND utility scripts are not included in this Solaris release.
Test Programs. The BIND test programs dig, dnsquery, and host are not included in this Solaris release because their purpose is similar to that of nslookup and nstest.
Setting up DNS service is accomplished in two basic steps:
Set up DNS service on your client machines. This chapter describes how to do this.
Set up your DNS servers as described in Chapter 13, Setting Up DNS Servers.
Setting up DNS on a client machine involves two tasks
Creating the /etc/resolv.conf file as described in"Creating the resolv.conf File".
Modifying the /etc/nsswitch.conf file, as described in "Enabling a Machine to Use DNS".
If you are setting up DNS service on a host that will function as a DNS server, you also need to set up boot and data files as described in Chapter 13, Setting Up DNS Servers.
DNS clients use the dynamic library routines, collectively called the resolver, to locate a remote host. The resolver queries the DNS database on a name server, which eventually returns the host name or IP address of the machine requested by the resolver. Because DNS name servers are clients of servers outside their local domains, they must also run the resolver.
The DNS name server uses several files to load its database. At the resolver level, it needs the file /etc/resolv.conf listing the addresses of the servers where it can obtain its information. The resolver reads this resolv.conf file to find the name of the local domain and the location of name servers. It sets the local domain name and instructs the resolver routines to query the listed name servers for information. Normally, each DNS client system on your network has a resolv.conf file in its /etc directory. (If a client does not have a resolv.conf file it defaults to using a server at IP address 127.0.0.1.)
Whenever the resolver has to find the IP address of a host (or the host name corresponding to an address), the resolver builds a query package and sends it to the name servers listed in /etc/resolv.conf. The servers either answer the query locally or contact other servers known to them, ultimately returning the answer to the resolver.
A simple example resolv.conf file for a client (non-server) machine in the doc.com domain is shown in Example 12-1:
; 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 123.45.6.1 nameserver 111.22.3.5 |
The first line of the /etc/resolv.conf file lists the domain name in the form:
domain domainname |
Where domainname is the name registered with the Internet governing bodies (as of this writing, the 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 loopback name server in the form:
nameserver 127.0.0.1 |
Succeeding lines list the IP addresses of up to three DNS master, secondary, or cache-only name servers that the resolver should consult to resolve queries. (Do not list more than three primary or secondary servers.) Name server entries have the form:
nameserver IP_address |
Where IP_address is the IP address of a primary or secondary DNS name server. The resolver queries these name servers in the order they are listed until it obtains the information it needs.
How you enable a machine to use DNS depends on your underlying enterprise-level name service:
NIS+. If your primary enterprise-level name service is NIS+, follow the directions described in "Enabling a Machine to Use DNS".
NIS. If your primary enterprise-level name service is NIS, and it is correctly set up, do nothing. With proper configuration, NIS is ready to use DNS from the time it is installed.
Files-based. If your primary enterprise-level name service is based on /etc files, follow the directions described in "Enabling a Machine to Use DNS".
For additional information on the nsswitch.conf file, see Solaris Naming Administration Guide.
This chapter describes how to set up a Domain Name System (DNS) name server.
To set up a DNS server:
Set the server up as a DNS client (this includes setting up the server's resolv.conf file.
Set up the boot file.
Set up the data files
See "Setting Up the Data Files". Four data files have to be set up:
Initialize the server.
Test the server.
See "Testing Your Installation".
The most common use of DNS is to connect your network to the global Internet. In order 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 type of parent domain. This manual does not describe how to register networks with domain administrators.
To function correctly, the in.named daemon requires a boot file and four data files.
The IP addresses and network numbers used in examples and code samples in this manual are for illustration purposes only. Do not use them as shown because they may have been assigned to an actual network or host.
The master server boot file is /etc/named.boot. (See "Setting Up the Boot File".) The boot file contains a list of domain names and the file names containing host information. (See Solaris Naming Administration Guide for additional information on the named.boot file.)
So long as you are internally consistent, you can name the zone data files anything you want. This flexibility may lead to some confusion when working at different sites or referring to different DNS manuals and books.
For example, the file names used in Sun manuals and at most many Solaris sites vary from those used in the book DNS and BIND by Albitz and Liu, O'Reilly & Associates, 1992, and both of those nomenclatures have some differences from that used in the public-domain Name Server Operations Guide for BIND, University of California.
In addition, this manual and other DNS documentation uses generic names that identify a file's main purpose, and specific example names for that file in code record samples. For example, Solaris Naming manuals use the generic name hosts when describing the function and role of that file, and the example names db.doc and db.sales in code samples.
For reference purposes, Table 13-1 compares BIND file names from these three sources:
Table 13-1 File Name Examples
Solaris Names |
O'Reilly Names or other names |
U.C. Berkeley Names |
Content and Purpose of File |
---|---|---|---|
/etc/named.boot |
/etc/named.boot |
/etc/named.boot |
The boot file specifies the type of server it is running on and the zones over which it has control. It contains a list of domain names and the names of the data files. |
/etc/resolv.conf |
/etc/resolv.conf |
/etc/resolv.conf |
This file resides on every DNS client (including DNS servers) and designates the servers which the client queries for DNS information. |
named.ca |
db.cache db.root |
root.cache |
This file establishes the names of root servers and lists their addresses. |
Generic: hosts Examples: db.doc db.sales |
Generic: db.domain Examples: db.movie db.fx |
Generic: hosts Example: ucbhosts |
This file contains all the data about the machines in the local zone that the server serves. |
Generic: hosts.rev Examples: doc.rev |
Generic: db.ADDR Examples: db.192.249.249 db.192.249.253 |
hosts.rev |
This file specifies a zone in the in-addr.arpa. domain, a special domain that allows reverse (address-to-name) mapping. |
named.local |
Generic: db.cache Example: db.127.0.0 |
named.local |
This file specifies the address for the local loopback interface, or localhost |
$INCLUDE files |
$INCLUDE files |
$INCLUDE files |
Any file identified by an $INCLUDE() statement in a data file. |
The four required data files are:
/var/named/named.ca. (See "Setting Up the named.ca File" and Solaris Naming Administration Guide for additional information on the named.ca file.) So long as you are internally consistent, you can name this file anything you want.
/var/named/hosts. (See "Setting Up the hosts File" and Solaris Naming Administration Guide for additional information on hosts files.)
The name hosts is a generic name indicating the file's purpose and content. But to avoid confusion with /etc/hosts, you should name this file something other than hosts. The most common naming convention is db.domainname. Thus, the hosts file for the doc.com domain would be called db.doc.
If you have more than one zone, each zone must have its own hosts file and each of these zone hosts files must have a unique name. For example, if your DNS domain is divided into doc.com and sales.doc.com zones, you could name one hosts file db.doc and the other db.sales.
/var/named/hosts.rev. See "Setting Up the hosts.rev File" and Solaris Naming Administration Guide for additional information on the hosts.rev file.)
The name hosts.rev is a generic name indicating the file's purpose and content. If you have more than one zone, each zone must have its own hosts.rev file and each of these zone hosts.rev files must have a unique name. For example, if your DNS domain is divided into doc.com and sales.doc.com zones, you could name one hosts.rev file doc.rev and the other sales.rev.
/var/named/named.local. See "Setting Up the named.local File" and Solaris Naming Administration Guide for additional information on the named.local file.) So long as you are internally consistent, you can name this file anything you want.
An include file is any file named in an $INCLUDE() statement in a DNS data file. $INCLUDE files can be used to separate different types of data into multiple files for your convenience. (See Solaris Naming Administration Guide for additional details.)
A domain name is the name assigned to a group of systems on a local network that share DNS administrative files. A domain name is required for the network information service database to work properly.
DNS obtains your default domain name from your resolv.conf file.
If the resolv.conf file is not available, or does not identify a default domain, and if your enterprise-level name service is either NIS+ or NIS, the Sun implementation of DNS obtains the default domain name from those services.
If resolv.conf is not available or does not provide a domain name and you are not running either NIS+ or NIS, you must either provide a resolv.conf file on each machine that does specify the domain , (see "Setting Up the resolv.conf File"), or set the LOCALDOMAIN
environment variable.
When working with DNS-related files, follow these rules regarding the trailing dot in domain names:
Use a trailing dot in domain names in hosts, hosts.rev, named.ca, and named.local data files. For example, sales.doc.com. is correct for these files.
Do not use a trailing dot in domain names in named.boot or resolv.conf files. For example, sales.doc.com is correct for these files.
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 0.0.0.0 nameserver 111.22.3.5 |
The first line of the /etc/resolv.conf file lists the domain name in the form:
domain domainname |
Where domainname is the name registered with the Internet governing bodies (as of this writing, the 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 server itself in the form:
nameserver 0.0.0.0 |
Succeeding lines list the IP addresses of one or two secondary or cache-only name servers that the resolver should consult to resolve queries. Name server entries have the form:
nameserver IP_address |
Where IP_address is the IP address of a secondary or cache only DNS name server. The resolver queries these name servers in the order they are listed until it obtains the information it needs.
The contents of the boot file varies, depending on the type of server. This section describes boot files for primary, secondary, and caching-only servers.
The boot file must be called named.boot. The server's initialization script, /etc/init.d/inetsvc, expects to find /etc/named.boot when it looks for the in.named daemon boot file. The script will not start the daemon if you name the boot file anything else.
; named.boot file on the dnsmastr ; ; files required by in.named are located here directory /var/named ; here are the names of the primary files cache . named.ca primary doc.com db.doc primary 0.0.127.in-addr.arpa db.127.0.0 primary 6.45.123.in-addr.arpa db.123.45.6 ;This system is also the secondary for the sales.doc.com domain secondary sales.doc.com 111.22.3.4 db.sales secondary 3.22.111.in-addr.arpa 111.22.3.4 db.192.168.8 |
In the context of the various example files presented in this chapter, the sample boot file above corresponds to the boot file of the dnsmaster, server which is an alias for the altair machine whose IP address is 123.45.6.1.
A boot file contains three elements:
A directory line (see "The directory Line").
A cache line (see "The cache Line").
One or more name server lines (see "Specifying Server Function").
The directory line in the boot file designates the directory in which you want the name server to run:
directory /var/named |
This allows the use of relative path names for the files mentioned in the boot file or, later, with the $INCLUDE
directive. This feature is especially useful if you have many files to be maintained, and you want to locate them all in one directory dedicated to that purpose.
If there is no directory line in the boot file, all file names listed in the boot file must be full path names.
A name server needs to know which servers are the authoritative name servers for the root zone. To do this, you have to list the addresses of these higher authorities.
All servers should have the following line in the boot file to find the root name servers:
cache . named.ca |
The first field after cache (.) indicates that the server will obtain root servers hints from the indicated file, in this case, named.ca (located in the directory /var/named).
The server role lines specify whether the server is a primary and secondary name server as described in "Specifying Server Function", below.
DNS servers perform one or more functions:
Zone primary master server. Each zone has one server that is designated as the primary master server for that zone. A zone's primary master server is the authoritative server for that zone. (See "Specifying a Primary Master Server".)
Zone secondary master server. A zone may have one or more secondary master servers. Secondary master servers obtain their DNS from the zone's primary master server. You do not modify data files on a secondary server; you modify the data files on the zone's primary server and the secondary servers update their files from the primary. (See "Specifying a Secondary Master Server".)
Caching-Only Server. All servers are caching servers in the sense that they all maintain a cache of DNS data. A caching-only server is a server that is not a master server for any zone other than the in-addr.arpa. domain. (See "Specifying a Cache-Only Server".)
Root Domain servers. If your network is connected to the Internet, your root domain servers are out on the Internet itself and all you have to do is provide their Internet IP addresses in the named.ca file, as explained in "Setting Up the named.ca File". If your network is not connected to the Internet, you have to set up your own root domain server, as explained in "Setting Up a Non-Internet Root Master".
These various server functions can be performed by the same machine. For example, a machine can be a primary master server for one zone and a secondary master server for another zone. When this manual refers to a primary, secondary, or caching-only server, it is not referring to a particular machine, but the role that machine plays for a given zone.
Refer to Solaris Naming Administration Guide for additional information on these different server functions.
To specify that a server is the primary server for a given zone, you create three primary records in that server's named.boot file:
Create the primary record for the zone.
This record designates the server as a primary server for the zone and tells the server where to find the authoritative hosts file. A "primary" record has three fields:
The first field designates the server as "primary."
The second field identifies the zone it serves.
For example, the following line in a boot file specifies that the server is the primary server for the doc.com zone, using authoritative data from the file db.doc:
primary doc.com db.doc |
Create a primary record for the zone's reverse map.
This record designates the server as a primary server for the zone's reverse address map (that is, the reverse address domain for doc.com), and tells the server where to find the authoritative hosts file. This record has three fields; the first field designates the server as "primary," the second field identifies the zone, and the third field identifies the hosts.rev file.
The reverse address domain for a zone is the composed by the zone's IP address in reverse order followed by in-addr.arpa. For example, suppose that the doc.com zone's IP address is 123.45.6. In that case, the reverse address domain would be 6.45.123.in-addr.arpa.
Thus, the following line in a boot file specifies that the server is the primary server for the reverse address domain of the doc.com zone, using authoritative data from the file doc.rev:
primary 6.45.123 . in-addr.arpa doc.rev |
Create a primary record for the reverse address of the local loopback interface or host.
This record designates the server as a primary server for the loopback host, and tells the server where to find the authoritative hosts file. This record has three fields, the first field designates the server as "primary," the second field identifies the loopback host reverse address, and the third field identifies the hosts file.
Loopback hosts are always identified as 0.0.127.in-addr.arpa.
Thus, the following line in a boot file specifies that the server is the primary server for the reverse address domain of the loopback host using authoritative data from the file named.local:
primary 0.0.127.in-addr.arpa named.local |
To specify that a server is to be the secondary server for a given zone, you create "secondary" records in that server's named.boot file. Separate records can designate the server as a secondary server for the zone, the zone's reverse address domain, and the loopback host.
A "secondary" record has three required fields:
The first field designates the server as "secondary."
The second field identifies the zone it serves.
The third field identifies the IP address of the primary server for the zone from which the secondary server obtains its authoritative data.
A "secondary" record may have one or more optional fields after the required fields. The optional fields are:
Secondary servers. After the IP address of the primary server, you can add IP addresses of other secondary servers. These provide additional sources from which the secondary server can obtain data. Adding IP addresses of secondary servers may under some circumstances reduce performance, unless those IP addresses are additional network addresses of a multihome primary server.
Backup file. After the IP address of the primary (and optional secondary) server(s), you can add the name of a backup hosts file. If a backup file name is present, the secondary server loads its data from that file, then checks with the primary (and optional secondary) servers to make sure that the data in the backup file is up to date. If the backup file is not up to date, it is brought up to date, based on the information received from the primary server.
For example, the following lines in a boot file specify that the server is the secondary server for the doc.com zone and its reverse address domain; that it obtains its authoritative data from the primary server with an IP address of 129.146.168.119, that it uses the server 192.146.168.38 as a secondary source of zone data, and initially loads its data from the file doc.com.bakup:
secondary doc.com 129.146.168.119 192.146.168.38 doc.com.bakup secondary 4.0.32.128.in-addr.arpa 129.146.168.119 |
In the context of the various example files presented in this chapter, the sample boot file lines above correspond to the boot file of the dnssecondary server, which is an alias for the sirius machine whose IP address is 192.146.168.38.
A server may act as the primary server for one or more zones, and as the secondary server for one or more zones. The mixture of entries in the boot file determines whether a server is a primary or secondary server for a given zone
A cache-only server does not maintain any authoritative data; it handles queries and asks the hosts listed in the in.named file for the information needed. In other words, a cache-only server handles the same kind of queries that authoritative name servers perform but it does not maintain any authoritative data itself.
Example 13-3 is a sample boot file for a caching-only server.
; ; Sample named.boot file for caching-only name server ; ; type domain source file or host ; directory /var/named cache . named.ca primary 0.0.127.in-addr.arpa named.local |
You do not need a special line to designate a server as a cache-only server. What denotes a cache-only server is the absence of any secondary or primary authority lines in the boot file, except as noted below.
A cache-only server requires:
A directory line in the boot file
A primary 0.0.127.in-addr.arpa line in the boot file
A cache . named.ca line in the boot file
All the data files used by the DNS daemon in.named are written in standard resource record format. Each line of a file is a record, called a resource record (RR). Each DNS data file must contain certain resource records.
See Solaris Naming Administration Guide for a description of resource records, their formats, the fields they contain, special characters, and control entries.
The most commonly used types of resource records are listed in Table 13-2. They are usually entered in the order shown in Table 13-2, but that is not a requirement.
Table 13-2 Commonly Used Resource Record Types
Type |
Description |
---|---|
SOA |
start of authority |
NS |
name server |
A |
Internet address (name to address) |
PTR |
pointer (address to name) |
CNAME |
canonical name (nickname) |
TXT |
text information |
MX |
mail exchanger |
See Solaris Naming Administration Guide for detailed descriptions of these Resource Record types.
In the sample files included in the following sections, @ indicates the current zone or origin and lines that begin with a semicolon (;) are comments.
he root servers. Root server names are indicated in the NS record and addresses in the A record. You need to add an NS record and an A record for each root server you want to include in the file.
How you obtain or create your named.ca file depends on whether or not your network is connected to the world Internet.
If your network is connected to the Internet, at the present time you obtain your named.ca file from InterNIC registration services via:
Anonymous FTP. The FTP site is: ftp.rs.internic.net. The file name is: /domain/named.root.
Gopher. The Gopher site is: rs.internic.net. The file is: named.root, which can be found under the InterNIC Registration Services menu, InterNIC Registration Archives submenu.
If you are following the naming conventions used in this manual, you then move named.root to /var/named/named.ca.
; ; formerly NS1.ISI.EDU . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ; ; formerly C.PSI.NET . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ; ; formerly TERP.UMD.EDU . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ; ; formerly NS.NASA.GOV ;. 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ; ; formerly NS.ISC.ORG . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 ; ; formerly NS.NIC.DDN.MIL . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 ; ; formerly NIC.NORDU.NET . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ; ; temporarily housed at NSI (InterNIC) . 3600000 NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10 ; ; temporarily housed at NSI (InterNIC) . 3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 198.41.0.11 ; ; temporarily housed at ISI (IANA) . 3600000 NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12 ; ; temporarily housed at ISI (IANA) . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 198.32.65.12 ; End of File |
If your network is not connected to the Internet, you create your own named.ca file. To do this, you designate one of your servers to be your root server, then create a named.ca file on every DNS server pointing to that root server.
For example, suppose your domain is named private and you designate the machine ourroot as your non-Internet root server. The ourroot machine has an IP address of 192.1.1.10. Your named.ca files would then contain the line:
ourroot.private. 999999 IN A 192.1.1.10 |
Cache files also need an SOA record, NS records for each domain and subdomain, and A records for each server.
For example, suppose that in addition to ourroot you also had DNS name servers called ourprimary and oursecondary. The named.ca files on all of your DNS servers would then look like this:
; @ IN SOA ourroot.private. hermit.ourroot.private ( 1997071401 ; serial number (YYYYMMDD##) 10800 ; refresh after 3 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day ; ourroot.private. 999999 IN A 192.1.1.10 ; private. IN NS ourprimary.private. 1.1.192.in-addr.arpa IN NS ourprimary.private. ourprivate.private. IN A 192.1.1.1 ; private. IN NS oursecondary.private. 1.1.192.in-addr.arpa IN NS ourseconary.private. oursecondary.private. IN A 192.1.1.2 |
See "Setting Up a Non-Internet Root Master" for a more complete discussion of setting up a domain that is not connected to the Internet.
The hosts file contains all the data about every machine in your zone. If a zone covers more than one domain, all machines in all the domains covered by the zone are listed in the zone's host file (see "Setting Up Subdomains--Same Zone").
The name hosts is a generic name indicating the file's purpose and content. But to avoid confusion with /etc/hosts, you should name this file something other than hosts. If you have more than one zone, each zone must have its own hosts file and each of these zone hosts files must have a unique name. For example, if your DNS domain is divided into doc.com and sales.doc.com zones, you could name one hosts file db.doc and the other sales.db.doc.
There must be a separate, uniquely named, hosts file for each zone. If you have more than one zone, each zone's host file must include information about the master (primary and secondary) servers of the other zones as described in "Setting Up Subdomains--Different Zones".
; ; SOA rec doc.com IN SOA sirius.doc.com sysop.centauri.doc.com ( 1997071401 ; serial number (YYYYMMDD##) 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers doc.com IN NS sirius.doc.com sales.doc.com IN NS altair.sales.doc.com ; Addresses localhost IN A 127.0.0.1 sirius IN A 123.45.6.1 rigel IN A 123.45.6.112 antares IN A 123.45.6.90 polaris IN A 123.45.6.101 procyon IN A 123.45.6.79 tauceti IN A 123.45.6.69 altair.sales.doc.com IN A 111.22.3.4 ; aliases durvasa IN CNAME sirius.doc.com dnsmastr IN CNAME sirius.doc.com dnssales IN CNAME altair.sales.doc.com |
A hosts file usually contains five elements:
A Start of Authority (SOA) record
One or more Name Server (NS) records identifying primary and secondary DNS name servers
Address (A) records for each host in the zone
Canonical Name (CNAME) records for each host alias in the zone
One or more Mail Exchange (MX) records
(See Solaris Naming Administration Guide for detailed descriptions of these resource record types.)
The hosts.rev file sets up inverse mapping.
The name hosts.rev is a generic name indicating the file's purpose and content. If you have more than one zone, each zone must have its own hosts.rev file and each of these zone hosts.rev files must have a unique name. For example, if your DNS domain is divided into doc.com and sales.doc.com zones, you could name one hosts.rev file doc.rev and the other sales.rev.
; SOA rec 6.45.123.in-addr.arpa. IN SOA sirius.doc.com sysop.centauri.doc.com ( 1997071401 ; serial number (YYYYMMDD##) 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers 6.45.123.in-addr.arpa. IN NS sirius.doc.com 1 IN PTR sirius.doc.com |
A hosts.rev file contains three elements:
A Start of Authority (SOA) record
One or more Name Server (NS) records identifying primary and secondary DNS name servers. Server names should be fully qualified.
A PTR record for each host in the zone. Machine names should be fully qualified.
(See Solaris Naming Administration Guide for detailed descriptions of these resource record types.)
The named.local file sets up the local loopback interface for your name server.
; SOA rec 0.0.127.in-addr.arpa. IN SOA sirius.doc.com sysop.centauri.doc.com ( 1997071401 ; serial number (YYYYMMDD##) 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers 0.0.127.in-addr.arpa. IN NS sirius.doc.com 1 IN PTR localhost. |
A named.local file contains three elements:
A Start of Authority (SOA) record, which indicates the start of a zone and includes the name of the host on which the named.local data file reside.
One or more Name Server (NS) records identifying primary and secondary DNS name servers. Server and domain names should be fully qualified.
A PTR record for localhost
(See Solaris Naming Administration Guide for detailed descriptions of these resource record types.)
To initialize a server:
Install the named.boot boot 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 boot and data files are set up and in.named running, test your installation as follows:
Check your syslog file for error messages.
See Solaris Naming Administration Guide for common DNS error messages and troubleshooting information.
Look up a host name in the local domain with nslookup.
dnsmaster% nslookup altair Server: dnsmaster.doc.com Address: 192.146.168.5 Name: altair.doc.com Address: 192.146.168.10 |
If you get a successful result, your name server is probably functioning correctly.
If you get a "Can't find," or "can't initialize address," type of message for your server, or a "Non-existent domain," type message, it may mean that your server is not correctly listed in the boot or hosts files.
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 one.) For example, to look up the name of the remote internic.net Internet domain, you would enter:
dnsmaster% nslookup internic.net Server: dnsmaster.doc.com Address: 192.146.168. Name: internic.net Addresses: 198.41.0.9, 198.41.0.6, 198.41.0.5, 198.41.0.8 |
If you get a successful result, your name server is probably functioning correctly.
If the above command does not find the remote domain name, one possible cause is that your network's connection to the Internet is not functioning properly.
Another possible cause is that your named.ca file is not properly installed or set up.
(The second time you use nslookup to find a domain, your answer will be returned as "non-authoritative". This is normal because 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, if you have one.)
For example, to look up the name of host in your domain from a remote Internet domain, you would enter two arguments after the nslookup command: First the name of the host you are searching for, and second, the name of the name server you are testing:
remotemachine9% nslookup altair remotemaster.foo.org. Server: remotemaster.foo.org Address: 123.231.12.22 Name: altair.doc.com Addresses: 111.22.3.4 |
If you get a successful result, your name server is probably functioning correctly.
If the above command does not find the machine you are searching for, one possible cause is that your domain is not properly registered with whomever is administering the parent domain (.com in the above example).
Same zone. The easiest method is to include the subdomain in the parent domain's zone. In this way, one set of DNS servers and data files cover all the machines regardless of their domain. See "Setting Up Subdomains--Same Zone".
The advantage of the same-zone method is simplicity and ease of administration. The disadvantage is that one set of servers has to serve all machines in all of the zone's domains. If there are too many machines, the servers will be overloaded and network performance may decline.
Different zones. You can place different domains in different zones. This is more complex because you have to specify how clients in one zone obtain DNS information about hosts in another zone. See "Setting Up Subdomains--Different Zones".
The advantage of the different-zone method is that you can assign different sets of servers to serve machines in different domains; in that way, you spread out server load so that no group of servers is overloaded. The disadvantage is that setup maintenance is more complicated.
Data files for multi-domain zones must include records for all machines and servers in each domain covered by the zone.
Setting up a multi-domain zone is the same as setting up a zone with a single domain, except that fully qualified domain names are used in the hosts file to identify machines in remote domains. In other words, in the hosts file, when you identify a machine in the server's local domain, you only need to use the machine's name. But when you identify a machine in some other domain, you must identify the machine with a fully qualified domain name in the format: machine.domain.
Server and machine names in hosts.rev and named.local files also need to be fully qualified with domain names. But that is true regardless of whether or not the zone has more than one domain.
Setting up subdomains that are in different zones is more complicated than including multiple domains in a single zone, because you have to specify how clients in different zones obtain DNS information from the other zones.
When you divide a network into multiple domains, you do so by creating a domain hierarchy. That is, one domain is the top domain. Beneath the top domain, you create one or more subdomains. If you want, you can create subdomains of subdomains. But every subdomain has a set place relative to the top domain in the hierarchy of domains. When read from left to right, domain names identify the domain's place in the hierarchy. For example, the doc.com domain is above the sales.doc.com domain, while the west.sales.doc.com domain is below the sales.doc.com domain.
DNS zones acquire a hierarchy from the domains that they contain. The zone containing a network's top domain is the top zone. A zone that contains one or more subdomains below the top domain is below the top zone in the zone hierarchy. When DNS information has to be passed from one zone to another, it is passed up and down the zone hierarchy. This means that each zone has to have records in its data files specifying how to pass information up to the zone immediately above it, and down to any zones immediately below it.
To correctly transfer DNS information from one zone to another in a multi-zone network:
hosts.rev file. There must be a PTR record in each hosts.rev file pointing to the name of one or more master servers in the zone immediately above it. This type of PTR record is exactly the same as any other PTR record in the file, except that it identifies a server in the zone above.
hosts file NS records. There must be a zone NS record in each hosts file identifying each name server in each zone immediately below. This type of NS record has to have the name of the zone below as the first field in the NS record. (The name of the zone is specified in the SOA record of the zone's host file.)
hosts file A records. There must be an A record in each hosts file identifying the IP address of each name server in each zone immediately below. This type of A record has to have the name of the zone below as the first field in the A record. (The name of the zone is specified in the SOA record of the zone's host file.)
The example files in "A Practical Example" illustrate a network with two zones.
If your network is connected to the Internet, your root domain server exists at the root domain Internet site; all you have to do is provide that site's Internet IP addresses in your cache file, as explained in "Internet named.ca File".
If your network is not connected to the Internet, you must set up primary and secondary name servers in the root-level domain on your local network. This enables all domains in your network to have a consistent authoritative server to which to refer; otherwise, machines may not be able to resolve queries.
For example, suppose your non-Internet domain is named private and you designate the machine ourroot as your root server. The ourroot machine has an IP address of 192.1.1.10. You would then perform the following steps:
Create named.ca files on your primary master servers that point to your own root server.
For example:
ourroot.private. 999999 A 192.1.1.10 |
A named.ca file must also contain NS records for each internal domain and subdomain and A records for each server as described in "Setting Up a Non-Internet Root Master".
Add a cache resource record for the root domain to the boot files of all DNS name servers on your network.
For example:
cache . named.ca |
(See "Boot File"for more information.)
Remove the root domain cache resource record from the boot file of your root server.
In other words, delete the cache . named.ca line from ourroot's boot file.
Insert a primary line for the root domain in the root server's boot file.
For example, in ourroot's boot file you would add the line:
primary . ourroot.private |
If you later decide to connect your network to the Internet, you must replace all the named.ca files on all of your servers with the current Internet files and replace the primary . rootserver line with a cache . named.ca line in the former root server's boot file.
This section shows the files that would be needed to implement DNS for a sample Internet-connected network based on the examples used in this chapter.
The IP addresses and network numbers used in examples and code samples in this manual are for illustration purposes only. Do not use them as shown because they may have been assigned to an actual network or host.
This practical example assumes:
An environment connected to the Internet
Two networks, each with its own domain (doc.com and sales.doc.com) and its own DNS zone
Thedoc.com domain and zone is the top zone over the sales.doc.com subdomain and zone.
Each network has its own network number
Name and Zone |
Number |
---|---|
doc.com |
123.45.6 |
sales.doc.com |
111.22.3 |
Each zone has a master and one secondary server, and the secondary server of sales.doc.com is also the primary server of doc.com:
Zone |
Host Name |
Function |
Address | CNAME |
---|---|---|---|---|
doc.com |
sirius |
primary for doc.com |
123.45.6.1 | dnsmaster |
doc.com |
deneb |
secondary for doc.com |
111.22.3.5 | dnssecond |
sales.doc.com |
altair |
primary for sales.doc.com |
111.22.3.4 | dnssales |
sales.doc.com |
altair |
secondaryfor sales.doc.com |
123.45.6.1 | dnsmaster |
The following code examples show boot files for the three servers in the two networks:
; named.boot file on the dnsmastr (sirius) ; ; files required by in.named are located here directory /var/named ; here are the names of the primary files cache . named.ca primary doc.com db.doc primary 0.0.127.in-addr.arpa named.local primary 6.45.123.in-addr.arpa doc.rev ;This system is also the secondary for the sales.doc.com domain secondary sales.doc.com 111.22.3.4 db.sales secondary 3.22.111.in-addr.arpa 111.22.3.4 sales.rev |
; named.boot file on the dnssales (altair) ; ; in.named is located here directory /var/named ; here are the names of the primary files cache . named.ca primary sales.doc.com db.sales primary 0.0.127.in-addr.arpa db.127.0.0 primary 3.22.111.in-addr.arpa db.192.168.8 |
; named.boot file on the dnsecond (deneb) directory /var/named cache . named.ca secondary doc.com 123.45.6.1 doc.com secondary 6.45.123.in-addr.arpa 123.45.6.1 doc.123.45.6 |
The following code examples show resolv.conf files for the three servers in the two networks. (If the host in question is not running in.named, the local host address should not be used as a name server.)
; ; /etc/resolv.conf file for dnsmaster (sirius) ; domain doc.com nameserver 0.0.0.0 nameserver 111.22.3.5 |
; ; /etc/resolv.conf file for dnssales (altair) ; domain sales.doc.com nameserver 111.22.3.4 nameserver 123.45.6.1 |
; ; /etc/resolv.conf for dnssecond ; domain doc.com nameserver 111.22.3.5 nameserver 123.45.6.1 |
The following code example shows the named.local file used by the two primary servers on the two networks. Both servers have the same file.
; SOA rec 0.0.127.in-addr.arpa. IN SOA siriusdoc.com. sysop.centauri.doc.com. ( 19970331 ; serial number 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers 0.0.127.in-addr.arpa. IN NS sirius.doc.com. 0.0.127.in_addr.arpa IN NS dnssecond.doc.com 1 IN PTR localhost. |
The following code examples show db.doc and db.sales files for the two primary servers on the two networks.
; SOA rec doc.com. IN SOA sirius.doc.com. sysop.centauri.doc.com. ( 19970332 ; serial number 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers doc.com. IN NS sirius.doc.com. sales.doc.com. IN NS altair.sales.doc.com. ; Addresses localhost IN A 127.0.0.1 sirius IN A 123.45.6.1 rigel IN A 123.45.6.112 antares IN A 123.45.6.90 polaris IN A 123.45.6.101 procyon IN A 123.45.6.79 tauceti IN A 123.45.6.69 altair.sales.doc.com. IN A 111.22.3.4 ; aliases dnsmastr IN CNAME sirius.doc.com. dnssecond.doc.com IN CNAME deneb.doc.com |
; SOA rec sales.doc.com. IN SOA altair.sales.doc.com. sysop.polaris.doc.com. ( 19970332 ; serial number 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers doc.com. IN NS sirius.doc.com. sales.doc.com. IN NS altair.sales.doc.com. ; Addresses altair IN A 111.22.3.4 localhost IN A 127.0.0.1 sirius.doc.com. IN A 123.45.6.1 luna IN A 192.168.8.22 phoebus IN A 192.168.8.24 deimos IN A 192.168.8.25 ganymede IN A 192.168.8.27 europa IN A 192.168.8.28 callisto IN A 192.168.8.29 ; ; aliases dnssales.sales.doc.com IN CNAME altair.sales.doc.com |
The following code examples show hosts.rev files for the two primary servers on the two networks:
; SOA rec 6.45.123.in-addr.arpa. IN SOA sirius.doc.com. sysop.centauri.doc.com. ( 19970331 ; serial number 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers 6.45.123.in-addr.arpa. IN NS sirius.doc.com. ;Pointer records for 123.45.6 1 IN PTR sirius.doc.com. 112 IN PTR rigel.doc.com. 90 IN PTR antares.doc.com. 101 IN PTR polaris.doc.com. 79 IN PTR procyon.doc.com. 69 IN PTR tauceti.doc.com. |
; SOA rec 3.22.111.in-addr.arpa. IN SOA altair.sales.doc.com. sysop.polaris.doc.com. ( 19970331 ; serial number 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers 3.22.111.in-addr.arpa. IN NS altair.sales.doc.com. ;Pointer records for 111.22.3 22 IN PTR luna 23 IN PTR deneb 24 IN PTR phoebus 25 IN PTR deimos 26 IN PTR altair 27 IN PTR ganymede 28 IN PTR europa 29 IN PTR callisto |
The following code example shows the named.ca file that is stored on each of the two primary servers on the two networks. Both servers use identical named.ca files.
; ; formerly NS1.ISI.EDU . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ; ; formerly C.PSI.NET . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ; ; formerly TERP.UMD.EDU . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ; ; formerly NS.NASA.GOV ;. 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ; ; formerly NS.ISC.ORG . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 ; ; formerly NS.NIC.DDN.MIL . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 ; ; formerly NIC.NORDU.NET . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ; ; temporarily housed at NSI (InterNIC) . 3600000 NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10 ; ; temporarily housed at NSI (InterNIC) . 3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 198.41.0.11 ; ; temporarily housed at ISI (IANA) . 3600000 NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12 ; ; temporarily housed at ISI (IANA) . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 198.32.65.12 ; End of File |