{{ summaryTitle }}
{{ summaryPrimary }}
{{ summaryLine }}
{{ badge.label }}
Enter the existing cache lifetime that resolvers may still hold before the lower TTL takes effect.
Set the temporary TTL that should be active by the time the record value changes.
Use the time between publishing the lower TTL and changing the DNS answer.
Use 1.0 for strict TTL math, or 1.25-1.5 for conservative migrations.
x
Use 0 unless a resolver, parent record, or delegated record has a longer cache lifetime than the current TTL.
Include this when clients may have queried a missing name or type before you add the record.
Used in the final stable-time estimate only; it does not change pre-lower readiness.
min
Two cycles is a practical default for seeing late resolver refreshes before restoring TTL.
cycles
Keep this at the normal production TTL you want after the migration has settled.
Window item Value Runbook note Copy
{{ row.item }} {{ row.value }} {{ row.note }}
Guardrail Condition Current Outcome Copy
{{ row.guardrail }} {{ row.condition }} {{ row.current }} {{ row.outcome }} 

          

        

      

    

  

                

                

                    

                        

                            Tags: DNS, Networking
                        

                        

                            Export to PDF
                            Fullscreen
                        

                    

                

            

        

    


        
    

        

        

            

            
        

    


                                                                                                                                                                                                                                                        
    

        

            
            

                Customize

                

                    

                        

                            
                            
                        


                        

                            
                            
                        


                        

                            
                            
                        

                    


                    

                        Advanced

                        

                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    :
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                
                                
                            


                            

                                
                                
                            

                        

                    

                

            

            
        


        

            
            
            
        


        
    



    

        

  

    
    
DNS time to live, or TTL, is the cache lifetime attached to a DNS answer. When a resolver has already cached an answer, changing the authoritative record does not force that resolver to forget the old value immediately. The resolver can keep using the cached answer until its remaining TTL expires.

    
A DNS change window is the planned time between lowering TTL, making the actual record change, checking that the new answer is visible, and restoring a normal production TTL. The window matters during migrations, failovers, mail routing changes, CDN moves, and any cutover where stale answers could send users to the wrong service.


    

      
        
        
        
        
        
        
        
          Old cache drain
          Lead covered
          Wait gap
          Edit
          Observe
          longest TTL x safety
          pre-lower lead
          remaining wait
          cutover
          TTL cycles
          
          
          
          lower TTL published
          answer changed
          new answer checked
        
      
      
The useful planning question is whether the pre-lower lead fully covers the old cache drain before the DNS answer changes.

    


    
Lowering TTL before a change is useful only after the previous, longer TTL has had time to age out of resolver caches. A record that used to have a 24 hour TTL can still be held for close to that long by resolvers that queried it shortly before you lowered the value. The shorter TTL helps later refreshes, but it does not rewrite caches that already exist.

    
The estimate should be read as a planning guardrail, not a promise that every client will switch at the same second. Recursive resolvers, operating system caches, application caches, parent-zone records, and negative answers can all make real cutovers look wider than the main record TTL alone suggests.

  






  

    
Technical Details

    
A resource record TTL is expressed in seconds and tells a resolver how long the record may be cached before the resolver should consult the source again. In a change plan, the old answer drains according to the longest relevant cached value, not necessarily the record you are about to edit. NS, DS, resolver-observed, provider-specific, and negative-cache values may be longer than the current record TTL.

    
Negative caching needs separate attention when clients may have asked for a name or record type before it existed. For NXDOMAIN or NODATA answers, the cache lifetime is carried through the zone's SOA data. A migration that adds a previously missing record can be slowed by that negative TTL even when the final positive record has a short TTL.

    
The model uses conservative elapsed time. First it chooses the longest cache input, multiplies it by the safety factor, and subtracts the pre-lower lead already planned. After the actual record edit, it adds the operational cutover budget and a verification period based on lowered-TTL cycles before treating the record as ready for TTL restoration.


    
Formula Core

    

      
        
          
            L
            =
            max(current TTL, known longer cache, negative cache TTL)
          
          
            D
            =
            L×safety factor
          
          
            W
            =
            max(0, safe drain - pre-lower lead)
          
          
            O
            =
            lowered TTL×verification cycles
          
          
            S
            =
            W+cutover action time+O
          
        
      
    


    
In the formulas, L is the longest cache lifetime, D is the safe drain window, W is the additional wait before changing the DNS answer, O is the post-change observation period, and S is the stable-time estimate after the planned cutover point. The full window from the moment TTL is lowered is D + cutover action time + O.


    

      

        
        
          

            Quantity
            Rule
            Effect on the window
          

        
        
          

            Current TTL
            Must be greater than zero.
            Represents old positive answers that may still be cached before the lowered TTL is seen.
          

          

            Lowered TTL
            Must be greater than zero. A value at or below 5 minutes is treated as a strong migration target.
            Controls how quickly refreshed answers can age out after the cutover and how long verification cycles last.
          

          

            Pre-lower lead time
            Cannot be negative.
            Offsets the safe drain window. If it is long enough, no extra wait is needed at cutover time.
          

          

            Safety factor
            Must be at least 1.0x; the input control is capped at 3.0x.
            Adds room for resolver lag, stale observations, client-side caches, and schedule uncertainty.
          

          

            Known longer cache
            0 disables the override; positive values join the longest-cache comparison.
            Accounts for parent NS or DS TTLs, resolver observations, or provider outliers that exceed the record TTL.
          

          

            Negative cache TTL
            0 leaves negative caching out; positive values join the longest-cache comparison.
            Protects additions of names or record types that clients may already have queried unsuccessfully.
          

          

            Verification cycles
            Clamped between 0.5 and 6 lowered-TTL cycles.
            Sets how long to observe the new answer before restoring the steady-state TTL.
          

        
      

    


    
The calculation is deterministic and runs from the timing values entered on the page. It does not query authoritative servers or public resolvers, so it cannot discover your actual DNS state. If the page address is shared with values in it, treat those timing assumptions as visible to anyone who receives the link.

  






  

    
Everyday Use & Decision Guide

    
Start with the longest TTL that can affect the change, not just the record you plan to edit. For an ordinary A or CNAME cutover, that may be the current record TTL. For delegation work, DNSSEC work, or records that were missing before the change, the longer value may come from NS, DS, resolver cache observations, or negative caching.

    
A practical first pass is to enter the current TTL, choose a lowered TTL such as 300 seconds when your DNS provider allows it, and set the pre-lower lead time to the time between publishing that lower TTL and changing the answer. Use 1.0x only when you want strict TTL arithmetic. Use 1.25x to 1.5x when the change window needs operational margin.

    
Open the advanced section when the main record is not the only cache that matters. Known longer cache is for parent records, resolver measurements, or provider outliers. Negative cache TTL belongs in the plan when clients may have received NXDOMAIN or NODATA before you added the name or type. Cutover action time is the editing and verification budget, and Verification cycles controls how long the lowered TTL should be observed after the new answer appears.

    
    
      
  • Use Window Ledger to read the safe drain, remaining wait, stable point, full window, and restore timing as runbook rows.
    • 
      
  • Use TTL Guardrails before the maintenance window. It flags a lowered TTL that is not actually lower, a temporary TTL above 10 minutes, and long-cache values that drive the conservative wait.
    • 
      
  • Use TTL Window Stack when the timing needs to be explained visually in a change review.
    • 
      
  • Use the JSON view when the same assumptions need to be pasted into a ticket, runbook, or before-and-after record.
    • 
    

    
Do not treat a ready status as proof that every client will see the new answer. It means the entered lead time covers the modeled cache drain. Confirm authoritative answers, sample the recursive resolvers your users depend on, and restore the normal TTL only after the observation window has passed.

  






  

    
Step-by-Step Guide

    
    
      
  1. Enter the current TTL that resolvers may already have cached. Use the longest relevant value if more than one cache can affect the cutover.
    2. 
      
  2. Enter the lowered TTL you plan to publish before the record value changes. A 5 minute value is a common migration target when the DNS provider accepts it.
    3. 
      
  3. Set the pre-lower lead time to the actual delay between publishing the lower TTL and making the DNS value change.
    4. 
      
  4. Choose a safety factor. Keep 1.0x for strict math, or add margin for conservative migrations and scheduled change reviews.
    5. 
      
  5. Open advanced settings if a parent record, DNSSEC record, resolver observation, provider cache, or negative answer may last longer than the current record TTL.
    6. 
      
  6. Review warnings before relying on the result. A lower TTL that is not lower, a temporary TTL above 10 minutes, or a longer-cache override can change the decision.
    7. 
      
  7. Read the additional wait before cutover and the stable point after planned cutover. Those two rows are usually the main runbook timings.
    8. 
      
  8. After changing the DNS answer, observe the configured lowered-TTL cycles before restoring the steady-state TTL.
    9. 
    

  






  

    
Interpreting Results

    
Ready now means the planned pre-lower lead is at least as long as the safe drain window. Wait needed means the old-cache drain is not fully covered yet. A short wait appears when the gap is within two lowered-TTL cycles or 10 minutes, whichever is larger; a longer gap is a stronger signal that the cutover should be delayed.


    

      

        
        
          

            Output
            What it means
            Useful follow-up
          

        
        
          

            Safe drain window
            Longest cache lifetime multiplied by the safety factor.
            Check that the longest source named in the ledger is the value you intended to model.
          

          

            Additional wait before cutover
            Time still needed after the planned pre-lower lead before changing the answer.
            Delay the DNS value change by this amount when it is greater than zero.
          

          

            Post-change observation
            Lowered TTL multiplied by verification cycles.
            Use it as the minimum watch period before restoring a longer TTL.
          

          

            Stable point after planned cutover
            Remaining wait, cutover action time, and observation time combined.
            Use this row when the runbook needs a single time after the planned cutover start.
          

          

            Full window from TTL lowering
            Safe drain, cutover action time, and observation time combined.
            Use it to estimate the total maintenance preparation span from the TTL-lowering step.
          

          

            Resolver query load
            Current TTL divided by lowered TTL, shown as cache turnover versus the old setting.
            Check authoritative capacity when this multiplier is large and the lowered TTL will stay in place for a long time.
          

        
      

    


    
Warnings should slow the plan down. A lowered TTL that is greater than or equal to the current TTL will not shorten old cached answers. A lowered TTL above 10 minutes may still be valid, but it stretches rollback and verification loops. A known longer cache or negative cache warning means the conservative wait is being driven by something other than the current positive record TTL.

    
The stack chart compares phases in hours. It is useful for spotting a plan where the pre-lower lead is much longer than needed, or where a long negative TTL overwhelms an otherwise short record change. Read the chart with the ledger rows, because the table names the source and exact duration behind each phase.

  






  

    
Worked Examples

    
With the default values, a current TTL of 3,600 seconds and a safety factor of 1.5x produce a safe drain window of 5,400 seconds, or 1 hour 30 minutes. A 24 hour pre-lower lead covers that drain with 22 hours 30 minutes spare. With a 15 minute cutover budget and two 300 second verification cycles, the stable point after planned cutover is 25 minutes.

    
A more constrained plan looks different. If the current TTL is 24 hours, the lowered TTL is 300 seconds, the pre-lower lead is 12 hours, and the safety factor is 1.25x, the safe drain is 30 hours. The plan is 18 hours short before the DNS answer should change. After that wait, a 15 minute cutover budget and two lowered-TTL observation cycles add another 25 minutes before restoring the normal TTL.

    
For a record that did not exist before the migration, a negative cache TTL can become the controlling value. If the current positive TTL is 1 hour but the relevant negative cache TTL is 2 hours, the safe drain uses 2 hours before the safety factor is applied. That prevents a newly added record from being planned as if only positive answers had ever been cached.

  






  

    
FAQ

    

      
Does lowering TTL make an existing cache expire immediately?

      
No. A resolver that cached the old answer before the TTL was lowered can keep that old answer until the old remaining TTL expires. The lower TTL helps future refreshes after that point.

    

    

      
Why include a safety factor?

      
Strict TTL math assumes the entered cache lifetime is the only delay that matters. A safety factor adds margin for late observations, resolver behavior that is not perfectly visible, client caches, and human scheduling uncertainty.

    

    

      
When should negative cache TTL be used?

      
Use it when clients may have queried a missing name or missing record type before you add it. Examples include adding a new TXT record for verification, creating a new subdomain, or publishing a record type that previously returned no data.

    

    

      
Can the estimate replace a DNS propagation check?

      
No. The estimate plans a conservative timing window from the values you enter. A propagation check asks resolvers what they actually return. Use both when the change is important.

    

    

      
Why not leave the lowered TTL in place forever?

      
Short TTLs make resolvers refresh more often. That can help during a migration, but it may increase authoritative query load and reduce cache resilience during outages. Restoring a normal TTL after verification is usually better for steady-state operation.

    

  






  

    
Glossary

    

      
TTL

      
Time to live, the number of seconds a DNS answer may be cached before refresh.

      
Pre-lower lead time

      
The time between publishing a shorter TTL and changing the DNS answer itself.

      
Safe drain window

      
The longest relevant cache lifetime after applying the chosen safety factor.

      
Negative caching

      
Caching of a missing-name or missing-type answer, such as NXDOMAIN or NODATA.

      
Verification cycle

      
One lowered-TTL interval used as an observation period after the new answer appears.

      
Restored TTL

      
The normal steady-state TTL planned after the migration has settled.

    

  






  

    
References