5 votes

Le serveur ne peut pas trouver XXX.in-addr.arpa : NXDOMAIN

Je fais face à un problème lors de la configuration du DNS BIND affichant que le serveur ne peut pas trouver XXX.in-addr.arpa: NXDOMAIN lors de la vérification du reverse DNS!

Tout fonctionne sur la recherche DNS forward mais la recherche DNS reverse échoue. Voici mes fichiers de configuration:

named.conf

options {
         listen-on port 53 { 192.168.10.1; }; //      listen-on-v6 port 53 { ::1; };
         directory       "/var/named";
         dump-file       "/var/named/data/cache_dump.db";
         statistics-file "/var/named/data/named_stats.txt";
         memstatistics-file "/var/named/data/named_mem_stats.txt";
         allow-query     { any; };
         recursion no;
         allow-recursion {
         localhost;
         };

         dnssec-enable yes;
         dnssec-validation yes;
         dnssec-lookaside auto;

         /* Chemin de la clé ISC DLV */
         bindkeys-file "/etc/named.iscdlv.key";     anaged-keys-directory "/var/named/dynamic"; };

 logging {
         channel default_debug {
                 file "data/named.run";
                 severity dynamic;
         }; };

 zone "." IN {
         type hint;
         file "named.ca"; };

 include "/etc/named.rfc1912.zones"; include "/etc/named.root.key";

named.rfc1912.zones:

 acl trusted-servers  {
         192.168.10.1;  //ns2 };

 zone "johndeo.com" IN {
         type master;
         file "forward.zone";
         allow-update { none; };
         allow-transfer { trusted-servers; }; };

 zone "localhost" IN {
         type master;
         file "named.localhost";
         allow-update { none; }; }; zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa"$
         type master;
         file "named.loopback";
         allow-update { none; }; };

 zone "10.168.192.in-addr.arpa" IN {
         type master;
         file "reverse.zone";
         allow-update { none; }; };

 zone "0.in-addr.arpa" IN {
         type master;
         file "named.empty";
         allow-update { none; }; };

forward.zone

$TTL 86400 @ IN SOA  ns1.johndeo.com. root.ns1.johndeo.com. (
                                         8       ; serial
                                         86400   ; refresh,seconds
                                         7200    ; retry
                                         3600000 ; expire
                                         86400 ) ; minimum johndeo.com. IN A 192.168.10.1

johndeo.com.    IN NS ns1.johndeo.com. 
johndeo.com.    IN NS ns2.johndeo.com. 
johndeo.com.    IN MX 1 mail.johndeo.com.

ns1.johndeo.com. IN A 192.168.10.1 
ns2.johndeo.com. IN A 192.168.10.1

www IN CNAME johndeo.com. ftp IN CNAME johndeo.com.

mail IN A 192.168.10.1

reverse.zone

$ORIGIN 10.168.192.in-addr.arpa.
$TTL 14400
@       IN      SOA     www.johndeo.com.        admin.johndeo.com. (
                                        30      ; serial
                                        86400   ; refresh
                                        7200    ; retry
                                        3600000 ; expire
                                        86400 ) ; minimum
        IN      NS      ns1.johndeo.com.
        IN      NS      ns2.johndeo.com.

1     IN      PTR     ns1.johndeo.com.

nslookup FQDN in Server

nslookup ns1.johndeo.com
Server:         192.168.10.1
Address:        192.168.10.1#53

Name:   ns1.johndeo.com
Address: 192.168.10.1

nslookup in windows 7 cmd

C:\Windows\system32>nslookup 192.168.10.1
Server:
Address:  192.168.2.1

***  can't find 192.168.10.1

J'ai même utilisé " ipconfig /flushdns " pour vider le cache DNS.

nslookup IP on server

nslookup 192.168.10.1
Server:         192.168.10.1
Address:        192.168.10.1#53

1.10.168.192.in-addr.arpa    name = ns1.johndeo.com.

Host IP on server :

host 192.168.10.1
1.10.168.192.in-addr.arpa domain name pointer ns1.johndeo.com.

Je ne parviens pas à comprendre ce qui cause ce problème.

1 votes

Je suppose qu'il n'y a rien d'évident dans vos journaux? Vous pourriez augmenter le niveau de journalisation de BIND pour voir ce qui se passe réellement lors de la requête. Une chose à noter - votre client Windows résout à partir de 192.168.2.1 au lieu de 192.168.10.1 - que je suppose être votre DNS maître. Obtenez-vous le même résultat lorsque vous êtes pointé vers 192.168.10.1?

0 votes

@Sobrique oui même résultat J'ai également effectué une recherche de serveur nslookup sur l'IP qui résout reverse. Veuillez consulter l'IP de nslookup sur le serveur en sortie comme je l'ai mis à jour dans la question.

2 votes

Je voulais plutôt dire - étant donné que votre hôte Windows utilise un serveur de noms différent, est-ce que ce serait plutôt 192.168.2.1 qui ne fonctionne pas au lieu de 10.1?

4voto

Calle Dybedahl Points 2073

Votre autre machine ne sait pas magiquement qu'elle devrait interroger votre serveur de noms à propos de 1.10.168.192.in-addr.arpa. Elle demandera à un serveur récursif (ou se lancera éventuellement elle-même dans une récursion) de résoudre le nom en commençant par la racine, et cette récursion lui indiquera que l'ensemble de 168.192.in-addr.arpa. est géré par les serveurs de noms blackhole-1.iana.org et blackhole-2.iana.org. Vous pouvez deviner à partir de leurs noms ce que font réellement ces serveurs.

Si vous voulez que cette recherche inverse fonctionne, il ne suffit pas de configurer une zone pour les données inverses que vous souhaitez fournir. Vous devez également faire en sorte que les machines qui doivent voir ces informations interrogent votre serveur plutôt que l'arbre DNS global.

1 votes

Et comment exactement faites-vous ça?

0 votes

@staypuftman ... parce que c'est ainsi que fonctionne le DNS ? Une requête inverse pour une adresse IP signifie en fait une requête normale pour un enregistrement PTR sur le nom D.C.B.A.in-addr.arpa pour l'adresse IPv4 A.B.C.D (c'est similaire pour IPv6, avec juste un autre suffixe). Ainsi, pour résoudre cela, on commence à la racine et on récurs. À un moment donné, il demandera aux serveurs de noms pour 168.192.in-addr.arpa. qui sont ceux que Calle a donnés, et non ceux que l'OP essaye de mettre en place. Donc en effet, les clients doivent être configurés pour s'assurer d'utiliser ce serveur de noms spécifique pour cette requête.

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