Oversimplified DNS

BACKGROUND: The SOA record has core information about your zone. It defines which server is your primary nameserver, your contact information (E-mail), how your secondary nameservers get updated, and the default (minimum) Time-To-Live values for your records.

To get your SOA data, you can use NSLOOKUP or DIG (or any other program, or a web site, that can query DNS records from a nameserver you choose). You need to use your domain as the domain name to query, query for the SOA record, once for each nameserver on the list you wrote down.

Using NSLOOKUP, enter "server nameserver.example.com" (do this once for each nameserver on your list, replacing "nameserver.example.com" with one nameserver at a time). Then, type "set type=SOA". Finally, type your domain name ("example.com"). You will see the SOA record for your domain.

Using DIG, enter your domain name as the domain name to query, and enter each server from the list you wrote down (one at a time), and look at the SOA or "Zone of Authority" section.

Problem? Make sure that the SOA record returned by each name server is identical. If the serial numbers are different, you will have to wait up to the number of seconds listed in the "refresh" section of the nameserver with the lower serial number for it to get updated (or more time if the secondary nameserver can't reach the primary). If the primary nameserver has a lower serial number than a secondary, you have a serious problem that you will need to fix. If the serial numbers are the same, but other data is different, you have a serious problem -- your primary was updated without updating the serial number (update the serial number and the problem will get fixed).

Problem? The SOA record MUST be the FIRST record in your zone file, and MUST also be the LAST record in your zone file. It must appear only those two times, and both of the entries must be identical. This can be verified correctly only on the nameserver itself; the procedure varies depending on the software you use.

• MNAME ("Primary NS") - This entry is the domain name of the name server that was the original source of the data (this entry MUST be your primary nameserver). This is your primary nameserver, and MUST be the one and only server that you ever update. You must not update the secondary server(s) -- they will update automatically, based on this the SOA record. Problem? This should be a fully qualified domain name .

• RNAME ("Responsible Person") - This is a DOMAIN NAME that indicates the E-mail address of the person responsible for this zone. It MUST be in the format username.domain.tld; IE "jimmy.example.com" if the E-mail address is "jimmy@example.com". Problem? If this record has an "@" sign in it, it is wrong! (some programs, such as Sam Spade, may put the "@" sign in there when displaying it -- check the actual SOA record to be sure). Problem? If this record doesn't have a domain name in it (ie, just "hostmaster"), it is wrong!. It is recommended [RFC1912 2.2] to use the format "hostmaster.example.com", of course making sure that "hostmaster@example.com" is a valid E-mail address! If the E-mail address has a "." in it, there must be a "\" before it (for example, "scott\.perry.example.com" for "scott.perry@example.com"). Problem? Make sure that there is no "@" sign in this entry, otherwise there is an error.

• SERIAL - This is a serial number (32-bit unsigned integer) that must be incremented on the primary name server whenever a change is made. The recommended [RFC1912 2.2] value for this is a 10-digit number in the form YYYYMMDDnn (year, month, date, revision). For example, if you change the primary on June 4, 2001, you would enter 2001060401. If you change it again that day, you would enter 2001060402. Using this format (rather than 1, 2, 3, 4, ...) is very useful, as you can determine the last day the file was changed (which comes in handy when looking at cached entries in other DNS servers). It can also be used to double-check that you remembered to update the serial number when you last made a change. Problem? Make sure that there is NOT a decimal point in the serial number -- if so, it won't work as you think [RFC1912 2.2].

• REFRESH - The number of seconds (32-bit integer) between the time that a secondary name server gets a copy of the zone (or sees that it hasn't changed), and the next time it checks to see if it needs a new copy. This should be set to the amount of time you think it is O.K. for your secondary to have out-of-date information when you update your primary server. An hour or two might be a good value. If set too short (say, 1 minute), it will cause more traffic. If set too long (say, 1 day), the secondary servers might give out old information for up to a day. Problem? Make sure this value isn't very high, say a week or more, or else it will take a long time for your secondary nameservers to update when you make changes.

• RETRY - The number of seconds (32-bit integer) that the primary name server(s) should wait, if an attempt to refresh failed, before making another attempt to refresh. If your primary nameserver is reliable, this value should never be needed.

• EXPIRE - The number of seconds (32-bit integer) that lets the secondary name server(s) know how long they can hold the information before it is no longer considered authoritative. A good value might be 2 to 4 weeks [RFC1912 2.2]. It should be long enough to keep the data during a major outage. Problem? Make sure that the value is greater than the minimum and retry intervals, or else the data will immediately expire if the secondary server can't reach the primary server.

• MINIMUM ("Minimum TTL") - The number of seconds that the records in the zone are valid for (time-to-live, or TTL), unless the records have a higher TTL value. This is VERY important! I would recommend setting this to one day, or less if you change your DNS often (note that RFC1912 2.2 suggests at least 3 days if your DNS is fairly stable). If you rarely change your DNS, and have a lot of traffic, you could increase this somewhat to minimize traffic. Problem? Make sure that this value isn't too long (say a week or more); otherwise, when you have to make a change to one of your servers, it will take this long before everyone knows about it -- and you may not have that much time. If you are about to make a DNS change, you can lower the value temporarily, wait the old default TTL, make your changes, and then raise it back again.