Pregunta ¿Cómo puedo resolver 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) es irresoluble desde algunas redes, y resuelve 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 logra resolver mi dominio, pero parece que no puedo averiguar dónde. Me desnudé el dig página de manual para las opciones que podrían ayudar, pero no encontraron nada particularmente útil.

Estoy en Namecheap, tanto como registrador de dominios como de hosting 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?


13
2018-04-16 22:51


origen


Gracias por proporcionar el nombre del dominio. Problemas como este son extremadamente difíciles de solucionar por nosotros en Serverfault sin esa información. - Andrew B
@AndrewB oh, lo sé. De nada, confia en mi :) - 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 las exitosas usaban IPV4. A menudo (obviamente, no en este caso) esto sugiere una mala configuración de IPV6, y puede ser útil usar explícitamente direcciones IPV [4/6] numéricas de los servidores de nombres en lugar de alias. - Guntram Blohm
@Guntram Mientras tengamos en cuenta que obtuvimos una respuesta desde El servidor de nombres, lo que significa que tenemos conectividad. a El servidor DNS al menos. Solo quiero asegurarnos de que la gente no se aleje de eso con la impresión incorrecta ...SERVFAIL puede indicar un problema en sentido ascendente, pero aún así indica un paquete de respuesta. - Andrew B
@GuntramBlohm Estás en algo. strugee.net tiene cinco registros de NS, pero no AAAA solo registros de pegamento A registros de pegamento. Lo peor es que esos cinco. A pegar registros apunta a sólo 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 para comenzar, pero la única respuesta real aquí es que necesita saber cómo pensar como un servidor DNS recursivo. Dado que hay numerosas configuraciones erróneas en la capa autorizada que pueden resultar en una inconsistente SERVFAIL, necesitas un profesional de DNS o herramientas de validación en línea.

De todos modos, el objetivo no es arrepentirte de ayudarte, pero quería asegurarme de que entiendes que no hay una respuesta concluyente para esa pregunta.


En tu caso particular, noté que strugee.net Parece ser una zona firmada con DNSSEC. Esto es evidente por la presencia de la DS y RRSIG Registros en la cadena de referidos:

# 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 frecuentemente utilizada para este propósito, y confirma que de hecho hay problemas. El rojo enojado en la imagen sugiere que tienes un problema, pero en lugar de pasar el ratón sobre todo, podemos expandirlo. 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 caducado 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 eliminando su dominio, y para los que no lo hacen, es como siempre.


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

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

24
2018-04-16 23:40



Vaya, yo tenía stugee.net en 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 está viendo que los servidores de nombres autorizados responden correctamente, debe hacer un seguimiento de toda la cadena de resolución de DNS. Esto es, bajar 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 usted está haciendo lo mismo que debería hacer su sistema de resolución de DNS. Por lo tanto, debería estar obteniendo las mismas respuestas que las anteriores en su servidor de 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 de Digital Ocean que falla. Revisar su /etc/resolv.conf e intente consultar el servidor DNS secundario. Si el secundario funciona, simplemente cambie el orden de los resolutores e intente nuevamente.


5
2018-04-16 23:14