Who Still Points Where: Mapping DNS Delegation Before the Deal Closes

Most integration plans contain a line for DNS. It normally sits near the end, bracketed as technical housekeeping and assigned to whoever happens to hold the administrator account. That placement is the mistake. By the time a deal reaches completion, the target's zone files have usually been accumulating delegated authority for a decade or more, and each delegation is a standing instruction about who may speak for a name. Some of those instructions were written by people who have since left, for services that have since been retired, in favour of providers whose contracts nobody can now locate.

The consequence is not usually an outage on day one. It is a slow realisation, some months into integration, that a subsidiary domain still resolves through an agency that was never told the company changed hands, that a federated sign-in path depends on a hostname nobody has inventoried, or that mail for a dormant brand is being accepted by a third party with no agreement covering it. This piece sets out how to audit delegated authority before completion rather than after.

Delegation is a contract written in a database

It helps to stop thinking of a zone as configuration and start treating it as a record of obligations. Every NS record hands authority for a child zone to named servers. Every delegation to a managed service provider encodes an assumption about continuity, billing and liability. Every wildcard record encodes a decision about what happens to names that were never explicitly created. None of this appears on a balance sheet, yet all of it constrains what the buyer can do once the transaction completes.

The audit therefore begins with a question that is commercial before it is technical: for each name in scope, who is entitled to answer for it, under what agreement, and until when?

The four patterns that cause the most trouble

Orphaned delegations. A child zone points to name servers that no longer exist, or that belong to an entity the target stopped paying years ago. Resolution may continue through cached records or a tolerant resolver, which is precisely what makes the problem hard to see. When the tolerant path finally fails, the failure is total and sudden.

Third-party authority. Marketing agencies, e-commerce platforms and regional partners are frequently granted control of a subdomain so they can move quickly. The grant is rarely revisited. In a transaction, that subdomain becomes an asset with an unknown custodian.

Split-horizon divergence. Where internal and external views of the same name differ, the internal view is an inventory of the estate's private naming conventions. Two organisations merging two internal views is an exercise in collision management, and a misconfigured view can publish internal hostnames to the public internet with no announcement at all.

Unlisted zones. Subsidiaries, legacy brands and regional trading names often hold zones that appear in no central register. They surface during due diligence only if someone asks the right question of the right person.

Building the ownership map

Produce one row per zone, and resist the temptation to compress. Each row should carry the zone name, its parent delegation, the name servers currently authoritative, the registrar and registry status, DNSSEC signing state, the named accountable owner inside the business, the contract or purchase order that funds the service, and a classification of what the names actually expose.

Two columns deserve particular attention. The first is the accountable owner, which must be a role rather than a person, because people leave during integrations faster than systems do. The second is the contract reference, because a delegation without a matching commercial instrument is an unsupported dependency and should be treated as such in the risk register.

Where a zone is administered by a third party, note the mechanism by which authority could be withdrawn: registrar credentials, registry lock, contractual notice period. Authority you cannot practically reclaim is not authority you hold.

Scoring exposure rather than counting records

A simple weighted score is sufficient, provided it is applied consistently across both estates. Weight most heavily any delegation whose name servers are not controlled by either party. Weight next the absence of a documented owner, then unsigned zones where signing is expected, then split-horizon divergence without a documented reason, then short TTLs on records that will need to change during cutover, since these indicate volatility rather than stability.

The output should be a short list of names that require action before completion, a longer list that can be managed afterwards, and an explicit register of accepted risk signed by someone senior enough to carry it. That register matters later, when a name stops resolving and the question of who knew becomes relevant.

Evidence to request, not describe

Ask for full zone exports rather than screenshots or summaries, and reconcile them against registry data for every domain the target claims to own. Request resolver logs for the internal views, which will show which delegated names are actually in use and which are decorative. Ask specifically about acquisition history: any zone inherited from a previous purchase is a candidate for exactly the failure modes described above.

In the UK, the internal exposure question also carries a regulatory edge. Where an internal view publishes hostnames that map to systems processing personal data, the disclosure becomes an incident with a reporting obligation rather than a hygiene issue, and the assessment is easier to make before completion than during a live investigation.

A cutover sequence that holds

Four disciplines keep the migration from becoming an incident. First, freeze delegation changes across both estates at exchange, with a named approver for exceptions. Second, lower TTLs on records scheduled to change at least a full former-TTL period beforehand. Third, run a dual-authority window for mail before touching anything else, because mail is the dependency that other teams notice first and understand least. Fourth, move federated sign-in paths only after the mail cutover is stable and the identity team has confirmed the metadata endpoints resolve from every network segment that matters.

Retire nothing until the replacement has been observed through a full business cycle, including month-end. Then retire decisively, and record the retirement against the zone row so the map reflects reality rather than intent.

Keep the map alive

The value of this exercise decays quickly. A quarterly re-verification of owners and name server targets costs little and prevents the map from becoming another artefact that was accurate once. Delegation debt is not repaid by a single audit; it is held in check by knowing, at any moment, who is still pointing where.