Récursion indisponible : une politique DNS, pas un tunnel cassé

Le nom interne se résout, et le même serveur répond à un nom externe par un refus au sujet de la récursion. Cette combinaison n’est pas une contradiction. Publier ses propres zones et résoudre tout l’internet sont deux services distincts qu’un serveur peut offrir, et il peut assurer le premier sans le second. Traitez le refus comme une déclaration de politique, puis vérifiez si la politique correspond à la conception.

Un refus et un délai d’attente sont deux réponses différentes

Notez le nom, le type de requête, le serveur qui répond, le statut et les enregistrements renvoyés. Un avertissement de récursion n’invalide pas automatiquement une réponse autoritative arrivée avec lui. Écrivez le statut avant de l’interpréter. Un statut reconstruit de mémoire une heure plus tard est un autre fait.

L’en-tête DNS porte une demande de récursion et une indication que le serveur l’offre ou non, et la spécification du protocole garde ces indicateurs séparés des données de la réponse. C’est pourquoi une réponse peut être utile et porter malgré tout une plainte. Un délai d’attente, une réponse négative et un refus sont trois résultats différents. Chacun pointe vers une couche différente, et seul le refus est le serveur qui vous parle de politique.

Lisez d’abord le code de statut, puis décidez si l’avertissement compte pour cette requête. Une réponse autoritative qui nomme la zone reste utilisable même lorsque le bit de récursion est refusé. Un refus sans réponse est un résultat de politique, pas un chemin de paquets cassé.

Ce que le résolveur a enregistré comme votre source

Le client peut arriver depuis un pool d’adresses hors des plages récursives autorisées du serveur, ou une traduction peut le faire ressembler à une passerelle. L’adresse de l’adaptateur du client n’est pas une preuve de ce que le résolveur a reçu. Demandez à l’administrateur du serveur la source observée au lieu de la déduire de votre côté du chemin. Les deux adresses peuvent différer à chaque saut qui traduit.

Interrogez le même nom depuis le client et depuis un hôte auquel le serveur fait déjà confiance. La différence entre les deux réponses est la condition de source, et elle est plus utile que l’une ou l’autre réponse seule.

dig +short host.corp.example
dig +short example.com

Si le déploiement veut la récursion pour les clients VPN, l’administrateur autorise la plage de sources appropriée via les contrôles propres au serveur. Ouvrir la récursion à tous les réseaux pour qu’un test passe est un changement bien plus important que celui qui est testé. Écrivez la plage autorisée à côté de la règle, car le prochain relecteur demandera à quelles sources la politique devait servir. Une plage de sources sans propriétaire est la façon dont un test temporaire devient permanent.

Le DNS scindé est une conception, pas un défaut

Certains déploiements n’envoient que les domaines de travail au résolveur privé et tout le reste à un autre résolveur approuvé. C’est une conception de routage des requêtes, et ce n’est pas la preuve que le serveur privé a besoin d’une politique plus permissive. Dans cette conception, un nom externe qui échoue via le résolveur privé est le résultat voulu et non un défaut. Le refus est la conception qui fonctionne, pas un symptôme à étouffer.

Un résolveur public peut rétablir la navigation tout en cassant des noms internes ou en envoyant des requêtes privées là où elles ne devraient pas aller. Écrivez le comportement voulu avant de changer une adresse de résolveur.

Vérifiez la politique avec deux requêtes

Après la correction voulue, interrogez un nom privé autorisé et un nom externe depuis le client réel. Ce qui revient devrait être ce que la politique promet, pas seulement un diagnostic plus silencieux. Notez le serveur qui répond avec chaque réponse, puis comparez la paire à la politique. La comparaison est le test, et une seule recherche réussie ne l’est pas.

resolvectl query host.corp.example
resolvectl query example.com

Si le nom privé fonctionne et que le nom public est refusé, la politique fait ce qu’elle dit. Si le nom privé échoue aussi, le problème est la zone, la route ou l’autorisation de source, et la récursion est une distraction. Les deux issues sont utiles, et chacune écarte la moitié des hypothèses restantes.

Lisez le refus comme une preuve

Un refus est une réponse. Il signifie que le serveur a reçu la requête et a refusé d’effectuer le travail demandé, ce qui diffère d’un paquet jamais arrivé. Cette distinction est tout le diagnostic. Consignez-la comme une réponse, pas comme une panne de connectivité.

Cette distinction vous dit où regarder : les journaux du serveur, sa politique d’accès et la source qu’il a enregistrée. Un changement de pare-feu ne peut pas corriger un refus de politique, et un changement de politique ne peut pas corriger une route manquante. Gardez les deux hypothèses séparées jusqu’à ce que l’une d’elles ait une preuve.

Écrivez le résultat et le propriétaire de la politique dans le ticket, afin que la personne suivante parte de la décision et non de l’avertissement. Nommez la plage de sources autorisée et les deux noms que vous avez testés. Un ticket avec ces trois faits peut être rejoué ; un ticket qui dit "la récursion est cassée" ne le peut pas.