Panne du registraire de domaine ou du fournisseur DNS : délai de grâce de rachat de domaine expiré, DNSSEC SERVFAIL Migration de pièges et de serveurs de noms d'urgence¶

En vous réveillant, vous découvrirez que le site Web principal de votre entreprise, les points de terminaison de l'API (api.example.com) et la messagerie d'entreprise (MX enregistrements pour Google Workspace ou Microsoft 365) sont totalement inaccessibles dans le monde entier (DNS_PROBE_FINISHED_NXDOMAIN ou SERVFAIL) est une crise d’infrastructure totale. Contrairement à un seul serveur Web en panne qui affecte un service, un système de noms de domaine (DNS) ou un échec d'enregistrement de domaine coupe simultanément tous les services de votre domaine racine, y compris l'authentification unique (SSO), les portails de support client et les e-mails entrants de réponse aux incidents. En pratique, les pannes de domaine mondiales proviennent de trois déclencheurs distincts : (1) une expiration accidentelle de domaine où une carte de crédit enregistrée a expiré et le registraire a détourné votre NS enregistrements pour pointer vers une page de stationnement au paiement par clic 24 to 48 hours avant la date d'expiration réelle ; (2) une attaque DDoS ou une panne du plan de contrôle chez votre fournisseur DNS faisant autorité (Route 53, Cloudflare, GoDaddy, Namecheap, DNSimple, NS1); ou (3) un cassé DNSSEC (DS record) chaîne de confiance lors d'un changement précipité de serveur de noms qui entraîne la validation des résolveurs (8.8.8.8, 1.1.1.1, résolveurs FAI) pour supprimer 100 % de votre trafic avec SERVFAIL. Si un attaquant a compromis vos identifiants de connexion au bureau d'enregistrement et a transféré ou modifié votre domaine de manière malveillante, passez à détournement de nom de domaine, DNS expiré et prise de contrôle de sites Web; si votre certificat TLS a expiré ou est tombé en panne après la récupération du DNS, consultez Le certificat SSL/TLS a expiré en production, verrouillage du préchargement HSTS et renouvellement d'urgence et Verrouillage de l'administrateur de domaine personnalisé Google Workspace ou Microsoft 365 et vérification DNS. Si cette panne désactive les communications cliniques de l'hôpital, le routage de répartition des urgences 911/112 ou les services publics critiques, appelez votre numéro d'urgence local (911 aux États-Unis et au Canada, 112 dans toute l'Union européenne, 999 au Royaume-Uni) ou consultez notre annuaire des numéros d'urgence.

Fais ça maintenant¶

1. ** Diagnostiquez en 10 secondes si la panne est un domaine expiré/suspendu (EPP Status), une panne de fournisseur DNS faisant autorité ou un DNSSEC Échec de validation** :
2. Courir whois yourdomain.com | grep -iE "Status|Expiry|Name Server" et dig +trace yourdomain.com.
3. Testez si le contournement DNSSEC validation (+cd = Coche désactivée) permet à votre domaine de se résoudre à nouveau :

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

   Si la première commande renvoie status: SERVFAIL tandis que la deuxième commande (+cd) renvoie immédiatement status: NOERROR avec l'adresse IP de votre serveur, vos serveurs DNS ne sont PAS en panne : votre DNSSEC (DS dossier au registraire) est rompu. Passez immédiatement à la phase 3 pour supprimer les fichiers obsolètes. DS enregistrez-vous auprès de votre registraire.
4. Si votre domaine a expiré (Auto-Renew Grace Period ou Redemption Grace Period), connectez-vous immédiatement à votre bureau d'enregistrement actuel et payez les frais de renouvellement/rachat ; N'attendez PAS que le domaine soit "abandonné" pour pouvoir le réenregistrer à moindre coût :
5. Pendant les 1 à 45 jours après l'expiration (Auto-Renew Grace Period), le renouvellement dans le tableau de bord de votre registraire restaure vos serveurs de noms d'origine au coût de renouvellement standard ($10 to $30).
6. Pendant les 30 jours Redemption Grace Period (RGP / redemptionPeriod), vous devez payer les frais de rachat de registre obligatoires ($80 to $250) via votre registraire actuel. Si vous attendez que le domaine termine les 5 jours Pending Delete phase à sauvegarder $100, des robots tireurs d'élite automatisés qui capturent les chutes (DropCatch, SnapNames, NameJet) récupérera votre domaine dans 5 milliseconds de sortie et le vendre aux enchères pour des milliers de dollars.
7. ** Ne changez JAMAIS vos serveurs de noms (NS) loin d'un fournisseur DNS compatible DNSSEC (comme Cloudflare, Route 53 ou Google Cloud DNS) sans supprimer le DS enregistrez d'abord auprès de votre registraire** : si DNSSEC est activé et vous échangez votre NS enregistrements vers un fournisseur DNS de secours lors d'une panne sans supprimer le parent DS (Delegation Signer) enregistrer dans le .com / .org Zone TLD en premier, chaque résolveur de validation sur Terre rejettera les réponses non signées du nouveau fournisseur DNS comme une attaque d'usurpation cryptographique (SERVFAIL).
8. Si vous n'avez pas accès à votre entreprise @yourdomain.com email parce que votre domaine MX les enregistrements sont en panne, ne cliquez PAS sur "Envoyer le code de réinitialisation du mot de passe à admin@yourdomain.com" chez votre registraire : pendant que votre domaine est NS ou MX les enregistrements sont hors ligne, tout e-mail de vérification envoyé à @yourdomain.com rebondit ou disparaît dans une file d'attente. Utilisez le SMS/Authenticator MFA de votre registraire, l'e-mail de sauvegarde hors bande (@gmail.com / @proton.me), ou flux de vérification d'identité par téléphone.
9. Après avoir renouvelé un domaine expiré, vérifiez manuellement que votre registraire a restauré vos serveurs de noms personnalisés d'origine (NS) au lieu de quitter le domaine sedoparking.com / renewyourname.net : Lorsqu'un domaine expire, les bureaux d'enregistrement écrasent votre personnalisé NS enregistrements avec des serveurs de noms de stationnement (ns1.parklogic.com, dns1.name-services.com). Parfois, le paiement du renouvellement met à jour la date d'expiration à l'année prochaine tout en laissant les serveurs de noms de stationnement actifs jusqu'à ce que vous les rétablissiez manuellement.
10. ** Vider les caches DNS récursifs publics mondiaux (Google 8.8.8.8, Cloudflare 1.1.1.1, OpenDNS) à la seconde où votre NS ou DS les enregistrements sont restaurés** : au lieu d'attendre 24 à 48 heures pour la mise en cache NXDOMAIN ou page de stationnement NS que les enregistrements expirent naturellement, déclenchez une purge globale instantanée du cache sur Google Public DNS (developers.google.com/speed/public-dns/cache) et Cloudflare 1.1.1.1 (one.one.one.one/purge-cache/).

Arbre de décision : triage d'urgence en cas de panne de domaine global ou de DNS¶

Utilisez cet organigramme pour identifier la couche exacte de la hiérarchie DNS (TLD Registry, Registrar EPP Status, DNSSEC DS Chain, ou Authoritative Nameserver) où la résolution échoue :

flowchart TD
    Start["Panne mondiale : échec de résolution du domaine Web et de la messagerie électronique (NXDOMAIN / SERVFAIL)"] --> RunDiag["Exécutez : whois domain.com ET creusez @8.8.8.8 domain.com +cd"]

    RunDiag --> CheckCD{"Est-ce que dig @8.8.8.8 domain.com échoue, lors de l'ajout de +cd réussit ?"}

    CheckCD -->|"Oui : fonctionne avec +cd, échoue sans +cd"| DnssecBreak["Chaîne de confiance DNSSEC rompue : supprimer l'enregistrement DS périmé au niveau du bureau d'enregistrement OU re-signer la zone -> Vider 8.8.8.8 et 1.1.1.1"]

    CheckCD -->|"Non : IP de stationnement en échec ou en retour"| CheckWhois{"Inspecter le statut et la date d'expiration du domaine WHOIS EPP"}

    CheckWhois -->|"Statut : clientHold ou serverHold"| HoldState["Bureau d'enregistrement/suspension du registre : effectuez immédiatement la vérification de l'e-mail RAA de l'ICANN OU le ticket d'abus/facturation"]

    CheckWhois -->|"Date d'expiration dépassée (Statut : autoRenewPeriod)"| GraceRenew["Jour 1 à 45 après l'expiration : payer le renouvellement standard dans le portail du registraire -> Vérifier le NS personnalisé restauré"]

    CheckWhois -->|"Statut : période de rachat (RGP)"| RgpRestore["Jours 45 à 75 après l'expiration : ouvrez un ticket d'assistance urgent pour le bureau d'enregistrement / payez les frais de restauration RGP (80 $ à 250 $) immédiatement"]

    CheckWhois -->|"Statut : en attenteSupprimer"| PendingDel["Verrouillage final de 5 jours : ne peut pas être renouvelé auprès du registraire -> Passez maintenant des commandes en souffrance sur tous les principaux Drop-Catchers"]

    CheckWhois -->|"Statut : ok / clientTransferProhibited ET expiration future"| AuthDown["Enregistrement de domaine sain -> Panne du fournisseur DNS faisant autorité ou zone manquante"]

    AuthDown --> MigrateNS["Importer le fichier de zone (`BIND` / Terraform) vers le fournisseur DNS secondaire -> Supprimer l'enregistrement DS si DNSSEC est activé -> Mettre à jour NS chez le registraire"]

Phase 1 : le cycle de vie de l'expiration des domaines de l'ICANN (Auto-Renew contre Redemption contre Pending Delete)¶

Lorsqu'un domaine générique de premier niveau (gTLD comme .com, .net, .org, .io, .ai, .co, .app, .dev) expire parce qu'une carte de crédit à renouvellement automatique a échoué ou qu'une carte de financement a été annulée après le départ d'un employé, le domaine passe par un cycle de vie strict en plusieurs étapes régi par ** la politique de récupération des enregistrements expirés de l'ICANN (ERRP)** et les accords des opérateurs de registre (Verisign pour .com/.net, PIR pour .org, Identity Digital).

Comment un domaine meurt et pourquoi il se déconnecte AVANT ou LE premier jour de son expiration¶

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

Comparez vos droits exacts, vos coûts et vos actions de récupération à chaque étape de l'expiration, y compris les domaines de premier niveau de code pays (ccTLDs comme .uk, .de, .eu, .ca, .au), qui ne suivent pas l'ICANN gTLD règles :

Phase 2 : Récupération étape par étape d'un fichier expiré ou RedemptionPeriod domaine¶

Suivez cette séquence exacte pour remettre en ligne un domaine expiré dans les plus brefs délais :

Étape 1 : récupérez l'accès à votre compte de registraire lorsque @yourdomain.com l'email est mort¶

Voici le Catch-22 classique d'un domaine expiré : - Votre domaine (company.com) a expiré, donc MX enregistrements pour company.com arrêté de résoudre. - Vous essayez de vous connecter à votre registraire de domaine (GoDaddy, Namecheap, Cloudflare, Porkbun, Hover, Network Solutions, Gandi), et le registraire dit : "Nous avons envoyé un code de vérification à 6 chiffres à admin@company.com." - Parce que company.com est expiré, cet e-mail ne pourra jamais arriver.

Comment sortir immédiatement de la boucle de messagerie des domaines expirés : 1. Ne transférez ni ne modifiez rien pour l'instant : vérifiez si vous pouvez lancer un récupérateur de courrier d'urgence temporaire UNIQUEMENT si le domaine n'a pas expiré (si le domaine lui-même a expiré au niveau TLD, MX ne peut être résolu nulle part tant qu'il n'est pas renouvelé). 2. Utilisez le canal de récupération de compte « Accès aux e-mails perdus / Domaine expiré » du registraire : - Presque tous les bureaux d'enregistrement accrédités par l'ICANN fournissent un flux de travail dédié de vérification des numéros de téléphone ou des identifiants gouvernementaux / des documents de constitution d'entreprise, spécifiquement pour les clients dont l'adresse e-mail de connexion se trouve @ le domaine expiré dans le compte. - Préparez trois éléments avant d'appeler l'assistance du registraire : (a) les 4 derniers chiffres de la carte de crédit ou de l'ID de transaction PayPal utilisé sur la facture de renouvellement précédente, (b) votre ID de compte de registraire/PIN client, et © une pièce d'identité gouvernementale avec photo + statuts constitutifs/facture de services publics correspondant à l'organisation d'enregistrement WHOIS (Tech / Admin / Registrant). 3. Une fois connecté, changez immédiatement l'adresse e-mail de votre compte de registraire en un domaine externe (@gmail.com, @proton.me, ou un domaine d'urgence distinct que vous possédez) et activez Clé de sécurité matérielle (FIDO2) ou TOTP Authenticator App MFA pour que la connexion ne dépende jamais de @company.com envoyez à nouveau un e-mail.

Étape 2 : Exécuter le renouvellement ou RedemptionPeriod (RGP) Restaurer¶

1. Si le domaine est en phase 1 (Auto-Renew Grace Period, Jours 1 au 30/45) :
2. Accédez à Facturation -> Renouvellements ou Liste de domaines -> Filtre expiré et payez la facture de renouvellement.
3. Contrôle critique 60 secondes après le paiement : ouvrez les serveurs de noms du domaine (NS) paramètres dans le tableau de bord du registraire. Vérifiez si le registraire rétablit automatiquement vos vrais serveurs de noms (par exemple, ns-123.awsdns-15.com ou ada.ns.cloudflare.com) ou a quitté le domaine en pointant vers ses serveurs de stationnement expirés (ns1.sedoparking.com / dns1.registrar-servers.com). Si les serveurs de stationnement sont toujours répertoriés, ressaisissez manuellement vos serveurs de noms de production et enregistrez.
4. Si le domaine est en phase 2 (Redemption Grace Period / redemptionPeriod, Jours 30/45 à 75) :
5. Recherchez dans un onglet séparé dans le tableau de bord de votre registraire, souvent intitulé Domaines expirés -> Rachat, Corbeille/Restauration ou Facturation grâce/rédemption.
6. Payez les frais de restauration RGP + renouvellement 1 an.
7. Comment fonctionne la restauration RGP au Registre (Verisign / PIR) ? Lorsque vous payez les frais RGP, votre registraire envoie un EPP <update><restore op="request"> commande au registre TLD. Le registre change immédiatement le statut du domaine de redemptionPeriod à pendingRestore et met celui de votre domaine NS enregistre dans la zone racine du TLD dans un délai de 15 à 60 minutes pendant que votre registraire soumet le restore op="report" attestation de conformité.

Étape 3 : Contourner les retards du cache du FAI local en purgeant 8.8.8.8 et 1.1.1.1¶

Lorsque votre domaine a expiré, les résolveurs DNS récursifs du monde entier ont mis en cache les serveurs de noms de stationnement ou les noms négatifs. NXDOMAIN réponse (régie par le TLD SOA Minimum TTL, généralement 900 à 3,600 secondes, ou 86,400 secondes pendant NS enregistrements). L'instant dig @a.gtld-servers.net yourdomain.com NS (en interrogeant le .com serveur racine directement) affiche à nouveau vos vrais serveurs de noms de production : 1. Ouvrez le cache de vidage DNS public de Google (https://developers.google.com/speed/public-dns/cache) : - Type affleurant NS d'abord pour yourdomain.com, puis rincez SOA, A, AAAA, MX, et TXT. 2. Ouvrez Cloudflare 1.1.1.1 Purger le cache (https://one.one.one.one/purge-cache/) : - Purger NS, A, AAAA, et MX pour yourdomain.com.

Phase 3 : Serveur de noms d'urgence (NS) Migration lors d'une panne de fournisseur DNS (et le DNSSEC Piège)¶

Que se passe-t-il si l'enregistrement de votre domaine est valide à 100 % et n'a pas expiré, mais que votre fournisseur DNS faisant autorité (Route 53, Cloudflare, GoDaddy DNS, DigitalOcean DNS, Azure DNS, DNSimple, Dyn) subit une panne catastrophique ou une attaque DDoS et vous devez migrer les serveurs de noms de votre domaine (NS) vers un fournisseur DNS de sauvegarde en ce moment ?

Le tueur de migration n°1 : le changement NS Alors que DNSSEC (DS Enregistrer) est activé¶

Avant de changer un seul NS enregistrez chez votre registraire, exécutez cette commande pour vérifier si DNSSEC est activé sur votre domaine au niveau du registre TLD parent :

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

Liste de contrôle de migration sécurisée du serveur de noms d'urgence (zéro SERVFAIL Procédure)¶

1. Reconstruisez ou importez d'abord votre fichier de zone DNS complet auprès du nouveau fournisseur DNS :
2. Ne devinez jamais vos enregistrements DNS de mémoire (@, www, et api sont rarement les seuls enregistrements ; oubli MX, SPF/TXT, DKIM, _dmarc, autodiscover, ou CAA interrompt la livraison des e-mails et les renouvellements TLS).
3. Où trouver votre zone DNS complète lorsque le tableau de bord de votre fournisseur DNS principal est en panne :
   • Vérifiez l'infrastructure en tant que code (Terraform, Pulumi, OctoDNS, DNSControl) dans votre dépôt Git.
   • Vérifiez les exportations de zone récentes (BIND .zone fichiers) ou recherchez des bases de données DNS historiques (SecurityTrails, ViewDNS.info, DNSDumpster, ou Censys / crt.sh pour les sous-domaines).
   • Requête des enregistrements mis en cache toujours présents dans les résolveurs récursifs publics (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) avant l'expiration de leur durée de vie.
4. Vérifiez que le nouveau fournisseur DNS répond avec autorité à chaque enregistrement critique AVANT de toucher votre bureau d'enregistrement : Supposons que votre nouveau fournisseur vous assigne ns1.rescuedns.com et ns2.rescuedns.com. Testez-les directement avec 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
   

   Attendez que le flags: ligne dans le dig l'en-tête inclut explicitement aa (Authoritative Answer) et revient status: NOERROR.
5. Si dig +short yourdomain.com DS a rendu un DS enregistrer, manipuler DNSSEC au bureau d'enregistrement :
6. Pendant une panne active où l'ancien fournisseur DNS est complètement inaccessible : connectez-vous à votre registraire de domaine (où vous avez acheté le domaine), accédez à la section Enregistrements DNSSEC/DS et supprimez tout. DS records afin que le domaine revienne à unsigned (Insecure) dans la zone parent du TLD. Attendez que dig +short yourdomain.com DS @a.gtld-servers.net renvoie vide (et vide DS dans 8.8.8.8 / 1.1.1.1), ou ajoutez le nouveau fournisseur DNS DS enregistrez-le à côté de l'ancien si vous effectuez une migration multi-signataire planifiée.
7. Mettre à jour les serveurs de noms (NS) auprès de votre registraire de domaine : Remplacez les serveurs de noms morts par ns1.rescuedns.com et ns2.rescuedns.com dans le panneau Serveurs de noms personnalisés de votre bureau d'enregistrement (remarque : modification NS les enregistrements dans l'éditeur de zone ne font rien lorsque les anciens serveurs sont morts ; vous devez modifier les Serveurs de noms de délégation Glue / Parent au niveau du registraire).
8. Purge NS et DS caches sur Google (8.8.8.8) et Cloudflare (1.1.1.1) : Utilisez les outils de purge du cache public de la phase 2, étape 3 pour forcer l'adoption immédiate des nouveaux serveurs de noms.

Phase 4 : Survivre au verrouillage de transfert du bureau d'enregistrement de l'ICANN pendant 60 jours en cas d'urgence¶

Que faire si vous devez transférer votre domaine vers un nouveau registraire (ICANN Inter-Registrar Transfer), pour ensuite être bloqué par Domain Status: clientTransferProhibited et un message indiquant : "Ce domaine est soumis à un verrouillage de transfert ICANN de 60 jours car les informations de contact ont été récemment mises à jour" ?

1. Pourquoi le verrouillage de 60 jours s'est déclenché : en vertu de la Politique de transfert de l'ICANN (Section II.C.1), les bureaux d'enregistrement placent un verrouillage de transfert de 60 jours chaque fois qu'un domaine est nouvellement enregistré, transféré entre bureaux d'enregistrement ou subit un "Changement de titulaire" (mise à jour du prénom, du nom, du nom de l'organisation ou de l'adresse e-mail du contact du titulaire).
2. Comment contourner ou se désinscrire du verrouillage de 60 jours en cas de changement de titulaire :
3. Avant de modifier les coordonnées WHOIS : Presque tous les principaux bureaux d'enregistrement proposent une case à cocher directement sur l'écran de modification du contact intitulée : "Désactiver le verrouillage de transfert de 60 jours après cette mise à jour du contact." Cocher cette case vous permet de mettre à jour votre adresse e-mail d'administrateur/inscrit tout en générant un EPP Auth-Code (Transfer Secret) pour transférer le domaine le jour même.
4. N'oubliez pas que vous n'avez PAS besoin de transférer l'enregistrement du domaine pour changer de fournisseur DNS : Même si un domaine est verrouillé pendant 60 jours contre les Transferts de registraire (clientTransferProhibited), vous pouvez toujours modifier ses Serveurs de noms (NS records) auprès du bureau d'enregistrement actuel à tout moment sans délai d'attente ; le changement de DNS prend quelques minutes, alors qu'un transfert complet de bureau d'enregistrement prend jusqu'à 5 à 7 jours à moins que le bureau d'enregistrement perdant clique sur un instant Approuver le transfert sortant (FOa) bouton.

Phase 5 : renforcement des enregistrements de domaine et du DNS contre de futures pannes¶

Une fois votre domaine et votre résolution DNS restaurés à 100 %, complétez cette liste de contrôle de résilience :

• Activer Registry Lock (serverDeleteProhibited, serverUpdateProhibited, serverTransferProhibited) sur les domaines de production critiques : Standard Registrar Lock (clientTransferProhibited) peut être désactivé d'un simple clic si un attaquant détourne votre connexion au bureau d'enregistrement. Registry Lock (proposé par Verisign, PIR, Cloudflare, CSC, MarkMonitor, Gandi et Porkbun/Namecheap pour les domaines d'entreprise) verrouille le domaine directement au niveau du registre TLD, nécessitant une vérification vocale/cryptographique hors bande de plusieurs personnes avant tout NS l'enregistrement peut être modifié ou le domaine supprimé.
• Renouveller les domaines de production 5 à 10 ans à l'avance (ICANN maximum horizon is 10 years) : Ne laissez jamais un domaine critique pour votre entreprise faire l'objet d'un renouvellement annuel, car une seule carte de crédit d'entreprise expirée peut déclencher une panne d'expiration. Payez d'avance 5 à 10 ans d'un coup.
• N'utilisez jamais un @yourdomain.com adresse e-mail comme contact de connexion ou de notification de facturation chez le registraire gérant yourdomain.com : utilisez une liste de distribution de sécurité dédiée sur un domaine administratif indépendant ou un compte externe renforcé, et surveillez RDAP / WHOIS dates d'expiration via des moniteurs Prometheus/Uptime externes automatisés (domain_expiry_days < 60).
• Inférieur NS et DS TTL (300 à 3600 secondes) 48 heures avant toute migration DNS planifiée : la réduction des TTL à l'avance garantit le basculement des résolveurs dans les 5 minutes suivant un basculement planifié.

Numéros d'urgence régionaux et protocoles des agences¶

Lorsqu'une panne de domaine ou de DNS affecte les établissements de santé, les services d'urgence, les services publics municipaux ou les infrastructures gouvernementales, suivez ces canaux de remontée d'informations régionaux :

• États-Unis et Canada : Composez 911 si une panne de domaine/DNS désactive la télémétrie de l'hôpital clinique, la répartition des ambulances ou les systèmes de sécurité des personnes. Signalez les attaques DDoS sur l'infrastructure DNS ou le détournement BGP/DNS à CISA (1-844-Say-CISA / cisa.gov/report), le FBI IC3 (ic3.gov), ou le Centre canadien pour la cybersécurité (1-833-CYBER-88). Pour .gov domaines, contactez le CISA .gov Service d'assistance du registraire.
• Royaume-Uni : Composez 999 pour les menaces de mort ou les perturbations aiguës du NHS. Signalez les pannes DNS critiques ou les piratages de domaine au NCSC (ncsc.gov.uk), et contactez Nominet (01865 332244) directement en cas d'urgence .uk / .gov.uk / .nhs.uk problèmes de registre.
• Union européenne : Composez 112 dans tous les États membres de l'UE. Les fournisseurs de services DNS et les registres de noms TLD sont réglementés par la Directive UE NIS2 (Directive 2022/2555) et doivent signaler les incidents de disponibilité significatifs à leur CSIRT national dans un délai de 24 heures.
• Australie et Nouvelle-Zélande : Composez 000 en Australie ou 111 en Nouvelle-Zélande ; signaler les incidents critiques de DNS ou de domaine à l'ACSC (1300 CYBER1), auDA (pour .au), ou Domain Name Commission NZ (pour .nz).
• Inde et Asie-Pacifique : Composez 112 en Inde pour les interventions d'urgence ; signaler les attaques d'infrastructure DNS/domaine à CERT-In (incident@cert-in.org.in) dans les 6 heures ou NIXI pour .in escalades de registre.

Questions fréquemment posées¶

Pourquoi mon domaine a-t-il cessé de fonctionner 24 heures AVANT son horodatage officiel d'expiration WHOIS ?¶

Tout d’abord, vérifiez les fuseaux horaires : WHOIS `Registry Expiry Date` est toujours imprimé en **UTC (`Z`)**, soit 4 à 8 heures en avance sur les fuseaux horaires nord-américains (ce qui signifie qu'un domaine expire à `2026-11-01T04:00:00Z` expire en fait à `8:00 PM PDT` le 31 octobre). Deuxièmement, si votre `NS` les enregistrements avaient un `24-hour` ou `48-hour` TTL et le registraire les ont échangés à `00:00 UTC` le jour de l'expiration, les utilisateurs dont les résolveurs ont été actualisés plus tôt accèdent immédiatement à la page de stationnement tandis que les autres restent en cache pendant des heures.

Mon registraire est complètement en faillite ou ne répond pas (Dead / De-accredited Registrar), et mon domaine expire. Comment puis-je le sauver ?¶

Lorsque l'ICANN résilie ou désaccrédite un bureau d'enregistrement défaillant dans le cadre de la **Procédure de transition des bureaux d'enregistrement désaccrédités (`DARTP`)**, l'ICANN transfère automatiquement tous les domaines en masse à un registraire dépositaire gagnant, sans frais pour les titulaires. Vérifier `whois yourdomain.com` (ou `lookup.icann.org`) pour voir quel **registraire** et **ID IANA** détient actuellement votre domaine, ou déposez une **plainte de renouvellement/transfert de domaine** urgente directement auprès de **conformité contractuelle de l'ICANN (`icann.org/compliance/complaint`)**.

Pourquoi mon site Web fonctionne-t-il pour certains clients avec des données cellulaires, mais affiche-t-il toujours la page de stationnement expirée sur le Wi-Fi de notre bureau 6 heures après le renouvellement du domaine ?¶

Le résolveur DNS récursif de votre réseau de bureau ou de votre FAI local a mis en cache la page de stationnement du registraire `NS` et `A` enregistrements alors que le domaine était expiré, et les serveurs de noms de stationnement définissaient notoirement des TTL élevés (`3,600` à `86,400` secondes / 24 heures) afin que les pages publicitaires restent mises en cache plus longtemps. Vider Google (`8.8.8.8`) et Cloudflare (`1.1.1.1`) à l'aide de leurs outils de purge Web, puis sur votre ordinateur local, exécutez `ipconfig /flushdns` (Windows), `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` (macOS), ou `sudo resolvectl flush-caches` (Linux).

Qu'arrive-t-il aux e-mails envoyés à @yourdomain.com Alors que notre domaine ou DNS a expiré pendant 18 heures ? Sont-ils perdus à jamais ?¶

Dans la plupart des cas, les emails légitimes envoyés pendant les 12 à 48 premières heures d'une panne DNS ne sont PAS perdus : ils sont mis en file d'attente sur le serveur de messagerie de l'expéditeur et arriveront automatiquement dans les heures suivantes. Sous **`RFC 5321` (Simple Mail Transfer Protocol, Section 4.5.4.1)**, lorsqu'un serveur de messagerie expéditeur (`Gmail`, `Microsoft Exchange Online`, `Postfix`) obtient un échec temporaire de recherche DNS (`SERVFAIL`) ou ne peut pas se connecter à un `MX` hôte, il place le message dans une file d'attente de nouvelles tentatives pendant **4 à 5 jours (`96 to 120 hours`)**, nouvelle tentative avec une interruption exponentielle. Cependant, si la page de stationnement expirée du registraire incluait un **wildcard null `MX` enregistrer (`0 .`)** ou un serveur de messagerie de stationnement qui a rejeté le courrier avec un problème `550 5.1.1 User Unknown` rebond permanent, ces expéditeurs reçoivent une notification de rebond immédiate et doivent renvoyer leurs e-mails.

Puis-je configurer deux fournisseurs DNS en même temps (Cloudflare + Route 53) simplement en listant deux Cloudflare NS records et deux Route 53 NS enregistrements chez mon registraire ?¶

Oui, tant que `DNSSEC` est désactivé (ou correctement configuré avec `RFC 8901` DNSSEC multi-signataire) et les deux fournisseurs servent des enregistrements DNS identiques. Les résolveurs récursifs interrogent tous les parents répertoriés `NS` enregistrements utilisant la sélection de latence round-robin/RTT (`SRTT`). Si vous listez `ns1.providerA.com`, `ns2.providerA.com`, `ns1.providerB.com`, et `ns2.providerB.com` dans les serveurs de noms personnalisés de votre registraire et gardez les deux zones synchronisées à l'aide de **OctoDNS**, **DNSControl**, **Terraform** ou `AXFR / IXFR` Lors des transferts de zone, votre domaine survit automatiquement à une panne de 100 % de l'un ou l'autre des fournisseurs DNS.

Quelle est la différence entre clientHold et serverHold dans WHOIS?¶

Codes de statut EPP commençant par **`client...`** (`clientHold`, `clientTransferProhibited`) sont définis par votre **registraire de domaine** (le détaillant auprès duquel vous gérez votre compte, tel que Namecheap ou GoDaddy) et peuvent être immédiatement supprimés par le support ou le système de facturation de votre registraire. Codes d'état commençant par **`server...`** (`serverHold`, `serverTransferProhibited`) sont définis directement par l'**opérateur de registre TLD** (`Verisign`, `PIR`, `Nominet`) en raison d'ordonnances judiciaires, de litiges UDRP, de suspensions abusives au niveau du registre ou de **verrouillage du registre** matériel, et nécessitent de contacter le registre via votre registraire pour le lever.

Guides associés¶

• Détournement de nom de domaine, DNS expiré et piratage de sites Web
• Le certificat SSL/TLS a expiré en production, le verrouillage du préchargement HSTS, le blocage des enregistrements CA CAA et le renouvellement d'urgence
• Verrouillage de l'administrateur de domaine personnalisé Google Workspace ou Microsoft 365, vérification DNS TXT et sauvetage des locataires
• Détournement DNS, reconfiguration WAN du routeur FAI et usurpation de portail captif
• Crise d'hébergement Web, migration et restauration des sauvegardes
• Numéros d'urgence par pays

Sources et directives officielles¶

• Internet Corporation pour l'attribution des noms et des numéros (ICANN): Politique de récupération des inscriptions expirées (ERRP), Politique de suppression de domaine expiré (EDDP), la politique de transfert entre bureaux d'enregistrement (verrouillage de changement de titulaire de 60 jours) et la référence des codes de statut EPP (clientHold, redemptionPeriod, pendingDelete).
• Groupe de travail sur l'ingénierie Internet (IETF) : RFC 6781 (Pratiques opérationnelles du DNSSEC : renouvellements de clés et mesures d'urgence). DS Suppression) & RFC 8901 (Modèles DNSSEC multi-signataires pour DNS faisant autorité multi-fournisseurs).
• Institut national des normes et de la technologie (NIST) (États-Unis) : Publication spéciale 800-81-2 : Secure Domain Name System (DNS) Guide de déploiement.
• Agence de cybersécurité et de sécurité des infrastructures (CISA) (États-Unis) : Directive d'urgence 19-01 : Atténuation de la falsification de l'infrastructure DNS.
• Agence de l'Union européenne pour la cybersécurité (ENISA) : Guide technique NIS2 pour les fournisseurs de services DNS et les registres de noms TLD.