DNSが機能するのはなぜですか？

これは、DNS（ドメインネームサービス）に関する正規の質問です。

DNSシステムの理解が正しい場合、.comレジストリには、ドメイン（www.example.com）をDNSサーバーにマップするテーブルが保持されます。

1. 利点は何ですか？なぜIPアドレスに直接マッピングしないのですか？

2. 別のIPアドレスを指すようにDNSサーバーを構成しているときに変更する必要がある唯一のレコードがDNSサーバーにある場合、プロセスがすぐに実行されないのはなぜですか？

3. 遅延の唯一の理由がDNSキャッシュである場合、それらをバイパスすることは可能ですか？そのため、リアルタイムで何が起こっているのかを確認できますか？

実際には、それよりも複雑です。1つの「ドメイン（www.mysite.com）をDNSサーバーにマップするテーブルを保持する中央レジストリ」ではなく、階層のいくつかの層があります

-すべてのトップレベルドメインのNS（ネームサーバー）レコード：中央レジストリエントリのほんのセットが含まれている（ルートサーバー）あります.com、.net、.org、.uk、.us、.au、等が。

これらのサーバーには、次のレベルのNSレコードが含まれています。一例を選ぶためには、ネームサーバのための.ukドメインだけのエントリがある.co.uk、.ac.uk英国での使用には、他方の第2レベルのゾーンを。

これらのサーバーには、次のレベルのNSレコードが含まれているだけです。例を続けると、のNSレコードがどこにあるかがわかりますgoogle.co.uk。それらのサーバー上で、最終的にホスト名www.google.co.ukとIPアドレスの間のマッピングを見つけることができます。

追加のしわとして、各レイヤーは「接着剤」レコードも提供します。各NSレコードは、ドメインをホスト名にマップします。たとえば、.ukリストのNSレコードnsa.nic.ukはサーバーの1つです。次のレベルに到達するには、isのNSレコードを見つける必要nic.ukがあり、それらnsa.nic.ukも含めることが判明しました。のIPを知る必要がありますがnsa.nic.uk、それを見つけるためにクエリを作成する必要がありnsa.nic.ukますが、IPがわかるまでクエリを作成することはできませんnsa.nic.uk...

この苦境を解決するには、サーバーは、のために.ukのためにAレコードを追加するnsa.nic.ukにADDITIONAL SECTION応答（簡潔にするためにトリミングされた以下の応答）の：

jamezpolley@li101-70:~$dig nic.uk ns

; <<>> DiG 9.7.0-P1 <<>> nic.uk ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21768
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 14

;; QUESTION SECTION:
;nic.uk.                IN  NS

;; ANSWER SECTION:
nic.uk.         172800  IN  NS  nsb.nic.uk.
nic.uk.         172800  IN  NS  nsa.nic.uk.

;; ADDITIONAL SECTION:
nsa.nic.uk.     172800  IN  A   156.154.100.3
nsb.nic.uk.     172800  IN  A   156.154.101.3

これらの余分なグルーレコードがないと、ネームサーバーを見つけるnic.uk.ことができず、そこでホストされているドメインを検索することもできません。

質問に戻るには...

a）利点は何ですか？なぜIPアドレスに直接マッピングしないのですか？

一つには、個々のゾーンの編集を配布できるようにします。のエントリを更新する場合はwww.mydomain.co.uk、mydomain.co.ukのネームサーバーの情報を編集するだけです。中央.co.ukサーバー、.ukサーバー、またはルートネームサーバーに通知する必要はありません。階層全体のすべてのレベルをマッピングする単一の中央レジストリのみが存在し、チェーン全体のDNSエントリのすべての変更について通知する必要がある場合、トラフィックは絶対に圧倒されます。

1982年以前は、これが実際に名前解決が行われた方法でした。すべての更新について1つの中央レジストリに通知さhosts.txtれ、インターネット上のすべてのマシンのホスト名とIPアドレスを含むというファイルが配布されました。このファイルの新しいバージョンは数週間ごとに公開され、インターネット上のすべてのマシンは新しいコピーをダウンロードする必要があります。1982年のかなり前に、これは問題になり始めていたため、より分散されたシステムを提供するためにDNSが発明されました。

別のこととして、これは単一障害点になります。単一の中央レジストリがダウンすると、インターネット全体がオフラインになります。分散システムがあるということは、障害がインターネット全体ではなく、インターネットの小さなセクションにのみ影響することを意味します。

（余分な冗長性を提供するには、ルートゾーンを提供するサーバーのクラスターが実際に13個あります。トップレベルドメインレコードへの変更はすべて13個にプッシュする必要があります。世界中の任意のホスト名に...）

b）別のIPアドレスを指すようにDNSサーバーを構成しているときに変更する必要がある唯一のレコードがDNSサーバーにある場合、プロセスがすぐに行われないのはなぜですか？

DNSは多くのキャッシュを利用して、物事を高速化し、NSesの負荷を軽減するためです。キャッシュがなければ、あなたが訪問した毎回google.co.ukお使いのコンピュータはのためのサーバーをルックアップするために、ネットワークに出て行かなければならないだろう.uk、その後、.co.ukその後、.google.co.ukその後、www.google.co.uk。これらの答えは実際にはあまり変わらないので、毎回調べるのは時間とネットワークトラフィックの無駄です。代わりに、NSがコンピューターにレコードを返す場合、TTL値が含まれ、コンピューターに結果を数秒間キャッシュするように指示します。

例えば、のためのNSレコードは.uk2日- 172800秒のTTLを持っています。Googleはさらに保守的です。NSレコードgoogle.co.ukのTTLは4日間です。迅速に更新できることに依存しているサービスは、はるかに低いTTLを選択できます。たとえば、telegraph.co.ukNSレコードのTTLはわずか600秒です。

ゾーンの更新をほぼ瞬時にしたい場合は、TTLを好きなだけ下げることができます。設定を低くすると、クライアントがレコードを頻繁に更新するため、サーバーに表示されるトラフィックが多くなります。クライアントがクエリを実行するためにサーバーに接続する必要があるたびに、ローカルキャッシュで回答を検索するよりも遅いため、これにより多少の遅延が発生します。そのため、高速更新と高速サービスのトレードオフも考慮する必要があります。

c）遅延の唯一の理由がDNSキャッシュである場合、それらをバイパスすることは可能ですか？そのため、リアルタイムで何が起こっているかを確認できますか

はい、手動digまたは同様のツールでテストしている場合、これは簡単です-どのサーバーに連絡するかを伝えてください。

キャッシュされた応答の例を次に示します。

jamezpolley@host:~$dig telegraph.co.uk NS

; <<>> DiG 9.7.0-P1 <<>> telegraph.co.uk NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36675
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;telegraph.co.uk.       IN  NS

;; ANSWER SECTION:
telegraph.co.uk.    319 IN  NS  ns1-63.akam.net.
telegraph.co.uk.    319 IN  NS  eur3.akam.net.
telegraph.co.uk.    319 IN  NS  use2.akam.net.
telegraph.co.uk.    319 IN  NS  usw2.akam.net.
telegraph.co.uk.    319 IN  NS  use4.akam.net.
telegraph.co.uk.    319 IN  NS  use1.akam.net.
telegraph.co.uk.    319 IN  NS  usc4.akam.net.
telegraph.co.uk.    319 IN  NS  ns1-224.akam.net.

;; Query time: 0 msec
;; SERVER: 97.107.133.4#53(97.107.133.4)
;; WHEN: Thu Feb  2 05:46:02 2012
;; MSG SIZE  rcvd: 198

ここのフラグセクションにはaaフラグが含まれていないため、この結果は信頼できるソースから直接ではなくキャッシュからのものであることがわかります。実際、それ97.107.133.4はLinodeのローカルDNSリゾルバーの1つであるから発生したことがわかります。答えが私の近くのキャッシュから提供されたという事実は、答えを得るのに0ミリ秒かかったことを意味します。しかし、すぐにわかるように、その速度に対して支払う代償は、答えがほぼ5分遅れているということです。

Linodeのリゾルバーをバイパスしてソースに直接進むには、これらのNSの1つを選択し、digに直接連絡するように指示します。

jamezpolley@li101-70:~$dig @ns1-224.akam.net telegraph.co.uk NS

; <<>> DiG 9.7.0-P1 <<>> @ns1-224.akam.net telegraph.co.uk NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23013
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;telegraph.co.uk.       IN  NS

;; ANSWER SECTION:
telegraph.co.uk.    600 IN  NS  use2.akam.net.
telegraph.co.uk.    600 IN  NS  eur3.akam.net.
telegraph.co.uk.    600 IN  NS  use1.akam.net.
telegraph.co.uk.    600 IN  NS  ns1-63.akam.net.
telegraph.co.uk.    600 IN  NS  usc4.akam.net.
telegraph.co.uk.    600 IN  NS  ns1-224.akam.net.
telegraph.co.uk.    600 IN  NS  usw2.akam.net.
telegraph.co.uk.    600 IN  NS  use4.akam.net.

;; Query time: 9 msec
;; SERVER: 193.108.91.224#53(193.108.91.224)
;; WHEN: Thu Feb  2 05:48:47 2012
;; MSG SIZE  rcvd: 198

今回は、結果がソースから直接提供されたことを確認できます- aa結果が信頼できるソースからのものであることを示すフラグに注意してください。以前の例では、結果はローカルキャッシュから取得されたため、aaフラグがありません。このドメインの信頼できるソースがTTLを600秒に設定していることがわかります。ローカルキャッシュから以前に取得した結果のTTLはわずか319秒でした。これは、キャッシュに（600〜319）秒（約5分）座っていたことがわかります。

ここでのTTLはわずか600秒ですが、一部のISPはDNSリゾルバーに結果をより長い時間（場合によっては24時間以上）キャッシュさせることにより、トラフィックをさらに削減しようとします。DNSの変更がどこにでも表示されないことを前提とするのが伝統的です（これが本当に必要なのかどうかわからないが、安全な方法です） 24〜48時間のインターネット。

a）世界中のIP->ホスト名マッピングの数は本当に大きい。このシステムは、すべてのサブドメインとMXレコード、およびその他すべてのDNSレコードをホストする責任をドメイン名の所有者に分配します。これがほとんどドメイン名のポイントでした。 別の.comレジストリ.ukが保持できるレジストリによって保持されます。同様にexample.com、otherexample.com個別にホストできるため、リソースを分散できます。

b）キャッシュされているため、DNSホストでのヒット数が、それ以外の場合の数分の1に減少します。デフォルトでは、レコードはキャッシュに2日間保存されてから破棄されます。これは、レコードのTTL（有効期間）を変更することで変更できます。

c）本当に短いTTLを設定することにより、レコードのキャッシュを効果的に停止できます。ダイナミックDNSに使用しない限り、これはお勧めしません。キャッシュにより、DNSサーバーのヒットが大幅に減少します。空中から推測された数を選択するために、要求の95％をノックオフすることについて話します。

* nixシステムを使用している場合は、Dan Bernsteinのdjbdnsのコピーをhttp://cr.yp.to/djbdns.htmlからダウンロードし、dnstraceプログラムを実行して、再帰クエリシステムの動作を確認します。その非常に有益です。

a）考えられるドメイン名の数は、1つのサーバーが処理するには大きすぎます。そして.comだけではありません。.net、.org、.se、.info、その他多数あります。それに加えて、サブドメインの責任を委任することができます（これは事実上comそうです）。DNSの集中性が低いため、管理がすべて容易になります。

b）必要なリクエストの数を最小限にするために、ユーザーからあなたまでの途中のマシンにはDNSキャッシュがあります。たとえば、SFからページを取得するたびに、「serverfault.com」のアドレスの要求でネットワークをスパムすることを防ぎます。これらのサーバーは「ドメインが存在しません」という結果をキャッシュすることもできるため、新しいドメインでさえ表示されるまでに時間がかかることがあります。

c）キャッシュを無効にすることはできますが、マシンとyourdomain.comのDNSサーバーの間に他のDNSサーバーが存在することがよくあります。たとえば、ISPのDNSサーバーは、できる限りキャッシュしようとします。ネット上で比較的迅速に更新されるレコードは、TTLが短いレコードのみです（基本的には「数秒間しか有効ではありません。その後、現在の情報を再度求めてください」）。ただし、TTLが非常に高いのは、ドメインを担当するサーバーが作業の一部を他のサーバーにオフロードできるようにするためです。Webサイトへのすべてのヒットに対して、1つまたは2つのrinky-dink DNSサーバーにすべてのネットがアクセスしている場合、/。、diggなどで2番目に誰かがあなたのサイトを見たとき、それらはほとんど使用できません。