web-dev-qa-db-ja.com

nslookupがNXDOMAINを提供するのに、Digが正常に機能するのはなぜですか？

これに対する正確な答えは他の場所では見当たらないので、勇気を出してここで質問します。私はlinodeを持っていて、ホストのDNS Aレコードを設定しました。これをA.wc.netと呼びます。 A.wc.netでnslookupを使用して検索すると、次のような答えが得られます。

#  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

ただし、他のマシンからは、nslookupは正しい結果をもたらします。

@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 ;-)

また、ホストA.wc.netでDigを実行する場合：

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 ;-)

私の質問は、なぜですか

nslookup A.wc.net

ホストで実行A.wc.net自体は、他のホストで実行された同じコマンドが成功した場合、正しい答えを見つけることができません。

掘る@ ns1.linode.com A.wc.net

ホストA.wc.net自体が失敗しますか？

networkingdnsnslookup
6
Rich

この回答では、私は仮定を立てています。ドメインの新しいAレコードを作成し、他のシステムからすぐにクエリを作成し始めました。

3つの例のそれぞれで実際に何を求めていたかを見てみましょう。

例1：nslookupにA.wc.netのAレコードを見つけるように依頼しましたが、そのレコードを検索するために使用するネームサーバーをnslookupに指示しませんでしたアップ。 OSにはデフォルト値がいくつかあります。nslookupは、173.255.243.5のネームサーバーを使用して検索を試みていることを示しています。そのルックアップは失敗します。

例2：別のコンピューターのnslookupに、使用するネームサーバーをnslookupに指示せずにA.wc.netをもう一度検索するように要求しました。この接続は、デフォルトで8.8.8.8のGoogleDNSを使用しています。 （personal rant} google DNSは高速ですが、Googleに必要以上の情報を提供することを拒否します。{/ personalrant} Googleから回答があり、あなたに伝えました、それはまた、このドメインに対して権威のあるDNSではないことを示しています-つまり、本質的に〜簡単に言えば〜と言います：このネームサーバーはこのドメインの権威ではありません。このドメインの権威DNSでのより最近の記録（権威/非権威の回答などを完全に説明することは実際には質問の範囲をはるかに超えていますが、迅速な答えは次のとおりです：権威ネームサーバーはドメインを設定するネームサーバーですこの回答を投稿した時点でのwc.netの場合、wc.netのネームサーバーはUDNS2.ULTRADNS.NETとUDNS1.ULTRADNS.NETであり、Digまたはnslookupにいずれかを使用するように指示すると、信頼できる回答が提供されます。クエリ用のサーバー）。

例3：ネームサーバー@ns1.linode.comを使用してA.wc.netを検索するようにDigに要求し、Aレコードを見つけてそれを与えましたあなたへ。今回は、86400秒または24時間に設定された1つの追加情報TTLまたはTime-To-Live）を取得しました。

これの重要性は、クエリを処理する権限のないネームサーバー（および3つすべての例でwc.netに権限のないネームサーバーを使用していた）は、最初に独自のキャッシュを調べて、期限が切れていない回答をすでに知っているかどうかを確認することです。質問に対して、速度と帯域幅の理由でそうする場合は、キャッシュした回答を返します。 TTL 24時間の場合、〜このキャッシュされたレコードが24時間未満の場合はそれが答えです。それ以外の場合は、アップストリームDNSサーバーに新しいレコードを照会します。〜現代では、このアップストリームクエリは信頼できるネームサーバーに直接送信されることがよくありますが、他のネームサーバーのキャッシュされた回答になる可能性があります-これも質問の範囲を超えています-しかし、複雑なのは、次の場合にキャッシュ時間を延長できることですネームサーバーは、応答したアップストリームキャッシュの残りのTTL）を想定するように適切に構成されていません。

結論：既存のAレコードに変更を加えると、通常、世界中のすべてのDNSサーバーから86400秒（24時間）以内に利用可能になります。より直接的な回答が必要です。ドメインの権限のあるサーバーを検索し、それらのいずれかを使用してnslookupまたはDigクエリを実行します。 （高度なケースでは、サブドメインは実際には独自の〜メインドメインとは異なる〜権威ネームサーバーを持つことができますが、これも範囲外です。）

whatsmydns.net は、伝播を監視したり、DNSの変更が世界中でどのくらいの速さで発生しているかを監視するために使用できるツールです。緑のチェックと赤いXは、信頼できる回答と比較して、さまざまなDNSサーバーの回答を示しています。 whatsmydns.netのマップには世界中のすべての名前が含まれているわけではないので、すべての緑のチェックでさえ、キャッシュされたレコードを持つサーバーがまだ存在している可能性があることを覚えておいてください。このツールを使用すると、インターネット上で伝播する新しいレコードをより迅速に発見できます。変更されたレコードがリモートで表示されるまでにTTL秒かかる場合があります。実際には「可能性がある」と言わなければなりません。多かれ少なかれ、おそらく少ない。

結論：A.wc.netのAレコードに追加の変更を加えることなく、TTL 24時間）待ってから、もう一度クエリを実行すると、ほとんどの回答はその時点で正しいはずです。

5
Tyson