Come verificare se le informazioni DNS si sono propagate?

16

Ho impostato una nuova voce DNS per uno dei miei sottodomini (non ho ancora configurato alcun host virtuale Apache o cose simili). Come posso verificare che le informazioni DNS si siano propagate?

Supponevo di poter semplicemente ping my.subdomain.come supporre che, se fosse stato risolto, avrebbe mostrato l'indirizzo IP specificato nel record A. Tuttavia, non so se sto assumendo correttamente. Qual è il modo migliore per controllare queste informazioni?

domain-name-system 
— Andrea
fonte
3
Non è una domanda stupida. Non è così semplice scoprire questo tipo di cose.
— aseq,
1
Sono d'accordo con @aseq che questa non è una domanda stupida , ma "provalo e vedi" ti avrebbe dato anche la risposta. È anche qualcosa a cui Google potrebbe rispondere altrettanto facilmente con il minimo sforzo (cerca How to test if DNS information has propagated: il titolo sanguinoso della domanda genera buoni risultati di Google).
— voretaq7,
4
Non penso che tu abbia sprecato il tempo della gente. La tua domanda ha provocato alcune risposte preziose. Non si sa mai come possa apparire una domanda apparentemente semplice che potrebbe essere "solo googled". Uno dei valori di questo forum è che le risposte e le domande possono essere espanse molto facilmente.
— aseq,
1
@andrew non ha fatto nulla di male nel chiedere a molti di noi come semplici domande - questo sarà probabilmente il miglior risultato google per quella stringa in pochi giorni a causa del modo in cui il sito viene indicizzato / classificato. In generale, però, Google è un posto migliore (più veloce) per guardare: se Google non lo sa, chiedi qui (e Google imparerà) :-)
— voretaq7,
1
Ho capito perché nulla che stavo provando stava funzionando. Apparentemente, la nostra rete è configurata in modo tale che un nuovo sottodominio debba essere aggiunto anche nel nostro DNS locale. Quindi il sottodominio era accessibile dal mondo esterno, ma non nella nostra rete in cui stavo testando. = [Ma usando nslookupe digmentre specificavo un server esterno ce l'ho fatta in modo da poter verificare le informazioni DNS esterne.
— Andrew,

Risposte:

15

Puoi usare dig o nslookup, ad esempio il tuo (o il tuo provider se non esegui il tuo) nameserver è ns1.example.com.

Utilizzando nslookup:

nslookup - ns1.example.com

Al prompt digitare:

my.example.com

Se si risolve in quello che ti aspettavi, allora funziona. Dovrebbe darti qualcosa del tipo:

Name:   example.com
Address: 192.0.43.10

Potrebbe volerci un po 'di tempo per propagarsi al resto di Internet, che è fuori dal tuo controllo.

Utilizzando dig:

dig@ns1.example.com my.example.com

Dovresti vedere qualcosa del tipo:

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

Il solo utilizzo del ping può darti un'idea, ma solo quando si è propagato (memorizzato nella cache da server dei nomi remoti potrebbe essere un modo migliore per descriverlo) e potrebbe essere necessario svuotare la cache DNS locale. Anche se nel tuo caso questo non si applica perché si tratta di un nuovo record. In tal caso, dovrebbe essere disponibile immediatamente. Il modo sopra è più preciso nel darti un'idea invece di limitarti a eseguire il ping.

Se usi Windows, i comandi e la sintassi possono differire leggermente, ma sono abbastanza simili.

— ASEQ
fonte
3
+1 Se stai facendo qualcosa con DNS, ottieni una copia di dig(* i sistemi nix già lo hanno, ci sono diverse versioni per Windows disponibili).
— Chris S,
3
-1. Mi dispiace. Lo sono davvero, ma questa risposta "propaga" il mito propagato dai record DNS, che sicuramente NON. Il termine che stai cercando è "memorizzazione nella cache" che è ciò che accade con i record DNS, in base al TTL del record. Poiché l'OP si riferisce a un nuovo record DNS, non può essersi verificata alcuna memorizzazione nella cache, pertanto qualsiasi client DNS che cerca di risolvere il record in questione otterrà la risposta ... immediatamente ... poiché non può essere stato memorizzato nella cache da quel client ... o quel server DNS client ... o qualsiasi altro server DNS. I record DNS non si propagano al "resto di Internet".
— joeqwerty,
1
joeqwerty è assolutamente corretto. i server DNS memorizzeranno nella cache un hit positivo o negativo per un tempo predefinito. Tuttavia, oltre al post originale, ci sono diversi server di nomi pubblici che puoi controllare tra cui il vecchio GTE (4.2.2.1, 4.2.2.2, 4.2.2.3 e 4.2.2.4) e google (8.8.8.8, 8.8. 4.4). Semplice regola empirica, i nuovi cambiamenti possono richiedere fino alla durata del ttl per un colpo positivo o negativo. Tuttavia, ci sono casi in cui le app implementano una logica errata e risposte nella cache per un periodo di tempo più lungo.
— bangdang,
2
Non penso che devi davvero attenerti alla definizione esatta per ottenere un punto. Inoltre penso che propagare non sia una parolaccia da usare. Copre l'argomento nel senso che la memorizzazione nella cache del record DNS si estende a una gamma più ampia di server. Quella diffusione è ciò a cui si riferisce la propagazione. Ho aggiornato la mia risposta per riflettere il fatto che un nuovo record è immediatamente disponibile.
— aseq,
1
@aseq, è un termine fuorviante. E si scopre soprattutto che i ppl che pensano / parlano del DNS come una sorta di "propagazione" non sanno come funziona il DNS. Di solito affermano una merda come "ci vogliono 2-3 giorni per diffondere le tue informazioni DNS su Internet / Terra" e così via.
— poige
7

Non è possibile verificare la propagazione dei record DNS perché non si verifica la propagazione DNS. Ciò che è possibile verificare è se un client o un server DNS ha un particolare record DNS memorizzato nella cache.

Poiché si tratta di un nuovo record DNS, non può essersi verificata alcuna memorizzazione nella cache. Supponendo che i server dei nomi siano registrati correttamente sui server padre e che i server dei nomi funzionino correttamente, questo record DNS dovrebbe essere immediatamente disponibile per qualsiasi client o server DNS.

— joeqwerty
fonte
Sono felice di aiutare ...
— joeqwerty,
C'è un modo per verificare che ho inserito un indirizzo IP valido? Volevo solo essere sicuro che l'indirizzo IP che ho usato fosse quello giusto. Qualcuno con cui ho parlato sembrava pensare che il ping sarebbe fallito se non avessi ancora configurato Apache VHost.
— Andrew,
Il ping non è uno strumento di test DNS. Dig e Nslookup sono strumenti di test DNS. Utilizzare Dig o Nslookup per testare il nuovo record DNS. Esegui una query per il record sul tuo server dei nomi e quindi esegui una query per il record su altri server dei nomi per assicurarti che trovino il tuo server dei nomi e che il tuo server dei nomi risponda con la risposta corretta.
— joeqwerty,
1
"propagazione" è una nozione inventata nel caso in cui le persone non riescano a capire la situazione reale, che è l'invecchiamento e la scadenza della cache. Ciò che doveva essere detto dai provider DNS è "i tuoi dati potrebbero non essere visualizzati fino a dopo XX ore". Una spiegazione del perché era necessaria in modo che non sembrasse che il provider DNS fosse il ritardo. Troppe persone "non possono gestire la verità". La "propagazione" inventata è una storia di copertura efficace. I veri geek DNS sanno cosa succede realmente perché leggono i dettagli tecnici.
— Skaperen,
Abbastanza vero ... Odio usare un termine che "propaga" un'idea sbagliata di come funziona il DNS.
— joeqwerty,
5

Mentre le altre risposte sono abbastanza buone, ricorda che ciò che ti è stato propagato potrebbe non essere propagato a me. piuttosto che usare DIG o NSlookup e passare un'ora a controllare i server DNS in tutto il mondo, di solito uso http://www.whatsmydns.net/ per vedere come procede la propagazione.

— Jim B
fonte
Non c'è propagazione nel DNS, questo termine è piuttosto fuorviante per tutti i tipi di lamer che non si troveranno a leggere le RFC, quindi non <strike> propagate </strike> usare questo termine, per favore. ;-D
— poige
1
Naturalmente c'è propagazione nel DNS che le RFC presumono che il lettore capisca che le informazioni possono propagarsi mentre i server eseguono ricerche e cache. è particolarmente ovvio quando i lamer leggono gli RFC, quindi si chiedono perché un record sul loro server non corrisponda ai risultati di una ricerca da un altro server. Scoprono che propagate ha la definizione di "diffondere ampiamente" (che è esattamente ciò che deve essere verificato - la distribuzione dei record aggiornati)
— Jim B
Né distribuzione, né propagazione (tranne master to slave).
— poige
Probabilmente è una reliquia di quando a volte ci volle quasi un giorno per caricare le modifiche nei domini .com sui server dei nomi di root (fino a quando .com era sulle radici!)
— Cakemox,
@ poige- grazie per aver verificato la tua mancanza di comprensione del funzionamento della cache DNS. Suggerirei di leggere le RFC su come funziona il DNS e magari di controllare il sito Web a cui ho collegato per esempi reali.
— Jim B,
3

Il modo più semplice per assicurarsi che i server DNS autorevoli nel percorso di delega rispondano correttamente è utilizzare 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

Questo seguirà le delegazioni ai nameserver autorevoli per la tua query. L'ultima risposta è normalmente quella di cui ti preoccupi di più, ma la traccia è utile in quanto mostrerà chi sta rispondendo per ciascuna delegazione. Se stai cambiando i nameserver, tuttavia, questo può essere molto utile.

Tenere presente che la traccia eseguirà una query direttamente sui server autorevoli, quindi non è presente alcuna cache. Questa è la migliore indicazione che le risposte vengono restituite come previsto, ma non è una buona indicazione di ciò che potrebbero verificarsi gli utenti finali. Tuttavia, dal momento che spesso non si ha il controllo sui server dei nomi nella cache di altre persone (oltre ad avere la previsione di abbassare il TTL, attendere il TTL originale, apportare la modifica, quindi ripristinare il TTL), di solito non vale la pena controllare dopo il fatto.

— Cakemox
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.