Por que o nslookup fornece o NXDOMAIN, mas o dig funciona bem?

Question

Eu não vejo uma resposta exata para isso em outro lugar, então eu vou ser corajosa e perguntar aqui. Eu tenho um linode e configurei um registro de DNS A para meu host, que chamarei de A.wc.net. Quando eu procuro usando o nslookup no A.wc.net, recebo este tipo de resposta:

#  running on A.wc.net:  
root@linode (etc ): nslookup A.wc.net
Server:         173.255.243.5
Address:        173.255.243.5#53

** server can't find A.wc.net: NXDOMAIN

No entanto, em qualquer outra máquina, o nslookup fornece o resultado correto:

@HomeMac (~ (BARE:master)): nslookup A.wc.net
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   A.wc.net
Address: 173.255.111.911  (number changed for my protection ;-) 

Além disso, se eu executar a escavação no host A.wc.net:

root@linode (etc ): dig @ns1.linode.com A.wc.net

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @ns1.linode.com A.wc.net
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55398
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 10
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;A.wc.net.                IN      A

;; ANSWER SECTION:
A.wc.net. 86400   IN      A       173.255.111.911  (number changed for my protection ;-) 

Minha pergunta é: por que

nslookup A.wc.net

executado no próprio host A.wc.net não consegue encontrar a resposta correta, quando o mesmo comando executado em outros hosts é bem-sucedido, e

dig @ns1.linode.com A.wc.net

no host O próprio A.wc.net falha?

    

Answer 1

Nesta resposta, estou assumindo: você criou um novo registro A para o domínio e começou a fazer consultas imediatamente de outros sistemas.

Vamos ver o que você estava realmente perguntando em cada um dos seus três exemplos.

Exemplo 1: Você pediu ao nslookup para encontrar um registro A para A.wc.net , você não disse ao nslookup que servidor de nomes deve usar para procurar esse registro. O SO tem alguns padrões O nslookup diz que está usando um servidor de nomes em 173.255.243.5 para tentar procurar. Essa pesquisa falha.

Exemplo 2: você pediu ao nslookup em um computador diferente para pesquisar A.wc.net novamente sem informar ao nslookup que servidor de nomes deve usar. Esta conexão está usando o google DNS em 8.8.8.8 por padrão. ( rant pessoal} o google DNS é rápido, mas eu me recuso a dar mais informações ao google sobre mim do que eles precisam saber. {/ pessoal rant } Google tinha uma resposta para você e lhe disse, também lhe disse que não é DNS autoritativo para este domínio - que essencialmente ~ em palavras simples ~ diz: este servidor de nomes não é a autoridade para este domínio, aqui está uma resposta para você, porém meu registro pode ser armazenado em cache, pode haver um registro mais recente em o DNS autoritativo para este domínio. (totalmente explicando respostas autoritativas / não autoritativas, etc. é realmente muito além do escopo da sua pergunta, mas a resposta rápida é: os servidores de nomes oficiais são os servidores de nome que você define para usar). de wc.net no momento estou postando esta resposta Os servidores de nomes do wc.net são UDNS2.ULTRADNS.NET e UDNS1.ULTRADNS.NET e eles fornecem respostas autoritativas se você disser dig ou nslookup para usar qualquer um desses servidores para a consulta).

Exemplo 3: você pediu para usar o servidor de nomes @ns1.linode.com para pesquisar A.wc.net e ele encontrou um registro A e deu para você. Desta vez, recebemos uma informação adicional TTL ou Time-To-Live, que é definida para 86400 segundos ou 24 horas.

O significado disso é que os servidores de nomes não oficiais que manipulam consultas (e em todos os 3 exemplos que você estava usando servidores de nomes não autorizados para wc.net) procurarão em seu próprio cache primeiro para ver se já conhecem um não -Resposta vencida para a pergunta, se for por razões de velocidade e largura de banda, retornará a resposta que foi armazenada em cache. TTL de 24 horas está dizendo ~ se este registro em cache tem menos de 24 horas, então é a resposta, caso contrário, faça uma consulta a um servidor DNS upstream para um novo registro. ~ Nos tempos modernos, essa consulta upstream geralmente vai diretamente para o nameserver autoritativo, mas pode acabar com alguns outros servidores de nomes em cache resposta - mais uma vez isso está ficando muito além do escopo da sua pergunta, mas a complicação é que pode estender o tempo de cache se o nameserver não está configurado corretamente para assumir o restante TTL no cache upstream que respondeu.)

Conclusões: a alteração de um registro A existente geralmente ficará disponível em todos os servidores DNS em todo o mundo nos próximos 86400 segundos (24 horas), se uma resposta mais direta for necessária, pesquise o autoritativo servidores para o domínio e fazer o seu nslookup ou dig consulta usando um deles. (em casos avançados, os subdomínios podem, na verdade, ter seus próprios servidores de nomes com autoridade diferente do domínio principal, novamente além do escopo).

whatsmydns.net é uma ferramenta que você pode usar para assistir a propagação ou o quão rápido sua mudança de DNS está ocorrendo em todo o mundo. Os cheques verdes e os X vermelhos estão mostrando vários servidores DNS respondendo, em comparação com a resposta autoritária. Lembre-se que o whatsmydns.net não tem todos os nomes do mundo em seu mapa, então mesmo todas as verificações verdes podem significar que ainda existem servidores com um registro em cache. Usando essa ferramenta, você descobrirá que NOVOS registros se propagam ou mais pela Internet mais rapidamente, um registro alterado pode levar segundos TTL para ser visto remotamente. Temos que dizer "poder" porque pode ser mais ou menos, mas provavelmente menos.

Conclusão: sem fazer alterações adicionais no registro A de A.wc.net , espere o TTL de 24 horas e faça suas consultas novamente. A maioria das respostas deve estar correta até o momento.