DNS とは？#
DNS、正式名称は Domain Name System、つまりドメイン名システムです。
DNS の役割#
DNS の役割は、ドメイン名を IP アドレスに変換することです。
DNS の意義#
DNS の役割は、ドメイン名を IP アドレスに変換することで、人々が複雑な数字を記憶する必要がなく、意味のあるドメイン名を記憶できるようにすることです。
DNS はどのように機能するのか？#
私たちは、DNS の作業プロセスを簡単に次のように見ることができます：大きな図書館で本を探す図書館員。
ウェブページの読み込みに関与する 4 つのサーバー#
DNS 再帰的リゾルバー（DNS Recursive Resolver）
- 役割：図書館員
- DNS 再帰的リゾルバーは、Web ブラウザなどのアプリケーションを通じてクライアントコンピュータのクエリを受け取るサーバー / コンピュータです。リゾルバーは一般的に、クライアントの DNS クエリを満たすために他のリクエストを発行する責任があります。
ルートネームサーバー（Root nameserver）
- 役割：異なる書架へのインデックス
- ルートネームサーバーは、ホスト名を IP アドレスに変換する最初のステップです。
TLD ネームサーバー（Top Level Domain Server）
- 役割：図書館内の特定の書架
- サーバーはホスト名の最後の部分（例えば、example.com の中で、TLD サーバーは「com」）をホストしています。
権威あるネームサーバー（authoritative nameserver）
- 役割：書架上の辞書
- 権威あるネームサーバーは、ドメイン名サーバーのクエリの最終地点です。権威あるネームサーバーが要求されたレコードにアクセスできる場合、リクエストされたホスト名の IP アドレスを初期リクエストを発行した DNS リゾルバー（図書館員）に返します。
DNS ルックアップのステップ#
DNS クエリプロセス
- ユーザーが Web ブラウザに「example.com」と入力し、クエリがインターネットに送信され、DNS 再帰的リゾルバーが受信します。
- 次に、リゾルバーは DNS ルートネームサーバー（.）にクエリします。
- ルートサーバーは、トップレベルドメイン（TLD）DNS サーバー（例えば.com または.net）のアドレスを使用してリゾルバーに応答します。example.comを検索する際、私たちのリクエストは.com TLD を指します。
- リゾルバーは.com TLD にリクエストを送信します。
- TLD サーバーは、そのドメインのドメインネームサーバーexample.comの IP アドレスを使用して応答します。
- 再帰的リゾルバーは、ドメインのドメインネームサーバーにクエリを送信します。
- ドメインネームサーバーはexample.comの IP アドレスをリゾルバーに返します。
- その後、DNS リゾルバーは最初にリクエストされたドメインの IP アドレスを使用して Web ブラウザに応答します。（この時点でブラウザは IP を取得したことになります）
- ブラウザはその IP アドレスにHTTPリクエストを送信します。
- その IP にあるサーバーは、ブラウザに表示されるウェブページを返します。
DNS クエリにはどのような種類がありますか？#
-
再帰クエリ
再帰クエリでは、クライアントが DNS サーバー（一般的には DNS 再帰的リゾルバー）にリクエストされたリソースレコードを使用して応答するよう要求します。リゾルバーがそのレコードを見つけられない場合は、エラーメッセージを返します。
-
反復クエリ
DNS クライアントは、DNS サーバーが提供できる最良の応答を返すことを許可します。クエリされた DNS サーバーがクエリ名と一致しない場合、サーバーはより低いレベルのドメインスペースに権威を持つ DNS サーバーへの参照を返します。その後、DNS クライアントは参照アドレスにクエリを行います。このプロセスは、エラーが発生するかタイムアウトするまで、クエリチェーン内の他の DNS サーバーを使用して続きます。
-
非再帰クエリ
DNS リゾルバークライアントが DNS サーバーにアクセス権のあるレコードを取得するためにクエリを行うときに通常行われます。これは、そのレコードに権威があるか、またはそのレコードがキャッシュ内に存在する場合です。DNS サーバーは通常、DNS レコードをキャッシュして、さらなる帯域幅の消費と上流サーバーの負荷を防ぎます。
DNS キャッシュとは何か、キャッシュはどこにあり、役割は何か、キャッシュはどのように機能するのか？#
キャッシュの目的は、データを一時的に特定の場所に保存し、その後の応答でその場所に保存されたデータを直接返すことができるようにすることです。DNS の高速キャッシュは、リクエストクライアントに近い場所にデータを保存し、DNS クエリを早期に解決し、DNS ルックアップチェーン内のさらなる追加クエリを回避することで速度を向上させ、読み込み時間を短縮します。
DNS データは異なる場所にキャッシュされ、各場所のストレージデータの有効期限は TTL（生存時間）によって決まります。
ブラウザ DNS キャッシュ#
現代の Web ブラウザは、デフォルトで DNS レコードを一定期間キャッシュするように設計されています。目的は明らかです；Web ブラウザに近い DNS キャッシュの方が、キャッシュを確認し、IP アドレスに正しいリクエストを送信するために必要な処理ステップが少なくなります。DNS レコードへのリクエストを発行するとき、ブラウザキャッシュはリクエストされたレコードに対して最初に確認される場所です。
オペレーティングシステム DNS キャッシュ#
オペレーティングシステムレベルの DNS リゾルバーは、DNS クエリがコンピュータを離れる前の第二のステップであり、ローカルの最後のステップでもあります。オペレーティングシステム内でこのクエリを処理するために設計されたプロセスは通常「スタブリゾルバー」または DNS クライアントと呼ばれます。スタブリゾルバーがアプリケーションからのリクエストを受け取ると、まず自分のキャッシュを確認して、そのレコードがあるかどうかを確認します。ない場合、ローカルネットワーク外の DNS クエリ（再帰フラグが設定されている）をインターネットサービスプロバイダー（ISP）内部の DNS 再帰的リゾルバーに送信します。
ISP 内の再帰的リゾルバーが DNS クエリを受け取ると、要求されたホストから IP アドレスへの変換が ISP のローカル永続層に保存されているかどうかを確認します。
Hosts ファイル#
ローカルの hosts ファイル
高速キャッシュの仕組み#
DNS リゾルバーは、IP アドレスクエリの応答を一定期間保存します。これにより、リゾルバーは将来のクエリに対してより迅速に応答でき、典型的な DNS リゾルバープロセスに関与する多くのサーバーと通信する必要がなくなります。指定された生存時間 (TTL)が許可されている限り、DNS リゾルバーはその応答をキャッシュに保存します。
キャッシュなし：
キャッシュあり：
DNS A レコードとは何か#
Address Record. ドメインの IP を示します。
「A」は「Address」（アドレス）を表し、これは最も基本的な DNS レコードタイプで、特定のドメインの IP アドレスを示します。例えば、[cloudflare.com](http://cloudflare.com)の DNS レコードを取得すると、A レコードが返す IP アドレスは：104.17.210.9 です。
「AAAA」は IPv6 アドレスを表します。
DNS A レコードを使用するタイミング#
A レコードの最も一般的な用途は、IP アドレスの検索で、ドメイン名と IPv4 アドレスを一致させることです。
MX レコードとは何か#
Mail Exchanger. メールを関連するサーバーにルーティングするのに役立ちます。
DNS「メール交換」（MX）レコードは電子メールをメールサーバーに向ける役割を果たします。MX レコードは、シンプルメール転送プロトコル（SMTP、すべての電子メールの標準プロトコル）に基づいて電子メールをルーティングする方法を示します。CNAME レコードと同様に、MX レコードは常に別のドメインを指す必要があります。
メール転送エージェント（MTA）ソフトウェアが MX レコードをクエリします。ユーザーが電子メールを送信すると、MTA は電子メールの受信者のメールサーバーを特定するために DNS クエリを送信します。MTA は、優先度の高いドメインから SMTP 接続を確立します（上記の最初の例では mailhost1 です）。
NS レコードとは何か#
Name server Record. 権威あるサーバーを示します。
NS は「ネームサーバー」を表し、ネームサーバーレコードはどのDNSサーバーがそのドメインに対して権威を持つかを示します（つまり、どのサーバーが実際のDNS レコードを含んでいるか）。基本的に、NS レコードはインターネットがドメインのIP アドレスをどこで見つけるかを教えます。1 つのドメインには通常、複数の NS レコードがあり、これらのレコードはそのドメインの主要および補助ネームサーバーを示すことができます。正しく構成された NS レコードがないと、ユーザーはウェブサイトやアプリケーションを読み込むことができません。
CNAME レコードとは何か#
Canonical name. ドメインまたはサブドメインを別のドメインにポイントします。
ドメイン名またはサブドメインが別のドメイン名のエイリアスである場合、「CNAME」（Canonical Name）レコードを使用してA レコードの代わりに使用します。すべての CNAME レコードは、IP アドレスではなく、ドメインを指す必要があります。宝探しゲームを想像してみてください。各手がかりが別の手がかりを指し、最後の手がかりが宝物を指します。CNAME レコードを持つドメインは、別の手がかり（CNAME レコードを持つ別のドメイン）または宝物（A レコードを持つドメイン）を指す手がかりのようなものです。
例えば、blog.example.com の CNAME レコードの値が「example.com」（「blog」は含まれません）であると仮定します。これは、DNSサーバーが blog.example.com のDNS レコードをクリックすると、実際には example.com への別の DNS ルックアップをトリガーし、その A レコードを介して example.com の IP アドレスを返すことを意味します。この場合、私たちは example.com が blog.example.com の正規名（または真の名前）であると言います。
一般的な誤解は、CNAME レコードは常にその指すドメインが存在するウェブサイトに解決される必要があるということですが、実際にはそうではありません。CNAME レコードは、クライアントをルートドメインと同じ IP アドレスに指し示すだけです。** クライアントがその IP アドレスにアクセスした後、Web サーバーは URL を適切に処理します。** 例えば、blog.example.comはexample.comを指す CNAME を持っているかもしれませんが、クライアントはexample.comの IP アドレスに向けられます。しかし、クライアントが実際にその IP アドレスに接続すると、Web サーバーは URL を確認し、それがblog.example.comであることを発見し、ホームページではなくブログページを提供します。（同じ IP で、Web サーバーはルーティングに基づいてコンテンツを表示します）
ドメイン名とは何か#
ドメイン名は、クライアントソフトウェアがウェブサイトにアクセスするためにマッピングされたテキスト文字列で、数字のIP アドレスに対応します。簡単に言えば、ドメイン名はユーザーが特定のウェブサイトにアクセスするためにブラウザウィンドウに入力するテキストです。例えば、Google のドメイン名は「google.com」です。
ドメイン名の構成要素#
ドメイン名は通常、2 つまたは 3 つの部分に分かれており、各部分はドットで区切られています。右から左に読むと、ドメイン名の識別子は最も広範なものから最も具体的なものへと進みます。ドメイン名の最後のドットの右側の部分はトップレベルドメイン (TLD)です。これには「.com」、「.net」、「.org」などの「一般的な」TLD や、「.uk」や「.jp」などの特定の国 / 地域の TLD が含まれます。
TLD の左側は第二レベルドメイン（2LD）であり、2LD の左側に何かがある場合は第三レベルドメイン（3LD）と呼ばれます。例を見てみましょう：
Google のアメリカのドメイン「google.com」について：
- 「.com」は TLD（最も広範）
- 「google」は 2LD（最も具体）
ドメイン名と URL の違い#
統一リソースロケータ（URL）は、時折ウェブアドレスとも呼ばれ、サイトのドメイン名と、転送プロトコルやパスなどの他の情報を含みます。例えば、https://cloudflare.com/learning/の中で、「cloudflare.com」はドメイン名であり、「https」はプロトコルであり、「/learning/」はウェブサイト上の特定のページへのパスを指します。
DNS に関与する攻撃にはどのようなものがありますか？#
DNS スプーフィング / キャッシュポイズニング
これは、偽の DNS データを DNS リゾルバーのキャッシュに導入する攻撃であり、リゾルバーがドメインの誤ったIP アドレスを返すことになります。トラフィックは悪意のあるコンピュータや攻撃者が望む他の場所に転送される可能性があり、正しいウェブサイトには向かわなくなります。
例を挙げると、卒業クラスの学生がいたずらをして、キャンパス内のすべての教室番号を入れ替え、新入生がキャンパスのレイアウトを知らずに次の日に迷子になり、間違った教室に現れることになります。今、間違った教室番号（レコード）がキャンパスの案内板（ディレクトリ）に入っていると想像してみてください。学生たちは間違った教室に向かい続け、誰かが最終的に気づいてディレクトリを修正するまで続きます。
DNS リゾルバーは通常、キャッシュ内のデータを検証できないため、誤った DNS 情報はキャッシュ内に保持され、生存時間（TTL）が切れるか手動で削除されるまで保持されます。DNS ポイズニングを引き起こす多くの脆弱性がありますが、主な問題は DNS がはるかに小さなインターネットのために構築されており、信頼の原則に基づいていることです（非常に BGP に似ています）。より安全な DNS プロトコルであるDNSSECは、これらの問題のいくつかを解決することを目的としていますが、まだ広く採用されていません。
DNS トンネリング
この攻撃は、他のプロトコルを使用して DNS クエリと応答を通じてトンネルを確立します。攻撃者は、SSH、TCPまたはHTTPを使用して、ほとんどのファイアウォールに気づかれずに悪意のあるソフトウェアや盗まれた情報を DNS クエリに渡すことができます。
DNS ハイジャック
DNS ハイジャックでは、攻撃者がクエリを他のドメインネームサーバーにリダイレクトします。これは、悪意のあるソフトウェアや無許可の DNS サーバーの変更によって実現されます。結果は DNS スプーフィングと似ていますが、これは全く異なる攻撃であり、その目的はドメインネームサーバー上のウェブサイトのDNS レコードであり、リゾルバーのキャッシュではありません。
DNS キャッシュをどのように中毒させるか#
攻撃者は、偽のDNS ドメインサーバーを介して DNS リゾルバーにリクエストを送信し、DNS リゾルバーがドメインネームサーバーにクエリを行う際に偽の応答を生成することで DNS キャッシュを中毒させることができます。これは、DNS サーバーがTCPではなくUDPを使用しているため可能であり、現在DNS 情報の検証が行われていないためです。
なぜ攻撃者はリクエストと応答を簡単に偽造できるのか？
DNS リクエストと応答は UDP プロトコルを使用しており、TCP プロトコルではないため、UDP は簡単に偽造できます。攻撃者は UDP を介してメッセージを送信し、偽のヘッダーデータを使用して合法的なサーバーからの応答であるかのように装うことができます。
DNS リゾルバーが偽造された応答を受け取ると、それを無条件に受け入れ、キャッシュします。なぜなら、これらの情報が正しいかどうか、合法的なソースからのものであるかどうかを検証できないからです（UDP は一方向です）。
中毒した DNS キャッシュ
TTL の役割#
TTL の設定は更新に影響を与えます。例えば、TTL が 30 秒に設定されている場合、2 回目の DNS クエリリクエストが期限切れになると、キャッシュが期限切れになり、最新のバージョンが得られます。TTL が 300000 秒に設定されている場合、DNS 解析レコードが変更されても、すぐには変更が反映されず、DNS キャッシュが期限切れになるのを待たなければなりません。
複数のデバイス / サービスが同じドメインを共有する方法（負荷分散）#
2 つの DNS 解析を作成し、同じドメインが異なる IP を指すようにします。
このドメインにアクセスすると、DNS クエリリクエストがトリガーされ、DNS リゾルバー（Resolver）は 2 つの一致するレコードを見つけます。それは、次のいずれかの方法でそれらを返す順序を決定します。
- 受け取った順序でレコードを返す
- 毎回受け取ったリクエストで順序を変更する
- ランダムに順序を選択する
- その他の何か