分类：
2006-06-20 23:14:38
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 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.
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 , 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.
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.
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):
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 , 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 , 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:
| Master Name Server | Loads its data from a file or disk and may delegate authority to other servers in its domain. |
| Slave Name Server | Receives its information at system startup time for the given zone of authority from a master name server, and then periodically asks the master server to update its information. On expiration of the refresh value in the start of authority (SOA) Resource Record on a slave name server, or upon receipt of a Notify message from the master name server, the slave will reload the database from the master if the serial number of the database on the master is greater than the serial number in the current database on the slave. If it becomes necessary to force a new zone transfer from the master, simply remove the existing slave databases and refresh the named daemon on the slave name server. |
| Stub Name Server | Although its method of database replication is similar to that of the slave name server, the stub name server only replicates the Name Server records of the master database rather than the whole database. |
| Hint Server | Indicates a name server that relies only on the hints that it has built from previous queries to other name servers. The hint name server responds to queries by asking other servers that have the authority to provide the information needed if a hint name 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. Forwarding-only servers (a forwarder that obtains information and passes it on to other clients, but that is not actually a server) will not interact with the master 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, or when you may wish to build a large cache on a select number of name 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 master name server for one zone and a slave name server for another zone.
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. These routines are essentially accessors into a library of name translation routines known as resolvers.
Resolver routines on hosts running TCP/IP normally attempt to resolve names using the following sources:
When NIS+ is installed, lookup preferences are set using the irs.conf file. For more information, see AIX Version 4.3 Network Information Services (NIS and NIS+) Guide.
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 or 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 described above can be overwritten by creating the /etc/irs.conf configuration file and specifying the desired order. Also, both the default and /etc/irs.conf orderings can be overwritten with the environment variable, NSORDER. If either the /etc/irs.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/irs.conf file:
hosts value [ continue ]
The order is specified with each method indicated on a line by itself. The value is one of the listed methods and the continue keyword indicates that another resolver method follows on the next line.
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.
For example, if the local network is organized as a flat network, then only the /etc/hosts file is needed.
In this example, the /etc/irs.conf file would contain the following line:
hosts local
Alternatively, the NSORDER environment variable could 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/irs.conf file would contain the following lines:
hosts dns continue hosts local
The NSORDER environment variable would be set as:
NSORDER=bind,local
Note: The values listed must be in lowercase.
When following any defined or default resolver ordering, the search algorithm will continue from one resolver to the next only 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 getdomainname and yp_bind subroutines 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 at 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 NSORDER environment variable contains the following:
hosts = nis=auth,dns,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 DNS.
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, name servers can specify how long they expect their responses to be considered authoritative.
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.
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.
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.
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 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 |
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:
Changing a name is much more difficult than setting up the initial one. Obtain consensus from your organization on network, gateway, name server, and host names before you set up your files.
If you cannot set up redundant name servers, be sure to set up slave and hint name servers so you have some type of backup.
objectclass container
requires
objectclass,
cn
objectclass hosts
requires
objectclass,
hname
allows
addr
halias,
comment
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 master 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 slave name server or stub name server receives its information at system startup time for a given zone of authority from a master name server, and then periodically asks the master server to update its information. A hint name server responds to requests to resolve names by querying other servers that have the authority to provide the information needed.
Note: Previous generations of the named name server specified the master name server as the primary name server, the slave name server as the secondary name server, and the hint name server as the caching-only name server. Any reference to the named.conf file in this documentation is specific to AIX version 4.3.2 and above.
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 master name server for one zone and a slave name server for another zone. If your system has NIS or NIS+ installed, these services can also provide name resolution. For more information, see AIX Version 4.3 Network Information Services (NIS and NIS+) Guide.
There are several files involved in configuring name servers.
| conf | This file is read when the named daemon starts. The records in the conf 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.conf. 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.conf as the conf file, if it does not exist, a message is generated in syslog and named terminates. However, if an alternative conf 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 conf file. |
| domain data | There are three typical 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 file names are user definable and are set in the conf 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.abc.data named.abc.rev named.abc.local When modifying the named data files the serial number in the SOA Resource Record must be incremented for slave name servers to properly realize the new zone changes. |
| 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.
To configure a master 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.
This file is read each time the named daemon starts. It tells the server which type of server it is, the zone or zones for which it is responsible, and where to get its initial information.
options {
directory "/usr/local/domain";
};
zone "." IN {
type hint;
file "/etc/named.ca";
};
zone "abc.aus.century.com" in {
type master;
file "/etc/named.abcdata";
};
zone "201.9.192.in-addr.arpa" in {
type master;
file "/etc/named.abcrev";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "/etc/named.local";
};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 .
@ IN SOA venus.abc.aus.cntry.com. gail.zeus.abc.aus.cntry.com.
(
1.1 ;serial
3600 ;refresh
600 ;retry
3600000 ;expire
86400) ;minimum
IN NS venus.abc.aus.century.com.
1 IN PTR localhost.
Note: All lines in this file must be in .
@ IN SOA venus bob.robert.abc.aus.century.com.
(
1.1 ;serial
3600 ;refresh
600 ;retry
3600000 ;expire
86400) ;minimum
venus IN A 192.9.201.1 venus IN A 128.114.100.1
IN NS venus.abc.century.com IN NS kronos.xyz.century.com
Note: All lines in this file must be in .
@ IN SOA venus.abc.aus.century.com. bob.robert.abc.aus.century.com.
(
1.1 ;serial
3600 ;refresh
600 ;retry
3600000 ;expire
86400) ;minimum
;ABC.AUS.CENTURY.COM Hosts 1 IN PTR venus.abc.aus.century.com. 2 IN PTR kronos.abc.aus.century.com.
Note: All lines in this file must be in .
touch /etc/resolv.confThe 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.1The 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 domainnameIn the previous example, domainname would be aus.century.com.
smit stnamedThis initializes the daemon with each system startup. Indicate whether you want to start the named daemon now, at the next system restart, or both.
#start /etc/named "$src_running"This initializes the daemon with each system startup.
startsrc -s named
To configure a slave 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.
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.
options {
directory "/usr/local/domain";
};
zone "." IN {
type hint;
file "/etc/named.ca";
};
zone "abc.aus.century.com" IN {
type slave;
file "/etc/named.abc.bak";
masters { 192.9.201.1; 192.9.201.2; };
};
zone "xyz.aus.century.com" IN {
type slave;
file "/etc/named.xyz.bak";
masters { 192.9.201.1; 192.9.201.2; };
};
zone "201.9.192.in-addr.arpa" IN {
type slave;
file "named.rev.bak";
masters { 192.9.201.1; 192.9.201.2; };
};
zone "100.114.128.in-addr.arpa" IN {
type slave;
file "named.rev.bak";
masters { 192.9.201.1; 192.9.201.2; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "/etc/named.local";
};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 .
@ IN SOA venus.abc.aus.cntry.com. gail.zeus.abc.aus.cntry.com.
(
1.1 ;serial
3600 ;refresh
600 ;retry
3600000 ;expire
86400) ;minimum
IN NS venus.abc.aus.century.com.
1 IN PTR localhost.
Note: All lines in this file must be in .
touch /etc/resolv.confThe 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.
smit stnamedThis initializes the daemon with each system startup. Indicate whether you want to start the named daemon now, at the next system restart, or both.
#start /etc/named "$src_running"This initializes the daemon with each system startup.
startsrc -s named
To configure a hint, or 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.
Configure a hint name server according to the following steps:
zone "0.0.127.in-addr.arpa" IN {
type master;
file "/etc/named.local";
};
zone "." IN {
type hint;
file "/etc/named.ca";
};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 .
@ IN SOA venus.abc.aus.cntry.com. gail.zeus.abc.aus.cntry.com.
(
1.1 ;serial
3600 ;refresh
600 ;retry
3600000 ;expire
86400) ;minimum
IN NS venus.abc.aus.century.com.
1 IN PTR localhost.
Note: All lines in this file must be in .
touch /etc/resolv.confThe 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.
smit stnamedThis initializes the daemon with each system startup. Indicate whether you want to start the named daemon now, at the next system restart, or both.
#start /etc/named "$src_running"This initializes the daemon with each system startup.
startsrc -s named
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.
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
Cw $w $?D$w.$D$. widget.com
DRblack.widget.com
sam:sam@orange.widget.com david:david@green.widget.com judy:judy@red.widget.com
Note: Mailbox (MB) records can serve the same function.
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.
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.
sammy IN MR samThis record will cause all mail addressed to sammy to be delivered to sam. Each MR record should be entered on a line by itself.
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.
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.
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.
options {
...
forwarders { 192.100.61.1; 129.35.128.222; };
...
};
zone "." IN {
type hint;
file "/etc/named.ca";
};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.
@ IN SOA venus.abc.aus.cntry.com. gail.zeus.abc.aus.cntry.com.
(
1.1 ;serial
3600 ;refresh
600 ;retry
3600000 ;expire
86400) ;minimum
IN NS venus.abc.aus.century.com.
1 IN PTR localhost.
Note: All lines in this file must be in .
touch /etc/resolv.confThe 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.1The 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 domainnameIn the previous example, domainname would be austin.century.com.
smit stnamedThis initializes the daemon with each system startup. Indicate whether you want to start the named daemon now, at the next system restart, or both.
#start /etc/named "$src_running"This initializes the daemon with each system startup.
startsrc -s named
To configure a forward 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.
Note: You can achieve a similar configuration without running a forward only name server. Instead, create an /etc/resolv.conf file that contains name server lines that point to the forwarders you wish to use.
options {
...
forwarders { 192.100.61.1; 129.35.128.222; };
forward only;
...
};; 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.
@ IN SOA venus.abc.aus.cntry.com. gail.zeus.abc.aus.cntry.com.
(
1.1 ;serial
3600 ;refresh
600 ;retry
3600000 ;expire
86400) ;minimum
IN NS venus.abc.aus.century.com.
1 IN PTR localhost.
Note: All lines in this file must be in .
touch /etc/resolv.confThe 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.1The 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 domainnameIn the previous example, domainname would be austin.century.com.
smit stnamedThis initializes the daemon with each system startup. Indicate whether you want to start the named daemon now, at the next system restart, or both.
#start /etc/named "$src_running"This initializes the daemon with each system startup.
startsrc -s named
To configure a host to use a name server, use the Web-based System Manager fast path wsm network or use the following procedure.
host hostnameUse 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:
- 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- 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.2The system will query the name servers in the order listed.
The named command allows for dynamic updates. The named database and configuration 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 allow-update to that zone's stanza in the /etc/named.conf file. The allow-update keyword specifies an Internet address match list that define hosts allowed to submit updates. Refer to the in the AIX Version 4.3 Files Reference for more information and a detailed example of a conf file. In the following example, all hosts are allowed to update the dynamic zone:
zone "aoot.austin.ibm.com" IN {
type master;
file "named.data";
allow-update { any; };
};
After a zone is marked dynamic, three modes of security can be initiated:
| Unsecured | Allows anyone at anytime to update any information in the zone.
Warning: Use of this mode is not recommended. It can lead to data loss, data interception, and user frustration. At the least, an unsecured zone should be limited to updates only from specific internet addresses. |
| 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. |
| Presecured | 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 unsecured mode. To use one of the other modes, add "controlled" or "presecured" after the keyword update-security in the zone stanza of the /etc/named.conf file. This tells the named server the level of security to use with that zone. For example:
zone "aoot.austin.ibm.com" IN {
type master;
file "named.boot";
allow-update { any; };
update-security controlled;
};
After a mode is selected, the actual data files need to be modified for your level of security. In unsecured mode, the data files are used "as is." For controlled or presecured mode, you need to generate a set of master server/hostname key pairs per name in the zone. This should be done with the nsupdate command using the -g option. This command generates the key pair, a private and a public key. These keys are needed to authentically sign for updates. After generating all the keys for your list of zone names, you need to add them to the data file. The KEY format is as follows:
Index ttl Class Type KeyFlags Protocol Algorithm KeyData
where:
| 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 defines the typical key record used for a host. 0x0100 defines the key record associated with the zone name. |
| 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 last in the output file. |
To ensure security over a host name in a dynamic zone, 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 to sign his update with the private key matching the this public key in the database. For the nsupdate command to succeed, the private key needs to be placed on the client in a keyfile (defaults to /etc/keyfile). It should be in the format:
hostname mastername base64 key
A similar KEY entry is required in the zone definition section. A zone key is required for both presecured and controlled modes or the mode is considered to be unsecured. This can be done as shown in the previous bears example, but the private key is left for the administrator to use with the nsupdate command's administrative mode.
To generate a key pair using the nsupdate command, enter:
nsupdate -g -h ZoneName -p ServerName -k AdminKeyFile
This generates a key for the zone. Place the last key of the pair in the beginning section for the zone as follows:
IN KEY 0x0100 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.