☰

El DNS secundario no responde a la excavación

tag-icon • tag-icon domain-name-system bind
El DNS secundario no responde a la excavación

Somos nuevos en DNS. Estamos intentando configurar un servidor DNS secundario usando Bind & CentOS para un servidor primario existente (por ejemplo: 142.250.192.110).

La configuración de nuestro servidor secundario es la siguiente:

    listen-on port 53 { 127.0.0.1; any; };
        listen-on-v6 port 53 { ::1; any; };
        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";
        recursing-file  "/var/named/data/named.recursing";
        secroots-file   "/var/named/data/named.secroots";
        allow-query     { any; };

    
zone "example.com" IN {
        type slave;
        masters {  142.250.192.110; };
        file "slaves/example.forward";
};
zone "192.250.142.in-addr.arpa" IN {
        type slave;
        masters {  142.250.192.110; };
        file "slaves/example.reverse";
};

Cuando ejecutamos dig @127.0.0.1 host1.example.comrecibimos una respuesta adecuada. Cuando ejecutamos con IP local (servidor secundario), dig @192.168.1.10 host1.example.comobtenemos una respuesta adecuada.

Pero cuando ejecutamos un comando con IP pública/nombre de host de un servidor secundario, por ejemplo: dig @dns2.example.com host1.example.comrecibimos errores como;; connection timed out; no servers could be reached

Sugiera algo de ayuda para resolver este problema. Gracias de antemano por su valioso tiempo y ayuda.

Alguna información y detalles de solución de problemas (la IP y el nombre de host no son originales):

DNS primario: 142.250.192.110 (dns1.example.com)

DNS secundario: 192.168.1.10 (IP local), 142.250.192.220 (dns2.example.com)

nslookup dns2.example.com

Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   dns2.example.com
Address: 142.250.192.220

dig @127.0.0.1 host1.example.com- Éxito

dig @192.168.1.10 host1.example.com- Éxito

dig @142.250.192.220 host1.example.com- Fallido.

dig @dns2.example.com host1.example.com- Fallido.

tcpdumpmuestra la transferencia de paquetes, con dig @127.0.0.1y dig @192.168.1.10. pero muestraSIN transferencia de paquetes, con dig @142.250.192.220y dig @dns2.example.com.

Para verificar si el firewall está bloqueando el puerto 53, probamos el puerto con tcpdump y tcpdump muestra la transferencia de paquetes cuando lo hizo.telnet 142.250.192.220 53

Nota:Tenemos un firewall que hace NAT IP local con IP pública. Estamos esperando la respuesta del equipo de red, si el Firewall está bloqueando esta solicitud de excavación.

Respuesta1

Siempre verifique los registros en ambos servidores. Verifique que el esclavo haya podido recuperar la zona. Un paso es hacer la transferencia manualmente usando dig @192.168.1.10 axfr example.comdesde el esclavo, donde @192.168.1.10está el maestro en la configuración del esclavo.

allow-transfer { };Podría ser necesario en el maestro para permitir que el esclavo busque la zona. Nuevamente, todo esto está en los registros.

Siempre verifique primero el acceso local. Verifique con netstat -anp si el servidor está escuchando correctamente y verifique nuevamente los registros. y como último recurso, pruebe tcpdump para ver qué paquetes van a dónde y si hay alguna respuesta.

información relacionada