Skip to content
allanninal.dev/build
Collaborate

Part 2 of 7 · DNS change auditor series ~5 min read

How a zone gets snapshotted

There is an awkward fact at the centre of this design: from outside, you generally cannot list what is in a DNS zone. You can only ask about names you already know. So the first job is knowing which names to ask about, and it turns out you have four sources for that.

Key takeaways

  • You cannot enumerate a zone from outside. The name list is assembled from four sources.
  • Certificate transparency is the best single source of hostnames you actually use.
  • Query a fixed set of record types per name, not everything.
  • Two resolvers, and a change is only a change when both agree.
  • A name that stops resolving is as important as one that changes.

Building the name list

How the list of DNS names to snapshot is assembledA vertical chain of five steps entered by a box labelled A domain, from the register. Step one asks whether a provider API is available giving the complete list; if so it exits to Done and enumerates directly. Step two adds names from certificate transparency logs, covering every hostname that has had a certificate. Step three adds names from your own application configuration. Step four adds the obvious names: the apex, www, mail, and the well-known TXT names. Step five produces a name list, usually twenty to sixty entries. A note says the list is a superset, and a name that has never resolved is checked and stays absent.AWS ACCOUNTA domainfrom the registerProvider API, if you have onethe complete listDoneenumerate directlyavailableCertificate logsevery hostname with a certYour own configwhat your apps refer toThe obvious namesapex, www, mail, and thewell-known TXT namesA name listusually 20 to 60The list is a superset. A name that has never resolved is checked and stays absent.
Fig 1. How the list of names to snapshot is built. Where a provider API exists it is the complete answer; where it does not, three sources between them cover almost everything that matters.
  • Machine learning
  • Networking
  • Security & identity
  • Analytics
  • Outside AWS

Where a provider API exists, use it

If your zones are in Route 53, or any provider with a list-records API, that is the complete answer and the enumeration problem disappears. Read the zone, snapshot every record, done. Most small businesses have at least one zone like this and at least one that is somewhere else entirely.

Even then, the resolved check is still worth running alongside it, because a zone that is correct in the provider and not authoritative in the real world is precisely the failure the API view cannot show you.

The obvious names

A fixed list that costs nothing to check and catches a surprising amount: the apex, www, mail, autodiscover, _dmarc, _domainkey and the selectors your mail provider uses, and _acme-challenge. The last one is worth watching for an unusual reason: a validation record that has been left in place long after a certificate was issued is an untidiness, and one that appears when nobody is issuing a certificate is not.

Which record types

TypeWhyWhere
A / AAAAWhere a name pointsEvery name
CNAMEWhat a name aliasesEvery name
MXWhere mail goesApex and any mail subdomain
TXTSPF, DMARC, verification tokensApex, _dmarc, selectors
NSWho is authoritativeApex and any delegated subdomain
CAAWho may issue certificatesApex

CAA is the one most people leave out and it is cheap to include. A CAA record that changes, or one that disappears, changes who is allowed to issue a certificate for your domain, and that is worth a message.

Two resolvers

Why DNS snapshots are taken from two resolversA horizontal row of five boxes. Resolver A says X. Resolver B says Y. Disagree: the zone is mid-propagation. Wait an hour: and check again. Both agree: now it is a change. A note says a single resolver mid-propagation reports a change and then reports it back again.WHY TWO RESOLVERSResolver Asays XResolver Bsays YDisagreemid-propagationWait an hourcheck againBoth agreenow it is a changeA single resolver mid-propagation reports a change, then reports it back again.
Fig 2. Why the snapshot uses two independent resolvers. Propagation makes a single resolver report a change and then un-report it, which is exactly how people learn to ignore a monitor.
  • Machine learning
  • Networking
  • Management

Requiring both resolvers to agree before calling something a change removes almost all propagation noise at the cost of one extra query per name and up to an hour of delay. For a critical record that delay is unwelcome, so critical records use a third resolver and alarm on two out of three — faster, and still not fooled by one stale cache.

Disappearance

A name that resolved yesterday and does not today is a change, and it is one that a naive diff on record contents will miss entirely. It is also, in practice, more likely to be a real problem than a modification: records get deleted during tidy-ups far more often than they get maliciously edited.

Next: how a change gets described.

All posts