Timeout DNS ou SERVFAIL : quelle différence ?

Toutes les résolutions DNS qui échouent n'échouent pas de la même façon. Deux des échecs les plus courants autres que NXDOMAIN, le timeout et le SERVFAIL, se ressemblent vus de l'extérieur (aucune réponse exploitable n'est revenue), mais indiquent des causes profondes sensiblement différentes.

Timeout : aucune réponse n'est arrivée à temps

Un timeout veut dire exactement ce qu'il dit : la requête a été envoyée, et aucune réponse n'est revenue pendant le délai d'attente configuré. Cela peut arriver parce que le serveur faisant autorité est surchargé, à cause de pertes de paquets quelque part sur le chemin réseau, ou parce qu'un pare-feu abandonne silencieusement le trafic DNS au lieu de le rejeter explicitement. Du côté de l'émetteur de la requête, un timeout et un serveur qui n'existe tout simplement pas sont indiscernables : dans les deux cas, c'est le silence.

SERVFAIL : une réponse est arrivée, et c'était « je ne peux pas »

Un SERVFAIL est une vraie réponse, pas du silence. Le serveur qui a répondu indique explicitement qu'il a rencontré un problème en traitant la requête : une zone mal configurée, un échec de validation DNSSEC, une erreur interne côté résolveur. Recevoir un SERVFAIL vous apprend que quelque chose de concret s'est produit côté serveur, alors qu'un timeout vous renseigne comparativement très peu sur l'endroit où se situe réellement le problème.

Comme les deux peuvent être passagers, la bonne gestion est la même en pratique : réessayer un petit nombre de fois avec une temporisation exponentielle, et ne signaler un véritable échec qu'une fois ces tentatives épuisées. C'est exactement ainsi que cet outil traite ces deux codes, différemment d'un NXDOMAIN définitif.

REFUSED indique généralement une politique, pas une panne

REFUSED est souvent mis dans le même sac que SERVFAIL parce que, dans les deux cas, « le serveur a dit non » au lieu de rester silencieux, mais les raisons sont généralement très différentes. Un serveur de noms renvoie couramment REFUSED lorsqu'il est configuré pour ne répondre que pour certaines zones et qu'on l'interroge sur autre chose, lorsqu'une liste de contrôle d'accès bloque l'IP émettrice, ou lorsqu'un résolveur a été explicitement configuré pour rejeter les requêtes venant de l'extérieur de son propre réseau (un résolveur récursif qui refuse de fournir des réponses récursives à des inconnus sur Internet, par exemple : un comportement correct et voulu, pas un bogue). Recevoir REFUSED d'un serveur que vous ne contrôlez pas se règle rarement par une nouvelle tentative ou une stratégie de temporisation ; mieux vaut vérifier si vous interrogez bien le bon serveur.

Une cause fréquente et précise de SERVFAIL : un DNSSEC défaillant

L'un des scénarios de SERVFAIL les plus frustrants se produit sur les domaines où DNSSEC est activé mais mal configuré : une signature expirée, une clé renouvelée sur le serveur de noms mais pas mise à jour chez le registraire, ou une chaîne de confiance rompue quelque part entre le domaine et la racine. Un résolveur validant qui respecte DNSSEC refusera de renvoyer une réponse qu'il ne peut pas vérifier cryptographiquement, et renvoie SERVFAIL plutôt que d'ignorer silencieusement la signature défaillante. Le plus troublant est que le domaine fonctionne souvent parfaitement avec un résolveur qui ne valide pas DNSSEC du tout, ce qui permet de mal diagnostiquer la cause en se disant « chez moi, ça marche » alors que le domaine est réellement en panne pour une part non négligeable des visiteurs.