64 votes

Remplacer certaines entrées DNS dans BIND pour les réseaux internes

Je dispose d'un réseau interne avec un serveur DNS exécutant BIND, connecté à Internet par une passerelle unique. Mon domaine "exemple.com" est géré par un fournisseur DNS externe. Certaines des entrées de ce domaine, comme "host1.example.com" et "host2.example.com", ainsi que l'entrée de premier niveau "example.com", pointent vers l'adresse IP publique de la passerelle.

Je voudrais que les hôtes situés sur le réseau interne résolvent "host1.example.com", "host2.example.com" et "example.com" en adresses IP internes au lieu de celle de la passerelle. Les autres hôtes, tels que "otherhost.example.com", doivent toujours être résolus par le fournisseur DNS externe.

J'ai réussi à le faire pour les entrées host1 et host2, en définissant deux zones à entrée unique dans BIND pour "host1.example.com" et "host2.example.com". Cependant, si j'ajoute une zone pour "example.com", toutes les requêtes pour ce domaine sont résolues par mon serveur DNS local, et par exemple, la requête "otherhost.example.com" donne lieu à une erreur.

Est-il possible de configurer BIND de façon à ce qu'il ne prenne en compte que les éléments suivants un peu de d'un domaine, et de résoudre le reste de manière récursive ?

57voto

Florin Andrei Points 1098

La meilleure méthode consiste à utiliser la zone de politique de réponse dans Bind 9.8.1 ou plus récent. Elle vous permet de remplacer des enregistrements uniques dans des zones arbitraires (et il n'est pas nécessaire de créer un sous-domaine entier pour cela, seulement l'enregistrement unique que vous voulez modifier), elle vous permet de remplacer les CNAME, etc. D'autres solutions, comme Unbound, ne peuvent pas remplacer les CNAME.

https://www.redpill-linpro.com/sysadvent/2015/12/08/dns-rpz.html


EDIT : Faisons ça correctement alors. Je vais documenter ce que j'ai fait en me basant sur le tutoriel lié ci-dessus.

Mon système d'exploitation est Raspbian 4.4 pour Raspberry Pi, mais la technique devrait fonctionner sans aucune modification sur Debian et Ubuntu, ou avec des modifications minimales sur d'autres plateformes.

Allez à l'endroit où se trouvent les fichiers de configuration de Bind sur votre système - ici, ils se trouvent à l'adresse suivante /etc/bind . Créez-y un fichier appelé db.rpz avec le contenu suivant :

$TTL 60
@            IN    SOA  localhost. root.localhost.  (
                          2015112501   ; serial
                          1h           ; refresh
                          30m          ; retry
                          1w           ; expiry
                          30m)         ; minimum
                   IN     NS    localhost.

localhost       A   127.0.0.1

www.some-website.com    A        127.0.0.1

www.other-website.com   CNAME    fake-hostname.com.

Que fait-il ?

  • il remplace l'adresse IP pour www.some-website.com avec la fausse adresse 127.0.0.1 en envoyant tout le trafic de ce site vers l'adresse de bouclage.
  • il envoie du trafic pour www.other-website.com vers un autre site appelé fake-hostname.com

Tout ce qui pourrait aller dans un fichier de zone de liaison peut être utilisé ici.

Pour activer ces changements, il y a encore quelques étapes à franchir :

Modifier named.conf.local et ajoutez cette section :

zone "rpz" {
  type master;
  file "/etc/bind/db.rpz";
};

Le tutoriel lié ci-dessus vous dit d'ajouter plus de choses à zone "rpz" { } mais ce n'est pas nécessaire dans les configurations simples - ce que j'ai montré ici est le minimum pour que cela fonctionne sur votre résolveur local.

Modifier named.conf.options et quelque part dans le options { } ajouter la section response-policy option :

options {
  // bunch
  // of
  // stuff
  // please
  // ignore

  response-policy { zone "rpz"; };
}

Maintenant, redémarrez Bind :

service bind9 restart

C'est ça. Le serveur de noms devrait commencer à remplacer ces enregistrements maintenant.

Si vous devez faire des changements, il suffit de modifier db.rpz puis redémarrez Bind.

Bonus : si vous souhaitez enregistrer les requêtes DNS dans le syslog, afin de garder un œil sur la procédure, modifiez le fichier named.conf.local et assurez-vous qu'il y a un logging qui comprend ces déclarations :

logging {
    // stuff
    // already
    // there

    channel my_syslog {
        syslog daemon;
        severity info;
    };
    category queries { my_syslog; };
};

Redémarrez Bind à nouveau et c'est tout.

Testez-le sur la machine qui exécute Bind :

dig @127.0.0.1 www.other-website.com. any

Si vous exécutez dig sur une autre machine, utilisez simplement @the-ip-address-of-Bind-server au lieu de @127.0.0.1.

J'ai utilisé cette technique avec succès pour remplacer le CNAME d'un site Web sur lequel je travaillais, en l'envoyant vers un nouvel équilibreur de charge AWS que je testais. Un Raspberry Pi a été utilisé pour exécuter Bind, et le RPi a également été configuré pour fonctionner comme un routeur WiFi - ainsi, en connectant des appareils au SSID fonctionnant sur le RPi, j'obtenais les dérogations DNS dont j'avais besoin pour mes tests.

23voto

Joey deVilla Points 4487

En Non consolidé Le serveur DNS récursif a la possibilité de remplacer les enregistrements de ressources individuels.

Regardez le local-zone y local-data les paramètres de configuration dans le manuel par exemple :

local-zone: "example.com." transparent
local-data: "foo.example.com. IN A 192.168.1.1"

En transparent sur le local-zone lui indique d'effectuer des recherches récursives normales pour tous les noms qui ne sont pas fournis par le paramètre local-data .

4voto

Russ Cam Points 58168

Vous pouvez vous intéresser à "dnsmasq", qui vous permet de faire des choses assez astucieuses en modifiant la résolution.

4voto

Justin Scott Points 8728

Ce que vous recherchez est le split DNS, qui est défini par Webopedia comme :

Dans une infrastructure DNS divisée, vous créez deux zones pour le même domaine, une pour être utilisée par le réseau interne réseau interne, l'autre utilisée par le réseau externe. Le DNS divisé dirige les hôtes internes vers un serveur de nom de domaine interne de domaine interne pour la résolution des noms et les hôtes externes sont dirigés vers un serveur de nom de domaine externe pour la pour la résolution des noms.

Pour l'essentiel, vous devrez faire une copie de votre fichier de zone externe et l'installer sur votre serveur DNS interne, puis modifier ou ajouter les enregistrements nécessaires spécifiquement pour votre réseau interne. Il s'agit d'une configuration assez courante, bien qu'il puisse être difficile de synchroniser les enregistrements "externes" entre les deux serveurs DNS. Si vous créez ou modifiez un enregistrement sur le serveur public, il devra également être créé ou modifié sur le serveur privé.

Cela peut être mis en œuvre indépendamment de l'implémentation du serveur DNS que vous utilisez. Dans la plupart des configurations, vous aurez un serveur DNS qui servira le réseau externe, et un autre qui servira le réseau interne. Avec BIND, et éventuellement d'autres implémentations, vous pouvez avoir les deux versions de la zone sur le même serveur en utilisant l'instruction "allow-query" dans la section zone du fichier named.conf.

Une autre possibilité sur BIND (et je n'ai jamais essayé) serait de définir votre domaine exemple.com sur le serveur DNS interne avec seulement les enregistrements que vous utilisez en interne. Ensuite, définissez une instruction "forward" avec l'argument "first" (en conjonction avec "forwarders"). En théorie, cela devrait demander une réponse au serveur DNS externe (comme défini dans "forwarders"), qui n'aurait pas vos enregistrements internes et renverrait une réponse d'échec. Ensuite, le serveur interne s'interrogerait sur lui-même pour obtenir une réponse. Pas sûr que cela fonctionne, mais c'est une idée.

3voto

Utiliser dnsmasq rend les choses très faciles. http://www.thekelleys.org.uk/dnsmasq/doc.html Agit comme le serveur DNS mais reçoit les réponses du serveur DNS local. Ce qui est bien, c'est que vous pouvez modifier les enregistrements d'un seul domaine sans avoir à manipuler les fichiers de zone.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X