کد:
http://articles.techrepublic.com.com/5100-10878_11-1048140.html
Takeaway: How to configure basic DNS records for use with BIND

Properly managing DNS records is essential when hosting a DNS server. It is also a skill that takes some careful reading and practice to fully master. Previously, I introduced you to BIND, or Berkeley Internet Name Domain, the most common software package for implementing DNS services, and showed you how to set it on a Linux server. Now, I will show how to configure basic DNS records for use with BIND, and I’ll define standard DNS features. The basic DNS records you will encounter in this article are platform-independent and will work on any Linux system running BIND.

Configuring DNS records
Once BIND has been set up on your system, you can create DNS records to provide services for your Internet domains. DNS records, also known as zone files, are plain-text files that tell the server what to do with a given domain. These files are usually served out of a centralized directory such as /var/named/but can be placed anywhere as long as the named.conf file points to them and the nameddaemonhas access to read them.

For large organizations, such as ISPs, it may be helpful to create logical subdirectories to store the files. The naming of zone files is also rather open-ended. Any name will work as long as the entries in named.conf correspond to the correct files. Typically, a zone file will be called something like sample.com.zone. The configuration file named.conf, if you recall, stores server information as well as the location of domains for which it provides DNS services. It also specifies the name and location of the zone file for each domain that the DNS server works with. The actual DNS zone file will look something like this.

SOA is short for Start of Authority, which is the preamble necessary for all zone files. The server keeps track of updates using the serial number. As long as this number increments from the last time the daemon started, it will reread the information into its database. For instance, you could start at 0 and add a digit after every modification, or you could use a date entry (as in the example) like 200101111. This is helpful because it lets you see when the last update was made and whether it was updated more than once in a single day.

The next four lines deal with refresh and timeout periods in seconds. If no manual or server-wide refresh of the BIND database occurs, it will automatically attempt to reread the information based on the refresh entry. The retry information lets the server know how often it should attempt to refresh should an authoritative server be unreachable. The next entry, expire, dictates how long a secondary server will store information about a domain without an update. The minimum TTL determines how long information retrieved about this domain will last. All of the above were created in order to allow for downtime of machines and still have DNS function to a certain degree.

The NS entry lists which server, or servers, has authoritative control over the domain. This is needed to let other name servers on the Internet know from which servers to accept authoritative responses. While data may exist in the cache of these DNS servers, the NS entry will make sure that new information comes from the correct source. There may be multiple authoritative servers listed. These DNS servers will accept the fastest reply.

The MX record is listed next. Short for Mail Exchanger (it has nothing to do with the product Microsoft Exchange), this record lets the server know what information to give when mail information is requested for sample.com. For instance, if someone attempts to send e-mail to webmaster@sample.com, delivery is made to the server of the corresponding MX entry. In this case, mail.sample.com is the primary, with priority of 10. The secondary is backup.sample.com. Notice that both of these entries have a trailing period, which is necessary when listing fully qualified domain names as MX entries. You may list multiple MX records as backups in the event that one fails. The lowest number is considered the primary. Notice that there is also a corresponding A record belowthat gives the IP address for mail.sample.com. This is a required field.

An A record is merely the way in which IP address are assigned to subdomain entries (for example: www, mail, ftp, or ns). These should always be entered in the format above and will always correspond to an IP address. Remember that words may not be entered here; for that purpose, use CNAMEs.

The CNAME record is also used in the example above. CNAME, which stands for “canonical name,” is a way of using aliases as opposed to IP addresses. Standard practice dictates these should refer back to A records already in use. In this case, the CNAMEpop is configured to point back to mail, which is an A record pointing to 212.204.219.71.

Sound confusing? In large domain files, it can be easy to lose track of what needs to point back to what. This is where good documentation can mean the difference between 10 seconds and 10 minutes when making a change.

Reverse mappings
I would like to briefly cover reverse mappings, which are slightly different from the forward mappings we’ve already gone over. Basically, a reverse map is a way of verifying an IP back to a domain name, rather than the other way around. This is commonly referred to as a “reverse lookup,” and you may have noticed Web sites doing it for security purposes.

The reverse lookup files are usually named something similar to x.x.x.in-addr.arpa, where x.x.x equals the first three octets of the IP address in reverse order. In the sample.com example, the IP address of the Web site is 212.204.219.71. Thus, the filename for the reverse lookup would be 219.204.212.in-addr.arpa. The contents of the file would then look like this.

Notice the beginning is just like that of the standard DNS zone record. Underneath, however, we are introduced to the PTR record, which is a pointer back to a domain name. The line begins with the last octet of the IP address for which the reverse lookup will be performed. Be sure to end the domain name with a period; otherwise, you will encounter errors upon restarting named.

Summary
DNS records are many and varied, much like the Internet of which they are an integral part. We’ve covered the SOA, MX, NS, A, CNAME, and PTR types. There are many more options and configurations than those listed here, as you will find in administering a DNS server of any size. However, this will get you started in administering your first DNS server using BIND on Linux



موضوعات مشابه: