none
Minimum TTL Value defined in SOA record

    Question

  • Hi,

    I have a small query in implementing the TTL value of SOA record. After reviewing the article which defines the The minimum TTL Value which is defined in SOA record, i'm thinking not to change and leave it by default. I would like to know if there are any potential adv/dis-adv by changing them.

    Am i correct saying that " Minimum TTL value is applied for a zone which contains RR's. So here, when i create a new RR in zone and try to ping it immediately, at first time it contacts the RR ,gives me a response and set the TTL value to 1 hr.When i contact after 2 hrs , ideally the ttl value of this record is expired and it will contact RR again to see if there are any changes. If it's the same/different, gives me replies and  then again ttl is set to 1 hr." So ,as this is only for querying a RR in zone within a time period, i don't find any advantages in changing them to any hour. Can someone kindly explain the adv/dis-adv here.

    One more confusion i have, "when a RR Ip/hostname changes(not the new one), then do i have to manually clear the cache on dns server to get  a proper replies? " Or it will be giving me correct reply automatically?

    Thanks in advance..

     

     

     


    Regards, Mohan R Sr. Administrator - Server Support
    Sunday, November 20, 2011 10:57 AM

Answers

  • Hello Mohan,

     

    For deep technical understanding I recommend you give a look in the DNS RFC, where you will find ALL info from the protocol definition

    http://tools.ietf.org/html/rfc2308

    Some other hints:

    TTL ("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.

    In short, it depends on the usage from your DNS, if many changes, a lower TTL is OK, but for some applications (some SPF and RBLs for mail) will require TTL from 1 day or more. I usually put it in 1 day for stable zones with outside (Internet) visibility.

    If this post helps or answers your question, please mark as answer or vote as helpful


    Thank you,

    F. Schubert
    System Administrator

    MCP | Microsoft Certified Professional
    MTCS 70-642 | Microsoft Certified Technology Specialist: Windows Server 2008 Network Infrastructure, Configuration
    • Edited by CoffeineNerd Sunday, November 20, 2011 5:59 PM
    • Marked as answer by Tiger Li Wednesday, November 23, 2011 2:53 AM
    Sunday, November 20, 2011 5:58 PM
  • I have a small query in implementing the TTL value of SOA record. After reviewing the article which defines the The minimum TTL Value which is defined in SOA record, i'm thinking not to change and leave it by default. I would like to know if there are any potential adv/dis-adv by changing them.

    Let me start by putting down some sample zone data using the usual sample name and IP range

     

    $ORIGIN example.com
    
    @       IN SOA ns1.example.com. dnsadmin.example.com. (
                               2011062217 ; serial
                               7200       ; refresh (2 hours)
                               3600       ; retry (1 hour)
                               2419200    ; expire (4 weeks)
                               3600       ; minimum (1 hour)
                               )
    
    @       IN NS       ns1.example.com.
    @       IN NS       ns2.example.com.
    
    @       IN MX 10    mx1.example.com.
    @       IN MX 20    mx2.example.com.
    @       IN MX 30    mx3.example.com.
    
    @       IN TXT      "v=spf1 mx -all"
    
    ns1     IN A        192.0.2.50
    ns2     IN A        192.0.2.51
    
    mx1     IN A        192.0.2.100
    mx2     IN A        192.0.2.150
    mx3     IN A        192.0.2.200
    
    wwww    IN A        192.0.2.80
    ftp     IN A        192.0.2.81
    mail    IN A        192.0.2.55
    
    
    

     

    now, let's look at the SOA TTL values

    serial is the SOA record "serial number" the RFCs recommend using the format "yyyymmddNN" for such a record, basically it represent the "version number" of the zone, so, whenever you change the zone informations (e.g. add or modify an RR) you should update the serial number with a new value; the final "NN" in the number increases as long as you perform changes at the same date

    refresh tells to the secondary DNS servers how often they must query the primary DNS to check for any zone update (assuming the "notify" mechanism isn't used) and, if needed transfer the zone

    retry is used by the secondaries too, it tells them the interval to retry refreshing the zone in case the refresh fails

    expire represent the value (time) after which the SOA record will expire; so, a secondary server holding a copy of the zone but unable to contact the primary, will keep answering to queries for the zone up to the expiry time after that, if no zone refresh/transfer took place, the secondaries will stop answering for the zone

    minimum this value has a double meaning; it defines the default TTL for any RR which has no explictly defined TTL value and it also represent the negative-cache timing, that is, if an external DNS sends to one of the auth DNS servers a query for a non existing record, the negative answer should be cached by the external DNS for up to the value defined in "minimum"

    Now, using a low value for "minimum" means that external DNS servers will keep the returned answers in their cache for a short time so will increase the load on your DNS servers since those infos will be requested  too often; on the other hand, setting the value too high means that the externally cached data (on which you have no control) will be kept in cache for a quite long time so, changes you'll make to your zone will take a lot of time to "propagate" to other DNS servers

    My suggestion is to keep the TTL inside the 1800...7200 range (3600 is a good pick); this will both help relieving the load on your DNS and will allow any change to propagate quickly enough; for example, let's say you decide to change your "www" record so that instead of pointing to 192.0.2.80 it will point to 192.0.2.180, now, using a TTL of 3600 will allow you to be sure that after 1 hour (or even less in some cases) the change will be propagated to any external DNS since after one hour (3600 seconds) the cached record will expire and any external DNS will need to re-request it to one of your authoritative DNS servers (ns1 and ns2 in the above example)

    For further informations, please see here and here



    • Edited by ObiWan Tuesday, November 22, 2011 3:27 PM
    • Marked as answer by Tiger Li Wednesday, November 23, 2011 2:53 AM
    Tuesday, November 22, 2011 8:03 AM

All replies

  • Hello Mohan,

     

    For deep technical understanding I recommend you give a look in the DNS RFC, where you will find ALL info from the protocol definition

    http://tools.ietf.org/html/rfc2308

    Some other hints:

    TTL ("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.

    In short, it depends on the usage from your DNS, if many changes, a lower TTL is OK, but for some applications (some SPF and RBLs for mail) will require TTL from 1 day or more. I usually put it in 1 day for stable zones with outside (Internet) visibility.

    If this post helps or answers your question, please mark as answer or vote as helpful


    Thank you,

    F. Schubert
    System Administrator

    MCP | Microsoft Certified Professional
    MTCS 70-642 | Microsoft Certified Technology Specialist: Windows Server 2008 Network Infrastructure, Configuration
    • Edited by CoffeineNerd Sunday, November 20, 2011 5:59 PM
    • Marked as answer by Tiger Li Wednesday, November 23, 2011 2:53 AM
    Sunday, November 20, 2011 5:58 PM
  • I have a small query in implementing the TTL value of SOA record. After reviewing the article which defines the The minimum TTL Value which is defined in SOA record, i'm thinking not to change and leave it by default. I would like to know if there are any potential adv/dis-adv by changing them.

    Let me start by putting down some sample zone data using the usual sample name and IP range

     

    $ORIGIN example.com
    
    @       IN SOA ns1.example.com. dnsadmin.example.com. (
                               2011062217 ; serial
                               7200       ; refresh (2 hours)
                               3600       ; retry (1 hour)
                               2419200    ; expire (4 weeks)
                               3600       ; minimum (1 hour)
                               )
    
    @       IN NS       ns1.example.com.
    @       IN NS       ns2.example.com.
    
    @       IN MX 10    mx1.example.com.
    @       IN MX 20    mx2.example.com.
    @       IN MX 30    mx3.example.com.
    
    @       IN TXT      "v=spf1 mx -all"
    
    ns1     IN A        192.0.2.50
    ns2     IN A        192.0.2.51
    
    mx1     IN A        192.0.2.100
    mx2     IN A        192.0.2.150
    mx3     IN A        192.0.2.200
    
    wwww    IN A        192.0.2.80
    ftp     IN A        192.0.2.81
    mail    IN A        192.0.2.55
    
    
    

     

    now, let's look at the SOA TTL values

    serial is the SOA record "serial number" the RFCs recommend using the format "yyyymmddNN" for such a record, basically it represent the "version number" of the zone, so, whenever you change the zone informations (e.g. add or modify an RR) you should update the serial number with a new value; the final "NN" in the number increases as long as you perform changes at the same date

    refresh tells to the secondary DNS servers how often they must query the primary DNS to check for any zone update (assuming the "notify" mechanism isn't used) and, if needed transfer the zone

    retry is used by the secondaries too, it tells them the interval to retry refreshing the zone in case the refresh fails

    expire represent the value (time) after which the SOA record will expire; so, a secondary server holding a copy of the zone but unable to contact the primary, will keep answering to queries for the zone up to the expiry time after that, if no zone refresh/transfer took place, the secondaries will stop answering for the zone

    minimum this value has a double meaning; it defines the default TTL for any RR which has no explictly defined TTL value and it also represent the negative-cache timing, that is, if an external DNS sends to one of the auth DNS servers a query for a non existing record, the negative answer should be cached by the external DNS for up to the value defined in "minimum"

    Now, using a low value for "minimum" means that external DNS servers will keep the returned answers in their cache for a short time so will increase the load on your DNS servers since those infos will be requested  too often; on the other hand, setting the value too high means that the externally cached data (on which you have no control) will be kept in cache for a quite long time so, changes you'll make to your zone will take a lot of time to "propagate" to other DNS servers

    My suggestion is to keep the TTL inside the 1800...7200 range (3600 is a good pick); this will both help relieving the load on your DNS and will allow any change to propagate quickly enough; for example, let's say you decide to change your "www" record so that instead of pointing to 192.0.2.80 it will point to 192.0.2.180, now, using a TTL of 3600 will allow you to be sure that after 1 hour (or even less in some cases) the change will be propagated to any external DNS since after one hour (3600 seconds) the cached record will expire and any external DNS will need to re-request it to one of your authoritative DNS servers (ns1 and ns2 in the above example)

    For further informations, please see here and here



    • Edited by ObiWan Tuesday, November 22, 2011 3:27 PM
    • Marked as answer by Tiger Li Wednesday, November 23, 2011 2:53 AM
    Tuesday, November 22, 2011 8:03 AM
  • Hi,

    I'm happy to leave this as answered, and great thanks to obiwan and Schubert for taking time to explain this. I learnt one new thing "negative caching"

    I would also like to know, when changing a RR IP or name  in DNS server, do i really have to clear the cache if i have to get proper replies within one hour.. ?

     


    Regards, Mohan R Sr. Administrator - Server Support
    Sunday, November 27, 2011 8:13 AM
  • I'm happy to leave this as answered, and great thanks to obiwan and Schubert for taking time to explain this. I learnt one new thing "negative caching"

    I would also like to know, when changing a RR IP or name  in DNS server, do i really have to clear the cache if i have to get proper replies within one hour.. ?


    As for the "cache", you have to keep in mind that any DNS querying your public zone (that is requesting an RR to your authoritative, published DNS servers) will keep the replies in its cache up to the specified TTL, this means that you have no way to "clear the cache" of such external DNS servers which are totally outside your control, all you can do is keeping the TTL value reasonably low (but, again, don't make it too short or you'll have other kind of issues) so that, whenever you'll change an RR in your DNS, the changes will propagate quickly enough (that is, the remotely cached RRs TTL will expire so the remote DNS servers will have to query your DNS again and will get back the new RR values)

    Hope it's clear

     

    Monday, November 28, 2011 7:45 AM
  • Hi Obiwan,

     

    Thanks again. I totally understood the TTL Value and its timings... As you said, when some external DNS servers trying to query this RR,they will have to query again ie very often in case if I change RR's. This could lead to more incoming traffic to my DNS server.. This sounds perfect.. 

    Say i set my TTL as 1 hour.. how abt my internal clients reaching this RR when i change its IP? Even for my internal clients do they have to wait 1 hour to get the updated IP when they ping it? 

    Thanks for your time again..

     


    Regards, Mohan R Sr. Administrator - Server Support
    Monday, November 28, 2011 1:44 PM
  • Hi,

    Even when internal clients try to reach within this TTL value they will not get the updated value.So,we need to clear the cache in DNS server and in client as well to get the updated change in RR.

    Thanks evryone for your time in this.


    Regards, Mohan R Sr. Administrator - Server Support
    Monday, December 05, 2011 12:21 PM
  • Even when internal clients try to reach within this TTL value they will not get the updated value.So,we need to clear the cache in DNS server and in client as well to get the updated change in RR.

    Sounds like you totally missed the point; whenever you request a given RR, the authoritative DNS server will return YOU that info along with the related TTL; from that point on, whoever is caching the RR, be it a client or another DNS server, will keep such an info into its cache UP TO the TTL time, so it's NORMAL that, if you re-query a given RR before its TTL expires you'll get back the SAME answer since that answer will come straight from cache, to get a fresh answer you'll need to wait until the TTL expires so, another query for the given RR will cause the resolution process to kick in (since the cached data are now expired) and you'll get back fresh data... again, REREAD the previous messages since, judging from what you wrote above, you didn't understand how it works

     

    Monday, December 05, 2011 2:24 PM
  • Hi,

    Sound like both are trying to say the samething. :)


    Regards, Mohan R Sr. Administrator - Server Support
    Monday, December 05, 2011 3:38 PM
  • Sound like both are trying to say the samething. :)

    No, sorry, this doesn't seem the case or either, I didn't understand what you tried to write above, see, you wrote the following

    Even when internal clients try to reach within this TTL value they will not get the updated value.So,we need to clear the cache in DNS server and in client as well to get the updated change in RR.

    now, maybe I'm wrong, but as I read it, it means that if a client issues a query BEFORE the TTL expires (within the TTL if you prefer), the client will get back the "old" RR value, now this is expected and totally correct because the client (or whatever resolver) will cache the RR up to the TTL value; now, you write about "clearing the cache"... well, yes, but you should clear the cache of ALL the clients and all the DNS resolvers which have your RR stored in their cache and sincerely, running around the world and trying to convince users and admins to flush their DNS resolvers cache just because you need it, doesn't seem a good approach to me.

    Better reducing the TTL to a decent value (say 1800, that is 30 minutes) and allowing that interval whenever you update whatever RR, at that point, after 30 minutes you'll be sure that every client/server will get the new value

     

    Monday, December 05, 2011 3:53 PM
  • Hi,

    Obiwan, Thanks again. What you mentioned in the second paragraph is what i meant. :)

    As you said,clearing the cache on dns server and on all clients is definitely not a agood approach ; best way is to reduce the TTL value like 30 mins is the rite approach as you said..

    I'm gonna clear the cache only when we run around serious issues and we need it immediately...

    Thanks again.

     


    Regards, Mohan R Sr. Administrator - Server Support
    Wednesday, December 07, 2011 8:55 AM