Прекъсване на регистратор на домейн или DNS доставчик: Изтекъл гратисен период за обратно изкупуване на домейн, DNSSEC SERVFAIL Прихващане и спешна миграция на сървър за имена¶

Събуждане, за да откриете, че основният уебсайт на вашата компания, крайни точки на API (api.example.com) и фирмен имейл (MX записи за Google Workspace или Microsoft 365) са напълно недостъпни по целия свят (DNS_PROBE_FINISHED_NXDOMAIN или SERVFAIL) е инфраструктурна криза с пълно затъмнение. За разлика от един повреден уеб сървър, който засяга една услуга, системата за имена на домейни (DNS) или неуспешна регистрация на домейн прекъсва всяка отделна услуга под вашия основен домейн едновременно, включително Single Sign-On (SSO), портали за поддръжка на клиенти и входящи имейли за отговор на инциденти. На практика глобалните прекъсвания на домейни произтичат от три различни причини: (1) случайно изтичане на домейн, при което кредитна карта във файла е изтекла и регистраторът е отвлякъл вашия NS записи, които да сочат към страница за паркиране с плащане на клик 24 to 48 hours преди действителния срок на годност; (2) DDoS атака или прекъсване на контролната равнина при вашия авторитетен DNS доставчик (Route 53, Cloudflare, GoDaddy, Namecheap, DNSimple, NS1); или (3) счупен DNSSEC (DS запис) верига на доверие по време на прибързано превключване на сървъра за имена, което причинява валидиращи резолвери (8.8.8.8, 1.1.1.1, преобразуватели на ISP), с които да намалите 100 процента от трафика си SERVFAIL. Ако нападател е компрометирал идентификационните ви данни за вход в регистратора и е прехвърлил или променил домейна ви злонамерено, преминете към отвличане на име на домейн, изтекъл DNS и превземане на уебсайт; ако вашият TLS сертификат е изтекъл или се е счупил след възстановяване на DNS, вижте Сертификатът SSL/TLS е изтекъл в производството, блокиране на предварително зареждане на HSTS и спешно подновяване и Google Workspace или Microsoft 365 персонализирано блокиране на администратор на домейн и DNS проверка. Ако това прекъсване деактивира болничните клинични комуникации, 911/112 спешни диспечерски маршрути или критични обществени услуги, обадете се на вашия местен номер за спешни повиквания (911 в Съединените щати и Канада, 112 в целия Европейски съюз, 999 в Обединеното кралство) или се консултирайте с нашия указател на номера за спешни случаи.

Направете това сега¶

1. Диагностицирайте за 10 секунди дали повредата е изтекъл/спрян домейн (EPP Status), прекъсване на авторитетен DNS доставчик или a DNSSEC Неуспешно валидиране:
2. Бягай whois yourdomain.com | grep -iE "Status|Expiry|Name Server" и dig +trace yourdomain.com.
3. Тествайте дали байпас DNSSEC валидиране (+cd = Проверката е деактивирана) кара вашия домейн да се разреши отново:

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

   Ако първата команда върне status: SERVFAIL докато втората команда (+cd) веднага се връща status: NOERROR с IP адреса на вашия сървър, вашите DNS сървъри НЕ работят: вашият DNSSEC (DS запис в регистратора) е повреден. Преминете незабавно към фаза 3, за да изтриете застоялото DS запишете при вашия регистратор.
4. Ако вашият домейн е изтекъл (Auto-Renew Grace Period или Redemption Grace Period), незабавно влезте в текущия си регистратор и платете таксата за подновяване/изкупуване; НЕ чакайте домейна да "падне", за да можете да го пререгистрирате евтино:
5. През първите 1 до 45 дни след изтичане (Auto-Renew Grace Period), подновяването в таблото за управление на вашия регистратор възстановява вашите оригинални сървъри за имена на стандартна цена за подновяване ($10 to $30).
6. По време на 30-дневния Redemption Grace Period (RGP / redemptionPeriod), трябва да платите задължителната такса за обратно изкупуване на регистър ($80 to $250) чрез текущия ви регистратор. Ако изчакате домейнът да завърши 5-дневния Pending Delete фаза за запазване $100, автоматизирани снайперски ботове за улавяне на падане (DropCatch, SnapNames, NameJet) ще грабне вашия домейн вътре 5 milliseconds на пускане и го продаде на търг за хиляди долари.
7. НИКОГА не променяйте своите сървъри за имена (NS) далеч от DNS доставчик с активиран DNSSEC (като Cloudflare, Route 53 или Google Cloud DNS), без да премахвате DS първо запишете при вашия регистратор: Ако DNSSEC е активиран и вие разменяте своя NS записва към спасителен DNS доставчик по време на прекъсване, без да изтрива родителския DS (Delegation Signer) запис в .com / .org TLD зона първо, всеки валидиращ преобразувател на Земята ще отхвърли неподписаните отговори на новия DNS доставчик като криптографска атака за подправяне (SERVFAIL).
8. Ако сте заключени от вашата компания @yourdomain.com имейл, защото вашият домейн е MX записите липсват, НЕ кликвайте върху „Изпращане на код за нулиране на паролата до admin@yourdomain.com“ при вашия регистратор: Докато вашият домейн NS или MX записите са офлайн, всеки имейл за потвърждение е изпратен до @yourdomain.com отскача или изчезва в опашка. Използвайте SMS/Удостоверител MFA на вашия регистратор, резервен имейл извън обхвата (@gmail.com / @proton.me), или поток за проверка на самоличността на телефона.
9. След като подновите домейн с изтекъл срок на валидност, проверете ръчно дали вашият регистратор е възстановил оригиналните персонализирани сървъри на имена (NS), вместо да оставите домейна включен sedoparking.com / renewyourname.net: Когато домейнът изтече, регистраторите презаписват вашите персонализирани NS записи със сървъри за имена на паркинг (ns1.parklogic.com, dns1.name-services.com). Понякога плащането на подновяването актуализира датата на изтичане до следващата година, като оставя сървърите на имена за паркиране активни, докато ръчно не ги превключите обратно.
10. Изчистване на глобални публични рекурсивни DNS кешове (Google 8.8.8.8, Cloudflare 1.1.1.1, OpenDNS) вторият твой NS или DS записите се възстановяват: Вместо да чакате 24 до 48 часа за кеширане NXDOMAIN или страница за паркиране NS записите да изтекат естествено, задействайте незабавно глобално изчистване на кеша в Google Public DNS (developers.google.com/speed/public-dns/cache) и Cloudflare 1.1.1.1 (one.one.one.one/purge-cache/).

Дърво на решения: глобален домейн или DNS затъмнение при спешни случаи¶

Използвайте тази блок-схема, за да посочите точния слой на йерархията на DNS (TLD Registry, Registrar EPP Status, DNSSEC DS Chain, или Authoritative Nameserver), където резолюцията е неуспешна:

flowchart TD
    Start["Глобално прекъсване: Домейн Уеб и имейл не могат да бъдат разрешени (NXDOMAIN / SERVFAIL)"] --> RunDiag["Стартирайте: whois domain.com И изкопайте @8.8.8.8 domain.com +cd"]

    RunDiag --> CheckCD{"Изкопаването @8.8.8.8 domain.com е неуспешно, докато добавянето на +cd е успешно?"}

    CheckCD -->|"Да: Работи с +cd, не работи без +cd"| DnssecBreak["Прекъсната DNSSEC верига на доверие: Изтрийте остарял DS запис в регистратора ИЛИ Подпишете отново зоната -> Прочистете 8.8.8.8 & 1.1.1.1"]

    CheckCD -->|"Не: И двете са неуспешни или връщат IP за паркиране"| CheckWhois{"Проверете състоянието и датата на изтичане на домейна WHOIS EPP"}

    CheckWhois -->|"Статус: clientHold или serverHold"| HoldState["Регистратор/Суспендиране на регистъра: Завършете незабавно потвърждение на ICANN RAA имейл ИЛИ Злоупотреба/Тактурен билет"]

    CheckWhois -->|"Датата на изтичане е изтекла (статус: autoRenewPeriod)"| GraceRenew["Ден 1 до 45 след изтичане: Платете стандартно подновяване в портала на регистратора -> Проверете персонализирания NS възстановен"]

    CheckWhois -->|"Статус: redemptionPeriod (RGP)"| RgpRestore["Ден 45 до 75 след изтичане: Отворете спешен билет за поддръжка на регистратора / Платете такса за възстановяване на RGP ($80-$250) незабавно"]

    CheckWhois -->|"Състояние: в процес на изтриване"| PendingDel["Окончателно 5-дневно заключване: Не може да бъде подновено от регистратора -> Поставете резервни поръчки във всички основни Drop-Catchers сега"]

    CheckWhois -->|"Състояние: ок / clientTransferProhibited И изтичане в бъдеще"| AuthDown["Здрава регистрация на домейн -> Прекъсване или липсваща зона на авторитетен DNS доставчик"]

    AuthDown --> MigrateNS["Импортиране на файл на зона (`BIND` / Terraform) към вторичен DNS доставчик -> Премахване на DS запис, ако DNSSEC е включен -> Актуализиране на NS при регистратора"]

Фаза 1: Жизненият цикъл на изтичане на домейна на ICANN (Auto-Renew срещу Redemption срещу Pending Delete)¶

Когато общ домейн от първо ниво (gTLD като например .com, .net, .org, .io, .ai, .co, .app, .dev) изтича, защото автоматично подновяване на кредитна карта е неуспешно или финансова карта е анулирана след напускане на служител, домейнът преминава през строг многоетапен жизнен цикъл, управляван от Правилата на ICANN за възстановяване на изтекла регистрация (ERRP) и споразумения с оператор на регистър (Verisign за .com/.net, PIR за .org, Identity Digital).

Как домейн умира и защо излиза офлайн ПРЕДИ или НА Ден 1 след изтичане¶

+-------------------------------------------------------------------------+
| ICANN gTLD EXPIRATION TIMELINE (.com / .net / .org example)             |
|                                                                         |
| [Active Domain]                                                         |
|       |                                                                 |
|       v  (Expiration Date Reached: Day 0)                               |
| +---------------------------------------------------------------------+ |
| | STAGE 1: Auto-Renew Grace Period (Day 1 to Day 30-45)               | |
| | - EPP Status: ok or clientHold (Registrar swaps your NS to parking) | |
| | - Production Impact: 100% OFFLINE within 0 to 48 hours of expiry    | |
| | - Recovery: Log into registrar & pay normal renewal ($10-$30).      | |
| +---------------------------------------------------------------------+ |
|       |  (Registrar sends Delete command to Registry at Day 30-45)      |
|       v                                                                 |
| +---------------------------------------------------------------------+ |
| | STAGE 2: Redemption Grace Period [RGP] (Exactly 30 Calendar Days)   | |
| | - EPP Status: redemptionPeriod (Domain removed from TLD Root Zone)  | |
| | - Recovery: Still 100% guaranteed to original owner, MUST pay       | |
| |   Registry RGP Redemption Fee ($80-$250) + renewal via registrar.   | |
| +---------------------------------------------------------------------+ |
|       |  (30-Day RGP expires without redemption payment)                |
|       v                                                                 |
| +---------------------------------------------------------------------+ |
| | STAGE 3: Pending Delete (Exactly 5 Calendar Days)                   | |
| | - EPP Status: pendingDelete                                         | |
| | - Recovery: IMPOSSIBLE to renew or redeem at any price. Registry    | |
| |   rejects all registrar commands until public drop at Day 5 (~18:00 | |
| |   UTC for Verisign .com/.net).                                      | |
| +---------------------------------------------------------------------+ |
+-------------------------------------------------------------------------+

Сравнете точните си права, разходи и действия за възстановяване на всеки етап от изтичането, включително домейни от първо ниво с код на държава (ccTLDs като .uk, .de, .eu, .ca, .au), които не следват ICANN gTLD правила:

Фаза 2: Стъпка по стъпка възстановяване на изтекъл или RedemptionPeriod домейн¶

Следвайте точно тази последователност, за да върнете изтекъл домейн обратно онлайн за възможно най-кратко време:

Стъпка 1: Възстановете достъпа до своя регистрационен акаунт, когато @yourdomain.com имейлът е мъртъв¶

Ето класическия Catch-22 на изтекъл домейн: - Вашият домейн (company.com) е изтекъл, така че MX записи за company.com спря да се разрешава. - Опитвате се да влезете в регистратора на вашия домейн (GoDaddy, Namecheap, Cloudflare, Porkbun, Hover, Network Solutions, Gandi), а регистраторът казва: „Изпратихме 6-цифрен код за потвърждение на admin@company.com." - защото company.com е изтекъл, този имейл никога не може да пристигне.

Как незабавно да излезете от имейл цикъла с изтекъл домейн: 1. Все още НЕ прехвърляйте и не променяйте нищо: проверете дали можете да завъртите временен уловител на спешна поща САМО ако домейнът не е с изтекла валидност (ако самият домейн е с изтекла валидност на ниво TLD, MX не може да бъде разрешен никъде, докато не бъде подновен). 2. Използвайте канала за възстановяване на акаунт „Загубен имейл достъп/домейнът е изтекъл“ на регистратора: - Почти всички акредитирани от ICANN регистратори предоставят специален работен процес за потвърждение на телефон или държавен идентификатор/корпоративен документ за учредяване специално за клиенти, чийто имейл за вход се намира @ изтеклия домейн в акаунта. - Подгответе три елемента, преди да се обадите на поддръжката на регистратора: (a) последните 4 цифри от кредитната карта или идентификационния номер на транзакция в PayPal, използвани в предишната фактура за подновяване, (b) вашият ID на акаунта на регистратора / ПИН код на клиента и © държавен документ за самоличност със снимка + учредителен акт / сметка за комунални услуги, съответстващ на организацията на регистратор в WHOIS (Tech / Admin / Registrant). 3. След като влезете, незабавно променете имейл адреса на своя регистрационен акаунт на външен домейн (@gmail.com, @proton.me, или отделен спешен домейн, който притежавате) и активирайте Хардуерен ключ за сигурност (FIDO2) или TOTP Authenticator App MFA, така че влизането никога не зависи от @company.com имейл отново.

Стъпка 2: Изпълнете подновяването или RedemptionPeriod (RGP) Възстановяване¶

1. Ако домейнът е в Етап 1 (Auto-Renew Grace Period, Дни 1 до 30/45):
2. Отидете на Таксуване -> Подновявания или Списък на домейни -> Филтър с изтекъл срок и платете фактурата за подновяване.
3. Критична проверка 60 секунди след плащане: Отворете Name servers (NS) настройки в таблото за управление на регистратора. Проверете дали регистраторът автоматично е върнал вашите истински сървъри на имена (например, ns-123.awsdns-15.com или ada.ns.cloudflare.com) или напусна домейна, сочещ към неговите сървъри за паркиране с изтекъл срок (ns1.sedoparking.com / dns1.registrar-servers.com). Ако сървърите за паркиране все още са в списъка, въведете отново ръчно производствените сървъри за имена и запазете.
4. Ако домейнът е в етап 2 (Redemption Grace Period / redemptionPeriod, дни 30/45 до 75):
5. Погледнете в отделен раздел в таблото за управление на вашия регистратор, често обозначен с Изтекли домейни -> Осребряване, Кошче/Възстановяване или Таксуване за отсрочка/осребряване.
6. Платете таксата за възстановяване на RGP + 1-годишно подновяване.
7. Как работи възстановяването на RGP в регистъра (Verisign / PIR)? Когато платите таксата за RGP, вашият регистратор изпраща EPP <update><restore op="request"> команда към регистъра на TLD. Регистърът незабавно променя състоянието на домейна от redemptionPeriod към pendingRestore и поставя вашия домейн NS записва обратно в основната зона на TLD в рамките на 15 до 60 минути, докато вашият регистратор изпраща restore op="report" потвърждение за съответствие.

Стъпка 3: Заобикаляне на забавянията на кеша на локалния ISP чрез изчистване 8.8.8.8 и 1.1.1.1¶

Когато вашият домейн изтече, рекурсивните DNS преобразуватели по целия свят кешираха сървърите за имена за паркиране или отрицателния NXDOMAIN отговор (управляван от TLD SOA Minimum TTL, обикновено 900 към 3,600 секунди, или 86,400 секунди за NS записи). Моментът dig @a.gtld-servers.net yourdomain.com NS (запитване към .com root сървър директно) показва вашите реални сървъри за имена отново: 1. Отворете Google Public DNS Flush Cache (https://developers.google.com/speed/public-dns/cache): - Тип промиване NS първо за yourdomain.com, след това промийте SOA, A, AAAA, MX и TXT. 2. Отворете Cloudflare 1.1.1.1 Purge Cache (https://one.one.one.one/purge-cache/): - Прочистване NS, A, AAAA и MX за yourdomain.com.

Фаза 3: Спешен сървър на имена (NS) Миграция по време на прекъсване на DNS доставчик (и DNSSEC капан)¶

Ами ако регистрацията на вашия домейн е 100 процента валидна и не е изтекла, но вашият Оторитетен DNS доставчик (Route 53, Cloudflare, GoDaddy DNS, DigitalOcean DNS, Azure DNS, DNSimple, Dyn) страда от катастрофално прекъсване или DDoS атака и трябва да мигрирате сървърите на имена на вашия домейн (NS) към резервен DNS доставчик точно сега?

Убиецът на миграцията №1: Превключване NS Докато DNSSEC (DS Запис) е активиран¶

Преди да смените сингъл NS запис при вашия регистратор, изпълнете тази команда, за да проверите дали DNSSEC е активиран на вашия домейн в регистъра на родителския TLD:

dig +short yourdomain.com DS @8.8.8.8

+-------------------------------------------------------------------------+
| WHY CHANGING NS RECORDS WITH AN ACTIVE DS RECORD BREAKS THE INTERNET    |
|                                                                         |
| 1. Parent TLD (.com) holds your old DNS provider's DS Record (Key #2371)|
| 2. Old DNS Provider goes down. You import zone to New DNS Provider      |
|    (unsigned, or signed with a brand-new Key #9910) and swap NS.        |
| 3. Validating Resolver (8.8.8.8 / 1.1.1.1 / Comcast / ISP) queries      |
|    New DNS Provider, sees signature does NOT match DS Key #2371.        |
| 4. Resolver assumes an active MITM Spoofing Attack -> Returns SERVFAIL  |
| 5. RESULT: Your domain stays 100% dead worldwide even though the new    |
|    DNS servers are up and answering cleanly.                            |
+-------------------------------------------------------------------------+

Контролен списък за миграция на безопасен спешен сървър на имена (нула SERVFAIL процедура)¶

1. Първо реконструирайте или импортирайте вашия пълен файл на DNS зона при новия DNS доставчик:
2. Никога не отгатвайте вашите DNS записи от паметта (@, www, и api рядко са единствените записи; забравяне MX, SPF/TXT, DKIM, _dmarc, autodiscover, или CAA прекъсва доставката на имейли и подновяванията на TLS).
3. Къде да намерите пълната си DNS зона, когато таблото за управление на основния ви доставчик на DNS не работи:
   • Проверете инфраструктурата като код (Terraform, Pulumi, OctoDNS, DNSControl) във вашето Git хранилище.
   • Проверете последните износи на зони (BIND .zone файлове) или търсете в исторически DNS бази данни (SecurityTrails, ViewDNS.info, DNSDumpster, или Censys / crt.sh за поддомейни).
   • Кешираните записи на заявки все още се намират в публичните рекурсивни резолвери (dig @8.8.8.8 yourdomain.com MX, dig @1.1.1.1 yourdomain.com TXT, dig @9.9.9.9 api.yourdomain.com A) преди техните TTL да изтекат.
4. Уверете се, че новият DNS доставчик отговаря авторитетно за всеки критичен запис, ПРЕДИ да докоснете вашия регистратор: Да предположим, че вашият нов доставчик ви е назначил ns1.rescuedns.com и ns2.rescuedns.com. Тествайте ги директно с dig:

   dig @ns1.rescuedns.com yourdomain.com SOA +norecurse
   dig @ns1.rescuedns.com yourdomain.com A +norecurse
   dig @ns1.rescuedns.com yourdomain.com MX +norecurse
   

   Изчакайте, докато flags: линия в dig заглавката изрично включва aa (Authoritative Answer) и се връща status: NOERROR.
5. Ако dig +short yourdomain.com DS върна а DS запис, дръжка DNSSEC при регистратора:
6. По време на активно прекъсване, когато старият доставчик на DNS е напълно недостъпен: Влезте във вашия Регистратор на домейни (където сте купили домейна), отидете в раздела DNSSEC / DS записи и изтрийте всички DS записи, така че домейнът се връща към неподписан (Insecure) в родителската зона на TLD. Изчакайте, докато dig +short yourdomain.com DS @a.gtld-servers.net връща празен (и флъш DS в 8.8.8.8 / 1.1.1.1), или добавете новия DNS доставчик DS запишете заедно със стария, ако правите планирана миграция с множество подписващи лица.
7. Актуализирайте сървърите на имена (NS) при вашия регистратор на домейни: Заменете мъртвите сървъри на имена с ns1.rescuedns.com и ns2.rescuedns.com в панела Custom Nameservers на вашия регистратор (забележка: промяна NS записите в редактора на зони не правят нищо, когато старите сървъри са мъртви; трябва да промените Glue / Parent Delegation Nameservers на ниво регистратор).
8. Прочистване NS и DS кешира в Google (8.8.8.8) и Cloudflare (1.1.1.1): Използвайте инструментите за изчистване на публичен кеш от фаза 2, стъпка 3, за да принудите незабавно приемане на новите сървъри за имена.

Фаза 4: Оцеляване след 60-дневното заключване на прехвърляне на регистратор на ICANN по време на извънредна ситуация¶

Ами ако трябва да прехвърлите вашия домейн към нов регистратор (ICANN Inter-Registrar Transfer), само за да бъдете блокирани от Domain Status: clientTransferProhibited и съобщение, което гласи: „Този домейн е под 60-дневно заключване на ICANN за прехвърляне, тъй като информацията за контакт беше актуализирана наскоро“?

1. Защо се задейства 60-дневното заключване: Съгласно Политиката за прехвърляне на ICANN (Раздел II.C.1) регистраторите поставят 60-дневно заключване на прехвърляне всеки път, когато даден домейн е новорегистриран, прехвърлен между регистратори или претърпява „Промяна на регистранта“ (актуализиране на собственото име, фамилията, името на организацията или имейл адреса на регистранта за контакт).
2. Как да заобиколите или да се откажете от 60-дневното заключване за промяна на регистрант:
3. Преди да редактирате данните за контакт с WHOIS: Почти всички основни регистратори предоставят квадратче за отметка направо на екрана за редактиране на контакти с надпис: „Отказ от 60-дневното заключване на прехвърлянето след тази актуализация на контакта.“ Отбелязването на това квадратче ви позволява да актуализирате своя имейл адрес на администратор/регистрант и все пак да генерирате EPP Auth-Code (Transfer Secret), за да прехвърлите домейна още същия ден.
4. Запомнете, че НЕ е необходимо да прехвърляте регистрацията на домейна, за да промените DNS доставчиците: Дори ако домейнът е заключен за 60 дни срещу Регистраторски трансфери (clientTransferProhibited), все още можете да промените неговите сървъри на имена (NS записи) при текущия регистратор по всяко време с нулев период на изчакване; превключването на DNS отнема минути, докато пълното прехвърляне на регистратор отнема до 5 до 7 дни, освен ако загубилият регистратор щракне незабавно Одобрение на изходящ трансфер (FOa) бутон.

Фаза 5: Защита на регистрациите на домейни и DNS срещу бъдещи прекъсвания¶

След като вашият домейн и разделителната способност на DNS са възстановени на 100 процента, попълнете този контролен списък за устойчивост:

• Активиране Registry Lock (serverDeleteProhibited, serverUpdateProhibited, serverTransferProhibited) на критични производствени домейни: Стандартно Registrar Lock (clientTransferProhibited) могат да бъдат изключени с едно щракване, ако хакер открадне данните ви за вход в регистратора. Registry Lock (предлага се от Verisign, PIR, Cloudflare, CSC, MarkMonitor, Gandi и Porkbun/Namecheap за корпоративни домейни) заключва домейна директно на ниво регистър на TLD, като изисква гласова/криптографска проверка извън обхвата на множество лица преди всяка NS записът може да бъде променен или домейнът изтрит.
• Подновете производствените домейни за 5 до 10 години предварително (ICANN maximum horizon is 10 years): Никога не оставяйте критичен за бизнеса домейн при подновяване от година на година, когато една изтекла корпоративна кредитна карта може да предизвика прекъсване на изтичане. Предплащане за 5 до 10 години наведнъж.
• Никога не използвайте @yourdomain.com имейл адрес като контакт за влизане или известяване за фактуриране при управлението на регистратора yourdomain.com: Използвайте специален списък за разпространение на защита в независим административен домейн или защитен външен акаунт и наблюдавайте RDAP / WHOIS дати на изтичане чрез автоматизирани външни монитори Prometheus/Uptime (domain_expiry_days < 60).
• По-ниска NS и DS TTL (300 към 3600 секунди) 48 часа преди всяка планирана миграция на DNS: Намаляването на TTL предварително гарантира превключване на резолверите в рамките на 5 минути след планираното прекъсване.

Регионални номера за спешни повиквания и протоколи на агенцията¶

Когато прекъсването на домейн или DNS засегне здравни заведения, служби за спешна помощ, общински комунални услуги или правителствена инфраструктура, следвайте тези регионални канали за ескалация:

• САЩ и Канада: Наберете 911 ако прекъсване на домейн/DNS деактивира телеметрията на клиничната болница, изпращането на линейки или системите за безопасност на живота. Докладвайте DDoS атаки срещу DNS инфраструктура или отвличане на BGP/DNS на CISA (1-844-Say-CISA / cisa.gov/report), ФБР IC3 (ic3.gov) или Канадския център за киберсигурност (1-833-CYBER-88). За .gov домейни, свържете се с CISA .gov Бюро за помощ на регистратора.
• Обединено кралство: Наберете 999 за заплахи за живота или остри смущения в NHS. Докладвайте за критични прекъсвания на DNS или отвличания на домейни на NCSC (ncsc.gov.uk) и се свържете с Nominet (01865 332244) директно за спешно .uk / .gov.uk / .nhs.uk проблеми с регистъра.
• Европейски съюз: Наберете 112 във всички страни членки на ЕС. Доставчиците на DNS услуги и регистрите на имената на TLD се регулират от Директивата на ЕС NIS2 (Directive 2022/2555) и трябва да докладват значителни инциденти на наличност на своя национален CSIRT в рамките на 24 часа.
• Австралия и Нова Зеландия: Наберете 000 в Австралия или 111 в Нова Зеландия; докладвайте за критични DNS или домейн инциденти на ACSC (1300 CYBER1), auDA (за .au), или Комисионна за име на домейн NZ (за .nz).
• Индия и Азиатско-тихоокеанския регион: Наберете 112 в Индия за спешна реакция; докладвайте за атаки на DNS/домейн инфраструктура на CERT-In (incident@cert-in.org.in) в рамките на 6 часа или NIXI за .in ескалации на регистъра.

Често задавани въпроси¶

Защо домейнът ми спря да работи 24 часа ПРЕДИ официалното клеймо за изтичане на WHOIS?¶

Първо проверете часовите зони: WHOIS `Registry Expiry Date` винаги се отпечатва в **UTC (`Z`)**, което е с 4 до 8 часа пред часовите зони в Северна Америка (което означава, че домейн изтича на `2026-11-01T04:00:00Z` всъщност изтича на `8:00 PM PDT` на 31 октомври). Второ, ако вашият `NS` записите имаха a `24-hour` или `48-hour` TTL и регистраторът ги размениха `00:00 UTC` в деня на изтичане, потребителите, чиито резолвери са обновени по-рано, незабавно посещават страницата за паркиране, докато други остават кеширани с часове.

Регистраторът ми не работи напълно или не отговаря (Dead / De-accredited Registrar), а домейнът ми изтича. Как да го спася?¶

Когато ICANN прекрати или деакредитира неуспешен регистратор съгласно **Процедурата за прехвърляне на деакредитиран регистратор (`DARTP`)**, ICANN автоматично масово прехвърля всички домейни към регистратор-попечител с нулеви разходи за регистрантите. Проверете `whois yourdomain.com` (или `lookup.icann.org`), за да видите кой **Регистратор** и **IANA ID** в момента държи вашия домейн, или подадете спешно **Жалба за подновяване/прехвърляне на домейн** директно до **Спазването на договорите на ICANN (`icann.org/compliance/complaint`)**.

Защо уебсайтът ми работи за някои клиенти на клетъчни данни, но все още показва страницата за паркиране с изтекъл срок на Wi-Fi в нашия офис 6 часа след като поднових домейна?¶

Рекурсивният DNS резолвер на вашата офис мрежа или локален интернет доставчик са кеширали страницата за паркиране на регистратора `NS` и `A` записи, докато домейнът е изтекъл, а сървърите за имена за паркиране са известни с високи TTL (`3,600` към `86,400` секунди / 24 часа), така че рекламните страници остават кеширани по-дълго. Изчистете Google (`8.8.8.8`) и Cloudflare (`1.1.1.1`) с помощта на техните инструменти за почистване на мрежата, след което стартирайте на вашия локален компютър `ipconfig /flushdns` (Windows), `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` (macOS), или `sudo resolvectl flush-caches` (Linux).

Какво се случва с имейлите, изпратени до @yourdomain.com Докато нашият домейн или DNS бяха изтекли за 18 часа? Изгубени ли са завинаги?¶

В повечето случаи, легитимните имейли, изпратени през първите 12 до 48 часа от прекъсване на DNS, НЕ се губят: те се поставят на опашка на пощенския сървър на подателя и ще пристигнат автоматично през следващите няколко часа. Под **`RFC 5321` (Прост протокол за прехвърляне на поща, Раздел 4.5.4.1)**, когато изпращащ пощенски сървър (`Gmail`, `Microsoft Exchange Online`, `Postfix`) получава временна грешка при търсене в DNS (`SERVFAIL`) или не може да се свърже с `MX` хост, той поставя съобщението в опашка за повторен опит за **4 до 5 дни (`96 to 120 hours`)**, повторен опит с експоненциално забавяне. Въпреки това, ако изтеклата страница за паркиране на регистратора включва **заместващ знак null `MX` запис (`0 .`)** или сървър за паркиране на поща, който отхвърли пощата с твърд `550 5.1.1 User Unknown` постоянно отхвърляне, тези податели са получили незабавно известие за отхвърляне и трябва да изпратят отново своите имейли.

Мога ли да настроя два DNS доставчика едновременно (Cloudflare + Route 53) просто като изброите два Cloudflare NS записи и два маршрута 53 NS записи в моя регистратор?¶

да толкова дълго, колкото `DNSSEC` е деактивиран (или правилно конфигуриран с `RFC 8901` Multi-Signer DNSSEC) и двата доставчика обслужват идентични DNS записи. Рекурсивните резолвери отправят заявки към всички изброени родители `NS` записва с помощта на избор на латентност на кръгов режим/RTT (`SRTT`). Ако изброите `ns1.providerA.com`, `ns2.providerA.com`, `ns1.providerB.com`, и `ns2.providerB.com` в персонализираните сървъри на имена на вашия регистратор и поддържайте двете зони синхронизирани с помощта на **OctoDNS**, **DNSControl**, **Terraform** или `AXFR / IXFR` трансфери на зони, вашият домейн автоматично оцелява след 100 процента прекъсване на който и да е DNS доставчик.

Каква е разликата между clientHold и serverHold в WHOIS?¶

EPP статус кодове, започващи с **`client...`** (`clientHold`, `clientTransferProhibited`) са зададени от вашия **Регистратор на домейни** (търговецът на дребно, при който управлявате акаунта си, като Namecheap или GoDaddy) и могат да бъдат премахнати незабавно от системата за поддръжка или таксуване на вашия регистратор. Статус кодове, започващи с **`server...`** (`serverHold`, `serverTransferProhibited`) се задават директно от **оператора на регистъра на TLD** (`Verisign`, `PIR`, `Nominet`) поради съдебни разпореждания, спорове по UDRP, спирания на злоупотреби на ниво регистър или хардуерно **Заключване на регистъра** и изискват да се свържете с Регистъра чрез вашия регистратор за премахване.

Свързани ръководства¶

• Отвличане на име на домейн, изтекъл DNS и превземане на уебсайт
• Сертификатът SSL/TLS е изтекъл в производството, блокиране на предварително зареждане на HSTS, блокиране на записи на CA CAA и спешно подновяване
• Google Workspace или Microsoft 365 персонализирано блокиране на администратор на домейн, DNS TXT проверка и спасяване на наемател
• Отвличане на DNS, преконфигуриране на WAN рутер на ISP и подправяне на прихванат портал
• Уеб хостинг криза, миграция и възстановяване на резервно копие
• Номера за спешни повиквания по държави

Източници и официални указания¶

• Интернет корпорация за присвоени имена и номера (ICANN): Правила за възстановяване на изтекла регистрация (ERRP), Политика за изтриване на домейн с изтекъл срок (EDDP), Политика за прехвърляне между регистратори (60-дневно заключване на промяна на регистрант) и справка за кодове за състояние на EPP (clientHold, redemptionPeriod, pendingDelete).
• Работна група за интернет инженеринг (IETF): RFC 6781 (Оперативни практики на DNSSEC: Ключови промени и спешни случаи DS премахване) & RFC 8901 (Multi-Signer DNSSEC модели за Multi-Provider Authoritative DNS).
• Национален институт по стандарти и технологии (NIST) (САЩ): Специална публикация 800-81-2: Сигурна система за имена на домейни (DNS) Ръководство за внедряване.
• Агенция за киберсигурност и сигурност на инфраструктурата (CISA) (Съединени щати): Спешна директива 19-01: Намаляване на подправянето на DNS инфраструктура.
• Агенция на Европейския съюз за киберсигурност (ENISA): NIS2 Технически насоки за доставчици на DNS услуги и регистри на имена на TLD.