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). See Chapter 12, Setting Up DNS Clients.
Set up the boot file. See "The named.conf File".
Set up the data files See "Setting Up the Data Files". You need to set up four data files:
The named.ca file. See "Setting Up the named.ca File".
The hosts file. See "Setting Up the hosts File".
The hosts.rev file. See "Setting Up the hosts.rev File".
The named.local file. See "Setting Up the named.local File".
Initialize the server. See "Initializing 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 configuration 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 configuration file is /etc/named.conf. (See "The named.conf File".) The configuration 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.conf 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 use generic names that identify a file's main purpose, and specific example names for that file in code 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.conf, same file name for all three sources |
BIND 8.1 adds a new named.conf file to replace the earlier named.boot file. This configuration file adds security, startup options, logging. It specifies the type of server it is running on and selectively applies options on a per-zone or per-server basis, rather than all zones or servers. It contains a list of domain names and the names of the data files. |
||
/etc/resolv.conf, same file name for all three sources |
This file resides on every DNS client (including DNS servers) and designates the servers that 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 local host. |
$INCLUDE files, same convention for all three sources |
Any file identified by an $INCLUDE() statement in a data file. |
The 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 a $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 "The Resolver"), 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.
The following discussion describes how to set up the resolv.conf file.
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.
BIND 8.1 adds a new configuration file, /etc/named.conf, that replaces the /etc/named.boot file. The /etc/named.conf file establishes the server as a primary, secondary, or cache-only name server. It also specifies the zones over which the server has authority and which data files it should read to get its initial data.
The /etc/named.conf file contains statements that implement:
Security through an Access Control List (ACL) that defines a collection of IP addresses that a NIS+ host has read/write access
Logging specifications
Selectively applied options for a set of zones, rather than to all zones
The configuration file is read by in.named when the daemon is started by the server's start up script, /etc/init.d/inetsvc. The configuration file directs in.named either to other servers or to local data files for a specified domain.
The named.conf file contains statements and comments. Statements end with a semicolon. Some statements can contain a contain a block of statements. Again, each statement in the block is terminated with a semicolon.
Table 13-2 named.conf Statementsacl |
Defines a named IP address match list used for access control. The address match list designates one or more IP addresses (dotted-decimal notation) or IP prefixes (dotted-decimal notation followed with a slash and the number of bits in the netmask). The named IP address match list must be defined by an acl statement before it can be used elsewhere; no forward references allowed. |
include |
Inserts an include file at the point where the include statement is encountered. Use include to break up the configuration into more easily managed chunks. |
key |
Specifies a key ID used for authentication and authorization on a particular name server. See the server statement. |
logging |
Specifies what information the server logs and the destination of log messages. |
options |
Controls global server configuration options and sets default values for other statements. |
server |
Sets designated configuration options associated with a remote name server. Selectively applies options on a per-server basis, rather than to all servers. |
zone |
Defines a zone. Selectively applies options on a per-zone basis, rather than to all zones. |
options { directory "/var/named"; datasize 2098; forward only; forwarders { 99.11.33.44; }; recursion no; transfers-in 10; transfers-per-ns 2; allow-transfer { 127.0.1.1/24; }; }; logging { category queries { default_syslog; }; }; include "/var/named/abcZones.conf" // here are the names of the primary files zone "cities.zn" { type master; file "db.cities.zn"; }; zone "0.0.127.in-addr.arpa" { type master; file "db.127.cities.zn"; }; zone "168.192.in-addr.arpa" { type master; file "db.cities.zn.rev"; }; zone "sales.doc.com" { type slave; file "slave/db.sales.doc"; masters { 192.168.1.151; }; }; zone "168.192.in-addr.arpa" { type slave; file "slave/db.sales.doc.rev"; masters { 192.168.1.151; }; }; |
Become superuser and run the Korn shell script, /usr/sbin/named-bootconf, to convert a BIND 4.9.x named.boot file to a BIND 8.1 named.conf file. See named-bootconf(1M).
The named.boot and named.conf files cannot coexist in the same server.
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 can 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 a server as 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 contains 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 can 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 can 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-3. They are usually entered in the order shown in Table 13-3, but that is not a requirement.
Table 13-3 Commonly Used Resource Record Types
Type |
Description |
---|---|
SOA |
Start of authority |
NS |
Name server |
A |
IPv4 Internet address (name to address) |
AAAA |
IPv6 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.
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 through:
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 the 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 these 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 these 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 these 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.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 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 your lookup is successful, 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 are successful, 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 a 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 are successful, 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 applies to 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 can 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 need to use only 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.
To divide a network into multiple domains, create a domain hierarchy. That is, one domain becomes 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 is passed from one zone to another, it is passed up and down the zone hierarchy. This means that each zone requires records in its data files that specify 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 requires 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 Table 13-4 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 need 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 might 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 "Configuration 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 you need 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
The doc.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 |
secondary for 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 |