Domain Governance Baseline Practice guide 02 · Registrar and DNS authority
From baseline to practice · Guide 02

Control the privileged paths that can alter or recover public identity and service routing.

Control registrar and DNS authority.

Establish named, reviewable and recoverable control over domain registration, delegation and authoritative DNS - without relying on shared credentials, personal mailboxes or undocumented console changes.

For technology and risk generalists Eight practical steps Authority-review CSV DNS change-record template
Download authority-review CSV Download DNS change record Open the baseline
Outcome

Authority that is attributable, constrained and recoverable

The organisation should be able to state who can renew or transfer a domain, change delegation, alter authoritative DNS, approve those actions and recover control if normal administrators are unavailable. Those answers should be supported by current access records, provider evidence and a usable change trail.

Scope

Map the authority paths, not only the provider names

Registrar and DNS control is usually distributed across several accounts, roles and support paths. A provider name in the domain register is a starting point; this guide records who can exercise authority and how control is recovered.

Registration authority

Can renew, transfer or alter registration details and may expose transfer credentials or lock settings.

Delegation authority

Can change authoritative nameservers and, where used, DNSSEC delegation information at the registrar or registry boundary.

DNS authority

Can create, change or delete records that route websites, email, identity, APIs and other services.

Recovery authority

Can regain control through provider support, recovery contacts, secondary administrators, codes or documented escalation.

Do not confuse a supplier relationship with an access model. One account may control many domains, while a single domain may depend on a registrar, reseller, DNS provider, identity provider, API token and emergency support process. Record each material authority boundary.
Method

Establish control in eight practical steps

  1. 1

    Start from the domain register

    For each material domain, confirm the registrar or reseller, authoritative DNS provider and any separately delegated zones. Group domains that share the same provider account or authority boundary.

  2. 2

    Name accountability, approval and administration

    Record the accountable owner for the authority boundary, who approves privileged access or material changes, and the named people or supplier identities that perform administration.

  3. 3

    Replace shared and personal access

    Use named administrator accounts and organisational email identities wherever the provider supports them. Treat a shared login or personal mailbox as an exception requiring an owner, rationale and removal plan.

  4. 4

    Enforce MFA and constrain privilege

    Enable MFA on every available administrative path, apply the least privilege the platform supports, restrict API tokens to their required scope and avoid giving routine users transfer or account-owner authority.

  5. 5

    Make recovery organisational

    Use a monitored role mailbox, maintain a second viable administrator or support path, store recovery codes in an approved enterprise vault and record provider account identifiers and emergency contacts.

  6. 6

    Apply transfer and deletion protections

    Confirm registrar transfer locks and other available protections. Consider stronger registry-level locking for critical domains where proportionate. Protect transfer credentials and require deliberate approval before unlocking or deleting authority.

  7. 7

    Make DNS change recoverable

    Use the organisation's existing change process to record the current state, exact change, approval, validation and rollback. Preserve provider audit logs and a recoverable copy of material zone state before high-impact changes.

  8. 8

    Review, revoke and test

    Review privileged authority at least every six months - more frequently for essential services - and immediately after staff, supplier or platform changes. Test a critical recovery path rather than assuming provider support will work under pressure.

Authority record

Record enough to govern access and recovery

Use one row for each material registrar, reseller, DNS account or separately governed zone boundary. The CSV is an access-governance companion to the domain register, not a duplicate domain inventory.

Authority boundary
A clear name for the provider account, tenant or delegated zone being governed.
Authority type
Registrar, reseller, DNS provider, delegated zone or another material control boundary.
Domains or zones covered
The material domains and zones controlled through this boundary.
Provider and account identifier
The provider plus the tenant, customer or account identifier needed for support and recovery.
Accountable owner
The organisational role answerable for continued authority and access governance.
Named privileged administrators
The named internal or supplier identities with administrative access.
Access model or role
The roles used, privilege boundaries and any shared or supplier-managed exception.
MFA status
Enforced, partial, unavailable or unknown, including material limitations.
Recovery contact and secondary path
The monitored contact plus the independent administrator, codes or support path available if primary access fails.
Lock or protection status
Transfer, registry, deletion or provider protections that materially constrain authority.
Audit or change-record location
Where access reviews, provider audit logs and DNS change records are retained.
Last reviewed
The date named access, recovery and protection settings were last confirmed.
Next review
The scheduled date for the next privileged-access and recovery review.
Exception or next action
The specific unresolved gap, exception owner and action required.
Portable authority record

Review access without creating another platform

The blank CSV can be maintained in an approved spreadsheet, access-review system, CMDB or control repository. The worked example illustrates registrar, DNS and supplier-operated boundaries using reserved example domains.

Blank authority CSV Worked example CSV
Recoverable change

Use a complete record for material DNS changes

Do not create a separate DNS workflow if the organisation already has an ITSM, engineering or change process. Add the fields below to that process so a change can be attributed, validated and reversed.

Domain, zone and records
The exact authority boundary and records affected.
Reason and service impact
Why the change is required and which services or users may be affected.
Requester, approver and implementer
Distinct accountable identities where the risk and operating model require separation.
Current state captured
The pre-change values, zone export or other evidence needed to restore the prior state.
Planned change
The exact additions, removals or modifications, including relevant TTL considerations.
Dependencies and risk
Email, identity, application, supplier and sequencing considerations.
Validation
How technical resolution and the affected service will be checked after implementation.
Rollback
The exact restoration action, responsible person and conditions that trigger reversal.
Emergency designation
Whether the normal approval path was shortened and how retrospective review will occur.
Completion and outcome
Implementation time, evidence, deviations, incidents and final status.
Copy into existing change control

DNS change-record template

A plain Markdown template that can be pasted into an ITSM ticket, engineering issue, change record or incident follow-up. It contains no workflow logic or external connection.

Download Markdown template
Evidence and cadence

Know when authority is genuinely controlled

Evidence of practice

  • A current authority record covers material registrar, reseller and DNS boundaries.
  • Privileged administrators are named and MFA status is evidenced.
  • Recovery does not depend on one person or a personal mailbox.
  • Transfer, deletion and other material protection settings are known.
  • Recent DNS changes include approval, pre-change state, validation and rollback.
  • Provider audit logs or equivalent evidence can be retrieved.
  • A critical access or recovery path has been tested.

Review it when

  • The scheduled six-monthly or more frequent access review falls due.
  • An administrator, owner, supplier or recovery contact changes.
  • A registrar, reseller or DNS migration is planned or completed.
  • A domain, DNS, identity or email incident occurs.
  • API keys, service accounts or automation paths are introduced.
  • A critical domain is unlocked, transferred, delegated or placed into retirement.
  • The annual recovery exercise for essential authority falls due.
Common failure modes

Strong providers do not compensate for weak authority governance

One shared registrar login

Nobody can attribute access, offboarding is unreliable and the credential becomes a single point of failure.

One administrator can do everything

Routine DNS work, account recovery and domain transfer authority sit with one person and one authentication path.

A personal mailbox controls recovery

The organisation may lose authority when a staff member or supplier leaves, changes role or becomes unavailable.

MFA covers only the obvious console

Reseller portals, support resets, API tokens and secondary accounts remain weaker paths to the same authority.

Locks are assumed, not verified

Transfer or deletion protection is believed to exist but is not recorded, reviewed or understood by the accountable owner.

Service accounts have no owner

Automation tokens can alter DNS but are absent from access reviews, over-privileged or never rotated.

Console changes leave no usable record

The provider audit log may show that something changed without capturing why, approval, dependencies or rollback.

Recovery exists only on paper

Support numbers, account identifiers, codes or zone exports are missing or have never been tested during a controlled exercise.

Return to the baseline

Authority control should make three answers demonstrably stronger

Revisit the questions about registrar access, authoritative DNS providers and recoverable DNS change. The organisation should now be able to name the authority boundaries, show who holds access, evidence how changes are controlled and demonstrate how control would be recovered.

Return to the baseline Review guide 01 Back to practical guidance