... or, even a rocket scientist can understand DNS
Step 3 - Verify SOA (Start of Authority)GOAL: Find your
SOA record and make sure that it is accurate.
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.
Step 3a: Get your SOA data
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.
Step 3b: Check your SOA data
- 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 "firstname.lastname@example.org". 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
"email@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 "firstname.lastname@example.org"). 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
- 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