Votre site répond sur www.example.com, mais example.com affiche une erreur, un autre site ou une alerte de certificat. La documentation Cloudflare sur le domaine racine rappelle que la résolution DNS et la couverture TLS sont deux conditions distinctes.
Intention de recherche : localiser la panne entre domaine nu et www avant toute correction. Les adresses et domaines de ce guide sont fictifs ; utilisez uniquement vos propres serveurs.
1. Comparer les deux noms couche par couche
Le domaine nu, ou apex, et www sont deux noms DNS différents. Un CNAME est un alias DNS, pas une redirection HTTP. Un A fournit IPv4 ; un AAAA fournit IPv6. À l’apex, un CNAME standard entre en conflit avec les enregistrements nécessaires de la zone ; ALIAS et aplatissement sont des mécanismes propres aux fournisseurs.
dig example.com A +shortdig example.com AAAA +shortdig www.example.com CNAME +shortdig www.example.com A +shortdig www.example.com AAAA +shortnslookup example.com 1.1.1.1Comparez avec l’architecture prévue, pas seulement entre les noms : un CDN peut légitimement retourner plusieurs IP. Une absence d’A peut être normale si le service est volontairement IPv6 seul ; elle ne répond toutefois pas aux clients IPv4 seuls.
Poursuivez avec un terminal POSIX et curl :
curl -4 -I https://example.com/curl -4 -I https://www.example.com/curl -6 -I https://example.com/curl -IL --max-redirs 5 https://www.example.com/Un échec de résolution oriente vers DNS. Une erreur de certificat précède HTTP. Un Location répété révèle une boucle probable ; une réponse 404 ou un autre site peut indiquer le mauvais hôte virtuel. L’échec IPv6 n’est pertinent que depuis un réseau IPv6 fonctionnel.
2. Isoler l’origine et corriger la bonne couche
Risque : modifier le DNS ou les redirections peut interrompre les visiteurs et créer des redirections persistantes. Sauvegardez zone, configuration proxy/Web et certificat actuellement déployé.
- Testez l’IP d’origine autorisée en conservant le nom TLS et HTTP :
curl --resolve example.com:443:192.0.2.80 \ -I https://example.com/Cette commande remplace la résolution pour ce test. Si l’origine utilise volontairement un certificat privé réservé au proxy, un échec de confiance direct ne prouve pas une panne publique.
- Si l’origine répond correctement mais pas le chemin public, inspectez le proxy : nom d’hôte transmis, routage, certificat de bord et journaux. Si l’origine échoue aussi, examinez son certificat et l’hôte virtuel. Un code HTTP seul ne désigne pas avec certitude son émetteur ; corrélez les journaux.
- Corrigez les enregistrements manquants selon votre architecture. Exemple DNS simple, sans proxy :
example.com. 300 IN A 192.0.2.80www.example.com. 300 IN CNAME example.com.- Configurez le serveur ou proxy pour accepter les deux noms et présenter un certificat les couvrant. Un wildcard
*.example.comne couvre pas le domaine nu. - Choisissez une URL canonique, puis créez une seule direction de redirection. Testez d’abord temporairement avant de rendre la redirection permanente. HTTPS doit fonctionner sur le nom source avant sa redirection.
Retour arrière
Restaurez la dernière configuration Web/proxy valide et les anciens enregistrements si nécessaire. Tenez compte du TTL DNS et des redirections déjà mémorisées par les navigateurs. Gardez l’ancienne destination disponible pendant la convergence.
3. Vérification finale
Testez les quatre entrées HTTP/HTTPS, avec/sans www, depuis un autre réseau. Vérifiez le certificat de chaque nom, l’absence de boucle et la destination finale, y compris un chemin de page et ses paramètres.
Erreurs courantes
Ne corrigez pas un certificat en ajoutant un CNAME. N’oubliez pas un AAAA obsolète ni un hôte virtuel par défaut. Ne masquez pas une alerte TLS avec curl -k pour déclarer le test réussi.
Sources : Cloudflare, domaine racine et TLS, curl, résolution ciblée et redirections.