Need help?

Our experts have had an average response time of 11.7 minutes in August 2021 to fix urgent issues.

We will keep your servers stable, secure, and fast at all times for one fixed price.

Understanding SOA records

by | Dec 30, 2005

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.


Hire Bobcares Server Administrators
Get super reliable servers and delighted customers

See how we do it!


This is how a typical Zone file (containing many common DNS records) looks like.

; Zone file for 14400 IN SOA
		600 ) 14400 IN NS 14400 IN NS 14400 IN NS 14400 IN A 14400 IN A 14400 IN MX 0
mail 14400 IN CNAME
www 14400 IN CNAME
ftp 14400 IN CNAME

In the rest of this article, we’ll analyze the various parts of this DNS record, starting from the top.

SOA Records

An SOA(Start 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 14400	 IN 	SOA
		2004123001 ; Serial number
		86000 ; Refresh rate in seconds
		7200 ; Update Retry in seconds
		1209600 ; Expiry in seconds
		600 ; minimum in seconds ) 14400 IN SOA

can also be written as

@ 14400 IN SOA (


14400 IN SOA (
  • name – 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 – – 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 – – 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 [email protected], but written as . 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 – 1209600 – 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.

Reducing DNS bandwidth

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.

Increasing site speed

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.

How to improve backup

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.

How to test SOA records

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 from all the nameservers, primary and secondary, all you need to do is

# dig +nssearch
 2005122907 3600 300 604800 600 from server in 0 ms.
2005122907 3600 300 604800 600 from server in 0 ms.
 2005122907 3600 300 604800 600 from server in 239 ms.
 2005122907 3600 300 604800 600 from server in 280 ms.

Articles by Sangeetha NaikAbout the author:
Sangeetha Naik heads 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

var google_conversion_label = "Blp0CLCojHIQ0aD71QM";


  1. Dave Sailors

    My SOA record looks like this. How would I add a secondary DNS server to this SOA record, say

    $TTL 14400
    @ SOA ns dns ( 2008121200 10800 3600 2592000 600 )
    NS ns
    NS ns2

    localhost A
    ns A
    ns1 CNAME ns
    lists A
    sor-fw1 A
    mail A
    ns2 CNAME mail
    vpn A

  2. Kichu Mubarak

    Hi Dave,

    Your zone file should go this way:
    ; Zone file for 14400 IN SOA
    600 ) 14400 IN NS 14400 IN NS

    localhost 14400 IN A

    ns 14400 A
    ns2 14400 A ______________ 14400 IN MX 0

    mail 14400 IN A
    lists 14400 IN A
    sor-fw1 14400 IN A
    vpn 14400 IN A
    www 14400 IN CNAME
    ftp 14400 IN CNAME

    Please make sure :
    1. you fill the blank with the IP address of the secondary nameserver.
    2. you register the secondary nameserver at the registrar to point to the correct IP address.

  3. Acronyms

    I would suggest to use dig tool… easy to check all data you need

  4. Whitey

    SOA is Start of Authority not State of Authority.

  5. Lance Petrovski

    hi there,

    This article is truly useful in helping me understand the concept of DNS. Initially, I just have a rough idea about A, MX, NS and CNAME but after reading this article, it broadens my knowledge about the whole DNS and the benefits of setting the DNS “properly”

    I have a site hosted at HostForLife ( and initially, the Primary NS and the Secondary NS does not match each other. Well, actually the problem is not really visible as I still can see my site. However, what I notice is that sometimes, the pages will take more time to load from different area/region. I then contacted their Support and they can resolve the problem.

    Everything looks good now and I will certainly get back often to read more articles from you. Two thumbs up!

  6. Pradipta

    Awesome article for understanding the basics of DNS. Your explanation is simple, yet very clear.


    That was a helpful article about DNS zones.

    One thing
    in your example you show
    Expiry – 3600000
    but recommend 2 weeks! (others say 2~3 weeks)

    Using your example, sites like intodns complain the value is too long.

    naturally I copied your example (as much as possible) assuming it was optimum.

    Maybe you could change that expiry value?

    I think 2 weeks in seconds is
    but I may be wrong?

  8. Sankar H

    Yes, the ideal value should be around 2 weeks. This is actually the time in seconds you would expect your slave to serve requests(not bothering if it is stale data that it is serving). So setting it too high is not desirable, and also setting it too low does not make much sense as well.

    Typically you have to set it to a time(value) in which you could identify a problem with the master, step in and set the master up and running once again(in case the master goes down). Even a value of 2 days is good, if you really manage your DNS properly and can get the master back in action in 2 days.

    Thanks for pointing this out. The write-up has been edited to reflect the value of 2 weeks(1,209,600).


Submit a Comment

Your email address will not be published. Required fields are marked *

Privacy Preference Center


Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]


Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid


Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie


These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.