BIND derrière un VPN : transfert conditionnel ou zone stub ?

Votre résolveur de bureau répond à tout sauf à un espace de noms d'entreprise, et le serveur DNS d'entreprise qui le connaît se trouve derrière un VPN. BIND peut confier cette zone unique à l'upstream de trois manières différentes, et elles échouent différemment. Le transfert conditionnel est l'engagement le plus faible, une zone stub conserve les données de délégation, et une secondary conserve une copie complète. Choisissez selon ce que l'upstream autorisera et selon ce que vous voulez que votre résolveur conserve, pas selon l'extrait que vous avez trouvé en premier.

Trois dispositions pour un espace de noms

Transfert conditionnel : l'engagement le plus faible

Supposez un résolveur de bureau à 192.168.10.53 et un serveur d'entreprise à 10.40.0.53 joignable par un tunnel approuvé. La déclaration fait trois lignes, et la ligne intéressante est forward only, car elle change le comportement en cas de panne, pas le chemin.

zone "corp.example" {
    type forward;
    forward only;
    forwarders { 10.40.0.53; };
};

Avec forward only, un upstream injoignable produit un SERVFAIL pour cette zone au lieu d'un repli sur la résolution itérative. C'est généralement ce que vous voulez pour un espace de noms privé, car le repli enverrait des noms privés vers un résolveur public et renverrait une réponse inutile depuis l'internet. La référence BIND documente les deux politiques, et la différence compte plus que l'extrait ne le laisse penser. Intégrez la zone à la configuration existante plutôt que de remplacer une zone qui existe déjà pour le même nom.

Stub ou secondary : quand la délégation compte

Une zone stub demande au serveur d'entreprise les enregistrements NS de la zone, puis interroge directement les serveurs faisant autorité. Choisissez-la lorsque la région upstream est grande ou subdivisée et que vous voulez que votre résolveur suive la délégation au lieu de tout épingler à une adresse. Le coût est une dépendance à la fraîcheur des données NS et à la joignabilité de chaque serveur de noms listé depuis l'adresse source de votre résolveur.

zone "corp.example" {
    type stub;
    masters { 10.40.0.53; };
};

zone "corp.example" {
    type secondary;
    primaries { 10.40.0.53; };
    file "corp.example.db";
};

Une secondary répond à partir de données locales et survit à une panne de l'upstream, et c'est la raison d'accepter la dépendance au transfert. Cela signifie aussi que votre résolveur détient désormais une copie d'une zone qu'il ne possède pas, si bien que le chemin du fichier, l'ACL de transfert sur le primaire et les minuteries de rafraîchissement font tous partie de votre surface d'exploitation.

Le contrôle qui tranche entre elles

BIND génère sa propre requête sortante, donc la question n'est pas de savoir si un portable peut joindre 10.40.0.53, mais si l'hôte du résolveur le peut, depuis l'adresse source que verra le serveur d'entreprise. Interrogez le noyau, puis le serveur, dans cet ordre.

ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example

Autorisez UDP et TCP sur le chemin : une réponse tronquée force TCP, et une politique qui n'autorise qu'UDP produit des défaillances intermittentes qui ressemblent à une perte de paquets. Le côté entreprise a besoin à la fois d'une règle d'acceptation pour la source de votre résolveur et d'une route de retour vers celle-ci ; cette source peut être l'adresse routée du résolveur ou une adresse explicitement traduite, et c'est rarement une adresse de pool de clients. Si la requête NS échoue, une zone stub ne peut pas fonctionner, quel que soit le comportement de la zone forward.

Vérifiez la réponse, pas le tunnel

Interrogez le résolveur du bureau pour un nom que vous n'avez jamais demandé, et examinez la section authority de la réponse pour voir si elle vient de la zone d'entreprise. Une réponse en cache ne prouve rien sur le chemin actuel, et une requête directe réussie vers l'upstream ne prouve pas que votre résolveur a choisi cette zone. Répétez la même requête par TCP pour confirmer que le chemin survit à la troncature.

Gardez les clients pointés vers le résolveur du bureau, et gardez la validation DNSSEC activée. Un navigateur configuré avec un résolveur chiffré indépendant contourne entièrement cette disposition, et désactiver la validation pour qu'une réponse inattendue paraisse correcte échange une panne visible contre une invisible.

Notez laquelle des trois types vous avez choisie et pourquoi. La personne suivante qui verra la zone échouer aura plus besoin de cette phrase que du fichier de configuration.