Error de resolución de depuración de DNS

Estoy depurando un error de resolución de DNS para el dominio auth.otc.t-systems.comcon el servidor de Cloudflare, pero me atasqué. Lo extraño es que la búsqueda tiene éxito / falla dependiendo de la máquina que ejecuta la consulta, pero no puedo entender dónde difiere la configuración.

La falla siempre es con el siguiente mensaje: server can't find auth.otc.t-systems.com: SERVFAIL

1.1.1.1 es el DNS de Cloudflare.

Lo que he probado hasta ahora:

Corriendo nslookup auth.otc.t-systems.com 1.1.1.1en varias máquinas:
- Falla en mi máquina con Internet en el trabajo y el hogar (sin embargo, tiene éxito con el DNS de Google en ambos casos).
- Falla en una máquina de colegas con internet de trabajo.
- Tiene éxito en una sesión ssh a un servidor remoto.
Ahora supondría que hay una configuración extraña en nuestro trabajo en Internet, que hace que la búsqueda falle. Sin embargo, no sé qué debo buscar y también he encontrado algunos servicios nslookup en línea que también fallan:
- Falla: https://network-tools.com/nslook/Default.asp?domain=auth.otc.t-systems.com&type=1&server=1.1.1.1&class=1&port=53&timeout=5000&go.x=21&go.y=13
- Obras: http://www.kloth.net/services/nslookup.php

¿Alguna pista de cómo puedo depurar esto?

networking domain-name-system

— Thomas Obermüller
fuente

¿También probaste con 1.0.0.1o si tienes IPv6 2606:4700:4700::1111y 2606:4700:4700::1001, también son todos CloudFlare? También mire blog.cloudflare.com/fixing-reachability-to-1-1-1-1-globally y su último párrafo que brinda formas de informar el problema.

— Patrick Mevzek

Respuestas:

Intenta usar dig. Hace veinte años intentaron desaprobar nslookup, pero ahora está firmemente arraigado en la memoria muscular y es imposible deshacerse de él, pero cavar es muy superior. Por ejemplo.

dig +trace auth.otc.t-systems.com @1.1.1.1

Trazará la resolución por completo para usted y podrá ver en qué difieren.

— Sirch
fuente

Gracias, no sabía eso de nslookup. Ahora probé el comando de excavación y, extrañamente, devuelve la IP correcta en mi máquina. He publicado el resultado del comando tanto en mi máquina como en la máquina local aquí gist.github.com/thomas88/600d367387505a13223a5270c89eedda . Cualquiera que sea la excavación, mi navegador (Chrome en Mac) parece estar más en línea con nslookup: no puede resolver la dirección.

— Thomas Obermüller

No hay ninguna razón para esperar resultados diferentes entre digy nslookuppara esta consulta. Sin embargo, dado que se 1.1.1.1trata de una dirección de difusión ilimitada, el resultado puede diferir según el servidor en el que finaliza la consulta.

— Kasperd

Chrome, ser un cliente web podría estar redirigiéndote. ¿El encabezado http ... curl -I <la página web que está intentando acceder> revela algo sobre el reenvío?

— Sirch

¿Cuál es el punto de usar ambos +tracey @1.1.1.1? ¿Seguro que comprende cómo funcionan juntas estas opciones?

— Barmar

Sí, estoy seguro de entender cómo funcionan juntos. El punto de usar @ <dirección> sería especificar los servidores dns que su cliente está usando en las dos ubicaciones. En el ejemplo dado, es cloudflare, pero si otro cliente usa un servidor dns diferente, se especificará allí. Por ejemplo, donde estoy, la dirección del servidor en resolv.conf es una empresa, pero aún puedo resolver desde 1.1.1.1

— Sirch

Las personas de la red lo han usado durante las edades 1.1.1.1 como reemplazo de otra dirección privada en interfaces aleatorias de conmutadores / enrutadores AP. (Estoy en una ubicación en este momento donde la dirección IP pública de los cientos de AP inalámbricos es 1.1.1.1)

Apuesto a que mi dinero en las máquinas no puede hablar con Cloufare's 1.1.1.1 que tiene una ruta (inmediata) para dicha interfaz.

Por ejemplo, en mi caso, 1.1.1.1 me está dando mi dirección IP:

$ sudo tcpdump -i any -n host 1.1.1.1 and port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
13:11:51.037186 IP 1.1.1.1.67 > 10.x.x.x.68: BOOTP/DHCP, Reply, length 296
13:11:51.037250 IP 1.1.1.1.67 > 10.x.x.x.68: BOOTP/DHCP, Reply, length 296

— Rui F Ribeiro
fuente

Es por eso que RFC 3849 y RFC 5737 deben aplicarse rigurosamente.

— Kasperd

Sin embargo, "demasiado bajo" es una base difícil para determinar cualquier cosa. Cloudflare tiene muchos PoP. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=1.30 mses mi RTT a lo real.

— Håkan Lindqvist

@ HåkanLindqvist Su valor no parece un retraso demasiado bajo para una conexión externa .... pero sí, no es una métrica fiable.

— Rui F Ribeiro

La latencia de @RuiFRibeiro parece adecuada para la conectividad de la misma ciudad sin ningún vínculo de alta latencia. (Traceroute muestra 4 direcciones dentro de mi ISP, una dirección de Cloudflare en un intercambio de Internet en mi ciudad, luego 1.1.1.1.)

— Håkan Lindqvist

Parece que puedo alcanzar el DNS de Cloudflare, solo que falla para el dominio para mí. He ejecutado nslookup para auth.otc.t-systems.comy serverfault.com. Aquí está el resultado de tcpdump: gist.github.com/thomas88/03acc781f45c9427863b1876c75acb4d

— Thomas Obermüller