Skip to content
allanninal.dev/build
Collaborate

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

How a DNS change gets described

The difference between a DNS monitor people act on and one they filter is entirely in the wording of the message. A diff is correct and unreadable. A sentence with the consequence in it gets answered in ten seconds.

Key takeaways

  • The message names the record, the old value, the new value, and the consequence.
  • The consequence comes from a fixed table, not from a model.
  • A model is used for one thing: describing an SPF or DMARC change in plain words.
  • Additions, modifications and deletions read differently and should.
  • A change with no known consequence says so rather than inventing one.

Four lines

What a change message says

  • The record. “MX at example.com”
  • Was. “10 mail.provider.example”
  • Now. “10 mail.oldhost.example”
  • Which means. “Incoming mail for example.com now goes to mail.oldhost.example. If that host is not accepting mail, messages will bounce or be lost.”
  • Two buttons. “That was me” and “Not me — investigate”.

The fourth line is the one that changes behaviour. A person reading the first three lines has to know what an MX record does to know whether to care; a person reading the fourth does not. And the people most likely to be reading this message at nine on a Tuesday are exactly the people who half-remember.

Consequences come from a table

How a DNS change is turned into a readable explanationA vertical chain of four steps entered by a box labelled A confirmed change, carrying the record, the old value and the new. Step one asks whether it is a known record type such as MX, NS, an apex A record or CAA, checking a consequence table with one sentence each; a hit exits to Use the sentence, which is fixed and never generated. Step two asks whether it is SPF or DMARC, whose syntax people cannot read; if so it exits to One Bedrock call to explain the difference. Step three covers anything else, such as a CNAME or a TXT token. Step four says so plainly: we do not know what this one is for. A note says the model is used on exactly two record types because their syntax is genuinely opaque.AWS ACCOUNTA confirmed changerecord, old, newKnown record type?MX, NS, apex A, CAAConsequence tableone sentence eachUse the sentencefixed, never generatedyesSPF or DMARC?syntax people cannot readOne Bedrock callexplain the differenceyesAnything elsea CNAME, a TXT tokenSay so plainly'we don't know what thisone is for'The model is used on exactly two record types, because their syntax is genuinely opaque.
Fig 1. How a change gets its explanation. Almost every record type has one fixed sentence; the two that do not are the ones whose syntax nobody can read at a glance.
  • App integration
  • Machine learning
  • Analytics
  • Front-end & mobile

Why fixed sentences

An MX change means the same thing every time and the sentence explaining it can be written once, carefully, by somebody who knows what they are talking about. Generating it produces a slightly different sentence each time, occasionally a wrong one, and always a more expensive one.

The consequence table has perhaps a dozen entries and covers the record types where a change has a predictable effect. It is a sheet, so somebody who thinks a sentence is unclear can improve it without touching any code.

Why SPF and DMARC are different

Because the change is inside a string, and the string is genuinely unreadable. “v=spf1 include:_spf.provider.example include:mail.other.example ~all” becoming the same string with one include missing is a diff that a person can see and cannot interpret at a glance.

So those two get one model call, given both strings and asked what the practical difference is: “mail sent through Other Mail Provider will no longer pass SPF.” That is a sentence with a consequence in it, and it is the kind of thing a model is genuinely good at that a lookup table cannot do.

Three shapes of change

Five kinds of DNS change and how each is treatedA horizontal row of five boxes. Added: usually fine. Modified: show both values. Deleted: the dangerous one. Stopped resolving: which is not the same as deleted. Reappeared: worth a sentence. A note says deletion and non-resolution look identical to a diff and are different problems.FIVE THINGS THAT COUNT AS A CHANGEAddedusually fineModifiedshow both valuesDeletedthe dangerous oneStopped resolvingnot the same as deletedReappearedworth a sentenceDeletion and non-resolution look identical to a diff and are different problems.
Fig 2. The five shapes of change and why they read differently. A record that stopped resolving without being deleted is a delegation or propagation problem rather than an edit.
  • App integration
  • Machine learning
  • Management
  • Analytics

Distinguishing deletion from non-resolution needs the provider API where one exists: a record that is still in the zone but no longer resolving is a delegation problem, and one that has gone from the zone is an edit. Where there is no API, the message says which it cannot tell — “stopped resolving; we cannot see the zone to say whether it was removed” — because that distinction changes who you go and talk to.

Next: the mail records, which get their own post for good reason.

All posts