Lion Cipher Lab
Plan a DNS cutover from TTLs and negative caching
- Cyber / Security Engineer
- Intermediate
- ~35 min
- Free · no account required
Why it matters
Moving a service — a new load balancer, a new data centre, an emergency failover after an incident — very often comes down to changing a DNS record. How long users keep going to the old address after the change is set by caching rules, not by when you click save. RFC 1035 gives every record a TTL, the number of seconds a resolver may keep a cached copy. RFC 2308 adds negative caching: if a resolver asked for a name that did not exist yet, it may cache that 'does not exist' answer for a time set by the zone's SOA record. Teams get cutovers wrong in predictable ways. They change a record with a…
What you'll learn
- working out worst-case cutover time from TTLs
- lowering a TTL ahead of a change, and why you must wait out the old one
- how negative caching (RFC 2308) delays a brand-new name
- spotting a plan that causes NXDOMAIN rather than just delay
- planning rollback time as well as cutover time
- where real resolvers and applications ignore TTLs
Steps in this lab
- TTLs decide how long the old answer lives
- The current zone
- Write the planner
- Run it: one day, five minutes, or three hours of NXDOMAIN
- Plan the change, and allow for clients that do not follow TTLs