Erro de resolução de DNS de depuração

Estou depurando um erro de resolução de DNS para o domínio auth.otc.t-systems.comcom o servidor do Cloudflare, mas fiquei preso. O estranho é que a pesquisa é bem-sucedida / falha, dependendo da máquina que executa a consulta, mas não consigo descobrir onde a configuração difere.

A falha é sempre com a seguinte mensagem: server can't find auth.otc.t-systems.com: SERVFAIL

1.1.1.1 é o DNS do Cloudflare.

O que eu tentei até agora:

Executando nslookup auth.otc.t-systems.com 1.1.1.1em várias máquinas:
- Ele falha na minha máquina com a Internet do trabalho e doméstica (no entanto, obtém êxito com o DNS do Google nos dois casos).
- Ele falha em uma máquina de colegas com trabalho na Internet.
- É bem-sucedido em uma sessão ssh para um servidor remoto.
Agora, eu assumiria que há alguma configuração estranha em nossa internet de trabalho, que causa falha na pesquisa. No entanto, não sei o que devo procurar e também encontrei alguns serviços de nslookup online que também falham:
- Falha: 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
- Trabalhos: http://www.kloth.net/services/nslookup.php

Alguma dica de como eu posso depurar ainda mais isso?

networking domain-name-system

— Thomas Obermüller
fonte

Você também tentou com 1.0.0.1ou se possui IPv6 2606:4700:4700::1111e 2606:4700:4700::1001todos eles também são CloudFlare. Consulte também blog.cloudflare.com/fixing-reachability-to-1-1-1-1-globally e seu último parágrafo, oferecendo maneiras de relatar o problema.

— Patrick Mevzek

Respostas:

Tente usar dig. Vinte anos atrás, eles tentaram depreciar a pesquisa, mas agora está firmemente enraizada na memória muscular e é impossível se livrar dela, mas a escavação é muito superior. Por exemplo.

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

Rastreará a resolução totalmente para você e você poderá ver onde elas diferem.

— Sirch
fonte

Obrigado, eu não sabia disso sobre o nslookup. Agora eu tentei o comando dig e estranhamente retorna o ip correto na minha máquina. Publiquei a saída do comando na minha máquina e na máquina local aqui gist.github.com/thomas88/600d367387505a13223a5270c89eedda . Qualquer que seja a diferença, o meu navegador (Chrome no Mac) parece mais alinhado com o nslookup - ele não consegue resolver o endereço.

— Thomas Obermüller

Não há motivo para esperar resultados diferentes entre dige nslookuppara esta consulta. No entanto, como 1.1.1.1é um endereço anycast, o resultado pode variar dependendo do servidor em que a consulta acaba sendo atendida.

— kasperd

Chrome, ser um cliente da Web pode estar redirecionando você. O cabeçalho http ... ondula -I <a página da web que você está tentando acessar> revela algo sobre o encaminhamento?

— Sirch

Qual é o sentido de usar ambos +tracee @1.1.1.1? Tem certeza de que entende como essas opções funcionam juntas?

— Barmar

Sim, tenho certeza de que entendo como elas funcionam juntas. O objetivo de usar @ <endereço> seria especificar os servidores DNS que seu cliente está usando nos dois locais. No exemplo dado, seu cloudflare, mas se outro cliente usar um servidor DNS diferente, ele será especificado lá. Por exemplo, onde estou, o endereço do servidor no resolv.conf é da empresa, mas ainda posso resolver a partir de 1.1.1.1

— Sirch 10/10

As pessoas da rede têm usado por idades 1.1.1.1 como uma substituição para outro endereço privado em interfaces aleatórias de switches / roteadores AP. (Eu mesmo estou em um local no momento em que o endereço IP voltado para o público das centenas de pontos de acesso sem fio é 1.1.1.1)

Aposto meu dinheiro nas máquinas que você não pode falar com o 1.1.1.1 do Cloufare, de que você tem uma rota (imediata) para essa interface.

Por exemplo, no meu caso, 1.1.1.1 está me dando meu endereço 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

É por isso que as RFC 3849 e RFC 5737 precisam ser rigorosamente aplicadas.

— kasperd

"Muito baixo" é uma base complicada para determinar qualquer coisa, no entanto. O Cloudflare tem muitos PoPs. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=1.30 msé o meu RTT para a coisa real.

— Håkan Lindqvist

@ HåkanLindqvist O seu valor não parecer um atraso muito baixo para uma conexão externa .... mas sim, não uma métrica confiável.

— Rui F Ribeiro

A latência do @RuiFRibeiro parece certa para a conectividade na mesma cidade, sem o vínculo de alta latência envolvido. (Mostra Traceroute 4 endereços dentro do meu ISP, o endereço de um Cloudflare em uma troca internet na minha cidade, então 1.1.1.1.)

— Håkan Lindqvist

Parece que posso acessar o DNS do Cloudflare, mas ele falha no domínio para mim. Eu executei o nslookup para auth.otc.t-systems.come serverfault.com. Aqui está o resultado do tcpdump: gist.github.com/thomas88/03acc781f45c9427863b1876c75acb4d

— Thomas Obermüller