¿Cómo puedo resolver los problemas de DNS en algún lugar en medio de la recursión?

Tengo un problema realmente extraño con mi DNS. Mi nombre de dominio ( strugee.net) no se puede resolver desde algunas redes y se puede resolver desde otras.

Por ejemplo, en mi red doméstica (la misma red en la que está el servidor):

% dig strugee.net

; <<>> DiG 9.10.3-P4 <<>> strugee.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10086
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;strugee.net.           IN  A

;; ANSWER SECTION:
strugee.net.        1800    IN  A   216.160.72.225

;; Query time: 186 msec
;; SERVER: 205.171.3.65#53(205.171.3.65)
;; WHEN: Sat Apr 16 15:42:36 PDT 2016
;; MSG SIZE  rcvd: 56

Sin embargo, si inicio sesión en un servidor que tengo en Digital Ocean, el dominio no se resuelve:

% dig strugee.net      

; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> strugee.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58551
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;strugee.net.           IN  A

;; Query time: 110 msec
;; SERVER: 2001:4860:4860::8844#53(2001:4860:4860::8844)
;; WHEN: Sat Apr 16 18:44:25 EDT 2016
;; MSG SIZE  rcvd: 40

Pero , ir directamente a los servidores de nombres autorizados funciona bien:

% dig @dns1.registrar-servers.com strugee.net   

; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> @dns1.registrar-servers.com strugee.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30856
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;strugee.net.           IN  A

;; ANSWER SECTION:
strugee.net.        1800    IN  A   216.160.72.225

;; AUTHORITY SECTION:
strugee.net.        1800    IN  NS  dns3.registrar-servers.com.
strugee.net.        1800    IN  NS  dns4.registrar-servers.com.
strugee.net.        1800    IN  NS  dns2.registrar-servers.com.
strugee.net.        1800    IN  NS  dns1.registrar-servers.com.
strugee.net.        1800    IN  NS  dns5.registrar-servers.com.

;; Query time: 3 msec
;; SERVER: 216.87.155.33#53(216.87.155.33)
;; WHEN: Sat Apr 16 18:46:36 EDT 2016
;; MSG SIZE  rcvd: 172

Está bastante claro que hay un problema con alguna red grande en algún lugar que no puede resolver mi dominio, pero parece que no puedo entender dónde. Leí la página del digmanual buscando opciones que pudieran ayudar, pero no encontré nada particularmente útil.

Estoy en Namecheap como registrador de dominios y como alojamiento de DNS. Tengo la opción DNSSEC activada. No he realizado ningún cambio en mi configuración de DNS recientemente.

¿Cómo puedo depurar este problema y encontrar el servidor de nombres ofensivo?

domain-name-system recursive

— Strugee
fuente

Gracias por proporcionar el nombre del dominio. Problemas como este son extremadamente difíciles de resolver por nosotros en Serverfault sin esa información.

— Andrew B

@ AndrewB oh, lo sé. De nada, confía en mí :)

— strugee

La respuesta de @ AndrewB tiene sentido y me parece correcta. Sin embargo, antes de leerlo, noté que su consulta fallida usaba un servidor de nombres IPV6, mientras que los exitosos usaban IPV4. A menudo (obviamente, no en este caso), esto sugiere una mala configuración de IPV6, y puede ser útil utilizar explícitamente direcciones IPV numéricas [4/6] de los servidores de nombres en lugar de alias.

— Guntram Blohm apoya a Monica el

@Guntram Siempre que tengamos en cuenta que recibimos una respuesta del servidor de nombres, lo que significa que tenemos conectividad al servidor DNS al menos. Solo quiero asegurarme de que las personas no se alejen de eso con la impresión incorrecta ... SERVFAILpuede indicar un problema ascendente, pero aún indica un paquete de respuesta.

— Andrew B

@GuntramBlohm Estás en algo. strugee.nettiene cinco registros NS, pero no hay AAAAregistros de cola, solo Aregistros de cola. Lo peor es que esos cinco Aregistros de pegamento apuntan a solo dos direcciones IP diferentes. Eso parece una configuración bastante frágil. Incluso si no es la causa raíz del problema en cuestión, es algo a tener en cuenta.

— kasperd

Respuestas:

¿Cómo puedo depurar este problema y encontrar el servidor de nombres ofensivo?

daxd5 ofreció algunos buenos consejos iniciales, pero la única respuesta real aquí es que necesita saber cómo pensar como un servidor DNS recursivo. Dado que existen numerosas configuraciones erróneas en la capa autoritativa que pueden dar lugar a una inconsistencia SERVFAIL, necesita un profesional de DNS o herramientas de validación en línea.

De todos modos, el objetivo no es evitar ayudarlo, pero quería asegurarme de que comprenda que no hay una respuesta concluyente a esa pregunta.

En su caso particular, noté que strugee.netparece ser una zona firmada con DNSSEC. Esto es evidente por la presencia de los registros DSy RRSIGen la cadena de referencia:

# dig +trace +additional strugee.net
<snip>
strugee.net.            172800  IN      NS      dns2.registrar-servers.com.
strugee.net.            172800  IN      NS      dns1.registrar-servers.com.
strugee.net.            172800  IN      NS      dns3.registrar-servers.com.
strugee.net.            172800  IN      NS      dns4.registrar-servers.com.
strugee.net.            172800  IN      NS      dns5.registrar-servers.com.
strugee.net.            86400   IN      DS      16517 8 1 B08CDBF73B89CCEB2FD3280087D880F062A454C2
strugee.net.            86400   IN      RRSIG   DS 8 2 86400 20160423051619 20160416040619 50762 net. w76PbsjxgmKAIzJmklqKN2rofq1e+TfzorN+LBQVO4+1Qs9Gadu1OrPf XXgt/AmelameSMkEOQTVqzriGSB21azTjY/lLXBa553C7fSgNNaEXVaZ xyQ1W/K5OALXzkDLmjcljyEt4GLfcA+M3VsQyuWI4tJOng184rGuVvJO RuI=
dns2.registrar-servers.com. 172800 IN   A       216.87.152.33
dns1.registrar-servers.com. 172800 IN   A       216.87.155.33
dns3.registrar-servers.com. 172800 IN   A       216.87.155.33
dns4.registrar-servers.com. 172800 IN   A       216.87.152.33
dns5.registrar-servers.com. 172800 IN   A       216.87.155.33
;; Received 435 bytes from 192.41.162.30#53(l.gtld-servers.net) in 30 ms

Antes de continuar, debemos verificar si la firma es válida o no. DNSViz es una herramienta utilizada con frecuencia para este propósito, y confirma que efectivamente hay problemas . El rojo enojado en la imagen sugiere que tienes un problema, pero en lugar de pasar el mouse sobre todo, solo podemos expandir Avisos en la barra lateral izquierda:

RRSIG strugee.net/A alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/DNSKEY alg 8, id 16517: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/DNSKEY alg 8, id 16517: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/MX alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/NS alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/SOA alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/TXT alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
net to strugee.net: No valid RRSIGs made by a key corresponding to a DS RR were found covering the DNSKEY RRset, resulting in no secure entry point (SEP) into the zone. (216.87.152.33, 216.87.155.33, UDP_0_EDNS0_32768_4096)

El problema está claro: la firma en su zona ha expirado y las claves deben actualizarse. La razón por la que está viendo resultados inconsistentes es porque no todos los servidores recursivos tienen habilitada la validación DNSSEC. Los que validan están abandonando su dominio, y para los que no lo hacen, es lo de siempre.

Editar: se sabe que la infraestructura DNS de Comcast implementa la validación DNSSEC, y como uno de sus clientes, puedo confirmar que también estoy viendo una SERVFAIL.

$ dig @75.75.75.75 strugee.net | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2011

— Andrew B
fuente

Vaya, tuve stugee.neten la salida de excavación, que obviamente es un error tipográfico. La parte DNSSEC de este análisis se realizó con el nombre correcto.

— Andrew B

Si bien ve que los servidores de nombres autorizados responden correctamente, debe realizar un seguimiento de toda la cadena de resolución de DNS. Esto es, caminar por toda la jerarquía de DNS desde los servidores raíz hacia arriba.

$ dig net NS
;; ANSWER SECTION:
net.            172800  IN  NS  c.gtld-servers.net.
net.            172800  IN  NS  f.gtld-servers.net.
net.            172800  IN  NS  k.gtld-servers.net.
;; snipped extra servers given
$ dig @c.gtld-servers.net strugee.net NS
;; AUTHORITY SECTION:
strugee.net.        172800  IN  NS  dns2.registrar-servers.com.
strugee.net.        172800  IN  NS  dns1.registrar-servers.com.
;; snipped extra servers again

Básicamente, esto verifica que los servidores DNS públicos estén funcionando y que usted esté haciendo lo mismo que su resolución DNS debería estar haciendo. Por lo tanto, debería obtener las mismas respuestas que anteriormente en su servidor Digital Ocean a menos que haya algún problema con su resolución de DNS:

$ dig net NS
$ dig strugee.net NS
$ dig strugee.net

Si las dos primeras consultas fallan, es el DNS en el lado del Océano Digital que falla. Verifique su /etc/resolv.confe intente consultar el servidor DNS secundario. Si el secundario funciona, simplemente cambie el orden de los solucionadores e intente nuevamente.

— daxd5
fuente