¿Dig devuelve "estado: RECHAZADO" para consultas externas?

14

Parece que no puedo entender por qué mi DNS no funciona correctamente, si ejecuto dig desde el servidor de nombres funciona correctamente:

# dig ungl.org

; <<>> DiG 9.5.1-P2.1 <<>> ungl.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24585
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; QUESTION SECTION:
;ungl.org.                      IN      A

;; ANSWER SECTION:
ungl.org.               38400   IN      A       188.165.34.72

;; AUTHORITY SECTION:
ungl.org.               38400   IN      NS      ns.kimsufi.com.
ungl.org.               38400   IN      NS      r29901.ovh.net.

;; ADDITIONAL SECTION:
ns.kimsufi.com.         85529   IN      A       213.186.33.199

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Mar 13 01:04:06 2010
;; MSG SIZE  rcvd: 114

pero cuando lo ejecuto desde otro servidor en el mismo centro de datos que recibo:

# dig @87.98.167.208 ungl.org

; <<>> DiG 9.5.1-P2.1 <<>> @87.98.167.208 ungl.org
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 18787
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ungl.org.                      IN      A

;; Query time: 1 msec
;; SERVER: 87.98.167.208#53(87.98.167.208)
;; WHEN: Sat Mar 13 01:01:35 2010
;; MSG SIZE  rcvd: 26

mi archivo de zona para este dominio es

$ttl 38400
ungl.org.       IN  SOA r29901.ovh.net. mikey.aol.com. (
                201003121
                10800
                3600
                604800
                38400 )
ungl.org.       IN  NS  r29901.ovh.net.
ungl.org.       IN  NS  ns.kimsufi.com.
ungl.org.       IN  A   188.165.34.72
localhost.      IN  A   127.0.0.1
www             IN  A   188.165.34.72

y el named.conf.options es el predeterminado:

options {
    directory "/var/cache/bind";

    // If there is a firewall between you and nameservers you want
    // to talk to, you may need to fix the firewall to allow multiple
    // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

    // If your ISP provided one or more IP addresses for stable 
    // nameservers, you probably want to use them as forwarders.  
    // Uncomment the following block, and insert the addresses replacing 
    // the all-0's placeholder.

    // forwarders {
    //  0.0.0.0;
    // };

    auth-nxdomain no;    # conform to RFC1035
    listen-on-v6 { ::1; };
    listen-on { 127.0.0.1; };
    allow-recursion { 127.0.0.1; };
};

named.conf.local:

//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
// include "/etc/bind/zones.rfc1918";

zone "eugl.eu" {
         type master;
         file "/etc/bind/eugl.eu";
         notify no;
};


zone "ungl.org" {
         type master;
         file "/etc/bind/ungl.org";
         notify no;
};

El servidor ejecuta Ubuntu 9.10 y Bind 9, si alguien puede arrojar algo de luz sobre esto por mí, ¡me haría muy feliz!

Gracias


fuente
¿Cómo se ve su sección de "opciones" de la configuración de enlace en el servidor que no se comporta? Por defecto en ubuntu, creo que todo está en /etc/bind/named.conf.options
Cory J
He actualizado la pregunta, todavía no he cambiado nada en las opciones
1
¿Qué tal la definición de zona en named.conf.local?
ktower
Añadido a la publicación principal

Respuestas:

18

aunque puedo estar desenterrando un hilo antiguo, lo estoy haciendo porque este es uno de los resultados más relevantes al hacer una búsqueda en Google de "estado de consulta rechazado".

En mi caso particular, descubrí que tenía que incluir allow-query { any; };en cada definición de zona en named.conf.

w00t
fuente
¡Eres mi ángel salvador! Muchas gracias
codezombie
5

Solo de un vistazo rápido me parece que no está configurado para escuchar al resto del mundo debido a listen-on { 127.0.0.1; };. Deberá agregar la dirección IP adecuada allí.

John Gardeniers
fuente
Cambié esto a la dirección IP de Internet del servidor (188.165.34.72) y volví a cargar el enlace, pero sigo recibiendo el mismo mensaje rechazado
1
¿Hay un firewall local en esa máquina? Es posible que deba abrir los puertos (53 TCP y UDP).
John Gardeniers
La URL parece estar funcionando ahora, pero aún muestra el mismo estado de rechazo de mi otro servidor
4

Hago lo mismo pero pongo la opción allow-query en named.conf.options


fuente
1

NOERROR cuando no está acompañado por un registro de recursos (RR) significa que no existe tal registro, por lo que cuando obtiene una respuesta NOERROR y no 'record' al establecer "versión" en "none", entonces está funcionando como se esperaba.

También hay una allow-querydeclaración de configuración con BIND9, sin embargo, creo que el valor predeterminado es permitir consultas desde cualquier lugar.

ZaphodB
fuente
1

Tuve exactamente el mismo problema (estado de excavación NOERROR localmente, estado de excavación RECHAZADO desde el exterior), y la solución fue cambiar los clientes coincidentes de "localhost" (que es el valor predeterminado para la instalación de enlace) a "cualquiera" (más tarde puedo averiguar cuál es la IP exacta de mi proveedor de nombres de dominio y restringirla a esa IP específica por razones de seguridad). Además, cambié el nombre de la vista de local_something a predeterminado. El nombre realmente no importa.

view default {
        match-clients      { any; };
        match-destinations { any; };
        include "/etc/named.rfc1912.zones";
};

Ese fue realmente el problema con este negocio de "estado rechazado". Justo después de cambiar el parámetro match-clients, mis consultas dig @ 12.34.56.78 mydomain.com comenzaron a resolverse con el estado NOERROR, y el proveedor de nombres de dominio (godaddy) almacenó en caché el registro del servidor de nombres. Como mis archivos de zona ya estaban configurados correctamente, el nombre de dominio se hizo visible instantáneamente en Internet.

Sin embargo, estuve golpeando mi cabeza contra la pared durante bastante tiempo para resolver esto.

caballo alado
fuente
1
¿Podría aclarar qué archivo en qué computadora modificó?
Alexey
1

Tuve que ingresar una referencia explícita para la red que deseaba permitir la recursividad. Especificar "cualquiera" no ayudó. Por defecto (Umbutu Server 15) no había ninguna entrada para esto en el /etc/bind/named.conf.optionsarchivo.

recursion yes;  << needed to add this but did not resolve greater prob
allow-recursion { any; }; << this did not work
allow-recursion { 10.1.0.0/16; }; << this did the trick
Iradw
fuente
0

¿Estás seguro de que estás enviando las consultas al lugar correcto?

Su servidor en 188.165.34.72 ( r29901.ovh.net) está ejecutando BIND 9.5.1-P2.1: responde una consulta dig @ip version.bind ch txtcomo se esperaba con esa cadena de respuesta.

Sin embargo, la dirección IP que citó anteriormente devuelve un NOTIMPLerror, a pesar de que no hay nada en su archivo de configuración citado sobre los *.bindpseudo-registros y BIND requiere una configuración explícita para deshabilitarlos.

Alnitak
fuente
NOTIMPL no está implementado? ¿Por qué tendría características que no están implementadas habilitadas por defecto?
Si es BIND, hay una opción llamada "versión" que le dice que envíe un valor especificado por el usuario a esa consulta, o "none" para deshabilitar la función. Si la opción no está especificada, devuelve el número de versión real. No ha mencionado esa opción, lo que me hace sospechar que no está hablando con el servidor correcto. Ver isc.org/software/bind/documentation/arm95
Alnitak
Lo he comprobado aún más: en mi cuadro MacOSX con bind 9.6.0, establecer "version" en "none" devuelve NOERRORy no el NOTIMPLerror que veo desde esa IP.
Alnitak
0

Porque permite la recursividad solo desde su máquina local.

Si desea permitir agregar la dirección IP adecuada y necesita cambiar el valor de escucha en cualquier adaptador de su máquina local o poner la dirección IP de la interfaz de la máquina local:

listen-on { any;} or x.x.x.x;
Tamirat
fuente