{"id":3752,"date":"2025-12-30T18:52:38","date_gmt":"2025-12-30T15:52:38","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/domain-security-guide-registry-lock-transfer-lock-and-blocking-unauthorized-changes\/"},"modified":"2025-12-30T18:52:38","modified_gmt":"2025-12-30T15:52:38","slug":"domain-security-guide-registry-lock-transfer-lock-and-blocking-unauthorized-changes","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/domain-security-guide-registry-lock-transfer-lock-and-blocking-unauthorized-changes\/","title":{"rendered":"Domain Security Guide: Registry Lock, Transfer Lock and Blocking Unauthorized Changes"},"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 there is one tiny element that quietly controls everything: your domain name. If someone takes control of your domain, they can move your DNS, hijack your email, point your traffic to phishing pages and completely disconnect your real infrastructure in minutes. 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 it appears in WHOIS\/EPP statuses, and how to combine them with operational best practices so that both your marketing team and your security team can sleep well. As dchost.com, we manage domains, hosting, VPS, <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s and colocation every day, so we\u2019ll focus on what actually works in production rather than theoretical checklists.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_Domain_Security_Is_a_Single_Point_of_Failure\"><span class=\"toc_number toc_depth_1\">1<\/span> Why Domain Security Is 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=\"#How_Transfer_Lock_Appears_in_WHOIS\"><span class=\"toc_number toc_depth_2\">3.2<\/span> How Transfer Lock Appears in 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_WHOIS\"><span class=\"toc_number toc_depth_2\">4.3<\/span> How Registry Lock Appears in WHOIS<\/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=\"#How_dchostcom_Fits_Into_a_Strong_Domain_Security_Strategy\"><span class=\"toc_number toc_depth_1\">8<\/span> How dchost.com Fits Into a Strong Domain Security Strategy<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_Domain_Security_Is_a_Single_Point_of_Failure\">Why Domain Security Is 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 is useless if an attacker moves your domain to a different IP.<\/p>\n<p>In client security reviews we regularly see the same pattern: teams spend time on SSL\/TLS, backups and WAF rules, but their domain registrar account has a weak password, no 2FA and no locks enabled. From there, a phishing mail to the person who \u201conly manages domains\u201d is enough to:<\/p>\n<ul>\n<li>Change nameservers and redirect all web traffic to a malicious server.<\/li>\n<li>Modify MX records to receive all email for your domain, including password resets.<\/li>\n<li>Transfer the domain to a different registrar, cutting you off from any quick recovery.<\/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\/alan-adi-guvenligi-rehberi-registrar-lock-dnssec-whois-gizliligi-ve-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>These statuses fall into two big categories:<\/p>\n<ul>\n<li><strong>Client-side statuses<\/strong> (prefixed with <code>client<\/code>): Set by your <strong>registrar<\/strong> (for example, dchost.com). 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 statuses you\u2019ll see in WHOIS 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 (one part of a registry lock package).<\/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. That is where <strong>registry lock<\/strong> comes in.<\/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 becomes transferable to another registrar, assuming you also provide the EPP code and meet ICANN&#039;s transfer policies.<\/li>\n<li>Attackers who have gained access to your registrar account may unlock and transfer the domain away very quickly.<\/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\/alan-adi-transferi-nasil-yapilir-epp-kodu-transfer-kilidi-ve-kesintisiz-gecise-sakin-bir-rehber\/\">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=\"How_Transfer_Lock_Appears_in_WHOIS\">How Transfer Lock Appears in WHOIS<\/span><\/h3>\n<p>You can verify whether your domain is transfer-locked by looking at the WHOIS output. You should see 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, your domain is likely transferable. In that case, log into your domain panel (for example at dchost.com if your domain is with us) and switch on the lock immediately.<\/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 if an attacker compromises your registrar account, they might not be able to transfer the domain out, but they can still:<\/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> is a much stronger protection, implemented at the <strong>registry<\/strong> (TLD operator) level, not just the registrar. Most registry locks:<\/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: even if an attacker fully compromises your registrar login, they cannot change critical aspects of the domain without also passing the registry\u2019s additional verification process.<\/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 both client and server transfer-prohibited statuses are set.<\/li>\n<li><strong>Unauthorized DNS changes at the registry level<\/strong> \u2013 nameserver updates are blocked.<\/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), registry lock is often considered a must. We regularly see it as a hard requirement in security audits and even in some cyber-insurance policies.<\/p>\n<h3><span id=\"How_Registry_Lock_Appears_in_WHOIS\">How Registry Lock Appears in WHOIS<\/span><\/h3>\n<p>When a domain has registry lock, WHOIS usually shows one or more of these statuses:<\/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 might also still see the client-side equivalents, which means both registrar and registry are aligned on blocking unauthorized changes.<\/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 change often, this can slow your team down. 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, your main attack surface remains the <strong>registrar account<\/strong> and any 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>Many domain incidents start from password reuse or weak 2FA. If the same person who logs into social media also holds your registrar password in their browser, you have a problem.<\/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>Most registrars and ICANN policies rely on <strong>email verification<\/strong> for critical operations: domain contact changes, transfer approvals, security alerts. If an attacker hijacks the mailbox used for your registrar login or registrant contact, they can:<\/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>Have proper SPF, DKIM and DMARC to reduce phishing and spoofing risk. (If you need a refresher, see our guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/spf-dkim-ve-dmarc-nedir-ozel-alan-adi-ile-e-posta-dogrulamasini-cpanel-ve-vpste-sifirdan-kurmak\/\">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 for your dchost.com panel or any other management interface.<\/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\/ajanslar-icin-dns-ve-alan-adi-erisimi-yonetimi\/\">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 WHOIS\/status checks to ensure locks remain enabled.<\/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>: even if DNS changes slip through, availability checks will alert you. Our guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/web-sitesi-uptime-izleme-ve-alarm-kurma-rehberi\/\">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>Many unauthorized changes go unnoticed simply because 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\/dns-kayitlari-adan-zye-a-aaaa-cname-mx-txt-srv-caa-ve-sizi-yakan-o-kucuk-hatalar\/\">DNS Records Explained Like a Friend: A, AAAA, CNAME, MX, TXT, SRV, CAA<\/a> is a good starting point.<\/p>\n<p>Once everyone understands that modifying MX records hands your email to someone else, or that CAA records control who can issue SSL for your domain, it becomes easier to spot malicious or mistaken changes early.<\/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, especially those hosted and managed via dchost.com.<\/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 deserves the same level of protection. Start by listing your domains and classifying them as:<\/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, parked names.<\/li>\n<\/ul>\n<p>For each tier, define a minimum security level:<\/p>\n<ul>\n<li><strong>Tier 1<\/strong>: registry lock + transfer lock + DNSSEC + strict access control + monitoring.<\/li>\n<li><strong>Tier 2<\/strong>: transfer lock + DNSSEC + 2FA + good operational hygiene.<\/li>\n<li><strong>Tier 3<\/strong>: transfer lock + basic account security.<\/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 available for your TLD.<\/li>\n<li>Enable <strong>DNSSEC<\/strong> where your DNS stack supports it, to prevent DNS spoofing and cache poisoning. If you\u2019re new to DNSSEC, see our practical setup guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/dnssec-nedir-ne-ise-yarar-alan-adiniz-ve-hostinginiz-icin-adim-adim-dnssec-kurulum-rehberi\/\">What Is DNSSEC and When Should You Enable It?<\/a><\/li>\n<\/ul>\n<p>Make a habit of checking WHOIS after each change to confirm the correct statuses and DS records are in place.<\/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>Move to <strong>individual accounts<\/strong> in your dchost.com panel 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>Rotate passwords and verify recovery email addresses after staff changes.<\/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, infrastructure team at dchost.com or your internal admin).<\/li>\n<\/ul>\n<p>Even a minimal two-step workflow (\u201crequest + implement\u201d) drastically reduces the risk of one person accidentally or maliciously changing something critical.<\/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\/yedekleme-stratejisi-nasil-planlanir-blog-e-ticaret-ve-saas-siteleri-icin-rpo-rto-rehberi\/\">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 logs in to the real registrar account.<\/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: attacker cannot transfer, delete, or change nameservers without triggering manual verification with the registry.<\/li>\n<li>With strong account 2FA: phishing is harder; even with password, attacker cannot log in.<\/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, takes over the domain account and starts modifying records.<\/p>\n<p>Mitigations:<\/p>\n<ul>\n<li>Use a <strong>separate, locked-down mailbox<\/strong> for domain operations.<\/li>\n<li>Enable <strong>DMARC and good spam filtering<\/strong> to reduce phishing and spam noise.<\/li>\n<li>Use <strong>registry lock<\/strong> for Tier 1 domains so transfers and critical updates require out-of-band checks.<\/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 internal approval workflow make unilateral actions almost impossible.<\/li>\n<li>Regular <strong>audits of access lists<\/strong> and login history.<\/li>\n<\/ul>\n<h2><span id=\"How_dchostcom_Fits_Into_a_Strong_Domain_Security_Strategy\">How dchost.com Fits Into a Strong Domain Security Strategy<\/span><\/h2>\n<p>At dchost.com we see domain, hosting, VPS, dedicated and colocation infrastructure as one integrated stack. Domain security is not an afterthought; it\u2019s where everything else starts. When you manage your domains with us alongside hosting, it becomes easier 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, we can help you:<\/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, secure nameserver setups and, where appropriate, registry lock options.<\/li>\n<\/ul>\n<p>Strong domain security isn\u2019t about never changing anything. It\u2019s about being able to change what you need, when you need it, <strong>without<\/strong> giving attackers or accidents an opening. 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. If you\u2019re ready to tighten that foundation, review the locks and statuses on your key domains today, and feel free to reach out to our team at dchost.com for a domain and hosting architecture that takes security seriously from day one.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>When people think about website security, they usually jump straight to SSL certificates, WAF rules or hardened servers. But there is one tiny element that quietly controls everything: your domain name. If someone takes control of your domain, they can move your DNS, hijack your email, point your traffic to phishing pages and completely disconnect [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3753,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-3752","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_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":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3752\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3753"}],"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}]}}