Hướng Dẫn What zone configuration file contains a ptr record used to identify the loopback adapter?

Mẹo Hướng dẫn What zone configuration file contains a ptr record used to identify the loopback adapter? Mới Nhất

Hoàng Nhật Mai đang tìm kiếm từ khóa What zone configuration file contains a ptr record used to identify the loopback adapter? được Cập Nhật vào lúc : 2022-10-26 06:46:05 . Với phương châm chia sẻ Kinh Nghiệm về trong nội dung bài viết một cách Chi Tiết Mới Nhất. Nếu sau khi tham khảo Post vẫn ko hiểu thì hoàn toàn có thể lại Comment ở cuối bài để Tác giả lý giải và hướng dẫn lại nha.
[ 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.

Nội dung chính Show

Naming Performing Local Name Resolution (/etc/hosts) Planning for DOMAIN Name Resolution Configuring Name Servers Configuring a ForwarderConfiguring a Forward Only ServerConfiguring a Host to Use a Name Server Configuring Dynamic Zones on the DNS Name Server What DNS resource record type is used to provide the IP address for the e mail server for a zone?What PostgreSQL command line utility backs up PostgreSQL database settings?What FTP command uploads the filename?What DNS resource record type is used to provide an IP address for the email server for a zone quizlet?

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 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 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:

Terms that are rarely used, for example, sphinx or eclipse.Theme names, such as colors, elements (for example, helium, argon, or zinc), flowers, fish, and others.Real words (as opposed to random strings of characters).

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):

Terms that are already in common use, for example, up, down, or crash.Names containing only numbers.Names that contain punctuation marks.Names that rely on case distinction, for example, Orange and orange.The name or initials of the primary user of the system.Names having more than 8 characters.Unusual or purposefully incorrect spellings, for example, czek, which could be confused with "check" or "czech."Names that are, or resemble, domain names, for example, yale.edu.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:

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 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 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.

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. 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:

BIND/DNS (named)Network Information Service (NIS)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. 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 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,localNote: 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:

current service is not running, therefore, it is unavailable.current service could not find the name and is not authoritative.

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 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 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 sendmail

In a DNS environment, a host name that is set using the hostname command from the command line or in the rc 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.rootdomainNote: 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:

Only reply to RARP requestsOnly use permanent ARP table entriesNot use dynamic ARP table entriesNot automatically reply for itself

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 TasksWeb-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:

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.

Choose machines that are physically closest to exterior systems.The name servers should be as independent as possible. Try for different power supplies and independent cabling.Find another network to back up your name resolution service, and do the same for other networks.

Test both regular and reverse name resolution.Test zone transfer from master to slave name servers.Test each name server after a system crash and reboot.

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 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 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.

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.

Configuring a Master Name Server

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.

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

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.

Using the options configuration clause, specify the directory in which the named data files can be located (optional). Use this if you want the named data files to use paths relative to this directory. For example: options directory "/usr/local/domain"; ;Optionally specify the name of the hint zone file. This allows for the caching of record data outside of the defined zones. For example: zone "." IN type hint; file "/etc/named.ca"; ;Specify a number of zones. To configure a server as the master for a zone, specify each zone and its domain data file. For example, a master server for both forward and reverse zones might resemble: 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"; ;Define the name of the named local file. For example: zone "0.0.127.in-addr.arpa" in type master; file "/etc/named.local"; ;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.2Note: All lines in this file must be in Standard Resource Record Format.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. 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) ;minimumSpecify the name server (NS) record. For example: IN NS venus.abc.aus.century.com.Specify the pointer (PTR) record. 1 IN PTR localhost.Note: All lines in this file must be in Standard Resource Record Format.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. 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) ;minimumInclude 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.1Include name server records for all master name servers in the zone. For example: IN NS venus.abc.century.com IN NS kronos.xyz.century.comInclude 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.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. 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) ;minimumInclude 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.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.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.Perform one of the following steps:

Enable the named daemon using the following SMIT fast path: smit stnamed This initializes the daemon with each system startup. Indicate whether you want to start the named daemon now, the next system restart, or both.Edit the /etc/rc.tcpip file. Uncomment the line for the named daemon by removing the comment (#) symbol from the following line: #start /etc/named "$src_running" This initializes the daemon with each system startup.If you chose not to initialize the named daemon through SMIT, start the daemon for this session by running the following command: startsrc -s namedConfiguring a Slave Name Server

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.

Edit the /etc/named.conf file. If there is no named.conf file in the /etc directory, copy the /usr/samples/tcpip/named.conf sample file into the /etc directory and edit it. 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.

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.

Using the options configuration clause, specify the directory where the named data files can be located (optional). Use this if you want the named data files to use paths relative to this directory. For example: options directory "/usr/local/domain"; ;Optionally specify the name of the hint zone file for the name server. This allows for the caching of record data outside of the defined zones. For example: zone "." IN type hint; file "/etc/named.ca"; ;Specify the slave zone clauses. Each stanza includes the zone type, an optional file name to which the name server can back up its data, and the list of master server Internet addresses. This list of addresses define the hosts from which the zone will be replicated. For example: 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; ; ;Include slave zone clauses to define the reverse name resolution information for the name server. For example: 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; ; ;To support resolving the loopback network address, specify a zone of type master with a source of /etc/named.local as well as the domain for which the name server will be responsible. zone "0.0.127.in-addr.arpa" IN type master; file "/etc/named.local"; ;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:

Enable the named daemon using the following SMIT fast path: smit stnamed This initializes the daemon with each system startup. Indicate whether you want to start the named daemon now, the next system restart, or both.Edit the /etc/rc.tcpip file. Uncomment the line for the named daemon by removing the comment (#) symbol from the following line: #start /etc/named "$src_running" This initializes the daemon with each system startup. If you chose not to initialize the named daemon through SMIT, start the daemon for this session by running the following command: startsrc -s namedConfiguring a Hint Name Server

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.

Procedure

Configure a hint name server according to the following steps:

To support resolving the loopback network address, specify a zone of type master with a source of /etc/named.local as well as the domain for which the name server will be responsible. For example: zone "0.0.127.in-addr.arpa" IN type master; file "/etc/named.local"; ;Specify the name of the cache zone file. For example: zone "." IN type hint; file "/etc/named.ca"; ;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:

Enable the named daemon using the following SMIT fast path: smit stnamed This initializes the daemon with each system startup. Indicate whether you want to start the named daemon now, the next system restart, or both.Edit the /etc/rc.tcpip file. Uncomment the line for the named daemon by removing the comment (#) symbol from the following line: #start /etc/named "$src_running" This initializes the daemon with each system startup.If you chose not to initialize the named daemon through SMIT, start the daemon for this session by issuing the following command: startsrc -s namedConfiguring 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 , 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 ServerCreate 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.9Edit sendmail.cf on the mail server (black.widget.com) to add the domain alias (the w class): Cw $w $?D$w.$D$. widget.comMail 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.comUse the NameServOpt option to configure the sendmail daemon so everyone can use the MX records defined in the name server brown.widget.com. Add aliases for users in the domain that do not have accounts on the mail server using the aliases file, for example: sam: david: judy:Note: Mailbox (MB) records can serve the same function. The serial number in the SOA Resource Record should be incremented because the database has been modified. Refresh the name server database by issuing the refresh -s named command.Perform the following steps: Enter the command sendmail -bz to recompile the sendmail.cf file on the mail server. Enter the command sendmail -bi to recompile the aliases database on the mail server. Run the refresh -s sendmail command to make the changes take effect. 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) RecordsDefine 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. 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. Increment the serial number in the SOA Resource Record, because the database has been modified. Refresh the name server database by running the refresh -s named command. 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 UserEdit the /etc/named.data file on your domain name server.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.Since the database has been modified, the serial number in the SOA Resource Record should be incremented.Refresh the name server database by issuing the refresh -s named command.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 RecordsEdit the /etc/named.data file on your domain name server.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 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.The serial number in the SOA Resource Record should be incremented, because the database has been modified. Refresh the name server database by issuing the refresh -s named command.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) RecordsEdit the /etc/named.data file on your domain name server.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. The serial number in the SOA Resource Record should be incremented because the database has been modifiedRefresh the name server database using the refresh -s named command.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.

Specify a forwarders line in the options stanza of the /etc/named.conf file that lists the IP addresses of the name servers that should receive the forwarded requests. For example: options ... forwarders 192.100.61.1; 129.35.128.222; ; ... ;Specify the hint zone. For example: zone "." IN type hint; file "/etc/named.ca"; ;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:

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

Configuring a Forward Only Server

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.Edit the /etc/named.conf file. If there is no named.conf file in the /etc directory, copy the /usr/samples/tcpip/named.conf sample file into the /etc directory and edit it. 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.

Specify the forwarders and forward only lines in the options stanza of the /etc/named.conf file listing the IP addresses of the name servers receiving the forwarded requests. For example: options ... forwarders 192.100.61.1; 129.35.128.222; ; forward only; ... ;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.2Note: All lines in this file must be in Standard Resource Record Format.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. 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 Specify the name server (NS) record. For example: IN NS venus.abc.aus.century.com.Specify the pointer (PTR) record. 1 IN PTR localhost.Note: All lines in this file must be in Standard Resource Record Format.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.Perform one of the following steps:

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.

Create an /etc/resolv.conf file.If this host will use more than one name server, add the other name servers that this host will use.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 TasksWeb-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.comOn any blank line below the line which starts with the word domain, enter the word nameserver, followed by 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 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:

Unsecured Allows anyone 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. Example

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.

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. Tải thêm tài liệu liên quan đến nội dung bài viết What zone configuration file contains a ptr record used to identify the loopback adapter?

Review What zone configuration file contains a ptr record used to identify the loopback adapter? ?

Bạn vừa tham khảo nội dung bài viết Với Một số hướng dẫn một cách rõ ràng hơn về Review What zone configuration file contains a ptr record used to identify the loopback adapter? tiên tiến nhất

Share Link Download What zone configuration file contains a ptr record used to identify the loopback adapter? miễn phí

Quý khách đang tìm một số trong những Chia SẻLink Download What zone configuration file contains a ptr record used to identify the loopback adapter? Free.

Hỏi đáp thắc mắc về What zone configuration file contains a ptr record used to identify the loopback adapter?

Nếu sau khi đọc nội dung bài viết What zone configuration file contains a ptr record used to identify the loopback adapter? vẫn chưa hiểu thì hoàn toàn có thể lại phản hồi ở cuối bài để Admin lý giải và hướng dẫn lại nha #zone #configuration #file #ptr #record #identify #loopback #adapter - 2022-10-26 06:46:05

Hướng Dẫn What zone configuration file contains a ptr record used to identify the loopback adapter? - Lớp.VN

Mẹo Hướng dẫn What zone configuration file contains a ptr record used to identify the loopback adapter? Mới Nhất

Naming

Performing Local Name Resolution (/etc/hosts)

Planning for DOMAIN Name Resolution

Configuring Name Servers

Configuring a Forwarder

Configuring a Forward Only Server

Configuring a Host to Use a Name Server

Configuring Dynamic Zones on the DNS Name Server

What DNS resource record type is used to provide the IP address for the e mail server for a zone?

What PostgreSQL command line utility backs up PostgreSQL database settings?

What FTP command uploads the filename?

What DNS resource record type is used to provide an IP address for the email server for a zone quizlet?

Review What zone configuration file contains a ptr record used to identify the loopback adapter? ?

Share Link Download What zone configuration file contains a ptr record used to identify the loopback adapter? miễn phí

Hỏi đáp thắc mắc về What zone configuration file contains a ptr record used to identify the loopback adapter?

Contact Form