1.はじめに
タイトルそのまま。
CloudFlareの公式ドキュメントがわかりやすすぎるので、興味のある範囲を読んで写経する記事です。
目新しいことはありませんのでご了承ください…！
2.公式ドキュメントをご紹介
とはいえたまたまこの記事に辿り着いてしまった方もいると思うのでご紹介です！
3.DNSとはなんぞ
Domain Name Systemはいわばインターネットの電話帳。
ユーザーはオンラインで情報にアクセスする時、sosat.comのようなドメイン名を使用する。
WebブラウザはIP(Internet Protcol)で通信を行う。
DNSは、ブラウザがインターネットリソースを読み込めるように、ドメイン名をIPに変換する。
インターネットに接続された個々のデバイスに一意のIPアドレスがあり、このIPアドレスを使用して、他のデバイスがそのマシンを検出する。
DNSサーバーの登場で、192.168.1.1とかIPv6の数字文字の羅列を覚える必要が無くなった。
この絵めっちゃ好き
4.DNSの仕組みとは
DNS解決のプロセスには、sosat.comのようなホスト名をコンピューターに優しいIPアドレスに変換することが含まれる。
IPアドレスはインターネットの各デバイスに与えられ、そのアドレスは適切なインターネットデバイスを見つけるために必要。
(特定の家を見つけるために番地が使われるのと同じ)
ユーザーがWebページを読み込む場合、ユーザーがWebブラウザに入力したsosat.comを、sosat.comのWebページを見つけるために必要な機械が読み取れるアドレスに変換する必要がある。
DNS解決のプロセスを理解するためには、DNSクエリを処理するさまざまなハードウェア構成部品に関して学習することが重要。
Webブラウザーの場合、DNSルックアップ(IPをドメイン名に変換したり、その逆を行ったりすること
)は舞台裏で行われ、ユーザーのコンピューターからは最初のリクエスト以外のやりとりは一切必要ない。
5.Webページの読み込みには4つのDNSサーバーが関与している
-
DNSリカーサー(再帰リゾルバー)
リカーサーは、図書館のどこかにある特定の本を探すことを求められる司書に似ているらしい。
DNSリカーサーは、Webブラウザのようなクライアントマシンからアプリケーションを介してクエリを受け取るためのサーバー。
一般的に、リカーサーはクライアントからのDNSクエリに応えるためにリクエストを追加する。 -
ルートネームサーバー
ルートサーバーは、人間が読めるホスト名をIPアドレスに変換(解決)するための最初のステップ。
図書館の目録に似てて本棚を示すみたいな。
通常、更に特定の場所への参照として機能する。 -
TLDネームサーバー
もしかしてDeepl使ってるのか…？と思ったり。
さておき、最上位のドメインサーバー(TLD)は図書館の特定の本棚と考えることができる。
このネームサーバーは特定のIPアドレスの検索を引き継ぎ、ホスト名の最後の部分(sosat.comではTLDサーバーはcomにあたる)をホストする。 -
権威ネームサーバー
この最終ネームサーバーは本棚にある辞書に例えることができ、特定の名前をその定義に翻訳できる。？
権威ネームサーバーは、ネームサーバークエリの最後の段階。
権威ネームサーバーが要求されたレコードへのアクセス権を持つ場合、要求されたホスト名のIPアドレスを、最初のリクエストをおこなったDNSリカーサー(図書館司書)に返す。
6.権威DNSサーバーと再帰DNSリゾルバーの違い
どちらの概念も、DNSインフラストラクチャに不可欠なサーバー(サーバーグループ)を指す。
しかし、それぞれ異なる役割を果たし、DNSクエリのパイプライン内部で異なる場所に位置している。
違う点と言えば、再帰リゾルバーはDNSクエリの始めにあり、権威ネームサーバーはクエリの最後にあること。
6-1.再帰DNSリゾルバ
再帰リゾルバーは、クライアントからの再帰リクエストに応答し、DNSレコードを追跡するために時間をかけるコンピュータプログラム。。？？？
要求されたレコードのある権威ネームサーバーに達するまで一連のリクエストを行う。
(レコードが見つからない場合はタイムアウトするかエラーを返す)
再帰DNSリゾルバは、クライアントに応答するレコードを見つけるために、必ずしも何度もリクエストを送信する必要はない。
キャッシュは、DNSルックアップから以前要求されたことがあるリソースレコードを提供することで、必要なリクエスト応答を素早く送信するデータ永続化プロセスである。
6-2.権威DNSサーバー
権威DNSサーバーは、DNSリソースレコードを実際に保持し、その責任を負うサーバーである。
問い合わせされたリソースレコードで応答するDNSルックアップチェーンの一番下にあるサーバーであり、最終的に、リクエストしているWebブラウザがWebサイトやその他のWebリソースにアクセスするために必要なIPアドレスに到達できるようにする。
権威ネームサーバーは、特定のDNSレコードの信頼できる唯一の情報源であるため、別のソースを照会する必要がなく、自身のデータからのクエリを満たすことができる。
foo.sosat.comなどのサブドメインに対するクエリの場合、権威ネームサーバーの後のシーケンスにネームサーバーが追加されることに注意する。
このネームサーバーはサブドメインのCNAMEレコードを保存する。
7.DNSルックアップとは
多くの場合、DNSルックアップ情報は、クエリを行っているコンピューター内でローカルにキャッシュされるか、DNSインフラストラクチャでリモートにキャッシュされる。
通常、DNSルックアップには8つのステップがある。
DNS情報がキャッシュされると、DNSルックアッププロセスから手順がスキップされ、より迅速になる。
7-1.DNSルックアップの8つのステップ
-
ユーザーはexsample.comをWebブラウザに入力する。クエリはインターネットに送信され、DNS再帰リゾルバーがクエリを受け取る。
-
次に、リゾルバーはDNSルートサーバー(.)へのクエリを行う。
-
ルートサーバーは、ドメインの情報を保存するTLDサーバー(.comとか.net)のアドレスでリゾルバーに応答する。exsample.comを検索する場合、リクエストは.com TLDに向けられる。
-
次に、リゾルバーは.com TLDに要求を行う。
-
次にTLDサーバーが応答し、ドメインのネームサーバーのIPアドレス「exsample.com」を送信する。
-
最後に、再帰リゾルバーはドメインのネームサーバーへのクエリを送信する。
-
その後、ネームサーバーからリゾルバーに応答し、「exsample.com」のIPアドレスが送信される。
-
次に、DNSリゾルバーがWebブラウザに応答し、最初にリクエストされたドメインのIPアドレスを送信する。
DNSルックアップの8ステップを完了し、exsample.comのIPアドレスを取得すると、ブラウザはWebページにリクエストを送信することができるようになる。 -
ブラウザはIPアドレスに対してhttpリクエストを行う。
-
このIPを持つサーバーは、ブラウザにレンダリングするWebページを送信する。
8.DNSリゾルバーとは？
DNSリゾルバーは、DNSルックアップの最初の目的地であり、最初の要求を行ったクライアントの対応を行う。
リゾルバーは一連のクエリを開始し、最終的にURLが必要なIPに変換される。
※一般的な非キャッシュDNSルックアップには、再帰クエリと反復クエリの両方が含まれる
再帰DNSクエリと、再帰DNSリゾルバーを区別することは重要。
クエリは、クエリの解決を必要とするDNSリゾルバーに対して行われるリクエストを指す。
DNS再帰リゾルバーは、再帰クエリを受信し、必要なリクエストを送信して応答を処理するコンピュータプログラムである。
9.DNSクエリの種類について
一般的なDNSルックアップでは、3種類のクエリが発生する。
これらのクエリを組み合わせて使用することにより、DNS解決のための最適化されたプロセスにより、移動距離が短縮される。
理想的な状況では、キャッシュされたレコードデータが利用でき、DNSネームサーバーが非再帰クエリを返すことができる。
9-1.3種類のDNSクエリ
1.再帰クエリ
再帰クエリでは、DNSクライアントが、DNSサーバー(通常はDNS再帰リゾルバー)に対して、要求されたリソースレコードをクライアントに応答すること、またはリゾルバーがレコードを見つけることができない場合にエラーメッセージを応答することを要求する。
2.反復クエリ
この状況では、DNSクライアントはDNSサーバーが可能な限りで最善の回答を返せるようにする。
DNSサーバー内でクエリ名に一致するものが無い場合は、より低いレベルのドメインネームスペースの権威DNSサーバーへの参照が、応答として送信される。
その後、DNSクライアントから、参照されたアドレスへのクエリを行う。
このプロセスは、クエリチェーンのDNSサーバーを辿り、エラーかタイムアウトのいずれかが生じるまで続く。
3.非再帰クエリ
通常、DNSリゾルバクライアントがDNSサーバーにクエリを送信し、送信先がそのレコードの権威サーバーであった場合やレコードがキャッシュ内部に既に存在した場合に行われる。
通常、DNSサーバーはDNSレコードをキャッシュで保存し、帯域幅の消費を防止し、上流サーバーで読み込めるようにしている。
10.DNS Cachingとは？ DNS Cachingはどこで行われるか？
キャッシュ保存の目的は、データを一時的に保存し、データリクエストのパフォーマンスおよび信頼性を改善すること。
DNS Cachingは、リクエストを行ったクライアントに近いデータを保存してDNSクエリを迅速に解決するため、DNSルックアップチェーンのそれ以上のクエリが不要になる。
これによって読み込み時間が改善し、帯域幅/CPU消費が削減される。
DNSデータはキャッシュとして様々な場所に保存できる。
それぞれの場所にDNSレコードを一定時間保存し、保存時間はTTL(Time to Live)によって決まる。
10-1.ブラウザDNSキャッシュ
最新のWebブラウザは、デフォルトでDNSレコードを一定時間キャッシュするように設計されている。
ここでの目的は明らかで、DNSキャッシュがWebブラウザに近いほど、キャッシュをチェックしてIPアドレスに正しいリクエストを行うために必要な処理ステップが少なくなる。
DNSレコードの要求が行われると、要求されたレコードを最初にチェックする場所はブラウザのキャッシュになる。
Chromeでは、chrome://net-internals/#dnsからDNSキャッシュのステータスを見ることができる。
10-2.OSレベルのDNSキャッシュ
OSレベルのDNSリゾルバーは、DNSクエリがマシンを離れる前の２番目で最後のローカルの目的である。。？w
このクエリを処理するように設計されたオペレーティングシステム内のプロセスは、一般に「スタブリゾルバー」またはDNSクライアントと呼ばれる。
スタブリゾルバーは、アプリケーションからリクエストを取得すると、まず自身のキャッシュをチェックして、レコードがあるかどうかを確認する。
もし無い場合は、ローカルネットワークの外側で、ISP内部のDNS再帰リゾルバーにDNSクエリ(再帰フラグを設定)を送信する。
ISP内部の再帰リゾルバーが、DNSクエリを受け取ると、前の全てのステップと同様に、要求されたホストからIPアドレスに変換したものがローカルの永続層内部に既にあるかどうかをチェックする。
再帰リゾルバーにはキャッシュされたレコードのタイプに応じた追加機能もある。
- リゾルバーにAレコードがなく、権威ネームサーバーのNSレコードがある場合、DNSクエリのいくつかのステップを省略して、これらのネームサーバーに直接クエリする。このショートカットは、ルートおよび.comネームサーバー(example.comの検索)からのルックアップを防止して、DNSクエリの解決を迅速に行うのに役立つ。
- リゾルバーにNSレコードが無い場合はルートサーバーを省略し、TLDサーバー(このケースでは.com)へのクエリを送信する。
- 万が一、リゾルバーにTLDサーバーをポイントするレコードが無い場合はルートサーバーにクエリが送信される。こうした場合は、通常DNSキャッシュが削除された後に行われる。
11.おわりに
10-2.で書いてることがさっぱりわからないw
まあ今はこれでOK、必要になった時にまた。
CloudFlareのドキュメントはまだまだ大量にあるので、コンプするまで続けます！
以上です。