SOA timers are sensible

The SOA record carries four timers, and three of them only govern the relationship between a primary and its secondaries — they are not the TTLs that control caching of your records, which is a common source of confusion.

**Refresh** is how often a secondary checks the primary for a new serial. **Retry** is how long it waits after a failed check, and should be shorter than refresh. **Expire** is the point at which a secondary that has been unable to reach the primary stops serving the zone altogether; it is the one with the most serious consequence, because too short a value means an outage at the primary becomes an outage of the whole domain. Two to four weeks is the usual range.

The fourth field, **minimum**, no longer means what its name says. RFC 2308 redefined it as the negative caching TTL — how long a resolver may remember that a name does *not* exist. Set it high and a newly created record stays invisible to anyone who looked too early; set it very low and you invite repeated queries for names that will never exist.

In practice most zones are driven by NOTIFY rather than by polling, so refresh and retry matter less than they did. Expire and minimum still matter.

Reasonable defaults: refresh 1–24 hours, retry well under refresh, expire 2–4 weeks, minimum 5 minutes to 1 hour. If your provider manages the zone, these are usually set sensibly and are not worth touching.

Lower the negative caching TTL before a migration where new names will appear, and restore it afterwards. That is the timer people are actually feeling when a newly added record "takes hours to work" for some people and not others.

Do not shorten expire to make replication feel more responsive. It does not do that, and it converts a survivable primary outage into a total one.