{"id":3752,"date":"2025-12-30T18:51:05","date_gmt":"2025-12-30T15:51:05","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/domain-security-guide-registry-lock-transfer-lock-and-blocking-unauthorized-changes\/"},"modified":"2026-11-04T21:20:58","modified_gmt":"2026-11-04T18:20:58","slug":"registry-lock-vs-transfer-lock-for-domain-security","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/registry-lock-vs-transfer-lock-for-domain-security\/","title":{"rendered":"Registry Lock vs Transfer Lock: Domain Security"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>When people think about website security, they usually jump straight to <a href=\"https:\/\/www.dchost.com\/ssl\">SSL certificate<\/a>s, WAF rules or hardened servers. But one critical control point is easy to overlook: your domain name. If someone takes control of your domain, they may be able to change its DNS delegation, hijack email delivery and redirect visitors to phishing pages, even while your real infrastructure remains secure. That is why strong <strong>domain security<\/strong> is just as critical as <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> firewalls or application hardening. In this guide, we\u2019ll go deep into <strong>registry lock<\/strong>, <strong>transfer lock<\/strong> and practical protections against unauthorized changes. We\u2019ll explain what each lock really does at the protocol level, how to check its EPP statuses in RDAP or WHOIS data, and how to combine them with operational best practices so that both your marketing team and your security team can sleep well. The focus is protecting domain control independently of the infrastructure behind it: hosting, VPS, <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s or colocation.<\/p>\n<div id=\"toc_container\" role=\"navigation\" aria-label=\"Table of Contents\" data-nosnippet class=\"toc_transparent no_bullets toc_numbered toc_title_center\"><p class=\"toc_title\">\u0130\u00e7indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_Your_Domain_Can_Be_a_Single_Point_of_Failure\"><span class=\"toc_number toc_depth_1\">1.<\/span> Why Your Domain Can Be a Single Point of Failure<\/a><\/li><li><a href=\"#Understanding_Domain_Statuses_Where_Locks_Actually_Live\"><span class=\"toc_number toc_depth_1\">2.<\/span> Understanding Domain Statuses: Where Locks Actually Live<\/a><\/li><li><a href=\"#What_Is_Transfer_Lock_Registrar_Lock_and_How_Does_It_Work\"><span class=\"toc_number toc_depth_1\">3.<\/span> What Is Transfer Lock (Registrar Lock) and How Does It Work?<\/a><ul><li><a href=\"#The_Basics\"><span class=\"toc_number toc_depth_2\">3.1.<\/span> The Basics<\/a><\/li><li><a href=\"#Checking_Transfer_Lock_in_RDAP_or_WHOIS\"><span class=\"toc_number toc_depth_2\">3.2.<\/span> Checking Transfer Lock in RDAP or WHOIS<\/a><\/li><li><a href=\"#What_Transfer_Lock_Does_Not_Protect_Against\"><span class=\"toc_number toc_depth_2\">3.3.<\/span> What Transfer Lock Does Not Protect Against<\/a><\/li><\/ul><\/li><li><a href=\"#What_Is_Registry_Lock_and_Why_Its_Much_Harder_to_Bypass\"><span class=\"toc_number toc_depth_1\">4.<\/span> What Is Registry Lock and Why It\u2019s Much Harder to Bypass<\/a><ul><li><a href=\"#Registry_vs_Registrar_Who_Holds_the_Keys\"><span class=\"toc_number toc_depth_2\">4.1.<\/span> Registry vs Registrar: Who Holds the Keys?<\/a><\/li><li><a href=\"#Typical_Operations_Blocked_by_Registry_Lock\"><span class=\"toc_number toc_depth_2\">4.2.<\/span> Typical Operations Blocked by Registry Lock<\/a><\/li><li><a href=\"#How_Registry_Lock_Appears_in_Registration_Data\"><span class=\"toc_number toc_depth_2\">4.3.<\/span> How Registry Lock Appears in Registration Data<\/a><\/li><li><a href=\"#When_Is_Registry_Lock_Overkill\"><span class=\"toc_number toc_depth_2\">4.4.<\/span> When Is Registry Lock Overkill?<\/a><\/li><\/ul><\/li><li><a href=\"#Preventing_Unauthorized_DNS_and_Contact_Changes\"><span class=\"toc_number toc_depth_1\">5.<\/span> Preventing Unauthorized DNS and Contact Changes<\/a><ul><li><a href=\"#1_Harden_Your_Registrar_Account\"><span class=\"toc_number toc_depth_2\">5.1.<\/span> 1. Harden Your Registrar Account<\/a><\/li><li><a href=\"#2_Protect_the_Email_Addresses_That_Control_Your_Domain\"><span class=\"toc_number toc_depth_2\">5.2.<\/span> 2. Protect the Email Addresses That Control Your Domain<\/a><\/li><li><a href=\"#3_Restrict_Who_Can_Touch_Domains_and_DNS\"><span class=\"toc_number toc_depth_2\">5.3.<\/span> 3. Restrict Who Can Touch Domains and DNS<\/a><\/li><li><a href=\"#4_Monitor_Domain_Status_and_DNS_Changes\"><span class=\"toc_number toc_depth_2\">5.4.<\/span> 4. Monitor Domain Status and DNS Changes<\/a><\/li><li><a href=\"#5_Understand_What_Your_DNS_Records_Actually_Do\"><span class=\"toc_number toc_depth_2\">5.5.<\/span> 5. Understand What Your DNS Records Actually Do<\/a><\/li><\/ul><\/li><li><a href=\"#Putting_It_Together_A_Practical_Domain_Security_Playbook\"><span class=\"toc_number toc_depth_1\">6.<\/span> Putting It Together: A Practical Domain Security Playbook<\/a><ul><li><a href=\"#Step_1_Classify_Your_Domains_by_Criticality\"><span class=\"toc_number toc_depth_2\">6.1.<\/span> Step 1: Classify Your Domains by Criticality<\/a><\/li><li><a href=\"#Step_2_Enable_Locks_and_DNSSEC\"><span class=\"toc_number toc_depth_2\">6.2.<\/span> Step 2: Enable Locks and DNSSEC<\/a><\/li><li><a href=\"#Step_3_Clean_Up_Access_and_Credentials\"><span class=\"toc_number toc_depth_2\">6.3.<\/span> Step 3: Clean Up Access and Credentials<\/a><\/li><li><a href=\"#Step_4_Document_a_Change-Request_Workflow\"><span class=\"toc_number toc_depth_2\">6.4.<\/span> Step 4: Document a Change-Request Workflow<\/a><\/li><li><a href=\"#Step_5_Test_Your_Recovery_Plan\"><span class=\"toc_number toc_depth_2\">6.5.<\/span> Step 5: Test Your Recovery Plan<\/a><\/li><\/ul><\/li><li><a href=\"#Common_Vulnerabilities_and_How_Locks_Help_or_Dont\"><span class=\"toc_number toc_depth_1\">7.<\/span> Common Vulnerabilities and How Locks Help (or Don\u2019t)<\/a><ul><li><a href=\"#Scenario_1_Phishing_the_Domain_Admin\"><span class=\"toc_number toc_depth_2\">7.1.<\/span> Scenario 1: Phishing the Domain Admin<\/a><\/li><li><a href=\"#Scenario_2_Compromised_Email_Account\"><span class=\"toc_number toc_depth_2\">7.2.<\/span> Scenario 2: Compromised Email Account<\/a><\/li><li><a href=\"#Scenario_3_Insider_or_Former_Employee\"><span class=\"toc_number toc_depth_2\">7.3.<\/span> Scenario 3: Insider or Former Employee<\/a><\/li><\/ul><\/li><li><a href=\"#Integrating_Domain_Security_With_Your_Hosting_Strategy\"><span class=\"toc_number toc_depth_1\">8.<\/span> Integrating Domain Security With Your Hosting Strategy<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_Your_Domain_Can_Be_a_Single_Point_of_Failure\">Why Your Domain Can Be a Single Point of Failure<\/span><\/h2>\n<p>Your domain is the front door key to everything that sits behind it: web servers, email, APIs, admin panels, even VPN or remote desktop endpoints. A strong VPS firewall still protects the server, but it cannot stop an attacker with domain control from redirecting visitors to a different IP.<\/p>\n<p>Consider a team that invests in SSL\/TLS, backups and WAF rules but leaves its registrar account with a weak password, no 2FA and no locks enabled. If a phishing email succeeds in compromising that account, an attacker may be able to:<\/p>\n<ul>\n<li>Change nameservers to redirect web traffic to a malicious server.<\/li>\n<li>Modify MX records, if DNS access is also compromised, to intercept incoming email, potentially including password resets.<\/li>\n<li>Transfer the domain to a different registrar, making recovery more difficult.<\/li>\n<\/ul>\n<p>If you want a broader overview of the whole picture (DNSSEC, WHOIS privacy and account 2FA), you can also read our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/domain-security-locks-dnssec-privacy-2fa\/\">Domain Security Best Practices: Registrar Lock, DNSSEC, Whois Privacy and 2FA<\/a>. In this post, we\u2019ll zoom in specifically on <strong>registry lock<\/strong>, <strong>transfer lock<\/strong> and preventing unauthorized changes to DNS and contact data.<\/p>\n<h2><span id=\"Understanding_Domain_Statuses_Where_Locks_Actually_Live\">Understanding Domain Statuses: Where Locks Actually Live<\/span><\/h2>\n<p>To understand registry lock and transfer lock properly, it helps to know how domains are represented at the protocol level. Almost all generic TLDs (like .com, .net, .org) and many new gTLDs use the <strong>EPP (Extensible Provisioning Protocol)<\/strong> between registrars and registries. In EPP, every domain has one or more <strong>statuses<\/strong> that control what operations are allowed.<\/p>\n<p>Security-related prohibitions use two prefixes:<\/p>\n<ul>\n<li><strong>Client-side statuses<\/strong> (prefixed with <code>client<\/code>): Set by your <strong>registrar<\/strong>. Example: <code>clientTransferProhibited<\/code>.<\/li>\n<li><strong>Server-side statuses<\/strong> (prefixed with <code>server<\/code>): Set by the <strong>registry<\/strong> directly (the operator of the TLD). Example: <code>serverTransferProhibited<\/code>.<\/li>\n<\/ul>\n<p>Common security-related EPP statuses you can check through RDAP, WHOIS where available, or registrar panels include:<\/p>\n<ul>\n<li><strong>clientTransferProhibited<\/strong> \u2013 transfer lock at registrar level (usually called Registrar Lock or Transfer Lock).<\/li>\n<li><strong>serverTransferProhibited<\/strong> \u2013 transfer block at registry level (may be part of a registry lock service).<\/li>\n<li><strong>clientUpdateProhibited<\/strong> \u2013 prevents updates to the domain by client (registrar).<\/li>\n<li><strong>serverUpdateProhibited<\/strong> \u2013 prevents updates at registry level.<\/li>\n<li><strong>clientDeleteProhibited<\/strong> \/ <strong>serverDeleteProhibited<\/strong> \u2013 block deletion of the domain.<\/li>\n<\/ul>\n<p>When you see both client and server variants together (for example <code>clientTransferProhibited<\/code> and <code>serverTransferProhibited<\/code>), it effectively means both your registrar and the registry itself are refusing to allow that operation. These flags describe restrictions; they do not by themselves confirm enrollment in a <strong>registry lock<\/strong> service or its verification procedures.<\/p>\n<h2><span id=\"What_Is_Transfer_Lock_Registrar_Lock_and_How_Does_It_Work\">What Is Transfer Lock (Registrar Lock) and How Does It Work?<\/span><\/h2>\n<h3><span id=\"The_Basics\">The Basics<\/span><\/h3>\n<p><strong>Transfer lock<\/strong> \u2013 often called <strong>Registrar Lock<\/strong> \u2013 is the most common domain security setting. At the EPP level, this is usually the status <code>clientTransferProhibited<\/code>. It is controlled by the registrar and is often exposed in control panels as a simple on\/off toggle like \u201cDomain lock: Enabled\u201d.<\/p>\n<p>When transfer lock is enabled:<\/p>\n<ul>\n<li>Your domain cannot be transferred to another registrar using a standard EPP code (AuthInfo\/EPP key).<\/li>\n<li>Any transfer request will be rejected while the status remains active.<\/li>\n<\/ul>\n<p>When transfer lock is disabled:<\/p>\n<ul>\n<li>The domain may become transferable to another registrar if no other transfer restrictions apply and the applicable authorization and transfer-policy requirements are met.<\/li>\n<li>Attackers who have gained access to your registrar account may be able to unlock it and initiate an unauthorized transfer.<\/li>\n<\/ul>\n<p>We explain the transfer flow and EPP code details step-by-step in our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/domain-transfer-epp-codes-locks-dns\/\">How to Transfer a Domain Without Downtime: EPP Code, Transfer Lock, and a Smooth Migration Plan<\/a>. Here, the key takeaway is simple: <strong>transfer lock should be enabled by default, always<\/strong>, and only disabled briefly for planned, authorized transfers.<\/p>\n<h3><span id=\"Checking_Transfer_Lock_in_RDAP_or_WHOIS\">Checking Transfer Lock in RDAP or WHOIS<\/span><\/h3>\n<p>Check your domain\u2019s registration-data status using RDAP for gTLDs, or WHOIS where available. A WHOIS response for a domain with a registrar transfer lock may contain a line similar to:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">Status: clientTransferProhibited https:\/\/icann.org\/epp#clientTransferProhibited\n<\/code><\/pre>\n<p>If this status is missing, do not assume the domain is transferable: a registry-side prohibition or other restriction may still apply. Review the lock settings with your registrar and enable the available registrar transfer lock unless you are preparing an authorized transfer.<\/p>\n<h3><span id=\"What_Transfer_Lock_Does_Not_Protect_Against\">What Transfer Lock Does <em>Not<\/em> Protect Against<\/span><\/h3>\n<p>Transfer lock is powerful, but limited. It usually <strong>does not<\/strong> prevent:<\/p>\n<ul>\n<li>Changes to nameservers (NS records) at the registrar level.<\/li>\n<li>Changes to DNS records if you\u2019re using the registrar\u2019s DNS service.<\/li>\n<li>Changes to contact information (registrant\/admin email, address, etc.).<\/li>\n<li>Deletion of the domain (unless delete-prohibited flags are set separately).<\/li>\n<\/ul>\n<p>That means a transfer lock alone does not stop an attacker with registrar access\u2014and DNS panel access where needed\u2014from attempting to:<\/p>\n<ul>\n<li>Point your nameservers to their own DNS.<\/li>\n<li>Modify A, MX, TXT and other records if they have DNS panel access.<\/li>\n<li>Change contact email to take over future verification and reset flows.<\/li>\n<\/ul>\n<p>To protect against these scenarios, you need more than just a transfer lock.<\/p>\n<h2><span id=\"What_Is_Registry_Lock_and_Why_Its_Much_Harder_to_Bypass\">What Is Registry Lock and Why It\u2019s Much Harder to Bypass<\/span><\/h2>\n<h3><span id=\"Registry_vs_Registrar_Who_Holds_the_Keys\">Registry vs Registrar: Who Holds the Keys?<\/span><\/h3>\n<p>A <strong>registry lock<\/strong> adds protection at the <strong>registry<\/strong> (TLD operator) level, rather than relying only on registrar controls. Availability and procedures vary by registry and registrar. These services can:<\/p>\n<ul>\n<li>Set one or more <strong>server-side EPP statuses<\/strong>, such as <code>serverTransferProhibited<\/code>, <code>serverUpdateProhibited<\/code> and <code>serverDeleteProhibited<\/code>.<\/li>\n<li>Require out-of-band, high-assurance procedures to change or remove (manual verification, security tokens, phone callbacks, pre-approved contacts, etc.).<\/li>\n<\/ul>\n<p>While a registrar lock can be toggled from your control panel, a registry lock usually <strong>cannot be changed by simply logging into the account<\/strong>. That\u2019s the main security benefit: operations covered by the lock should require the registry\u2019s additional unlock process, rather than registrar login credentials alone. The protection depends on which operations are locked and how that process is secured.<\/p>\n<h3><span id=\"Typical_Operations_Blocked_by_Registry_Lock\">Typical Operations Blocked by Registry Lock<\/span><\/h3>\n<p>A well-configured registry lock often protects against:<\/p>\n<ul>\n<li><strong>Unauthorized transfers<\/strong> \u2013 a server-side transfer prohibition blocks registrar transfers; a client-side prohibition may also be set.<\/li>\n<li><strong>Unauthorized DNS changes at the registry level<\/strong> \u2013 nameserver updates can be blocked. This does not lock A, MX or other records in the existing DNS provider\u2019s zone.<\/li>\n<li><strong>Unauthorized deletions<\/strong> \u2013 serverDeleteProhibited blocks delete operations.<\/li>\n<li>Sometimes <strong>contact changes<\/strong> or other updates may require manual approval as well.<\/li>\n<\/ul>\n<p>For high-value domains (brand primary .com, key ccTLDs, critical SaaS platform domains), evaluate registry lock based on the impact of compromise, availability and the approval process for changes.<\/p>\n<h3><span id=\"How_Registry_Lock_Appears_in_Registration_Data\">How Registry Lock Appears in Registration Data<\/span><\/h3>\n<p>Check registration data through RDAP, or WHOIS where available. Registry-lock restrictions are represented by server-side statuses; the EPP names below may be displayed with spaces in RDAP tools:<\/p>\n<ul>\n<li><code>serverTransferProhibited<\/code><\/li>\n<li><code>serverUpdateProhibited<\/code><\/li>\n<li><code>serverDeleteProhibited<\/code><\/li>\n<\/ul>\n<p>You may also see the client-side equivalents, indicating restrictions at both registrar and registry levels. These statuses restrict the corresponding operations, not just unauthorized requests. Confirm registry-lock enrollment and its unlock procedure with your registrar; statuses alone do not establish the approval process.<\/p>\n<h3><span id=\"When_Is_Registry_Lock_Overkill\">When Is Registry Lock Overkill?<\/span><\/h3>\n<p>Registry lock usually comes with additional cost and operational friction. You typically need to:<\/p>\n<ul>\n<li>Submit change requests through verified contacts or support channels.<\/li>\n<li>Wait for manual approval for updates that would otherwise be one-click.<\/li>\n<\/ul>\n<p>For secondary project domains, test environments, or marketing campaign domains that need frequent registry-level updates, this can slow your team down. Editing records within an existing DNS zone is distinct from changing the registry&#8217;s nameserver delegation. We generally recommend:<\/p>\n<ul>\n<li>Use <strong>transfer lock + strong operational security<\/strong> for normal domains.<\/li>\n<li>Reserve <strong>registry lock<\/strong> for domains where a compromise would have serious financial, legal or brand impact.<\/li>\n<\/ul>\n<h2><span id=\"Preventing_Unauthorized_DNS_and_Contact_Changes\">Preventing Unauthorized DNS and Contact Changes<\/span><\/h2>\n<p>Even with transfer and registry locks, protect the <strong>registrar account<\/strong>, DNS-provider accounts and connected email inboxes. Think of your domain management like root access on a production server: tightly controlled, monitored and audited.<\/p>\n<h3><span id=\"1_Harden_Your_Registrar_Account\">1. Harden Your Registrar Account<\/span><\/h3>\n<p>At a minimum, you should:<\/p>\n<ul>\n<li><strong>Use a strong, unique password<\/strong> generated by a password manager.<\/li>\n<li><strong>Enable 2FA<\/strong> (preferably TOTP or hardware keys, not just SMS if you can avoid it).<\/li>\n<li><strong>Restrict login email<\/strong> to a well-protected mailbox, ideally on an internal or hardened domain.<\/li>\n<li><strong>Audit authorized users<\/strong> and remove old or unused logins regularly.<\/li>\n<\/ul>\n<p>Password reuse and weak account protections create avoidable risks. Keep registrar credentials unique, protect the devices and browser profiles that can access them, and require 2FA.<\/p>\n<h3><span id=\"2_Protect_the_Email_Addresses_That_Control_Your_Domain\">2. Protect the Email Addresses That Control Your Domain<\/span><\/h3>\n<p>Email inboxes may receive password-reset links, change confirmations and security alerts. Review which addresses your registrar uses and what additional approvals it requires. Depending on those controls, an attacker who hijacks the mailbox used for your registrar login or registrant contact may be able to:<\/p>\n<ul>\n<li>Reset your registrar password.<\/li>\n<li>Approve transfers or contact changes without touching your actual infrastructure.<\/li>\n<\/ul>\n<p>Make sure these inboxes:<\/p>\n<ul>\n<li>Use strong passwords and 2FA.<\/li>\n<li>Are hosted on a platform you control and understand.<\/li>\n<li>Use a domain with properly configured SPF, DKIM and DMARC to help receivers identify unauthorized use of that domain in email. These controls do not secure mailbox logins or stop all phishing. (If you need a refresher, see our guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/spf-dkim-dmarc-cpanel-vps-setup\/\">SPF, DKIM and DMARC Explained for cPanel and VPS Email<\/a>.)<\/li>\n<\/ul>\n<h3><span id=\"3_Restrict_Who_Can_Touch_Domains_and_DNS\">3. Restrict Who Can Touch Domains and DNS<\/span><\/h3>\n<p>In many organizations, \u201cwhoever handles websites\u201d has full access to domains, DNS, hosting and email. That might be one person today and completely different a year from now. From a security perspective, that\u2019s too much power in too many hands.<\/p>\n<p>Instead, aim for:<\/p>\n<ul>\n<li><strong>Clear separation<\/strong> between people who manage domains \/ DNS and people who manage application code.<\/li>\n<li><strong>Per-user logins<\/strong> instead of shared credentials; choose management interfaces that support individual access and appropriate permissions.<\/li>\n<li>Documented <strong>change workflows<\/strong>: who can request, approve and implement DNS or domain changes.<\/li>\n<\/ul>\n<p>If you\u2019re an agency managing many client domains, we also recommend reading <a href=\"https:\/\/www.dchost.com\/blog\/en\/dns-and-domain-access-management-for-agencies\/\">DNS and Domain Access Management for Agencies<\/a> for a more structured way to assign permissions and avoid risky shared accounts.<\/p>\n<h3><span id=\"4_Monitor_Domain_Status_and_DNS_Changes\">4. Monitor Domain Status and DNS Changes<\/span><\/h3>\n<p>You can\u2019t react to attacks you don\u2019t see. For critical domains, set up:<\/p>\n<ul>\n<li><strong>Domain status monitoring<\/strong>: periodic RDAP checks, or WHOIS where available, to detect changes to lock-related statuses.<\/li>\n<li><strong>DNS monitoring<\/strong>: detect unexpected changes to NS, A, MX, TXT or CNAME records.<\/li>\n<li><strong>Uptime monitoring<\/strong>: availability checks can alert you if a DNS change makes the monitored service unavailable, but may miss redirection to a working unauthorized endpoint. Our guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/website-uptime-monitoring-and-alerting-guide-for-small-businesses\/\">Website Uptime Monitoring and Alerting Guide for Small Businesses<\/a> covers practical options.<\/li>\n<\/ul>\n<p>For large portfolios, domain monitoring can be integrated into your general infrastructure observability stack, alongside VPS metrics and application logs.<\/p>\n<h3><span id=\"5_Understand_What_Your_DNS_Records_Actually_Do\">5. Understand What Your DNS Records Actually Do<\/span><\/h3>\n<p>Unauthorized changes can go unnoticed if nobody recognises that a new TXT or CNAME record is suspicious. Spend time educating your team about common DNS record types and their impact. Our guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/common-dns-record-mistakes\/\">DNS Records Explained Like a Friend: A, AAAA, CNAME, MX, TXT, SRV, CAA<\/a> is a good starting point.<\/p>\n<p>Understanding that MX changes can redirect incoming email, and that CAA records identify certificate authorities authorized to issue certificates for your domain, makes it easier to spot malicious or mistaken changes. CAA changes do not revoke existing certificates.<\/p>\n<h2><span id=\"Putting_It_Together_A_Practical_Domain_Security_Playbook\">Putting It Together: A Practical Domain Security Playbook<\/span><\/h2>\n<p>Let\u2019s turn all of this into a clear, repeatable process you can apply across your domains.<\/p>\n<h3><span id=\"Step_1_Classify_Your_Domains_by_Criticality\">Step 1: Classify Your Domains by Criticality<\/span><\/h3>\n<p>Not every domain needs the same additional controls. Classify domains by the actual impact of compromise; the examples below are starting points, not fixed assignments:<\/p>\n<ul>\n<li><strong>Tier 1 \u2013 Business critical<\/strong>: primary brand domain, production SaaS domains, main email domain.<\/li>\n<li><strong>Tier 2 \u2013 Important<\/strong>: regional\/country versions, key campaign domains, support portals.<\/li>\n<li><strong>Tier 3 \u2013 Low risk<\/strong>: test\/staging domains, experimental projects or parked names only where compromise would have limited impact and no sensitive dependencies.<\/li>\n<\/ul>\n<p>For each tier, define a minimum security level:<\/p>\n<ul>\n<li><strong>Tier 1<\/strong>: registry lock where supported by the registry and registrar + transfer lock + DNSSEC where supported + 2FA + strict access control + monitoring.<\/li>\n<li><strong>Tier 2<\/strong>: transfer lock + DNSSEC where supported + 2FA + good operational hygiene.<\/li>\n<li><strong>Tier 3<\/strong>: transfer lock + unique passwords + 2FA + protected recovery accounts.<\/li>\n<\/ul>\n<h3><span id=\"Step_2_Enable_Locks_and_DNSSEC\">Step 2: Enable Locks and DNSSEC<\/span><\/h3>\n<p>For each domain:<\/p>\n<ul>\n<li>Verify transfer lock (<code>clientTransferProhibited<\/code>) is enabled.<\/li>\n<li>For Tier 1 domains, evaluate and enable <strong>registry lock<\/strong> if your registry and registrar support it, with a documented unlock and relock process.<\/li>\n<li>Enable <strong>DNSSEC<\/strong> where your DNS stack supports it, with correctly signed records and a valid chain of trust to the validating resolver\u2019s trusted anchor. For those records, validation can detect forged or altered answers; signing alone does not protect a resolution path that does not validate. DNSSEC does not secure registrar accounts or approve DNS-management changes: a malicious change accepted and signed by the authoritative provider can still validate. If you\u2019re new to DNSSEC, see our practical setup guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/what-is-dnssec-and-when-should-you-enable-it-a-practical-setup-guide\/\">What Is DNSSEC and When Should You Enable It?<\/a><\/li>\n<\/ul>\n<p>After registrar or registry changes, check lock-related registration statuses through RDAP, or WHOIS where available; confirm registry-lock enrollment and its unlock procedure with the registrar. Verify DNSSEC separately: query the authoritative parent zone for the published DS record and match its parameters and digest to the child zone\u2019s DNSKEY set. Then use a DNSSEC-validating resolver or diagnostic tool to validate the DS\/DNSKEY\/RRSIG chain from a trusted anchor to the records you rely on.<\/p>\n<p>A DS entry in a registration lookup, or a DS record by itself, does not prove that validation succeeds. Record the validation result; do not treat an insecure, bogus or indeterminate result as secure. For a domain intended to validate as secure, investigate missing or mismatched DS data, key changes and invalid or expired signatures.<\/p>\n<h3><span id=\"Step_3_Clean_Up_Access_and_Credentials\">Step 3: Clean Up Access and Credentials<\/span><\/h3>\n<p>Across your organization (or agency):<\/p>\n<ul>\n<li>Eliminate shared \u201cinfo@\u201d logins for domain management where possible.<\/li>\n<li>Use management tools that support <strong>individual accounts<\/strong> with separate permissions per user or team.<\/li>\n<li>Ensure every account has <strong>2FA enabled<\/strong> and credentials stored in a password manager.<\/li>\n<li>After staff changes, revoke departed users\u2019 access, rotate credentials they could retain and verify recovery email addresses.<\/li>\n<\/ul>\n<h3><span id=\"Step_4_Document_a_Change-Request_Workflow\">Step 4: Document a Change-Request Workflow<\/span><\/h3>\n<p>For Tier 1 and Tier 2 domains, define a simple but strict process for:<\/p>\n<ul>\n<li>Who can <strong>request<\/strong> a change (for example, product owner or marketing lead).<\/li>\n<li>Who must <strong>approve<\/strong> the change (for example, technical lead or security owner).<\/li>\n<li>Who actually <strong>implements<\/strong> the change (for example, your designated internal administrator or an authorized service provider).<\/li>\n<\/ul>\n<p>For critical changes, require approval by someone other than the implementer and restrict access so that the approval cannot simply be bypassed. Recording a request alone does not prevent one person from making an unauthorized change.<\/p>\n<h3><span id=\"Step_5_Test_Your_Recovery_Plan\">Step 5: Test Your Recovery Plan<\/span><\/h3>\n<p>Assume that at some point, something will go wrong: a compromised account, a social engineering attempt, or a misconfigured DNS change. You should know in advance:<\/p>\n<ul>\n<li>How quickly you can <strong>revert DNS changes<\/strong> or restore previous zone versions.<\/li>\n<li>Who you contact at your registrar or hosting provider in case of domain compromise.<\/li>\n<li>How to <strong>prove ownership<\/strong> (invoices, company docs, registry contacts) if an attacker has changed contact data.<\/li>\n<\/ul>\n<p>Combine this with a wider disaster recovery plan that also covers website files, databases and email. If you need to design that broader plan, we recommend our guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/rpo-rto-backup-strategies-for-blogs-ecommerce-and-saas\/\">How to Design a Backup Strategy: RPO\/RTO and Hosting\u2011Side Best Practices<\/a> for the backup and restore side.<\/p>\n<h2><span id=\"Common_Vulnerabilities_and_How_Locks_Help_or_Dont\">Common Vulnerabilities and How Locks Help (or Don\u2019t)<\/span><\/h2>\n<h3><span id=\"Scenario_1_Phishing_the_Domain_Admin\">Scenario 1: Phishing the Domain Admin<\/span><\/h3>\n<p>An attacker sends a well-crafted email that looks like a renewal or policy update from the registrar. The domain admin clicks, logs into a fake panel and hands over credentials. The attacker then attempts to log in to the real registrar account; success depends on any additional authentication checks.<\/p>\n<p><strong>What happens next depends on your setup:<\/strong><\/p>\n<ul>\n<li>With only transfer lock: attacker may still change nameservers, DNS records and contacts.<\/li>\n<li>With registry lock: covered transfers, deletions and nameserver updates require removal of the relevant registry restrictions through the registry\u2019s verification process. Confirm the scope and unlock procedure for your TLD and registrar; this does not lock records in your DNS hosting account.<\/li>\n<li>With account 2FA: a stolen password alone is generally insufficient, but phishing may also capture codes or sessions. Prefer phishing-resistant authentication where supported.<\/li>\n<\/ul>\n<h3><span id=\"Scenario_2_Compromised_Email_Account\">Scenario 2: Compromised Email Account<\/span><\/h3>\n<p>The mailbox used as registrar login or registrant contact is compromised. The attacker requests a password reset from the registrar. If the registrar\u2019s recovery process allows access using that mailbox alone, the attacker can take over the domain account and attempt to modify records.<\/p>\n<p>Mitigations:<\/p>\n<ul>\n<li>Use a <strong>separate, locked-down mailbox<\/strong> for domain operations, with MFA and protected recovery methods. After a compromise, revoke unauthorized sessions and review recovery settings and forwarding rules.<\/li>\n<li>Use <strong>DMARC<\/strong> to help receivers detect unauthorized use of your domain in the visible From address, and good spam filtering to reduce malicious inbound mail. Neither restores control of an already compromised mailbox.<\/li>\n<li>Where available, use <strong>registry lock<\/strong> for Tier 1 domains and confirm which operations require additional verification. Ensure that verification does not rely solely on the same mailbox.<\/li>\n<\/ul>\n<h3><span id=\"Scenario_3_Insider_or_Former_Employee\">Scenario 3: Insider or Former Employee<\/span><\/h3>\n<p>A former contractor or employee still knows the shared registrar password or has their own account left active. They modify DNS or unlock domains as retaliation or by mistake.<\/p>\n<p>Mitigations:<\/p>\n<ul>\n<li>End shared accounts; move to <strong>per-user access<\/strong> with clear offboarding procedures.<\/li>\n<li>For high-value domains, <strong>registry lock<\/strong> plus an enforced internal approval workflow can reduce unilateral changes to covered registry operations; separately restrict access to DNS records.<\/li>\n<li>Regular <strong>audits of access lists<\/strong> and login history.<\/li>\n<\/ul>\n<h2><span id=\"Integrating_Domain_Security_With_Your_Hosting_Strategy\">Integrating Domain Security With Your Hosting Strategy<\/span><\/h2>\n<p>Domain security and hosting security need coordinated planning, whether you use one provider or several. Your operational plan should aim to:<\/p>\n<ul>\n<li>Align domain locks and DNSSEC with your actual server and application architecture.<\/li>\n<li>Coordinate domain\/DNS changes with planned server migrations or new deployments.<\/li>\n<li>Implement consistent access control policies across domains, DNS, hosting panels and VPS servers.<\/li>\n<\/ul>\n<p>Whether you run a single business website or a portfolio of brands and SaaS products, include these tasks in your domain security review:<\/p>\n<ul>\n<li>Review the current EPP statuses and lock configuration of your domains.<\/li>\n<li>Design a realistic classification of critical vs secondary domains.<\/li>\n<li>Implement DNSSEC and secure nameserver setups, and evaluate registry lock where supported by your TLD and registrar.<\/li>\n<\/ul>\n<p>Strong domain security isn\u2019t about never changing anything. It\u2019s about making necessary changes while <strong>reducing<\/strong> opportunities for attackers and operational mistakes. By combining <strong>transfer lock<\/strong>, <strong>registry lock<\/strong>, careful access management and clear operational playbooks, you can turn your domains from a silent risk into a quiet, reliable foundation for everything else you build. Start by reviewing the locks and statuses on your key domains and documenting who can authorize changes.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Learn how registrar transfer locks differ from registry locks, what their EPP statuses reveal, and why DNS accounts and change approvals need separate protection.<\/p>\n","protected":false},"author":1,"featured_media":12862,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[184],"tags":[],"class_list":["post-3752","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3752","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=3752"}],"version-history":[{"count":6,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3752\/revisions"}],"predecessor-version":[{"id":12864,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3752\/revisions\/12864"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/12862"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3752"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3752"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3752"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}