Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


To which extent does the TTL of a name resource record cause a chain of delays in propagation?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

To which extent does the TTL of a name resource record cause a chain of delays in propagation?

Not sure if I can word this correctly.

I know that TTL for a name resource record is sometimes ignored by many ISP, especially when this is set to a too low number. This is mostly the reason why we are told to wait "2 days or more to be sure", when we change a value for, say, an A name.

Let's assume that they do not ignore it. Let's also assume that secondary nameservers pull infos from the primary one immediately, and that SOA does not play a role in this. Just for the sake of my question.

Assume that I have a TTL of 3600 for the A name I am changing.

To which extent does this value cause a reaction chain of delays that, in the worst case, are a multiplication of the TTL itself? I am thinking of recursive nameservers that stay in the middle of some resolution, which will all in turn wait 3600 seconds (in the worst case) to update their record.

Comments

  • dfroedfroe Member, Host Rep

    Your worst case scenario is a delay of 1h (assuming all servers are RFC-compliant).

    There is no 'muliplication of the TTL'. If you query a recursor for a record with a TTL of 1h which was cached by that server 10mins ago, you will get a response with a TTL of 50mins.

    This way you can be sure that all nameservers and clients will be aware of the new value after the TTL of the record in your authorative zone.

    IMHO something like 'wait two days or more to be sure' can be considered an urban legend. Of course given RFC-compliant clients and that you can ensure all authorative nameservers to be notified properly when a change occurs.

    Thanked by 1sgheghele
  • sgheghelesgheghele Member
    edited August 2020

    @dfroe said: If you query a recursor for a record with a TTL of 1h which was cached by that server 10mins ago, you will get a response with a TTL of 50mins.

    I was missing this detail, that TTLs are updated (decreased) once passed around. Thanks!

    Thanked by 1dfroe
  • jsgjsg Member, Resident Benchmarker

    @sgheghele said:
    I was missing this detail, that TTLs are updated (decreased) once passed around. Thanks!

    In theory. In reality rather not, I guess.

    Explanation: Assume some recursor/ns cache keeps 100000 records (unrealistic, I know, because they cache whole domains, but let's keep it simple). If the server had to decrease the TTL even just every 5 seconds that would cause a very significant "event storm" to be handled - in addition to the need to still handle ns requests.

    So, I guess usually some other approach is used, e.g. a table of 360 rows, one for each minute of a rolling 6 hours window where any domain's next refresh is put into and then once a minute the domains scheduled for that minute are refreshed and their next entry is put into the table (min of 360 minutes and TTL).Additionally one might (and certainly many do) set the minimum cache refresh time to a minimum (e.g. 30 min) no matter the TTL.

    Thanked by 1sgheghele
Sign In or Register to comment.