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

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

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

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

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

次に、一部のDNS実装は各NSを並列にクエリし、最初に応答した方を使用します。他の人はそれぞれをヒットし、いくつかのリクエストで最速を決定し、そのリクエストを使用します。または、単にラウンドロビンにすることもできます。

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

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

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

これは無回答のものであり、取り上げる決定的なものはありませんが、上記を考えると、特定のドメインの動作を決定する唯一の真の方法はテストすることです。

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

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

さらに、Adam Cが述べたように、サーバーレベル（example.com）のDNSサーバー自体がNSレコードを返し、それらの順序をランダム化できます。貧弱なDNS実装が最初に返されたnamserverを常に選択するというわずかな偶然で、通常のDNSサーバーがNSレコードをランダム化することは非常に一般的です。ただし、ルートTLDネームサーバー（前述）はリストをランダム化することはありません。ドメインの解決に関しては、リストが本当に重要です。そのため、ほとんどの実装では、常に同じサーバーにアクセスして過負荷になることを避けるために、ネームサーバーリストからランダムなサーバーを選択します。

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

• 要するに：彼らはただ一つのサーバであるかのように彼らは答えるのすべて平等に能力があることを確認するために生活の中でそれをあなたの最高の目標を作り、DNSサーバーのすべてを扱うすべての彼らにスローされる可能性があるクエリを。

免責事項：DNSを管理するよりも人生の目標は高いかもしれませんが、別売りです。想像力を働かせてください。;-)