Journaliser et superviser un serveur DNS
Un serveur DNS tombe rarement franchement : il ralentit, renvoie des erreurs, ou répète des réponses fausses depuis son cache. Les journaux et quelques indicateurs bien choisis rendent ces dérives visibles avant qu'elles ne deviennent des incidents pour les utilisateurs.
Ce qu'un journal de requêtes contient
Un journal de requêtes enregistre, pour chaque question reçue, le nom demandé, le type, l'adresse du client, la réponse renvoyée et parfois la durée de traitement. C'est la matière première du diagnostic : il montre qui demande quoi, et permet de distinguer un défaut de zone d'un défaut de résolveur. Sans lui, l'analyse se limite à des essais depuis l'extérieur.
Ce contenu est aussi une donnée sensible. Une adresse IP associée à un nom consulté est une donnée personnelle au sens du règlement européen sur la protection des données : sa collecte doit avoir une finalité, une durée de conservation et des accès limités. Journaliser tout, indéfiniment, sur un serveur accessible, expose l'organisation sans améliorer le diagnostic.
La bonne pratique consiste à activer la journalisation des requêtes par période, lors d'un diagnostic, plutôt qu'en permanence. Lorsqu'un besoin d'analyse durable existe, la conservation se limite à quelques jours et les journaux sont restreints aux personnes qui en ont l'usage.
Activer les traces sans se noyer
Les serveurs de noms modernes séparent les catégories de messages : erreurs de configuration, transferts de zone, requêtes, mises à jour dynamiques. Activer tout revient à produire un volume considérable et à masquer l'essentiel. On active d'abord les catégories d'exploitation, puis la catégorie des requêtes seulement quand une question précise se pose.
Le volume impose une rotation et une purge automatiques. Un journal de requêtes sur un serveur un peu sollicité se compte en gigaoctets par jour ; sans rotation, il remplit la partition et le serveur cesse de fonctionner pour une raison sans rapport avec le DNS. La taille maximale, le nombre d'archives et la purge doivent être réglés avant la première activation.
Certains serveurs proposent un export structuré des événements, plus exploitable qu'un journal texte : chaque requête devient un objet avec ses champs, directement indexable par un outil d'analyse. Ce format coûte un peu de configuration mais évite le travail de réécriture qui accompagne les journaux texte.
Les indicateurs qui comptent
Quatre familles suffisent. Le volume de requêtes par seconde donne la charge et révèle une augmentation anormale. La part de réponses en erreur, en particulier les échecs de résolution côté serveur, mesure la santé réelle du service. La part de réponses négatives distingue une zone incomplète d'un trafic mal formé. La latence de traitement indique la saturation avant qu'elle ne devienne visible.
À ces indicateurs s'ajoutent ceux de la réplication : numéro de série identique sur tous les serveurs, âge de la dernière copie, échecs de transfert. Un serveur qui répond parfaitement mais dont la copie date de plusieurs jours est un incident en préparation, invisible dans les métriques de disponibilité classiques.
Reconnaître un trafic anormal
Un serveur récursif ouvert, qui répond à tout Internet, est utilisé dans des attaques par amplification : l'attaquant envoie des requêtes avec une adresse source falsifiée vers de nombreuses cibles. Le trafic entrant semble ordinaire, seule la répartition des destinations trahit l'usage. La première mesure reste de refuser la récursion aux clients qui n'y ont pas droit.
Les serveurs autoritatifs subissent une autre forme de trafic : des interrogations massives pour des noms aleatoires, destinées à saturer le cache négatif ou le lien. Les logiciels proposent une limitation du débit des réponses, qui réduit la charge en groupant les réponses identiques. Cette limitation se règle avec prudence : mal configurée, elle dégrade le service pour les résolveurs légitimes qui interrogent beaucoup.
Dans les deux cas, le journal est la preuve. Sans trace, la seule issue est de bloquer largement, avec le risque de couper des utilisateurs réels. Avec trace, on cible un préfixe, une signature de requête, ou l'on constate que le problème vient d'ailleurs.
Superviser depuis l'extérieur
La supervision interne mesure la machine ; la supervision externe mesure le service. Faire résoudre un nom témoin par plusieurs résolveurs, depuis plusieurs réseaux, à intervalle régulier, détecte une panne de délégation ou une réponse fausse qu'aucune métrique locale ne montrerait. Ce contrôle doit porter sur un nom de la zone elle-même, pas sur un nom générique.
Il faut y ajouter la surveillance des certificats lorsque le serveur expose DNS sur TLS ou DNS sur HTTPS : un certificat expiré coupe le service sans que le DNS lui-même soit en cause. Et la surveillance de l'horloge : une dérive invalide les signatures d'une zone signée, avec un effet identique à une panne.
Ces contrôles se complètent : la sonde externe dit qu'un utilisateur ne peut pas résoudre, le journal dit pourquoi. Séparer les deux évite de chercher dans les journaux une panne qui se trouve chez le fournisseur d'accès, ou l'inverse.
Ce qu'il ne faut pas mesurer
La tentation est de suivre un indicateur de propagation après un changement de zone. Cet indicateur n'existe pas : chaque cache expire à son rythme, et agréger des observations ponctuelles produit un chiffre sans signification. Le suivi utile est celui du contenu publié par les autorités, complété par des tests depuis quelques résolveurs représentatifs.
De même, un nombre élevé de requêtes n'est pas en soi un problème, et un nombre faible n'est pas une preuve de bonne santé. Les indicateurs se lisent par rapport à une base de référence propre au serveur, établie dans le temps. Comparer son trafic à celui d'un autre serveur n'apprend presque rien.
Sources
- https://www.rfc-editor.org/rfc/rfc8499.html
- https://www.rfc-editor.org/rfc/rfc1035.html
- https://bind9.readthedocs.io/en/latest/
Pour vérifier un nom de domaine en direct — racine, TLD, serveurs de noms — utilisez l'outil de test DNS. Demarcq.net assure l'exploitation de serveurs DNS : les prestations d'exploitation.