dnsmasq rejette une réponse DNS privée : est-ce la protection anti-rebinding ?

Le serveur DNS de l'entreprise renvoie bien l'adresse privée attendue, et pourtant une requête passant par le résolveur de transfert local échoue encore. La réponse existe, ce qui écarte la zone amont et l'enregistrement lui-même. Il reste l'étape où le résolveur décide de remettre ou non cette réponse au client. Si ce résolveur est dnsmasq, le rejet figure probablement déjà dans le journal.

Recevoir une réponse et choisir de la renvoyer sont deux étapes différentes.

Comparez le même nom sur les deux résolveurs

Notez quel résolveur l'application utilise réellement et le nom d'hôte exact qu'elle interroge. Comparez ensuite le résultat amont avec l'événement du résolveur de transfert pour ce même nom. Une réponse amont absente, une réponse négative mise en cache et un rejet journalisé demandent trois corrections différentes.

Une adresse visible dans une requête de diagnostic directe ne prouve pas que l'application l'a reçue par son chemin habituel. Les deux requêtes peuvent partir de résolveurs différents, ou du même résolveur avec des politiques différentes. Écrivez les deux résultats avant de théoriser, car c'est à cette étape que l'on substitue l'un à l'autre. La comparaison, c'est tout le diagnostic.

Lisez le rejet plutôt que le symptôme

L'option stop-dns-rebind de dnsmasq rejette les réponses d'adresse privée éligibles reçues de l'amont, et les journalise lorsqu'elle le fait. Cette protection a une bonne raison d'exister : un nom public qui se résout soudain vers une adresse privée est l'attaque de rebinding classique. Elle recoupe aussi un service volontairement privé, ce qui est votre cas.

Cherchez le rejet dans le journal avant de modifier quoi que ce soit, car le message nomme le mécanisme.

S'il n'y a ni rejet ni réponse amont, la protection anti-rebinding n'est pas votre problème, et la désactiver serait une modification qui ne corrige rien tout en élargissant l'exposition. C'est pire que la panne d'origine, car on retire un contrôle en laissant le défaut. Confirmez d'abord la ligne de journal précise. Décidez ensuite.

Limitez l'exception à un seul domaine

Pour un domaine vérifié, le manuel de dnsmasq propose une exception limitée au domaine plutôt qu'un interrupteur global.

rebind-domain-ok=corp.example

Le domaine ci-dessus n'est qu'un exemple. Utilisez le domaine administratif que vous exploitez réellement, et comprenez la portée de correspondance de l'option avant de l'appliquer, car une règle de suffixe couvre plus que l'hôte testé. Le générateur de configuration d'un routeur peut exposer le même réglage via son propre contrôle plutôt que par une directive brute. Les deux voies conviennent tant que la portée obtenue est celle voulue.

Une exception à la détection de rebinding fait exactement une chose : elle laisse passer les réponses de ce domaine.

Elle ne configure pas de redirecteur split-DNS, ne rend pas joignable un amont injoignable et ne crée pas de route vers l'adresse renvoyée. Chacune de ces exigences est distincte, avec sa propre signature de panne, et chacune échoue différemment côté client.

Vérifiez sans supprimer la frontière

Interrogez à nouveau le nom d'hôte par le chemin de transfert, puis connectez-vous au service avec ses contrôles d'identité habituels. Une exception DNS n'est pas une raison d'accepter un certificat inattendu, et les deux pannes sont faciles à confondre lorsqu'elles se manifestent par une erreur de navigateur. Testez le nom et le service séparément. Un seul des deux a jamais été un problème DNS.

Conservez la raison de l'exception à côté de la configuration, avec une date et un responsable.

Revérifiez-la lorsque le service privé déménage ou que le domaine change. Désactiver la protection globalement changerait le traitement des réponses sans rapport, et laisserait de toute façon la panne de route ou de service en place si le rebinding n'a jamais été la cause.