Comment tester si les informations DNS se sont propagées?

16

J'ai configuré une nouvelle entrée DNS pour l'un de mes sous-domaines (je n'ai pas encore configuré d'hôte virtuel Apache ou quelque chose comme ça). Comment puis-je vérifier que les informations DNS se sont propagées?

J'ai supposé que je pouvais simplement ping my.subdomain.comet supposer que s'il pouvait résoudre, il montrerait l'adresse IP que j'ai spécifiée dans l'enregistrement A. Cependant, je ne sais pas si je suppose correctement. Quelle est la meilleure façon de vérifier ces informations?

domain-name-system Andrew
la source
3
Pas une question stupide. Ce n'est pas si simple de découvrir ce genre de chose.
aseq
1
Je suis d'accord avec @aseq que ce n'est pas une question stupide , mais "essayez-le et voyez" vous aurait donné la réponse aussi. C'est aussi quelque chose que Google pourrait répondre aussi facilement avec le moindre effort (recherche How to test if DNS information has propagated- le titre de la question sanglante génère de bons résultats Google).
voretaq7
4
Je ne pense pas que vous ayez perdu le temps des gens. Votre question a provoqué de précieuses réponses. On ne sait jamais comment une question apparemment simple qui pourrait "simplement être googlé" peut se révéler. L'une des valeurs de ce forum est que les réponses et les questions peuvent être développées très facilement.
aseq
1
@andrew n'a rien de mal à demander ce que beaucoup d'entre nous considèrent comme de simples questions - ce sera probablement le meilleur résultat google pour cette chaîne en quelques jours en raison de la façon dont le site est indexé / classé. En général, bien que Google soit un meilleur (plus rapide) endroit où chercher: si Google ne sait pas, demandez ici (et Google apprendra) :-)
voretaq7
1
J'ai compris pourquoi rien de ce que j'essayais ne fonctionnait. Apparemment, notre réseau est configuré de manière à ce qu'un nouveau sous-domaine soit également ajouté dans notre DNS local. Le sous-domaine était donc accessible depuis le monde extérieur, mais pas dans notre réseau où je testais. = [Mais en utilisant nslookupet digen spécifiant un serveur externe, j'ai pu vérifier les informations DNS externes.
Andrew

Réponses:

15

Vous pouvez utiliser dig ou nslookup, disons que votre serveur de noms (ou celui de votre fournisseur si vous n'exécutez pas le vôtre) est ns1.example.com.

Utilisation de nslookup:

nslookup - ns1.example.com

À l'invite, tapez:

my.example.com

S'il résout ce que vous attendiez, cela fonctionne. Cela devrait vous donner quelque chose comme:

Name:   example.com
Address: 192.0.43.10

La propagation vers le reste d'Internet peut encore prendre un certain temps, c'est hors de votre contrôle.

En utilisant dig:

[email protected] my.example.com

Vous devriez voir quelque chose comme:

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

Le simple fait d'utiliser ping peut vous donner une idée, mais uniquement lorsqu'il s'est propagé (mis en cache par des serveurs de noms distants peut être une meilleure façon de le décrire) et que votre cache DNS local peut avoir besoin d'être vidé. Bien que dans votre cas, cela ne s'applique pas car il s'agit d'un nouveau record. Dans ce cas, il devrait être disponible immédiatement. La méthode ci-dessus est plus précise pour vous donner une idée plutôt que de la cingler.

Si vous utilisez des fenêtres, les commandes et la syntaxe peuvent différer légèrement, mais sont assez similaires.

aseq
la source
3
+1 Si vous faites quoi que ce soit avec DNS, obtenez une copie de dig(* les systèmes nix l'ont déjà, il existe différentes versions pour Windows disponibles).
Chris S
3
-1. Je suis désolé. Je le suis vraiment, mais cette réponse "propage" le mythe selon lequel les enregistrements DNS se propagent, ce qu'ils ne font certainement PAS. Le terme que vous recherchez est "mise en cache", ce qui se produit avec les enregistrements DNS, sur la base du TTL de l'enregistrement. Comme l'OP fait référence à un nouvel enregistrement DNS, aucune mise en cache ne peut avoir eu lieu, donc tout client DNS cherchant à résoudre l'enregistrement en question obtiendra la réponse ... immédiatement ... car il ne peut pas avoir été mis en cache par ce client ... ou ce serveur DNS client ... ou tout autre serveur DNS. Les enregistrements DNS ne se propagent pas au "reste d'Internet".
joeqwerty
1
joeqwerty est absolument correct. Les serveurs DNS mettront en cache un hit positif ou négatif pour une durée prédéfinie. Cependant, en plus de la publication d'origine, vous pouvez vérifier plusieurs serveurs de noms publics, notamment l'ancien GTE (4.2.2.1, 4.2.2.2, 4.2.2.3 et 4.2.2.4) et Google (8.8.8.8, 8.8. 4.4). En règle générale, les nouveaux changements peuvent prendre jusqu'à la durée du ttl pour un hit positif ou négatif. Cependant, il existe des cas où les applications implémentent une mauvaise logique et des réponses de cache pendant une période plus longue.
bangdang
2
Je ne pense pas qu'il faille vraiment s'en tenir à la définition exacte pour faire passer un point. D'ailleurs je pense que propager n'est pas un mauvais mot à utiliser. Il couvre le sujet dans le sens où la mise en cache de l'enregistrement DNS s'étend à un plus large éventail de serveurs. C'est cette propagation qui fait référence à la propagation. J'ai mis à jour ma réponse pour refléter le fait qu'un nouvel enregistrement est disponible immédiatement.
aseq
1
@aseq, c'est un terme trompeur. Et il s'avère surtout que les personnes qui pensent / parlent du DNS comme une sorte de "propagation" ne savent pas comment fonctionne le DNS. Ils déclarent généralement une merde comme "il faut 2 à 3 jours pour que vos informations DNS soient propagées sur Internet / Terre", etc.
poige
7

Vous ne pouvez pas tester la propagation des enregistrements DNS car la propagation DNS ne se produit pas. Ce que vous pouvez tester est de savoir si un client ou un serveur DNS a ou non un enregistrement DNS particulier mis en cache.

Puisqu'il s'agit d'un nouvel enregistrement DNS, aucune mise en cache ne peut avoir eu lieu. En supposant que vos serveurs de noms sont correctement enregistrés sur les serveurs parents et que vos serveurs de noms fonctionnent correctement, cet enregistrement DNS doit être disponible immédiatement pour tous les clients ou serveurs DNS.

joeqwerty
la source
Heureux d'aider ...
joeqwerty
Existe-t-il un moyen de vérifier que j'ai entré une adresse IP valide? Je voulais juste m'assurer que l'adresse IP que j'utilisais était la bonne. Quelqu'un à qui j'ai parlé semblait penser que le ping échouerait si je n'avais pas encore configuré Apache VHost.
Andrew
Ping n'est pas un outil de test DNS. Dig et Nslookup sont des outils de test DNS. Utilisez Dig ou Nslookup pour tester le nouvel enregistrement DNS. Recherchez l'enregistrement sur votre serveur de noms, puis recherchez l'enregistrement sur d'autres serveurs de noms pour vous assurer qu'ils trouvent votre serveur de noms et que votre serveur de noms répond avec la bonne réponse.
joeqwerty
1
"propagation" est une notion inventée au cas où les gens ne pourraient pas comprendre la situation réelle, à savoir le vieillissement et l'expiration du cache. Ce que les fournisseurs de DNS devaient dire, c'est que "vos données ne seront peut-être pas vues avant XX heures". Une explication de pourquoi était nécessaire pour qu'il ne semble pas que le fournisseur DNS ait été le retard. Trop de gens "ne peuvent pas gérer la vérité". La "propagation" inventée est une histoire de couverture efficace. Les vrais geeks DNS savent ce qui se passe réellement car ils lisent les détails techniques.
Skaperen
C'est vrai ... Je déteste utiliser un terme qui "propage" une idée fausse sur le fonctionnement du DNS.
joeqwerty
5

Bien que les autres réponses soient plutôt bonnes, rappelez-vous que ce qui vous est propagé ne le peut pas. plutôt que d'utiliser DIG ou NSlookup et de passer une heure à vérifier les serveurs DNS dans le monde, j'utilise généralement http://www.whatsmydns.net/ pour voir comment la propagation se déroule.

Jim B
la source
Il n'y a pas de propagation dans le DNS, ce terme est plutôt trompeur pour tous les types de lamers qui ne se retrouveront pas à lire les RFC, donc ne pas <strike> propager </strike> utiliser ce terme, s'il vous plaît. ;-D
poige
1
Bien sûr, il existe une propagation dans le DNS, les RFC supposent que le lecteur comprend que les informations peuvent se propager lorsque les serveurs effectuent des recherches et un cache. c'est particulièrement évident lorsque les lamers lisent les RFC puis se demandent pourquoi un enregistrement sur leur serveur ne correspond pas aux résultats d'une recherche à partir d'un autre serveur. Ils découvrent que propager a la définition de "se répandre largement" (c'est exactement ce qui doit être vérifié - la distribution des enregistrements mis à jour)
Jim B
Ni distribution, ni propagation (sauf maître à esclave).
poige
C'est probablement une relique du moment où il a fallu parfois près d'un jour pour que les modifications apportées aux domaines .com soient chargées sur les serveurs de noms racine (il y a bien
longtemps
@ poige- merci d'avoir vérifié votre manque de compréhension du fonctionnement de la mise en cache DNS. Je suggérerais de lire les RFC sur le fonctionnement du DNS et peut-être de consulter le site Web auquel je suis lié pour des exemples réels.
Jim B
3

La façon la plus simple de vous assurer que vos serveurs DNS faisant autorité dans votre chemin de délégation répondent correctement est d'utiliser 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

Cela suivra les délégations auprès des serveurs de noms faisant autorité pour votre requête. La dernière réponse est normalement celle qui vous préoccupe le plus, mais la trace est utile car elle indique qui répond pour chaque délégation. Si vous changez de serveurs de noms, cela peut être très utile.

Gardez à l'esprit que trace interrogera directement les serveurs faisant autorité, il n'y a donc pas de mise en cache. C'est la meilleure indication que les réponses sont renvoyées comme prévu, mais ce n'est pas une bonne indication de ce que les utilisateurs finaux pourraient ressentir. Cependant, comme vous n'avez pas souvent le contrôle sur les serveurs de noms de mise en cache d'autres personnes de toute façon (au-delà d'avoir la prévoyance pour réduire votre TTL, attendez le TTL d'origine, apportez la modification, puis restaurez le TTL), cela ne vaut généralement pas la peine de vérifier après coup.

Cakemox
la source