Rakirina navê domainê, jehrîkirina DNS, û qefilandina qeydê¶

Wendakirina kontrola navê domaina bingehîn a rêxistina we an devera DNS-ya Desthilatdar yek ji acîliyên dîjîtal ên herî wêranker e ku karsaziyek, nexweşxane, ajansa şaredariyê, an weşanek serhêl dikare êşê bikişîne. Ji ber ku navê domaina we ji bo her pergalê li ser înternetê bingeha pêbaweriyê ye, êrîşkarek ku hesabê qeydkarê domaina we direvîne an tomarên weya DNS-ê jehr dike, tenê malpera we xera nake. Di nav çend hûrdeman de ji guhertina xwe NS (Navserver), A/AAAA (IP-ya malperê), an MX (Mail Exchange) records, the attacker can silently intercept every incoming corporate and customer email, pass automated Let's Encrypt Domain Validation (DV) checks to mint valid TLS/SSL encryption certificates in your name, capture employee Single Sign-On (SSO) passwords, and trigger password-reset emails for your cloud infrastructure, banking portals, and financial accounts. Even an non-malicious failure, such as an expired domain falling into AutoRenewGracePeriod an RedemptionPeriod (clientHold), brings web traffic, API mobile backends, and company email to an instant halt across the globe.

If a domain hijacking or DNS outage compromises hospital patient routing, emergency dispatch communications, public utility telemetry, or an active life-safety system, call your local emergency number (911 li Dewletên Yekbûyî û Kanada, 112 li seranserê Yekîtiya Ewropayê, 999 li Keyaniya Yekbûyî) an bi pelrêça me ya navneteweyî şêwir bikin hejmarên acîl û tîmê xwe yê bersivdana bûyera sîberê ya neteweyî agahdar bikin (wek CISA li Dewletên Yekbûyî li 1-844-SAY-CISA or NCSC in the United Kingdom) immediately. For all commercial, nonprofit, and personal domain crises, execute the triage steps below in exact order.

Vê niha bikin¶

1. ** Di nav 30 saniyan de diyar bikin ka domaina we qediya, tomarên DNS-ya we hatin guhertin, an domain ji qeydkerek biyanî re hate veguheztin **: Zindî bimeşînin RDAP an WHOIS pirsek û pirsek DNS ya desthilatdar ji termînalek (rdap yourdomain.com an whois yourdomain.com, û dig +trace yourdomain.com). Check the Registrar Name, the EPP Status Codes (such as clientHold for billing/verification vs. ok with unfamiliar nameservers), and the Authoritative Nameservers (NS).
2. **Hemû vesazkirinên şîfreya derve tavilê bicemidînin û Pêşkêşvanê Nasnameyê (Okta, Microsoft Entra ID, Google Workspace) tavilê kilît bikin **: Ger êrîşkar domaina we kontrol bike MX records or NS servers, they receive every single email sent to *@yourdomain.com. Immediately instruct your IT administrators to disable "Forgot Password via Email" self-service resets across all corporate tools, revoke active sessions for users whose email addresses might be used to reset external vendor accounts, and switch administrative logins to hardware FIDO2 security keys or internal .onmicrosoft.com fallback domains.
3. Preserve full forensic snapshots of RDAP/WHOIS, DNS zones, and Certificate Transparency (CT) logs before anything changes: Save the output of dig ANY yourdomain.com @8.8.8.8, whois yourdomain.com, and check crt.sh/?q=%25.yourdomain.com immediately. Searching crt.sh reveals every unauthorized SSL/TLS certificate the attacker just minted for your subdomains (mail., vpn., login., api.) so you know exactly which internal services they are actively impersonating via Adversary-in-the-Middle (AitM) proxies.
4. Contact the Losing Registrar's dedicated Emergency Abuse / Security Operations Team (not Tier-1 chat support) to trigger an ICANN Unauthorized Transfer Dispute (IRTP) or Registry Lock reversal: If your domain was pushed to another account at the same registrar or transferred via a stolen Auth-Info (EPP) code to a foreign registrar, contact your original registrar's Domain Abuse / High-Risk Security Escalation Desk and request an immediate Registrar Undo / Emergency Transfer Dispute under the ICANN Transfer Policy (Section I.A û Transfer Dispute Resolution Policy), citing unauthorized credential compromise.
5. Escalate directly to the Top-Level Domain (TLD) Registry Operator if the registrar is unresponsive: Remember the hierarchy: Registrars (like GoDaddy, Namecheap, Cloudflare, MarkMonitor, Network Solutions, Gandi, Porkbun) are simply retail resellers; the Registry Operator (such as Verisign for .com/.net, Public Interest Registry (PIR) for .org, Nominet for .uk, CIRA for .ca, DENIC for .de, or auDA for .au) runs the master root zone database. Country-code (ccTLD) registries and several gTLD registries can place an emergency serverHold an serverUpdateProhibited lock directly at the root level during verified cybercrime incidents.
6. Warn customers, vendors, and banking partners through out-of-band channels that @yourdomain.com email is compromised: If the attacker hijacked your MX records, they will immediately reply to open accounting threads with fake wire transfer instructions. Notify clients via telephone, SMS, LinkedIn, status page on a separate backup domain, or official social media accounts not to trust any email or login portal on the affected domain until restoration is confirmed.

Decision tree: diagnosing and containing a domain or DNS outage¶

Follow this rapid diagnostic flowchart to pinpoint the exact layer of the Domain Name System that has failed or been hijacked:

flowchart TD
    A["Website Down, TLS Certificate Warning, or Corporate Email Halted"] --> B["Run RDAP/WHOIS & dig +trace from External Network"]
    B --> C{"What do RDAP Status & Registrar Fields Show?"}
    C -->|"Status: clientHold, autoRenewPeriod, or redemptionPeriod"| D["Accidental Expiration or ICANN Whois Verification Suspension"]
    D --> E["Log into Registrar Immediately: Pay Renewal / Redemption Fee or Click RAA Verification Link; Request Emergency TTL Flush"]
    C -->|"Registrar Name or Registrant Account Changed Without Authorization"| F["Veguheztina Hesabê Tevahiya Tomar an Veguheztina EPP ya Nerasterast"]
    F --> G["Pêşkêşvanê Nasnameyê kilît bike (Entra/Google), Bilêta Karûbarên Qeydkerê Rewşa Awarte + Nakokiya Veguhastina ICANN, Ji bo Sertîfîkayên Rogue Crt.sh kontrol bikin"]
    C -->|"Registrar & NS Neguherand, lê A / CNAME / MX Tomar Nîşan dide IP-yên Nenas"| H["Lihevkirina Pêşkêşkerê DNS-ê ya Birêvebir (Cloudflare / Route53 / NS1 Mifteya API an Binpêkirina Hesabê)"]
    H --> I["Nîşaneyên API-ya DNS-ê yên têkçûyî betal bikin, Pelê Zona Nas-Baş Vegerînin, Sertîfîkayên TLS yên Rogue betal bikin, Qeydeyên eşkerekirî bizivirînin"]
    C -->|"Tomar, NS, û Tomarên Zonê Normal xuya dikin, lê Malper bi SERVFAIL re têk diçe"| J["Zencîreya Baweriya DNSSEC ya şikestî (Nehevhatina Tomara DS an RRSIG ya qediyayî)"]
    J --> K["DNSViz.net Kontrol bikin: Qeyda Stale DS-ê li Registrar rakin an jî li Mêvandarê DNS Zone ji nû ve îmze bikin."]

Qonaxa 1: Dadweriya teknîkî ji bo destnîşankirina vektora êrîşê ya rastîn¶

Gava ku domainek ji nişka ve çareserkirinê rawestîne an dest bi xizmetkirina rûpelek phishing an xapandina diravê krîptoyê dike, her deqeya ku bi texmînkirinê derbas dibe dema başbûnê ya hêja winda dike. Çar senaryoyên bi tevahî cihêreng hene ku di gerokek webê de ji bikarhênerek dawîn re wekhev xuya dikin, û her yek ji wan rastkirinek bi tevahî cûda hewce dike.

Çawa Bixwîne RDAP, WHOIS, û dig Derketên Wek Bersiva Bûyerê¶

Li Linux, macOS, an Windows-ê termînalek fermanê vekin (WSL an jî bikar bînin nslookup(8.8.8.8 an 1.1.1.1):

1. ** Delegasyona Asta Qeydkirinê kontrol bikin (dig +trace û RDAP)**:

   dig +trace yourdomain.com NS @1.1.1.1
   

   • Li gavê rast li dû serverên root TLD binihêrin (mînak, a.gtld-servers.net. bo .com). Kîjan NS Navên mêvandar (Nameserver) ji hêla Tomara TLD-ê ve têne vegerandin?
   • Ger Registry TLD serverên navên we yên normal vegerîne (ns1.yourdnsprovider.com) bi statûyê NOERROR, revandin ** di hundurê pêşkêşvanê mêvandariya DNS-ya we de çêdibe** (an jî ew têkçûnek DNSSEC e).
   • Ger Tomara TLD serverên navên bi tevahî nenas vedigerîne (an heke whois yourdomain.com nû nîşan dide Registrar: nav û an Updated Date: di nav çend demjimêr an rojên paşîn de), revandin ** li ser asta Tomara Domainê** pêk hat.
2. ** Kodên Rewşa Domainê ya ICANN EPP deşîfre bikin **: Binêre li Domain Status: xetên di te WHOIS an RDAP karûabr. Van kodên Protokola Pêşkêşkirina Berfirehkirî ya standardkirî (EPP) ji we re vedibêjin ka çima domainek têk diçe an girtî ye:

Phase 2: Recovering from a malicious domain hijack or unauthorized registrar transfer¶

Attackers hijack high-value corporate, Web3/DeFi, financial, and media domains using three primary techniques: 1. Registrar Account Takeover (Credential Stuffing, Infostealer Malware, or SIM Swap): The attacker logs into your GoDaddy, Namecheap, Google Domains/Squarespace, or Network Solutions dashboard, turns off clientTransferProhibited, changes the NS records to point to an attacker-controlled Cloudflare account, or generates an Auth-Info (EPP) code to transfer the domain out. 2. Social Engineering of Registrar Support: The attacker submits forged incorporation documents, fake government IDs, or spoofed letterhead to a registrar's account recovery desk claiming the original IT admin died or left the company. 3. Subdomain Takeover (Dangling CNAME / Dangling NS): Your main domain is untouched, but an old subdomain (promo.yourdomain.com an status.yourdomain.com) still has a CNAME record pointing to a decommissioned AWS S3 bucket, Azure App Service, GitHub Pages repo, Heroku app, or Zendesk instance that you deleted months ago. The attacker registers that abandoned cloud resource name on AWS/Azure/GitHub and immediately serves malicious content from your official subdomain.

Step 1: Evict the Attacker from Your Cloud Identity Provider and Email System¶

Before you even finish filling out the registrar recovery form, assume the attacker is actively reading every email sent to your domain and trying to pivot into your internal cloud infrastructure:

1. Switch Microsoft 365 / Google Workspace to Fallback Domains and Hardware MFA:
   • In Microsoft Entra ID (formerly Azure AD), every tenant has a permanent, un-hijackable fallback domain (yourcompany.onmicrosoft.com). Administrators can log in via admin@yourcompany.onmicrosoft.com even if yourdomain.com DNS is completely hijacked.
   • Disable all SMS, voice call, and alternate-email password reset methods in Entra ID / Okta / Google Workspace (Authentication Methods Policy). Require FIDO2/WebAuthn hardware security keys or number-matching Authenticator push notifications.
2. Audit Outbound and Inbound Email Logs for the Exact Compromise Window:
   • Ger we MX tomar di 02:14 UTC de hatin guheztin, ji 02:14 UTC ve sifir e-nameyên derveyî yên rewa gihîştine pêşkêşkerên nameyên we yên rastîn; her yek e-nameya derveyî ya ku di wê pencereyê de ji xebatkarên we re hatî şandin ji hêla servera nameyê ya xapînok (Postfix/Exim guhdar) ve bi tevahî tekstek vekirî hate girtin.
   • Immediately pull a list of every third-party SaaS platform, bank, AWS/GCP root account, GitHub organization, and vendor portal tied to @yourdomain.com email addresses, and check whether the attacker triggered password resets on those external platforms during the hijack window.

Step 2: Execute the Registrar and Registry Emergency Recovery Protocol¶

Do not open a generic "My website isn't working" support chat. You must use the exact regulatory and legal terminology that triggers escalation to the Registrar Tier-3 Security / General Counsel / ICANN Compliance Team:

1. Case A: The Domain Is Still at Your Original Registrar (Account Takeover or Internal "Account Push"):
   • Many attackers do not wait 5 days for an inter-registrar EPP transfer; instead, they use the registrar's instant "Push Domain to Another Account" feature to move your domain into a burner account at the same registrar in 3 seconds.
   • Call and email the registrar's Fraud / Account Hijacking / Abuse Department immediately. State clearly: "URGENT SECURITY INCIDENT: Unauthorized Account Access and Internal Domain Push / DNS Modification of [yourdomain.com]. Requesting immediate freezing of the domain under serverHold/clientUpdateProhibited and rollback of unauthorized DNS/Account changes."
   • Assemble Your Proof of Historical Ownership Packet Right Away: Registrar security teams require incontrovertible proof that you are the legitimate prior registrant before they will pull a domain back from another account. Gather these 5 documents into a single PDF immediately:
     1. Historical Registrar Invoices and Payment Proofs: PDF receipts and credit card / bank wire statements showing your organization paying for the registration and renewal of yourdomain.com over the past 1 to 10 years (including the last 4 digits of the payment card or wire reference).
     2. Government-Issued Corporate Registration & Officer ID: Official Certificate of Incorporation / Articles of Organization matching the historical WHOIS Registrant Organization, plus a government photo ID of the corporate officer signing the affidavit.
     3. Historical DNS Zone File & Server Ownership Proof: Copies of your prior DNS zone file, historical WHOIS snapshots, or proof that your organization owns the autonomous system (ASN) or IP blocks (A records) that the domain pointed to for years prior to today's change.
     4. Original Account Creation Email / Ticket History: Headers of emails received from the registrar at the time the domain was originally registered or renewed.
     5. Official Law Enforcement Report Number: A filed FBI IC3 (ic3.gov) complaint number (United States), Action Fraud reference number (United Kingdom), or national police cybercrime report number. Registrars act dramatically faster when handed a formal law enforcement case number confirming a criminal computer intrusion under 18 U.S.C. § 1030 (CFAA) or the UK Computer Misuse Act 1990.
2. Case B: The Domain Was Transferred Out to a Different Registrar (Inter-Registrar Hijack):
   • Under the ICANN Transfer Policy (formerly IRTP), an inter-registrar transfer requires an Auth-Info (EPP) code and must be blocked for 60 days after certain registrant changes unless waived. If an attacker hacked your account at Registrar A (the "Losing Registrar") and transferred the domain to Registrar B (the "Gaining Registrar"):
   • Contact BOTH the Losing Registrar and the Gaining Registrar immediately, but prioritize the Losing Registrar's Transfer Dispute / Security Team. Under ICANN's Transfer Dispute Resolution Policy (TDRP), the Losing Registrar is the entity that has your historical billing records and login logs proving the transfer was unauthorized. The Losing Registrar can formally contact the Gaining Registrar's compliance officer to execute a cooperative Registrar Transfer Undo, or file a formal TDRP proceeding.
   • Simultaneously send your ownership proof packet and police report to the Gaining Registrar's Abuse Desk demanding that they place an immediate clientTransferProhibited û clientUpdateProhibited lock on the domain so the attacker cannot hop the domain through a chain of three more offshore registrars ("registrar hopping").
3. File an Emergency Escalation with ICANN (for gTLDs like .com, .net, .org, .io if gTLD) or the ccTLD Registry:
   • If a registrar refuses to investigate an unauthorized transfer or fails to respond during an active hijack, submit an urgent Unauthorized Transfer / Domain Hijacking Complaint via the ICANN Contractual Compliance Portal (icann.org/compliance/complaint).
   • If your domain uses a Country-Code Top-Level Domain (ccTLD), such as .uk, .ca, .au, .de, .fr, .nl, .ch, an .jp, you have an even faster option: ccTLD registries are governed by national oversight authorities rather than ICANN and almost always maintain direct Registry Emergency Security Teams (for example, Nominet in the UK at 0330 236 9470, CIRA in Canada, DENIC in Germany, AFNIC in France) that can freeze a hijacked domain directly at the national registry level within hours upon verifying corporate identity.

Phase 3: Rescuing an expired domain (clientHold, RedemptionPeriod, û PendingDelete)¶

Not every sudden global outage is a cyberattack. Every single day, major companies, SaaS startups, and government contractors go completely dark because the credit card on file at their domain registrar expired, and the renewal reminder emails were sent to former-founder@company.com who left the firm three years ago.

Understanding the ICANN Expired Domain Lifecycle Timeline¶

For generic Top-Level Domains (.com, .net, .org, .biz, .info), the ICANN Expired Registration Recovery Policy (ERRP) enforces a strict multi-stage lifecycle after the expiration date passes:

1. Stage 1: Auto-Renew Grace Period (Days 1 to ~30/45 after Expiration):
   • Immediately after expiration (often within 24 to 72 hours), the registrar changes the domain's NS records to a Parked / Expired Renewal Splash Page or places the domain on clientHold.
   • Impact: Your website and corporate email stop working immediately (DNS_PROBE_FINISHED_NXDOMAIN or parking ads).
   • Recovery: Log into the registrar account and pay the standard 1-year renewal fee ($10 to $30 USD). The registrar immediately restores your original NS records.
2. Stage 2: Redemption Grace Period (redemptionPeriod, 30 Days Duration):
   • If no one renews the domain during Stage 1 (usually after day 30 to 42 depending on the registrar's Terms of Service), the registrar deletes the domain at the Registry, and the Registry places it into the mandatory 30-day redemptionPeriod (unless the registrar auctioned the expired domain via an internal expired-domain auction platform like GoDaddy Auctions or NameJet, check your registrar's exact day-30 auction cutoff immediately).
   • Recovery: You can still rescue the domain with 100 percent certainty during redemptionPeriod, only through the original Losing Registrar. You must contact their billing/support desk and pay the Registry Redemption Restore Fee (typically $80 to $250 USD) plus a 1-year renewal.
3. Stage 3: Pending Delete (pendingDelete, Final 5 Calendar Days):
   • Once the 30-day redemptionPeriod expires, the domain enters pendingDelete for exactly 5 days (120 hours).
   • Impact: During pendingDelete, the Registry rejects all standard EPP restore commands from the registrar. At the end of day 5 (for .com/.net Verisign drops, between 18:00 and 19:15 UTC), the domain is released to the public and snatched within 10 milliseconds by automated drop-catching networks.
   • Emergency Action if Caught in pendingDelete or Registrar Expired Auction:
     • If the domain was sold via the registrar's day-30 expired auction before entering Registry redemptionPeriod, check if your registrar offers a short post-auction redemption window or contact the winning bidder/broker immediately.
     • If the domain is truly in the 5-day Registry pendingDelete phase, simultaneously place high-tier backorders across all three major drop-catching networks (DropCatch.com, SnapNames.com, û NameJet.com) so that if the domain drops to the public pool on Day 5, your backorder captures it or enters you into the closed bidder auction to buy your domain back.

Why Does My Website Still Fail for Hours After I Renewed an Expired Domain? (Fixing Negative DNS Caching)¶

When your domain expires, the registrar replaces your NS records with temporary parking nameservers that often carry a 24-hour to 48-hour TTL (Time-To-Live) (86400 an 172800 seconds). Even after you pay the renewal bill and your registrar restores your real NS Di nav 5 hûrdeman de li qada root tomar dike, çareserkerên DNS-ya vegerî yên gelemperî li çaraliyê cîhanê (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9, û çareserkerên ISP) dibe ku heya ku ew TTL-ya 48-saetê biqede, xizmeta rûpela parkkirinê ya qediyakirî ya cached bike.

** Meriv çawa di 60 çirkeyan de Cache-ya DNS-a Gerdûnî ya Yekser Bi zorê Dike : 48 saetan li bendê nemînin ku kaşeyên vegerî bi xwezayî biqede. Naha bi karanîna portalên xweya cache-paqijkirina webê ya belaş domaina xwe ji sê pêşkêşkerên DNS-ya giştî ya cîhanî ya herî mezin paqij bikin: 1. ** DNS-ya Giştî ya Google-ê bişon (8.8.8.8 / 8.8.4.4): Serdana developers.google.com/speed/public-dns/cache, tîp yourdomain.com, cureya tomarê hilbijêre NS (û paşê ji bo ** dubare bikinA, AAAA, MX, û DS), û bikirtînin Flush Cache **. Vê yekê domaina we li seranserê her navendê daneya Google DNS-ê li çaraliyê cîhanê di kêmtirî 10 çirkeyan de paqij dike. 2. ** DNS-ya Giştî ya Cloudflare Flush (1.1.1.1 / zzwxh:0060): Serdana **kzwxh:0061, bikeve klzzh:0062, hilbijêre NS, A, AAAA, û MX**, û bikirtînin ** Cache Paqij bik. 3. ** OpenDN/ Cisco Umbrella (208.67.222.222): Serdana cachecheck.opendns.com, bikeve yourdomain.com, encaman li ser girêkên gerdûnî kontrol bikin, û li binê tabloyê ** Cache-ê nûve bikin ** bikirtînin.

Qonaxa 4: Rastkirina DNSSEC şikestî (SERVFAIL) piştî koçkirin an revandinê¶

Berfirehkirinên Ewlekariya Sîstema Navê Domainê (DNSSEC) bi şîfrekirinê tomarên DNS-ya we îmze dike (RRSIG qeydên ku ji hêla Key Signing Zone ve hatî îmze kirin ZSK û Key Signing Key KSK) û lihevhatinek ** Îmzekarê Delegasyonê (DS)** di qada dêûbav TLD-ê de li qeydkera we de haş kirin.

Dema ku DNSSEC pêşî li jehrîbûna cache digire, ** veavakirinek DNSSEC ya şikestî dibe sedema qutbûnek gerdûnî ya tavilê û tevahî (SERVFAIL) li ser her çareserkerê pejirandî (di nav de 8.8.8.8, 1.1.1.1, Comcast, û hilgirên sereke yên mobîl)**. Ev bi gelemperî di dema koçberiyek acîl de diqewime: rêveberek tevdigere yourdomain.comPêşkêşkerên navên ji Cloudflare berbi AWS Route 53 (an berevajî) bêyî ku pêşî pêşkêşkarê kevn jêbirin DS li qeydê domainê tomar bikin.

Teşhîskirin û tamîrkirina DNSSEC SERVFAIL Lockout di 5 Minutes¶

1. ** Piştrast bike ku DNSSEC sûcdar e **: Birevin du dig fermanên paşîn-bi-paş dide: pirsek normal, û pirsek bi +cd (Kontrolkirina Neçalak) ala, ku ji çareserkerê vegerî re dibêje ku guh nede pejirandina krîptografî ya DNSSEC:

   dig yourdomain.com @8.8.8.8
   dig yourdomain.com @8.8.8.8 +cd
   

   • Ger emrê yekem bi status: SERVFAIL û sifir bersiv, dema ku fermana duyemîn (+cd) yekser bi ser dikeve status: NOERROR û we vedigerîne A navnîşana IP-ê tomar bikin, ** ji sedî 100 ê qutbûna we zincîreyek pêbawer a DNSSEC-ê şikestî ye **.
2. ** Bişkojka Rastî vekolîn bikin DNSViz.net an Verisign DNSSEC Debugger**:
   • veke dnsviz.net an dnssec-debugger.verisignlabs.com û têkevin yourdomain.com.
   • Ew ê diyagramek dîtbar xêz bike ku nîşan dide ka gelo DS record published at your registrar fails to match the DNSKEY served by your current DNS host, or whether your zone signatures (RRSIG) have expired.
3. Emergency Remediation:
   • If you just changed DNS providers: Log into your Domain Registrar, navigate to the DNSSEC / DS Records section, and delete the old stale DS record (or replace it with the new DS record generated by your new DNS host).
   • Flush the DS record cache: Immediately visit Google Public DNS Cache Flush (developers.google.com/speed/public-dns/cache) and Cloudflare Purge Cache (one.one.one.one/purge-cache/) and purge the DS and DNSKEY record types for yourdomain.com so validating resolvers stop checking the deleted DS hash immediately.

Phase 5: Post-recovery clean-up, TLS certificate revocation, and hardening¶

Getting your domain registrar account and DNS records back under your control is only half the battle. During the hours or days that the attacker controlled your domain's DNS, they had complete authority to prove "Domain Control Validation" (DCV) to every Certificate Authority (CA) on the planet.

1. Audit Certificate Transparency Logs (crt.sh) and Revoke Rogue TLS Certificates¶

When an attacker points your A an NS records to their server, they immediately run certbot (Let's Encrypt, ZeroSSL, Google Trust Services, or Sectigo) to generate valid, browser-trusted TLS certificates for yourdomain.com, *.yourdomain.com, vpn.yourdomain.com, û mail.yourdomain.com. Even after you restore your DNS records, the attacker still holds the valid Private Key (.key) and signed Public Certificate (.crt) for your domain, which they can use to stage captive-portal Wi-Fi attacks, BGP hijacks, or internal network spoofing for the next 90 days.

1. Query Certificate Transparency Logs:
   • Biçe crt.sh/?q=%25.yourdomain.com or Censys Certificate Search (search.censys.io/certificates).
   • Sort by Logged At / Not Before date and inspect every single certificate issued during the hijack window (and in the 24 hours after recovery, due to cached DCV authorizations).
2. Force Immediate Certificate Revocation:
   • Identify the issuing Certificate Authority (Issuer Name) on every unauthorized certificate.
   • Every publicly trusted CA is required under the CA/Browser Forum Baseline Requirements (Section 4.9.1.1) to revoke a fraudulent or unauthorized certificate within 24 hours of confirming that the applicant was not authorized by the true domain owner.
   • If you already regained DNS control over the domain, you can revoke unauthorized Let's Encrypt or ACME certificates yourself in 60 seconds without even needing the attacker's private key: simply install certbot on a server you control, pass a fresh DNS-01 or HTTP-01 challenge for the exact same domain name using a brand-new ACME account key, and run:

     certbot revoke --cert-path downloaded_rogue_cert_from_crt_sh.pem --reason keycompromise
     

   • Alternatively, submit the Certificate Serial Numbers directly to the CA's emergency revocation portal (for example, Let's Encrypt's revocation instruction page, DigiCert's /revoke portal, or Sectigo's SSL Abuse reporting form).

2. Lock Down Your Domain Permanently So It Can Never Be Hijacked Again¶

Once operations are restored, implement these five enterprise domain-hardening controls:

1. Enable Registry Lock (serverUpdateProhibited, serverDeleteProhibited, serverTransferProhibited):
   • For mission-critical production domains, upgrade to a registrar that offers true Registry Lock (supported by Verisign on .com/.net, PIR on .org, and offered through enterprise registrars like MarkMonitor,CSC Digital Brand Services, Cloudflare Enterprise, Porkbun/Gandi/Namecheap Registry Lock tiers). With Registry Lock active, even if a hacker steals your registrar login and MFA, the TLD Registry rejects all NS or transfer changes unless a human security officer completes an out-of-band cryptographic/telephone ceremony.
2. Publish CAA (Certification Authority Authorization) DNS Records:
   • Add a CAA record (RFC 8659) to your DNS zone specifying the exact Certificate Authorities allowed to issue TLS certificates for your domain (for example, 0 issue "letsencrypt.org" an 0 issue "digicert.com", plus 0 iodef "mailto:security@yourdomain.com"). While an attacker who controls your whole DNS zone can delete a CAA record, a CAA record stops BGP hijackers or compromised subdomain CNAME targets from using unauthorized CAs.
3. Separate Your Domain Registrar from Your Daily DNS Hosting Provider:
   • Keep your domain registration locked inside a high-security vault registrar account that only 2 corporate officers can access using FIDO2 hardware security keys (YubiKey), and delegate daily DNS record management (A, CNAME, TXT) to a separate managed DNS service with granular Role-Based Access Control (RBAC) and scoped API tokens.
4. Audit and Eliminate Dangling Subdomain CNAME û NS Records:
   • Run a monthly automated scan of your entire DNS zone file (subzy, nuclei -t takeovers/, or OWASP Amass) to identify any CNAME, ALIAS, or subdomain NS record pointing to an unregistered external cloud resource or expired domain, and delete the DNS record before decommissioning the cloud server.
5. Set Up Automated External RDAP, DNS, and CT Log Monitoring:
   • Configure an external monitor (such as CertSpotter, Cloudflare Certificate Transparency Monitoring, or a simple hourly cron script checking dig NS û whois) that alerts a dedicated Slack/PagerDuty channel and an off-domain SMS/email address the exact minute a new TLS certificate is logged in Certificate Transparency or an NS/MX/DS record changes.

Pirsên pir caran têne pirsîn¶

Çavkaniyan kontrol kirin¶

• Cybersecurity and Infrastructure Security Agency (CISA, United States): Emergency Directive 19-01: Mitigate DNS Infrastructure Tampering (CISA mandates on Registry Lock, MFA for DNS/Registrars, Certificate Transparency log auditing, and DNSSEC validation) (cisa.gov/news-events/directives/emergency-directive-19-01).
• Internet Corporation for Assigned Names and Numbers (ICANN, International): Transfer Policy (Inter-Registrar Transfer Policy / IRTP), Transfer Dispute Resolution Policy (TDRP), Expired Registration Recovery Policy (ERRP), and EPP Status Codes Reference (icann.org/resources/pages/epp-status-codes-2014-06-16-en).
• National Institute of Standards and Technology (NIST, United States): Special Publication 800-81-2, Secure Domain Name System (DNS) Deployment Guide (csrc.nist.gov).
• National Cyber Security Centre (NCSC, United Kingdom): Protecting Bulk Personal Data and Domain Security: Registry Lock, CAA Records, and Subdomain Takeover Prevention (ncsc.gov.uk).
• CA/Browser Forum (International): Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (Section 4.9.1.1: 24-Hour Mandatory Revocation for Domain Compromise) (cabforum.org).
• Internet Engineering Task Force (IETF, International): RFC 4033/4034/4035 (DNSSEC), RFC 8659 (DNS Certification Authority Authorization / CAA Resource Record), and RFC 9083 (Registration Data Access Protocol / RDAP) (datatracker.ietf.org).

rêberên Related¶

• Web hosting crisis, migration, and backup restoration
• Phishing û hesabên lihevhatî
• MFA phishing û dijberî-di-navîn-derbasbûna
• Bersiva binpêkirina daneyan û şîfreya şîfreyê
• Business ransomware and server breach
• SIM veguherandin