Domænenavnkapring, DNS-forgiftning og registrator lockout¶

At miste kontrollen over din organisations primære domænenavn eller autoritative DNS-zone er en af ​​de mest ødelæggende digitale nødsituationer, som en virksomhed, et hospital, et kommunalt bureau eller en online publikation kan komme ud for. Fordi dit domænenavn er roden til tillid for ethvert system på internettet, ødelægger en hacker, der kaprer din domæneregistratorkonto eller forgifter dine DNS-registreringer, ikke blot dit websted. Inden for få minutter efter at have ændret din NS (navneserver), A/AAAA (Web IP), eller MX (Mail Exchange)-registreringer, kan angriberen lydløst opsnappe enhver indgående virksomheds- og kunde-e-mail, videregive automatisk Let's Encrypt Domain Validation (DV) kontrollerer for at præge gyldige TLS/SSL-krypteringscertifikater i dit navn, registrere medarbejders Single Sign-On (SSO)-adgangskoder og udløse e-mails til nulstilling af adgangskode til din cloud-infrastruktur, bankportaler og finansielle konti. Selv en ikke-ondsindet fejl, såsom et udløbet domæne, der falder ind i AutoRenewGracePeriod eller RedemptionPeriod (clientHold), bringer webtrafik, API mobile backends og virksomheds-e-mail til et øjeblikkeligt stop over hele kloden.

Hvis en domænekapring eller DNS-afbrydelse kompromitterer hospitalspatientdirigering, nødudsendelseskommunikation, offentlig telemetri eller et aktivt liv-sikkerhedssystem, skal du ringe til dit lokale alarmnummer (911 i USA og Canada, 112 i hele EU, 999 i Storbritannien) eller se vores katalog over internationale alarmnumre og underret dit nationale cyberhændelsesresponsteam (såsom CISA i USA kl 1-844-SAY-CISA eller NCSC i Det Forenede Kongerige) straks. For alle kommercielle, nonprofit- og personlige domænekriser skal du udføre triage-trinene nedenfor i nøjagtig rækkefølge.

Gør dette nu¶

1. Afgør på 30 sekunder, om dit domæne udløb, dine DNS-registreringer blev ændret, eller domænet blev overført til en udenlandsk registrator: Kør en live RDAP eller WHOIS forespørgsel og en autoritativ DNS-forespørgsel fra en terminal (rdap yourdomain.com eller whois yourdomain.com, og dig +trace yourdomain.com). Tjek Registratornavnet, EPP-statuskoderne (som f.eks clientHold til fakturering/bekræftelse vs. ok med ukendte navneservere), og de autoritative navneservere (NS).
2. Frys alle udgående adgangskodenulstillinger og lås din identitetsudbyder (Okta, Microsoft Entra ID, Google Workspace) med det samme: Hvis en hacker kontrollerer dit domænes MX optegnelser eller NS servere, modtager de hver eneste e-mail sendt til *@yourdomain.com. Instruer straks dine it-administratorer om at deaktivere "Glemt adgangskode via e-mail" selvbetjeningsnulstillinger på tværs af alle virksomhedsværktøjer, tilbagekalde aktive sessioner for brugere, hvis e-mailadresser kan blive brugt til at nulstille eksterne leverandørkonti, og skifte administrative logins til hardware FIDO2 sikkerhedsnøgler eller interne .onmicrosoft.com reservedomæner.
3. Bevar fuldstændige retsmedicinske snapshots af RDAP/WHOIS, DNS-zoner og certifikatgennemsigtighed (CT) logs før noget ændres: Gem output fra dig ANY yourdomain.com @8.8.8.8, whois yourdomain.com, og tjek crt.sh/?q=%25.yourdomain.com med det samme. Søger crt.sh afslører alle uautoriserede SSL/TLS-certifikater, som angriberen lige har lavet for dine underdomæner (mail., vpn., login., api.), så du ved præcis, hvilke interne tjenester de aktivt efterligner via Adversary-in-the-Middle (AitM) proxyer.
4. Kontakt den tabende registrators dedikerede nødmisbrugs-/sikkerhedsoperationsteam (ikke Tier-1 chatsupport) for at udløse en uautoriseret ICANN-overførselstvist (IRTP) eller Registry Lock-tilbageførsel: Hvis dit domæne blev skubbet til en anden konto hos den samme registrator eller overført via en stjålet Auth-Info (EPP) kode til en udenlandsk registrator, kontakt din oprindelige registrators Domænemisbrug / High-Risk Security Escalation Desk og anmod om en øjeblikkelig Registrator Fortryd / Emergency Transfer Dispute i henhold til ICANN's overførselspolitik (Section I.A og Transfer Dispute Resolution Policy), med henvisning til uautoriseret kompromis med legitimationsoplysninger.
5. Eskaler direkte til Top-Level Domain (TLD) Registry Operator, hvis registratoren ikke reagerer: Husk hierarkiet: Registratorer (som GoDaddy, Namecheap, Cloudflare, MarkMonitor, Network Solutions, Gandi, Porkbun) er simpelthen detailforhandlere; Registry Operator (såsom Verisign for .com/.net, Public Interest Registry (PIR) for .org, Nomineret for .uk, CIRA for .ca, DENIC for .de, eller auDA for .au) kører master-rodzonedatabasen. landekode (ccTLD) registre og flere gTLD-registre kan placere en nødsituation serverHold eller serverUpdateProhibited lås direkte på rodniveau under verificerede cyberkriminalitetshændelser.
6. Advar kunder, leverandører og bankpartnere via kanaler uden for båndet @yourdomain.com e-mail er kompromitteret: Hvis hackeren kaprede din MX optegnelser, vil de straks svare på åbne regnskabstråde med falske instruktioner om bankoverførsel. Giv kunder besked via telefon, SMS, LinkedIn, statusside på et separat backup-domæne eller officielle sociale mediekonti om ikke at stole på nogen e-mail eller login-portal på det berørte domæne, før gendannelse er bekræftet.

Beslutningstræ: diagnosticere og indeholde et domæne- eller DNS-udfald¶

Følg dette hurtige diagnostiske flowchart for at lokalisere det nøjagtige lag af domænenavnesystemet, der er fejlet eller blevet kapret:

flowchart TD
    A["Hjemmeside nede, TLS-certifikatadvarsel eller firma-e-mail standset"] --> B["Kør RDAP/WHOIS og grav +spor fra eksternt netværk"]
    B --> C{"Hvad viser RDAP-status- og registratorfelter?"}
    C -->|"Status: clientHold, autoRenewPeriod eller redemptionPeriod"| D["Utilsigtet udløb eller suspendering af ICANN Whois-bekræftelse"]
    D --> E["Log ind på registrator med det samme: Betal fornyelses-/indløsningsgebyr eller klik på RAA-bekræftelseslink; Anmod om TTL-nødskylning"]
    C -->|"Registratornavn eller registrantkonto ændret uden autorisation"| F["Komplet registratorkontokapring eller uautoriseret EPP-overførsel"]
    F --> G["Lås identitetsudbyder (Entra/Google), Fil Emergency Registrar Misbrugsbillet + ICANN Transfer Dispute, Check crt.sh for Rogue Certs"]
    C -->|"Registrator & NS Uændret, men A/CNAME/MX Records peger på ukendte IP'er"| H["Kompromis med administreret DNS-udbyder (Cloudflare / Route53 / NS1 API-nøgle eller kontobrud)"]
    H --> I["Tilbagekald kompromitterede DNS API-tokens, gendan kendt-god zone-fil, tilbagekald Rogue TLS-certifikater, roter eksponerede legitimationsoplysninger"]
    C -->|"Registrator, NS og Zone Records ser normale ud, men webstedet fejler med SERVFAIL"| J["Brudt DNSSEC Chain of Trust (DS Record Mismatch eller Expired RRSIG)"]
    J --> K["Kør DNSViz.net-tjek: Fjern forældet DS-post hos registrator eller gensigner zone hos DNS-vært"]

Fase 1: Teknisk efterforskning for at identificere den nøjagtige angrebsvektor¶

Når et domæne pludselig holder op med at løse eller begynder at vise en phishing-side eller cryptocurrency-svindel, spilder hvert minut, der bruges på at gætte, værdifuld genopretningstid. Der er fire helt forskellige scenarier, der ser identiske ud med en slutbruger i en webbrowser, og hver kræver en helt anden rettelse.

Sådan læser du RDAP, WHOIS, og dig Udsender som en hændelsesvar¶

Åbn en kommandoterminal på Linux, macOS eller Windows (ved hjælp af WSL eller nslookup) og kør følgende tre diagnostiske kontroller ved hjælp af en neutral offentlig rekursiv resolver (8.8.8.8 eller 1.1.1.1):

1. Tjek delegationen på registerniveau (dig +trace og RDAP):

   dig +trace yourdomain.com NS @1.1.1.1
   

   • Se på trinnet lige efter TLD-rodserverne (f.eks. a.gtld-servers.net. for .com). Hvilket NS (Nameserver) værtsnavne returneres af TLD-registret selv?
   • Hvis TLD-registret returnerer dine normale navneservere (ns1.yourdnsprovider.com) med status NOERROR, sker kapringen inde i din DNS-hostingudbyder (eller det er et DNSSEC-brud).
   • Hvis TLD-registret returnerer helt ukendte navneservere (eller hvis whois yourdomain.com viser en ny Registrar: navn og en Updated Date: inden for de sidste par timer eller dage), skete kapringen på domæneregistratorniveau.
2. Afkode ICANN EPP-domænestatuskoderne: Se på Domain Status: linjer i din WHOIS eller RDAP output. Disse standardiserede EPP-koder (Extensible Provisioning Protocol) fortæller dig, hvorfor et domæne fejler eller er låst:

Fase 2: Gendannelse fra et ondsindet domænekapring eller uautoriseret registratoroverførsel¶

Angribere kaprer virksomheds-, Web3/DeFi-, finans- og mediedomæner af høj værdi ved hjælp af tre primære teknikker: 1. Overtagelse af registratorkonto (legitimationsfyldning, Infostealer-malware eller SIM-swap): Angriberen logger ind på dit GoDaddy-, Namecheap-, Google Domains/Squarespace- eller Network Solutions-dashboard, slukker clientTransferProhibited, ændrer NS optegnelser for at pege på en angriber-kontrolleret Cloudflare-konto, eller genererer en Auth-Info (EPP) kode for at overføre domænet ud. 2. Social Engineering of Registrar Support: Angriberen indsender forfalskede inkorporeringsdokumenter, falske stats-id'er eller forfalskede brevpapir til en registrators kontogendannelsesskranke og hævder, at den oprindelige it-administrator døde eller forlod virksomheden. 3. Underdomæneovertagelse (Dangling CNAME / Dangling NS): Dit hoveddomæne er uberørt, men et gammelt underdomæne (promo.yourdomain.com eller status.yourdomain.com) har stadig en CNAME record, der peger på en dekommissioneret AWS S3-bucket, Azure App Service, GitHub Pages-repo, Heroku-app eller Zendesk-instans, som du slettede for måneder siden. Angriberen registrerer det forladte cloud-ressourcenavn på AWS/Azure/GitHub og serverer straks ondsindet indhold fra dit officielle underdomæne.

Trin 1: Smid angriberen ud af din Cloud Identity-udbyder og e-mail-system¶

Inden du overhovedet er færdig med at udfylde registratorgendannelsesformularen, antag, at hackeren aktivt læser hver e-mail, der sendes til dit domæne, og forsøger at pivotere ind i din interne cloud-infrastruktur:

1. Skift Microsoft 365/Google Workspace til Fallback Domains and Hardware MFA:
   • I Microsoft Entra ID (tidligere Azure AD) har hver lejer et permanent, ikke-hijackable fallback-domæne (yourcompany.onmicrosoft.com). Administratorer kan logge ind via admin@yourcompany.onmicrosoft.com selvom yourdomain.com DNS er fuldstændig kapret.
   • Deaktiver alle metoder til nulstilling af SMS, taleopkald og alternativ e-mail adgangskode i Entra ID / Okta / Google Workspace (Authentication Methods Policy). Kræv FIDO2/WebAuthn-hardwaresikkerhedsnøgler eller nummer-matchende Authenticator-push-meddelelser.
2. Revider udgående og indgående e-maillogfiler for det nøjagtige kompromisvindue:
   • Hvis din MX registreringer blev ændret kl. 02:14 UTC, ingen legitime eksterne e-mails har nået dine rigtige mailservere siden 02:14 UTC; hver eneste eksterne e-mail, der blev sendt til dine medarbejdere i løbet af det vindue, blev fanget i fuld klartekst af angriberens useriøse mailserver (Postfix/Exim-lytter).
   • Træk straks en liste over alle tredjeparts SaaS-platforme, banker, AWS/GCP-rodkontoer, GitHub-organisationer og leverandørportaler, der er knyttet til @yourdomain.com e-mail-adresser, og kontroller, om angriberen udløste nulstilling af adgangskoder på disse eksterne platforme under kapringsvinduet.

Trin 2: Udfør protokollen til registrator og Registry Emergency Recovery¶

Åbn ikke en generisk "Mit websted fungerer ikke" supportchat. Du skal bruge den nøjagtige lovgivningsmæssige og juridiske terminologi, der udløser eskalering til Registrar Tier-3 Security / General Counsel / ICANN Compliance Team:

1. Case A: Domænet er stadig hos din oprindelige registrator (kontoovertagelse eller intern "konto-push"):
   • Mange angribere venter ikke 5 dage på en EPP-overførsel mellem registratorer; i stedet bruger de registratorens øjeblikkelige "Skub domæne til en anden konto"-funktion til at flytte dit domæne til en brænderkonto hos den samme registrator på 3 sekunder.
   • Ring og send en e-mail til registratorens Bedrageri / Kontokapring / Misbrugsafdeling med det samme. Angiv tydeligt: "HASTERENDE SIKKERHEDSHÆNDELSE: Uautoriseret kontoadgang og intern domæne-push/DNS-ændring af [ditdomæne.com]. Anmoder om øjeblikkelig indefrysning af domænet under serverHold/clientUpdateProhibited og tilbagerulning af uautoriserede DNS/kontoændringer."
   • Saml dit bevis på historisk ejerskabspakke med det samme: Registratorsikkerhedsteam kræver uomtvisteligt bevis på, at du er den legitime tidligere registrant, før de vil trække et domæne tilbage fra en anden konto. Saml disse 5 dokumenter i en enkelt PDF med det samme:
     1. Historiske registratorfakturaer og betalingsbevis: PDF-kvitteringer og kreditkort-/bankudtog, der viser, at din organisation betaler for registrering og fornyelse af yourdomain.com over de seneste 1 til 10 år (inklusive de sidste 4 cifre på betalingskortet eller bankreferencen).
     2. Statsudstedt virksomhedsregistrering og embedsmands-id: Officielt stiftelsesbevis/vedtægter, der matcher den historiske WHOIS Registrant Organizationplus et offentligt billed-id af den virksomhedsleder, der underskriver erklæringen.
     3. Bevis for historisk DNS-zonefil og serverejerskab: Kopier af din tidligere DNS-zonefil, historiske WHOIS-snapshots eller bevis på, at din organisation ejer det autonome system (ASN) eller IP-blokke (A optegnelser), som domænet pegede på i årevis før dagens ændring.
     4. Original kontooprettelse e-mail / billethistorik: Overskrifter på e-mails modtaget fra registratoren på det tidspunkt, hvor domænet oprindeligt blev registreret eller fornyet.
     5. Officielt retshåndhævelsesrapportnummer: En indleveret FBI IC3 (ic3.gov) klagenummer (USA), Action Fraud referencenummer (Storbritannien) eller nationalt politis cyberkriminalitetsrapportnummer. Registratorer handler dramatisk hurtigere, når de får udleveret et formelt retshåndhævende sagsnummer, der bekræfter en kriminel computerindtrængen under 18 U.S.C. § 1030 (CFAA) eller UK Computer Misuse Act 1990.
2. Sag B: Domænet blev overført til en anden registrator (inter-registrator kapring):
   • I henhold til ICANN-overførselspolitikken (tidligere IRTP) kræver en overførsel mellem registratorer en Auth-Info (EPP) kode og skal blokeres i 60 dage efter visse registrantændringer, medmindre de fraviges. Hvis en angriber hackede din konto hos Registrator A ("den tabende Registrator") og overførte domænet til Registrator B ("Gaining Registrar"):
   • Kontakt BÅDE den tabende registrator og den vindende registrator med det samme, men prioriter tvisten om den tabende registrators overførsel/sikkerhedsteam. I henhold til ICANN's Transfer Dispute Resolution Policy (TDRP) er den tabende registrator den enhed, der har dine historiske faktureringsregistreringer og login-logs, der beviser, at overførslen var uautoriseret. Den tabende registrator kan formelt kontakte den vindende registrators compliance officer for at udføre et samarbejde Registrar Transfer Fortryd, eller indgive en formel TDRP-procedure.
   • Send samtidig din ejerskabsbevispakke og politirapport til Gaining Registrar's Abuse Desk med krav om, at de placerer en øjeblikkelig clientTransferProhibited og clientUpdateProhibited lås på domænet, så angriberen ikke kan hoppe domænet gennem en kæde af yderligere tre offshore-registratorer ("registrar hopping").
3. Send en nødeskalering med ICANN (for gTLD'er som f.eks .com, .net, .org, .io if gTLD) eller ccTLD-registret:
   • Hvis en registrator nægter at undersøge en uautoriseret overførsel eller undlader at reagere under en aktiv kapring, skal du indsende en presserende klage over uautoriseret overførsel/domænekapring via ICANN Contractual Compliance Portal (icann.org/compliance/complaint).
   • Hvis dit domæne bruger et Country-Code Top-Level Domain (ccTLD), som f.eks .uk, .ca, .au, .de, .fr, .nl, .ch, eller .jp, har du en endnu hurtigere mulighed: ccTLD-registre styres af nationale tilsynsmyndigheder snarere end ICANN og opretholder næsten altid direkte Registry Emergency Security Teams (f.eks. Nominet i Storbritannien kl. 0330 236 9470, CIRA i Canada, DENIC i Tyskland, AFNIC i Frankrig), der kan fryse et kapret domæne direkte på det nationale registerniveau inden for få timer efter bekræftelse af virksomhedens identitet.

Fase 3: Redning af et udløbet domæne (clientHold, RedemptionPeriod, og PendingDelete)¶

Ikke alle pludselige globale afbrydelser er et cyberangreb. Hver eneste dag går store virksomheder, SaaS-startups og offentlige entreprenører helt i mørke, fordi det kreditkort, der er registreret hos deres domæneregistrator, udløb, og e-mails med påmindelser om fornyelse blev sendt til former-founder@company.com der forlod firmaet for tre år siden.

Forståelse af ICANN-tidslinjen for udløbet domænelivscyklus¶

For generiske topdomæner (.com, .net, .org, .biz, .info), håndhæver ICANN Expired Registration Recovery Policy (ERRP) en streng flertrins livscyklus efter udløbsdatoen passerer:

1. Tape 1: Udløbsperiode for automatisk fornyelse (dage 1 til ~30/45 efter udløb):
   • Umiddelbart efter udløb (ofte inden for 24 til 72 timer), ændrer registratoren domænets NS registrerer til en parkeret/udløbet fornyelsessplash-side eller placerer domænet på clientHold.
   • Påvirkning: Dit websted og din virksomheds e-mail holder op med at fungere med det samme (DNS_PROBE_FINISHED_NXDOMAIN eller parkeringsannoncer).
   • Gendannelse: Log ind på registratorkontoen og betal standard 1-års fornyelsesgebyr ($10 til $30 USD). Registratoren gendanner straks din original NS optegnelser.
2. Tape 2: Henstandsperiode for indløsning (redemptionPeriod, 30 dages varighed):
   • Hvis ingen fornyer domænet i trin 1 (normalt efter dag 30 til 42 afhængigt af registratorens servicevilkår), sletter registratoren domænet i registret, og registret placerer det i de obligatoriske 30-dages redemptionPeriod (medmindre registratoren auktionerede det udløbne domæne via en intern auktionsplatform for udløbet domæne som GoDaddy Auctions eller NameJet, skal du straks tjekke din registrators nøjagtige dag-30 auktion).
   • Gendannelse: Du kan stadig redde domænet med 100 procent sikkerhed under redemptionPeriod, kun gennem den originale Losing Registrar. Du skal kontakte deres fakturerings-/supportdesk og betale Registry Redemption Restore Fee (typisk $80 til $250 USD) plus en 1-årig fornyelse.
3. Tape 3: Afventer sletning (pendingDelete, sidste 5 kalenderdage):
   • En gang de 30 dage redemptionPeriod udløber, kommer domænet ind pendingDelete i præcis 5 dage (120 timer).
   • Påvirkning: Under pendingDelete, afviser topdomæneadministratoren alle standard-EPP restore kommandoer fra registratoren. I slutningen af dag 5 (for .com/.net Verisign falder mellem 18:00 og 19:15 UTC), domænet frigives til offentligheden og snuppes inden for 10 millisekunder af automatiserede drop-catching-netværk.
   • Nødhandling, hvis man bliver fanget pendingDelete eller registrator udløbet auktion:
     • Hvis domænet blev solgt via registratorens dag-30 udløb auktion, før det kom ind i registreringsdatabasen redemptionPeriod, tjek om din registrator tilbyder et kort indløsningsvindue efter auktionen, eller kontakt den vindende budgiver/mægler med det samme.
     • Hvis domænet virkelig er i 5-dages registreringsdatabasen pendingDelete fase, placere samtidigt high-tier restordrer på tværs af alle tre store drop-catching netværk (DropCatch.com, SnapNames.com, og NameJet.com), så hvis domænet falder til den offentlige pulje på dag 5, fanger din restordre det eller går med i den lukkede budauktion for at købe dit domæne tilbage.

Hvorfor svigter mit websted stadig i timer, efter at jeg har fornyet et udløbet domæne? (Lettelse af negativ DNS-cache)¶

Når dit domæne udløber, erstatter registratoren din NS poster med midlertidige parkeringsnavneservere, der ofte bærer en 24-timers til 48-timers TTL (Time-To-Live) (86400 eller 172800 sekunder). Selv efter at du har betalt fornyelsesregningen, og din registrator genopretter din rigtige NS registrerer i rodzonen inden for 5 minutter, offentlige rekursive DNS-resolvere over hele verden (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9, og ISP-resolvere) kan blive ved med at betjene den cachelagrede udløbne parkeringsside, indtil den 48-timers TTL udløber.

Sådan tvinger du en øjeblikkelig global DNS-cache-skylning på 60 sekunder: Vent ikke 48 timer på, at rekursive caches udløber naturligt. Skyl dit domæne manuelt fra de tre største globale offentlige DNS-udbydere lige nu ved hjælp af deres gratis webcache-rensningsportaler: 1. Skyl Google offentlige DNS (8.8.8.8 / 8.8.4.4): Besøg developers.google.com/speed/public-dns/cache, type yourdomain.com, vælg posttype NS (og gentag derefter for A, AAAA, MX, og DS), og klik på Skyl cache. Dette rydder dit domæne på tværs af alle Google DNS-datacentre verden over på mindre end 10 sekunder. 2. Skyl Cloudflare Public DNS (1.1.1.1 / 1.0.0.1): Besøg one.one.one.one/purge-cache/, indtast yourdomain.com, vælg NS, A, AAAA, og MX, og klik på Tøm cache. 3. Skyl OpenDNS / Cisco Umbrella (208.67.222.222): Besøg cachecheck.opendns.com, indtast yourdomain.com, tjek resultaterne på tværs af globale noder, og klik på Opdater cachen nederst i tabellen.

Fase 4: Udbedring af ødelagte DNSSEC (SERVFAIL) efter en migration eller kapring¶

Domain Name System Security Extensions (DNSSEC) signerer dine DNS-poster kryptografisk (RRSIG optegnelser underskrevet af en zonesigneringsnøgle ZSK og nøglesigneringsnøgle KSK) og udgiver en matchende delegationsunderskriver (DS) hash i den overordnede TLD-zone hos din registrator.

Mens DNSSEC forhindrer cacheforgiftning, ** forårsager en ødelagt DNSSEC-konfiguration et øjeblikkeligt, totalt globalt udfald (SERVFAIL) på hver validerende resolver (inklusive 8.8.8.8, 1.1.1.1, Comcast og større mobilselskaber)**. Dette sker oftest under en nødmigrering: en administrator flytter yourdomain.com's navneservere fra Cloudflare til AWS Route 53 (eller omvendt) uden først at slette den gamle udbyders DS registrere hos domæneregistratoren.

Diagnosticering og reparation af en DNSSEC SERVFAIL Lockout på 5 minutter¶

1. Bekræft, at DNSSEC er synderen: Løb to dig kommandoer back-to-back: en normal forespørgsel og en forespørgsel med +cd (Checking Disabled) flag, som fortæller den rekursive resolver at ignorere DNSSEC kryptografisk validering:

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

   • Hvis den første kommando fejler med status: SERVFAIL og nul svar, mens den anden kommando (+cd) lykkes med det samme med status: NOERROR og returnerer din A registrere IP-adresse, 100 procent af dit udfald er en brudt DNSSEC-tillidskæde.
2. Inspicer det nøjagtige brud med DNSViz.net eller Verisign DNSSEC Debugger:
   • Åben dnsviz.net eller dnssec-debugger.verisignlabs.com og indtast yourdomain.com.
   • Den vil tegne et visuelt diagram, der viser, om DS post offentliggjort hos din registrator stemmer ikke overens med DNSKEY betjenes af din nuværende DNS-vært, eller om dine zonesignaturer (RRSIG) er udløbet.
3. Nødafhjælpning:
   • Hvis du lige har skiftet DNS-udbyder: Log ind på din domæneregistrator, naviger til sektionen DNSSEC / DS Records, og slet den gamle uaktuelle DS optag (eller udskift det med det nye DS post genereret af din nye DNS-vært).
   • Skyl af DS optag cache: Besøg straks Google Public DNS Cache Flush (developers.google.com/speed/public-dns/cache) og Cloudflare Purge Cache (one.one.one.one/purge-cache/) og rens DS og DNSKEY posttyper for yourdomain.com så validerende resolvere stopper med at kontrollere de slettede DS hash med det samme.

Fase 5: Oprydning efter gendannelse, tilbagekaldelse af TLS-certifikat og hærdning¶

At få din domæneregistratorkonto og DNS-registrering tilbage under din kontrol er kun halvdelen af kampen. I løbet af de timer eller dage, hvor angriberen kontrollerede dit domænes DNS, havde de fuld autoritet til at bevise "Domain Control Validation" (DCV) til alle certifikatmyndigheder (CA) på planeten.

1. Revisionscertifikatgennemsigtighedslogfiler (crt.sh) og tilbagekald Rogue TLS-certifikater¶

Når en angriber peger din A eller NS poster til deres server, kører de straks certbot (Lad os kryptere, ZeroSSL, Google Trust Services eller Sectigo) for at generere gyldige, browser-betroede TLS-certifikater til yourdomain.com, *.yourdomain.com, vpn.yourdomain.com, og mail.yourdomain.com. Selv efter at du har gendannet dine DNS-poster, har hackeren stadig den gyldige Private Key (.key) og underskrevet Offentligt certifikat (.crt) for dit domæne, som de kan bruge til at iscenesætte captive-portal Wi-Fi-angreb, BGP-kapringer eller intern netværksspoofing i de næste 90 dage.

1. Forespørgselscertifikatgennemsigtighedslogfiler:
   • Go to crt.sh/?q=%25.yourdomain.com eller Censys certifikatsøgning (search.censys.io/certificates).
   • Sorter efter Logged At / Not Before dater og inspicér hvert enkelt certifikat, der er udstedt under kapringsvinduet (og inden for 24 timer efter gendannelse på grund af cachelagrede DCV-autorisationer).
2. Tvang øjeblikkelig tilbagekaldelse af certifikat:
   • Identificer den udstedende certifikatmyndighed (Issuer Name) på hvert uautoriseret certifikat.
   • Alle offentligt betroede CA er i henhold til CA/Browser Forum Baseline Requirements (afsnit 4.9.1.1) forpligtet til at tilbagekalde et svigagtigt eller uautoriseret certifikat inden for 24 timer efter bekræftelse af, at ansøgeren ikke var autoriseret af den sande domæneejer.
   • Hvis du allerede har genvundet DNS-kontrollen over domænet, kan du selv tilbagekalde uautoriserede Let's Encrypt- eller ACME-certifikater på 60 sekunder uden at skulle bruge angriberens private nøgle: blot installer certbot på en server, du kontrollerer, bestå en ny DNS-01- eller HTTP-01-udfordring for nøjagtig det samme domænenavn ved hjælp af en helt ny ACME-kontonøgle, og kør:

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

   • Alternativt kan du indsende certifikatets serienumre direkte til CA's nødtilbagekaldelsesportal (f.eks. Let's Encrypts tilbagekaldelsesinstruktionsside, DigiCerts /revoke portal eller Sectigos rapporteringsformular for SSL-misbrug).

2. Lås dit domæne permanent, så det aldrig kan blive kapret igen¶

Når operationerne er gendannet, skal du implementere disse fem virksomhedsdomænehærdende kontroller:

1. Aktiver registreringsdatabasenlås (serverUpdateProhibited, serverDeleteProhibited, serverTransferProhibited):
   • For missionskritiske produktionsdomæner skal du opgradere til en registrator, der tilbyder ægte Registry Lock (understøttet af Verisign på .com/.net, PIR tændt .org, og tilbydes gennem virksomhedsregistratorer som MarkMonitor, CSC Digital Brand Services, Cloudflare Enterprise, Porkbun/Gandi/Namecheap Registry Lock-niveauer). Med Registry Lock aktiv, selvom en hacker stjæler dit registrar-login og MFA, afviser TLD Registry alle NS eller overførselsændringer, medmindre en menneskelig sikkerhedsmedarbejder gennemfører en kryptografisk/telefonisk ceremoni uden for båndet.
2. Udgiv CAA (Certificeringsautorisation) DNS Records:
   • Tilføj en CAA optage (RFC 8659) til din DNS-zone med angivelse af de nøjagtige certifikatmyndigheder, der må udstede TLS-certifikater for dit domæne (f.eks. 0 issue "letsencrypt.org" eller 0 issue "digicert.com", plus 0 iodef "mailto:security@yourdomain.com"). Mens en angriber, der kontrollerer hele din DNS-zone, kan slette en CAA rekord, en CAA record stopper BGP-kaprere eller kompromitterede underdomæne-CNAME-mål i at bruge uautoriserede CA'er.
3. Adskil din domæneregistrator fra din daglige DNS-hostingudbyder:
   • Hold din domæneregistrering låst inde i en højsikkerhedsboksregistratorkonto, som kun 2 virksomhedsledere kan få adgang til ved hjælp af FIDO2 hardwaresikkerhedsnøgler (YubiKey), og uddeleger daglig DNS-registrering (A, CNAME, TXT) til en separat administreret DNS-tjeneste med granulær rollebaseret adgangskontrol (RBAC) og scoped API-tokens.
4. Revision og eliminer hængende underdomæne CNAME og NS Rekorder:
   • Kør en månedlig automatiseret scanning af hele din DNS-zonefil (subzy, nuclei -t takeovers/, eller OWASP Amass) for at identificere evt CNAME, ALIAS, eller underdomæne NS record, der peger på en uregistreret ekstern cloud-ressource eller udløbet domæne, og slet DNS-posten før nedlukning af cloud-serveren.
5. Konfigurer automatisk ekstern RDAP-, DNS- og CT-logovervågning:
   • Konfigurer en ekstern skærm (såsom CertSpotter, Cloudflare Certifikatgennemsigtighedsovervågning eller en simpel cron-script-kontrol hver time dig NS og whois), der advarer en dedikeret Slack/PagerDuty-kanal og en SMS/e-mail-adresse uden for domænet i det nøjagtige minut, hvor et nyt TLS-certifikat er logget på Certificate Transparency eller en NS/MX/DS registrere ændringer.

Ofte stillede spørgsmål¶

Kilder tjekket¶

• Cybersecurity and Infrastructure Security Agency (CISA, USA): Nøddirektiv 19-01: Afhjælpning af DNS Infrastructure Tampering (CISA-mandater om Registry Lock, MFA for DNS/registratorer, Certificate Transparency-logrevision og DNSSEC-validering) (cisa.gov/news-events/directives/emergency-directive-19-01).
• Internet Corporation for Assigned Names and Numbers (ICANN, International): Overførselspolitik (Inter-Registrar Transfer Policy / IRTP), Transfer Dispute Resolution Policy (TDRP), Udløbet Registration Recovery Policy (ERRP) og EPP Status Codes Reference (icann.org/resources/pages/epp-status-codes-2014-06-16-en).
• National Institute of Standards and Technology (NIST, USA): Special Publication 800-81-2, Secure Domain Name System (DNS) Deployment Guide (csrc.nist.gov).
• National Cyber Security Center (NCSC, Storbritannien): Beskyttelse af bulk personlige data og domænesikkerhed: Registry Lock, CAA Records og Subdomain Takeover Prevention (ncsc.gov.uk).
• CA/browserforum (internationalt): Basiskrav til udstedelse og administration af offentligt betroede TLS-servercertifikater (afsnit 4.9.1.1: 24-timers obligatorisk tilbagekaldelse for domænekompromittering) (cabforum.org).
• Internet Engineering Task Force (IETF, International): RFC 4033/4034/4035 (DNSSEC), RFC 8659 (DNS Certification Authority Authorization / CAA Resource Record), og RFC 9083 (Registration Data Access Protocol / RDAP) (datatracker.ietf.org).

Relaterede guider¶

• Webhosting-krise, migration og gendannelse af backup
• Phishing og kompromitterede konti
• MFA phishing and adversary-in-the-middle bypass
• Reaktion på databrud og adgangskodelæk
• Business ransomware og serverbrud
• SIM swapping