DNS drift: when the console becomes the source of truth

Infrastructure as code assumes the repository is authoritative. In practice, DNS records drift away from committed state more often than any other resource class, and the reason is structural rather than careless.

## Why DNS drifts more than compute

DNS changes are fast, low-friction and often urgent. A TTL is lowered ahead of a migration, a record is repointed during an incident, a CNAME is added to unblock a certificate renewal. Each change is made in a console because the console is faster than a pull request, and each one is intended to be temporary.

Most are never codified afterwards. The repository still describes the state that existed before the incident, and every subsequent plan reports success because it is comparing against a stale definition of correct.

## What separates noise from signal

Comparing live records against committed state produces a high volume of differences, most of which do not matter. TTL adjustments account for the majority and are almost always deliberate.

The differences that matter share one property: they change where traffic terminates. A repointed A record, a modified CNAME target, an altered MX priority. These alter the path a request takes without any corresponding change in the repository, which means the next apply may silently revert them.

## The detection gap

A drift check that runs on the same schedule as the apply pipeline will miss changes made between runs and reverted before the next one. Detection needs to run more frequently than change, not more frequently than deployment.

Fifteen minute intervals catch most manual intervention windows. Hourly checks do not.

## What to do with a finding

A material drift finding is not automatically an error. The console change may have been correct and the repository wrong. The useful output is not a reconciliation but a question: which of these two states was intended, and why was the other one never updated?