none
TTL of DNS records not updated when SOA Minimum TTL is changed

    Question

  • Hi,

    I am facing the following problem with my Windows DNS servers: when I change the Default TTL value of a zone (ie the MINIMUM field of the SOA record), records in the zone not having an explicit TTL defined are still being published with the previous Default TTL value of the zone. I need to manually reload the zone or restart the server for the change to take effect.

    I use nslookup in debug mode (set debug) to query the DNS server and see published TTL values. When I do the change, the SOA record is correctly updated (I see it with the new value for the Default TTL field and its own TTL is also correct) but when I query other records, the returned TTL is not up to date.

    My zones are RFC compliant Internet zones, stored as text files on the server (no Active Directory zones here, Dynamic Updates are disabled).

    I can reproduce this behaviour on two unrelated servers, one running Windows 2003 and the other running Windows 2008 R2 (I have not tested other platforms).

    Can someone try this and confirm this does not come from a special configuration I would have made?
    Or could this be a bug?...

    Regards,
    Nicolas

    Wednesday, June 09, 2010 8:17 PM

Answers

  • >>the Default TTL value of a zone (ie the MINIMUM field of the SOA record), records in the zone not having an explicit TTL defined are
    >>still being published with the previous Default TTL value of the zone. I need to manually reload the zone or restart the server for the
    >>change to take effect.

    This is by design.  The Default TTL, is just that a default for newly created records.  Once the records are created their TTL is independent of the Default TTL on the SOA.  Microsoft DNS implemtation copies the Default TTL setting to all newly created records their by giving them all independent TTL settings.

    Per RFC 2308 (exact text below), but my short interpretation is this: Microsoft was free to develop their own mechanism for assigning TTLs to records, my original statements holds...The Default TTL, is just that a default for newly created records....it also appears all records in MS DNS have their own TTL setting.

    SOA Minimum Field: The SOA minimum field has been overloaded in the past to have three different meanings, the minimum TTL value of all RRs in a zone, the default TTL of RRs which did not contain a TTL value and the TTL of negative responses. Despite being the original defined meaning, the first of these, the minimum TTL value of all RRs in a zone, has never in practice been used and is hereby deprecated. The second, the default TTL of RRs which contain no explicit TTL in the master zone file, is relevant only at the primary server. After a zone transfer all RRs have explicit TTLs and it is impossible to determine whether the TTL for a record was explicitly set or derived from the default after a zone transfer. Where a server does not require RRs to include the TTL value explicitly, it should provide a mechanism, not being the value of the MINIMUM field of the SOA record, from which the missing TTL values are obtained. How this is done is implementation dependent.

    Read more: http://www.faqs.org/rfcs/rfc2308.html#ixzz0qVpTEitk
    • Marked as answer by ngiraudex Friday, June 11, 2010 5:56 AM
    Friday, June 11, 2010 3:48 AM
  • Hi Gunner999,

    I knew about the different meanings of the MINIMUM field but I conducted more tests after your reply and I think I now have the full explanation.

    All you say corresponds exactly to what happens if I don't reload the zone: the Default TTL is applied to new records I create and other records stay at the previous value because each record seems to have its own TTL.

    But if I look at the physical zone files, things are different: my records do not have an explicit TTL defined in their lines.

    That's why, when I reload the zone, the explicit TTL values have no other choice than being recreated in memory from the SOA MINIMUM filed, which is the only source of information at that time, letting me think my changes are "applied".

    So the the confusion comes from the fact that Microsoft DNS servers behaves differently between memory and zone files. Either zone files should contain explicit TTL for all lines or memory should not be systematicaly filled with explicit values.

    I don't know if we should consider this a bug but it's clearly not instinctive.
    I guess it comes from the fact that Microsoft DNS servers were more designed to be Active Directory DNS servers (no zone files) than public DNS servers.

    Thanks a lot for your help!

    Regards,
    Nicolas

     

    • Marked as answer by ngiraudex Friday, June 11, 2010 5:56 AM
    Friday, June 11, 2010 5:55 AM

All replies

  • Hello, ngiraudex,

    I wouldn't call it a bug, rather when making a change such as zone property change, you need to restart the DNS service for it to take effect.

    The following was quoted from: http://technet.microsoft.com/en-us/library/cc723556.aspx.

    ====

    This is where the zone database files we specified when we created the zones come in. The zone database files are the zones' permanent storage location, holding all the zones' resource records. If you use DNS Manager to make a change to a zone, the copy of the zone in the name server's memory is changed, and a flag is set to update that zone's database file. The name server updates the zone database file when it exits, unless you tell it to update it sooner. The command DNS --> Update Server Data Files causes the name server to update the zone database files of all zones it's a primary for, regardless of whether or not they've been modified. To avoid losing data, we recommend using DNS --> Update Server Data Files after any changes-use it like you use the Save command in other applications. Of course, the difference here is that the server will save your data if it exits gracefully. You don't have to use DNS --> Update Server Data Files after a batch of changes, but it doesn't hurt anything and you can sleep better.

    ====

    Although the above was from NT4 DNS, some of the basic things haven't changed. When you restart the service, it applies the zone property's config to the records. You may even get away with reloading the zone, but I haven't test that. When I was hosting numerous public zones for customers years ago, anytime I had to change the TTL so I can change something, such as move their zone to a different nameserver, I would chop the TTL down to 5 minutes the day before. But I always restarted the service to insure it took effect.

    I don't know if BIND does the same thing, but if I were running BIND on a *nix box, I would probably restart the daemon as well.

    Ace


    Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003, Microsoft Certified Trainer, Microsoft MVP - Directory Services. This posting is provided AS-IS with no warranties or guarantees and confers no rights.
    Thursday, June 10, 2010 3:23 AM
  • Hi Ace,

    Thanks for your reply.

    The text you quote talks about updating the physical files manually to ensure any modification are persisted in case of an unexpected event. This is different from my problem of having invalid TTL data answered to external clients. The zone is always at least updated in memory and that's the main source of data when the server is running.

    I can see some changes without having to reload anything (the SOA record is correctly updated), so why not all? When I update the TTL of a specifc record, the change is also reflected publicly instantaneously. So the fact that the default TTL is not applied to other records seems inconsistent to me.

    The scenario you describe (lowering the Default TTL to 5 minutes for migrations) is exactly what my customers do frequently. But to do it, they use a Web interface I developped and I cannot restart the whole service after each change (for obvious security and availability reasons). Reloading the zone also seems problematic because the zone enters a locked state (pending replication to the secondary) after a change is made and reloading becomes denied for some time.

    Does anybody can confirm the problem (I'm still surprised this is occuring) or have a solution?

    Regards,
    Nicolas

     

    Thursday, June 10, 2010 4:51 AM
  • Hi Nicolas,

    As long as I remembered, changing something like this requires restarting the service. Understanding you have a web interface offering the ability for customers to manage their own zones can be challenging with this issue. After they make the change, may I suggest to instantiate a pop-up saying that "The changes you made will be effective after 15 minutes," or something like that?

    Even BIND has to be restarted, from what I found searching around a bit:
    DNS/BIND TTL Settings During Domain Migrations (look at the second section or search on 'restart' in this link):
    http://www.netadmintools.com/art232.html

    How Long Will A DNS Change Take (Blurb on telling customers to wait a certain time period for any changes to take effect):
    http://serverfault.com/questions/20123/how-long-will-a-dns-change-take

    And funny, some providers even ignore TTL changes -
    Providers Ignoring DNS TTL?
    http://ask.slashdot.org/article.pl?sid=05/04/18/198259

    Otherwise, if no one else responds or confirms the restart or reload requirement, as far as I know you have to do something with the service or reload the zone for the TTL to take effect on all records.

    Ace


    Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003, Microsoft Certified Trainer, Microsoft MVP - Directory Services. This posting is provided AS-IS with no warranties or guarantees and confers no rights.
    Thursday, June 10, 2010 6:00 AM
  • Hi Ace,

    Thanks for your help.

    I'm kind of disappointed if BIND also has to be restarted to apply changes. I was thinking of it as a better product than Microsoft DNS server ;)

    I'm well aware of DNS caching issues and providers ignoring actual TTL values. But that's a different story.

    I'm really looking for a confirmation and an explanation of the exact behaviour I described. As this is neither documented nor coherent with other actions, I still think it may be a bug to correct.

    Regards,
    Nicolas

     

    Thursday, June 10, 2010 1:21 PM
  • Nicholas,

    I don't have any specific Microsoft links explaining this for you, unfortunately. I can tell you the MOC (Microsoft Official Courseware), since I teach MOC courseware (I'm an MCT), it does indicate in some of the labs when DNS property settings are changed, to restart the software.

    I don't agree that it's a bug. It's simply a propertiers change that needs to be applied at service startup, such as in cases where some registry settings that don't take effect until the computer restarts.

    Ace


    Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003, Microsoft Certified Trainer, Microsoft MVP - Directory Services. This posting is provided AS-IS with no warranties or guarantees and confers no rights.
    Thursday, June 10, 2010 2:48 PM
  • Thank you Ace.

    I understand your point of view. I just hope you are wrong and this behaviour was not intentional (shouldn't we have a warning pop-up if it was?)

    Were you able to reproduce the problem on your side? This may come from me after all...

    I will also wait to see if others have other experience or suggestions.

    Regards,
    Nicolas

     

    Thursday, June 10, 2010 4:06 PM
  • You are welcome.

    It doesn't show an error or warning saying changes will take efffect after a service restart. Shoud it? Possibly, yes, which would remove any ambiguities.

    Let's see if anyone else responds, otherwise my thoughts still stand. :-)

    Cheers!

    Ace


    Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003, Microsoft Certified Trainer, Microsoft MVP - Directory Services. This posting is provided AS-IS with no warranties or guarantees and confers no rights.
    Thursday, June 10, 2010 9:26 PM
  • >>the Default TTL value of a zone (ie the MINIMUM field of the SOA record), records in the zone not having an explicit TTL defined are
    >>still being published with the previous Default TTL value of the zone. I need to manually reload the zone or restart the server for the
    >>change to take effect.

    This is by design.  The Default TTL, is just that a default for newly created records.  Once the records are created their TTL is independent of the Default TTL on the SOA.  Microsoft DNS implemtation copies the Default TTL setting to all newly created records their by giving them all independent TTL settings.

    Per RFC 2308 (exact text below), but my short interpretation is this: Microsoft was free to develop their own mechanism for assigning TTLs to records, my original statements holds...The Default TTL, is just that a default for newly created records....it also appears all records in MS DNS have their own TTL setting.

    SOA Minimum Field: The SOA minimum field has been overloaded in the past to have three different meanings, the minimum TTL value of all RRs in a zone, the default TTL of RRs which did not contain a TTL value and the TTL of negative responses. Despite being the original defined meaning, the first of these, the minimum TTL value of all RRs in a zone, has never in practice been used and is hereby deprecated. The second, the default TTL of RRs which contain no explicit TTL in the master zone file, is relevant only at the primary server. After a zone transfer all RRs have explicit TTLs and it is impossible to determine whether the TTL for a record was explicitly set or derived from the default after a zone transfer. Where a server does not require RRs to include the TTL value explicitly, it should provide a mechanism, not being the value of the MINIMUM field of the SOA record, from which the missing TTL values are obtained. How this is done is implementation dependent.

    Read more: http://www.faqs.org/rfcs/rfc2308.html#ixzz0qVpTEitk
    • Marked as answer by ngiraudex Friday, June 11, 2010 5:56 AM
    Friday, June 11, 2010 3:48 AM
  • Hi Gunner999,

    I knew about the different meanings of the MINIMUM field but I conducted more tests after your reply and I think I now have the full explanation.

    All you say corresponds exactly to what happens if I don't reload the zone: the Default TTL is applied to new records I create and other records stay at the previous value because each record seems to have its own TTL.

    But if I look at the physical zone files, things are different: my records do not have an explicit TTL defined in their lines.

    That's why, when I reload the zone, the explicit TTL values have no other choice than being recreated in memory from the SOA MINIMUM filed, which is the only source of information at that time, letting me think my changes are "applied".

    So the the confusion comes from the fact that Microsoft DNS servers behaves differently between memory and zone files. Either zone files should contain explicit TTL for all lines or memory should not be systematicaly filled with explicit values.

    I don't know if we should consider this a bug but it's clearly not instinctive.
    I guess it comes from the fact that Microsoft DNS servers were more designed to be Active Directory DNS servers (no zone files) than public DNS servers.

    Thanks a lot for your help!

    Regards,
    Nicolas

     

    • Marked as answer by ngiraudex Friday, June 11, 2010 5:56 AM
    Friday, June 11, 2010 5:55 AM
  • Good explanation, Gunner999. It makes sense based on some of the differences with Microsoft DNS' implemenation.

    Ace


    Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003, Microsoft Certified Trainer, Microsoft MVP - Directory Services. This posting is provided AS-IS with no warranties or guarantees and confers no rights.
    Sunday, June 13, 2010 3:48 PM