Name servers contain zone files (database files for domains). Zone files contain resource records. Resource records describe specific network resources that are available. Resources such as mail exchangers, nameservers and web servers are configured using records.
SPECIAL RECORD TYPES
FORWARD RECORD TYPES
REVERSE
- Pointer (PTR)
To provide any useful discussion on the topic of resource records, we need an example to work with. Below is the host name and IP address information for a fictional domain called zippo.com.
Host Name IP Address Service cerebrus 198.204.18.1 Firewall mercury 198.204.18.5 Mail Exchanger apollo 198.204.18.10 Primary / Master
DNS Nameserverhermes 198.204.18.11 Secondary / Slave
DNS Nameserverwww 198.204.18.190 Web server joeblow 198.204.18.131 User's workstation The zone file for zippo.com would be stored on the Primary DNS server apollo.zippo.com. Apollo will be authoritative for the zippo.com domain, and will serve as Primary name server. In our example Apollo is running DNS software called BIND (version 8.x or later) and has the db.zippo.com file. Stored in db.zippo.com are the resource records listed below.
Note that the nameserver hermes will download a copy (perform a zone transfer) of the db.zippo.com file periodically to keep up to date.
SPECIAL RECORDS
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 files. The only difference is in what is inside the file.
Start Of Authority (SOA) Record
The Start Of Authority (SOA) record is a special 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. hermes.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 dayThe above Start Of Authority (SOA) record identifies that our nameserver 'apollo' is the primary authoritative server for this domain, and that hermes is an authoritative secondary server for the domain. The settings in the SOA record affect solely the servers that query them for information. Hermes, the secondary authoritative server int the domain will attempt to get a copy of the file every four hours and will retry once an hour until it can successfully retrieve the db.zippo.com zone file. If Hermes fails to retrieve the file at the regularly scheduled time, it will wait 1 hour before trying again. If Hermes is unable to retreive the domain after 1 day, it will no longer provide the answers contained in this zone, but will still have it on file. If, after 1 week, Hermes is unable to reach the primary authoritative server to download the zone, it will delete the zone file. Note that host names of machines are completely up to the administrator. It is not necessary to name a machine according to it's function to get resolution to work. (ie. it is not necessary to call a name server ns.domain.com, or a mail server mail.domain.com). Host names are usually completely arbitrary.
Also note that the ';' character is used to indicate comments and are ignored by the DNS software.
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 server's serial number, no transfer of the zone file from the Primary to the Secondary will take place. It is common to use a date/version format 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 machine performs an update at the scheduled time.
Determines the interval between successful transfers of the entire zone file from the Primary name server to the Secondary name servers. The number indicates the number of seconds betwen refresh attempts.
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. More than once an hour is considered poor netiquette if someone else is providing secondary for you.
When a zone transfer fails, a countdown clock begins. When the number of seconds set in the expire field elapses, the server stops answering for that zone. It is assumed that if you cannot get the information in this period of time, the data is incorrect or out of date.
This is the number of seconds an external nameserver should keep any responses from the nameserver apollo in our example. If ns.berkeley.edu queried our apollo name server, ns.berkeley.edu would delete the answer after holding it in it's cache for 1 day.
zippo.net. IN NS apollo.zippo.net. apollo.zippo.net. IN A 198.204.18.10 zippo.net. IN NS hermes.zippo.net. hermes.zippo.net IN A 198.204.18.11
The records above tie the domain name on the left to the names of specific machines responsible for name resolution on the right. The specific machines must still have an Address record to identify their IP.
All internet records contain 'IN' which tell the DNS system that this is a TCP/IP (Internet) name/IP record as opposed to a Chaosnet resolution record.
FORWARD RECORDS
zippo.net. IN MX 10 mercury.zippo.net. mercury.zippo.net. IN A 198.204.18.5
A mail exchanger is a server configured to processing SMTP messages (E-MAIL!). The users of zippo.net will have 'ussername@zippo.net' as their e-mail addresses. 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.
OK, at this point, you're probably wondering about that funky '10' crammed in the middle of the zippo.net record. This is what is called a priority or 'preference' number. The greater the number, the less preferred that server is. The number is arbitrary and set by the DNS administrator, but mail will attempt delivery at the lowest numbered mail exchanger and move towards the highest numbered entry. So the primary mail exchanger will usually receive the mail, unless it's down or can't be reached, in which case the mail server with the next best preference will get tried.
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 below for more info.
zippo.net. IN A 198.204.18.190 www.zippo.net. IN A 198.204.18.190
This allows both http://zippo.net and http://www.zippo.net to resolve to the same IP address. This can be accomplished another way using a CNAME record, but isn't necessary. See CNAME below for more information on what they are for and how they work.
joeblow.zippo.net. IN A 198.204.18.131
Every machine that should be reachable from the internet should have an Address record so that it's host name listed on the left above, can be resolved to the IP address of the machine on the right.
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.190I 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 is to use CNAMES with MX records. 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!!!
Just how long do you think you will last when the CEO's screaming at you because the mail and web servers are down, and you have to explain that it's because YOU thought you were oh-so-smart and used a CNAME?!?
There is no reason (except laziness) for using a CNAME. DNS can be set up without ever using CNAMEs.
CNAMEs are like doing drugs. Just say NO!
REVERSE RECORDSThe reverse zone has only three types of records, PTR, NS and SOA. Reverse zones allow DNS servers 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. 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 128 bit encryption software. 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.
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.