DNS : résoudre l’erreur fatale “la liste des serveurs récupérée ne correspond pas à celle donnée”

Lorsqu’un nom de domaine utilise ses propres serveurs DNS, un test Zonemaster peut parfois retourner une erreur assez inquiétante :

---- fatal ----
cohérence avec la liste des serveurs de noms donnée
f: La liste des serveurs récupérée ne correspond pas à celle donnée

Le message peut varier selon l’outil utilisé, mais l’idée reste la même : la liste des serveurs DNS déclarée au niveau du registre ne correspond pas à la liste publiée dans la zone DNS elle-même.

En clair, le parent et l’enfant ne racontent pas la même histoire. Et en DNS, quand deux autorités donnent deux versions différentes, les résolveurs n’applaudissent pas. Ils hésitent, échouent, mettent en cache des réponses incohérentes, ou servent une ancienne configuration.

Comprendre l’erreur : parent NS et child NS ne correspondent pas

Pour un domaine, il existe deux endroits importants où les serveurs DNS peuvent être déclarés.

• Chez le registre ou registrar : c’est la délégation parent.
• Dans la zone DNS du domaine : ce sont les enregistrements NS de la zone enfant.

Par exemple, si le registre .net indique que example.net utilise ns1.example.net et ns2.example.net, alors la zone DNS de example.net doit aussi publier une liste cohérente de serveurs NS.

Si le parent annonce un serveur DNS qui n’existe pas dans la zone enfant, ou si la zone enfant annonce un serveur absent de la délégation parent, les outils de diagnostic lèvent une erreur de cohérence.

Zonemaster teste précisément ce type de cohérence. Sa documentation indique notamment que le serveur maître déclaré dans le SOA doit être autoritatif, que le serial SOA doit être cohérent entre serveurs, et que le serveur SOA MNAME doit faire partie du jeu d’enregistrements NS de la zone enfant.

Exemple d’erreur avec ns.kimsufi.com

Voici un exemple typique d’erreur rencontrée lors d’un test de zone :

---- fatal ----
cohérence avec la liste des serveurs de noms donnée
f: La liste des serveurs récupérée ne correspond pas à celle donnée :

ns.kimsufi.com/2001:41D0:3:1C7::1

Dans ce cas, le test signale que ns.kimsufi.com ne correspond pas à la liste attendue des serveurs de noms. Cela peut venir d’une délégation mal configurée chez le registrar, d’une zone BIND incomplète, d’un ancien serveur DNS encore déclaré, ou d’un serveur secondaire qui n’a pas récupéré la dernière version de la zone.

La correction ne consiste donc pas toujours à modifier une seule ligne. Il faut d’abord identifier où se trouve la divergence : côté registrar, côté zone DNS, côté serveur secondaire, ou côté glue record.

Étape 1 : vérifier les serveurs DNS déclarés par le parent

Commencez par interroger la délégation parent. Pour un domaine en .net, on peut demander aux serveurs du TLD .net quels serveurs DNS sont officiellement délégués.

Exemple avec skyminds.net :

dig +short NS skyminds.net @a.gtld-servers.netCode language: CSS (css)

Vous pouvez aussi demander une trace complète :

dig +trace NS skyminds.netCode language: CSS (css)

Notez précisément la liste retournée. C’est la liste vue par le parent, donc celle que les résolveurs découvriront lorsqu’ils suivront la délégation DNS.

Étape 2 : vérifier les NS publiés dans la zone enfant

Interrogez maintenant un serveur autoritatif du domaine, donc le serveur qui héberge réellement la zone DNS.

Par exemple :

dig +short NS skyminds.net @ns1.example.netCode language: CSS (css)

Remplacez évidemment ns1.example.net par le nom réel de votre serveur DNS autoritatif.

Vous pouvez aussi demander le SOA :

dig +short SOA skyminds.net @ns1.example.netCode language: CSS (css)

Cette commande permet de vérifier le serveur maître déclaré dans le SOA, ainsi que le numéro de série de la zone.

Étape 3 : comparer les réponses de tous les serveurs autoritatifs

Une zone DNS doit répondre de façon cohérente sur tous ses serveurs autoritatifs. Si ns1 sert une version récente, mais ns2 sert encore une ancienne version, les tests DNS peuvent échouer.

Vérifiez le SOA sur chaque serveur :

for ns in ns1.example.net ns2.example.net ns3.example.net; do
    echo "== $ns =="
    dig +short SOA skyminds.net @"$ns"
    dig +short NS skyminds.net @"$ns"
    echo
doneCode language: PHP (php)

Les numéros de série SOA doivent être cohérents. Si un serveur secondaire affiche un serial plus ancien, il n’a probablement pas récupéré la dernière zone.

Dans ce cas, il faut regarder les transferts de zone, les ACL, les logs BIND, les clés TSIG éventuelles, les pare-feu et l’accessibilité du port 53 en UDP et TCP.

Étape 4 : corriger les enregistrements NS dans la zone BIND

Si vous gérez vous-même la zone avec BIND9, ouvrez le fichier de zone concerné.

Un bloc SOA et NS propre ressemble par exemple à ceci :

$TTL 3600
@   IN  SOA ns1.example.net. hostmaster.example.net. (
        2026050701 ; serial
        3600       ; refresh
        900        ; retry
        1209600    ; expire
        3600       ; negative cache TTL
)

@   IN  NS  ns1.example.net.
@   IN  NS  ns2.example.net.

ns1 IN  A     203.0.113.10
ns2 IN  A     203.0.113.11
ns1 IN  AAAA  2001:db8::10
ns2 IN  AAAA  2001:db8::11Code language: PHP (php)

Points importants :

• Chaque nom de serveur DNS doit se terminer par un point final s’il est écrit en FQDN.
• La liste des NS dans la zone doit correspondre à celle déclarée chez le registrar.
• Le serveur indiqué dans le champ SOA MNAME doit être un serveur autoritatif réel.
• Les noms de serveurs situés dans le même domaine doivent avoir des enregistrements A et/ou AAAA.
• Le numéro de série SOA doit augmenter à chaque modification de zone.

Étape 5 : incrémenter le numéro de série SOA

Après toute modification de zone, incrémentez le numéro de série du SOA. C’est ce numéro qui permet aux serveurs secondaires de savoir qu’une nouvelle version de la zone existe.

Le format classique recommandé est :

YYYYMMDDnn

Par exemple, pour la première modification du 7 mai 2026 :

2026050701

Pour une deuxième modification le même jour :

2026050702

RFC 1912 recommande ce format YYYYMMDDnn et rappelle que le serial doit être incrémenté à chaque changement de zone.

Étape 6 : tester la configuration BIND avant de recharger

Avant de recharger BIND9, vérifiez la configuration globale :

sudo named-checkconf

Vous pouvez aussi tester le chargement des zones déclarées :

sudo named-checkconf -z

Puis vérifiez explicitement le fichier de zone :

sudo named-checkzone skyminds.net /etc/bind/zones/db.skyminds.net

La documentation BIND indique que named-checkzone retourne un code de sortie 1 si des erreurs sont détectées et 0 si tout va bien. C’est donc un bon garde-fou avant de recharger un serveur DNS en production.

Étape 7 : recharger BIND9 proprement

Sur une distribution moderne avec systemd, utilisez plutôt :

sudo systemctl reload bind9

Selon la distribution, le service peut aussi s’appeler named :

sudo systemctl reload named

Si le rechargement échoue, consultez immédiatement les logs :

sudo journalctl -u bind9 -n 100 --no-pager

ou :

sudo journalctl -u named -n 100 --no-pager

Évitez l’ancien réflexe /etc/init.d/bind9 restart sur les systèmes récents. Un reload suffit généralement après une modification de zone valide, et il évite de redémarrer brutalement le service.

Étape 8 : vérifier les glue records

Si vos serveurs DNS sont dans le même domaine que la zone, par exemple ns1.example.net pour example.net, le parent doit connaître leurs adresses IP. C’est le rôle des glue records.

Sans glue records corrects, un résolveur peut se retrouver dans une impasse : il doit résoudre ns1.example.net pour trouver example.net, mais il doit déjà connaître example.net pour résoudre ns1.example.net. Très DNS comme blague. Pas très drôle en production.

Vérifiez les glue records côté parent :

dig +additional NS skyminds.net @a.gtld-servers.netCode language: CSS (css)

Si les adresses A ou AAAA des serveurs DNS sont absentes ou anciennes, mettez-les à jour chez votre registrar. Ce réglage ne se corrige pas dans le fichier de zone seul : il dépend de la délégation au niveau parent.

Étape 9 : relancer un test Zonemaster

Une fois les corrections faites, relancez un test complet avec Zonemaster.

Vous pouvez aussi vérifier depuis la ligne de commande avec dig :

dig +trace NS skyminds.net
dig +short NS skyminds.net
dig +short SOA skyminds.netCode language: CSS (css)

Si vous venez de modifier la délégation chez le registrar, laissez aussi le temps aux caches DNS de se vider. Le parent, les résolveurs publics et les caches intermédiaires peuvent conserver une ancienne réponse pendant la durée du TTL.

Checklist rapide de correction

Voici la séquence que j’utilise pour corriger ce type d’erreur DNS :

# 1. Voir les NS côté parent.
dig +trace NS example.net

# 2. Voir les NS côté zone enfant.
dig +short NS example.net @ns1.example.net

# 3. Vérifier le SOA.
dig +short SOA example.net @ns1.example.net

# 4. Comparer tous les serveurs autoritatifs.
for ns in ns1.example.net ns2.example.net; do
    echo "== $ns =="
    dig +short SOA example.net @"$ns"
    dig +short NS example.net @"$ns"
done

# 5. Tester BIND.
sudo named-checkconf
sudo named-checkconf -z
sudo named-checkzone example.net /etc/bind/zones/db.example.net

# 6. Recharger BIND.
sudo systemctl reload bind9

# 7. Relancer le test externe.
dig +trace NS example.netCode language: PHP (php)

Causes fréquentes de l’erreur

• Un ancien serveur DNS reste déclaré chez le registrar.
• Un nouveau serveur DNS a été ajouté dans la zone, mais pas chez le registrar.
• La zone BIND contient une liste NS différente de la délégation parent.
• Le numéro de série SOA n’a pas été incrémenté après modification.
• Un serveur secondaire n’a pas récupéré la dernière zone.
• Les transferts de zone sont bloqués par une ACL, un pare-feu ou une clé TSIG incorrecte.
• Un glue record A ou AAAA est absent ou obsolète.
• Un nom de serveur DNS a été écrit sans point final dans le fichier de zone.
• Le serveur indiqué dans le SOA MNAME n’est pas autoritatif pour la zone.

Conclusion

L’erreur DNS “la liste des serveurs récupérée ne correspond pas à celle donnée” indique presque toujours une incohérence entre la délégation parent et la zone enfant.

La correction passe donc par une vérification méthodique : comparer les serveurs NS côté parent et côté zone, corriger le fichier de zone ou la délégation registrar, incrémenter le serial SOA, vérifier BIND, recharger le service, puis relancer un test Zonemaster.

La commande magique n’existe pas, mais la bonne séquence est simple :

dig +trace NS example.net
dig +short NS example.net @ns1.example.net
dig +short SOA example.net @ns1.example.net
sudo named-checkzone example.net /etc/bind/zones/db.example.net
sudo systemctl reload bind9Code language: CSS (css)

Une fois les deux listes alignées et le serial SOA correctement incrémenté, le test de zone devrait redevenir propre. Et votre DNS arrêtera enfin de raconter deux versions différentes de la même histoire.

Sources

• Zonemaster : lancer un test DNS
• Documentation Zonemaster : tests de cohérence de zone
• RFC 1912 : bonnes pratiques DNS et format du serial SOA
• Documentation BIND9 : named-checkzone et named-checkconf
• Documentation BIND9 : opérations des serveurs de noms

Report a typo