|
I've learned that there is nothing more peaceful than a sleeping child - Anonymous, Age 30
To an Internet Administrator, there is nothing more peaceful than a stable and optimized DNS server. The moment there is a wrong configuration, the server wakes up and starts crying, sites and email goes down. An important part of keeping DNS that way is properly setting up the SOA records.
What are DNS Records. DNS records or Zone files are used for
mapping URLs to an IPs. Located on servers called the DNS servers,
these records are typically the connection of your website with the
outside world. Requests for your website are forwarded to your DNS
servers and then get pointed to the WebServers that serve the website
or to Email servers that handle the incoming email.
This is how a typical Zone file (containing many common DNS records) looks like.
;
; Zone file for mydomain.com
mydomain.com. 14400 IN SOA ns.mynameserver.com. root.ns.mynameserver.com.(
2004123001
86000
7200
3600000
600 )
mydomain.com. 14400 IN NS ns.mynameserver.com.
mydomain.com. 14400 IN NS ns2.mynameserver.com.
mydomain.com. 14400 IN NS ns3.mynameserver.com.
mydomain.com. 14400 IN A 216.34.94.184
localhost.mydomain.com. 14400 IN A 127.0.0.1
mydomain.com. 14400 IN MX 0 mydomain.com.
mail 14400 IN CNAME mydomain.com.
www 14400 IN CNAME mydomain.com.
ftp 14400 IN CNAME mydomain.com.
In the rest of this article, we'll analyze the various parts of this
DNS record, starting from the top.
An SOA(State of Authority) Record is the most essential part of a
Zone file. The SOA record is a way for the Domain Administrator to
give out simple information about the domain like, how often it is
updated, when it was last updated, when to check back for more info,
what is the admins email address and so on. A Zone file can contain
only one SOA Record.
A properly optimized and updated SOA record can reduce bandwidth between
nameservers, increase the speed of website access and ensure the site
is alive even when the primary DNS server is down.
Here is the SOA record. Notice the starting bracket ``(``. This
has to be on the same line, otherwise the record gets broken.
; name TTL class rr Nameserver email-address
mydomain.com. 14400 IN SOA
ns.mynameserver.com. root.ns.mynameserver.com.
(
2004123001 ; Serial number
86000 ; Refresh rate in seconds
7200 ; Update Retry in seconds
3600000 ; Expiry in seconds
600 ; minimum in seconds )
mydomain.com. 14400 IN SOA ns.mynameserver.com. root.ns.mynameserver.com.(
can also be written as
;@ 14400 IN SOA ns.mynameserver.com. root.ns.mynameserver.com. (
or
14400 IN SOA ns.mynameserver.com. root.ns.mynameserver.com. (
- name - mydomain.com is the main name in this zone.
- TTL - 14400 - TTL defines the duration in seconds that the record
may be cached by client side programs. If it is set as 0, it indicates
that the record should not be cached. The range is defined to be between
0 to 2147483647 (close to 68 years !)
- Class - IN - The class shows the type of record. IN equates to Internet.
Other options are all historic. So as long as your DNS is on the Internet
or Intranet, you must use IN.
- Nameserver - ns.nameserver.com. - The nameserver is the server which
holds the zone files. It can be either an external server in which
case, the entire domain name must be specified followed by a dot.
In case it is defined in this zone file, then it can be written as
``ns'' .
- Email address - root.ns.nameserver.com. - This is the email of the
domain name administrator. Now, this is really confusing, because
people expect an @ to be in an email address. However in this case,
email is sent to root@ns.nameserver.com, but written as root.ns.nameserver.com
. And yes, remember to put the dot behind the domain name.
- Serial number - 2004123001 - This is a sort of a revision numbering
system to show the changes made to the DNS Zone. This number has to
increment , whenever any change is made to the Zone file. The standard
convention is to use the date of update YYYYMMDDnn, where nn is a
revision number in case more than one updates are done in a day. So
if the first update done today would be 2005301200 and second update
would be 2005301201.
- Refresh - 86000 - This is time(in seconds) when the slave DNS server
will refresh from the master. This value represents how often a secondary
will poll the primary server to see if the serial number for the zone
has increased (so it knows to request a new copy of the data for the
zone). It can be written as ``23h88M'' indicating 23 hours and
88 minutes. If you have a regular Internet server, you can keep it
between 6 to 24 hours.
- Retry - 7200 - Now assume that a slave tried to contact the master
server and failed to contact it because it was down. The Retry value
(time in seconds) will tell it when to get back. This value is not
very important and can be a fraction of the refresh value.
- Expiry - 3600000 - This is the time (in seconds) that a slave server
will keep a cached zone file as valid, if it can't contact the primary
server. If this value were set to say 2 weeks ( in seconds), what
it means is that a slave would still be able to give out domain information
from its cached zone file for 2 weeks, without anyone knowing the
difference. The recommended value is between 2 to 4 weeks.
- Minimum - 600 - This is the default time(in seconds) that the slave
servers should cache the Zone file. This is the most important time
field in the SOA Record. If your DNS information keeps changing, keep
it down to a day or less. Otherwise if your DNS record doesn't change
regularly, step it up between 1 to 5 days. The benefit of keeping
this value high, is that your website speeds increase drastically
as a result of reduced lookups. Caching servers around the globe would
cache your records and this improves site performance.
There is constant bandwidth usage between primary and secondary(backup
DNS) servers. This depends a lot on the Refresh value. If the refresh
value is say 3 hours, your secondary server is polling your primary
server every 3 hours and updating the cache. Lets assume you have
a 1000 zone files, each with 3 hours refresh rate. You can imagine
the bandwidth that must be getting used. This is especially true if
the servers are on 2 separate physical servers.
An increase in the Refresh rate can effectively reduce bandwidth usage
between the primary and secondary server.
The time it takes to access a website on a browser includes the time
it takes to look it up on the domain name server. By increasing the
``Minimum'' value, we're telling the contacting clients to keep
their copies of the zone file for a longer time. In effect, reducing
the lookups to the nameserver. By reducing the number of times a client
has to lookup, we're increasing the site speed.
However, this also means that if you make changes to the DNS record,
it will take longer to propagate. If you require to make frequent
updates to your DNS records, make sure your Minimum value is lesser
than 1 day. That means longer lookup times, but accurate information
for the clients
If you are planning a major update on the DNS zone file(say moving
to another server or hosting service), reduce the Minimum value a
couple of days prior to the change. Then make the change and then
jack up the minimum value again. This way the caching clients all
over the world will pick up the changes quicker and yet you do not
need to sacrifice on site speed thereafter.
Always keep a secondary DNS server and keep a higher Expiry value.
This will mean that even if the Primary server goes down, the secondary
will have the cached copy(for as long as the Expiry value stands)
and it will keep serving lookups. Keeping a secondary server but a
low expiry value defeats the purpose of a Backup.
You have set the new SOA values, and you want to know whether the
update has taken place. ``Dig'' is a good tool to troubleshoot
and check for DNS information.
For example to check out the SOA records of yahoo.com from all the
nameservers, primary and secondary, all you need to do is
# dig yahoo.com +nssearch
SOA ns1.yahoo.com. hostmaster.yahoo-inc.com.
2005122907 3600 300 604800 600 from server ns2.yahoo.com in 0 ms.
SOA ns1.yahoo.com. hostmaster.yahoo-inc.com.
2005122907 3600 300 604800 600 from server ns3.yahoo.com in 0 ms.
SOA ns1.yahoo.com. hostmaster.yahoo-inc.com.
2005122907 3600 300 604800 600 from server ns1.yahoo.com in 239 ms.
SOA ns1.yahoo.com. hostmaster.yahoo-inc.com.
2005122907 3600 300 604800 600 from server ns4.yahoo.com in 280 ms.
About the author: Sangeetha Naik heads Bobcares.com. She is the co-founder of Poornam Info Vision Ltd., Software and IT services company specializing in Linux based solutions for Webhosts and ISPs. Poornam Info Vision is an ISO 9001:2000 certified company with a team of over 140 engineers.
Sangeetha is a Computer Engineer based in India and has over 7 years of experience in the Hosting industry. Her articles have been published both online as well as in print. She can be contacted via Contact us form
|
US: 1-602-288-9145
|
Sitemap
