Domains and DNS are often critical assets that nobody owns
Consider a hypothetical enterprise that discovers one morning that its website will not load and all customer email is bouncing. Investigation shows that automatic renewal of the primary domain failed at the registrar: the linked credit card had expired, and the expiry reminders went to the mailbox of a colleague who left long ago. Another enterprise found that a contractor adjusting a marketing landing page accidentally deleted a DNS record required by the mail service, and the problem went unnoticed for half a day. What these incidents share is that domains and DNS look like a few lines of configuration, yet they support the website, email, remote access and the verification of many cloud services at once. When something goes wrong, the impact is far wider than for most individual systems.
The third revision of NIST's Secure Domain Name System Deployment Guide, finalized in March 2026, supersedes the second revision from 2013. It makes recommendations for protecting the integrity, availability and confidentiality of DNS services, covering authoritative and recursive servers, DNS security extensions, encrypted DNS, protective DNS and logging. The guide focuses mainly on technical deployment. Building on it, JOTOglobal adds management-level advice: first manage domains as assets with owners, expiry dates and a change process, so that technical hardening has a stable foundation.
Inventory domain assets and protect registrar accounts
The first step is led by the network lead together with marketing, legal and regional IT, listing every domain the enterprise holds: the primary domain, country or regional domains, product and campaign domains, and look-alike domains registered to prevent impersonation. For each domain, record the registrar, expiry date, auto-renewal status, payment method, authoritative DNS provider, business owner and technical owner. The inventory should also mark which domains carry email and which are used for cloud service verification, because when these domains fail, the impact often does not show up on a web page right away. For domains with no remaining business use, the business owner decides whether to keep holding them to prevent squatting or to let them go as planned.
The registrar account is the most powerful entry point in the whole chain. Whoever controls it can change the name servers, which amounts to taking over all DNS resolution. The login email for the registrar account should be a mailbox managed jointly by the team rather than a personal address; the strongest authentication method the registrar supports should be enabled, with at least two administrators holding access; and transfer lock should be enabled where the registrar supports it, to prevent unauthorized transfer of the domain. Payment should use a corporate account, checked by the finance owner before expiry. Expiry reminders go to both the team mailbox and the on-call channel, and key domains can be renewed several years in advance to reduce the risk near expiry. Contact details registered with the registrar should also be checked regularly, so that transfer confirmations and security notices reach current administrators instead of an old address nobody reads.
Bring DNS changes under approval and record-keeping
Changes to DNS records should go through tickets like any other production change. The requester states which record is to be added, modified or deleted, what it is for and which business system it relates to. The approver checks whether the record affects email authentication, certificate validation or other dependencies. Before the change, the current zone file is exported or captured in a screenshot; after the change, the result is confirmed by querying several public resolvers, and the ticket notes the record's cache time so the time needed for the change to take effect or to roll back can be estimated. For teams such as marketing or contractors that need frequent DNS adjustments, a separate subdomain can be delegated to them so they do not work directly on the primary domain. Urgent changes can be made first and ticketed afterwards, but the record must be completed before the end of the shift and the change reviewed by a second administrator.
Accounts on the DNS provider's console also need regular permission reviews, and accounts of people who have left or whose contracts have ended should be disabled promptly. If the provider offers operation logs, export them regularly and compare them with tickets, and ask about any change that has no ticket. For important domains, the enterprise can evaluate enabling DNSSEC signing, but it should first confirm support from the registrar and DNS provider and arrange key rotation and failure-handling steps, so that an expired signature does not itself cause resolution to fail. Any technical hardening should be trialled first on non-critical domains and extended to the primary domain only after confirming that monitoring can detect signing or resolution anomalies.
Acceptance evidence, common mistakes and limits
Acceptance is organized by the network lead. Evidence includes the complete domain inventory with each domain's owner and expiry date; screenshots of the registrar account's sign-in method, administrator list and transfer lock status; the ticket for the most recent DNS change with before-and-after records and public query results; and a reminder drill confirming that expiry reminders actually reach the team mailbox and the on-call channel. One common mistake is to focus only on the primary domain and overlook subdomains and auxiliary domains that email and cloud service verification depend on. Another is to treat the registrar account as a purchasing matter kept by one person, so that after staff changes nobody knows the password or where the linked phone is.
The inventory, account protection and change process in this article are organizational guidance from JOTOglobal. They do not replace the operating instructions of registrars and DNS providers and do not guarantee protection against every domain hijacking or DNS attack. Registration rules, real-name requirements and transfer procedures differ between countries and regions, and the rules of the registry and registrar take precedence. Choices about DNSSEC, encrypted DNS and protective DNS should be assessed against the enterprise's size, technical capability and provider support, and the review frequency for the inventory and how far ahead to renew should be set by each enterprise according to its own business risk.