Errore durante il debug della risoluzione DNS

Sto eseguendo il debug di un errore di risoluzione DNS per il dominio auth.otc.t-systems.comcon il server di Cloudflare, ma mi sono bloccato. La cosa strana è che la ricerca ha esito positivo / negativo a seconda della macchina che esegue la query, ma non riesco a capire dove differisce la configurazione.

L'errore è sempre con il seguente messaggio: server can't find auth.otc.t-systems.com: SERVFAIL

1.1.1.1 è il DNS di Cloudflare.

Quello che ho provato finora:

In esecuzione nslookup auth.otc.t-systems.com 1.1.1.1su varie macchine:
- Non funziona sulla mia macchina con Internet da lavoro e da casa (tuttavia riesce in entrambi i casi con il DNS di Google).
- Non funziona su una macchina dei colleghi con Internet di lavoro.
- Succede in una sessione ssh su un server remoto.
Ora suppongo che ci sia una strana configurazione sul nostro lavoro internet, che fa fallire la ricerca. Tuttavia non so cosa dovrei cercare e ho anche trovato alcuni servizi online nslookup che falliscono:
- Errore: 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
- Opere: http://www.kloth.net/services/nslookup.php

Qualche suggerimento su come posso eseguire ulteriormente il debug?

networking domain-name-system

— Thomas Obermüller
fonte

Hai provato anche con 1.0.0.1o se hai IPv6 2606:4700:4700::1111e anche 2606:4700:4700::1001loro sono tutti CloudFlare. Guarda anche blog.cloudflare.com/fixing-reachability-to-1-1-1-1-globally e il suo ultimo paragrafo che fornisce modi per segnalare il problema.

— Patrick Mevzek,

Risposte:

Prova a usare dig. Venti anni fa hanno cercato di deprecare nslookup, ma ora è saldamente radicato nella memoria muscolare ed è impossibile liberarsene, ma scavare è di gran lunga superiore. Per esempio.

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

Traccia la risoluzione per te e puoi vedere dove differiscono.

— Sirch
fonte

Grazie, non lo sapevo di nslookup. Ora ho provato il comando dig e stranamente restituisce l'ip corretto sulla mia macchina. Ho pubblicato l'output del comando sia sulla mia macchina che sulla macchina locale qui gist.github.com/thomas88/600d367387505a13223a5270c89eedda . Qualunque sia lo scavo diverso, il mio browser (Chrome su Mac) sembra essere più in linea con nslookup: non è in grado di risolvere l'indirizzo.

— Thomas Obermüller,

Non c'è motivo di aspettarsi risultati diversi tra dige nslookupper questa query. Tuttavia, poiché si 1.1.1.1tratta di un indirizzo anycast, il risultato può variare in base al server da cui viene eseguita la query.

— Kasperd,

Chrome, essere un client Web potrebbe reindirizzarti. L'intestazione http ... curl -I <la pagina Web che stai tentando di raggiungere> rivela qualcosa sull'inoltro?

— Sirch,

Qual è il punto di usare entrambi +tracee @1.1.1.1? Sei sicuro di capire come funzionano insieme queste opzioni?

— Barmar,

Sì, sono certo di capire come funzionano insieme. Il punto di usare @ <indirizzo> sarebbe specificare i server DNS che il suo client sta usando nelle due posizioni. Nell'esempio fornito, è cloudflare, ma se un altro client utilizza un server DNS diverso, verrebbe specificato lì. Ad esempio, dove mi trovo, l'indirizzo del server in resolv.conf è di tipo aziendale, ma posso ancora risolvere dall'1.1.1.1

— Sirch,

Le persone della rete hanno usato per 1.1.1.1 anni in sostituzione di un altro indirizzo privato in interfacce casuali di AP switch / router. (Mi trovo in una posizione in questo momento in cui l'indirizzo IP pubblico delle centinaia di AP wireless è 1.1.1.1)

Scommetto che i miei soldi con le macchine che non sono in grado di parlare con Cloufare 1.1.1.1 di avere un percorso (immediato) per tale interfaccia.

Ad esempio, nel mio caso, 1.1.1.1 mi sta fornendo il mio indirizzo 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
fonte

Questo è il motivo per cui RFC 3849 e RFC 5737 devono essere rigorosamente applicati.

— Kasperd,

"Troppo basso" è una base difficile per determinare qualsiasi cosa, però. Cloudflare ha molti PoP. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=1.30 msè il mio RTT per la cosa reale.

— Håkan Lindqvist,

@ HåkanLindqvist Il vostro valore non sembra un ritardo troppo basso per una connessione esterna .... ma sì, non è una metrica affidabile.

— Rui F Ribeiro,

@RuiFRibeiro La latenza sembra giusta per la connettività nella stessa città senza alcun collegamento ad alta latenza coinvolto. (Traceroute mostra 4 indirizzi all'interno del mio ISP, un indirizzo Cloudflare in uno scambio internet nella mia città, quindi 1.1.1.1.)

— Håkan Lindqvist

Sembra che posso raggiungere il DNS di Cloudflare, solo che non riesce per il dominio per me. Ho eseguito nslookup per auth.otc.t-systems.come serverfault.com. Ecco il risultato di tcpdump: gist.github.com/thomas88/03acc781f45c9427863b1876c75acb4d

— Thomas Obermüller