Before migrating the tax portal to new addresses, county DNS operators want client caches to notice the cutover quickly. Which DNS practice should they apply ahead of the change?
Select an answer to reveal the explanation.
Short Explanation
TTL is how long the old address sticks on people's mental (and resolver) sticky notes. Lower it before tax-portal cutover so caches refresh sooner when you flip DNS. Cranking TTL up or deleting the zone is how you stretch out the pain.
Full Explanation
Before migrating a tax portal to new addresses, county DNS operators should lower the relevant DNS TTL values ahead of the planned cutover window. TTL controls how long resolvers may cache answers; a lower TTL means caches expire sooner, so after the cutover record change a larger share of clients learn the new addresses quickly. This is standard migration hygiene for municipal public hostnames where prolonged split-brain between old and new endpoints causes citizen errors and support load.
Raising TTL to several weeks so resolvers ignore the migration longer fails the goal of fast notice—it extends cache lifetime and prolongs stale answers after cutover. Deleting the zone apex so all municipal names fail during planning fails catastrophically: it creates an avoidable outage across the zone rather than preparing a single portal migration. Disabling DNSSEC validation permanently to speed every lookup fails on security concept; DNSSEC integrity is unrelated to intentional TTL planning and should not be sacrificed for migration convenience.
Exam caveat: lower TTL before the change, wait at least the old TTL period so caches have mostly refreshed to the new low TTL, then update the record; after stability, TTLs may be raised again. TTL reduction helps but does not replace correct record updates, health checks, and rollback planning.
Operational check: document original TTLs, publish lowered TTLs on the tax-portal records, wait out prior cache lifetime, perform the address cutover, measure resolution at recursive resolvers serving citizens, then restore longer TTLs once the migration is confirmed stable.