A zone file is a computer file in ASCII text format that contains all resource records for a given domain.
Below is a copy of a standard zone file containing the information for the Internet domain InetDaemon.com:
inetdaemon.com. IN SOA ns1.hostsave.com. contact.hostsave.com. (
2001121123 ; serial
102000 ; refres
108000 ; retry
102000 ; expiry
3600 ); minimum
inetdaemon.com. IN NS 1.hostsave.com.
inetdaemon.com. IN NS 2.hostsave.com.
inetdaemon.com. IN NS 3.hostsave.com.
inetdaemon.com. IN A 207.150.192.12
inetdaemon.com. IN MX 20 mail.hostsave.com.
inetdaemon.com. IN MX 1 mail-incoming.hostsave.com.
inetdaemon.com. IN MX 10 mail-incoming2.hostsave.com.
Resource Records
Nameservers contain zone files (database files for domains). Zone files contain resource records. Resource records describe specific network resources that are available. The ability to use names for resources such as e-mail exchangers, nameservers and web servers are configured within zone files using resource records.
SPECIAL Resource Record Types
Start of Authority (SOA) and Nameserver (NS) records are special because they must be included in every database zone file. Most DNS systems do not make distinctions between forward and reverse zones, the resolution process works the same.
The only difference between forward and reverse resolution is the files the DNS nameserver uses to find the answers to queries and the records inside those zone files.
* Start Of Authority (SOA)
* Nameserver (NS)
FORWARD Lookup Resource RECORDs
The following resource record types are used in zone files configured to provide forward resolution (name to IP address translation) of domains and host names.
* Address (A)
* Nameserver (NS)
* Mail Exchanger (MX)
* Canonical Name (CNAME)
* Reverse Lookup Resource RECORDs
1.Start Of Authority (SOA)
The Start Of Authority (SOA) record is a special resource record included in every database file (also called zone files). The SOA record supplies certain basic information about the zone. An SOA record is included in both forward and reverse zone files.
zippo.net. IN SOA apollo.zippo.net. james.zippo.net.
1999102003 ; Serial Number
14400 ; Refresh every 4 hours
3600 ; Retry in 1 hour
604800 ; Expire in 1 week
86400 ; Minimum TTL of 1 day
The above Start Of Authority (SOA) resource record identifies that our nameserver 'apollo' is the primary authoritative server for this domain, and that james@zippo.net is the e-mail address of the DNS Administrator for the domain. The settings in the SOA resource record affect solely nameservers that query the authoritative nameserver for domain or hostname information.
The SOA resource record should be followed by one nameserver resource record for each nameserver that is authoritative for that domain, which in turn should be followed by Address resource records defining the IP addresses of the nameservers.
A properly configured zone file with matching Start of Authority, nameserver and Address resource records will look something like this:
zippo.net. IN SOA apollo.zippo.net. james.zippo.net.
1999102003 ; Serial Number
14400 ; Refresh every 4 hours
3600 ; Retry in 1 hour
604800 ; Expire in 1 week
86400 ; Minimum TTL of 1 day
;
; Primary Nameserver
zippo.net. IN NS apollo.zippo.net.
;
; Secondary Nameserver
zippo.net. IN NS hermes.zippo.net.
;
; Address Records for the Nameservers
apollo.zippo.net. IN A 199.144.219.10
hermes.zippo.net. IN A 199.144.218.10
According to the SOA resource record above, the secondary authoritative nameserver (lets call it "Hermes") will attempt to get a copy of the zone file from the primary authoritative nameserver every four hours and the secondary nameserver will try again once an hour until it can successfully retrieve the db.zippo.com zone file. If Hermes is unable to retreive the domain after 1 day, it will no longer provide the answers contained in this zone, but Hermes will still have the information in it's cache. If, after 1 week, Hermes is still unable to reach the primary authoritative nameserver to download the zone, it will delete the zone file information from cache.
Note that host names are completely up to the administrator. It is not necessary to name a host according to it's function to get name resolution to work, nor must the host name configured on the host itself match the name in DNS. (ie. it is not necessary to call a nameserver ns.domain.com, or a mail server mail.domain.com). Host names are usually completely arbitrary, but for sanity's sake, administrators usually make sure that the names configured on hosts and the names in DNS match.
Also note that the ';' character is used within a zone file to indicate comments and are ignored by the DNS software.
Serial Number
The serial number is used to indicate which copy of the zone file is the most current. If the Primary nameserver's serial number is less than or equal to the secondary nameserver's serial number, no transfer of the zone file from the primary authoritative nameserver to the secondary authoritative nameserver will take place. It is common to use a date/version format for the serial number such as YYYYMMDDVV for Year Month Day and Version. In the example above, the file was modified the 20th of October, 1999, and this is the third version of the file produced that day. When editing zone files, you must increment the serial number by one make sure the secondary authoritative nameserver performs an update.Refresh
The refresh value determines the interval between successful zone transfers of the entire zone file from the primary nameserver to the Secondary nameservers. The number indicates the number of seconds betwen refresh attempts.Retry
If a zone transfer to refresh the zone file data fails, it will wait the designated number of seconds listed in the retry field to perform additional attempts to load the zone file. More than one attempt an hour is considered poor netiquette if someone else is providing secondary DNS for your domain as this creates extra queries to the nameserver and extra load.Expire
When a zone transfer fails, a countdown clock begins. When the number of seconds set in the expire field elapses, the nameserver stops answering for that zone file. It is assumed that if the secondary nameserver cannot get the information from primary authoritative nameserver in this period of time, the data is incorrect or out of date.Minimum TTL
The Minimum Time to Live is the number of seconds an external caching nameserver should keep any responses from the nameserver (apollo in our example). If ns.berkeley.edu queried our apollo.zippo.net nameserver, ns.berkeley.edu would delete the answer after holding it in it's cache for 1 day.2.Adress Records (A)
When you use the Internet, you really aren't using the names of websites or computers, you're using IP addresses, but since most computers use DNS, you can use a website name and DNS takes care of finding the IP address for you. Address Resource Records are placed in a zone file stored on an authoritative nameserver so that when the nameserver is queried with a hostname, it can answer with the correct IP address.
Address resource records provide the base hostname to IP Address resolution service provided by a DNS nameserver. An Internet Address record is configured the same way for all hosts; however, additional records may be necessary if the host being resolved provides additional services such as DNS or E-mail.
Web Servers
zippo.net. IN A 198.204.18.190
www.zippo.net. IN A 198.204.18.190
The example above allows both http://zippo.net and http://www.zippo.net to resolve to the same IP address. Most people, including most web hosting providers, forget to set this up. This makes accessing a web page easier on your customers. This can be accomplished another way using a CNAME record, but isn't necessary.
User's Workstation or Standalone Server
zorba.zippo.net. IN A 198.204.18.131
Every computer that should be reachable from the Internet must have an Address record. Networks that are not directly part of the Internet also need DNS resolution if you want to use the computer's name instead of it's IP address to connect to it.
The Address resource record places the fully qualified domain name of the host on the left and the IP address on the right.
DNS Name Servers
zippo.net. IN NS ns1.zippo.net.
ns1.zippo.net. IN A 198.204.18.131
DNS nameservers require an additional NS record. Note that if you have additional nameservers that aren't part of your domain, you do not use an A record for them in your zone file for your domain.
3.Mail Exchanger (MX)
Basic Mail Exchanger Setup
Mail exchanger records consist of a domain on the left hand side, a preference number and a fully qualiied host name on the right hand side. They look something like this:
zippo.net. IN MX 10 mercury.zippo.net.
mercury.zippo.net. IN A 198.204.18.5
MX DOMAIN
The domain should be the domain the mail exchanger serves and should be fully qualified if it appears. In the example above, the domain zippo.com. (note the trailing dot) is the domain. Note the trailing dot after the domain. This is important as the server will add the local domain the zone file was written for if the dot does not appear at the end.
MX PREFERENCE Value
The MX record preference values indicate which mail server to use and in which order to try them when they fail or don't respond. A larger preference number is less preferred. Thus, a mail exchanger with a preference of zero (0) is always preferred over all other mail exchangers. Setting preference values to equal numbers makes mail servers equally preferred.
A mail exchanger is a server configured to processing SMTP messages (E-MAIL!). The users of zippo.net would have 'username@zippo.net' as their e-mail address. The mail still has to be delivered to a specific machine, so you must tie the domain name (zippo.com) to a mail machine. In our example we used the name 'mercury' for the mail server, but we could have used ANY legal DNS host name. After we tie the domain name to the name of a specific machine (mail.zippo.com) we still have to get the IP address for 'mail'. The IP address information is provided by the IP address.
MAIL DELIVERY
Mail will be delivered to the machine with the lowest preference value that is available and responding. If that machine's fully qualified domain name is not the same as the domain that lists it as a mail server, it will look up the domain and try to deliver the mail to the next 'closest' mail server, a server with a smaller preference number (smaller preference numbers indicate the server is more preferred).
Configuring a Backup Mail Exchanger
For example, if we configure the zone like so:
zippo.net. IN MX 10 mercury.zippo.net.
zippo.net. IN MX 20 venus.zippo.net.
mercury.zippo.net. IN A 198.204.18.5
venus.zippo.net. IN A 198.204.18.6
Mail will attempt delivery to mercury first, but if mercury can't be reached, then it tries venus.
Load Balancing on Mail Exchangers
Since DNS resolution works in a round robin fashion, you can uses maill servers with identical preferences to create a load balancing situation between mail servers. Take the following example:
zippo.net. IN MX 10 mercury.zippo.net.
zippo.net. IN MX 10 venus.zippo.net.
mercury.zippo.net. IN A 198.204.18.5
venus.zippo.net. IN A 198.204.18.6
Mail for the zippo.net domain will get delivered to mercury, then venus and then mercury again.
Using CNAMES with MX records can cause problems, including making your zone fail to load. Check out the section on CNAMEs for more info.
Using Your ISP as a Secondary Mail Server
If your ISP supports it, you can add an MX record for your domain that points to your ISP's mail servers. If your mail server is unavailable, mail will be queued at your provider's mail server until such time as your server returns to service. Most mail servers hold onto mail and retry delivery if they fail. Adding your ISP can increase this buffering time as the sender buffers the mail, then forwards to your ISP who buffers the mail for a time before the mail finally times out and dies. You set up your ISP as a secondary MX only after consulting with them and finding out whether they allow and support such services.
zippo.net. IN MX 10 mercury.zippo.net.
zippo.net. IN MX 10 venus.zippo.net.
zippo.net. IN MX 30 mail.isp.net.
mercury.zippo.net. IN A 198.204.18.5
venus.zippo.net. IN A 198.204.18.6
Note that in the examle above, the ISP's IP address is NOT listed in the zone file for the zippo domain. That's because the ISP will take care of the DNS resolution for their mail server because it is in their DNS domain. Also note that the MX record pointing to the ISP's mail server has the largest preference number. This makes sure that the ISP's mail server will only be used if none of the other servers are available. If the ISP's mail server had the higher preference, you may end up with a mail loop.
ANTI-SPAM: REVERSE LOOKUP OF MAIL EXCHANGERS
The most used application on the planet for sending SMTP is sendmail. This application checks both the sender's and receiver's addresses in both the mail headers and the envelope. To block spammers, many companies use reverse resolution to verify that the host that is sending the mail is indeed who it says it is. This blocks some of the SPAM, but not all of it. If you don't want to find yourself unable to send mail to an ever growing number of sites, it's a good idea to make sure your mail exchanger is properly configured in the correct reverse zone file. Often, this will require your ISP to set up the DNS for this as the zone file for a range of IP addresses resides with the owner of the IP's themselves.
4.Canonical Name (CNAME) Resource Records
Canonical Name (CNAME) records function as aliases. zippo.com could be aliased to www.zippo.com using a CNAME. CNAMEs allow you to alias one host name to another, however, the host that you are aliasing to MUST have an A record. You cannot define an alias using another alias that does not eventually point to an address. Let's take an example of setting up a web server:
zippo.net. IN CNAME www.zippo.net.
www.zippo.net. IN A 198.204.18.190
I cannot stress this next point enough:
WARNING!! USING CNAMES WITH MX RECORDS IS HAZARDOUS TO YOUR DOMAIN'S HEALTH! IF YOU ARE READING THESE PAGES FOR REFERENCE YOU SHOULDN'T BE USING CNAMES!!
The fastest way to get yourself fired from your job if you're new to DNS is to use CNAMES with MX records to point multiple mail exchanger records to one host name using CNAMEs. You CANNOT CNAME a host named in an MX record to something else. This will BREAK the mail service, AND prevent the zone from loading causing ALL DNS TO FAIL FOR ALL HOSTS INCLUDING YOUR WEB SERVER!!! Your e-mail will break, your website will break, your FTP server will break and anything else that is in that zone file will stop working because noone will be able to find the IP addresses of those devices.
If you're running true Microsoft Active Directory (no WINS), users won't even be able to log in unless they are on Windows XP or 2000 clients and the default login policy hasn't been altered to prevent login when the domain controller can't be reached.
As we said before: CNAME records are hazardous for inexperienced DNS administrators.
5.Reverse Lookup Resource RECORDs
The reverse zone has only three types of records, PTR, NS and SOA. Reverse zones allow DNS nameservers to turn IP addresses into fully qualified domain names (FQDN). Why is reverse resolution important and why do we need to set it up?
With the growth of SPAMHAUSES (places that send out unsolicited bulk commercial e-mail) it is easier to translate the IP address back into a domain name and block the domain name than to block the individual IP addresses of the spammer's e-mail servers. Some mail servers automatically block mail received from hosts they cannot reverse resolve, assuming it is an attack or junk mail.
Another use is for the authorization to download software with encryption capabilities. If the IP address of the host contacting the dowload server can be reverse resolved to a host in a domain that is registered inside the continental United States, then the download can be permitted.
When performing reverse lookup, a specific resource record type is used:
* Pointer (PTR)
Pointer (PTR) Resource Records
Pointer records (PTR) look like this:
190.18.204.198 IN PTR www.zippo.net.
1.18.204.198 IN PTR cerebrus.zippo.net.
Note that we are trying to resolve 198.204.18.190 back to www.zippo.net. PTR records list the IP addresses in reverse order, from most specific to least specific, just as names are done. When you think about it, it makes sense. The most specific part of a fully qualified host name is on the left as is the most specific part of the IP address if you turn it around. In the fully qualified host name www.zippo.net, the host name www is the most specific part, and it's on the left. In the IP address 198.204.18.190, 190 is the most specific part but it's on the RIGHT, so we have to reverse the order of the octets to put it on the left. This way the software which does forward resolution can do reverse resolution the same way. Have a look at reverse resolution if you haven't done so already.
Kishore
No comments:
Post a Comment