Դոմենների անունների առևանգում, DNS թունավորում և ռեգիստրի արգելափակում¶

Ձեր կազմակերպության առաջնային տիրույթի անվան կամ Հեղինակավոր DNS գոտու վերահսկողությունը կորցնելն ամենակործանարար թվային արտակարգ իրավիճակներից մեկն է, որը կարող է տուժել բիզնեսը, հիվանդանոցը, քաղաքային գործակալությունը կամ առցանց հրատարակությունը: Քանի որ ձեր տիրույթի անունը վստահության արմատն է ինտերնետում գտնվող յուրաքանչյուր համակարգի համար, հարձակվողը, ով առևանգում է ձեր տիրույթի գրանցման հաշիվը կամ թունավորում ձեր DNS գրառումները, պարզապես չի փչացնում ձեր կայքը: Ձեր փոխելուց րոպեների ընթացքում NS (Անվան սպասարկիչ), A/AAAA (Վեբ IP), կամ MX (Mail Exchange) գրառումները, հարձակվողը կարող է լուռ ընդհատել յուրաքանչյուր մուտքային կորպորատիվ և հաճախորդի էլ.DV) ստուգում է ձեր անունով TLS/SSL գաղտնագրման վավեր վկայագրերը, աշխատողի Single Sign-On (SSO) գաղտնաբառերը և ձեր ամպային ենթակառուցվածքի, բանկային պորտալների և ֆինանսական հաշիվների համար գաղտնաբառի վերակայման նամակներ գործարկելու համար: Նույնիսկ ոչ վնասակար ձախողում, ինչպիսին է ժամկետանց տիրույթի ընկնելը AutoRenewGracePeriod կամ RedemptionPeriod (clientHold), ամբողջ աշխարհում ակնթարթորեն դադարեցնում է վեբ տրաֆիկը, API-ի շարժական սարքերը և ընկերության էլ.

Եթե ​​տիրույթի առևանգումը կամ DNS-ի խափանումը վտանգի է ենթարկում հիվանդանոցի հիվանդների երթուղին, արտակարգ իրավիճակների ուղարկման հաղորդակցությունը, կոմունալ ծառայությունների հեռաչափությունը կամ կյանքի անվտանգության ակտիվ համակարգը, զանգահարեք ձեր տեղական շտապ օգնության համարին (911 Միացյալ Նահանգներում և Կանադայում, 112 ամբողջ Եվրամիությունում, 999 Միացյալ Թագավորությունում) կամ դիմեք մեր միջազգային գրացուցակին շտապ օգնության համարները և տեղեկացրեք ձեր ազգային կիբեր միջադեպերի արձագանքման թիմին (ինչպես, օրինակ, CISA Միացյալ Նահանգներում 1-844-SAY-CISA կամ NCSC Միացյալ Թագավորությունում) անմիջապես: Առևտրային, շահույթ չհետապնդող և անձնական տիրույթի բոլոր ճգնաժամերի դեպքում կատարեք ստորև բերված տրիաժի քայլերը ճշգրիտ հերթականությամբ:

Արեք սա հիմա¶

1. 30 վայրկյանում որոշեք, թե արդյոք ձեր տիրույթի ժամկետը սպառվել է, ձեր DNS գրառումները փոփոխվել են, թե տիրույթը փոխանցվել է օտարերկրյա գրանցողին. RDAP կամ WHOIS հարցում և հեղինակավոր DNS հարցում տերմինալից (rdap yourdomain.com կամ whois yourdomain.com, և dig +trace yourdomain.com) Ստուգեք Գրանցողի անունը, EPP կարգավիճակի կոդերը (օրինակ clientHold վճարման/ստուգման համար ընդդեմ. ok անծանոթ անունների սերվերներով), և Հեղինակավոր անունների սպասարկիչներ (NS).
2. Անմիջապես սառեցրեք բոլոր ելքային գաղտնաբառերի վերակայումները և կողպեք ձեր ինքնության մատակարարին (Okta, Microsoft Entra ID, Google Workspace). Եթե հարձակվողը վերահսկում է ձեր տիրույթը MX գրառումներ կամ NS սերվերներ, նրանք ստանում են յուրաքանչյուր նամակ ուղարկված *@yourdomain.com. Անմիջապես հանձնարարեք ձեր ՏՏ ադմինիստրատորներին անջատել «Մոռացել եք գաղտնաբառը էլփոստի միջոցով» ինքնասպասարկման վերակայումները բոլոր կորպորատիվ գործիքներում, չեղյալ համարել ակտիվ նիստերն այն օգտատերերի համար, որոնց էլ. .onmicrosoft.com հետադարձ տիրույթներ.
3. Պահպանեք RDAP/WHOIS-ի, DNS գոտիների և Վկայագրի թափանցիկության ամբողջական դատաբժշկական նկարները (CT) տեղեկամատյաններ, նախքան որևէ բան փոխվելը. Պահպանեք ելքը dig ANY yourdomain.com @8.8.8.8, whois yourdomain.comև ստուգեք crt.sh/?q=%25.yourdomain.com անմիջապես. Որոնում crt.sh բացահայտում է բոլոր չարտոնված SSL/TLS վկայականը, որը հարձակվողը հենց նոր մշակել է ձեր ենթադոմեյնների համար (mail., vpn., login., api.) այնպես որ դուք հստակ գիտեք, թե որ ներքին ծառայություններն են նրանք ակտիվորեն նմանակում հակառակորդի միջինում (AitM) վստահված անձանց միջոցով:
4. Կապվեք կորցրած գրանցողի հատուկ արտակարգ իրավիճակների չարաշահումների/անվտանգության գործառնությունների թիմի հետ (ոչ թե 1-ին մակարդակի զրույցի աջակցություն)՝ ICANN-ի չարտոնված փոխանցման վեճ առաջացնելու համար (IRTP) կամ Registry Lock-ի հակադարձում. Եթե ձեր տիրույթը տեղափոխվել է մեկ այլ հաշիվ նույն ռեգիստրատորում կամ փոխանցվել է գողացվածի միջոցով Auth-Info (EPP) ծածկագրեք օտարերկրյա գրանցողին, կապվեք ձեր սկզբնական գրանցողի Դոմենի չարաշահման / Բարձր ռիսկի անվտանգության ընդլայնման գրասենյակի հետ և խնդրեք անհապաղ Գրանցողից հետարկել / Արտակարգ իրավիճակների փոխանցման վեճ՝ համաձայն ICANN-ի փոխանցման քաղաքականության (Section I.A և Transfer Dispute Resolution Policy), վկայակոչելով հավատարմագրերի չարտոնված փոխզիջումը:
5. Անմիջապես դեպի վերին մակարդակի տիրույթի (TLD) ռեեստրի օպերատոր, եթե գրանցողը չի արձագանքում. Հիշեք հիերարխիան. Գրանցողները (ինչպես GoDaddy, Namecheap, Cloudflare, MarkMonitor, Network Solutions, Gandi, Porkbun) պարզապես մանրածախ վերավաճառողներ են; Ռեեստրի օպերատորը (օրինակ՝ Verisign համար .com/.net, Հանրային շահերի ռեգիստր (PIR) համար .org, Նոմինետ համար .uk, CIRA համար .ca, ԴԵՆԻԿ համար .de, կամ auDA համար .au) գործարկում է հիմնական արմատային գոտու տվյալների բազան: Երկրի կոդը (ccTLD) գրանցամատյանները և մի քանի gTLD գրանցամատյաններ կարող են արտակարգ իրավիճակ ներկայացնել serverHold կամ serverUpdateProhibited կողպեք ուղղակիորեն արմատային մակարդակում ստուգված կիբերհանցագործությունների ժամանակ:
6. ** Զգուշացրեք հաճախորդներին, վաճառողներին և բանկային գործընկերներին ցանցից դուրս ալիքների միջոցով @yourdomain.com էլփոստը վտանգված է**. Եթե հարձակվողը հափշտակել է ձեր MX գրառումները, նրանք անմիջապես կպատասխանեն հաշվապահական գծերի բացմանը կեղծ դրամական փոխանցման հրահանգներով: Տեղեկացրեք հաճախորդներին հեռախոսի, SMS-ի, LinkedIn-ի, կարգավիճակի էջի միջոցով առանձին պահուստային տիրույթում կամ սոցիալական մեդիայի պաշտոնական հաշիվների միջոցով, որ չվստահեն որևէ էլփոստի կամ մուտքի պորտալ տուժած տիրույթում, մինչև վերականգնումը հաստատվի:

Որոշումների ծառ. ախտորոշում և պարունակում է տիրույթի կամ DNS անջատում¶

Հետևեք այս արագ ախտորոշիչ սխեմային՝ մատնանշելու համար Դոմենների Անունների համակարգի ճշգրիտ շերտը, որը ձախողվել է կամ առևանգվել է.

flowchart TD
    A["Կայքի աշխատանքը դադարեցվել է, TLS վկայագրի նախազգուշացումը կամ կորպորատիվ էլ"] --> B["Գործարկեք RDAP/WHOIS և փորեք + հետք արտաքին ցանցից"]
    B --> C{"Ի՞նչ են ցույց տալիս RDAP կարգավիճակի և գրանցողի դաշտերը:"}
    C -->|"Կարգավիճակը՝ clientHold, autoRenewPeriod կամ RedemptionPeriod"| D["Պատահական ժամկետանց կամ ICANN Whois ստուգման կասեցում"]
    D --> E["Անմիջապես մուտք գործեք ռեգիստր. Վճարեք նորացման / մարման վճար կամ սեղմեք RAA ստուգման հղումը; Հայցեք Արտակարգ TTL Flush"]
    C -->|"Գրանցողի անունը կամ գրանցողի հաշիվը փոխվել է առանց թույլտվության"| F["Ամբողջական ռեգիստրի հաշվի առևանգում կամ EPP չարտոնված փոխանցում"]
    F --> G["Կողպեք ինքնության մատակարարը (Entra/Google), Ֆայլերի շտապ օգնության գրանցման չարաշահման տոմս + ICANN փոխանցման վեճ, ստուգեք crt.sh-ը խարդախ վկայականների համար"]
    C -->|"Գրանցողը և NS-ն անփոփոխ են, բայց A / CNAME / MX գրառումները մատնանշում են անհայտ IP-ներ"| H["Կառավարվող DNS մատակարարի փոխզիջում (Cloudflare / Route53 / NS1 API բանալի կամ հաշվի խախտում)"]
    H --> I["Չեղարկել վտանգված DNS API-ի նշանները, վերականգնել հայտնի լավ գոտու ֆայլը, չեղարկել Rogue TLS վկայագրերը, պտտել բացված հավատարմագրերը"]
    C -->|"Գրանցող, NS և Zone գրառումները նորմալ տեսք ունեն, բայց կայքը ձախողվում է SERVFAIL-ով"| J["Կոտրված DNSSEC վստահության շղթա (DS ռեկորդային անհամապատասխանություն կամ ժամկետանց RRSIG)"]
    J --> K["Գործարկեք DNSViz.net ստուգում. Հեռացրեք Stale DS Record-ը գրանցամատյանում կամ Re-sign Zone-ը DNS Host-ում:"]

Փուլ 1. Տեխնիկական դատաբժշկական փորձաքննություն՝ ճշգրիտ հարձակման վեկտորը բացահայտելու համար¶

Երբ տիրույթը հանկարծ դադարում է լուծել կամ սկսում է սպասարկել ֆիշինգի էջ կամ կրիպտոարժույթի խարդախություն, գուշակությունների վրա ծախսված յուրաքանչյուր րոպեն վատնում է վերականգնման թանկարժեք ժամանակը: Գոյություն ունեն չորս բոլորովին տարբեր սցենարներ, որոնք նույնական են վեբ բրաուզերում վերջնական օգտագործողին, և յուրաքանչյուրը պահանջում է բոլորովին այլ ուղղում:

Ինչպես կարդալ RDAP, WHOIS, և dig Արդյունքներ, ինչպես միջադեպի արձագանքողը¶

Բացեք հրամանի տերմինալ Linux-ում, macOS-ում կամ Windows-ում (օգտագործելով WSL կամ nslookup) և կատարեք հետևյալ երեք ախտորոշիչ ստուգումները՝ օգտագործելով չեզոք հանրային ռեկուրսիվ լուծիչ (8.8.8.8 կամ 1.1.1.1):

1. ** Ստուգեք ռեեստրի մակարդակի պատվիրակությունը (dig +trace և RDAP)**:

   dig +trace yourdomain.com NS @1.1.1.1
   

   • Նայեք քայլին անմիջապես TLD արմատային սերվերներից հետո (օրինակ, a.gtld-servers.net. համար .com) Որը NS (Nameserver) հոսթների անունները վերադարձվում են հենց TLD ռեգիստրի կողմից:
   • Եթե TLD ռեգիստրը վերադարձնում է ձեր սովորական անունների սերվերները (ns1.yourdnsprovider.com) կարգավիճակով NOERROR, առևանգումը տեղի է ունենում ձեր DNS հոստինգի մատակարարի ներսում (կամ դա DNSSEC-ի խախտում է):
   • Եթե TLD ռեգիստրը վերադարձնում է բոլորովին անծանոթ անունների սերվերներ (կամ եթե whois yourdomain.com ցույց է տալիս նոր Registrar: անունը և ան Updated Date: վերջին մի քանի ժամերի կամ օրերի ընթացքում), առևանգումը տեղի է ունեցել Դոմեն ռեգիստրի մակարդակում:
2. Վերծանեք ICANN EPP տիրույթի կարգավիճակի կոդերը. Նայեք Domain Status: տողեր քո մեջ WHOIS կամ RDAP ելքը։ Այս ստանդարտացված Extensible Provisioning Protocol (EPP) կոդերը պատմում են ձեզ, թե ինչու է տիրույթը ձախողվում կամ արգելափակված.

Փուլ 2. Վերականգնում վնասակար տիրույթի առևանգումից կամ ռեգիստրի չարտոնված փոխանցումից¶

Հարձակվողներն առևանգում են բարձրարժեք կորպորատիվ, Web3/DeFi, ֆինանսական և մեդիա տիրույթները՝ օգտագործելով երեք հիմնական տեխնիկա. 1. Գրանցողի հաշվի գրավում (հավատարմագրերի լցոնում, Infostealer չարամիտ ծրագիր կամ SIM-ի փոխանակում). հարձակվողը մուտք է գործում ձեր GoDaddy, Namecheap, Google Domains/Squarespace կամ Network Solutions վահանակ, անջատվում է: clientTransferProhibited, փոխում է NS գրառումներ՝ մատնանշելու հարձակվողի կողմից վերահսկվող Cloudflare հաշիվը կամ առաջացնում է Auth-Info (EPP) կոդը՝ տիրույթը դուրս փոխանցելու համար: 2. Գրանցողի աջակցության սոցիալական ճարտարագիտություն. հարձակվողը ներկայացնում է գրանցման կեղծ փաստաթղթեր, կեղծ պետական ​​անձը հաստատող փաստաթղթեր կամ կեղծված բլանկներ ռեգիստրի հաշվի վերականգնման գրասեղանինպնդելով, որ սկզբնական ՏՏ ադմինիստրատորը մահացել է կամ հեռացել է ընկերությունից: 3. ** Ենթադոմեյնի գրավում (Dangling CNAME/Dangling NS)**. Ձեր հիմնական տիրույթն անձեռնմխելի է, բայց հին ենթադոմեյն է (promo.yourdomain.comկամstatus.yourdomain.com) դեռ ունի աCNAME` գրառում, որը ցույց է տալիս շահագործումից հանված AWS S3 դույլը, Azure App Service, GitHub Pages ռեպո, Heroku հավելվածը կամ Zendesk օրինակը, որը դուք ջնջել եք ամիսներ առաջ: Հարձակվողը գրանցում է այդ լքված ամպային ռեսուրսի անունը AWS/Azure/GitHub-ում և անմիջապես սպասարկում է վնասակար բովանդակություն ձեր պաշտոնական ենթատիրույթից:

Քայլ 1. Վտարեք հարձակվողին ձեր ամպային ինքնության մատակարարից և էլփոստի համակարգից¶

Նախքան նույնիսկ ավարտեք գրանցողի վերականգնման ձևը լրացնելը, ենթադրեք, որ հարձակվողն ակտիվորեն կարդում է ձեր տիրույթ ուղարկված յուրաքանչյուր նամակ և փորձում է շրջել ձեր ներքին ամպային ենթակառուցվածքի մեջ.

1. Անցեք Microsoft 365 / Google Workspace-ը հետընտրական տիրույթների և ապարատային MFA-ի.
   • Microsoft Entra ID-ում (նախկինում՝ Azure AD), յուրաքանչյուր վարձակալ ունի մշտական, անառողջ հետադարձ տիրույթ (yourcompany.onmicrosoft.com) Ադմինիստրատորները կարող են մուտք գործել միջոցով admin@yourcompany.onmicrosoft.com նույնիսկ եթե yourdomain.com DNS-ն ամբողջությամբ առևանգված է:
   • Անջատեք SMS-ի, ձայնային զանգի և էլփոստի գաղտնաբառի վերակայման բոլոր եղանակները Entra ID-ում/Okta/Google Workspace-ում (Authentication Methods Policy) Պահանջվում է FIDO2/WebAuthn ապարատային անվտանգության բանալիներ կամ թվերի համապատասխանող Authenticator push ծանուցումներ:
2. **Աուդիտ ելքային և ներգնա էլփոստի մատյանները ճշգրիտ փոխզիջման պատուհանի համար **:
   • Եթե ​​ձեր MX գրառումները փոխվել են ժամը 02:14 UTC-ին, 02:14 UTC-ից 02:14 UTC-ից զրոյական օրինական արտաքին էլփոստեր են հասել ձեր իրական փոստային սերվերներին; Այդ պատուհանի ընթացքում ձեր անձնակազմին ուղարկված յուրաքանչյուր արտաքին էլ-նամակ ամբողջությամբ պարզ տեքստով նկարահանվել է հարձակվողի սրիկա փոստային սերվերի կողմից (Postfix/Exim ունկնդիր):
   • Անմիջապես քաշեք յուրաքանչյուր երրորդ կողմի SaaS պլատֆորմի, բանկի, AWS/GCP արմատային հաշվի, GitHub կազմակերպության և վաճառողի պորտալի ցուցակը, որոնք կապված են: @yourdomain.com էլփոստի հասցեները և ստուգեք, թե արդյոք հարձակվողը գաղտնաբառի վերականգնում է գործարկել այդ արտաքին հարթակներում առևանգման պատուհանի ժամանակ:

Քայլ 2. Կատարեք ռեգիստրի և ռեգիստրի արտակարգ իրավիճակների վերականգնման արձանագրությունը¶

Մի բացեք ընդհանուր «Իմ կայքը չի աշխատում» աջակցության զրույցը: Դուք պետք է օգտագործեք ճշգրիտ կարգավորող և իրավական տերմինաբանությունը, որը խթանում է էսկալացիան Գրանցողի մակարդակի 3 անվտանգության / Գլխավոր խորհրդատուի / ICANN-ի համապատասխանության թիմին.

1. Դեպ Ա. Դոմենը դեռ գտնվում է ձեր սկզբնական գրանցամատյանում (Հաշվի տիրացում կամ ներքին «Հաշվի մղում»):
   • Շատ հարձակվողներ չեն սպասում 5 օր միջգրանցման EPP փոխանցման համար. փոխարենը, նրանք օգտագործում են գրանցողի ակնթարթային «Դոմենը մեկ այլ հաշիվ մղել» հատկությունը, որպեսզի ձեր տիրույթը տեղափոխեն այրիչ հաշիվ նույն գրանցամատյանում 3 վայրկյանում:
   • Անմիջապես զանգահարեք և էլեկտրոնային փոստով գրանցեք գրանցողի Խարդախության/Հաշիվների առևանգման/Չարաշահման բաժին: Հստակ նշեք. «ԱՆՎՏԱՆԳՈՒԹՅԱՆ ՇՏԱՊ ԴԵՊՔ. Չլիազորված հաշվում մուտք և ներքին տիրույթի սեղմում / DNS փոփոխություն [yourdomain.com]-ում: Դոմենի անհապաղ սառեցում պահանջվում է տակ serverHold/clientUpdateProhibited և չթույլատրված DNS/Հաշվի փոփոխությունների հետ վերադարձ։
   • Անմիջապես հավաքեք ձեր պատմական սեփականության ապացույցի փաթեթը. Գրանցող անվտանգության թիմերը պահանջում են անհերքելի ապացույցներ, որ դուք նախկին օրինական գրանցողն եք, նախքան նրանք տիրույթը հետ կհանեն մեկ այլ հաշվից: Անմիջապես հավաքեք այս 5 փաստաթղթերը մեկ PDF-ի մեջ.
     1. Պատմական ռեգիստրի հաշիվ-ապրանքագրեր և վճարման ապացույցներ. PDF անդորրագրեր և վարկային քարտերի/բանկային քաղվածքներ, որոնք ցույց են տալիս, որ ձեր կազմակերպությունը վճարում է գրանցման և նորացման համար: yourdomain.com վերջին 1-ից 10 տարիների ընթացքում (ներառյալ վճարային քարտի վերջին 4 թվանշանները կամ թղթային տեղեկանքը):
     2. Կառավարության կողմից թողարկված կորպորատիվ գրանցում և պաշտոնատար անձի ID. Հիմնադրման պաշտոնական վկայական / Կազմակերպության կանոնադրությունը համապատասխանում է պատմական WHOIS-ին Registrant Organization, գումարած հավատարմագիրը ստորագրող կորպորատիվ աշխատակցի անձը հաստատող փաստաթուղթը լուսանկարով:
     3. Պատմական DNS գոտու ֆայլի և սերվերի սեփականության ապացույց. Ձեր նախկին DNS գոտու ֆայլի պատճենները, WHOIS-ի պատմական նկարները կամ ապացույցն այն մասին, որ ձեր կազմակերպությանն է պատկանում ինքնավար համակարգը (ASN) կամ IP բլոկներ (A գրառումներ), որոնց տիրույթը մատնանշում էր այսօրվա փոփոխությունից տարիներ առաջ:
     4. Հաշվի ստեղծման սկզբնական էլ.փոստ/տոմսերի պատմություն. Գրանցողից ստացված նամակների վերնագրերը այն պահին, երբ տիրույթն ի սկզբանե գրանցվել է կամ նորացվել:
     5. Իրավապահ մարմինների պաշտոնական հաշվետվության համարը. ներկայացվել է FBI IC3 (ic3.gov) բողոքի համարը (Միացյալ Նահանգներ), Գործողությունների խարդախության հղման համարը (Միացյալ Թագավորություն) կամ ազգային ոստիկանության կիբերհանցագործության մասին հաշվետվության համարը: Գրանցողներն ավելի արագ են գործում, երբ իրավապահ մարմիններին տրվում է գործի պաշտոնական համար, որը հաստատում է 18 U.S.C.-ի տակ գտնվող քրեական համակարգչային ներխուժումը: § 1030 (CFAA) կամ Միացյալ Թագավորության Համակարգիչների չարաշահման մասին օրենքը 1990 թ.
2. ** Դեպք B. տիրույթը փոխանցվել է մեկ այլ գրանցողին (Միջգրանցիչի առևանգում)**.
   • ICANN Փոխանցման քաղաքականության (նախկինում IRTP) համաձայն, միջգրանցող փոխանցումը պահանջում է. Auth-Info (EPP) կոդը և պետք է արգելափակվի 60 օրով՝ գրանցվողի որոշակի փոփոխություններից հետո, եթե չհրաժարվենք: Եթե ​​հարձակվողը կոտրել է ձեր հաշիվը Գրանցող A-ում («Կորցնող Ռեգիստրը») և տիրույթը փոխանցել Գրանցող B-ին («Ձեռք բերող գրանցող»).
   • Անմիջապես կապվեք և՛ պարտվող գրանցողի, և՛ շահող գրանցողի հետ, բայց առաջնահերթություն տվեք Կորցնող գրանցողի փոխանցման վեճը/անվտանգության թիմին: Համաձայն ICANN-ի Տրանսֆերային վեճերի լուծման քաղաքականության (TDRP), պարտվող գրանցողն այն կազմակերպությունն է, որն ունի ձեր պատմական հաշվարկային գրառումները և մուտքի գրանցամատյանները, որոնք ապացուցում են, որ փոխանցումը չարտոնված է: Պարտվող գրանցողը կարող է պաշտոնապես կապվել Գինինգ գրանցողի համապատասխանության պատասխանատուի հետ՝ իրականացնելու կոոպերատիվ Գրանցողի փոխանցման հետարկումը կամ ներկայացնելու պաշտոնական TDRP վարույթ:
   • Միաժամանակ ուղարկեք ձեր սեփականության իրավունքի ապացույցների փաթեթը և ոստիկանության հաշվետվությունը Ձեռք բերող գրանցողի չարաշահումների գրասենյակ՝ պահանջելով, որ նրանք անհապաղ ներկայացնեն clientTransferProhibited և clientUpdateProhibited կողպեք տիրույթը, որպեսզի հարձակվողը չկարողանա դոմենը ցատկել ևս երեք օֆշորային գրանցողների շղթայի միջով («գրանցող վազք»):
3. Ներկայացրեք արտակարգ իրավիճակների էսկալացիա ICANN-ի հետ (օրինակ՝ gTLD-ների համար .com, .net, .org, .io եթե gTLD) կամ ccTLD գրանցամատյան:
   • Եթե ​​գրանցողը հրաժարվում է հետաքննել չարտոնված փոխանցումը կամ չի արձագանքում ակտիվ առևանգման ժամանակ, ներկայացրեք հրատապ Չարտոնված փոխանցման/Դոմենի առևանգման բողոք ICANN պայմանագրային համապատասխանության պորտալի միջոցով (icann.org/compliance/complaint).
   • Եթե ​​ձեր տիրույթն օգտագործում է Երկրի կոդի վերին մակարդակի տիրույթ (ccTLD), ինչպես, օրինակ .uk, .ca, .au, .de, .fr, .nl, .ch, կամ .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 գրանցում է կայանված/ժամկետանց նորացման էջ կամ տեղադրում է տիրույթը -ումclientHold.
   • Ազդեցություն. Ձեր կայքը և կորպորատիվ էլ.փոստը անմիջապես դադարում են աշխատել (DNS_PROBE_FINISHED_NXDOMAIN կամ կայանատեղիների գովազդ):
   • Վերականգնում. Մուտք գործեք գրանցողի հաշիվ և վճարեք ստանդարտ 1 տարվա նորացման վճարը ($10-ից $30 USD): Գրանցողն անմիջապես վերականգնում է ձեր բնօրինակը NS գրառումներ.
2. Փուլ 2. մարման արտոնյալ ժամանակաշրջան (redemptionPeriod, 30 օր Տևողություն):
   • Եթե ​​ոչ ոք չի թարմացնում տիրույթը 1-ին փուլի ընթացքում (սովորաբար 30-ից 42-րդ օրվանից հետո՝ կախված ռեգիստրի ծառայության պայմաններից), գրանցողը ջնջում է տիրույթը Ռեեստրում, և Ռեեստրն այն դնում է պարտադիր 30-օրյա :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):
   • 30 օրը մեկ անգամ 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 կամ 172800 seconds). Even after you pay the renewal bill and your registrar restores your real NS records in the root zone within 5 minutes, public recursive DNS resolvers around the world (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9, և ISP-ի լուծումներ) կարող են շարունակել սպասարկել քեշավորված ժամկետանց կայանման էջը մինչև այդ 48-ժամյա TTL-ի ժամկետի ավարտը:

Ինչպե՞ս ստիպել ակնթարթային գլոբալ DNS քեշի մաքրումը 60 վայրկյանում: Մի սպասեք 48 ժամ, որպեսզի ռեկուրսիվ քեշերը բնականաբար ավարտվեն: Ձեռքով մաքրեք ձեր տիրույթը գլոբալ երեք խոշորագույն հանրային DNS պրովայդերներից հենց հիմա՝ օգտագործելով իրենց անվճար վեբ քեշի մաքրման պորտալները. 1. ** Լվացեք Google Հանրային DNS (8.8.8.8 / 8.8.4.4): Այցելեք developers.google.com/speed/public-dns/cache, տեսակ yourdomain.comընտրեք գրառման տեսակը NS (և այնուհետև կրկնել A, AAAA, MX, և DS), և սեղմեք Flush Cache: Սա մաքրում է ձեր տիրույթը աշխարհի բոլոր Google DNS տվյալների կենտրոնում 10 վայրկյանից պակաս ժամանակում: 2. Flush Cloudflare հանրային DNS (1.1.1.1 / 1.0.0.1): Այցելեք one.one.one.one/purge-cache/, մուտքագրեք yourdomain.com, ընտրել NS, A, AAAA, և MX և սեղմեք ** Մաքրել քեշը: 3. Flush OpenDNS / Cisco Umbrella (208.67.222.222): Այցելեք cachecheck.opendns.com, մուտքագրեք yourdomain.com, ստուգեք արդյունքները գլոբալ հանգույցներում և սեղմեք Թարմացնել քեշը աղյուսակի ներքևի մասում։

Փուլ 4. կոտրված DNSSEC-ի շտկում (SERVFAIL) միգրացիայից կամ առևանգումից հետո¶

Domain Name System Security Extensions (DNSSEC) ծածկագրորեն ստորագրում է ձեր DNS գրառումները (RRSIG գրառումներ՝ ստորագրված Zone Signing Key-ով ZSK և Key Signing Key KSK) և հրապարակում է համապատասխան պատվիրակության ստորագրող (DS) հեշը ձեր գրանցամատյանի մայր TLD գոտում:

Մինչ DNSSEC-ը կանխում է քեշի թունավորումը, խախտված DNSSEC կոնֆիգուրացիան առաջացնում է ակնթարթային, ընդհանուր գլոբալ անջատում (SERVFAIL) յուրաքանչյուր վավերացնող լուծիչի վրա (ներառյալ 8.8.8.8, 1.1.1.1, Comcast և հիմնական բջջային օպերատորներ): Ամենից հաճախ դա տեղի է ունենում արտակարգ իրավիճակների միգրացիայի ժամանակ. ադմինիստրատորը տեղափոխվում է yourdomain.com-ի անունների սերվերները Cloudflare-ից մինչև AWS Route 53 (կամ հակառակը), առանց նախապես ջնջելու հին մատակարարի DS գրանցել տիրույթի գրանցամատյանում:

DNSSEC-ի ախտորոշում և վերանորոգում SERVFAIL Լոկաուտ 5 րոպեում¶

1. Հաստատեք, որ DNSSEC-ը մեղավոր է. Վազիր երկու dig հրամաններ իրար հետեւից. մեկ սովորական հարցում և մեկ հարցում +cd (Ստուգելով անջատված է) դրոշակ, որը ռեկուրսիվ լուծիչին ասում է անտեսել DNSSEC ծածկագրային վավերացումը.

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

   • Եթե ​​առաջին հրամանը ձախողվի status: SERVFAIL և զրոյական պատասխաններ, մինչդեռ երկրորդ հրամանը (+cd) անմիջապես հաջողվում է status: NOERROR և վերադարձնում է ձեր A գրանցեք IP հասցեն, Ձեր անջատման 100 տոկոսը DNSSEC վստահության կոտրված շղթա է:
2. ** Ստուգեք ճշգրիտ խախտումը DNSViz.net կամ Verisign DNSSEC Debugger**:
   • Բացել dnsviz.net կամ dnssec-debugger.verisignlabs.com և մուտքագրեք yourdomain.com.
   • Այն կնկարի տեսողական դիագրամ, որը ցույց կտա, թե արդյոք DS Ձեր գրանցամատյանում հրապարակված գրառումը չի համապատասխանում DNSKEY սպասարկվում է ձեր ընթացիկ DNS հոսթի կողմից, կամ արդյոք ձեր գոտու ստորագրությունները (RRSIG) ժամկետանց է:
3. Արտակարգ վերականգնում.
   • Եթե նոր եք փոխել DNS-ի մատակարարը. Մուտք գործեք ձեր Դոմեն գրանցող, անցեք DNSSEC / DS Records բաժին և ջնջեք հին հնացածը: DS գրառում (կամ փոխարինել նորով DS ձեր նոր DNS հոսթի կողմից ստեղծված գրառումը):
   • ** Լվացեք DS ռեկորդային քեշ**. Անմիջապես այցելեք Google Public DNS Cache Flush (developers.google.com/speed/public-dns/cache) և Cloudflare Purge Cache (one.one.one.one/purge-cache/) և մաքրել DS և DNSKEY ռեկորդային տեսակների համար yourdomain.com այնպես որ վավերացնող լուծիչները դադարում են ստուգել ջնջվածները DS հաշվել անմիջապես:

Փուլ 5. Վերականգնումից հետո մաքրում, TLS վկայագրի չեղարկում և կարծրացում¶

Ձեր տիրույթի գրանցողի հաշիվը և DNS գրառումները ձեր վերահսկողության տակ վերադարձնելը գործի միայն կեսն է: Այն ժամերի կամ օրերի ընթացքում, երբ հարձակվողը վերահսկում էր ձեր տիրույթի DNS-ը, նրանք լիակատար լիազորություններ ունեին ապացուցելու «Դոմենի վերահսկման վավերացումը» (DCV) յուրաքանչյուր սերտիֆիկատի մարմնին (CA) մոլորակի վրա։

1. Աուդիտի վկայականի թափանցիկության մատյաններ (crt.sh) և չեղյալ համարել Rogue TLS վկայականները¶

Երբ հարձակվողը ցույց է տալիս ձեր A կամ NS գրառումները իրենց սերվերին, նրանք անմիջապես գործարկվում են certbot (Եկեք գաղտնագրենք, ZeroSSL, Google Trust Services կամ Sectigo)՝ վավեր, զննարկիչի կողմից վստահված TLS վկայագրեր ստեղծելու համար։ yourdomain.com, *.yourdomain.com, vpn.yourdomain.com, և mail.yourdomain.com. Նույնիսկ ձեր DNS գրառումները վերականգնելուց հետո հարձակվողը դեռևս պահպանում է վավեր Անձնական բանալին (.key) և ստորագրված Հանրային վկայական (.crt) ձեր տիրույթի համար, որը նրանք կարող են օգտագործել գերի-պորտալի Wi-Fi գրոհների, BGP-ի առևանգումների կամ ներքին ցանցի կեղծման համար հաջորդ 90 օրվա ընթացքում:

1. Հարցման վկայականի թափանցիկության մատյաններ:
   • Գնալ դեպի crt.sh/?q=%25.yourdomain.com կամ Censys վկայականի որոնում (search.censys.io/certificates).
   • Դասավորել ըստ Logged At / Not Before ամսաթիվը և ստուգեք յուրաքանչյուր վկայական, որը տրվել է առևանգման պատուհանի ընթացքում (և վերականգնումից հետո 24 ժամվա ընթացքում, քեշավորված DCV թույլտվությունների պատճառով):
2. Ստիպել անհապաղ չեղյալ համարել վկայական.
   • Բացահայտեք թողարկող Վկայագրի մարմինը (Issuer Name) յուրաքանչյուր չարտոնված վկայականի վրա:
   • Հանրության կողմից վստահված յուրաքանչյուր CA պահանջվում է CA/Browser Forum-ի ելակետային պահանջների համաձայն (բաժին 4.9.1.1)՝ չեղյալ համարել կեղծ կամ չարտոնված վկայականը 24 ժամվա ընթացքում՝ հաստատելու, որ հայտատուն լիազորված չէ իրական տիրույթի սեփականատիրոջ կողմից:
   • Եթե ​​դուք արդեն վերականգնել եք DNS վերահսկողությունը տիրույթի վրա, կարող եք չեղարկել չարտոնված Let's Encrypt կամ ACME վկայականները ինքներդ 60 վայրկյանում՝ առանց նույնիսկ հարձակվողի անձնական բանալի կարիքի. պարզապես տեղադրեք: certbot Ձեր կողմից վերահսկվող սերվերի վրա, փոխանցեք թարմ DNS-01 կամ HTTP-01 մարտահրավեր նույն տիրույթի անվան համար՝ օգտագործելով բոլորովին նոր ACME հաշվի բանալի և գործարկեք.

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

   • Այլապես, ներկայացրեք Վկայականի սերիական համարները անմիջապես CA-ի արտակարգ իրավիճակների չեղարկման պորտալին (օրինակ՝ Let's Encrypt-ի չեղարկման հրահանգների էջը, DigiCert-ի /revoke պորտալը կամ Sectigo-ի SSL չարաշահման հաշվետվության ձևը):

2. Մշտապես փակեք ձեր տիրույթը, որպեսզի այն այլևս երբեք չառևանգվի¶

Գործողությունները վերականգնվելուց հետո կիրառեք ձեռնարկության տիրույթի կարծրացման այս հինգ հսկիչները.

1. ** Միացնել ռեեստրի կողպումը (serverUpdateProhibited, serverDeleteProhibited, serverTransferProhibited)**:
   • Առաքելության համար կարևոր արտադրական տիրույթների համար թարմացրե՛ք գրանցողին, որն առաջարկում է իրական Registry Lock (աջակցվում է Verisign-ի կողմից .com/.net, PIR միացված է .orgև առաջարկվում է ձեռնարկությունների գրանցողների միջոցով, ինչպիսիք են MarkMonitor, CSC Digital Brand Services, Cloudflare Enterprise, Porkbun/Gandi/Namecheap Registry Lock մակարդակները): Registry Lock-ի ակտիվ դեպքում, նույնիսկ եթե հաքերը գողանում է ձեր գրանցամատյանի մուտքն ու ԱԳՆ-ն, TLD ռեգիստրը մերժում է բոլորը NS կամ փոխադրումը փոխվում է, եթե մարդկային անվտանգության աշխատակիցը չի ավարտում գաղտնագրման/հեռախոսային արարողություն առանց խմբի:
2. ** Հրապարակել CAA (Սերտիֆիկացման մարմնի թույլտվություն) DNS գրառումներ**:
   • Ավելացնել ա CAA գրառում (RFC 8659) ձեր DNS գոտում՝ նշելով հավաստագրման ճշգրիտ մարմինները, որոնք թույլ են տալիս ձեր տիրույթի համար տրամադրել TLS վկայագրեր (օրինակ՝ 0 issue "letsencrypt.org" կամ 0 issue "digicert.com", գումարած 0 iodef "mailto:security@yourdomain.com") Մինչ հարձակվողը, ով վերահսկում է ձեր ամբողջ DNS գոտին, կարող է ջնջել ա CAA արձանագրություն, ա CAA գրառումը դադարեցնում է BGP առևանգողներին կամ վտանգված ենթադոմեյնի CNAME թիրախներին չարտոնված CA-ների օգտագործումը:
3. Առանձնացրեք ձեր տիրույթի ռեգիստրը ձեր ամենօրյա DNS հոստինգի մատակարարից.
   • Պահպանեք ձեր տիրույթի գրանցումը կողպված բարձր անվտանգության պահոց գրանցողի հաշվում, որին կարող են մուտք գործել միայն 2 կորպորատիվ աշխատակիցներ՝ օգտագործելով FIDO2 ապարատային անվտանգության բանալիները (YubiKey), և պատվիրակեք ամենօրյա DNS գրառումների կառավարումը (A, CNAME, TXT) առանձին կառավարվող DNS ծառայությանը՝ մանրազնին դերի վրա հիմնված մուտքի վերահսկումով (RBAC) և ընդգրկված API նշաններով:
4. ** Աուդիտ և վերացրեք կախվող ենթադոմեյնը CNAME և NS Գրառումներ **:
   • Գործարկեք ձեր ամբողջ DNS գոտու ֆայլի ամսական ավտոմատացված սկանավորում (subzy, nuclei -t takeovers/, կամ OWASP Amass)՝ ցանկացածը բացահայտելու համար CNAME, ALIAS, կամ ենթադոմեյն NS գրառում, որը ցույց է տալիս չգրանցված արտաքին ամպային ռեսուրսը կամ ժամկետանց տիրույթը, և ջնջեք DNS գրառումը մինչև ամպային սերվերը շահագործումից հանելը:
5. Կարգավորեք ավտոմատացված արտաքին RDAP, DNS և CT մատյանների մոնիտորինգ:
   • Կարգավորեք արտաքին մոնիտորը (օրինակ CertSpotter, Cloudflare Վկայագրի թափանցիկության մոնիտորինգ կամ պարզ ամենժամյա cron սցենարի ստուգում dig NS և whois) որը ծանուցում է հատուկ Slack/PagerDuty ալիքին և տիրույթից դուրս SMS/էլփոստի հասցեին, հենց այն պահին, երբ նոր TLS վկայականը մուտք է գործում Վկայագրի թափանցիկություն կամ NS/MX/DS արձանագրել փոփոխություններ.

Հաճախակի տրվող հարցեր¶

Աղբյուրները ստուգված են¶

• Կիբերանվտանգության և ենթակառուցվածքների անվտանգության գործակալություն (CISA, Միացյալ Նահանգներ).cisa.gov/news-events/directives/emergency-directive-19-01)
• Ինտերնետ կորպորացիա նշանակված անունների և համարների համար (ICANN, միջազգային). Փոխանցման քաղաքականություն (Միջգրանցման փոխանցման քաղաքականություն / IRTP), Փոխանցման վեճերի լուծման քաղաքականություն (TDRP), Ժամկետանց գրանցման վերականգնման քաղաքականություն (ERRP) և * EPP կոդերicann.org/resources/pages/epp-status-codes-2014-06-16-en)
• Ստանդարտների և տեխնոլոգիաների ազգային ինստիտուտ (NIST, Միացյալ Նահանգներ). Հատուկ հրապարակում 800-81-2, Անվտանգ տիրույթի անունների համակարգի (DNS) տեղակայման ուղեցույց (csrc.nist.gov)
• Կիբերանվտանգության ազգային կենտրոն (NCSC, Միացյալ Թագավորություն). Զանգվածային անձնական տվյալների և տիրույթի անվտանգության պաշտպանություն. ռեեստրի կողպեք, CAA գրառումներ և ենթադոմեյնների գրավման կանխարգելում (ncsc.gov.uk)
• CA/Browser Forum (միջազգային). Հանրային վստահելի TLS սերվերի վկայագրերի թողարկման և կառավարման ելակետային պահանջներ (Բաժին 4.9.1.1. 24-ժամյա պարտադիր չեղարկում տիրույթի փոխզիջման համար) (cabforum.org)
• Ինտերնետ ինժեներական աշխատանքային խումբ (IETF, միջազգային): RFC 4033/4034/4035 (DNSSEC), RFC 8659 (DNS սերտիֆիկացման մարմնի թույլտվություն / CAA ռեսուրսների գրառում), և RFC 9083 (Գրանցման տվյալների մուտքի արձանագրություն / RDAP) (datatracker.ietf.org)

Առնչվող ուղեցույցներ¶

• Վեբ հոստինգի ճգնաժամ, միգրացիա և կրկնօրինակի վերականգնում
• Ֆիշինգ և վտանգված հաշիվներ
• ԱԳՆ ֆիշինգ և հակառակորդի միջի շրջանցում
• Տվյալների խախտման պատասխան և գաղտնաբառի արտահոսք
• Բիզնես փրկագին և սերվերի խախտում
• SIM քարտի փոխանակում