DNSルックアップ順序はどのように決定されますか？

Question

例：ドメイン名を登録しました domain.com レジストラサーバーにネームサーバーレコードを追加しました。
ns1.domain.com。
ns2.domain.com。
ns3.domain.com。

私たちが探すより domain.com。 3つのネームサーバーのアドレスをすべて取得します。
1。そのサーバーのどれがさらに要求され、なぜですか？
2。ゾーンファイルのNSレコードの順序は重要ですか？
3。それはいずれかで決定されますか RFC？

Adam C · Accepted Answer

悲しいことに、ここでの答えは「依存する」です。依存する要素は、ドメイン、所有サーバーの設定方法、およびローカルDNSの設定方法によって異なります。

まず、たとえば、NS返されるレコードについて：これらのレコードが返される順序をランダム化することが完全に許可されているため、要求するたびに順序が異なる場合があります。一方、、それはすべてのDNS実装で行われるわけではないので、静的に順序付けられたリストを取得する可能性があります。

次に、一部のDNS実装は、各NSを並行してクエリし、どちらか最初に応答したものを使用します。他のDNS実装は、それぞれにヒットし、いくつかの要求で最も速いものを決定して、それを使用します。または、単にラウンドロビン。

DNSには複数のRFCがあり、私が見つけた2つのより有用なものは次のとおりです。

http://www.faqs.org/rfcs/rfc1912.html

http://www.faqs.org/rfcs/rfc1033.html

私はこれが答えのないものであり、あなたが取り除く決定的なものは何もないことに気づきますが、上記を考えると、特定のドメインの動作を決定する必要がある唯一の真の方法はテストすることです。

DELETEDACC · Answer

世界中のISPなど、私がクライアントレベルで見た最も一般的な実装は次のとおりです。

（ブロードバンド加入者のような）誰かがfoo.example.comのAレコードを解決するようにISPのDNSサーバーに要求します。
ISPは自身のキャッシュをチェックし、そのレコードがキャッシュされていても「フレッシュ」と見なされている場合は、すぐにキャッシュ経由で返されます。（これはすべてのDNSキャッシュが機能する方法であり、問題のサイトのDNSサーバーに不必要に負荷をかけないようにします。）
それらのレコードがキャッシュされていなかった場合、またはキャッシュが「古くなった/古くなった」と見なされた場合、ISPは最新のレコードを再度解決する必要があることを認識しています。
次に、ISPは最新のレコードについてクエリするネームサーバーを知る必要があります。
ISPは、ドメインの信頼できるネームサーバーのキャッシュリストをチェックすることから始めます（これらは、IPとともにns1.example.com、ns2.example.comなどです）。それらのレコードがまだ新しいと見なされている場合は、ステップ8にスキップします。
キャッシュされたネームサーバーレコードが期限切れと見なされた場合、またはそのドメインのキャッシュされたレコードがなかった場合、ISPはTLDのルートネームサーバー（.comドメインの場合は.comレジストリなど）に問い合わせて、 example.comの最新のネームサーバー名/ IPペア。（ "Dig @ b.gtld-servers.net example.com"から自分で試して、TLDのルートネームサーバーがドメインについて知っていることを確認できます-ドメインが通常のcom/net/etc TLD。他のTLDはそれぞれのルートサーバーにクエリを実行する必要があります。）
TLDのルートネームサーバーalwaysは、ネームサーバーを正確な順序で返します。ランダム化は行われません。また、各ネームサーバーのIPも返します。これは「GLUE」と呼ばれ、インターネットがドメインについてまったく知る前にネームサーバーのホスト名をIPに解決する方法の「鶏と卵」の問題を解決できるようにします。さらに、それらのほとんど（最大のものであるcom/net/etcレジストリなど）は2日間のキャッシュ時間を使用するため、「ドメインXのネームサーバーのリストは何ですか？」リクエスト。これは、ネームサーバーリストを編集した後、新しいネームサーバーが世界中で知られていると安全に言えるまで2日待たなければならないという一般的な知識の源です。
ISPがexample.comのネームサーバーとそれらのIP（ns1.example.com、ns2.example.com、ns3.example.comなど）を知っている場合、ISPはそのリストからランダムサーバーを選択しますクエリを送信します。（これはいいことです。問題のサイトのすべてのDNSサーバーを不必要に攻撃する必要はなく、最初にリストされたネームサーバーに常にクエリを実行するわけではないため、負荷分散をさらに支援します。）
指定されたタイムアウト期間内にISPがそのネームサーバーから応答を受信しない場合、ISPはリスト上の別のサーバーにクエリを送信します。
応答があると、ISPはそれを独自のローカルキャッシュに保存します。キャッシュに保持される期間については、 DNSサーバーによって返される各レコードには、それに関連付けられた「ソフト有効期限」時間（秒単位）も関連付けられています。これは、クエリを実行するクライアント（ISPのDNSサーバーなど）が、考慮される前にそのレコードをキャッシュできる時間です。まだ使用可能ですが、古くなっている可能性があります。変更されていないことを確認するために、可能な場合は新しいクエリを実行してください。」個々のネームサーバーの「SOA」（Start of Authority）レコードで指定されている「ハード有効期限」時間もあります（「Dig @ ns1.example.com example.com -t soa」で自分の名前を確認できます）。そのサーバーから返されるすべてのレコードに対してグローバルな「ハード制限」を指定します。その後、ネームサーバーがダウンしていて、レコードを再度検索できない場合でも、キャッシュはそのキャッシュされたレコードを削除する必要があります（SHOULD）。通常、ソフト有効期限は30分から5時間で、ハード有効期限は通常1〜3週間です。
その徹底的な仕事の後、ISPはついに最新のDNSレコードを取得し、それをクエリを実行しているブロードバンドサブスクライバーに返すことができます。

このプロセスは、すべてのレコード検索で繰り返されます。ただし、最初のクエリだけがすべての作業を行います。その後ネームサーバーIPがキャッシュされ、ISPのキャッシュDNSサーバーへの後続のクエリはすぐにステップ8にジャンプできます。

ステップ8のランダム化については、レコードレベルで機能します。そのISPのブロードバンド加入者が次の記録について尋ねたとしましょう：

Foo.example.com
Example.com
Www.example.com
MX example.com（ISPのお客様はこのレコードを要求するべきではありませんが、これは単なる例です）

各レコードは、独自の個別の「エンティティ」として処理され、個別にキャッシュされて検索されます。したがって、サブスクライバーとISPがドメインに出会ったことがなく、キャッシュされたレコードが完全にゼロであるとします。検索は次のようになります。

Ns1.example.comを介したfoo.example.com、次にISPキャッシュに保存
Ns3.example.comを介したexample.com、次にISPキャッシュに保存
Ns2.example.com経由のwww.example.com、次にISPキャッシュに保存
Ns3.example.com経由のMX example.com、次にISPキャッシュに保存

キャッシュされたレコードがソフト期限切れになるたびにプロセスが繰り返されるため、そのレコードに対する後続のリクエストで同じサーバーが再び使用されることもわかりません。

したがって、DNSサーバーのallが互いに完全に同期し、完全にミラーリングevery DNSレコードがすべてのサーバーにわたっていることを確認することが絶対最大の目標です。あなたnever DNSクライアントがヒットするサーバーを知っており、いかなる順序にも依存することはできません。そのような事はありません。

さらに、Adam Cが述べたように、サーバーレベル（example.com）のDNSサーバー自体がNSレコードを返し、それらの順序をランダム化します。通常のDNSサーバーがランダム化することは非常に一般的です。彼らのNSレコードは、貧弱なDNS実装が常に最初に返されるnamserverを選択するというわずかなオフチャンスを記録します。ただし、ROOT TLDネームサーバー（前述）は決してリストをランダム化せず、それらのリストはドメインの解決に関して本当に重要なことです。それが、most実装がネームサーバーリストからランダムなサーバーを選択し、常に同じサーバーにヒットして過負荷になるのを防ぐ理由ですそれ。

DNSの仕組みと覚えておくべきことの入門書です。

簡単に言えば、すべてのDNSサーバーを1つのサーバーであるかのように扱い、すべてのサーバーが同等に応答できることを確認することが、人生における最高の目標になりますanyそれらでスローされる可能性のあるクエリ。

免責事項：DNSの管理よりも人生の目標が高い場合がありますが、別売りです。想像力を使用してください。 ;-）