What zone configuration file contains a ptr record used to identify the loopback adapter?
[ Previous | Next | Contents |
Glossary | Home | Search ]
AIX Version 4.3 System Management Guide: Communications and Networks 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. Show
The topics discussed in this section are:
NamingNaming 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 AuthorityIn 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 ConventionsIn 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 NetworkThe 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 ServersIn 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:
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. Name ResolutionThe 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 attempt to resolve names using the following sources:
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. The DNS resolver 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 hosts map on the master NIS server is checked. By default, resolver routines attempt to resolve names using the above resources. If the /etc/resolv.conf file exists, the BIND/DNS mechanism will be tried first. If the /etc/resolv.conf file does not exist or if the domain name server could not resolve the query, NIS is queried if available. Availability of the NIS service is determined if the domainname is configured on the client, and the yp client is bound to a server. Because NIS is authoritative over the local /etc/hosts, the search may end here. However, if NIS is not available, 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:
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. Potential Host Name Conflict Between nameserver and sendmailIn 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 sendmailFor 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 ProtocolThe 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.
Planning for DOMAIN Name ResolutionIf 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 ServersIn 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 the Network Information Service (NIS) application installed, NIS can also provide Name-server service. There are several files involved in configuring name servers.
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 Master Name ServerTo 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 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.
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.
startsrc -s named Configuring a Slave Name ServerTo 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.
Configuring a Hint Name ServerTo 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. ProcedureConfigure a hint name server according to the following steps:
Configuring a Domain Mail ServerConfiguring 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 , 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, . 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
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
Defining a Mail Rename (MR) Record for a User
Defining Mail Group (MG) Member Records
Defining Mail Exchanger (MX) Records
Configuring a ForwarderTo 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.
Configuring a Forward Only ServerTo 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.
Configuring a Host to Use a Name ServerTo configure a host to use a name server, use the Web-based System Manager fast path wsm network or use the following procedure.
Other configuration tasks are shown in the following table.
Notes: Configuring Dynamic Zones on the DNS Name ServerThe 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 "named.conf File Format for TCP/IP" 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:
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:
ExampleTo 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. [ Previous | Next | Contents | Glossary | Home | Search ] What DNS resource record type is used to provide the IP address for the e mail server for a zone?Every DNS zone requires a start of authority (SOA) record. RFC 1035 specifies SOA record formats. The SOA record stores important information about the zone, such as its primary authoritative name server and the administrator's email address.
What PostgreSQL command line utility backs up PostgreSQL database settings?PostgreSQL provides the pg_dump utility to simplify backing up a single database. This command must be run as a user with read permissions to the database you intend to back up.
What FTP command uploads the filename?APPE FTP command
A client issue the APPE command after successfully establishing a data connection when it wishes to upload data to the server. The client provides the file name it wishes to use for the upload. If the file already exists on the server, the data is appended to the existing file.
What DNS resource record type is used to provide an IP address for the email server for a zone quizlet?This is the most common resource record type. The AAAA records maps an IPv6 (128-bit) DNS host name to an IP address. The MX record identifies servers that can be used to deliver e-mail.
|