6 votes

Comment configurer BIND pour qu'il transmette les requêtes DNS inversées à un autre serveur DNS ?

J'ai deux domaines dans mon environnement. L'un d'eux est un domaine Active Directory pour 'myproductionlab.local' à 10.60.0.0/16.
Ensuite, j'ai une boîte Debian qui utilise bind9 pour un domaine, 'mytestlab.local'.
J'ai ajouté une entrée dans mon named.conf.local :

zone "60.10.in-addr.arpa" {
        type forward;
        forwarders {
                10.60.10.5;
                10.60.10.7;
                10.60.10.9;

        };
};
zone "myproductionlab.local" {
        type forward;
        forwarders {
                10.60.10.5;
                10.60.10.7;
                10.60.10.9;

        };
};

la boîte debian est configurée pour avoir 127.0.0.1 pour la résolution DNS et il n'y a pas de forwarders configurés globalement.

La résolution du nom se résout très bien :

nslookup mymachine.myproductionlab.local  
Server:     127.0.0.1
Address:    127.0.0.1#53
Non-authoritative answer:
Name:   mymachine.myproductionlab.local
Address: 10.60.10.200

et du journal des requêtes :

client 127.0.0.1#36076 (mymachine.myproductinlab.local): query: mymachine.myproductionlab.local IN A + (127.0.0.1)

mais le reverse DNS n'est pas transmis :

nslookup 10.60.10.200
Server:     127.0.0.1
Address:    127.0.0.1#53
** server can't find 200.10.60.10.in-addr.arpa: NXDOMAIN

et du journal des requêtes :

client 127.0.0.1#40295 (200.10.60.10.in-addr.arpa): query: 200.10.60.10.in-addr.arpa IN PTR + (127.0.0.1)

J'ai essayé un tas de variations de zones :

zone "60.10.in-addr.arpa" {
zone "10.60.10.in-addr.arpa" {
zone "200.10.60.10.in-addr.arpa" {

J'ai également essayé de tcpdump et 0 paquet est capturé pour nslookup 10.60.10.200 mais des paquets sont capturés pour le nom.

lorsque je spécifie manuellement le serveur DNS dans nslookup, cela fonctionne également très bien :

nslookup 10.60.10.200 10.60.10.5
Server:     10.60.10.5
Address:    10.60.10.5#53
200.10.60.10.in-addr.arpa   name = mymachine.myproductionlab.local.

0 votes

Je suppose que vous avez rechargé la zone après vos modifications et fait une vérification de namedconf.

0 votes

Oui, j'ai rechargé à chaque fois et named-checkconf sur toutes les configurations ne rapporte aucune erreur.

1 votes

Quel est le résultat de dig -x 10.60 10.200

5voto

eli Points 11

La sortie de DIG m'a permis de découvrir le problème.

dig -x 10.60.10.200

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> -x 10.60.10.200
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26824
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;200.10.60.10.in-addr.arpa. IN  PTR

;; AUTHORITY SECTION:
10.in-addr.arpa.    86400   IN  SOA localhost. root.localhost. 1 604800     86400 2419200 86400

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 21 13:46:50 CST 2017
;; MSG SIZE  rcvd: 104

10.in-addr.arpa. a été défini dans zones.rfc1918 qui pointe vers db.empty
Dans les versions précédentes de bind, le fichier zones.rfc1918 n'était pas inclus par défaut et même si j'ai vérifié toutes les configurations, rien n'indique à bind de lire ce fichier. Il doit donc être lu par défaut sur cette version ou il est configuré ailleurs.

dpkg -l | grep bind
ii  bind9                                1:9.9.5.dfsg-9+deb8u6            amd64        Internet Domain Name Server
ii  bind9-host                           1:9.9.5.dfsg-9+deb8u6        amd64        Version of 'host' bundled with BIND 9.X
ii  bind9utils                           1:9.9.5.dfsg-9+deb8u6        amd64        Utilities for BIND
ii  libbind9-90                          1:9.9.5.dfsg-9+deb8u6        amd64        BIND9 Shared Library used by BIND

0 votes

Dans le cas où vous utilisez SystemD resolved, vous devez spécifier le serveur réel que resolved interroge - vérifiez la sortie de resolvectl status | grep "Current DNS Server" pour obtenir cette IP. Ensuite, avec dig : dig @127.0.0.1 -x 10.60.10.200 . Le processus de résolution interne ne retournera jamais une réponse faisant autorité.

5voto

Stephan Points 245

Juste au cas où quelqu'un tomberait dessus Pour les versions récentes de Bind9 (au moins sur Debian), il n'est pas suffisant de désactiver la fonction

include "/etc/bind/zones.rfc1918";

car Bind9 les crée alors automatiquement. Au lieu de cela,

empty-zones-enable no;

est nécessaire dans votre section d'options ( named.conf.options ).

Voir https://deepthought.isc.org/article/AA-00800/0/Automatic-empty-zones-including-RFC-1918-prefixes.html .

1voto

Jacob Evans Points 7455

Nslookup n'est pas très utile, quelle est la sortie de dig -x 10.60 10.200

qui a montré que vos plages privées par défaut étaient activées et capturaient vos demandes en tant qu'autorité.

supprimez-les ou modifiez-les pour être plus précis.

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