Ola Marek

I find that almost every confusing DNS behaviour is a cache, and the cache is the only thing standing between a change and the rest of the internet. The time-to-live is how long a resolver may keep an answer, and it is a lower bound on freshness rather than an upper bound, because a resolver may discard sooner. That is why lowering a TTL and waiting before making a change is the standard procedure and why skipping the wait produces a partial update. The wait has to be at least as long as the TTL currently published, and it has to happen before the change, not after. The second cache is the one on your own machine, and it survives a restart on some systems. A resolver cache that is not cleared after a change is why a machine next to the one you just fixed still shows the old answer. Propagation also differs by authority. A recursive resolver asking an authoritative server gets a fresh answer on the TTL schedule, and the time to appear is bounded by the TTL of the record that changed, not by the record you are looking at. Record types behave differently under this. A change of address on an existing name is visible on the old TTL, while a new name is queried fresh because nothing cached it. That asymmetry is behind most of the half-changed states people describe. The practical response to a change that needs to land quickly is to lower the time to live beforehand and wait, then restore it afterwards.