Domain Hijacking Prevention: Registrar Locks, DNSSEC, CAA, and Expiration Risks
https://vulnify.app/blog/domain-hijacking-prevention-registrar-locks-dnssec-caa-expiration

Learn how registrar locks, MFA, renewal controls, DNSSEC, CAA, and DNS change management work together to reduce domain hijacking and domain takeover risk.

A website can have secure application code, strong authentication, current software, and a valid TLS certificate and still fail catastrophically if the organization loses control of its domain. The domain name sits above much of the public web stack. It points users to the website, routes email, delegates DNS, and influences which certificate authorities may issue certificates for the name. If that control is stolen or allowed to expire, the impact can extend far beyond a temporary website outage. Domain hijacking is therefore not just an administrative problem for the person who manages renewals. It is a security problem that belongs in the same risk program as vulnerability scanning, access control, patching, and monitoring. The strongest approach combines registrar account security, transfer protection, renewal discipline, DNSSEC, DNS change control, and certificate issuance policy. What domain hijacking actually means Domain hijacking broadly describes an unauthorized change that causes the legitimate registrant to lose effective control of a domain or its critical configuration. The exact incident can take several forms. An attacker may transfer the domain to another registrar, alter nameservers, change DNS records, compromise the registrar account, manipulate recovery channels, or exploit weak organizational processes around ownership and renewal. Not every DNS incident is domain hijacking. A compromised DNS provider account, for example, can allow malicious record changes while the registrant still owns the domain at the registrar. From the victim's perspective, however, the consequences can look similar: users are redirected, email can be disrupted, and public services may point at infrastructure the attacker controls. That is why domain security should be evaluated as a chain rather than a single setting: Registry and registrar status: who controls the registration and whether transfer protections are active. Registrar account: who can log in, recover the account, change contacts, or alter nameservers. DNS hosting: who can change the zone and whether privileged changes are monitored. DNSSEC: whether resolvers can validate the authenticity and integrity of signed DNS data. Certificate issuance policy: whether CAA limits which public certificate authorities may issue for the domain. Renewal: whether the domain can expire because of failed payment, stale contact information, or operational neglect. Start with live registration data Before hardening anything, establish the current state. Registration information is increasingly exposed through RDAP, the structured successor to traditional WHOIS for many top-level domains. Security-relevant registration data can include registrar information, status flags, lifecycle events, and DNSSEC delegation state. Vulnify's WHOIS / RDAP Domain Lookup is built for this first check. It reviews live registry RDAP data for expiration and renewal risk, transfer and hold status, and DNSSEC delegation signals. Treat the result as an external verification of what the registry is reporting, then compare it with the settings inside your registrar account. Some country-code registries and other operators may expose less lifecycle data than others. If an expiration date is missing from RDAP, that is not evidence that the domain does not expire. Confirm the renewal date directly with the registrar and maintain your own ownership records. Registrar locks reduce unauthorized transfer risk ICANN describes domain locking as a mechanism used to protect against unauthorized changes or transfers. One common Extensible Provisioning Protocol status is clientTransferProhibited . When this status is active, an inter-registrar transfer cannot proceed normally until the lock is removed through the registrar's authorized process. A transfer lock is an important control, but it is not a magic shield. If an attacker has full access to the registrar account, they may be able to remove the lock unless the registrar has stronger out-of-band protections. The lock is most effective when combined with strong account authentication and tight administrative access. For high-value domains, some registries and registrars offer stronger registry-lock services that require additional verification before certain changes can be completed. Availability and implementation vary, so organizations with high-impact names should ask their registrar what enhanced locking options exist rather than assuming the standard client lock is the strongest available protection. Protect the registrar account itself The registrar account is a privileged security account. Treat it more like a production cloud administrator than a routine billing login. Enable MFA using the strongest method the registrar supports. Use a unique password stored in an approved password manager. Limit administrative users and remove former employees or vendors promptly. Use a monitored corporate recovery address rather than a personal mailbox. Keep recovery phone numbers and backup methods current. Turn on change, login, transfer, and renewal notifications where available. Document who is authorized to unlock, transfer, or change nameservers. If the registrar supports role separation, avoid giving every user full domain-transfer privileges. Least privilege matters here for the same reason it matters in cloud platforms: routine administration should not automatically include the power to move a critical asset. Domain expiration is a security risk, not just a billing risk Many domain incidents begin with something less dramatic than a sophisticated intrusion: a renewal fails. Payment cards expire, employees leave, billing emails go to abandoned inboxes, or a domain portfolio grows without a clear owner. Once a domain enters expiration and deletion lifecycles, the organization may face service disruption and eventually the possibility that another party can register the name. Expiration can affect more than the website. Depending on DNS and mail configuration, email can stop resolving or later point somewhere unintended. Password-reset emails, vendor verification messages, and customer communications can all become part of the impact. Reduce renewal risk by using several independent controls: Enable auto-renew for production domains. Keep the payment method current and monitored. Maintain an internal domain inventory with business owner and renewal date. Create calendar or ticketing reminders well before expiration. Route registrar notifications to a shared, monitored security or infrastructure mailbox. Review domains after mergers, rebrands, migrations, and staff changes. Do not rely on a single email reminder from the registrar as your entire renewal process. DNS control is part of domain control The registrar decides where the domain is delegated, while the authoritative DNS provider controls the records beneath that delegation. A domain can remain registered to the correct organization while a compromised DNS account redirects the website or alters mail routing. Review the published zone with Vulnify's DNS Record Lookup . It inventories common record types including A, AAAA, MX, NS, TXT, SOA, and CAA and helps highlight issues such as stale routing, nameserver redundancy gaps, or policy records that do not match the intended architecture. Operational controls matter as much as the records themselves. Protect DNS-provider accounts with MFA, restrict who can edit production zones, log changes, and require review for high-impact changes such as nameservers, MX, apex records, authentication records, or CAA. What DNSSEC does and does not do DNS was not originally designed to provide cryptographic proof that an answer came from the legitimate zone owner. DNSSEC adds data-origin authentication and integrity protection for DNS data by using digital signatures and a chain of trust. A validating resolver can use that chain to detect forged or modified signed DNS answers. This matters because DNS spoofing and cache-poisoning attacks attempt to make resolvers accept fraudulent answers. When DNSSEC is correctly deployed and validation is performed, forged signed data should fail validation rather than silently being accepted as authentic. DNSSEC has important limits. It does not encrypt DNS queries or provide confidentiality. It does not stop an attacker who has legitimately compromised the registrar or authoritative DNS account from publishing malicious but correctly signed records. It also does not replace TLS, account security, or monitoring. DNSSEC solves a specific authenticity and integrity problem in DNS. Deployment also requires care. The chain between the parent zone and your signed zone depends on Delegation Signer records. Bad key rotation or broken DS data can make a correctly hosted site appear unreachable to validating resolvers. Plan changes, test them, and confirm validation after DNSSEC updates. CAA limits public certificate-authority authorization Certification Authority Authorization, or CAA, is a DNS record that allows a domain holder to specify which certificate authorities are authorized to issue certificates for the domain. Public CAs check applicable CAA policy as part of certificate issuance requirements. A simple conceptual example is: example.com. CAA 0 issue "ca.example" example.com. CAA 0 issuewild "ca.example" The actual value should name the CA domain specified by the certificate authority you use. Do not copy example values into production. CAA can reduce the chance of unintended certificate issuance, but it is not a guarantee that certificates can never be mis-issued. RFC 8659 explicitly frames conformance with CAA as necessary but not sufficient for issuance. CAA also does not protect a private key that has already been stolen, and it does not repair a compromised registrar or DNS account. Use Vulnify's CAA Record Analyzer to review effective certificate-authority policy, including parent-domain inheritance and common issue , issuewild , and iodef handling. Then compare the result with the CAs your organization actually uses. TLS still needs separate validation Registrar locks, DNSSEC, and CAA protect different parts of the chain. None of them tells you whether the currently deployed HTTPS certificate is valid, correctly chained, or close to expiration. After reviewing domain controls, verify the live HTTPS endpoint separately. Vulnify's SSL Checker can be used for focused certificate and TLS review. This is especially useful after DNS migrations, CDN changes, certificate renewals, or provider switches, where ownership may be correct but the deployed endpoint can still be misconfigured. Common domain security mistakes Mistake 1: The domain is owned by an employee Critical business domains should be registered under an account controlled by the organization, not a founder's forgotten personal email, a contractor, or an agency account that the company cannot independently access. Document legal ownership, account ownership, registrar, DNS provider, billing owner, and recovery contacts. Mistake 2: Auto-renew is enabled, so nobody monitors expiration Auto-renew reduces risk but can still fail because of payment or account problems. Keep independent reminders and review renewal state periodically. Mistake 3: DNSSEC is treated as a universal anti-hijacking control DNSSEC authenticates DNS data. It does not stop an authorized account from changing the zone maliciously after compromise. Protect the control plane as well as the protocol. Mistake 4: CAA is configured once and forgotten Certificate providers change. Acquisitions, CDN migrations, and automation platforms may introduce new issuance paths. A stale CAA policy can either block legitimate issuance or fail to represent the organization's intended policy. Review it when certificate architecture changes. Mistake 5: Nameserver changes receive no special scrutiny Changing authoritative nameservers can effectively hand control of the entire DNS zone to a different provider. Treat nameserver changes as high-risk changes that require verification and logging. Domain hijacking prevention checklist Confirm the organization controls the registrar account and recovery channels. Enable strong MFA on registrar and DNS-provider accounts. Keep clientTransferProhibited enabled except during authorized transfers. Ask about stronger registry-lock options for high-value domains. Enable auto-renew and maintain independent expiration reminders. Use a current shared mailbox for ownership, billing, and security notices. Inventory authoritative nameservers and DNS-provider administrators. Log and review high-impact DNS changes. Deploy DNSSEC where operationally appropriate and verify the chain after changes. Publish CAA records that match the public CAs you actually use. Validate the live TLS certificate separately from registration controls. Review RDAP status, DNS, CAA, and TLS after migrations and ownership changes. A practical quarterly domain-security review A short recurring review is more useful than a one-time hardening project. Start with the WHOIS / RDAP Domain Lookup and compare registrar, expiration, transfer-lock, hold, and DNSSEC signals against your asset inventory. Investigate unexpected status changes immediately. Next run the DNS Record Lookup to compare the public zone with intended web, mail, and nameserver configuration. Review the CAA Record Analyzer whenever certificate providers or CDN architecture changes. Finally, validate HTTPS with the SSL Checker and consider a broader Website Security Scanner assessment for the application layer. This layered workflow matters because no single tool or record answers the complete question. Registration, DNS, certificate policy, TLS, and application security are separate controls with different failure modes. Conclusion Domain security is foundational. If an attacker can move the domain, replace its nameservers, alter DNS, or exploit a neglected expiration process, many application-level controls can be bypassed operationally rather than technically. The right defense is not one checkbox. It is a chain of ownership, access, protocol, monitoring, and renewal controls. Keep registrar access tightly controlled, maintain transfer locks, treat expiration as a security deadline, deploy DNSSEC for DNS authenticity where appropriate, use CAA to express certificate-authority policy, and verify the public state regularly. Vulnify's domain and infrastructure tools can help you inspect what the outside world currently sees, while the Website Security Scanner can then take the next step into the exposed website and application surface.