【基礎から学び直すITインフラ入門】#6 DNS
6記事目。次の記事あたりでネットワーク系の記事はひと段落の予定です。次はセキュリティかOS(Linux)か。全然別件でAI関連のお仕事も入りそうだから、連載と関係なくその記事もまとめるか、、、
ひとまず、始めます。前回記事は ↓ から。
はじめに
前回は、ルーティングについて学びました。パケットがどのように経路を選択されて転送されるのか、静的ルーティングと動的ルーティングの違いなどを理解しました。
今回は、DNS(Domain Name System)について見ていきます。普段「google.com」や「amazon.co.jp」といったドメイン名でWebサイトにアクセスできるのは、このDNSのおかげです。その仕組みを詳しく学びましょう。
DNSの基礎
DNSとは
DNSは、ドメイン名とIPアドレスを相互に変換するシステムです。
google.comのような覚えやすい名前でWebサイトにアクセスしますが、実際にネットワーク上で通信するには 142.250.207.46 のようなIPアドレスが必要です。人間にとってIPアドレスは覚えにくく、サーバーを移転してIPアドレスが変わった場合、アクセスができなくなります。
DNSは名前と連絡先(IPアドレス)を紐づけて探すため、よくインターネットの電話帳として例えられています。
名前解決の流れ
ざっくりとしたフローは上記の図にある通りですが、実際にはどのような経路をたどって名前解決しているか、追っていきましょう。
1: DNSリゾルバへの問い合わせ
まずDNSリゾルバに接続先ドメインのIPアドレスを問い合わせます。
DNSリゾルバは、クライアントの代わりに複雑なDNS問い合わせをしてくれるサーバーです。
よく使われるDNSリゾルバには、Google Public DNS(8.8.8.8)、Cloudflare DNS(1.1.1.1)などがあります。
2: ルートDNSサーバーへの問い合わせ
DNSリゾルバはルートDNSサーバーに対象ドメインのDNSサーバーを問い合わせます。ルートDNSサーバーは、DNS階層の最上位に位置し、ルートDNSサーバーは13の論理サーバー名で構成されており、実際には世界中に多数配置されています。
ルートDNSサーバーは直接IPアドレスを知っているわけではないですが、.comのことなら、.comを管理しているTLDサーバーに問い合わせるようにと、次に問い合わせるべきサーバーのアドレスを教えてくれます。(厳密には、NSレコードとそのIPアドレスを返却している)
3: TLDサーバーへの問い合わせ
次にDNSリゾルバは、TLDサーバー(.comを管理するサーバー)にも、同じく対象ドメインのDNSサーバーを問い合わせます。TLDサーバーも直接IPアドレスは知りませんが、google.comのことなら、google.comを管理している権威DNSサーバーに問い合わせるようにと教えてくれます。
TLD(Top Level Domain)とは、.com、.net、.jp のようなドメイン名の最後の部分です。.com や .net は世界中で使える汎用TLD(gTLD)、.jp や .uk は国別TLD(ccTLD)と呼ばれます。
4: 権威DNSサーバーへの問い合わせ
最後に、権威DNSサーバーに問い合わせます。権威DNSサーバーは、google.comというドメインの正式な情報を持っているサーバーで、通常はそのドメインの管理者が運用しています。
権威DNSサーバーで宛先ドメインのIPアドレスはxxx.xxx.xxx.xxxです、とついに正確なIPアドレスを返してくれます。
5: 結果を受け取る
DNSリゾルバは、このようにして手に入れたIPアドレスをクライアントに渡して、このアドレスに対してリクエストを送信できるようになります。
この一連の流れを名前解決と呼びます。実際には数十〜数百ミリ秒で完了します。
DNSの階層構造
なぜこんなに複雑な問い合わせが必要なのでしょうか? それは、DNSが階層構造になっているからです。
DNS階層は、ちょうど住所のような構造になっています。「神奈川県 > 横浜市 > XX区 > △丁目」のように、大きな単位から小さな単位へと細分化されています。最上位にはルート(.)があり、その下に.comや.jpといったTLDがあります。さらにその下にgoogle.comやexample.comといった個別のドメインがあり、最後にwwwやmailといったサブドメインがあります。
この階層構造により、世界中の膨大な数のドメイン名を効率的に管理できるようになっています。各階層のサーバーは自分の管轄範囲だけを管理すればよく、全体を1つのサーバーで管理する必要がありません。
DNSキャッシュ
毎回ルートサーバーから順番に問い合わせていたら時間がかかりますし、サーバーへの負荷も大きくなります。そこでキャッシュという仕組みが使われています。
初めて訪れるサイトにアクセスするとき、前述の長い名前解決のための問い合わせプロセスが実行されます。しかし、その結果はブラウザ、OS、DNSリゾルバの各段階でキャッシュ(一時保存)されます。
2回目以降に同じドメイン名にアクセスするときは、まずブラウザのキャッシュを確認し、そこにあればすぐに使えます。なければOSのキャッシュ、それでもなければDNSリゾルバのキャッシュを確認します。これにより、名前解決が大幅に高速化されます。
TTL(Time To Live)
ただし、キャッシュには有効期限(TTL)があります。例えばTTLが3600秒(1時間)と設定されていれば、キャッシュされてから1時間後には期限切れとなり、再度問い合わせが必要になります。
TTLを短く設定すると、キャッシュがすぐに期限切れになるため、IPアドレスの変更がすぐに反映されます。サーバー移行時など、IPアドレスを変更する予定があるときに便利です。ただし、DNSへの問い合わせ回数が増えるため、サーバーへの負荷は高くなります。
逆にTTLを長く設定すると、キャッシュが長時間有効なため、DNS問い合わせが減ってサーバー負荷は低くなります。しかし、IPアドレスを変更した際に、全てのキャッシュが更新されるまでの時間も多くかかってしまいます。
DNSレコードの種類
権威DNSサーバーは、様々な種類の情報を管理しています。これをDNSレコードと呼びます。主要なレコードを見ていきましょう。
Aレコード
Aレコードは、ドメイン名をIPv4アドレスに変換するための最も基本的なレコードです。例えば「google.com は 142.250.207.46」という対応関係を記録します。
AAAAレコード
AAAAレコード(クアッドエーと読みます)は、AレコードのIPv6版です。IPv6アドレスは128ビットと長いため、「2404:6800:4004:800::200e」のような形式になります。
CNAMEレコード
CNAMEレコードは、ドメイン名の別名(エイリアス)を設定するためのレコードです。例えば「www.example.com → example.com」と設定することができます。
これは特に、CDNを使う場合や、ロードバランサーにトラフィックを振り分ける場合に便利です。実際のIPアドレスが変わっても、CNAMEレコードを変更するだけで対応できます。
※あくまでエイリアスなので、最終的にはAレコードまたはAAAAレコードに解決される必要があります。
MXレコード
MXレコードは、メールサーバーを指定するためのレコードです。「user@google.com」宛のメールをどのサーバーに配送すればいいかを示します。
例えば「google.comのメールは、mail.google.comのサーバーで受け取ります」といった設定をします。MXレコードには優先度も設定でき、複数のメールサーバーで冗長構成を組むことができます。
TXTレコード
TXTレコードは、ドメインに対して任意のテキスト情報を登録できるDNSレコードです。
もともとはメモのように自由な情報を書き込む用途で用意された仕組みでしたが、現在では主に認証やセキュリティ関連の設定に利用されています。
代表的な用途としては以下のようなものがあります。
SPF：このドメインからメールを送信してよいサーバーはどれかをDNS上で宣言することで、送信元を偽装したメールを検知しやすくします。
DKIM：メールに付与された電子署名を検証するための公開鍵をTXTレコードに登録し、メールが途中で改ざんされていないかを確認できるようにします。
Google Search Console：ドメインの所有確認にもよく使われ、外部サービスが指定した文字列をDNSに登録することで、そのドメインを管理していることを証明できます。
まとめ
今回は、DNSについて学びました。
google.comのような人間に覚えやすい名前でWebサイトにアクセスできるのは、DNSがドメイン名とIPアドレスを変換してくれるからです。その裏側では、キャッシュDNS、ルートサーバー、TLDサーバー、権威DNSサーバーが階層的に連携し、効率的に名前解決を行っていることがわかりました。
次回は、DHCP(IPアドレスの自動割当)について学びます。なぜデバイスをネットワークに繋ぐだけで自動的にIPアドレスが設定されるのか、その仕組みを見ていきます。
