[ Previous | Next | Contents | Glossary | Home | Search ]
AIX Version 4.3 System Management Guide: Communications and Networks

TCP/IP Name Resolution

Although 32-bit Internet addresses provide machines an efficient means of identifying the source and destination of datagrams sent across an internetwork, users prefer meaningful, easily remembered names. Transmission Control Protocol/Internet Protocol (TCP/IP) provides a naming system that supports both flat and hierarchical network organizations.

The topics discussed in this section are:

Naming

Naming in flat networks is very simple: Host names consist of a single set of characters and generally are administered locally. In flat TCP/IP networks, each machine on the network has a file (/etc/hosts) containing the name-to-Internet-address mapping information for every host on the network. As a TCP/IP network grows, the administrative burden of keeping each machine's naming file current grows. When TCP/IP networks become very large, as on the Internet, naming is divided hierarchically. Typically, the divisions follow the network's organization. In TCP/IP, hierarchical naming is known as the domain name system (DNS) and uses the DOMAIN protocol. The DOMAIN protocol is implemented by the named daemon in TCP/IP.

As in naming for flat networks, the domain name hierarchy provides for the assignment of symbolic names to networks and hosts that are meaningful and easy for users to remember. However, instead of each machine on the network keeping a file containing the name-to-address mapping for all other hosts on the network, one or more hosts are selected to function as name servers. Name servers translate (resolve) symbolic names assigned to networks and hosts into the efficient Internet addresses used by machines. A name server has complete information about some part of the domain, referred to as a zone, and it has authority for its zone.

Naming Authority

In a flat network, all hosts in the network are administered by one central authority. This form of network requires that all hosts in the network have unique host names. In a large network, this requirement creates a large administrative burden on the central authority.

In a domain network , groups of hosts are administered separately within a tree-structured hierarchy of domains and subdomains. In this case, host names need to be unique only within the local domain, and only the root domain is administered by a central authority. This structure allows subdomains to be administered locally and reduces the burden on the central authority. For example, the root domain of the Internet consists of such domains as com (commercial organizations), edu (educational organizations), gov (governmental organizations), and mil (military groups). New top-level domains can only be added by the central authority. Naming at the second level is delegated to designated agents within the respective domains. For example, in the following figure, com has naming authority for all commercial organization subdomains beneath it. Likewise, naming at the third level (and so on) is delegated to agents within that level. For example, in the Domain Structure of the Internet figure, Century has naming authority for its subdomains Austin, Hopkins, and Charlotte.

Century's Austin subdomain might also be divided into zones, for example, Dev and Graphics. In this case, the zone austin.century.com would have all the data contained in the domain austin.century.com , except that which was delegated to Dev and Graphics. The zone dev.century.com would contain only the data delegated to Dev; it would know nothing about Graphics, for example. The zone austin.century.com (as opposed to the domain of the same name) would contain only that data not delegated to other zones.

Naming Conventions

In the hierarchical domain name system, names consist of a sequence of case-insensitive subnames separated by periods with no embedded blanks. The DOMAIN protocol specifies that a local domain name must be less than 64 characters and that a host name must be less than 32 characters in length. The host name is given first, followed by a . (period), a series of local domain names separated by periods, and finally the root domain. A fully specified domain name for a host, including periods, must be less than 255 characters in length and in the following form:

host.subdomain1.[subdomain2 . . . subdomain].rootdomain

Since host names must be unique within a domain, you can use an abbreviated name when sending messages to a host within the same domain. For example, instead of sending a message to smith.eng.lsu.edu , a host in the eng domain could send a message to smith . Additionally, each host can have several aliases that other hosts can use when sending messages.

Choosing Names for the Hosts on Your Network

The purpose of using names for hosts is to provide a quick, easy, and unambiguous way to refer to the computers in your network. Internet system administrators have discovered that there are good, as well as poor, choices for host names. These suggestions are intended to help you avoid common pitfalls in choosing host names.

Here are some suggestions for choosing unambiguous, easy to remember host names:

Here are some examples of poor choices. In general, these are poor choices because they are difficult to remember or are confusing (either to humans or computers):

Name Servers

In a flat name space, all names must be kept in the /etc/hosts file on each host on the network. If the network is very large, this can become a burden on the resources of each machine.

In a hierarchical network, certain hosts designated as name servers resolve names into Internet addresses for other hosts. This has two advantages over the flat name space: It keeps the resources of each host on the network from being tied up in resolving names, and it keeps the person who manages the system from having to maintain name resolution files on each machine on the network. The set of names managed by a single name server is known as its zone of authority.

Note: Although the host machine that performs the name resolution function for a zone of authority is commonly referred to as a name server host, the process controlling the function, the named daemon, is the actual name server process.

To further reduce unnecessary network activity, all name servers cache (store for a period of time) name-to-address mappings. When a client asks a server to resolve a name, the server checks its cache first to see if the name has been resolved recently. Since domain and host names do change, each item remains in the cache for a limited length of time specified by the record's time to live. In this way, authorities can specify how long they expect the name resolution to be accurate.

Within any autonomous system there can be multiple name servers. Typically, name servers are organized hierarchically and correspond to the network's organization. Referring to the figure Domain Structure of the Internet, each domain might have a name server responsible for all subdomains within the domain. Each subdomain name server communicates with the name server of the domain above it (called the parent name server), as well as with the name servers of other subdomains.

For example, in the figure Domain Structure of the Internet, Austin, Hopkins, and Charlotte are all subdomains of the domain Century. If the tree hierarchy is followed in the network design, the Austin name server communicates with the name servers of Charlotte and Hopkins as well as with the parent Century name server. The Austin name server will also communicate with the name servers responsible for its subdomains.

There are several types of name servers:

Primary Name Server Loads its data from a file or disk and may delegate authority to other servers in its domain.
Secondary Name Server Receives its information at system startup time for the given zone of authority from a primary name server, and then periodically asks the primary server to update its information. On expiration of the refresh value in the start of authority (SOA) Resource Record on a secondary name server, the secondary will reload the database from the primary if the serial number of the database on the primary is greater than the serial number in the current database on the secondary. To force a new zone transfer from the primary, simply remove the existing secondary databases and refresh the named daemon on the secondary name server.
Caching-Only Server Indicates that the caching-only server responds to queries by asking other servers that have the authority to provide the information needed if a caching-only server does not have a name-to-address mapping in its cache
Forwarder or Client Server Forwards queries it cannot satisfy locally to a fixed list of forwarding servers. Slave forwarders (a forwarder that obtains information and passes it on to other clients, but that is not actually a server) will not interact with the primary name servers for the root domain and other domains. The queries to the forwarding servers are recursive. There may be one or more forwarding servers, which are tried in turn until the list is exhausted. A client and forwarder configuration is typically used when you do not wish all the servers at a given site to interact with the rest of the Internet servers.
Remote Server Runs all the network programs that use the name server without the name server process running on the local host. All queries are serviced by a name server that is running on another machine on the network.

One name server host can perform in different capacities for different zones of authority. For example, a single name-server host can be a primary name server for one zone and a secondary name server for another zone.

Name Resolution

The process of obtaining an Internet address from a host name is known as name resolution and is done by the gethostbyname subroutine. The process of translating an Internet address into a host name is known as reverse name resolution and is done by the gethostbyaddr subroutine.

When a process receives a symbolic host name and needs to resolve it into an address, it calls a resolver routine.

Resolver routines on hosts running TCP/IP attempt to resolve names using the following sources:

  1. BIND/DNS (named)
  2. Network Information Service (NIS)
  3. Local /etc/hosts file.

To resolve a name in a domain network, the resolver routine first queries the domain name server database, which may be local if the host is a domain name server or may be on a foreign host. Name servers translate domain names into Internet addresses. The group of names for which a name server is responsible is its zone of authority. If the resolver routine is using a remote name server, the routine uses the Domain Name Protocol (DOMAIN) to query for the mapping. To resolve a name in a flat network, the resolver routine checks for an entry in the local /etc/hosts file. When NIS is used, the /etc/hosts file on the master server is checked.

By default, resolver routines attempt to resolve names using the above resources. BIND/DNS will be tried first, if the /etc/resolv.conf file does not exist or if BIND/DNS could not find the name, NIS is queried if it is running. NIS is authoritative over the local /etc/hosts, so the search will end here if it is running. If NIS is not running, then the local /etc/hosts file is searched. If none of these services could find the name, then the resolver routines return with HOST_NOT_FOUND. If all of the services are unavailable, then the resolver routines return with SERVICE_UNAVAILABLE.

The default order can be overwritten by creating the /etc/netsvc.conf configuration file and specifying the desired order. Both the default and /etc/netsvc.conf can be overwritten with the environment variable, NSORDER. If either the /etc/netsvc.conf file or environment variable, NSORDER are defined, then at least one value must be specified along with the option.

To specify host ordering with the /etc/netsvc.conf file:

hosts = value,value,value

where value is one of the listed sources.

To specify host ordering with the NSORDER environment variable:

NSORDER=value,value,value

The order is specified on one line with values separated by commas. White spaces are permitted between the commas and the equal sign. The values specified and their ordering is dependent on the network configuration. For example, if the local network is organized as a flat network, then only the /etc/hosts file is needed.

The etc/netsvc.conf file would contain the following line:

hosts=local

The NSORDER environment variable would be set as:

NSORDER=local

If the local network is a domain network using a name server for name resolution and an /etc/hosts file for backup, then both services should be specified.

The etc/netsvc.conf file would contain the following line:

hosts=bind,local

The NSORDER environment variable would be set as:

NSORDER=bind,local
Note: The values listed must be in lowercase.

The first source in the list will be tried. The algorithm will try another specified service if the:

If the /etc/resolv.conf file does not exist, then BIND/DNS is considered to be not set up or running and therefore not available. If the subroutines, getdomainname and yp_bind fail, then it is assumed that the NIS service is not set up or running and therefore not available. If the /etc/hosts file could not be opened, then a local search is impossible and therefore the file and service are unavailable.

When a service is listed as authoritative, it means that this service is the expert of its successors and should have all pertinent names and addresses. Resolver routines do not try successor services, since they may contain only a subset of the information in the authoritative service. Name resolution ends with a service listed as authoritative, even if it does not find the name (in which case, the resolver routine returns HOST_NOT_FOUND). If an authoritative service is not available, then the next service specified will be queried.

An authoritative source is specified with the string "=auth" directly behind a value. The entire word, "authoritative" can be typed in, but only the "auth" will be used. For example, if the /etc/netsvc.conf file contains the following line:

hosts = nis=auth,bind,local

the search is ended after the NIS query, if NIS is running, regardless of whether the name was found. If NIS is not running, then the next source is queried, which is BIND.

TCP/IP name servers use caching to reduce the cost of searching for names of hosts on remote networks. Instead of searching for a host name each time a request is made, a name server first looks at its cache to see if the host name has been resolved recently. Since domain and host names do change, each item remains in the cache for a limited length of time specified by the record's time-to-live (TTL). In this way, authorities can specify how long they expect the name resolution to be accurate.

Potential Host Name Conflict Between nameserver and sendmail

In a DNS environment, a host name that is set using the hostname command from the command line or in the rc.net file format must be the official name of the host as returned by the name server. Generally, this name is the full domain name of the host in the form:

host.subdomain.subdomain.rootdomain
Note: Resolver routines require the default domain to be set. If the default domain is not set in the hostname command, then it must be set in the /etc/resolv.conf file.

If the host name is not set up as a fully qualified domain name, and if the system is set up to use a domain name server in conjunction with the sendmail program, the sendmail configuration file (/etc/sendmail.cf) must be edited to reflect this official host name. In addition, the domain name macros in this configuration file must be set for the sendmail program to operate correctly.

Note: The domain specified in the /etc/sendmail.cf file takes precedence over the domain set by the hostname command for all sendmail functions.
Potential Domain Name Conflict Between nameserver and sendmail

For a host that is in a DOMAIN network but is not a name server, the local domain name and domain name server are specified in the /etc/resolv.conf file. In a DOMAIN name server host, the local domain and other name servers are defined in files read by the named daemon when it starts.

Reverse Address Resolution Protocol

The Reverse Address Resolution Protocol (RARP) translates unique hardware addresses into Internet addresses on the Ethernet local area network (LAN) adapter (Ethernet protocol only). Standard Ethernet protocol is supported with the following restrictions. The server will:

The system administrator must manually build and maintain a table of permanent ARP entries using the arp command. A specific ARP table entry must be added on the AIX server for each host that requires RARP replies from an authoritative source.

Performing Local Name Resolution (/etc/hosts)

You should configure the /etc/hosts file if your network is small, and you are using a flat naming scheme. Even if you are using a hierarchical (or domain) naming scheme with name servers, you may want to configure the /etc/hosts file to identify hosts that are not known by the name servers.

You can configure your system for local host resolution using Web-based System Manager, System Management Interface Tool (SMIT), or commands. If you choose the command method, be sure to preserve the format of the /etc/hosts file, as described in "Hosts File Format for TCP/IP" in the AIX Version 4.3 Files Reference.

Local Name Resolution Tasks
Web-based System Manager:    wsm network fast path
(Network application)

-OR-
Task SMIT Fast Path Command or File
List All the Hosts smit lshostent view /etc/hosts
Add a Host smit mkhostent edit /etc/hosts
Change/Show Characteristics of a Host smit chhostent edit /etc/hosts
Remove a Host smit rmhostent edit /etc/hosts

Planning for DOMAIN Name Resolution

If you are part of a larger internetwork, you need to coordinate setting up your domain and name servers with their central authority.

Some hints in planning your own DOMAIN name resolution system:

Configuring Name Servers

In a hierarchical network, certain hosts are designated as name servers. These hosts resolve names into Internet addresses for other hosts. The named daemon controls the name server function and, therefore, must be run on a name-server host.

Before you configure a name server, decide which type or types best fit the network it will serve. There are several types of name servers.

A primary name server actually stores the database containing name-to-address mapping information. It loads its data from a file or disk and may delegate authority to other servers in its domain. A secondary name server receives its information at system startup time for a given zone of authority from a primary name server, and then periodically asks the primary server to update its information. A caching-only server responds to requests to resolve names by querying other servers that have the authority to provide the information needed.

Keep in mind that a name server may function in different capacities for different zones of authority. For example, one name server host can be a primary name server for one zone and a secondary name server for another zone. If your system has the Network Information Service (NIS) application installed, NIS can also provide Name-server service.

There are several files involved in configuring name servers.

boot This file is read when the named daemon starts. The records in the boot file tell the named daemon which type of server it is, which domains it has authority over (its zones of authority), and where to get the data for initially setting up its database. The default name of this file is /etc/named.boot. However, you can change the name of this file by specifying the name and path of the file on the command line when the named daemon is started. When using the /etc/named.boot as the boot file, if it does not exist, a message is generated in syslog and named terminates. However, if an alternative boot file is specified, and the alternative file does not exist, no error message will be generated and named will continue.
cache Contains information about the local cache. The local cache file contains the names and addresses of the highest authority name servers in the network. The cache file uses the Standard Resource Record Format. The name of the cache file is set in the boot file.
domain data There are three domain data files, also referred to as the named data files. The named local file contains the address resolution information for local loopback. The named data file contains the address resolution data for all machines in the name server's zone of authority. The named reverse data file contains the reverse address resolution information for all machines in the name server's zone of authority. The domain data files use the Standard Resource Record Format. Their names are user definable and are set in the boot file. By convention, the names of these files generally include the name of the daemon (named ), and in the extension the type of file and name of the domain. For example, the name server for the domain abc might have the following files: 
named.abcdata 
named.abcrev 
named.abclocal

When modifying the named data files the serial number in the SOA Resource Record should be incremented.

resolv.conf The presence of this file indicates to a host that it should go to a name server to resolve a name first. If the resolv.conf file does not exist, the host looks in the /etc/hosts file for name resolution. On a name server, the resolv.conf file must exist and can contain the local host's address, the loopback address (127.0.0.1), or be empty.
Note: The resolver routines require the default domain be set. If the default domain is not set in the /etc/resolv.conf file, then it must be set in the hostname.

Time-to-live (TTL) is specified in resource records. If TTL is not specified in a record, the length of this time period defaults to the minimum field as defined in the start of authority (SOA) record for that zone. TTL is used when data is stored outside a zone (in a cache) to ensure that the data does not stay around indefinitely.

Configuring a Primary Name Server

To configure a primary name server, use the Web-based System Manager fast path wsm network or use the following procedure, which edits a series of files and then uses the System Management Interface Tool (SMIT) or the command line to start the named daemon.

  1. Edit the /etc/named.boot file. If there is no named.boot file in the /etc directory, copy the /usr/samples/tcpip/named.boot sample file into the /etc directory and edit it. See "named.boot File Format for TCP/IP" in the AIX Version 4.3 Files Reference for more information and a detailed example of a boot file.

    This file is read each time the named daemon starts. It tells the server which type of server it is, the zone for which it is responsible, and where to get its initial information.

    1. Specify the directory in which the named data files can be located (optional). Use this line if you want the named data files to use paths relative to this directory. For example: 
      directory /usr/local/domain
    2. Optionally specify the name of the cache file. For example: 
      cache . /etc/named.ca
    3. Specify a name server type of primary, and define the names of the named hosts data file and named reverse hosts data file. For example: 
      primary    abc.aus.century.com       /etc/named.abcdata 
primary  201.9.192.in-addr.arpa  /etc/named.abcrev
      Note: Include lines for each zone for which the name server is primary.
    4. Define the name of the named local file. For example: 
      primary    0.0.127.in-addr.arpa  /etc/named.local
  2. Edit the /etc/named.ca file. Refer to the "DOMAIN Cache File Format for TCP/IP" in the AIX Version 4.3 Files Reference for more information and a detailed example of a cache file.

    This file contains the addresses of the servers that are authoritative, or root name servers for the domain. For example:

    ; root name servers.
         1          IN    NS    relay.century.com.
relay.century.com.   3600000    IN    A     129.114.1.2
    Note: All lines in this file must be in Standard Resource Record Format.
  3. Edit the /etc/named.local file. See the "DOMAIN Local Data File Format for TCP/IP" in the AIX Version 4.3 Files Reference for more information and a detailed example of a local data file.
    1. Specify the start of authority of the zone and the default time-to-live information. For example: 
      @ IN SOA venus.abc.aus.cntry.com. gail.zeus.abc.aus.cntry.com. 
( 
                           1.1     ;serial 
                           3600    ;refresh 
                           600     ;retry 
                           3600000 ;expire 
                           86400)  ;minimum
    2. Specify the name server (NS) record. For example: 
      IN    NS     venus.abc.aus.century.com.
    3. Specify the pointer (PTR) record. 
      1      IN    PTR    localhost.
      Note: All lines in this file must be in Standard Resource Record Format.
  4. Edit the /etc/named.data file. The /usr/samples/tcpip/hosts.awk file contains directions for creating the /etc/named.data file. Use the /usr/samples/tcpip/named.data sample file as an example when creating the /etc/named.data file. See the "DOMAIN Data File Format for TCP/IP" in the AIX Version 4.3 Files Reference for more information and an example of a hosts data file.
    1. Specify the start of authority of the zone and the default time-to-live information for the zone. This record designates the start of a zone. There should only be one start of authority record per zone. For example: 
      @   IN   SOA   venus   bob.robert.abc.aus.century.com. 
( 
                           1.1     ;serial 
                           3600    ;refresh 
                           600     ;retry 
                           3600000 ;expire 
                           86400)  ;minimum
    2. Include name-to-address resolution information on all hosts in the name server's zone of authority. For example: 
      venus        IN    A        192.9.201.1 
venus        IN    A        128.114.100.1
    3. Include name server records for all primary name servers in the zone. For example: 
      IN    NS       venus.abc.century.com 
IN    NS       kronos.xyz.century.com
    4. Include other types of entries, such as canonical name records and mail exchanger records as needed.
      Note: All lines in this file must be in Standard Resource Record Format.
  5. Edit the /etc/named.rev file. The /usr/samples/tcpip/addrs.awk file contains directions for creating the /etc/named.rev file. See the "DOMAIN Reverse Data File Format for TCP/IP" in the AIX Version 4.3 Files Reference for more information and a detailed example of a reverse hosts data file.
    1. Specify the start of authority of the zone and the default time-to-live information. This record designates the start of a zone. There should only be one start of authority record per zone. For example: 
      @  IN  SOA  venus.abc.aus.century.com. bob.robert.abc.aus.century.com. 
( 
                           1.1     ;serial 
                           3600    ;refresh 
                           600     ;retry 
                           3600000 ;expire 
                           86400)  ;minimum
    2. Include address-to-name resolution information on all hosts to be in the name server's zone of authority. 
      ;ABC.AUS.CENTURY.COM Hosts 
1                      IN    PTR    venus.abc.aus.century.com. 
2                      IN    PTR    kronos.abc.aus.century.com.
    3. Include other types of entries, such as name server records and canonical name records (optional).
      Note: All lines in this file must be in Standard Resource Record Format.
  6. Create an /etc/resolv.conf file by issuing the following command: 
    touch /etc/resolv.conf
    The presence of this file indicates that the host should use a name server, not the /etc/hosts file, for name resolution. This file must exist on a name server host and may contain either the local host's address, the loopback address (127.0.0.1), be empty.

    Alternatively, the /etc/resolv.conf file may contain the following entry:

    nameserver 127.0.0.1
    The 127.0.0.1 address is the loopback address, which causes the host to access itself as the name server. The /etc/resolv.conf file may also contain an entry like the following: 
    domain domainname
    In the previous example, domainname would be aus.century.com .

  7. Perform one of the following steps:
  8. If you chose not to initialize the named daemon through SMIT, start the daemon for this session by running the following command: 
    startsrc -s named

Configuring a Secondary Name Server

To configure a secondary name server, use the Web-based System Manager fast path wsm network or use the following procedure, which edits a series of files and then uses SMIT or the command line to start the named daemon.

  1. Edit the /etc/named.boot file. If there is no named.boot file in the /etc directory, copy the /usr/samples/tcpip/named.boot sample file into the /etc directory and edit it. Refer to the "named.boot File Format for TCP/IP" in the AIX Version 4.3 Files Reference for more information and a detailed example of a boot file.

    This file is read each time the named daemon starts. It tells the server which type of server it is, the zone for which it is responsible, and where to get its initial information.

    1. Specify the directory where the named data files can be located (optional). Use this line if you want the named data files to use paths relative to this directory. For example: 
      directory /usr/local/domain
    2. Optionally specify the name of the cache file for the name server. For example: 
      cache . /etc/named.ca
    3. Include a secondary line to define the domain for which the name server is responsible and the Internet addresses from which the host is to get its initial data. Include a line for each domain for which the host is a backup name server. Specify a file name to which the name server can back up its data. For example: 
      secondary   abc.aus.century.com   192.9.201.1   192.9.201.2\ 
/etc/named.abc.bak 
secondary   xyz.aus.century.com   192.9.201.1   192.9.201.2\ 
/etc/named.xyz.bak
    4. Include a secondary line to define the reverse name resolution information for the name server. For example: 
      secondary   201.9.192.in-addr.arpa 192.9.201.1 192.9.201.2\  
named.rev.bak 
secondary   100.114.128.in-addr.arpa 192.9.201.1 192.9.201.2\ 
named.rev.bak
    5. Specify a name server type of primary with a source of /etc/named.local as well as the domain for which the name server will be responsible. 
      primary       0.0.127.in-addr.arpa   /etc/named.local
  2. Edit the /etc/named.ca file. Refer to the "DOMAIN Cache File Format for TCP/IP" in the AIX Version 4.3 Files Reference for more information and a detailed example of a cache file.

    This file contains the addresses of the servers that are authoritative name servers for the root domain of the network. For example:

    ; root name servers. 
         1          IN    NS    relay.century.com. 
relay.century.com.   3600000    IN    A     129.114.1.2
    Note: All lines in this file must be in Standard Resource Record Format.
  3. Edit the /etc/named.local file. See the "DOMAIN Local Data File Format for TCP/IP" in the AIX Version 4.3 Files Reference for more information and a detailed example of a local data file.
    1. Specify the start of authority of the zone and the default time-to-live information. For example: 
      @ IN SOA venus.abc.aus.cntry.com. gail.zeus.abc.aus.cntry.com. 
( 
                           1.1     ;serial 
                           3600    ;refresh 
                           600     ;retry 
                           3600000 ;expire 
                           86400)  ;minimum
    2. Specify the name server (NS) record. For example: 
      IN    NS     venus.abc.aus.century.com.
    3. Specify the pointer (PTR) record. 
      1      IN    PTR    localhost.
      Note: All lines in this file must be in Standard Resource Record Format.
  4. Create an /etc/resolv.conf file by issuing the following command: 
    touch /etc/resolv.conf
    The presence of this file indicates that the host should use a name server, not the /etc/hosts file, for name resolution. You may want to enter records to specify the name, domain, and address of the name server.

  5. Perform one of the following steps:
  6. If you chose not to initialize the named daemon through SMIT, start the daemon for this session by running the following command: 
    startsrc -s named

Configuring a Cache-Only Name Server

To configure a cache-only name server, use the Web-based System Manager fast path wsm network or use the following procedure, which edits a series of files and then uses SMIT or the command line to start the named daemon.

Procedure

Configure a cache name server according to the following steps:

  1. Edit the /etc/named.boot file. If there is no named.boot file in the /etc directory, copy the /usr/samples/tcpip/named.boot sample file into the /etc directory and edit it. Refer to the "named.boot File Format for TCP/IP" in the AIX Version 4.3 Files Reference for more information and a detailed example of a boot file.
  2. Edit the /etc/named.ca file. Refer to the "DOMAIN Cache File Format for TCP/IP" in the AIX Version 4.3 Files Reference for more information and a detailed example of a cache file.

    This file contains the addresses of the servers that are authoritative name servers for the root domain of the network. For example:

    ; root name servers. 
         1          IN    NS    relay.century.com. 
relay.century.com.   3600000    IN    A     129.114.1.2
    Note: All lines in this file must be in Standard Resource Record Format.
  3. Edit the /etc/named.local file. Refer to the "DOMAIN Local Data File Format for TCP/IP" in the AIX Version 4.3 Files Reference for more information and a detailed example of a local data file.
    1. Specify the start of authority of the zone and the default time-to-live information. For example: 
      @ IN SOA venus.abc.aus.cntry.com. gail.zeus.abc.aus.cntry.com. 
( 
                           1.1     ;serial 
                           3600    ;refresh 
                           600     ;retry 
                           3600000 ;expire 
                           86400)  ;minimum
    2. Specify the name server (NS) record. For example: 
      IN    NS     venus.abc.aus.century.com.
    3. Specify the pointer (PTR) record. 
      1      IN    PTR    localhost.
      Note: All lines in this file must be in Standard Resource Record Format.
  4. Create an /etc/resolv.conf file by issuing the following command: 
    touch /etc/resolv.conf
    The presence of this file indicates that the host should use a name server, not the /etc/hosts file, for name resolution. You may want to enter records to specify the name, domain, and address of the name server.

  5. Perform one of the following steps:
  6. If you chose not to initialize the named daemon through SMIT, start the daemon for this session by issuing the following command: 
    startsrc -s named

Configuring a Domain Mail Server

Configuring a domain mail server provides users external to your organization a simple method for addressing mail to your organization's users. That is, without a domain mail server, the mail address must specify a particular host in your organization. For example sam@orange.widget.com , where widget.com is your organization's domain name, and orange is the host that sam uses. But with a domain mail server, users outside your organization can simply specify the user name and domain name, without having to know which host the user uses, for example, sam@widget.com .

To configure a domain mail server, use the Web-based System Manager fast path wsm network or use one of the following procedures.

To Configure a Domain Mail Server
  1. Create a mail exchanger (MX) record and an address (A) record for the mail server (black.widget.com ): 
    widget.com           IN    MX     10 black.widget.com
widget.com           IN     A     192.10.143.9
black.widget.com     IN     A     192.10.143.9
  2. Edit sendmail.cf on the mail server (black.widget.com ) to add the domain alias (the w class): 
    Cw $w $?D$w.$D$. widget.com
  3. Mail clients must know where to send their non-local mail, so edit sendmail.cf on each client to point to the mail server (the S macro): 
    DRblack.widget.com
  4. Use the NameServOpt option to configure the sendmail daemon so everyone can use the MX records defined in the name server brown.widget.com .

  5. Add aliases for users in the domain that do not have accounts on the mail server using the aliases file, for example: 
    sam:sam@orange.widget.com
david:david@green.widget.com
judy:judy@red.widget.com
    Note: Mailbox (MB) records can serve the same function.
  6. The serial number in the SOA Resource Record should be incremented because the database has been modified.

  7. Refresh the name server database by issuing the refresh -s named command.

  8. Perform the following steps:
    1. Enter the command sendmail -bz to recompile the sendmail.cf file on the mail server.
    2. Enter the command sendmail -bi to recompile the aliases database on the mail server.
    3. Run the refresh -s sendmail command to make the changes take effect.

  9. On the clients, recompile (sendmail) and run the refresh -s sendmail command to make the changes take effect.

There are other methods to configure a domain mail server. The following procedures use experimental mailbox (MB), mail rename (MR), and mail group (MG) records.

To Configure a Domain Mail Server Using mailbox (MB) Records
  1. Define a mailbox (MB) record for each user in the domain. Add entries such as: 
    sam IN MB orange.widget.com.
    to the /etc/named.data file on host brown.widget.com . These entries identify to the mail server (black.widget.com ) where to send mail for each user in the domain.
  2. Configure the sendmail daemon on the mail server (black.widget.com ) to use the MB records defined in the name server (brown.widget.com ). Use the NameServOpt option.
  3. Increment the serial number in the SOA Resource Record, because the database has been modified.
  4. Refresh the name server database by running the refresh -s named command.
  5. Enter the command sendmail -bz to recompile the sendmail.cf file on the mail server, and then run the refresh -s sendmail command to make the changes take effect.
Defining a Mail Rename (MR) Record for a User
  1. Edit the /etc/named.data file on your domain name server.

  2. Add a Mail Rename record for each alias. For example, if a user sam has an alias sammy , the Mail Rename record would be: 
    sammy IN MR sam
    This record will cause all mail addressed to sammy to be delivered to sam . Each MR record should be entered on a line by itself.

  3. Since the database has been modified, the serial number in the SOA Resource Record should be incremented.

  4. Refresh the name server database by issuing the refresh -s named command.

  5. Enter the command sendmail -bz to recompile the sendmail.cf file on the mail server, and then run the refresh -s sendmail command to make the changes take effect.
Defining Mail Group (MG) Member Records
  1. Edit the /etc/named.data file on your domain name server.

  2. Add MG records for each mail group. MG records function like the /etc/aliases file, with the aliases maintained on the name server. For example: 
    users IN HINFO users-request widget.com
users IN MG sam
users IN MG david
users IN MG judy

    This example would cause all mail addressed to users@widget.com to be delivered to sam , david , and judy . Each MG record should be on a line by itself.

    Note: Users sam , david , and judy must have MB records defined.
  3. The serial number in the SOA Resource Record should be incremented, because the database has been modified.

  4. Refresh the name server database by issuing the refresh -s named command.

  5. Enter the command sendmail -bz to recompile the sendmail.cf file on the mail server, and then run the refresh -s sendmail command to make the changes take effect.
Defining Mail Exchanger (MX) Records
  1. Edit the /etc/named.data file on your domain name server.

  2. Add MX records for each machine not directly connected to your network to which you wish to forward mail. For example, if mail addressed to users on purple.widget.com should be forwarded to post.office.widget , the MX record would look like the following:

    purple.widget.com IN MX 0 post.office.widget.

    You must specify both host and machine names when using MX records. Each MX record should be on a line by itself. You may use wildcards, for example:

    *.widget.com IN MX 0 post.office.widget.

    This example would cause mail to an unknown host (a host without an explicit MX record) in the widget.com domain to be forwarded to post.office.widget .

    Note: Wildcard MX records are not appropriate for use on the Internet.
  3. The serial number in the SOA Resource Record should be incremented because the database has been modified

  4. Refresh the name server database using the refresh -s named command.

  5. Enter the command sendmail -bz to recompile the sendmail.cf file on the mail server, and then run the refresh -s sendmail command to make the changes take effect.

Configuring a Forwarder

To configure a forwarder, use the Web-based System Manager fast path wsm network or use the following procedure, which edits a series of files and then uses SMIT or the command line to start the named daemon.

  1. Edit the /etc/named.boot file. If there is no named.boot file in the /etc directory, copy the /usr/samples/tcpip/named.boot sample file into the /etc directory and edit it. Refer to the "named.boot File Format for TCP/IP" in the AIX Version 4.3 Files Reference for more information and a detailed example of a boot file.
  2. Edit the /etc/named.ca file. Refer to the "DOMAIN Cache File Format for TCP/IP" in the AIX Version 4.3 Files Reference for more information and a detailed example of a cache file.

    This file contains the addresses of the servers that are authoritative name servers for the root domain of the network. For example:

    ; root name servers. 
         1          IN    NS    relay.century.com. 
relay.century.com.   3600000    IN    A     129.114.1.2
    Note: All lines in this file must be in Standard Resource Record Format.
  3. Edit the /etc/named.local file. Refer to the "DOMAIN Local Data File Format for TCP/IP" in the AIX Version 4.3 Files Reference for more information and a detailed example of a local data file.
    1. Specify the start of authority of the zone and the default time-to-live information. For example: 
      @ IN SOA venus.abc.aus.cntry.com. gail.zeus.abc.aus.cntry.com. 
( 
                           1.1     ;serial 
                           3600    ;refresh 
                           600     ;retry 
                           3600000 ;expire 
                           86400)  ;minimum
    2. Specify the name server (NS) record. For example: 
      IN    NS     venus.abc.aus.century.com.
    3. Specify the pointer (PTR) record. 
      1      IN    PTR    localhost.
      Note: All lines in this file must be in Standard Resource Record Format.
  4. Create an /etc/resolv.conf file by issuing the following command: 
    touch /etc/resolv.conf
    The presence of this file indicates that the host should use a name server, not the /etc/hosts file, for name resolution.

    Alternatively, the /etc/resolv.conf file may contain the following entry:

    nameserver 127.0.0.1
    The 127.0.0.1 address is the loopback address, which causes the host to access itself as the name server. The /etc/resolv.conf file may also contain an entry like the following: 
    domain domainname
    In the previous example, domainname would be austin.century.com .

  5. Perform one of the following steps:

  6. If you chose not to initialize the named daemon through SMIT, start the daemon for this session by issuing the following command: 
    startsrc -s named

Configuring a Slave Forwarder

To configure a slave forwarder, use the Web-based System Manager fast path wsm network or use the following procedure, which edits a series of files and then uses SMIT or the command line to start the named daemon.

Note: You can achieve a similar configuration without running a slave server. Instead, create an /etc/resolv.conf file that contains name server lines that point to the forwarders you wish to use.
  1. Edit the /etc/named.boot file. If there is no named.boot file in the /etc directory, copy the /usr/samples/tcpip/named.boot sample file into the /etc directory and edit it. Refer to the "named.boot File Format for TCP/IP" in the AIX Version 4.3 Files Reference for more information and a detailed example of a boot file.
  2. Edit the /etc/named.ca file. Refer to "DOMAIN Cache File Format for TCP/IP" in AIX Version 4.3 Files Reference for more information and a detailed example of a cache file. This file contains the addresses of the servers that are authoritative name servers for root domain of the network. For example: 
    ; root name servers. 
         1          IN    NS    relay.century.com. 
relay.century.com.   3600000    IN    A     129.114.1.2
    Note: All lines in this file must be in Standard Resource Record Format.
  3. Edit the /etc/named.local file. Refer to the "DOMAIN Local Data File Format for TCP/IP" in the AIX Version 4.3 Files Reference for more information and a detailed example of a local data file.
    1. Specify the start of authority of the zone and the default time-to-live information. For example: 
      @ IN SOA venus.abc.aus.cntry.com. gail.zeus.abc.aus.cntry.com. 
( 
                           1.1     ;serial 
                           3600    ;refresh 
                           600     ;retry 
                           3600000 ;expire 
                           86400)  ;minimum
    2. Specify the name server (NS) record. For example: 
      IN    NS     venus.abc.aus.century.com.
    3. Specify the pointer (PTR) record. 
      1      IN    PTR    localhost.
      Note: All lines in this file must be in Standard Resource Record Format.
  4. Create an /etc/resolv.conf file by issuing the following command: 
    touch /etc/resolv.conf
    The presence of this file indicates that the host should use a name server, not the /etc/hosts file, for name resolution.

    Alternatively, the /etc/resolv.conf file may contain the following entry:

    nameserver 127.0.0.1
    The 127.0.0.1 address is the loopback address, which causes the host to access itself as the name server. The /etc/resolv.conf file may also contain an entry such as: 
    domain domainname
    In the previous example, domainname would be austin.century.com .

  5. Perform one of the following steps:
  6. If you chose not to initialize the named daemon through SMIT, start the daemon for this session by issuing the following command: 
    startsrc -s named

Configuring a Host to Use a Name Server

To configure a host to use a name server, use the Web-based System Manager fast path wsm network or use the following procedure.

  1. Create an /etc/resolv.conf file.

  2. If this host will use more than one name server, add the other name servers that this host will use.

  3. Assuming the name server is operational, you can test the communication between the host and the name server using the following command: 
    host hostname
    Use the name of a host that should be resolved by the name server to see if the process is working. The output you should receive will appear similar to the following: 
    brown.abc.aus.century.com is 129.35.145.95

Other configuration tasks are shown in the following table.

Configuring a Host to Use a Name Server Tasks
Web-based System Manager:    wsm network fast path
(Network application)

-OR-
Task SMIT Fast Path Command or File
Create an /etc/resolv.conf File smit stnamerslv2 create and edit /etc/resolv.conf1
List All the Name Servers Used by a Host smit lsnamerslv view /etc/resolv.conf
Add a Name Server smit mknamerslv edit /etc/resolv.conf2
Remove a Name Server smit rmnamerslv edit /etc/resolv.conf
Start/Restart Using Domain Name Resolution smit stnamerslv
Stop Using Domain Name Resolution smit spnamerslv
Change/Show the Domain smit mkdomain edit /etc/resolv.conf
Remove the Domain smit rmdomain edit /etc/resolv.conf
Notes:
  1. On the first line of the /etc/resolv.conf file, enter the word domain followed by the full name of the domain that this host is in. For example: 
    domain abc.aus.century.com
  2. On any blank line below the line which starts with the word domain , enter the word nameserver , followed by at least one space, followed by the dotted decimal Internet address of the name server that this host will use (the name server must serve the domain indicated by the domain statement). You may have up to 16 name server entries. For example, your /etc/resolv.conf file might contain the entries: 
    nameserver 192.9.201.1 
nameserver 192.9.201.2
    The system will query the name servers in the order listed.

Configuring Dynamic Zones on the DNS Name Server

The named command allows for dynamic updates. The named database files need to be configured to allow for client machines to issue updates. A zone can be set to dynamic or static. The default zone is static. To make a zone dynamic, you need to add the keyword dynamic to the end of that zone's entry in the /etc/named.boot file. This tells the named command to load this zone with dynamic updates.

After a zone is marked dynamic, three modes of security can be initiated:

Unsecure Allows anyone at anytime to update any information in the zone.
Attention: Use of this mode is not recommended. It can lead to data loss, data interception, and user frustration.
Controlled Allows for the creation of new information and the replacement of existing information. This is probably the easiest mode to use for a secure transition environment. This mode also requires that all incoming updates be timestamped and have keyed signatures.
Secure Requires all updates to existing information be replaced with similar information. This mode also requires that all incoming updates be timestamped and have keyed signatures.

A dynamic zone defaults to secure mode. To use one of the other modes, add "unsecured" or "controlled" after the keyword dynamic in the /etc/named.boot file. This tells the named command the level of security to use with that zone.

After a mode is selected, the actual data files need to be modified for your level of security. In unsecure mode, the data files are used "as is." For secured mode, you need to generate a set of primary server/hostname key pairs. This should be done with the nsupdate command using the -g option. This command generates a set of key pairs, a private and a public key. These keys are needed to authentically sign for updates. After generating all the keys for your list of host names, you need to add them to the data file. The KEY format is as follows:

Index ttl Class Type KeyFlags Protocol Algorithm KeyData

Index Specifies the name used to reference the data in the zone.
ttl Specifies the time to live for this data. This is an optional field.
Class Specifies the class of the data. This is dependent on the zone, but usually it is IN.
Type Indicates the type of the record. In this case, it is KEY.
KeyFlags Gives named information about the key. 0x0000 means the key record will be used in secure mode. 0x0080 means the key record will be used in secure mode. This value should match the value in the /etc/named.boot file for the zone.
Protocol Specifies the protocol to use. Currently, there is only one, 0 .
Algorithm Specifies the algorithm of the key. Currently, there is only one, 1 . This is the MD5 Private/Public authentication method.
KeyData Indicates the key in base64 representation. The nsupdate command generates both the public and private keys in base64 representation. The public key is listed first in the output file.

Example

To dynamically update a hostname so the IP address it represents can be resolved, a line similar to the following needs to be added to the zone file for the zone containing the hostname.

bears    4660    IN    KEY    0x0000    0    1    AQOtg......

The above example indicates that bears has a KEY record defined. Someone wanting to update bears would need the private key generated to match the public key in the database. For an update to succeed, the private key needs to be placed on the client in /etc/keyfile. It should be in the format:

hostname      primaryname     base64    key

A similar entry is required in the zone definition section. A zone key is required for both secured and controlled modes. This can be done as shown in the previous bears example, but the private key is left for the administrator to use to fix zone problems. To generate the key using the nsupdate command, enter:

nsupdate -g -h ServerName -p ServerName -k AdminFile

This generates a key for the zone. Place the first key in the beginning section for the zone as follows:

IN     KEY     [0x0080|0x0000]   0   1   Key

The zone is ready to be loaded. The administrator should use the zone key to apply updates and maintenance operations on the zone.

[ Previous | Next | Contents | Glossary | Home | Search ]