Remplacement 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 "exemple.com" est géré par un fournisseur DNS externe. Certaines entrées de ce domaine, telles que "hôte1.exemple.com" et "hôte2.exemple.com", ainsi que l'entrée de niveau supérieur "exemple.com", renvoient à l'adresse IP publique de la passerelle.

Je souhaite 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 celles 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 "exemple.com", toutes les requêtes de ce domaine sont résolues par mon serveur DNS local. Par exemple, l'interrogation de "otherhost.example.com" entraîne une erreur.

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

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 (il n'est pas nécessaire de créer un sous-domaine complet pour cela, mais uniquement le seul enregistrement 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 minimales sur d'autres plates-formes.

Accédez à l'emplacement où sont conservés vos fichiers de configuration de liaison sur votre système /etc/bind. Créez-y un fichier appelé db.rpzavec 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 www.some-website.compar la fausse adresse 127.0.0.1, en envoyant effectivement tout le trafic de ce site à l'adresse de bouclage
• il envoie du trafic www.other-website.comvers un autre site appeléfake-hostname.com

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

Pour activer ces modifications, quelques étapes supplémentaires sont nécessaires:

Modifier named.conf.localet ajouter 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.optionset quelque part dans la options { }section ajouter l' response-policyoption:

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 apporter des modifications, modifiez-les db.rpz, puis redémarrez Bind.

Bonus: si vous souhaitez enregistrer les requêtes DNS dans syslog, vous pouvez ainsi surveiller les procédures, éditer named.conf.localet vérifier qu'une loggingsection contient les instructions suivantes:

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 en cours d'exécution Bind:

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

Si vous utilisez dig sur une machine différente, utilisez simplement @ l'adresse-ip-de-serveur-Bind 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 et l'envoyer à un nouvel équilibreur de charge AWS que je venais de tester. Un Raspberry Pi était utilisé pour exécuter Bind, et le RPi était également configuré pour fonctionner en tant que routeur WiFi. Ainsi, en connectant des périphériques au SSID exécuté sur le RPi, j'obtenais les substitutions DNS dont j'avais besoin pour les tests.

Le serveur DNS récursif non lié peut remplacer des enregistrements de ressources individuels.

Regardez les paramètres de configuration local-zoneet local-datadans le manuel , par exemple:

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

Le transparentparamètre sur le lui local-zonedit d'effectuer des recherches récursives normales pour tous les noms non fournis local-data.

Vous voudrez peut-être vous pencher sur "dnsmasq", qui vous permet de faire des choses très intelligentes avec une résolution améliorée.

Ce que vous recherchez, c'est un DNS fractionné, défini par Webopedia comme:

Dans une infrastructure DNS divisée, vous créez deux zones pour le même domaine, l'une devant être utilisée par le réseau interne et l'autre par le réseau externe. Split DNS 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.

Pour l'essentiel, vous devez copier votre fichier de zone externe et le conserver sur votre serveur DNS interne, puis modifier ou ajouter les enregistrements nécessaires à votre réseau interne. Il s’agit d’une configuration assez courante, même s’il peut être difficile de garder les enregistrements "externes" synchronisés entre les deux serveurs DNS. Si vous créez ou modifiez un enregistrement sur le serveur public, vous devrez également le créer ou le modifier sur le serveur privé.

Cela peut être implémenté indépendamment de l'implémentation du 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 é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é 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 (en conjonction avec "forwarders"). En théorie, cela irait demander au serveur DNS externe (comme défini dans les "redirecteurs") une réponse qui n'aurait pas vos enregistrements internes et ne renverrait une réponse d'échec. Ensuite, le serveur interne se chercherait lui-même une réponse. bien sûr si cela fonctionnerait, mais c'est une pensée.

Dans BIND, je parviens à ce résultat en définissant une zone à l'aide du nom d'hôte souhaité. L'approche est acceptable si vous souhaitez uniquement remplacer 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 j'interroge exemple.com sur DNS intranet et DNS du FAI, j'obtiens la même adresse IP mais si j'interroge override.example.com, j'obtiens des résultats différents si l'intranet DNS (principal) est accessible.

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 situé immédiatement sous "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 deux serveurs DNS vers lesquels les clients sont dirigés et un DNS faisant autorité distinct vers lequel ces serveurs sont dirigés pour "internal.example.com".)

En règle générale, les exceptions que vous décrivez sont créées uniquement lorsqu'un hôte doit être accessible à la fois en externe et en interne. 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". Dans certaines situations, ce que vous faites déjà est approprié, par exemple si le certificat d'un serveur identifie le serveur comme étant "hôte1.exemple.com", auquel cas vous souhaitez que ce soit le nom auquel les clients se connectent.

Utiliser dnsmasq rend cela vraiment facile. http://www.thekelleys.org.uk/dnsmasq/doc.html Agit en tant que serveur DNS mais obtient des réponses du serveur DNS local. La bonne chose est que vous pouvez remplacer des enregistrements de domaine unique sans jouer avec les fichiers de zone

En fait, il existe une autre façon de procéder, même si elle est légèrement différente. J'ai la même situation, j'ai un domaine qui est utilisé en externe et en interne, et j'ai des hôtes externes statiques et dynamiques. Les seuls réellement douloureux sont les dynamiques externes. La solution n'est peut-être pas la plus élégante, mais peut être mise en œuvre avec un petit script. La plupart du temps, je fais mon propre script DNS dynamique avec l'API de mon fournisseur DNS dynamique, je lance ce script par cron toutes les 5 minutes:

1) obtenir mon adresse IP externe. cela a-t-il changé? sans issue.

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

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

4) redémarrer la liaison.

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