BIND9 : corriger l’erreur “ignoring out-of-zone data” dans un fichier de zone DNS

L’erreur BIND9 ignoring out-of-zone data indique qu’un fichier de zone contient un enregistrement DNS qui n’appartient pas à cette zone. BIND ignore alors la ligne concernée. Pour corriger le problème, identifiez l’entrée fautive, déplacez-la dans la bonne zone ou remplacez-la par un nom appartenant au domaine, puis validez et rechargez la configuration.

Les fichiers de zone DNS paraissent simples. Pourtant, un point final oublié, un mauvais $ORIGIN ou un nom placé dans le mauvais fichier suffit à produire des résultats surprenants.

Voici un message que l’on peut rencontrer lors du chargement d’une zone avec BIND9 :

/etc/bind/db.skyminds.net:15: ignoring out-of-zone data (ks3094174.kimsufi.com)

Cette alerte signifie que BIND a trouvé un enregistrement qu’il ne peut pas publier dans la zone en cours. La ligne est donc ignorée, même si le reste du fichier parvient à se charger.

Que signifie « ignoring out-of-zone data » ?

Un serveur DNS faisant autorité ne peut publier que les données appartenant aux zones qu’il gère.

Par exemple, le fichier de la zone skyminds.net peut contenir des enregistrements pour :

• skyminds.net. ;
• www.skyminds.net. ;
• mail.skyminds.net. ;
• ns1.skyminds.net. ;
• n’importe quel autre nom situé sous skyminds.net..

En revanche, cette même zone ne peut pas définir directement l’adresse de ks3094174.kimsufi.com.. Ce nom appartient à la zone kimsufi.com.

Cette ligne est donc incorrecte dans le fichier de zone de skyminds.net :

ks3094174.kimsufi.com.    IN    A    91.121.201.147Langage du code : CSS (css)

BIND refuse à juste titre de la publier. Sans cette limitation, un administrateur pourrait déclarer arbitrairement des adresses pour des domaines qu’il ne contrôle pas. Ce serait un DNS en roue libre, ce qui finit rarement bien.

Identifier précisément la ligne fautive

Commencez par vérifier la zone concernée avec named-checkzone. Cet outil contrôle la syntaxe et l’intégrité d’un fichier de zone. Il applique les mêmes contrôles que BIND lors du chargement de cette zone.

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

Le résultat peut ressembler à ceci :

/etc/bind/db.skyminds.net:15: ignoring out-of-zone data (ks3094174.kimsufi.com)
zone skyminds.net/IN: loaded serial 2026061801
OK

Le message fournit les trois informations nécessaires au diagnostic :

• le fichier concerné : /etc/bind/db.skyminds.net ;
• le numéro de ligne : 15 ;
• le nom considéré comme hors zone : ks3094174.kimsufi.com.

Pour afficher la zone avec ses numéros de ligne, utilisez par exemple :

sudo nl -ba /etc/bind/db.skyminds.net | sed -n '10,20p'Langage du code : JavaScript (javascript)

Cette commande affiche les lignes 10 à 20. Elle évite de chercher à l’aveugle dans un fichier volumineux.

Vérifier toutes les zones déclarées dans BIND

Pour tester la configuration générale et simuler le chargement de toutes les zones primaires, lancez :

sudo named-checkconf -z

L’option -z demande à named-checkconf de charger les zones primaires trouvées dans la configuration. Le contrôle ne se limite donc plus à la seule syntaxe de named.conf.

Pour vérifier uniquement la syntaxe globale, sans charger les zones, utilisez :

sudo named-checkconf

Corriger un enregistrement A ou AAAA hors zone

Dans notre exemple, la mauvaise ligne tente de publier l’adresse IPv4 d’un nom externe :

ks3094174.kimsufi.com.    IN    A    91.121.201.147Langage du code : CSS (css)

Si l’objectif consiste à faire pointer skyminds.net vers cette machine, il faut déclarer des noms appartenant à la zone locale :

@       IN    A    91.121.201.147
www     IN    A    91.121.201.147
mail    IN    A    91.121.201.147

Dans cette syntaxe :

• @ représente l’origine de la zone, soit skyminds.net. ;
• www devient www.skyminds.net. ;
• mail devient mail.skyminds.net..

L’enregistrement externe doit simplement être supprimé. Il appartient au fichier de zone géré par l’autorité DNS de kimsufi.com, pas à celui de skyminds.net.

Comprendre $ORIGIN, les noms relatifs et le point final

BIND interprète les noms présents dans un fichier de zone selon leur forme.

Les noms relatifs

Un nom sans point final est généralement relatif à l’origine courante de la zone.

www    IN    A    192.0.2.10Langage du code : CSS (css)

Dans la zone example.com, cette ligne représente :

www.example.com.    IN    A    192.0.2.10Langage du code : CSS (css)

Les noms pleinement qualifiés

Un nom terminé par un point est un nom pleinement qualifié, ou FQDN. BIND l’utilise tel quel.

@    IN    MX    10 mx.provider.example.

Ici, la cible exacte est mx.provider.example..

Sans le point final :

@    IN    MX    10 mx.provider.example

BIND peut interpréter la cible comme un nom relatif. Dans une zone skyminds.net, elle devient alors :

mx.provider.example.skyminds.net.Langage du code : CSS (css)

Le résultat reste techniquement dans la zone, mais il ne correspond probablement pas au serveur souhaité. Le point final n’est donc pas décoratif. Il fait partie de la configuration.

La directive $ORIGIN

La directive $ORIGIN modifie l’origine utilisée pour les noms relatifs placés après elle.

$ORIGIN example.com.
www    IN    A    192.0.2.10

$ORIGIN internal.example.com.
app    IN    A    192.0.2.20Langage du code : PHP (php)

Ce fichier définit respectivement :

• www.example.com. ;
• app.internal.example.com..

Une directive $ORIGIN mal placée peut donc déplacer silencieusement les noms suivants dans une autre branche DNS.

Cas fréquent : un serveur MX ou NS externe

Une zone peut parfaitement référencer un serveur externe. Elle ne doit simplement pas tenter de publier les enregistrements qui appartiennent à la zone externe.

Serveur de messagerie externe

Cette déclaration est valide :

@    IN    MX    10 mx.provider.example.

En revanche, cette ligne est hors zone dans le fichier de skyminds.net :

mx.provider.example.    IN    A    203.0.113.10Langage du code : CSS (css)

L’adresse du serveur doit être publiée par la zone provider.example.

Serveur de noms externe

Cette déclaration est également valide :

@    IN    NS    ns1.provider.example.

En revanche, il ne faut pas définir son adresse dans une zone étrangère :

ns1.provider.example.    IN    A    203.0.113.53Langage du code : CSS (css)

La zone locale référence le serveur externe. Elle ne devient pas pour autant responsable de son nom.

Cas particulier des glue records

Les glue records sont parfois confondus avec des données hors zone. Pourtant, leur rôle diffère.

Lorsque le serveur de noms appartient lui-même à la zone qu’il dessert, son adresse doit être disponible pour éviter une dépendance circulaire.

@      IN    NS    ns1.skyminds.net.
ns1    IN    A     192.0.2.53

L’enregistrement A est ici valide, car ns1.skyminds.net. appartient bien à la zone skyminds.net.

Le registrar doit généralement connaître cette adresse comme « hôte », « serveur enfant » ou « glue record ». La terminologie varie selon les interfaces.

En revanche, un serveur comme ns1.provider.example. reste externe. Son adresse ne doit pas être ajoutée au fichier de zone local.

Attention aux zones DNS inverses

L’erreur peut également apparaître dans une zone inverse in-addr.arpa. Le principe reste identique : le nom complet du PTR doit appartenir à la plage gérée par cette zone.

Pour une zone inverse IPv4 correspondant à 192.0.2.0/24, la déclaration peut ressembler à ceci :

zone "2.0.192.in-addr.arpa" {
    type primary;
    file "/etc/bind/db.192.0.2";
};Langage du code : JavaScript (javascript)

Dans son fichier de zone, ce PTR relatif est valide :

10    IN    PTR    web.example.com.Langage du code : CSS (css)

Il représente :

10.2.0.192.in-addr.arpa.    IN    PTR    web.example.com.Langage du code : CSS (css)

En revanche, une entrée comme 10.3.0.192.in-addr.arpa. serait hors de la zone 2.0.192.in-addr.arpa..

Pour vérifier la zone inverse :

sudo named-checkzone 2.0.192.in-addr.arpa /etc/bind/db.192.0.2

Exemple de fichier de zone valide

Voici une zone minimale pour example.com. Les adresses utilisent les plages réservées à la documentation.

$TTL 3600

@    IN    SOA    ns1.example.com. hostmaster.example.com. (
                  2026061801 ; serial
                  3600       ; refresh
                  1800       ; retry
                  1209600    ; expire
                  3600       ; negative cache TTL
)

@       IN    NS      ns1.example.com.
@       IN    NS      ns2.example.com.

@       IN    A       192.0.2.10
@       IN    AAAA    2001:db8::10
www     IN    A       192.0.2.10
www     IN    AAAA    2001:db8::10
mail    IN    A       192.0.2.20

@       IN    MX      10 mail.example.com.

ns1     IN    A       192.0.2.53
ns2     IN    A       192.0.2.54Langage du code : PHP (php)

Tous les propriétaires d’enregistrements situés à gauche appartiennent à example.com. Les noms pleinement qualifiés placés à droite se terminent par un point.

Augmenter le serial SOA après la correction

Après chaque modification d’une zone primaire, augmentez le serial du SOA.

2026061801

Une convention répandue utilise le format AAAAMMJJNN :

• 20260618 correspond à la date ;
• 01 correspond à la première modification de la journée.

La valeur doit surtout être supérieure au serial précédent. Les serveurs secondaires utilisent ce nombre pour déterminer si une nouvelle version doit être transférée.

Valider puis recharger la zone

Ne rechargez pas BIND immédiatement après avoir enregistré le fichier. Validez d’abord la zone seule :

sudo named-checkzone example.com /etc/bind/db.example.com

Un résultat correct se termine par :

zone example.com/IN: loaded serial 2026061801
OK

Vérifiez ensuite la configuration complète :

sudo named-checkconf -z

Rechargez enfin uniquement la zone concernée :

sudo rndc reload example.comLangage du code : CSS (css)

Pour recharger l’ensemble de la configuration et des zones :

sudo rndc reload

Un rechargement évite l’interruption plus brutale provoquée par un redémarrage complet du service.

Si rndc n’est pas disponible ou correctement configuré, utilisez systemd :

sudo systemctl reload bind9

Selon la distribution, l’unité peut s’appeler named :

sudo systemctl reload named

Contrôler les journaux BIND

Sur Debian ou Ubuntu, consultez les derniers messages du service :

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

Pour suivre les nouveaux messages en temps réel :

sudo journalctl -u bind9 -f

Avec une unité nommée named :

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

Après la correction, le message ignoring out-of-zone data ne doit plus apparaître pour la zone rechargée.

Vérifier les réponses avec dig

Interrogez d’abord le serveur local afin de vérifier ce que BIND publie réellement :

dig @127.0.0.1 example.com A
dig @127.0.0.1 www.example.com A
dig @127.0.0.1 example.com MX
dig @127.0.0.1 example.com NSLangage du code : CSS (css)

L’option +short permet d’obtenir une sortie plus concise :

dig @127.0.0.1 example.com A +short
dig @127.0.0.1 example.com NS +shortLangage du code : CSS (css)

Pour vérifier qu’il s’agit bien d’une réponse faisant autorité, utilisez :

dig @127.0.0.1 example.com SOA +norecurseLangage du code : CSS (css)

Le drapeau aa doit apparaître dans l’en-tête de la réponse si le serveur interrogé fait autorité pour la zone.

Pour une zone publique, interrogez ensuite son serveur faisant autorité depuis l’extérieur :

dig @ns1.example.com example.com SOA +norecurse
dig @ns1.example.com example.com A +norecurseLangage du code : CSS (css)

Cas des zones dynamiques et des fichiers .jnl

Une zone mise à jour avec nsupdate peut posséder un fichier journal portant l’extension .jnl. Dans ce cas, le contenu actuellement chargé ne correspond pas forcément au seul fichier texte visible sur le disque.

Pour contrôler une zone en tenant compte de son journal :

sudo named-checkzone -j example.com /var/cache/bind/db.example.comLangage du code : JavaScript (javascript)

Évitez de modifier directement le fichier d’une zone dynamique pendant que BIND fonctionne. Figez d’abord les mises à jour et synchronisez le journal :

sudo rndc freeze example.comLangage du code : CSS (css)

Modifiez et validez ensuite le fichier. Puis réactivez les mises à jour :

sudo rndc thaw example.comLangage du code : CSS (css)

Cette précaution évite qu’une version conservée dans le journal écrase ou contredise vos changements manuels.

Checklist de résolution

1. Lancez named-checkzone sur la zone concernée.
2. Notez le fichier, la ligne et le nom indiqués.
3. Vérifiez que le propriétaire de l’enregistrement appartient à la zone.
4. Contrôlez la valeur courante de $ORIGIN.
5. Ajoutez un point final aux cibles externes pleinement qualifiées.
6. Supprimez les enregistrements A ou AAAA de noms externes.
7. Déplacez l’enregistrement dans sa véritable zone lorsque vous la gérez.
8. Augmentez le serial SOA.
9. Relancez named-checkzone.
10. Validez toute la configuration avec named-checkconf -z.
11. Rechargez uniquement la zone avec rndc reload.
12. Vérifiez les journaux et les réponses avec dig.

Commandes essentielles

Vérifier une zone :

sudo named-checkzone example.com /etc/bind/db.example.com

Vérifier la configuration et charger les zones primaires :

sudo named-checkconf -z

Recharger une seule zone :

sudo rndc reload example.comLangage du code : CSS (css)

Consulter les journaux :

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

Tester la réponse faisant autorité :

dig @127.0.0.1 example.com SOA +norecurseLangage du code : CSS (css)

Questions fréquentes

L’erreur « ignoring out-of-zone data » empêche-t-elle BIND de démarrer ?

Pas toujours. BIND peut ignorer uniquement l’enregistrement concerné et charger le reste de la zone. Toutefois, la donnée rejetée ne sera pas publiée. Il faut donc corriger l’avertissement, même lorsque le service semble fonctionner.

Puis-je déclarer l’adresse IP d’un serveur MX externe dans ma zone ?

Non. Votre zone peut référencer ce serveur dans un enregistrement MX, mais l’enregistrement A ou AAAA du serveur externe doit être publié par sa propre zone DNS.

Pourquoi faut-il terminer certains noms par un point ?

Le point final indique que le nom est pleinement qualifié. Sans lui, BIND peut ajouter l’origine de la zone au nom, ce qui produit une cible différente de celle attendue.

Faut-il redémarrer BIND après chaque modification ?

Non. Après validation, rechargez uniquement la zone avec rndc reload nom-de-zone. Cette méthode limite les interruptions et évite de redémarrer inutilement le service complet.

Quelle différence existe-t-il entre named-checkzone et named-checkconf ?

named-checkzone valide une zone et son fichier. named-checkconf contrôle la configuration générale de BIND. Avec l’option -z, il tente également de charger les zones primaires déclarées.

Conclusion

L’erreur ignoring out-of-zone data signale qu’un enregistrement DNS a été placé dans une zone qui ne peut pas en être l’autorité.

Le plus souvent, la correction consiste à supprimer un enregistrement A ou AAAA associé à un domaine externe. Dans d’autres cas, il faut corriger $ORIGIN, ajouter un point final ou déplacer l’entrée dans le bon fichier.

Après la modification, augmentez le serial SOA, validez avec named-checkzone, contrôlez l’ensemble avec named-checkconf -z, puis rechargez la zone avec rndc. BIND n’aime pas les approximations, mais il fournit heureusement de très bons outils pour les retrouver.

Sources

• ISC BIND 9 : documentation de named-checkzone
• ISC BIND 9 : documentation de named-checkconf
• ISC BIND 9 : configuration et fichiers de zone
• BIND 9 : outils d’administration named-checkconf, named-checkzone et rndc
• BIND 9 : fichiers de zone, @ et $ORIGIN

Report a typo