web-dev-qa-db-fra.com

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

J'ai un réseau interne avec un serveur DNS exécutant BIND, connecté à Internet via une seule passerelle. Mon domaine "example.com" est géré par un fournisseur DNS externe. Certaines des entrées de ce domaine, par exemple "Host1.example.com" et "Host2.example.com", ainsi que l'entrée de niveau supérieur "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. D'autres hôtes comme "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 interroger "otherhost.example.com" entraîne une erreur.

Est-il possible de configurer BIND pour remplacer uniquement certaines entrées d'un domaine et résoudre le reste de manière récursive?

domain-name-systembind
41
Remy Blank

La meilleure méthode consiste à utiliser la zone de stratégie de réponse dans Bind 9.8.1 ou une version plus récente. Il 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, uniquement l'enregistrement unique que vous souhaitez modifier), il vous permet de remplacer les CNAME, etc. D'autres solutions telles que Unbound ne peuvent pas remplacer les CNAME .

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

EDIT: Faisons cela correctement alors. Je vais documenter ce que j'ai fait sur la base du 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 minimes sur d'autres plates-formes.

Allez à l'endroit où vos fichiers de configuration Bind sont conservés sur votre système - ici, c'est dans /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.

Qu'est ce que ça fait?

  • il remplace l'adresse IP pour www.some-website.com avec la fausse adresse 127.0.0.1, envoyant efficacement tout le trafic de ce site à 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, vous pouvez l'utiliser ici.

Pour activer ces modifications, il y a quelques étapes supplémentaires:

Éditer 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 le faire fonctionner sur votre résolveur local.

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

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

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

Redémarrez maintenant Bind:

service bind9 restart

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

Si vous devez apporter des modifications, modifiez simplement db.rpz, puis redémarrez Bind à nouveau.

Bonus: si vous souhaitez enregistrer les requêtes DNS dans syslog, afin de pouvoir garder un œil sur la procédure, modifiez named.conf.local et assurez-vous qu'il existe une section logging qui inclut ces instructions:

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 exécutant Bind:

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

Si vous exécutez Dig sur une autre machine, utilisez simplement @ l'adresse-ip-du-serveur-Bind au lieu de @ 127.0.0.1

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

19
Florin Andrei

Le serveur récursif non consolidé a la capacité de remplacer les enregistrements de ressources individuels.

Regarde le local-zone et local-data paramètres de configuration dans manuel , par exemple:

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

Le paramètre transparent sur le local-zone lui dit d'effectuer des recherches récursives normales pour tous les noms non fournis avec local-data.

21
Alnitak

Vous voudrez peut-être examiner "dnsmasq", qui vous permet de faire des choses assez intelligentes avec une résolution de réglage.

4
Luke

Ce que vous recherchez est un DNS divisé, qui est défini par Webopedia comme:

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

Essentiellement, vous devrez faire une copie de votre fichier de zone externe et le soutenir 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, mais il peut ê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 implémenté quelle que soit l'implémentation de serveur DNS que vous utilisez. Dans la plupart des configurations, vous aurez un serveur DNS qui dessert le réseau externe et un autre qui dessert le réseau interne. Avec BIND, comme peut-être 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é cela) serait de définir votre domaine example.com sur le serveur DNS interne avec uniquement les enregistrements que vous utilisez en interne. Ensuite, définissez une instruction "forward" avec le "premier" argument (conjointement avec "forwarders"). En théorie, cela irait demander au serveur DNS externe (comme défini dans "redirecteurs" une réponse, qui n'aurait pas vos enregistrements internes et retournerait une réponse d'échec. Ensuite, le serveur interne se regarderait lui-même pour une réponse. Pas sûr que cela fonctionnerait, mais c'est une pensée.

4
Justin Scott

Dans BIND, j'obtiens ces résultats en définissant une zone en utilisant le nom d'hôte souhaité. L'approche est correcte si vous ne souhaitez remplacer que quelques hôtes.

Ma déclaration de zone ressemble à ceci:

zone "override.example.com" {
        type master;
        notify no;
        file "zone-config/override.example.com";
};

Ma définition de zone ressemble à ceci:

$TTL 4H
@       IN      SOA     ns.override.example.com.    root.override.example.com. (
                        2009072215      ; Serial
                        3600            ; Refresh
                        600             ; Retry
                        604800          ; Expire
                        3600    )       ; Minimum
;
                NS      ns
        IN      NS      ns.override.example.com.
        IN      A       192.168.1.100
ns      IN      A       192.168.1.100

Donc, si je demande example.com sur DNS intranet et DNS ISP, j'obtiens la même IP, mais si je demande override.example.com, j'obtiens des résultats différents si le DNS intranet (principal) est accessible.

3
srdjan

Utiliser dnsmasq rend la tâche très simple. http://www.thekelleys.org.uk/dnsmasq/doc.html Agit comme le serveur DNS mais obtient des réponses du serveur DNS local. Une bonne chose est que vous pouvez remplacer les enregistrements de domaine unique sans jouer avec les fichiers de zone

2
Dustin

En fait, il existe un autre moyen, même légèrement différent, de procéder. J'ai la même situation, j'ai un domaine qui est utilisé en externe et en interne, et j'ai des hôtes statiques et dynamiques externes. Les seuls vraiment douloureux sont les dynamiques externes. La solution n'est peut-être pas la plus élégante, mais implémentable avec un petit script. La plupart du temps, je fais mon propre script DNS dynamique avec l'API de mon fournisseur DNS dynamique, j'exécute ce script par cron, toutes les 5 minutes:

1) obtenir mon adresse IP externe. at-il changé? sans issue.

2) IP changée, appelez l'API de dyndns-provider, avec la nouvelle adresse IP,

3) sed le db.mydomain.com avec l'IP externe

4) redémarrez la liaison.

Fonctionne de manière très fiable pour mon réseau domestique

2
nico

Vous êtes déjà sur la bonne voie.

Sur vos serveurs DNS internes, vous devrez définir une zone pour chaque hôte d'exception immédiatement en dessous de "example.com". Pour minimiser ces exceptions, il est courant de nommer toutes les machines internes "hosta.internal.example.com", le serveur DNS envoyant la plupart des requêtes aux serveurs DNS externes, mais faisant autorité pour la zone "internal.example.com". (Une fois que vous avez dépassé de petites opérations, il existe généralement un serveur DNS vers lequel les clients sont dirigés et un DNS faisant autorité distinct vers lequel ces serveurs sont dirigés pour "internal.example.com".)

Habituellement, ce n'est que lorsqu'un hôte doit être accessible à la fois en externe et en interne que les exceptions que vous décrivez sont créées. Même dans ce cas, vous souhaiterez peut-être utiliser "Host1.example.com" de l'extérieur et "Host1.internal.example.com" de l'intérieur. Les hôtes internes sont configurés pour rechercher des noms dans "internal.example.com". Il y a des situations où ce que vous faites déjà est approprié, comme si le certificat d'un serveur identifie le serveur comme "Host1.example.com", auquel cas vous voulez que ce soit le nom auquel les clients se connectent.

2
Stephen P. Schaefer