Registrar, Resolver, Record: Assembling a DNS Resilience Evidence Pack

Every regulated estate in the UK carries an assurance file of some description. It will contain restore test results, evidence of exit readiness from cloud arrangements, perhaps a supplier register with fourth-party visibility. It is much less likely to contain anything meaningful about the domain name system. That omission is difficult to defend. DNS is the first dependency of nearly every service the business exposes, and the last one most teams rehearse failing over.

Why DNS Sits Outside the Assurance Habit

The reason is partly structural. DNS is rarely owned by a single team. Registrars sit with brand or marketing, zone files with network engineering, DNSSEC keys with whoever last touched them, and recursive resolution with the endpoint or security function. No one holds the whole picture, so no one is asked to evidence it. The control plane is silent until it is not, and when it fails the failure mode is unusually punishing: names stop resolving, certificates cannot be validated, and recovery tooling that depends on those names becomes unreachable at precisely the moment it is needed.

Regulators and auditors have grown comfortable asking for restore evidence and, more recently, for reversibility evidence. The same standard should apply to naming. A DNS resilience evidence pack is not a large artefact. It is a small set of attested facts, refreshed on a schedule, and it can be assembled in weeks rather than quarters.

Start With the Registrar Relationship

Registrar controls are the outermost ring and the easiest to leave unexamined. For each domain in scope, the pack should record which registrar holds it, which registry it sits under, and which of the available locks are active — client transfer prohibition, registry lock, and where offered, registrar-level hold. A registry lock that exists but is not enabled is not a control; it is a capability. The evidence should show the lock enabled, the process for lifting it, the named individuals authorised to do so, and the expected time to lift under each registrar's operating model.

Two further items belong here. First, the authentication posture on the registrar account: hardware-backed multi-factor authentication, restricted account recovery routes, and confirmation that no shared mailbox is the recovery address. Second, the renewal posture: auto-renew enabled, payment method current, and a monitored expiry calendar that survives staff turnover. Domain expiry remains one of the least glamorous and most effective ways to take an organisation offline.

DNSSEC Key Custody Is an Operational Control

Where DNSSEC is signed — and for UK estates handling payments, identity or regulated data it increasingly should be — key custody must be evidenced, not assumed. The pack should identify the key signing key and zone signing key arrangements, where the keys are held (hardware security module, on-premises appliance, or a managed provider), who can invoke them, and what the rollover schedule looks like. A key that cannot be rolled over within its validity window is a latent outage.

The more difficult question is the failure case. If the signing infrastructure is lost, what happens? The honest answer for many estates is that the zone continues to serve unsigned or ceases to validate, and downstream validating resolvers begin refusing answers. That outcome should be documented and, where possible, rehearsed. Evidence of a rehearsed DNSSEC recovery is worth considerably more than a policy statement asserting one exists.

TTLs, Split Horizon and the Cost of Convenience

Time-to-live values are the tuning dials of DNS resilience and are frequently set for convenience rather than for recovery. Long TTLs reduce query load and improve caching; they also extend the interval during which a stale or wrong answer persists after a change. The evidence pack should record TTLs for the records that matter most — the apex, the primary service entries, mail authentication records and any names used in failover — and should state the rationale. A TTL of 86,400 seconds on a record that must move within an hour during a regional incident is a contradiction that will surface at the worst moment.

Split-horizon arrangements deserve separate treatment. Internal names served to staff and external names served to the public often resolve through different platforms, with different change control. When a region is lost, the internal view frequently lags the external one, and staff find that the service they can reach from home is unreachable from the office. The pack should map which zones are split, which resolvers see which view, and how the two are reconciled during failover.

Recursive Paths and Third-Party Resolvers

Authoritative resilience is only half the problem. Recursive resolution — the path an endpoint takes to find an answer — is now dominated by third-party resolvers, whether provided by an ISP, a security vendor, or a cloud platform. These resolvers cache aggressively, apply their own filtering, and in some cases refuse to resolve names they consider suspicious. The pack should record which resolvers the estate uses, whether they are contractual, what their filtering policies are, and what fallback exists if a resolver provider suffers an outage or changes policy at short notice.

A useful test here is a controlled failover of the recursive path in a non-production context: point a pilot group at an alternate resolver, observe behaviour for internal and external names, and record the results. The exercise is inexpensive and consistently reveals dependencies nobody had documented.

The Region-Loss Rehearsal

The final section of the pack should describe what happens to naming when a cloud region is lost. This is not a theoretical concern. Estates that run authoritative DNS through a single provider in a single region, without secondary nameservers in a different provider or geography, have concentrated a great deal of operational risk in one place. The evidence should show the secondary arrangement, confirm that delegation lists both sets of nameservers, and record the observed time for a controlled change to propagate.

Filing It With the Rest

None of this is exotic. It is a modest set of facts, most of which already exist somewhere in the organisation. The argument is about placement. DNS evidence belongs in the same assurance pack as restore testing and exit readiness, reviewed on the same cycle, and presented to the same governance forum. A board that has accepted a restore throughput benchmark has no reason to refuse a registrar lock attestation. The name layer is a control plane, and control planes deserve evidence.