Engineering reference: the dns change auditor architecture

The system, by service name

• Compute
• Database
• App integration
• Networking
• Management

Region and account

• Region: us-east-1. Chosen because SES inbound receipt rules exist in only a subset of regions and this one has the widest Bedrock model availability. If your data has to stay elsewhere, check both constraints before moving: inbound SES is the binding one.
• Account: one. This is a small system, and a separate account per environment costs more in wiring than it saves. A dev and a prod stack in the same account, with distinct resource prefixes, is the right size here.
• Everything is regional. The only global resources are the IAM roles and policies. There is no CloudFront, no global table and no cross-region replication, because nothing here has a latency or durability requirement that would justify them.

Lambda inventory

Splitting this into separate functions is not about modularity. It is that only one of them needs Bedrock permissions and only one is reachable from the public internet, and neither of those is true if it is one handler behind a router.

IAM, scoped

No role has a Resource: “*” on anything that writes, and every GetSecretValue grant names a single secret arn. That is why there is more than one secret rather than one JSON blob with everything in it.

DynamoDB schemas

Table: current

PK   name              S   example.com
SK   rrtype            S   MX
     values            L   sorted, so ordering is not a diff
     digest            S   sha256 of the sorted values
     critical          BOOL true
     resolvers_agree   BOOL true
     last_seen         S   2026-07-27T14:00:00Z
     spf_lookups       N   only on the apex TXT: 7

Values are SORTED before hashing. Two MX records returned in a different
order by a resolver is not a change, and un-sorted comparison would report
one every few hours.

Table: changes

PK   name_rrtype       S   example.com#MX
SK   seen_at           S   2026-07-27T14:00:00Z
     kind              S   added | modified | deleted | unresolvable | reappeared
     old               L   the previous values
     new               L   the current values
     consequence       S   from the table, or from the model for SPF/DMARC
     critical          BOOL true
     confirmed_by      S   who said it was them
     confirmed_at      S   when
     escalated_to      L   [who, when]
     ttl               N   epoch, +3 years

Inbound and outbound

• Outbound DNS only, plus the signed confirmation links. There is no inbound path of any kind.
• Two resolvers for ordinary records and three for critical ones, so a stale cache cannot manufacture a change or delay a real one.
• DNS over HTTPS to public resolvers, rather than UDP, so the whole thing works from a Lambda with no VPC and no NAT gateway. That last detail is worth more than it sounds: a NAT gateway would cost thirty times the rest of this system.
• Nothing in the account has a Route 53 write permission, and a read permission only where a provider API is used for enumeration.

The model call

• Model: anthropic.claude-haiku-4-5-20251001-v1:0 on Bedrock, used only to describe the practical difference between two SPF or DMARC strings.
• Every other record type uses a fixed sentence from the consequence table, which is a sheet somebody can improve without a deploy.
• Called a handful of times a year. SPF and DMARC records change rarely, which is exactly why a change to one matters.
• Output is a JSON schema with one sentence and a nullable named sender. A null produces the diff with no interpretation rather than a guess.
• It is never asked whether a change is bad. That is the question a person answers by recognising their own work or not.

That is the whole system. Seven posts, one diagram at a time, and nothing in it that needs a server.

All posts