| Systems Administration Toolkit: Understanding DNS | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 摘自: IBM developerWorks Worldwide 被阅读次数: 96 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
由 yangyi 于 2008-05-09 23:51:07 提供 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Level: Intermediate Martin Brown (mc@mcslp.com), Professional Writer, Freelance 04 Mar 2008 The Domain Name System (DNS) is the service that converts hostnames and domain details into the IP addresses required for application to communicate. Under UNIX®, the primary DNS service is based on BIND, and DNS itself is a key part of most UNIX installations. This article looks at the basics of DNS setup, how servers and requests are distributed, and exchanged and how to set up and keep a DNS environment running smoothly. The typical UNIX administrator has a key range of utilities, tricks, and systems he or she uses regularly to aid in the process of administration. There are key utilities, command line chains, and scripts that are used to simplify different processes. Some of these tools come with the operating system, but a majority of the tricks come through years of experience and a desire to ease the system administrator's life. The focus of this series is on getting the most from the available tools across a range of different UNIX environments, including methods of simplifying administration in a heterogeneous environment.
As a general rule, humans are not particularly good at remembering numbers. Unfortunately, the IP addressing system uses numbers to identify individual hosts. Remembering numbers for all of the machines that you might want to use both inside and outside of your network is obviously impractical. Instead, it's easier to remember the name of your server as 'bear' or the address of a Web site on the Internet as www.mcslp.com. Historically, UNIX has used three main locations for this type of information. The built-in /etc/hosts file is the main source and a useful backup, but keeping it up to date across multiple machines requires a lot of copying of data. A distributed system, where individual machines and services can contact a central point, is the better method and two systems, the Network Information System (NIS) and DNS, were developed with different goals in mind. NIS is a general-purpose database-sharing service and can be used to share host, password, and other normally text-based databases. Unfortunately, NIS is not as effective across systems, and certainly not in the distributed format of the Internet. The Domain Name System (DNS) resolves that by providing a mechanism so that names can be resolved to the appropriate IP address. Addresses within the domain name system are organized in a tree structure. Although you can organize any private DNS in the format that you want, it is easiest to understand the DNS system by looking at the structure used on the Internet. Looking at a typical DNS address, www.mcslp.com, the name can be divided by splitting up the contents by a period, starting with the fragment on the far right (com). From our example, www.mcslp.com, the 'com' is example of a top-level domain (TLD) name that organizes the names by organizational or regional structure. For example, valid TLDs included com (commercial), edu (educational) and net (network related). On the Internet, regional organization provides for country-specific TLDs, such uk for the United Kingdom or fr for France. Each fragment to the left of the TLD is a subdivision of the original domain. For example, mcslp.com is a subdivision of the com TLD. Further subdivisions can occur, up to a maximum of 127 levels. Each subdivision is known as a subdomain. From the example, mcslp.com is a subdomain of the com TLD, and www.mcslp.com is a subdomain of the mcslp.com subdomain. The use of subdomains has two main purposes; one is for ease of identification and the other is for the purposes of delegation. From an identification perspective, it is much easier to understand and identify that www.mcslp.com and bear.mcslp.com are both hosts within the mcslp.com domain. Similarly, it is easy to identify that www.google.com and mail.google.com are both hosts within the google.com domain. The delegation relates to the way in which administrators (and computers) are responsible for the configuration and contents of the various domains. The mclsp.com domain is a subdomain of the com TLD. The administrators of the com TLD have given permission for the domain and subdomains of the mcslp.com domain to be the responsibility of another administrator. This delegation is what enables administrators of services on the Internet to 'own' a domain and in turn assign their own IP addresses, configure their own names, and organize their own structure to help them identify the machines within their network. Internally, the domain name system can also be used as a method for identifying and locating machines on your network, and you can use the organization and delegation features of DNS to help organize your network. For example, mcslp.com is the public domain for a company, while mcslp.pri is the private domain used internally to identify machines within the network. The address www.mcslp.pri relates to an internal Web server, and mail.mcslp.pri relates to an internal mail server. In addition, a subdomain, vm.mcslp.pri, is used to provide a logical grouping of hosts (in this case, virtual machines).
How domain name resolution works Domain name resolution works by a client contacting a server and requesting that a particular address be resolved to the corresponding part (i.e., name to IP address, or IP address to name). Because name servers can hold different types of information, the exact response and process depends on the query, but for the examples we will assume a simple name lookup that is expecting an IP address in response. In general, the client asks the server to resolve an address and receives the resolved address back from the server. Queries can be of two types: recursive and non-recursive. In a recursive query, the client expects the server to respond the full answer (i.e., to resolve a name to the IP address). Non-recursive queries allow the server to return a partial response, such as returning the name or address of the server that may know the answer (or may have more information). The reason for this is that the DNS systems work on a system with an analogy similar to Chinese whispers. If the server doesn't know the answer itself (because it is not responsible for the domain), then it will find out which server is responsible for the domain and ask that server instead. In a recursive query, the server does the asking and returns the final result. Non-recursive queries are generally used by servers when talking to each other to resolve a query on behalf of a client. You can see this more clearly by looking at Figure 1. The numbers in the diagram relate to the same steps within the list below.
Earlier in this article, I discussed the role of delegation and the subdivision of domains and subdomains to allow individual administrators to be responsible for their own domains and the information and hosts defined within that domain. Setting up your own domain server can be useful both if you are hosting a public DNS domain available on the Internet, and if you want to configure your own DNS information to resolve the addresses and other information within your private network. To set up a DNS server within a UNIX server or client, you need a DNS daemon, which answer queries about one or more domains. The most common daemon is BIND, and most implementations of a DNS server use BIND or a derivative of the BIND code as the basis for their DNS service. The core of the BIND service is a daemon called named (or in.named), which handles all of the queries. The configuration of a typical BIND environment involves the main named configuration file, usually /etc/named.conf (or /etc/bind/named.conf) and a number of 'zone' files, which hold the individual information about each DNS domain that the server is responsible for. The main configuration file sets up the directories used for the zone files, security information, and also the additional servers that should be queried if the DNS server is unable to resolve the address itself. You need this setting if you want your server to resolve addresses outside of your network (for example, on the Internet), in addition to those inside your network for the configured zones. You can see the header portion of a simple configuration file in Listing 1. Listing 1. Simple configuration file
Note that within the configuration file you need to use the double-slash (//) to introduce a comment. You should also be aware that the semicolon is used to split up individual configuration options of the file, and that braces are used to group configuration options together. Most problems with the content of the configuration file are introduced when a semicolon or brace is missing. The individual configurable options show in this example are as follows:
The remainder of the configuration file contains the zone file data that will be used by your server to share DNS information.
DNS information is stored within a series of 'zone' files. Typically you have one zone file for each domain that you host.
All configured zones within your configuration are designated either as master or secondary. Master zones are those for which the server is a master host (i.e., the delegated server for the domain). Only one server can be the master for a domain; additional servers that can be authoritative for a domain (that is, they provide qualified responses) are classed as 'secondary,' or slave, servers. You can use the slave servers to help spread the load and provide resilience in the event of a failure. We'll return to this issue later in this article. For each zone file that you host, you must add a zone portion to the named.conf file (see Listing 2). Listing 2. Adding a zone portion to the named.conf file
This configures the zone mcslp.pri (an internal subdomain used to identify computers only on the local network), the file in which the zone data is located (relative to the directory option), and the type of the file. In this case, the actual file will be located in /var/bind/pri/mcslp.pri.zone. An example of the contents of the file, in this case a 'forward' zone, primarily mapping names to IP addresses, are shown in Listing 3. Listing 3. Zone file
The header block of the zone file specifies the information about the domain. In this case, we specify the domain name and the SOA (Start of authority) information. The SOA configures the data about the domain to define which servers are classed as authoritative (that is, then give qualified responses to queries for this domain). The remainder of the SOA record configures a serial number (used by other DNS servers to determine whether their copy of the domain data is up to date), and the refresh and retry intervals (in seconds) for updating the information. From our example, there is only one server qualified to give responses about hosts and other data within the domain, bear.mcslp.pri. The hostname, rather than IP address, is provided so that you can change the host IP address without having to update the DNS SOA record. The remainder of the information within the zone file then configures the specific DNS records. DNS is capable of holding much more information than simple name to address data, and therefore the DNS records are organized into different types. A list of the main types includes:
For names within the domain, you can specify a name that is implied to be within the domain simply by specifying the name, for example: Because the DNS knows that this file contains information for the mcslp.pri domain, the full hostname is expanded to bear.mcslp.pri. You can also specify the fully qualified domain name (FQDN) by setting the full hostname and appending a period to the end of the name: The above will configure the amazon.mcslp.pri hostname to act as an alias to www.amazon.com. Returning to the original list of hosts, the hosts are configured as follows in Listing 4. Listing 4. Configuring the hosts
The mail exchanger records are used by mail transport agents like sendmail and postfix when looking up where to send e-mail. In the above example, bear.mcslp.pri is configured to accept any e-mail where the domain within the e-mail address is mcslp.pri. For 'reverse' lookups, that is, when you want to resolve an IP address to a name, you should set up an additional zone. Reverse zones have a specific domain name that identifies them as reverse zones. You can see an example of this in Listing 5. Listing 5. Reverse zones
The domain is the portions of your IP address class, in reverse order, and then placed within the in-addr.arpa domain. For example, IP addresses in the class C address 192.168.0.x are defined within the 0.168.192.in-addr.arpa domain, as shown in Listing 4. The header and NS (name server) records are as before. IP address to hostname mappings are defined use the PTR (pointer) record. You should have one of these records for each corresponding name to IP address entry within your domain. To add your reverse domain mapping to your named config, specify the domain and domain file in the same way within your named.conf file (see Listing 6). Listing 6. Adding reverse domain mapping
You should also configure the 'hint' zone, which refers to the root servers and a localhost forward and reverse domain so that resolution of localhost and 127.0.0.1 (the localhost IP address) operate correctly. You can find examples of these in the bind source, and usually also provided with your bind installation. Listing 7 shows the named.conf zone entries. Listing 7. named.conf zone entries
Once the zones are configured and you have added the zone file, you can start up the
named daemon. For most UNIX/Linux variants, you can do this using the script in /etc/init.d: For Solaris 10, use Once the named daemon is running, make sure you edit your /etc/resolv.conf file (see Listing 8) to configure the domain and DNS servers that provide responses: Listing 8. Edit your /etc/resolv.conf file to configure the domain and DNS servers
You may also need to edit your /etc/nsswitch.conf file so that hostname lookups are redirected to the DNS service. For example, to use the local files first and then resort to DNS: You should now be able to look up hosts from the DNS using dig, a tool that queries DNS servers for information. Listing 9 shows the result when looking up bear.mcslp.pri. Listing 9. Result when looking up bear.mcslop.pri
The output shows the server that was queried, and the full DNS record returned.
DNS is a distributed service, in that more than one server is capable of responding to a given query, providing it knows who to ask for the information. In addition to forwarding DNS requests and the recursive nature, you can also configure more than one server to be 'authoritative' for a particular domain. Secondary or slave servers are delegated through the domains NS records as being qualified to give responses. Secondary DNS servers transfer their zone information directly from the primary DNS server and keep a copy locally. Clients can then be configured to use one or more of the DNS servers responsible for a domain. This can help to reduce the load on requests and also ensures that if the primary server (or another slave) is down when a query is made, another server can provide an answer to the client resolution query. To add more DNS servers to your configuration, first edit your zone files and add NS records for each slave that will also be hosting the domain. This ensures that your slaves will return authoritative answers to queries for that domain. Then, add an entry to your named.conf file that specifies the domain name with a type of 'slave' and then providing a list of qualified 'masters' that can transfer a copy of the domain to the slave. For an example, setting up a slave for the mcslp.pri domain (see Listing 10). Listing 10. Setting up a slave for the mcslp.pri domain
Now reload or start the named service on your slave server and check the logs. You should see entries reporting the successful transfer of the domain to your slave (see Listing 11). Listing 11. Reloading the named service on your slave server
Now you can add the IP address of your new slave server to the list of valid IP addresses to query.
The DNS system, at its heart, resolves the names with which we are all familiar on the Internet and locally on our networks to an IP address. Although we take the system for granted, it is in fact a well-designed service that distributes and delegates queries and zones around the Internet and enables you to create custom zones within your own network. In this article we've seen how the fundamentals of the DNS service work, and how that relates not only to the internal process of resolve local addresses but also to addresses on the Internet. We've also examined how to create a simple DNS setup for use on your local network, and how that integrates with Internet name resolution. Learn
Get products and technologies
Discuss
Original link: http://www.ibm.com/developerwork... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
