Un bilan complet de délégation et de DNS
DNS et enregistrements
Lookup DNS Tous les enregistrements DNS d'un domaine Lookup d'enregistrement A Adresses IPv4 d'un domaine Lookup d'enregistrement AAAA Adresses IPv6 d'un domaine Lookup MX Serveurs de messagerie d'un domaine Lookup NS Serveurs de noms faisant autorité Lookup TXT Enregistrements TXT, SPF, vérification Lookup CNAME Enregistrements de nom canonique (alias) Lookup SOA Enregistrement Start of Authority Lookup SRV Enregistrements de localisation de service Lookup CAA Quelles CA peuvent émettre des certificats DNS inversé (PTR) Adresse IP vers nom d'hôte Vérification DNSSEC Le domaine est-il signé et validé ? Diagnostic DNS Un bilan complet de délégation et de DNSDélivrabilité des e-mails
Vérification SPF Validez votre enregistrement Sender Policy Framework Vérification DMARC Inspectez et évaluez votre politique DMARC Vérification DKIM Trouvez et validez votre clé publique DKIM Vérification de liste noire Vérifiez une IP face aux listes de blocage e-mail (DNSBL) Test SMTP Connectez-vous à un serveur de messagerie et vérifiez STARTTLS Vérification MTA-STS Politique TLS imposée pour le courrier entrant Vérification BIMI Enregistrement de logo de marque pour l'e-mail Vérification TLS-RPT Politique de rapport TLS SMTPRéseau et web
Vérification de certificat SSL Inspectez le certificat TLS d'un site et son expiration Vérification des en-têtes HTTP Inspectez les en-têtes de réponse, redirections et sécurité Ping (TCP) Accessibilité et latence via TCP Vérification de ports Quels ports courants sont ouvertsDomaine
Lookup WHOIS Données d'enregistrement pour domaines, IP et ASNUn diagnostic DNS inspecte la façon dont un domaine est délégué et configuré de bout en bout, et pas seulement un seul type d'enregistrement. Il demande aux serveurs du parent (le TLD) ce qu'ils publient pour votre domaine, puis interroge directement vos propres serveurs de noms, et compare les deux. Les écarts entre le parent et vos serveurs — glue manquant, listes de NS qui divergent, séries SOA désynchronisées, serveurs lame ou à récursion ouverte — sont précisément les problèmes qui rendent le DNS lent, intermittent ou silencieusement cassé. IPeek effectue chaque contrôle et vous explique, en langage clair, pourquoi chacun compte et comment le corriger.
Chaque requête vers votre domaine commence à la zone parente — le registre du TLD (par exemple .fr ou .com) — qui détient les enregistrements NS pointant les résolveurs vers vos serveurs de noms. Si ces serveurs se trouvent à l'intérieur de votre propre domaine, le parent doit aussi publier leurs adresses IP sous forme de « glue », faute de quoi les résolveurs se retrouvent dans une boucle de l'œuf et de la poule. Une délégation saine voit le parent et vos propres serveurs s'accorder sur le même ensemble de NS, avec le glue présent là où il le faut. Quand ils divergent, certains résolveurs suivent des informations obsolètes et vos changements semblent fonctionner pour certains utilisateurs mais pas pour d'autres.
La RFC 2182 recommande plusieurs serveurs de noms sur des réseaux différents afin qu'une seule panne ne mette jamais votre domaine hors ligne. Chacun doit répondre de façon autoritative pour votre zone — un serveur « lame » qui ne le fait pas est un trou de fiabilité silencieux. Vos serveurs autoritatifs devraient aussi refuser la récursion aux inconnus : un serveur récursif ouvert peut être détourné pour l'empoisonnement de cache et l'amplification DDoS. IPeek interroge chacun de vos serveurs de noms directement pour confirmer qu'ils répondent, qu'ils le font de façon autoritative, qu'ils s'accordent entre eux, qu'ils prennent en charge le TCP et qu'ils gardent la récursion fermée.
L'enregistrement SOA porte le numéro de série de votre zone et ses valeurs de temporisation ; chaque serveur de noms doit rapporter le même numéro de série, sinon votre zone est désynchronisée et les changements se propagent de façon inégale. Le numéro de série devrait suivre la convention YYYYMMDDnn, et les minuteurs refresh/retry/expire/minimum devraient se situer dans les plages recommandées par les RFC. Côté courrier, les enregistrements MX doivent être des noms d'hôte (jamais des IP nues ni des CNAME) qui résolvent vers des adresses publiques. Enfin, le domaine racine (votre domaine nu) devrait publier une adresse mais pas un CNAME, ce que la RFC 1912 interdit aux côtés d'autres enregistrements.
Une recherche DNS vous montre les enregistrements tels qu'ils apparaissent à travers un résolveur récursif. Un diagnostic va plus loin : il interroge les serveurs du TLD parent et chacun de vos propres serveurs de noms directement, puis les compare. Cela lui permet de détecter des problèmes de délégation qu'une simple recherche masque — glue manquant, divergences de NS entre parent et enfant, serveurs lame ou en désaccord, et séries SOA désynchronisées.
Le glue est l'adresse IP d'un serveur de noms, publiée par la zone parente aux côtés de l'enregistrement NS. Il est requis lorsque vos serveurs de noms se trouvent dans le même domaine qu'ils servent (par exemple ns1.exemple.com servant exemple.com), car les résolveurs devraient sinon résoudre le serveur de noms avant de pouvoir résoudre quoi que ce soit. Un glue manquant dans ce cas casse la résolution ; si vos serveurs de noms sont sur un autre domaine, le glue est facultatif et ne fait qu'économiser une recherche supplémentaire.
Les serveurs de noms autoritatifs ne devraient répondre que pour les zones qu'ils hébergent. Un serveur de noms qui effectue de la récursion pour n'importe qui (un « résolveur ouvert ») peut être détourné pour des attaques DDoS par amplification DNS et est plus exposé à l'empoisonnement de cache. Si le diagnostic signale une récursion ouverte, désactivez la récursion sur le serveur autoritatif ou séparez vos rôles autoritatif et récursif sur des hôtes différents.
La série SOA est un numéro de version de votre zone. Quand vos serveurs de noms rapportent des séries différentes, au moins l'un d'eux sert des données obsolètes — généralement un secondaire qui n'a pas réussi à transférer la dernière zone depuis le primaire. Le résultat, ce sont des réponses incohérentes selon le serveur que touche un résolveur. Vérifiez les transferts de zone (AXFR/IXFR), la configuration NOTIFY du primaire et le minuteur refresh du SOA.
Aucun n'est une erreur, mais les deux sont des points uniques de défaillance. Avec un seul MX, le courrier peut être perdu si ce serveur reste hors ligne assez longtemps ; un MX de secours ajoute de la résilience. Deux serveurs de noms est acceptable selon la RFC 2182, mais trois ou plus sur des réseaux différents est plus sûr. Le diagnostic signale ces points comme des avertissements, pas comme des échecs — ils méritent d'être améliorés, ce ne sont pas des urgences.