Domain and DNS Management Policy Template: Registrar Locks, Record Changes and Renewals Controlled

Domains and DNS records decide where your email, websites and login pages actually go, yet in many organisations they are held in a personal registrar account, renewed on someone's credit card and changed without a ticket. This template gives you numbered policy statements for domain ownership, registrar account security, registrar and registry locks, DNS record changes, renewals, dangling records and monitoring. It draws on the CISA Emergency Directive 19-01 actions, ICANN's EPP status codes and expiry rules, and NCSC guidance on managing public domain names, and it maps each section to ISO/IEC 27001:2022, NIST CSF 2.0 and NIST SP 800-53. It is written for security, network and IT leaders who need a policy they can adopt and defend to an auditor. For the technical background on how registrars, registries and DNS hosts fit together, read the Registrar and Authoritative DNS Security Guide; this page is the policy document.

How to use this template

• Replace text in square brackets, such as [Organisation], [Domain owner] and [30 days], with your own roles and values. Bracketed values are illustrative, not regulatory requirements.
• "Must" is mandatory; "should" is recommended practice where a documented deviation is acceptable.
• Keep the policy short and stable. Put provider-specific detail (registrar portal steps, DNS host API settings, change templates) in a supporting DNS operations procedure.
• Classify your domains first using the tiers below, because lock, MFA and change rules scale with the tier.
• Use this policy with the Change Management Policy Template and the Asset Management Policy Template, so DNS changes and the domain register follow the same governance as other assets.

Domain tiers

1. Purpose

This policy sets the requirements for registering, owning, configuring, renewing and retiring the internet domain names and public DNS records used by [Organisation]. Its aim is to prevent domain hijacking, unauthorised record changes, accidental expiry and takeover of abandoned records, any of which can redirect email, web traffic or authentication to an attacker, in line with [Organisation]'s [Information Security Policy].

2. Scope

This policy applies to:

• All domain names registered by or for [Organisation], its subsidiaries and brands, including defensive and parked domains, whichever registrar holds them.
• All authoritative DNS zones for those domains, whether hosted by the registrar, a managed DNS provider, a cloud provider or [Organisation]'s own name servers.
• Accounts, API tokens and service accounts that can change registrations, name server delegations, DNSSEC settings or DNS records.
• Third parties, such as agencies, hosting companies and marketing platforms, that register or operate domains on [Organisation]'s behalf.

Internal DNS and recursive resolvers are covered by the [Network Security Standard]. The policy applies to all staff, contractors and suppliers who manage in-scope domains or records.

3. Roles and responsibilities

4. Policy statements

4.1 Ownership and inventory

• All domains must be registered in the name of [Organisation legal entity], never an individual employee, agency or hosting company.
• Registrant, administrative and technical contacts must use role-based mailboxes on a domain [Organisation] controls (for example [domains@organisation]), never personal or free webmail addresses. The contact mailbox must not depend solely on the domain it recovers.
• [Domain management team] must maintain a domain register recording, for each domain: tier, registrar, account, DNS host, expiry date, lock status, DNSSEC status, business owner, services using it and cost centre.
• New domains must be requested through [request process] and registered only through approved registrars. Domains found outside the register must be transferred into an approved account or retired within [60 days].
• Proof-of-ownership documents (registration records, invoices, trademark evidence) must be stored by [Legal] to support recovery if a domain is hijacked.

4.2 Registrar and DNS provider requirements

• Registrars and DNS providers must support multi-factor authentication for every account, role-based access with separate user logins, an audit log of account and record changes, and scoped API credentials.
• For Tier 1 domains the registrar should offer registry lock, where the registry supports it, with an out-of-band verification process for unlocking.
• [Procurement] must confirm each provider's documented process for recovering a hijacked domain and for urgent support out of hours.
• The number of registrars should be kept to the minimum needed. See the Corporate Domain Registrar buyer's guide for evaluation criteria.

4.3 Account and credential security

• Every person with access to a registrar or DNS provider account must have a named individual login. Shared logins are prohibited.
• Multi-factor authentication must be enforced on all registrar and DNS provider accounts. Phishing-resistant methods (FIDO2 security keys or passkeys) must be used for accounts that can change Tier 1 domains; SMS must not be used. See the Phishing-Resistant MFA Guide.
• At least [two] and no more than [five] named people must hold administrative rights for each registrar account, so access survives staff absence without becoming widespread.
• API tokens and service accounts used by automation (infrastructure-as-code, ACME certificate clients, CDN integrations) must be scoped to the zones and record types they need, stored in [approved secrets manager], have an owner, and be rotated at least [every 90 days] and when the owner leaves. See the API Key Management Guide.
• Access must be reviewed [quarterly] and removed on the day a person leaves or changes role, under the [Joiners, Movers and Leavers procedure].
• Transfer authorisation codes must be requested only when a transfer is approved and must be treated as secrets.

4.4 Registrar and registry locks

• All domains must carry the registrar transfer lock (EPP status clientTransferProhibited). Tier 1 and Tier 2 domains must also carry clientUpdateProhibited and clientDeleteProhibited.
• Tier 1 domains must use registry lock (server statuses such as serverTransferProhibited, serverUpdateProhibited and serverDeleteProhibited) where the registry offers it.
• Removing any lock is a change that must be approved under section 4.5, time-limited to the approved work, and reapplied immediately afterwards.
• Lock status must be checked automatically against the domain register at least [weekly], using registration data (RDAP or WHOIS).

4.5 DNS record and delegation changes

• All changes to records, name server delegations, glue records and DNSSEC settings must go through [change management system] with a requester, reviewer and rollback plan.
• Changes to NS records, DS records, MX records and records for identity, login and payment services are high-risk and require [Security] approval.
• Zones should be managed as code in [repository] with peer review, so every change is versioned and can be reverted.
• Record time-to-live (TTL) values should be lowered before planned migrations and restored afterwards; TTLs on critical records must not be set so long that a malicious change cannot be reversed quickly, or so short that resolvers are overloaded.
• Tier 1 zones must publish CAA records restricting certificate issuance to [approved certificate authorities], and email domains must publish SPF, DKIM and DMARC records. See the Email Authentication Checklist.
• DNSSEC should be enabled for Tier 1 zones where the registry and DNS host support it, with key rollover procedures documented. See the DNSSEC Deployment Guide.

4.6 Renewals and expiry

• Auto-renew must be enabled on every domain [Organisation] intends to keep, paid with an organisation-maintained payment method, not a personal card.
• [Domain management team] must review all domains expiring in the next [90 days] each month and confirm renewal or deliberate retirement.
• Registrar renewal notices must go to a monitored role mailbox. ICANN's expiry rules require registrars to send reminders before and shortly after expiry, but [Organisation] must not rely on those notices alone.
• A domain that has entered its grace or redemption period must be treated as an incident and restored the same day.

4.7 Retirement and dangling records

• When a service, cloud resource or SaaS tenant is retired, its DNS records (CNAME, A, AAAA, NS delegations, MX and TXT verification records) must be removed in the same change that decommissions the service.
• [DNS operations] must scan all zones at least [monthly] for records pointing to deprovisioned cloud resources, unclaimed third-party services or expired external domains, and remove them within [5 working days]. See the Subdomain Takeover and Dangling DNS Guide.
• Domains no longer needed must be reviewed before lapse: domains that have carried email, login or customer traffic should be kept as defensive registrations for at least [2 years] rather than released. See the Domain Without Email guide for protecting parked domains.

4.8 Monitoring and response

• Registrar and DNS provider audit logs must be forwarded to [SIEM] where the provider supports it, and reviewed for logins from new locations, user or token changes, lock removals and contact changes.
• [Security operations] must monitor NS, MX and critical service records from outside the network and alert on any change not linked to an approved ticket.
• Certificate transparency logs must be monitored for certificates issued for [Organisation] domains that were not requested. See the Certificate Transparency Monitoring Guide for Web Teams.
• Suspected hijacking or unauthorised record changes must be handled under the [Incident Response Plan] using the DNS Hijack Playbook and Domain Registrar Compromise Playbook.

4.9 Third parties

• Agencies and suppliers must not register domains for [Organisation] in their own name. Existing registrations held by third parties must be transferred to [Organisation] accounts.
• Where a supplier hosts DNS for [Organisation], the contract must require MFA, change logging, notification of security incidents within [24 hours] and return of zone data on exit.

5. Exceptions

• Exceptions must be requested by the domain's business owner, recorded in [risk register] with the reason, compensating controls and an expiry date of no more than [12 months], and approved by [CISO].
• No exception may be granted for MFA on accounts that can change Tier 1 domains, or for registering domains in an individual's name.

See the Security Exceptions and Risk Acceptance Guide for an approval workflow.

6. Compliance and monitoring

Non-compliance may lead to access being removed and to action under [disciplinary procedure]. Compliance will be checked by [internal audit] at least [annually].

7. Review and approval

• Policy owner: [CISO]. Approved by: [risk committee / executive board] on [date].
• Review at least annually, and after any domain or DNS incident, a change of registrar or DNS provider, or an acquisition that adds domains.
• Version history: [version], [date], [summary of change], [approver].
• Related documents: [Information Security Policy], [Change Management Policy], [Asset Management Policy], [Privileged Access Management Policy], [Incident Response Plan], [Brand Protection Procedure].

Implementation guidance

Rolling out the policy

1. Build the register: export domain lists from every registrar account you know of, then search invoices, expense claims, certificate transparency logs and DNS references for domains held elsewhere. Acquisitions and marketing campaigns are the usual source of strays.
2. Secure accounts before anything else: follow the four CISA ED 19-01 actions as a baseline: audit records, change passwords on accounts that can change DNS, add MFA, and start certificate transparency monitoring.
3. Consolidate and lock: move domains into approved accounts, apply registrar locks to all and registry lock to Tier 1. Transfers temporarily need the lock removed, so schedule them in approved windows.
4. Move zones to code: import zones into [repository], require pull requests, and test a rollback by reverting a harmless record.
5. Switch on detection: external monitoring of NS and MX, audit log forwarding and a monthly dangling record scan.
6. Drill recovery: run a tabletop of a registrar account takeover, including who calls the registrar, which documents prove ownership and how long a registry unlock takes.

Decisions for small and large organisations

• Small organisations: one registrar with MFA, auto-renew on a company card, transfer lock on every domain and DNS hosted at the registrar or one managed provider. The biggest wins are removing personal accounts and personal email contacts.
• Large organisations: a corporate registrar with registry lock, zones as code with automated drift detection, a domain register linked to the CMDB and a formal defensive registration budget.
• Registrar lock versus registry lock: registrar (client) locks are set and removed by your registrar, so anyone who takes over the registrar account can remove them. Registry (server) locks are set by the registry and take longer to remove, with out-of-band verification, which is why ICANN describes them as extra protection. Use registry lock where an outage of the domain would be a major incident.

Common failure patterns

• Domain in a former employee's account: renewal notices go to a dead mailbox and the domain lapses or cannot be recovered without a dispute.
• Locks removed and never reapplied: a transfer or name server change unlocks the domain and nobody checks afterwards.
• Single shared registrar login: no MFA, no individual audit trail, and the password is in a team chat.
• Retired cloud services leave CNAMEs behind: the record still points to a resource name an attacker can claim.
• Over-scoped DNS API tokens: a certificate automation token that can edit every zone, including NS records.

Framework mapping

The threats this policy addresses map to MITRE ATT&CK T1584.001 Compromise Infrastructure: Domains, T1584.002 Compromise Infrastructure: DNS Server and T1583.001 Acquire Infrastructure: Domains (for lapsed domains re-registered by attackers). For secure DNS deployment detail see the NIST SP 800-81 Rev. 3 Secure DNS Deployment Guide and, for lookalike domains, the Domain Portfolio and Lookalike Domain Management Guide. Sources: CISA ED 19-01: Mitigate DNS Infrastructure Tampering, ICANN: EPP Status Codes, ICANN: Expired Registration Recovery Policy and NCSC: Managing public domain names.

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Registrar and Authoritative DNS Security Guide · DNS Security Guide · Privileged Access Management Policy Template · Change Management Policy Template