Outils populaires

Thème

Test de santé DNS

Validation de domaine côté DNS : délégation, chaque serveur de noms interrogé en direct, SOA, DNSSEC et messagerie. 40 vérifications, chacune avec sa correction.

Niveaux de Zonemaster et des RFC · chaque serveur de noms interrogé en TCP · Google Public DNS · RDAP

Va d'un serveur racine au registre .nl, puis interroge directement chaque serveur de noms de sidn.nl · 40 vérifications · environ 3 sregistre .nl → chaque serveur de noms · 40 vérifications

Essayez
ExempleRelevé le 23 oct. 2026 · depuis notre serveur.nl3 NSDNSSEC signé

sidn.nl réussit toutes les vérifications qui ont tourné, DNSSEC compris

enregistré chez SIDN·2,9 s

40 réussies

A+ : rien au-dessus d'info. Chaque serveur de noms a répondu en faisant autorité et en accord avec les autres, les temporisations sont dans la plage de Zonemaster, et Google Public DNS valide la chaîne DNSSEC depuis la racine.

Problèmes d'abord

Interrogés en TCP depuis notre serveur, à la périphérie du réseau de Cloudflare : la racine, le registre .nl et chaque serveur de noms directement ; Google Public DNS et Cloudflare pour les enregistrements de messagerie et la validation. Nous ne gardons aucun journal de ce que vous vérifiez.

Que vérifie un test de santé DNS ?

Un test de santé DNS suit un domaine comme un résolveur le trouve et teste chaque étape : la délégation du registre, chaque serveur de noms interrogé directement, l'accord entre ces serveurs, l'enregistrement SOA, DNSSEC et les enregistrements de messagerie. Celui-ci lance 40 vérifications en sept groupes et note chacune au niveau fixé par son autorité.

La plupart des outils interrogent un résolveur et notent ce qui revient. Cela cache les serveurs qui se trouvent derrière : un résolveur répond depuis n'importe quel serveur de noms qui fonctionne, si bien qu'un serveur en panne reste invisible jusqu'à ce que les autres tombent aussi. Ici, chaque serveur de noms est interrogé en TCP sans récursivité, la copie des enregistrements NS du registre est comparée à celle de la zone, et la chaîne DNSSEC est vérifiée du DS au registre jusqu'aux signatures de la zone.

Utilisez-le comme un audit DNS après chaque changement : il vérifie les enregistrements DNS dont dépend un domaine, pas seulement si son site se charge (pour cela, le Vérificateur de site en panne examine le site lui-même). Copier le rapport transforme le résultat en rapport DNS en texte brut, à coller dans un ticket.

Racineh.root-servers.net
.comRegistre .comh.gtld-servers.net
8 serveurs de nomsRoute 53 + NS1
La zonegithub.com
  • DNSSEC7 vérificationsla chaîne de confiance depuis la racine : github.com : s'arrête à .com (pas de DS)
  • Parent et délégation6 vérificationsle renvoi du registre : 8 noms · 295 octets · pas de glue nécessaire
  • Serveurs de noms14 vérificationschaque serveur interrogé directement : 8 sur 8 font autorité · en TCP · EDNS · pas de récursivité
  • Cohérence3 vérificationsles serveurs sont-ils d'accord : 2 numéros de série SOA, un par hébergeur DNS · les mêmes MX et SPF
  • SOA4 vérificationstemporisations sous les seuils de Zonemaster : remarques
  • CAA1 vérification7 enregistrements · 4 AC autorisées
  • DNS de messagerie5 vérificationsMX chez Microsoft 365 · SPF 10 sur 10 requêtes · DMARC quarantine
Où regarde chaque groupe de vérifications, sur le vrai chemin de github.com (23 octobre 2026) : de la racine au registre .com, puis aux serveurs de noms de la zone chez Route 53 et NS1.
Vérifier le DNS de github.com : note A, 40 vérifications en sept groupes et le chemin de la racine à 8 serveurs de nomsVérifier le DNS de github.com : note A, 40 vérifications en sept groupes et le chemin de la racine à 8 serveurs de nomsLa noteTirée des seuls niveaux : aucun critique, aucune erreur, deux avertissements donnent un A. L'anneau montre le score, 90 sur 100.40 vérifications, une case chacuneGroupées comme la page les liste. Les cases ambre et bleues sont les avertissements et les remarques ; les cases hachurées n'ont pas pu tourner.Les problèmes d'abordLes groupes qui ont quelque chose à corriger s'ouvrent en haut, chaque ligne avec son autorité et sa correction.Le cheminUn serveur racine, le registre .com géré par Verisign, puis chaque serveur de noms interrogé directement : sa réponse, son numéro de série et EDNS.Chaîne de confianceLe rail DNSSEC à côté du chemin : vert là où elle tient, en pointillés là où elle s'arrête, rouge là où elle casse.
Un test de santé DNS de github.com. Sélectionnez un numéro pour voir ce que montre chaque partie.

Comment la note est-elle calculée ?

La lettre vient uniquement des niveaux de ce qui a échoué, jamais d'un barème de points : le moindre problème critique donne un F, deux erreurs ou plus un D, une erreur ou cinq avertissements ou plus un C, trois ou quatre avertissements un B, un ou deux avertissements (ou seulement des remarques) un A, et rien au-dessus d'info un A+.

Les niveaux sont ceux de l'autorité citée : le profil par défaut de Zonemaster quand il définit le test, le MUST ou SHOULD de la RFC sinon. Le nombre sur 100 ne fait que classer les domaines au sein d'une même lettre (100 − 30 par critique, 12 par erreur, 4 par avertissement, 1 par remarque). Les vérifications que notre serveur ne peut pas lancer ne sont jamais retenues contre un domaine ; quand un quart ou plus ne peut pas tourner, la note l'indique : partielle.

  1. A+100rien au-dessus d'infoINFO « n'indique certainement pas un problème »sidn.nl100
  2. A90–991 ou 2 avertissements, ou seulement des remarquesNOTICE « devrait être connu de l'administrateur de la zone, sans être forcément un problème »github.com90example.com95bücher.de90
  3. B75–893 ou 4 avertissementsWARNING « posera problème dans certaines circonstances, mais un utilisateur ordinaire a peu de chances de le remarquer »cloudflare.com87google.com83
  4. C60–741 erreur, ou 5 avertissements ou plusERROR « très susceptible (voire certain) de nuire au fonctionnement de la zone »aucun dans l'échantillon
  5. D45–592 erreurs ou plusdnssec-failed.org55
  6. F0–44un problème critique, quel qu'il soitCRITICAL « peut raisonnablement être considérée comme inexistante »un domaine en .com44

score = 100 − 30 × critique − 12 × erreur − 4 × avertissement − 1 × remarque, maintenu dans la plage de la lettre

partielleun quart des vérifications ou plus n'a pas pu tourner depuis notre serveur, et la note l'indique

L'échelle, avec les domaines vérifiés le 23 octobre 2026 placés selon leur note relevée. Niveaux cités d'après les définitions de gravité de Zonemaster.

Vérifier les serveurs de noms : les NS du parent et de la zone concordent-ils ?

Ils le devraient : le registre (le parent) et la zone (l'enfant) publient chacun un ensemble NS, et la RFC 1912 §2.8 demande de les garder identiques. Quand le registre pointe vers un serveur qui ne répond pas pour la zone, c'est une délégation lame : le serveur répond REFUSED, ou répond sans le flag de réponse faisant autorité (AA).

Les résolveurs passent au serveur suivant : un seul serveur lame coûte donc du temps ; quand tous les serveurs listés sont lames, le domaine cesse de se résoudre. Zonemaster classe les noms que seul le registre liste comme une erreur (EXTRA_NAME_PARENT), les noms que seule la zone liste comme une remarque, et l'absence de tout serveur qui fonctionne comme critique.

github.comconcordance

Registre .com
  • ns-520.awsdns-01.net
  • ns-421.awsdns-52.com
  • ns-1707.awsdns-21.co.uk
  • ns-1283.awsdns-32.org
  • dns1–4.p08.nsone.net
La zone
  • les mêmes 8

8 sur 8 répondent avec AA

un domaine en .netdivergence

Registre .net
  • ns1.domaindirect.com
  • ns2.domaindirect.comREFUSED
  • ns3.domaindirect.com
La zone
  • ns1.hover.com
  • ns2.hover.com

aucun nom en commun · ns2.domaindirect.com : REFUSED · 2 erreurs

un domaine en .comdélégation lame

Registre .com
  • ns63.domaincontrol.comREFUSED
  • ns64.domaincontrol.comREFUSED
La zone
  • personne ne répondSERVFAIL

chaque serveur : REFUSED · les résolveurs répondent SERVFAIL · CRITICAL

Trois délégations relevées le 23 octobre 2026. Les noms des deux délégations défaillantes ne sont pas communiqués ; leurs serveurs de noms et leurs réponses sont réels.

De combien de serveurs de noms un domaine a-t-il besoin ?

Au moins deux, et trois sont recommandés. La RFC 1034 §4.1 exige que chaque zone soit disponible sur au moins deux serveurs, et la RFC 2182 §5 en recommande trois pour la plupart des zones au niveau d'une organisation. Un seul serveur de noms est une erreur pour Zonemaster ; deux passent avec une simple info.

Leur emplacement compte plus que leur nombre : la vérification des serveurs de noms examine donc aussi leurs réseaux. Des serveurs sur un même réseau tombent ensemble : Zonemaster avertit quand toutes les adresses se trouvent dans un même système autonome (IPV4_ONE_ASN), même pour des hébergeurs anycast comme Google, Cloudflare ou Akamai, dont chaque adresse répond depuis de nombreux sites. L'anycast répartit la charge ; cela reste un seul opérateur.

  • google.com4 NS · 1 réseauun seul réseau
  • github.com8 NS · 2 réseauxrépartis
  • sidn.nl3 NS · 2 réseauxrépartis
  • cloudflare.com5 NS · 1 réseauun seul réseau
  • nasa.gov6 NS · 1 réseauun seul réseau
  • example.com2 NS · 1 réseauun seul réseau

AS1921 ipcomAS13335 CloudflareAS15169 GoogleAS16509 AmazonAS21342 AkamaiAS48283 SIDNAS62597 NS1

« Il est recommandé de fournir trois serveurs pour la plupart des zones au niveau d'une organisation, dont au moins un doit être bien éloigné des autres. » RFC 2182 §5
Un point par serveur de noms, coloré selon le réseau (AS) qui annonce son adresse, d'après les relevés du 23 octobre 2026. Un seul réseau, c'est l'avertissement IPV4_ONE_ASN de Zonemaster, anycast ou non.

Les valeurs de votre enregistrement SOA sont-elles correctes ?

Si un grand hébergeur DNS les a fixées, elles sont presque certainement bonnes, même quand un outil les signale. Refresh, Retry et Expire ne pilotent que les serveurs secondaires qui copient la zone par transfert de zone. Minimum est le TTL du cache négatif (RFC 2308) : la durée pendant laquelle les résolveurs retiennent qu'un nom n'existe pas.

Le RIPE-203 (1999) recommande Refresh 86400, Retry 7200, Expire 3600000 et Minimum 172800, ce dernier datant d'avant la RFC 2308. Zonemaster fixe des seuils plus bas : Refresh 14400 et Retry 3600 (remarques), Expire 604800 (le seul avertissement), Minimum entre 300 et 86400 (une remarque). Les valeurs par défaut de Cloudflare, Route 53 et Azure sont sous les seuils de Refresh et de Retry ; l'Expire de 3 jours de Google Cloud DNS est le seul avertissement parmi les grands hébergeurs.

RefreshZonemaster ≥ 4 h · ◆ 1 jRetryZonemaster ≥ 1 h · ◆ 2 hExpireZonemaster ≥ 7 j · ◆ 41,7 jMinimumZonemaster 5 min – 1 j · ◆ 2 j
Cloudflare2,8 h40 min7 j30 min2 remarques
Amazon Route 532 h15 min14 j1 j2 remarques
Google Cloud DNS6 h1 h3 j5 min1 avertissement
Azure DNS1 h5 min28 j5 min2 remarques
GoDaddy8 h2 h7 j1 hréussi
Namecheap BasicDNS12 h1 h7 j1 hréussi
google.com (ses propres serveurs)15 min15 min30 min1 min1 avertissement · 3 remarques

sous le seuil de ZonemasterréussiremarqueavertissementRIPE-203 (1999)

Les valeurs de chaque hébergeur telles que ses zones les servaient via dig le 23 octobre 2026 : Cloudflare, Route 53 et Google Cloud DNS correspondent à leur documentation ; la page d'aide de GoDaddy indique un Minimum de 600, ses zones d'exemple servent 3600 ; nous n'avons trouvé aucune valeur par défaut publiée pour Azure DNS ni pour Namecheap BasicDNS, leurs valeurs sont donc celles de leurs zones. Échelle logarithmique de 1 minute à 6 semaines.

Test DNSSEC : DS, DNSKEY et signatures

Un test DNSSEC parcourt la chaîne de confiance : l'enregistrement DS au registre doit être le condensat d'une clé (DNSKEY) de la zone, cette clé doit signer l'ensemble de clés de la zone, et chaque signature (RRSIG) doit se vérifier et être dans sa fenêtre de validité. Ce test calcule lui-même le condensat et vérifie chaque signature, puis demande à Google Public DNS si la validation réussit.

Qu'un maillon casse, et les résolveurs qui valident répondent SERVFAIL : le domaine disparaît pour tous ceux qui passent par eux. dnssec-failed.org, une zone de test volontairement maintenue cassée, montre deux ruptures à la fois. Les algorithmes sont jugés d'après le registre de l'IANA (RFC 9904) : 8, 13 et 15 sont recommandés, tandis que 5 et 7, qui signent avec SHA-1, ne doivent plus être utilisés (RFC 9905) et sont classés en erreur par Zonemaster.

cloudflare.comsécurisée

  1. DS 2371 dans .comalgorithme 13 · SHA-256 · 329968…26F2B9
  2. le condensat correspond à la clé 2371
  3. DNSKEY 2371 · KSKflags 257 · ECDSA P-256 (13)
  4. signe l'ensemble de clés · reste 50,8 jours sur 61 jours
  5. DNSKEY 34505 · ZSKflags 256 · ECDSA P-256 (13)
  6. signe les enregistrements · SOA : reste 1 jour sur 2 jours
  7. Google Public DNSflag AD positionné : sécurisée

dnssec-failed.orginvalide

  1. DS 42069 dans .orgalgorithme 13 · SHA-256
  2. pas de clé 42069 dans la zone
  3. DNSKEY 50719 · KSKla vraie clé de signature de clés (KSK) de la zone
  4. sa signature sur l'ensemble de clés a expiré il y a 112 jours
  5. DNSKEY 32784 · ZSKsigne le SOA : valide, reste 5,7 jours sur 7 jours
  6. rien de fiable n'y mène
  7. Google Public DNSSERVFAIL ; répond dès que CD est positionné : invalide (bogus)

Algorithmes de signature (registre de l'IANA, RFC 9904)

  • RECOMMENDED8 RSASHA256 · 13 ECDSAP256SHA256 · 15 ED25519à utiliser
  • MAY14 ECDSAP384SHA384 · 16 ED448autorisés
  • NOT RECOMMENDED10 RSASHA512Zonemaster WARNING
  • MUST NOT5 RSASHA1 · 7 RSASHA1-NSEC3-SHA1 · 1 · 3 · 6 · 12RFC 9905 · Zonemaster ERROR

les deux chaînes ci-dessus signent avec 13

Deux chaînes relevées le 23 octobre 2026 : celle de cloudflare.com tient ; celle de dnssec-failed.org casse au DS, puis à nouveau sur une signature expirée.

DNS de messagerie : MX, SPF et DMARC

Les vérifications de messagerie lisent ce que lisent les serveurs de réception : les enregistrements MX (ou un MX nul qui déclare que le domaine ne reçoit pas de courrier, RFC 7505), un seul enregistrement SPF dans la limite de 10 requêtes DNS de la RFC 7208, et une politique DMARC (RFC 9989, qui a remplacé la RFC 7489 en mai 2026).

Le SPF est évalué, pas seulement trouvé : chaque include est suivi et compté. L'enregistrement de github.com demande exactement 10 requêtes plus une requête vide : valide, sans aucune marge. Un domaine qui n'envoie jamais de courrier devrait le dire : example.com publie l'ensemble des domaines parqués, un MX nul, v=spf1 -all et p=reject. Pour le détail, le Vérificateur SPF et le Vérificateur DMARC vont plus loin.

github.comenvoie et reçoit

MX
0 github-com.mail.protection.outlook.comMicrosoft 365 · 1 hôte · pas un alias
SPF
v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.227.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all10 sur 10 requêtes DNS1 sur 2 requêtes vides · valide, sans aucune marge
DMARC
p=quarantine; sp=rejectrapports vers 1 adresse · sous-domaines : reject

example.comdomaine parqué

MX
0 .MX nul : ne reçoit pas de courrier (RFC 7505)
SPF
v=spf1 -alln'envoie pas de courrier · 0 requête
DMARC
p=reject; sp=rejecttout ce qui se présente comme example.com est refusé
github.com et example.com, tels que publiés le 23 octobre 2026.

Vérifier le DNS en ligne de commande (dig)

Quatre étapes avec dig et delv refont l'essentiel de ce test : suivre la délégation depuis la racine, interroger un serveur de noms directement sans récursivité, comparer le DS du registre aux clés de la zone, et laisser un résolveur qui valide juger la chaîne.

Ajoutez +tcp pour voir ce que voit notre serveur ; omettez-le pour tester l'UDP, ce qu'un outil web sur le réseau de Cloudflare ne peut pas faire. Dans l'en-tête de la réponse, aa marque une réponse faisant autorité ; REFUSED, ou l'absence du flag aa chez un serveur listé par le registre, signale une délégation lame.

Terminal · dig 9.20

$ dig +trace +tcp github.com NS
;; (abrégé)
com.          172800 IN NS a.gtld-servers.net.   ;; depuis h.root-servers.net 1
github.com.   172800 IN NS ns-520.awsdns-01.net. ;; depuis h.gtld-servers.net : 8 NS 2

$ dig @ns-421.awsdns-52.com github.com SOA +norec +tcp
;; flags: qr aa; QUERY: 1, ANSWER: 1 3
github.com.   900 IN SOA ns-1707.awsdns-21.co.uk. awsdns-hostmaster.amazon.com.
              1 7200 900 1209600 86400 4

$ dig @a.gtld-servers.net github.com DS +norec
;; status: NOERROR, ANSWER: 0 ;; pas de DS : non signé 5

$ delv @8.8.8.8 cloudflare.com SOA
; fully validated 6
cloudflare.com. 300 IN SOA ns3.cloudflare.com. dns.cloudflare.com.
                2417999975 10000 2400 604800 300
  1. La racine renvoie .com vers ses 13 serveurs
  2. L'ensemble NS du registre pour github.com, gardé 2 jours
  3. aa : une réponse faisant autorité, pas un cache
  4. SOA : numéro de série 1, puis Refresh, Retry, Expire, Minimum
  5. Pas de DS dans .com : rien à vérifier pour DNSSEC
  6. delv a validé la chaîne depuis la racine
Réponses réelles pour github.com et cloudflare.com (23 octobre 2026), abrégées. Les repères numérotés renvoient aux notes.

Pourquoi les outils de vérification DNS ne sont-ils pas d'accord ?

Parce qu'ils notent d'après des chiffres différents. Les outils classiques signalent les valeurs par défaut des fournisseurs : intoDNS qualifie de « NOT OK » l'Expire de 1800 secondes de google.com et met en erreur les deux numéros de série de github.com, pourtant normaux avec deux hébergeurs DNS. Zonemaster classe ces numéros de série en avertissement et reconnaît un MX nul ; notre propre première version se trompait sur les deux.

Et ils voient le réseau depuis des endroits différents. Zonemaster (l'AFNIC et la fondation suédoise de l'Internet) interroge en UDP et en TCP, en IPv4 et en IPv6. Ce test tourne à la périphérie du réseau de Cloudflare : il n'interroge qu'en TCP, ne se connecte pas en IPv6 et ne peut pas joindre les propres adresses de Cloudflare, si bien que ces serveurs sont lus via 1.1.1.1 et que leurs vérifications sont marquées non testées, jamais en échec. En alternative à intoDNS, il montre l'autorité derrière chaque niveau au lieu d'un simple OK ou NOT OK.

CasintoDNSZonemasterDNS Robot v1Ce test
github.comdeux numéros de série SOA (deux hébergeurs DNS)erreur« Looks like your nameservers do not agree on the SOA serial. »avertissementMULTIPLE_SOA_SERIALSéchec« Serial mismatch detected: 1656468023 vs 1. »avertissementexpliqué : un numéro de série par hébergeur DNS
google.comExpire du SOA : 1 800 spas ok« Your SOA EXPIRE number is: 1800. That is NOT OK »avertissementEXPIRE_MINIMUM_VALUE_LOWERéchec« too low (min recommended: 14 days) »avertissementavec ce sur quoi Expire agit
example.comMX nul (0 .)erreur« 0 No A Record (no glue either) »infoZ09_VALID_NULL_MXréussi« Found 1 MX record(s) »réussiMX nul reconnu
cloudflare.comRetry du SOA : 2 400 s—non citéremarqueRETRY_MINIMUM_VALUE_LOWERéchec« too high (max recommended: 15min) »remarquela valeur par défaut de Cloudflare
cloudflare.comsigné avec DNSSECnon vérifiépas de test DNSSECréussiDNSSEC02 · 05 · 08 : chaîne vérifiéealerte« DNSSEC does not appear to be enabled for this domain. »réussiDS → KSK → RRSIG vérifiés, Google valide
Les mêmes domaines dans quatre outils. Résultats d'intoDNS et de la v1 cités d'après leurs pages et leurs réponses des 22–23 octobre 2026 ; niveaux de Zonemaster d'après ses spécifications de tests. La dernière colonne est ce test : une alternative à intoDNS qui note chaque constat au niveau fixé par son autorité.

Test de santé DNS : questions fréquentes

Qu'est-ce qu'un test de santé DNS (check DNS) ?

Un test de santé DNS, ou validation DNS, vérifie que le DNS d'un domaine est configuré pour que tout Internet puisse le joindre : la délégation du registre, chaque serveur de noms, l'enregistrement SOA, DNSSEC et les enregistrements de messagerie. Chaque constat est noté selon le tort qu'il peut causer, d'info à critique, et ce validateur DNS montre la règle appliquée (un test Zonemaster ou une section de RFC) et la correction.

La validation de domaine, est-ce la même chose qu'un test de santé DNS ?

Pas toujours. « Validation de domaine » désigne aussi le contrôle qu'une autorité de certification effectue avant d'émettre un certificat DV, et l'enregistrement TXT que Google Workspace ou Microsoft 365 demande pour prouver que vous possédez un domaine. Ce validateur de domaine vérifie le DNS du domaine : délégation, serveurs de noms, SOA, DNSSEC et enregistrements de messagerie. Pour un certificat, voyez la Vérification du certificat SSL.

Qu'est-ce qu'une délégation lame, et comment la corriger ?

Une délégation lame, c'est un serveur de noms listé par le registre qui ne répond pas pour votre domaine : il dit REFUSED ou répond sans faire autorité. Corrigez-la là où se trouve l'écart : ajoutez la zone chez cet hébergeur DNS, ou changez chez votre registrar les serveurs de noms pour ceux qui ont la zone. Si tous les serveurs listés sont lames, le domaine ne se résout plus du tout.

Mon hébergeur DNS utilise l'anycast. Pourquoi un avertissement pour un seul réseau ?

Parce qu'un opérateur est un seul domaine de défaillance. L'anycast permet à chaque adresse de répondre depuis de nombreux sites, ce qui protège contre la panne d'un site, pas contre une panne du fournisseur lui-même ni une erreur dans sa configuration. Zonemaster maintient donc IPV4_ONE_ASN au niveau avertissement, et la RFC 2182 demande des serveurs sur des réseaux variés. Un second hébergeur DNS sur un autre réseau lève l'avertissement.

Mes temporisations SOA sont signalées. Dois-je les changer ?

En général, non. Refresh, Retry et Expire ne comptent que pour les serveurs secondaires qui copient votre zone par transfert de zone ; les grands hébergeurs comme Cloudflare et Route 53 ne les utilisent pas pour votre zone, et leurs valeurs par défaut conviennent. Un Expire de moins d'une semaine est le seul que Zonemaster classe en avertissement. Ne changez les valeurs que si vous gérez vous-même votre primaire et vos secondaires.

Pourquoi certaines vérifications sont-elles marquées « non testée » ?

Parce que notre serveur n'a pas pu les lancer, pas parce que quelque chose ne va pas. Il tourne sur le réseau de Cloudflare, qui ne peut pas ouvrir de connexion vers les propres adresses de Cloudflare, et il n'interroge qu'en TCP, sans se connecter en IPv6. Ces serveurs sont alors lus via le résolveur 1.1.1.1 de Cloudflare. Les vérifications non testées ne baissent jamais la note ; à partir d'un quart, elle devient partielle.

Pourquoi mes serveurs de noms annoncent-ils des numéros de série SOA différents ?

Soit un secondaire n'a pas encore rattrapé une modification, soit votre domaine utilise deux hébergeurs DNS qui ne se transfèrent pas la zone, si bien que chacun garde son propre numéro de série. Le second cas est normal : les serveurs Route 53 de github.com disent 1, ses serveurs NS1 1656468023. Zonemaster signale toute différence comme un avertissement ; nous expliquons de quel cas il s'agit.

Est-ce un test DNSSEC, et l'absence de DNSSEC baisse-t-elle la note ?

Oui : il compare le DS au registre aux clés de la zone et vérifie chaque signature, puis interroge Google Public DNS. Une zone non signée vaut un avertissement Zonemaster (DS07_NOT_SIGNED) : la note reste donc au mieux à A. Une chaîne cassée est bien pire que pas de chaîne du tout : les résolveurs qui valident refusent le domaine, une erreur qui fait tomber la note à C ou moins.

À quelle fréquence faut-il vérifier le DNS d'un domaine ?

Après chaque changement de serveurs de noms, de DNSSEC ou d'enregistrements de messagerie, et avant et après un passage chez un nouvel hébergeur DNS ou un nouveau registrar. Sinon, une fois par mois suffit pour repérer une signature qui expire, un serveur de noms qui ne répond plus ou un changement au registre que vous n'avez pas fait. Chaque résultat a son propre lien : vous pouvez comparer les exécutions.

Conservez-vous les domaines que je vérifie ?

Non. Le test tourne sur notre serveur, à la périphérie du réseau de Cloudflare, et interroge la racine, le registre, vos serveurs de noms, Google Public DNS et le résolveur de Cloudflare ; rien n'est journalisé avec votre adresse. Une exécution terminée est gardée 10 minutes pour qu'une répétition ou un lien partagé réponde aussitôt, puis supprimée. Vos serveurs de noms voient environ 20 questions de notre serveur par exécution.

Il vous manque quelque chose ?Suggérez une fonction ou un nouvel outil

Outils DNS associés