Como posso resolver problemas de DNS em algum lugar no meio da recursão?

Eu tenho um problema muito estranho com o meu DNS. Meu nome de domínio ( strugee.net) não pode ser resolvido em algumas redes e pode ser resolvido em outras.

Por exemplo, na minha rede doméstica (mesma rede em que o servidor está ligado):

% 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

No entanto, se eu efetuar login em um servidor que possuo no Digital Ocean, o domínio não resolverá:

% 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

Mas , ir diretamente para os servidores de nomes oficiais funciona muito bem:

% 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á bem claro que há um problema com alguma rede grande em algum lugar que não consegue resolver meu domínio, mas não consigo descobrir onde. Eu procurei na página de digmanual por opções que poderiam ajudar, mas não achei nada particularmente útil.

Estou na Namecheap, tanto como registrador de domínio quanto como hospedagem DNS. Eu tenho a opção DNSSEC ativada. Não fiz alterações nas minhas configurações de DNS recentemente.

Como posso depurar esse problema e encontrar o servidor de nomes incorreto?

domain-name-system recursive

— strugee
fonte

Obrigado por fornecer o nome do domínio. Problemas como este são extremamente difíceis de solucionar por nós no Serverfault sem essas informações.

— Andrew B

@AndrewB oh, eu sei. Você é bem-vindo, confie em mim :)

— strugee

A resposta de @ AndrewB faz sentido e parece correta para mim. Antes de ler, notei que sua consulta com falha usava um servidor de nomes IPV6, enquanto as bem-sucedidas usavam IPV4. Freqüentemente (obviamente não neste caso), isso sugere uma configuração IPV6 ruim e pode ser útil usar explicitamente endereços IPV numéricos [4/6] dos servidores de nomes em vez de aliases.

— Guntram Blohm apoia Monica

@ Guntram Desde que tenhamos em mente que recebemos uma resposta do servidor de nomes, o que significa que temos pelo menos conectividade com o servidor DNS. Só quero garantir que as pessoas não se afastem disso com a impressão errada ... SERVFAILpode indicar um problema de upstream, mas ainda indica um pacote de resposta.

— Andrew B

@GuntramBlohm Você gosta de algo. strugee.netpossui cinco registros NS, mas nenhum AAAAregistro de Acola apenas registros de cola. O pior é que esses cinco Aregistros de cola apontam para apenas dois endereços IP diferentes. Parece uma configuração bastante frágil. Mesmo que não seja a causa raiz do problema em questão, é algo a se observar.

— kasperd

Respostas:

Como posso depurar esse problema e encontrar o servidor de nomes incorreto?

O daxd5 ofereceu alguns bons conselhos para iniciar, mas a única resposta real aqui é que você precisa saber como pensar como um servidor DNS recursivo. Como existem inúmeras configurações incorretas na camada autoritativa que podem resultar em uma inconsistência SERVFAIL, você precisa de um profissional de DNS ou de ferramentas de validação online.

De qualquer forma, o objetivo não é ajudar você, mas eu queria ter certeza de que você entende que não há uma resposta conclusiva para essa pergunta.

No seu caso particular, notei que strugee.netparece ser uma zona assinada com DNSSEC. Isso é evidente pela presença dos registros DSe RRSIGna cadeia de referência:

# 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 prosseguirmos, precisamos verificar se a assinatura é válida ou não. O DNSViz é uma ferramenta frequentemente usada para esse fim e confirma que há realmente problemas . O vermelho raivoso na imagem está sugerindo que você tem um problema, mas, em vez de passar o mouse sobre tudo, podemos apenas expandir Avisos na barra lateral esquerda:

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)

O problema é claro: a assinatura na sua zona expirou e as chaves precisam ser atualizadas. A razão pela qual você está vendo resultados inconsistentes é porque nem todos os servidores recursivos têm a validação DNSSEC ativada. Aqueles que validam estão descartando seu domínio e, para aqueles que não o fazem, são negócios como sempre.

Edit: A infraestrutura DNS da Comcast é conhecida por implementar a validação DNSSEC e, como um de seus clientes, posso confirmar que estou vendo uma SERVFAILtambém.

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

— Andrew B
fonte

Opa, eu tive stugee.netna saída dig, que obviamente é um erro de digitação. A parte DNSSEC desta análise foi feita com o nome correto.

— Andrew B

Enquanto você realmente vê que os servidores de nomes com autoridade estão respondendo corretamente, é necessário acompanhar toda a cadeia de resolução de DNS. Ou seja, desça toda a hierarquia DNS a partir dos servidores raiz.

$ 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

Isso basicamente verifica se os servidores DNS públicos estão funcionando e você está fazendo a mesma coisa que o seu resolvedor DNS deveria estar fazendo. Portanto, você deve obter as mesmas respostas acima em seu servidor Digital Ocean, a menos que algo esteja errado com o resolvedor de DNS:

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

Se as duas primeiras consultas falharem, é o DNS do lado do Digital Ocean que está falhando. Verifique seu /etc/resolv.confe tente consultar o servidor DNS secundário. Se o secundário funcionar, basta mudar a ordem dos resolvedores e tente novamente.

— daxd5
fonte