Mon site a disparu du jour au lendemain : la vérification ICANN expliquée

Le contexte : une infrastructure solide… mais un site mort

Tout développeur web a vécu ce moment de panique : le site d'un client devient inaccessible sans raison apparente. Pas de panne serveur, pas d'erreur de code, pas de facture impayée. Les containers Docker tournent parfaitement, les logs sont propres. Et pourtant — le site est mort.

C'est exactement ce qui m'est arrivé récemment. L'infrastructure était solide : un container nginx servant une application React buildée avec Vite, un container Certbot gérant le renouvellement automatique du certificat SSL, le tout orchestré avec Docker Compose sur un VPS Ubuntu.

# En SSH sur le serveur, tout semblait normal
docker ps

NAMES              STATUS
app-landing        Up 24 minutes
app-certbot        Up 24 minutes

# Mais en tentant de résoudre le domaine...
nslookup mondomaine.com

;; connection timed out; no servers could be reached

# Diagnostic plus précis
dig mondomaine.com

;; ANSWER SECTION: (vide — aucun enregistrement DNS)

Le domaine ne répondait plus. Aucun enregistrement DNS. Comme si le domaine n'existait plus. Après avoir vérifié les logs, les containers, la configuration Nginx et le certificat SSL — tout était parfaitement en ordre côté technique. Le problème venait d'ailleurs.

Le coupable : la procédure de vérification ICANN

L'ICANN (Internet Corporation for Assigned Names and Numbers) est l'organisme international qui régule les noms de domaine sur internet. Il impose à tous les registrars — les revendeurs de noms de domaine comme OVH, Namecheap, LWS, Gandi — de vérifier l'adresse email associée à chaque domaine enregistré.

Le processus est simple mais implacable :

1. Tu enregistres un domaine
2. Le registrar envoie un email à l'adresse associée au compte
3. Tu dois cliquer sur un lien de validation dans un délai de 15 jours
4. Si tu ne le fais pas → le domaine est suspendu

Dans mon cas, l'email de vérification avait été envoyé quelques jours après l'enregistrement du domaine. Il était passé inaperçu — probablement noyé dans la boîte de réception au moment du lancement du projet, entre les emails de confirmation de commande, les accès FTP, et les notifications diverses.

Le tableau de bord du registrar affichait clairement le statut "Verification" en orange dans la section domaines — mais sans connaître ce mécanisme, on peut très facilement passer à côté de cette indication.

Pourquoi cet email est si facile à rater

L'email de vérification ICANN cumule plusieurs caractéristiques qui le rendent particulièrement invisible :

• L'objet est en anglais : "IMMEDIATE VERIFICATION required for mondomaine.com" — sur un compte francophone, ça ressemble à du phishing ou du spam
• Il arrive au mauvais moment : juste après l'enregistrement, quand tu reçois déjà 4 ou 5 autres emails (confirmation de commande, facture, accès à l'espace client, DNS…)
• Le délai de 15 jours semble long mais passe très vite quand on est en plein développement d'un projet
• Les filtres anti-spam l'envoient parfois directement dans le dossier Spam ou Promotions
• Aucune relance : contrairement à d'autres services, l'ICANN n'envoie pas de rappel à J-5 ou J-1

Point important : Ce mécanisme s'applique à tous les TLD gérés par l'ICANN : .com, .net, .org, .io, .dev, .app, et la grande majorité des extensions nouvelles. Les extensions nationales comme .fr ou .be ont leurs propres règles, souvent différentes.

Les conséquences d'une suspension ICANN

Quand un domaine est suspendu par le registre, l'impact est total et immédiat :

Et contrairement à ce qu'on pourrait croire, le registrar ne peut rien faire directement : c'est le registre supérieur (Verisign pour les .com, PIR pour les .org) qui applique la suspension sur instruction de l'ICANN. Le registrar n'est qu'un intermédiaire.

# Vérifier le statut WHOIS d'un domaine suspect
whois mondomaine.com | grep -i status

# Un domaine suspendu affiche :
Domain Status: clientHold https://icann.org/epp#clientHold
Domain Status: serverHold https://icann.org/epp#serverHold

# Un domaine sain affiche :
Domain Status: clientTransferProhibited
Domain Status: clientUpdateProhibited

La résolution : plus simple qu'on ne le croit

Heureusement, la réactivation est rapide si le délai n'est pas trop largement dépassé. La procédure complète :

# Étape 1 : Confirmer le diagnostic DNS
dig mondomaine.com +short
# Si aucun résultat → problème DNS confirmé

# Étape 2 : Vérifier le statut WHOIS
whois mondomaine.com | grep -E "Status|Expiry|Registrar"

# Étape 3 : Chercher l'email de vérification
# Dans Gmail : chercher "VERIFICATION" ou "verify" dans tous les dossiers
# Y compris Spam et Promotions

# Étape 4 : Si le lien est expiré, forcer le renvoi
# → Aller dans l'espace client du registrar
# → Editer les coordonnées du compte → Sauvegarder
# → Un nouvel email de vérification est envoyé automatiquement

# Étape 5 : Après validation, attendre la propagation DNS
# Vérifier toutes les 30 minutes :
dig mondomaine.com @8.8.8.8 +short

Dans mon cas, le lien de vérification était encore actif malgré quelques jours de dépassement. Après avoir cliqué, le domaine est revenu en ligne en quelques heures, le temps de la propagation DNS mondiale.

Comment éviter que ça vous arrive

Lors de l'enregistrement d'un nouveau domaine

# Checklist immédiate après achat d'un domaine
# 1. Chercher l'email ICANN dans la boîte mail
grep -i "verification\|icann\|verify domain" ~/boite-mail

# 2. Cliquer sur le lien de validation DANS LES 24H
# Ne pas remettre à plus tard

# 3. Vérifier le statut WHOIS quelques heures après
whois mondomaine.com | grep Status

# Résultat attendu (domaine actif et vérifié) :
# Domain Status: clientTransferProhibited

Mettre en place une surveillance DNS

#!/bin/bash
# dns-monitor.sh - Alerter si un domaine ne résout plus

DOMAIN="mondomaine.com"
RESULT=$(dig +short $DOMAIN @8.8.8.8)

if [ -z "$RESULT" ]; then
    echo "ALERTE: $DOMAIN ne résout plus !" | mail -s "DNS Alert" admin@example.com
    logger -t dns-monitor "ALERTE: $DOMAIN DNS failed"
else
    echo "DNS OK: $DOMAIN -> $RESULT"
fi

# Planifier toutes les heures
# crontab -e
# 0 * * * * /home/ubuntu/dns-monitor.sh

Ce que cette expérience m'a appris

Au-delà du problème ICANN lui-même, cette panne m'a rappelé quelques principes fondamentaux souvent oubliés dans l'excitation d'un nouveau projet :

• Toujours vérifier le DNS avant les logs applicatifs : quand un site devient inaccessible, commencez par dig ou nslookup avant d'inspecter Nginx ou PHP-FPM
• L'infrastructure technique et la gestion administrative vont de pair : un serveur parfaitement configuré ne sert à rien si le DNS est mort
• Surveiller le tableau de bord registrar régulièrement : un statut orange ou rouge est un signal d'alarme à ne pas ignorer
• Documenter les étapes post-lancement : créer une checklist pour chaque nouveau projet, incluant la validation ICANN

Conseil pro : Configurez une adresse email de contact pour vos domaines qui est réellement consultée (pas une adresse de projet abandonnée). Les communications administratives importantes — renouvellement, vérification ICANN, transfert — arrivent sur cette adresse. Utilisez un alias ou une adresse générique type domains@votre-agence.com que vous surveillez activement.

Récapitulatif : la vérification ICANN en 5 points

Un serveur bien configuré, un certificat SSL valide, des containers Docker qui tournent — tout cela ne sert à rien si le DNS est coupé pour un email non lu. La partie administrative de la gestion de domaine est aussi importante que la partie technique. Ne la négligez pas.