Suivre la requête DNS saut par saut pour trouver la vraie source
Une adresse de résolveur imposée ne décide pas de la source que le résolveur voit. Suivez le client, le relais et le serveur qui reçoit, puis consignez le chemin.
Fournir une adresse de résolveur à un client fixe où les requêtes sont envoyées, pas la source que le résolveur verra. Le routage, le transfert et la traduction ont chacun leur tour entre les deux extrémités. Un guide d'intervention pour les questions de source suit la requête saut par saut et note ce que chaque observateur a réellement vu. L'ordre compte, car une affirmation faite avant l'observation n'est qu'une supposition mieux formatée.
Consignez la disposition avant de recueillir des preuves
Quatre endroits peuvent vous apprendre quelque chose sur une source DNS, et ils ne disent pas tous la même chose. Le noyau du client sait quelle source il utiliserait, un relais sait ce qu'il a envoyé en amont, un appareil de traduction sait ce qu'il a réécrit, et le résolveur qui reçoit sait ce qui est arrivé. Consignez ceux que vous pouvez réellement atteindre avant de recueillir quoi que ce soit.
| Observation point | What it can prove | What it cannot prove | How to read it |
|---|---|---|---|
| client kernel | which source address it would use for that resolver | anything a device in between rewrote | ip route get against the resolver address |
| forwarder | that it sent an upstream query, and from which source | what the client originally asked for | its own log and its cache state |
| translating device | that a source was rewritten, and to what | whether the query was legitimate | NAT policy and its counters |
| receiving resolver | the address that actually arrived | which client behind that address asked | a scoped capture on port 53 |
Consignez aussi votre attente, y compris le résolveur que vous croyez en service. Une route fractionnée peut envoyer une requête ailleurs du tout, et un cache peut répondre sans le moindre échange en amont, si bien qu'une hypothèse gardée en mémoire seule ne survivra pas à la première surprise. Gardez la conception annoncée et le chemin observé dans des colonnes séparées d'une même note ; quand les deux divergent, vous avez trouvé la question qui vaut la peine d'être poursuivie.
Vérifiez quel processus a réellement envoyé la requête
Commencez par le client : notez l'adresse du résolveur, le nom interrogé et l'heure, puis confirmez quel processus l'a envoyée. La première ligne ci-dessous nomme le processus qui détient la socket UDP, et c'est la vérification que cette rubrique promet. Si ce processus est une assistance de navigateur ou un moteur de conteneur plutôt que le résolveur du système, le reste de la trace décrit un chemin que personne n'a demandé.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Sur un hôte à plusieurs interfaces, déterminez d'abord quelle adresse source le noyau choisit pour cette destination avant de regarder ailleurs. C'est le dernier point où le chemin est entièrement sous votre contrôle, et c'est la valeur que vous comparerez à ce que le résolveur rapporte. Un écart est le signal que quelque chose entre les deux a réécrit le paquet, ou que deux requêtes différentes ont été envoyées.
Gardez les noms de test internes, car un nom interne soumis à un résolveur public ne prouve rien sur le chemin interne et publie un nom que vous n'aviez pas besoin de publier. Un navigateur avec DNS sécurisé activé n'apparaîtra pas du tout dans cette liste de sockets, et cette absence est elle-même la réponse.
Le relais émet une seconde requête, distincte
Un relais transforme un échange en deux. La demande aval arrive, puis le relais envoie sa propre requête en amont depuis une adresse qu'il choisit. Sa configuration, et non le client, décide de ce que voit le résolveur amont.
Le manuel de dnsmasq mérite d'être lu pour cette raison : il documente comment un relais choisit ses serveurs amont et lie son côté écoute, et rien dans cette disposition ne transporte la source du client vers l'amont. Un journal de résolveur montrant une adresse de passerelle est donc normal, et non la preuve d'une anomalie. L'absence se lit tout aussi facilement de travers, car un succès de cache ne produit aucune requête en amont et ressemble à s'y méprendre à une requête qui n'est jamais arrivée. Lisez la configuration du relais et l'état de son cache avant de tirer l'une ou l'autre conclusion. Deux questions, deux endroits à regarder.
Lisez la source sur le résolveur qui reçoit
La seule observation qui tranche est prise côté serveur. Tout ce qui se déduit de la liste d'interfaces du client reste une hypothèse tant que le résolveur n'a pas rapporté ce qui est réellement arrivé.
tcpdump -ni any port 53 and host 10.20.30.53Capturez sur l'hôte du résolveur, gardez la capture courte et limitée, et stockez-la là où la politique l'autorise. Si la source observée est une adresse traduite, la question suivante est quel appareil a fait la traduction et si sa politique est celle prévue. Une capture répond à ce qui est arrivé ; elle n'explique pas pourquoi la politique l'a permis. Nommez l'observateur et le saut dans la note, car une affirmation de confidentialité sur une passerelle porte sur ce saut et non sur tout le chemin.
Écrivez le constat comme un chemin, pas comme une adresse
Consignez le client, le résolveur, tout relais, la source observée à chaque saut et la politique qui le régit. Ce relevé répond à la plupart des questions futures sans nouvelle capture. Dessinez-le comme une chaîne, car une liste d'adresses cache quel saut a produit laquelle.
Joignez la date, la version du client et la révision de configuration au schéma, afin qu'un lecteur ultérieur puisse dire s'il s'applique encore. Séparez la source de transport de tout le reste que le service traite, car voir une adresse de passerelle ne dit rien de ce qui est conservé par ailleurs. L'emplacement d'un résolveur ne dit rien non plus sur le client qui a interrogé. C'est en gardant ces affirmations distinctes que la conclusion reste défendable en revue.