Interrupción do rexistro de dominio ou do provedor de DNS: período de gracia de canxeo de dominio caducado, DNSSEC SERVFAIL Migración de trampa e servidor de nomes de emerxencia¶

Espertar para descubrir que o sitio web principal da súa empresa, os puntos finais da API (api.example.com), e correo electrónico corporativo (MX rexistros de Google Workspace ou Microsoft 365) son completamente inalcanzables en todo o mundo (DNS_PROBE_FINISHED_NXDOMAIN ou SERVFAIL) é unha crise de infraestruturas de apagón total. A diferenza dun único servidor web fallido que afecta a un servizo, un sistema de nomes de dominio (DNS) ou un erro no rexistro do dominio corta todos os servizos do teu dominio raíz ao mesmo tempo, incluído o inicio de sesión único (SSO), portais de atención ao cliente e correos electrónicos de resposta a incidentes entrantes. Na práctica, os cortes de dominio global derivan de tres desencadenantes distintos: (1) unha caducidade accidental de dominio onde caducou unha tarxeta de crédito rexistrada e o rexistrador secuestrou o teu NS rexistros para apuntar a unha páxina de aparcamento de pago por clic 24 to 48 hours antes da data de caducidade real; (2) un ataque DDoS ou interrupción do plano de control no teu provedor de DNS autorizado (Route 53, Cloudflare, GoDaddy, Namecheap, DNSimple, NS1); ou (3) un roto DNSSEC (DS rexistro) cadea de confianza durante un cambio de servidor de nomes apresurado que provoca a validación de resolutores (8.8.8.8, 1.1.1.1, solucionadores de ISP) para eliminar o 100 por cento do seu tráfico SERVFAIL. Se un atacante comprometeu as credenciais de inicio de sesión do teu rexistrador e transferiu ou modificou o teu dominio de forma maliciosa, cambia a secuestro de nomes de dominio, DNS caducado e toma de control do sitio web; se o seu certificado TLS caducou ou rompeu despois de recuperar o DNS, consulte O certificado SSL/TLS caducou na produción, o bloqueo de precarga de HSTS e a renovación de emerxencia e Bloqueo de administrador de dominio personalizado de Google Workspace ou Microsoft 365 e verificación de DNS. Se esta interrupción desactiva as comunicacións clínicas hospitalarias, o enrutamento do envío de emerxencia 911/112 ou os servizos públicos críticos, chame ao número de emerxencia local (911 nos Estados Unidos e Canadá, 112 en toda a Unión Europea, 999 no Reino Unido) ou consulte o noso directorio de números de emerxencia.

Fai isto agora¶

1. Diagnóstica en 10 segundos se o fallo é un dominio caducado/suspendido (EPP Status), unha interrupción do provedor de DNS autorizado ou a DNSSEC Fallo de validación:
2. Corre whois yourdomain.com | grep -iE "Status|Expiry|Name Server" e dig +trace yourdomain.com.
3. Proba se se omite DNSSEC validación (+cd = Marcando Desactivado) fai que o teu dominio se resolva de novo:

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

   Se o primeiro comando devolve status: SERVFAIL mentres o segundo comando (+cd) volve inmediatamente status: NOERROR co enderezo IP do teu servidor, ** os teus servidores DNS NON están inactivos: o teu DNSSEC (DS rexistro no rexistrador) está roto**. Ir inmediatamente á Fase 3 para eliminar o obsoleto DS rexistrar no seu rexistro.
4. Se o teu dominio caducou (Auto-Renew Grace Period ou Redemption Grace Period), inicie sesión no seu rexistro actual de inmediato e pague a taxa de renovación/canxeo; NON agardes a que o dominio "se solte" para poder rexistralo de novo a un prezo económico:
5. Durante os primeiros 1 a 45 días despois do vencemento (Auto-Renew Grace Period), a renovación no panel de rexistro do teu rexistro restablece os teus servidores de nomes orixinais a un custo de renovación estándar ($10 to $30).
6. Durante os 30 días Redemption Grace Period (RGP / redemptionPeriod), debe pagar a taxa obrigatoria de rescate do rexistro ($80 to $250) a través do seu rexistro actual. Se esperas a que o dominio remate os 5 días Pending Delete Fase para gardar $100, bots de francotiradores automáticos para capturar caídas (DropCatch, SnapNames, NameJet) arrebatará o teu dominio dentro 5 milliseconds de lanzamento e poxalo por miles de dólares.
7. ** NUNCA cambie os seus servidores de nomes (NS) lonxe dun provedor de DNS habilitado para DNSSEC (como Cloudflare, Route 53 ou Google Cloud DNS) sen eliminar o DS rexistrar primeiro no seu rexistrador**: Se DNSSEC está activado e cambias o teu NS rexistra a un provedor de DNS de rescate durante unha interrupción sen eliminar o pai DS (Delegation Signer) rexistrar no .com / .org En primeiro lugar, todos os resolutores validadores da Terra rexeitarán as respostas sen asinar do novo provedor de DNS como un ataque de suplantación criptográfica (SERVFAIL).
8. Se estás bloqueado na túa empresa @yourdomain.com correo electrónico porque é o teu dominio MX os rexistros están caídos, NON faga clic en "Enviar o código de restablecemento de contrasinal a admin@yourdomain.com" no teu rexistrador: mentres o teu dominio NS ou MX os rexistros están fóra de liña, calquera correo electrónico de verificación enviado @yourdomain.com rebota ou desaparece nunha cola. Use o correo electrónico de copia de seguranza fóra de banda do SMS/Authenticator MFA do seu rexistrador (@gmail.com / @proton.me), ou o fluxo de verificación da identidade do teléfono.
9. Despois de renovar un dominio caducado, verifique manualmente que o seu rexistro restaurou os seus servidores de nomes personalizados orixinais (NS) en vez de deixar o dominio activado sedoparking.com / renewyourname.net: Cando un dominio caduca, os rexistradores sobrescriben o teu personalizado NS rexistros con servidores de nomes de aparcamento (ns1.parklogic.com, dns1.name-services.com). Ás veces, o pago da renovación actualiza a data de caducidade ao próximo ano mentres deixan activos os servidores de nomes de aparcamento ata que os cambias manualmente.
10. ** Vaciar cachés DNS recursivos públicos globais (Google 8.8.8.8, Cloudflare 1.1.1.1, OpenDNS) o segundo teu NS ou DS os rexistros son restaurados**: en lugar de esperar de 24 a 48 horas para almacenalos na caché NXDOMAIN ou páxina de aparcamento NS caducan de forma natural, desencadea unha purga instantánea da caché global en Google Public DNS (developers.google.com/speed/public-dns/cache) e Cloudflare 1.1.1.1 (one.one.one.one/purge-cache/).

Árbore de decisión: dominio global ou triaxe de emerxencia de corte de DNS¶

Use este diagrama de fluxo para identificar a capa exacta da xerarquía de DNS (TLD Registry, Registrar EPP Status, DNSSEC DS Chain, ou Authoritative Nameserver) cando a resolución falla:

flowchart TD
    Start["Interrupción global: non se resolveu o correo electrónico e a web do dominio (NXDOMAIN / SERVFAIL)"] --> RunDiag["Executar: whois domain.com E cavar @8.8.8.8 domain.com +cd"]

    RunDiag --> CheckCD{"Falla dig @8.8.8.8 domain.com mentres se engade +cd correctamente?"}

    CheckCD -->|"Si: funciona con +cd, falla sen +cd"| DnssecBreak["Cadea de confianza DNSSEC rota: eliminar o rexistro obsoleto de DS no rexistrador OU Volver a asinar a zona -> Borrar 8.8.8.8 e 1.1.1.1"]

    CheckCD -->|"Non: Tanto a IP de aparcamento como a devolución"| CheckWhois{"Inspeccione o estado e a data de caducidade do dominio WHOIS EPP"}

    CheckWhois -->|"Estado: clientHold ou serverHold"| HoldState["Rexistro/Suspensión do Rexistro: complete a verificación do correo electrónico da RAA da ICANN OU o ticket de abuso/facturación inmediatamente"]

    CheckWhois -->|"Data de caducidade superada (estado: autoRenewPeriod)"| GraceRenew["Día 1 a 45 posterior á caducidade: pagar a renovación estándar no portal do rexistro -> Verificar o NS personalizado restaurado"]

    CheckWhois -->|"Estado: período de redención (RGP)"| RgpRestore["Día 45 ao 75 posterior á caducidade: Abrir o ticket de asistencia do rexistrador urxente / Pagar a taxa de restauración de RGP ($80-$250) inmediatamente"]

    CheckWhois -->|"Estado: pendente de Eliminar"| PendingDel["Bloqueo final de 5 días: non se pode renovar no rexistro -> Fai pedidos atrasados en todos os principais drop-Catchers agora"]

    CheckWhois -->|"Estado: ok / clientTransferProhibited E caduca no futuro"| AuthDown["Rexistro de dominio saudable -> Interrupción ou zona faltante do provedor de DNS autorizado"]

    AuthDown --> MigrateNS["Importar ficheiro de zona (`BIND`/Terraform) ao provedor de DNS secundario -> Eliminar rexistro DS se DNSSEC está activado -> Actualizar NS no rexistro"]

Fase 1: Ciclo de vida de caducidade do dominio da ICANN (Auto-Renew vs. Redemption vs. Pending Delete)¶

Cando un dominio xenérico de nivel superior (gTLD como .com, .net, .org, .io, .ai, .co, .app, .dev(ERRP)** e acordos de operador de rexistro (Verisign para .com/.net, PIR para .org, Identity Digital).

Como morre un dominio e por que se desconecta ANTES ou O día 1 de caducidade¶

+-------------------------------------------------------------------------+
| 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).                                      | |
| +---------------------------------------------------------------------+ |
+-------------------------------------------------------------------------+

Compare os seus dereitos exactos, custos e accións de recuperación en todas as fases de caducidade, incluídos os dominios de nivel superior de código de país (ccTLDs como .uk, .de, .eu, .ca, .au), que non seguen a ICANN gTLD regras:

Fase 2: recuperación paso a paso dun caducado ou RedemptionPeriod dominio¶

Siga esta secuencia exacta para que un dominio caducado volva estar en liña no menor tempo posible:

Paso 1: recupere o acceso á súa conta de rexistrador cando @yourdomain.com o correo electrónico está morto¶

Aquí está o clásico Catch-22 dun dominio caducado: - O teu dominio (company.com) caducou, polo tanto MX rexistros para company.com deixou de resolver. - Tentas iniciar sesión no teu rexistrador de dominios (GoDaddy, Namecheap, Cloudflare, Porkbun, Hover, Network Solutions, Gandi), e o rexistrador di: "Enviamos un código de verificación de 6 díxitos a admin@company.com." - Porque company.com está caducado, ese correo electrónico nunca pode chegar.

Como saír do bucle de correo electrónico do dominio caducado inmediatamente: 1. Non transfire nin modifique nada aínda: comprobe se pode crear un colector de correo de emerxencia temporal SÓ se o dominio non caducou (se o propio dominio caducou a nivel de TLD, MX non pode resolverse en ningún lugar ata que se renove). 2. Utiliza a canle de recuperación da conta de "Acceso ao correo electrónico perdido/Dominio caducado" do rexistrador: - Case todos os rexistradores acreditados pola ICANN proporcionan un teléfono dedicado ou un fluxo de traballo de verificación de documentos de identificación do goberno/incorporación corporativa específicamente para os clientes cuxo correo electrónico de inicio de sesión se atopa. @ o dominio caducado dentro da conta. - Teña preparados tres elementos antes de chamar ao servizo de asistencia do rexistrador: (a) os últimos 4 díxitos da tarxeta de crédito ou o ID de transacción de PayPal utilizado na factura de renovación anterior, (b) o ID da conta de rexistrador/PIN do cliente e © un ID con foto do goberno + artigos de incorporación/factura de servizos públicos que coincida coa organización de rexistro WHOIS (Tech / Admin / Registrant). 3. Unha vez iniciado sesión, cambie inmediatamente o enderezo de correo electrónico da súa conta de rexistrador a un dominio externo (@gmail.com, @proton.me, ou un dominio de emerxencia separado que posúa) e habilite Chave de seguranza de hardware (FIDO2) ou TOTP Authenticator App MFA polo que o inicio de sesión nunca depende de @company.com correo electrónico de novo.

Paso 2: executa a renovación ou RedemptionPeriod (RGP) Restaurar¶

1. Se o dominio está na fase 1 (Auto-Renew Grace Period, Días 1 ao 30/45):
2. Vaia a Facturación -> Renovacións ou Lista de dominios -> Filtro caducado e pague a factura de renovación.
3. Comprobación crítica 60 segundos despois do pago: abre os servidores de nomes do dominio (NS) configuración no panel de rexistro. Comproba se o rexistrador devolve automaticamente os teus servidores de nomes reais (por exemplo, ns-123.awsdns-15.com ou ada.ns.cloudflare.com) ou deixou o dominio apuntando aos seus servidores de estacionamento caducados (ns1.sedoparking.com / dns1.registrar-servers.com). Se aínda aparecen servidores de aparcamento, introduza manualmente de novo os seus servidores de nomes de produción e gárdeo.
4. Se o dominio está na fase 2 (Redemption Grace Period / redemptionPeriod, días 30/45 a 75):
5. Busca nunha pestana separada dentro do panel de control do teu rexistrador, a miúdo etiquetada como Dominios caducados -> Canxeo, Lixo/Restaurar ou Facturación de graza/redención.
6. Paga a taxa de restauración de RGP + renovación dun ano.
7. Como funciona a restauración de RGP no Rexistro (Verisign / PIR)? Cando pagas a taxa RGP, o teu rexistrador envía un EPP <update><restore op="request"> comando para o Rexistro de TLD. O Rexistro cambia inmediatamente o estado do dominio de redemptionPeriod a pendingRestore e pon o teu dominio NS rexistra de novo na zona raíz do TLD nun prazo de 15 a 60 minutos mentres o seu rexistrador envía o restore op="report" confirmación de conformidade.

Paso 3: elimina os atrasos da caché do ISP local mediante a purga 8.8.8.8 e 1.1.1.1¶

Cando caducou o teu dominio, os resolutores de DNS recursivos de todo o mundo almacenaron en caché os servidores de nomes de aparcamento ou o negativo NXDOMAIN resposta (gobernada polos TLD's SOA Minimum TTL, normalmente 900 a 3,600 segundos, ou 86,400 segundos para NS rexistros). O momento dig @a.gtld-servers.net yourdomain.com NS (consultando o .com servidor raíz directamente) mostra os seus servidores de nomes de produción reais de novo: 1. Abre Google Public DNS Flush Cache (https://developers.google.com/speed/public-dns/cache): - Tipo de descarga NS primeiro para yourdomain.com, despois enxágüe SOA,A,AAAA,MX, e TXT. 2. Abre Cloudflare 1.1.1.1 Purgar caché (https://one.one.one.one/purge-cache/): - Purgar NS,A,AAAA, e MX para yourdomain.com.

Fase 3: servidor de nomes de emerxencia (NS) Migración durante unha interrupción do provedor de DNS (e DNSSEC trampa)¶

E se o rexistro do teu dominio é 100 por cento válido e non caduco, pero o teu proveedor de DNS autorizado (Route 53, Cloudflare, GoDaddy DNS, DigitalOcean DNS, Azure DNS, DNSimple, Dyn) está a sufrir unha interrupción catastrófica ou un ataque DDoS e necesitas migrar os servidores de nomes do teu dominio (NS) a un provedor de DNS de reserva agora mesmo?

The #1 Migration Killer: Switching NS Mentres DNSSEC (DS Rexistro) está activado¶

Antes de cambiar un único NS grava no teu rexistrador, executa este comando para comprobar se DNSSEC está habilitado no teu dominio no rexistro de TLD principal:

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.                            |
+-------------------------------------------------------------------------+

Lista de verificación de migración segura do servidor de nomes de emerxencia (cero SERVFAIL procedemento)¶

1. Reconstrúe ou importe primeiro o teu ficheiro de zona DNS completo no novo provedor de DNS:
2. Nunca adivine os seus rexistros DNS da memoria (@, www, e api raramente son os únicos rexistros; esquecemento MX, SPF/TXT, DKIM, _dmarc, autodiscover, ou CAA rompe a entrega de correo electrónico e as renovacións de TLS).
3. Onde atopar a túa zona DNS completa cando o panel de control do teu provedor de DNS principal está inactivo:
   • Verifique Infraestructura como código (Terraform, Pulumi, OctoDNS, DNSControl) no teu repositorio Git.
   • Verifique as exportacións recentes da zona (BIND .zone ficheiros) ou buscar bases de datos DNS históricas (SecurityTrails, ViewDNS.info, DNSDumpster, ou Censys / crt.sh para subdominios).
   • Consulta os rexistros almacenados na memoria caché aínda dentro dos resolvedores recursivos públicos (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) antes de que caduquen os seus TTL.
4. Verifique que o novo provedor de DNS responde con autoridade para cada rexistro crítico ANTES de tocar o seu rexistrador: Supoña que o teu novo provedor asignouche ns1.rescuedns.com e ns2.rescuedns.com. Proba-los directamente con 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
   

   Agarda ata que flags: liña na dig a cabeceira inclúe explícitamente aa (Authoritative Answer) e volve status: NOERROR.
5. Se dig +short yourdomain.com DS volveu a DS gravar, manexar DNSSEC no rexistro:
6. Durante unha interrupción activa na que o antigo provedor de DNS é completamente inalcanzable: inicie sesión no seu Rexistrador de dominios (onde comprou o dominio), vai á sección Rexistros DNSSEC/DS e elimine todos. DS rexistros polo que o dominio volve a ser sen asinar (Insecure) na zona principal do TLD. Agarda ata dig +short yourdomain.com DS @a.gtld-servers.net devolve baleiro (e vaciar DS en 8.8.8.8 / 1.1.1.1), ou engade o novo provedor de DNS DS rexistrar xunto co antigo se se realiza unha migración planificada de varios asinantes.
7. Actualizar os servidores de nomes (NS) no seu rexistro de dominio: Substitúe os servidores de nomes mortos por ns1.rescuedns.com e ns2.rescuedns.com no panel Servidores de nomes personalizados do teu rexistrador (nota: cambio NS os rexistros dentro do editor de zona non fan nada cando os antigos servidores están mortos; debes cambiar os Glue / Servidores de nomes da delegación de pais no nivel de rexistro).
8. ** Purgar NS e DS cachés en Google (8.8.8.8) e Cloudflare (1.1.1.1)**: Use as ferramentas de purga da caché pública da Fase 2 Paso 3 para forzar a adopción inmediata dos novos servidores de nomes.

Fase 4: Sobrevivir ao bloqueo de transferencia de rexistro da ICANN durante 60 días durante unha emerxencia¶

E se precisas transferir o teu dominio a un novo rexistrador (ICANN Inter-Registrar Transfer), só para ser bloqueado por Domain Status: clientTransferProhibited e unha mensaxe que di: "Este dominio está baixo un bloqueo de transferencia de 60 días da ICANN porque a información de contacto se actualizou recentemente"?

1. Por que se activou o bloqueo de 60 días: baixo a Política de transferencias da ICANN (Sección II.C.1), os rexistradores bloquean a transferencia de 60 días sempre que un dominio se rexistre recentemente, transfira entre rexistradores ou se someta a un "Cambio de rexistrador" (actualizando o nome, apelido, nome da organización ou enderezo de correo electrónico de contacto do rexistrador).
2. Como ignorar ou desactivar o bloqueo de 60 días de cambio de rexistrador:
3. Antes de editar os datos de contacto de WHOIS: Case todos os principais rexistradores proporcionan unha caixa de verificación xusto na pantalla de edición de contactos coa etiqueta: "Desactivar o bloqueo de transferencia de 60 días despois desta actualización de contactos." Marcar esa caixa permíteche actualizar o teu enderezo de correo electrónico de administrador/rexistrante e aínda así xerar un EPP Auth-Code (Transfer Secret) para transferir o dominio o mesmo día.
4. Lembre que NON precisa transferir o rexistro de dominio para cambiar de provedor de DNS: aínda que un dominio estea bloqueado durante 60 días contra Transferencias de rexistro (clientTransferProhibited), aínda podes cambiar os seus Namesservers (NS rexistros) no rexistro actual en calquera momento con período de espera cero; cambiar de DNS leva minutos, mentres que unha transferencia de rexistrador completa leva de 5 a 7 días a menos que o rexistrador perdedor faga clic instantáneamente Aprobar transferencia de saída (FOabotón ).

Fase 5: Endurecemento dos rexistros de dominios e DNS ante futuras interrupcións¶

Unha vez que o teu dominio e a resolución DNS estean restaurados ao 100 por cento, completa esta lista de verificación de resistencia:

• Activar Registry Lock (serverDeleteProhibited, serverUpdateProhibited, serverTransferProhibited) en dominios de produción de misión crítica: Estándar Registrar Lock (clientTransferProhibited) pódese desactivar cun só clic se un atacante secuestra o inicio de sesión do teu rexistrador. Registry Lock (ofrecido por Verisign, PIR, Cloudflare, CSC, MarkMonitor, Gandi e Porkbun/Namecheap para dominios empresariais) bloquea o dominio directamente no Rexistro de TLD, requirindo unha verificación criptográfica/voz multi-persoa fóra da banda antes de calquera NS pódese cambiar o rexistro ou eliminar o dominio.
• Renovar os dominios de produción con 5 a 10 anos de antelación (ICANN maximum horizon is 10 years): Nunca deixes un dominio crítico para a empresa na renovación interanual onde unha única tarxeta de crédito corporativa caducada pode provocar unha interrupción de caducidade. Pago anticipado de 5 a 10 anos á vez.
• Nunca use un @yourdomain.com enderezo de correo electrónico como contacto de inicio de sesión ou notificación de facturación no rexistro que xestiona yourdomain.com: utiliza unha lista de distribución de seguranza dedicada nun dominio administrativo independente ou unha conta externa reforzada e monitoriza RDAP / WHOIS datas de caducidade mediante monitores externos automatizados de Prometheus/Uptime (domain_expiry_days < 60).
• ** Baixo NS e DS TTL (300 a 3600 segundos) 48 horas antes de calquera migración de DNS planificada**: a baixada dos TTL con antelación garante que os resolutores cambien dentro de 5 minutos despois dun cambio planificado.

Números de emerxencia rexionais e protocolos da axencia¶

Cando unha interrupción de dominio ou DNS afecte ás instalacións sanitarias, aos servizos de emerxencia, aos servizos públicos municipais ou á infraestrutura gobernamental, siga estas canles de escalada rexionais:

• Estados Unidos e Canadá: Marque 911 se unha interrupción do dominio/DNS desactiva a telemetría do hospital clínico, o envío de ambulancias ou os sistemas de seguridade. Informe ataques DDoS a infraestrutura DNS ou secuestro de BGP/DNS a CISA (1-844-Say-CISA / cisa.gov/report), o FBI IC3 (ic3.gov) ou o Centro Canadiense para a Ciberseguridade (1-833-CYBER-88). Para .gov dominios, póñase en contacto co CISA .gov Rexistrador Helpdesk.
• Reino Unido: Marque 999 para ameazas de vida ou interrupcións agudas do NHS. Informe interrupcións críticas de DNS ou secuestros de dominios ao NCSC (ncsc.gov.uk) e póñase en contacto con Nominet (01865 332244) directamente por urxente .uk / .gov.uk / .nhs.uk problemas de rexistro.
• Unión Europea: Marque 112 en todos os estados membros da UE. Os provedores de servizos DNS e os rexistros de nomes de TLD están regulados pola Directiva NIS2 da UE (Directive 2022/2555) e deben informar os incidentes significativos de dispoñibilidade ao seu CSIRT nacional nun prazo de 24 horas.
• Australia e Nova Zelanda: Marque 000 en Australia ou 111 en Nova Zelanda; informe de incidentes de dominio ou DNS críticos ao ACSC (1300 CYBER1), auDA (para .au), ou Comisión de nomes de dominio NZ (para .nz).
• India e Asia-Pacífico: Marque 112 na India para a resposta de emerxencia; informar ataques DNS/infraestructura de dominio a CERT-In (incident@cert-in.org.in) dentro de 6 horas ou NIXI para .in escaladas de rexistro.

Preguntas frecuentes¶

Por que o meu dominio deixou de funcionar 24 horas ANTES da súa marca de caducidade oficial de WHOIS?¶

En primeiro lugar, verifique os fusos horarios: WHOIS `Registry Expiry Date` sempre se imprime en **UTC (`Z`)**, que é de 4 a 8 horas por diante dos fusos horarios norteamericanos (é dicir, un dominio que caduca ás `2026-11-01T04:00:00Z` efectivamente caduca ás `8:00 PM PDT` o 31 de outubro). En segundo lugar, se o teu `NS` rexistros tiñan un `24-hour` ou `48-hour` TTL e o rexistrador intercambiáronos en `00:00 UTC` o día de caducidade, os usuarios cuxos solucionadores actualizados cedo acceden á páxina de aparcamento inmediatamente mentres que outros permanecen na memoria caché durante horas.

O meu rexistrador está completamente fóra do negocio ou non responde (Dead / De-accredited Registrar), e o meu dominio está a caducar. Como o rescato?¶

Cando a ICANN rescinda ou desacredite a un rexistrador que falla segundo o **Procedemento de transición de rexistrador desacreditado (`DARTP`)**, a ICANN transfire automaticamente todos os dominios a un rexistrador custodio ganador a un custo cero para os rexistrados. Comproba `whois yourdomain.com` (ou `lookup.icann.org`) para ver que **Rexistrador** e **ID de IANA** posúen actualmente o teu dominio, ou presenta unha **Reclamación de Renovación/Transferencia de Dominio** urxente directamente con **Cumprimento contractual da ICANN (`icann.org/compliance/complaint`)**.

Por que o meu sitio web funciona para algúns clientes con datos móbiles, pero segue mostrando a páxina de aparcamento caducada na wifi da nosa oficina 6 horas despois de renovar o dominio?¶

A súa rede de oficina ou o resolvedor de DNS recursivo do ISP local almacenaron na caché a páxina de aparcamento do rexistrador `NS` e `A` rexistros mentres caducou o dominio, e os servidores de nomes de aparcamento establecen TTL altos (`3,600` a `86,400` segundos/24 horas) polo que as páxinas de anuncios permanecen almacenadas na memoria caché durante máis tempo. Borrar Google (`8.8.8.8`) e Cloudflare (`1.1.1.1`) usando as súas ferramentas de purga web e, a continuación, executar no seu ordenador local `ipconfig /flushdns` (Windows), `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` (macOS) ou `sudo resolvectl flush-caches` (Linux).

Que pasa cos correos electrónicos enviados a @yourdomain.com Mentres o noso dominio ou DNS caducou durante 18 horas? Están perdidos para sempre?¶

Na maioría dos casos, os correos electrónicos lexítimos enviados durante as primeiras 12 a 48 horas dunha interrupción do DNS NON se perden: están en cola no servidor de correo do remitente e chegarán automaticamente nas próximas horas.. Menos de **`RFC 5321` (Protocolo simple de transferencia de correo, sección 4.5.4.1)**, cando un servidor de correo`Gmail`, `Microsoft Exchange Online`, `Postfix`) obtén un fallo temporal de busca de DNS (`SERVFAIL`) ou non se pode conectar a un `MX` host, coloca a mensaxe nunha cola de reintentos durante **4 a 5 días (`96 to 120 hours`)**, tentando de novo con retroceso exponencial. Non obstante, se a páxina de aparcamento caducada do rexistrador incluía un **comodín nulo `MX` rexistro (`0 .`)** ou un servidor de correo de aparcamento que rexeitou o correo con un duro `550 5.1.1 User Unknown` rebote permanente, eses remitentes recibiron unha notificación de rebote inmediata e deben volver enviar os seus correos electrónicos.

Podo configurar dous provedores de DNS ao mesmo tempo (Cloudflare + Route 53) simplemente enumerando dous Cloudflare NS rexistros e dúas Ruta 53 NS rexistros no meu rexistro?¶

Si, sempre que `DNSSEC` está desactivado (ou configurado correctamente con `RFC 8901` Multi-Signer DNSSEC) e ambos provedores ofrecen rexistros DNS idénticos. Os resolvedores recursivos consultan todos os pais listados `NS` rexistros usando a selección de latencia round-robin/RTT (`SRTT`). Se listas `ns1.providerA.com`, `ns2.providerA.com`, `ns1.providerB.com`, e `ns2.providerB.com` nos servidores de nomes personalizados do teu rexistrador e mantén ambas zonas sincronizadas usando **OctoDNS**, **DNSControl**, **Terraform** ou `AXFR / IXFR` transferencias de zona, o teu dominio sobrevive automaticamente a unha interrupción do 100 por cento de calquera dos provedores de DNS.

Cal é a diferenza entre clientHold e serverHold en WHOIS?¶

Códigos de estado EPP que comezan por **`client...`** (`clientHold`, `clientTransferProhibited`) son definidas polo teu **Rexistrador de dominios** (o venda polo miúdo onde xestionas a túa conta, como Namecheap ou GoDaddy) e o soporte ou o sistema de facturación do teu rexistrador pode eliminarlos inmediatamente. Códigos de estado que comezan por **`server...`** (`serverHold`, `serverTransferProhibited`) son configurados directamente polo **Operador de rexistro de TLD** (`Verisign`, `PIR`, `Nominet`) debido a órdenes xudiciais, disputas UDRP, suspensións de abuso a nivel de rexistro ou **Bloqueo de rexistro** de hardware, e esixen que se poña en contacto co Rexistro a través do seu rexistrador para levantalo.

Guías relacionadas¶

• Secuestro de nomes de dominio, DNS caducado e toma de control do sitio web
• O certificado SSL/TLS caducou na produción, o bloqueo de precarga de HSTS, o bloqueo de rexistros CA CAA e a renovación de emerxencia
• Bloqueo de administrador de dominio personalizado de Google Workspace ou Microsoft 365, verificación de DNS TXT e rescate de inquilinos
• Secuestro de DNS, reconfiguración da WAN do enrutador ISP e suplantación do portal cativo
• Crise de hospedaxe web, migración e restauración de copias de seguridade
• Números de emerxencia por país

Fontes e orientacións oficiais¶

• Corporación de Internet para Nomes e Números Asignados (ICANN): Política de recuperación de rexistro caducada (ERRP), Política de eliminación de dominios caducada (EDDP), Política de transferencia entre rexistradores (bloqueo de cambio de rexistrador de 60 días) e referencia de códigos de estado do EPP (clientHold, redemptionPeriod, pendingDelete).
• Grupo de traballo de enxeñería de Internet (IETF): RFC 6781 (DNSSEC Operational Practices: Key Rollovers and Emergency). DS Eliminación) & RFC 8901 (Modelos DNSSEC de asinantes múltiples para DNS con autoridade de varios provedores).
• Instituto Nacional de Estándares e Tecnoloxía (NIST) (Estados Unidos): Publicación especial 800-81-2: Sistema seguro de nomes de dominio (DNS) Guía de implantación.
• Axencia de Seguridade Cibernética e de Infraestruturas (CISA) (Estados Unidos): Directiva de emerxencia 19-01: Mitigación da manipulación da infraestrutura DNS.
• Axencia da Unión Europea para a Ciberseguridade (ENISA): Orientación técnica NIS2 para provedores de servizos DNS e rexistros de nomes de TLD.