Como testar se as informações de DNS foram propagadas?

16

Configurei uma nova entrada DNS para um dos meus subdomínios (ainda não configurei nenhum host virtual Apache ou algo assim). Como posso verificar se as informações de DNS foram propagadas?

Eu assumi que poderia simplesmente ping my.subdomain.come suponho que, se pudesse resolver, mostraria o endereço IP especificado no registro A. No entanto, não sei se estou assumindo corretamente. Qual é a melhor maneira de verificar essas informações?

domain-name-system Andrew
fonte
3
Não é uma pergunta idiota. Não é tão fácil descobrir esse tipo de coisa.
aseq
11
Concordo com o @aseq que esta não é uma pergunta idiota , mas "experimente e veja" também lhe daria a resposta. Também é algo que o Google poderia responder com a mesma facilidade com o mínimo esforço possível (pesquise How to test if DNS information has propagated- o sangrento título da pergunta gera bons resultados no Google).
precisa saber é o seguinte
4
Eu não acho que você desperdiçou o tempo das pessoas. Sua pergunta provocou algumas respostas valiosas. Você nunca sabe como pode surgir uma pergunta aparentemente simples que poderia "apenas ser pesquisada no Google". Um dos valores deste fórum é que as respostas e perguntas podem ser expandidas com muita facilidade.
aseq
11
@andrew nada de errado em perguntar o que muitos de nós vemos como perguntas simples - esse provavelmente será o melhor resultado do google para essa sequência em alguns dias, devido à maneira como o site é indexado / classificado. Em geral, porém Google é a melhor (mais rápido) lugar para olhar: não Se o Google não sabe, então, pedir aqui (e Google vai aprender) :-)
voretaq7
11
Eu descobri por que nada que eu estava tentando estava funcionando. Aparentemente, nossa rede está configurada de forma que um novo subdomínio também deve ser adicionado ao nosso DNS local. Portanto, o subdomínio era acessível a partir do mundo exterior, não apenas em nossa rede onde eu estava testando. = [Mas o uso nslookupe a digespecificação de um servidor externo fizeram com que eu pudesse verificar as informações de DNS externo.
30512 Andrew

Respostas:

15

Você pode usar dig ou nslookup, digamos que o servidor de nomes (ou do seu provedor, se você não administra seus próprios) é ns1.example.com.

Usando o nslookup:

nslookup - ns1.example.com

No prompt, digite:

my.example.com

Se resolver o que você esperava, funcionará. Deve fornecer algo como:

Name:   example.com
Address: 192.0.43.10

Ainda pode demorar um pouco para se propagar para o resto da Internet, isso está fora de seu controle.

Usando dig:

[email protected] my.example.com

Você deve ver algo como:

;; ANSWER SECTION:
example.com.        172800  IN  A   192.0.43.10

O simples uso do ping pode lhe dar uma idéia, mas somente quando ele se propaga (em cache por servidores de nomes remotos pode ser a melhor maneira de descrevê-lo) e o cache do DNS local pode precisar ser liberado. Embora no seu caso, isso não se aplique porque este é um novo registro. Nesse caso, ele deve estar disponível imediatamente. A maneira acima é mais precisa, fornecendo uma idéia, em vez de apenas fazer ping.

Se você usa o Windows, os comandos e a sintaxe podem variar um pouco, mas são bastante semelhantes.

aseq
fonte
3
+1 Se você estiver fazendo alguma coisa com DNS, obtenha uma cópia de dig(* os sistemas nix já o possuem, existem várias versões disponíveis para Windows).
Chris S
3
-1. Eu sinto Muito. Eu realmente sou, mas esta resposta "propaga" o mito de que os registros DNS se propagam, o que eles certamente NÃO. O termo que você procura é "cache", que é o que acontece com os registros DNS, com base no TTL do registro. Como o OP está se referindo a um novo registro DNS, nenhum cache pode ter ocorrido; portanto, qualquer cliente DNS que tente resolver o registro em questão receberá a resposta ... imediatamente ... pois não pode ter sido armazenado em cache por esse cliente ... ou o servidor DNS dos clientes ... ou qualquer outro servidor DNS. Os registros DNS não se propagam para "o resto da internet".
precisa saber é o seguinte
11
joeqwerty está absolutamente correto. Os servidores DNS armazenam em cache um resultado positivo ou negativo por um tempo predefinido. No entanto, além da postagem original, existem vários servidores de nomes públicos que você pode comparar, incluindo o antigo GTE (4.2.2.1, 4.2.2.2, 4.2.2.3 e 4.2.2.4) e o google (8.8.8.8, 8.8. 4.4) Como regra geral simples, novas alterações podem levar a duração do ttl para acertos positivos ou negativos. No entanto, há casos em que os aplicativos implementam respostas ruins de cache e lógica por um longo período de tempo.
bangdang
2
Eu não acho que você realmente precise se ater à definição exata para entender o ponto. Além disso, acho que propagação não é uma palavra ruim para usar. Ele cobre o assunto no sentido de que o armazenamento em cache do registro DNS se espalha para uma variedade maior de servidores. Essa propagação é a que se refere a propagação. Atualizei minha resposta para refletir o fato de um novo registro estar disponível imediatamente.
Aseq 28/04/12
11
@aseq, é um termo enganador. E acontece que as pessoas que pensam / falam sobre DNS como meio "propagação" não sabem como o DNS funciona. Eles geralmente afirmam uma porcaria como "leva 2-3 dias para que suas informações de DNS sejam propagadas pela Internet / Terra" e assim por diante.
Poige
7

Você não pode testar a propagação de registros DNS porque a propagação DNS não ocorre. O que você pode testar é se um cliente ou servidor DNS tem ou não um registro DNS em cache.

Como esse é um novo registro DNS, nenhum cache pode ter ocorrido. Supondo que seus servidores de nomes estejam corretamente registrados nos servidores-pai e que seus servidores de nomes estejam funcionando corretamente, esse registro DNS deverá estar disponível imediatamente para todo e qualquer cliente ou servidor DNS.

joeqwerty
fonte
Fico feliz em ajudar ...
joeqwerty
Existe alguma maneira de verificar se eu inseri um IP válido? Eu só queria ter certeza de que o endereço IP que eu usei era o correto. Alguém com quem falei parecia pensar que o ping falharia se eu ainda não tivesse um Apache VHost configurado.
Andrew
Ping não é uma ferramenta de teste de DNS. Dig e Nslookup são ferramentas de teste de DNS. Use Dig ou Nslookup para testar o novo registro DNS. Consulte o registro no servidor de nomes e, em seguida, consulte outros servidores de nomes para garantir que eles estejam encontrando o servidor de nomes e que o servidor de nomes responda com a resposta correta.
precisa saber é o seguinte
11
"propagação" é uma noção criada caso as pessoas não entendam a situação real, que é o envelhecimento e a expiração do cache. O que precisava ser dito pelos provedores de DNS é "seus dados podem não ser vistos até depois de vinte horas". Uma explicação do porquê era necessária para não parecer que o provedor DNS era o atraso. Muitas pessoas "não conseguem lidar com a verdade". A "propagação" inventada é uma matéria de capa eficaz. Os verdadeiros geeks do DNS sabem o que realmente acontece porque leem os detalhes técnicos.
Skaperen
É verdade ... Eu odeio usar um termo que "propaga" um equívoco de como o DNS funciona.
Joeqwerty
5

Embora as outras respostas sejam muito boas, lembre-se de que o que é propagado para você pode não ser propagado para mim. em vez de usar o DIG ou o NSlookup e passar uma hora verificando os servidores DNS em todo o mundo, geralmente uso o http://www.whatsmydns.net/ para ver como está indo a propagação.

Jim B
fonte
Não há propagação no DNS, este termo é bastante enganador para todos os tipos de lamers que não se encontrarem lendo RFCs, portanto, não <strike> propagate </strike> use esse termo, por favor. ;-D
poige
11
Obviamente, há propagação no DNS, os RFCs presumem que o leitor entenda que as informações podem se propagar à medida que os servidores executam pesquisas e cache. é particularmente óbvio quando os lamers lêem RFCs e se perguntam por que um registro em seu servidor não corresponde aos resultados de uma pesquisa de um servidor diferente. Eles descobrem que se propagam tem a definição de "para espalhar amplamente" (que é exatamente o que precisa ser verificado - a distribuição de registros atualizados)
Jim B
Nem distribuição, nem propagação (exceto mestre para escravo).
Poige 01/05/12
Provavelmente é uma relíquia de quando, às vezes, demorava quase um dia para que as alterações feitas nos domínios .com fossem carregadas nos servidores de nomes raiz (no
passado
@ poige- obrigado por verificar sua falta de compreensão de como o cache do DNS funciona. Sugiro ler as RFCs sobre como o DNS funciona e talvez verificar o site ao qual vinculei para obter exemplos do mundo real.
Jim B
3

A maneira mais fácil de garantir que os servidores DNS autoritativos no caminho da delegação estejam respondendo corretamente é usar dig +trace:

; <<>> DiG 9.7.3 <<>> +trace www.google.com a
;; global options: +cmd
.           80050   IN  NS  m.root-servers.net.
.           80050   IN  NS  f.root-servers.net.
.           80050   IN  NS  i.root-servers.net.
.           80050   IN  NS  h.root-servers.net.
.           80050   IN  NS  c.root-servers.net.
.           80050   IN  NS  k.root-servers.net.
.           80050   IN  NS  d.root-servers.net.
.           80050   IN  NS  g.root-servers.net.
.           80050   IN  NS  a.root-servers.net.
.           80050   IN  NS  b.root-servers.net.
.           80050   IN  NS  e.root-servers.net.
.           80050   IN  NS  l.root-servers.net.
.           80050   IN  NS  j.root-servers.net.
;; Received 509 bytes from 192.168.1.1#53(192.168.1.1) in 0 ms

com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
;; Received 504 bytes from 198.41.0.4#53(a.root-servers.net) in 127 ms

google.com.     172800  IN  NS  ns2.google.com.
google.com.     172800  IN  NS  ns1.google.com.
google.com.     172800  IN  NS  ns3.google.com.
google.com.     172800  IN  NS  ns4.google.com.
;; Received 168 bytes from 192.43.172.30#53(i.gtld-servers.net) in 20 ms

www.google.com.     604800  IN  CNAME   www.l.google.com.
www.l.google.com.   300 IN  A   173.194.35.180
www.l.google.com.   300 IN  A   173.194.35.178
www.l.google.com.   300 IN  A   173.194.35.176
www.l.google.com.   300 IN  A   173.194.35.177
www.l.google.com.   300 IN  A   173.194.35.179
;; Received 132 bytes from 216.239.34.10#53(ns2.google.com) in 27 ms

Isso seguirá as delegações para os servidores de nomes com autoridade para sua consulta. A última resposta é normalmente a que mais lhe preocupa, mas o rastreamento é útil, pois mostra quem está respondendo para cada delegação. Se você estiver alterando servidores de nomes, isso pode ser muito útil.

Lembre-se de que o rastreamento consultará os servidores autoritativos diretamente, para que não haja armazenamento em cache. Essa é a melhor indicação de que as respostas estão sendo retornadas conforme o esperado, mas não é uma boa indicação do que os usuários finais podem experimentar. No entanto, como muitas vezes você não tem controle sobre os servidores de nomes de cache de outras pessoas (além de ter a previsão de diminuir seu TTL, aguarde o TTL original, faça a alteração e depois restaure o TTL), geralmente não vale a pena verificar após o fato.

Cakemox
fonte