DNS情報が伝播したかどうかをテストする方法は？

16

サブドメインの1つに新しいDNSエントリを設定します（Apache仮想ホストなどはまだ設定していません）。DNS情報が伝達されたことを確認するにはどうすればよいですか？

単純にping my.subdomain.com解決でき、解決できた場合、Aレコードで指定したIPアドレスが表示されると想定しました。しかし、私が正しく仮定しているかどうかはわかりません。この情報を確認する最良の方法は何ですか？

domain-name-system 
— アンドリュー
ソース
3
愚かな質問ではありません。この種のことを見つけるのはそれほど簡単ではありません。
— aseq
1
これは馬鹿げた質問ではありませんが、「試してみてください」という答えもあなたに与えてくれたことに@aseqに同意します。それはまた、Googleがほんの少しの努力で同じくらい簡単に答えることができるものです（検索How to test if DNS information has propagated-血なまぐさいタイトルは良いGoogle結果を生み出します）。
— voretaq7
4
人々の時間を無駄にしたとは思わない。あなたの質問はいくつかの貴重な反応を引き起こしました。あなたは、「グーグルにされる」ことができる一見単純な質問がどうなるかを決して知らない。このフォーラムの価値の1つは、回答と質問を非常に簡単に拡張できることです。
— aseq
1
@andは、多くの人が単純な質問と見なしているものを尋ねることに何の問題もありませんでした-これはおそらく、サイトがインデックス/ランク付けされる方法のため、数日でその文字列のトップのGoogle結果になるでしょう。一般に、Googleはより良い（高速な）外観になります。Googleがわからない場合は、こちらに問い合わせてください（そしてGoogleが学習します）:
— voretaq7
1
私は何もしようとしていなかった理由を理解しました。どうやら、ネットワークはローカルDNSに新しいサブドメインを追加する必要があるように構成されているようです。そのため、サブドメインは、私がテストしていたネットワークではなく、外の世界からアクセスできました。= [しかし、外部サーバーを指定して使用nslookupしているdig間に、外部DNS情報を確認できるようになりました。
— アンドリュー

回答:

15

digまたはnslookupを使用できます。自分（または自分で実行していない場合はプロバイダー）のネームサーバーはns1.example.comであると言います。

nslookupの使用：

nslookup - ns1.example.com

プロンプトタイプで：

my.example.com

期待どおりに解決したら、動作します。次のようになります。

Name:   example.com
Address: 192.0.43.10

インターネットの残りの部分に伝播するにはまだ時間がかかるかもしれませんが、それはあなたの制御の範囲外です。

digを使用する：

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

次のように表示されるはずです。

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

pingを使用するだけでアイデアが得られる場合がありますが、伝播した場合（リモートネームサーバーによってキャッシュされた方が記述しやすい場合があります）にのみ、ローカルDNSキャッシュをフラッシュする必要があります。ただし、これは新しいレコードであるため、これは適用されません。その場合、すぐに利用できるはずです。上記の方法は、単にpingするのではなく、アイデアを提供する際により正確です。

ウィンドウを使用する場合、コマンドと構文は若干異なる場合がありますが、かなり似ています。

— aseq
ソース
3
+1 DNSで何かをしている場合は、コピーを入手してくださいdig（* nixシステムはすでにそれを持っています。Windowsにはさまざまなバージョンがあります）。
— クリスS
3
-1。申し訳ありません。私は本当にそうですが、この答えは、DNSレコードが伝播するという神話を「伝播」します。探している用語は「キャッシュ」です。これは、レコードのTTLに基づいてDNSレコードで発生することです。OPは新しいDNSレコードを参照しているため、キャッシングは発生していません。したがって、問題のレコードを解決しようとするDNSクライアントは、すぐに答えを取得します。 ...またはそのクライアントDNSサーバー...またはその他のDNSサーバー。DNSレコードは「インターネットの他の部分」には伝播しません。
— -joeqwerty
1
joeqwertyは絶対に正しいです。DNSサーバーは、事前に定義された時間、正または負のヒットをキャッシュします。ただし、元の投稿に加えて、古いGTE（4.2.2.1、4.2.2.2、4.2.2.3、および4.2.2.4）やgoogle（8.8.8.8、8.8。 4.4）。簡単な経験則では、新しい変更は正または負のヒットのttlの期間までかかることがあります。ただし、アプリが悪いロジックを実装し、回答を長期間キャッシュする場合があります。
— bangdang
2
ポイントを得るために正確な定義に固執する必要はないと思います。それに、伝播は使うのに悪い言葉ではないと思います。DNSレコードのキャッシュがより広い範囲のサーバーに広がるという意味で、主題をカバーします。その広がりは、伝播が指すものです。新しいレコードがすぐに利用できるという事実を反映するために、回答を更新しました。
— aseq
1
@aseq、誤解を招く用語です。そして、DNSをちょっとした「伝播」と考えたり話したりする人々は、DNSの仕組みを知らないことがほとんどです。通常、「DNS情報がインターネット/地球全体に伝播されるには2〜3日かかる」などのくだらないことを述べています。
— poige
7

DNS伝播は発生しないため、DNSレコードの伝播をテストすることはできません。テストできるのは、DNSクライアントまたはサーバーに特定のDNSレコードがキャッシュされているかどうかです。

これは新しいDNSレコードであるため、キャッシュは発生していません。ネームサーバーが親サーバーに正しく登録され、ネームサーバーが正しく機能していると仮定すると、このDNSレコードは、すべてのDNSクライアントまたはサーバーですぐに利用できるはずです。

— joeqwerty
ソース
喜んで助けて
— ...-joeqwerty
有効なIPを入力したことを確認する方法はありますか？使用したIPアドレスが正しいものであることを確認したかっただけです。私が話した人は、Apache VHostをまだセットアップしていないとpingが失敗すると考えているようです。
— アンドリュー
PingはDNSテストツールではありません。DigとNslookupはDNSテストツールです。DigまたはNslookupを使用して、新しいDNSレコードをテストします。ネームサーバーに対してレコードを照会してから、他のネームサーバーに対してレコードを照会して、ネームサーバーを見つけていることと、ネームサーバーが正しい答えで応答していることを確認します。
— -joeqwerty
1
「伝播」は、キャッシュのエージングと有効期限である実際の状況を人々が理解できない場合に作成される概念です。DNSプロバイダーが言う必要があるのは、「XX時間後までデータが表示されない可能性がある」ということです。DNSプロバイダーが遅延のように見えないように、なぜ必要なのかの説明。「真実を処理できない」人が多すぎます。作成された「伝播」は、効果的なカバーストーリーです。真のDNSオタクは、技術的な詳細を読んでいるので、実際に何が起こるかを知っています。
— スカペレン
確かに... DNSがどのように機能するかについての誤解を「広める」という用語を使用するのは嫌です。
— joeqwerty
5

他の答えはかなり良いですが、あなたに伝えられたものは私に伝えられないかもしれないことを覚えておいてください。DIGまたはNSlookupを使用して世界中のDNSサーバーを1時間チェックするのではなく、通常、http： //www.whatsmydns.net/を使用して伝播の進行状況を確認します。

— ジムB
ソース
DNSには伝播はありません。この用語は、RFCを読んでいないと感じるあらゆる種類のラマーにとってかなり誤解を招くため、この用語を<strike> propagate </ strike>使用しないでください。;-D
— poige
1
もちろん、DNSには伝播があります。RFCは、サーバーが検索とキャッシュを実行するときに情報が伝播する可能性があることを読者が理解していると想定しています。ラマーがRFCを読んで、サーバー上のレコードが別のサーバーからのルックアップの結果と一致しない理由を疑問に思うとき、それは特に明白です。（ -更新されたレコードの分布チェックする必要が正確に何である）彼らは、伝播は、「広く普及するには」の定義があることを発見
— ジム・B
配布も伝播もありません（マスターからスレーブへを除く）。
— poige
ルートネームサーバーにロードされた.comドメインの変更を取得するのに1日近くかかったときの遺物です（.comがルートに戻ったとき！）
— Cakemox
@ poige- DNSキャッシングの仕組みを理解していないことを確認してくれてありがとう。DNSの動作に関するRFCを読んで、リンク先のWebサイトで実際の例を確認することをお勧めします。
— ジムB
3

委任パス内の信頼できるDNSサーバーが正しく応答していることを確認する最も簡単な方法は、次を使用すること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

これは、クエリに対して権限のあるネームサーバーへの委任に従います。通常、最後の回答が最も懸念されるものですが、トレースは、各委任に対して誰が回答しているかを示すのに役立ちます。ただし、ネームサーバーを変更する場合、これは非常に便利です。

トレースは権限のあるサーバーに直接照会するため、キャッシュは行われないことに注意してください。これは、回答が期待どおりに返されていることを示す最良の指標ですが、エンドユーザーが経験する可能性のある指標としては適切ではありません。ただし、とにかく他の人のキャッシングネームサーバーを制御することはあまりないため（TTLを下げるための先見性を持ち、元のTTLを待ってから変更を行い、TTLを復元します）、通常は事後に確認する価値はありません。

— ケーキモックス
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.