DNSとは ― 名前解決のしくみ

通信で使う住所はIPアドレスですが、人間が覚えて打ち込むにはwww.example.com のような名前の方が向いています。この名前からIPアドレスを引く仕組みがDNS（Domain Name System）です。このような名前を、ドメイン名と呼びます。

DNSの実体は、世界中に分散した住所録です。PCは名前を調べるとき、近くのDNSサーバに代わりに調べてもらいます。このサーバをキャッシュDNSサーバと呼びます。

キャッシュDNSサーバは、住所録を分担して持つサーバを上から順にたどります。たどり着いた答えのIPアドレスを、PCに返します。

www.example.com のIPアドレスを調べる例で、問い合わせの順番を追います。

1. 1

   PC内のキャッシュとhostsファイルを先に見る

   PCは外部に問い合わせる前に、自分の中に答えがないかを確かめます。確かめる場所の1つは、過去に調べた答えの控えです。この控えをDNSキャッシュと呼びます。

   もう1つは hosts ファイルです。このファイルには、名前とIPアドレスの対応を手動で書いておけます。どちらかに答えがあれば、手順2以降は行われません。

2. 2

   PCがキャッシュDNSサーバに聞く

   どちらにも答えがなければ、PCはキャッシュDNSサーバへ問い合わせます。このサーバは、PCに設定されています。そのIPアドレスは、DHCPによって自動で配られていることが多いです。

   PCは、最終的な答えまで丸ごと調べるように頼みます。PCの中で、こうして問い合わせる仕組みをスタブリゾルバと呼びます。キャッシュDNSサーバは、フルサービスリゾルバとも呼ばれます。

3. 3

   キャッシュになければルートDNSサーバへ

   キャッシュDNSサーバは、まず自分のキャッシュを探します。過去に調べた答えが残っていなければ、ルートDNSサーバに問い合わせます。ルートDNSサーバは、住所録を分担して持つサーバのうち、一番上の階層を受け持つサーバです。

4. 4

   ルートは「.comはここ」とTLDサーバを教える

   ルートDNSサーバは、最終的な答えを知りません。そこで、.comを管理するサーバの場所だけを教えます。 .comのような名前の一番右の部分を、TLD（Top Level Domain）と呼びます。この部分を管理するサーバがTLDサーバです。

   上の階層が、下の階層の管理をほかのサーバに任せることを委任と呼びます。ルートDNSサーバが返したのは、この委任の情報です。

5. 5

   TLDサーバが権威DNSサーバの場所を教える

   キャッシュDNSサーバは、同じ質問をTLDサーバに送ります。TLDサーバは、example.comを管理するサーバの場所を教えます。そのドメインの答えを正式に持つサーバを、権威DNSサーバと呼びます。

6. 6

   権威DNSサーバがIPアドレスを答える

   最後に、キャッシュDNSサーバは権威DNSサーバへ問い合わせます。権威DNSサーバは、203.0.113.50のような最終的なIPアドレスを返します。

何往復もするのは、キャッシュDNSサーバです。PCに返ってくるのは、最終的なIPアドレス1つだけです。PC自身が、ルートDNSサーバやTLDサーバに直接問い合わせることはありません。

上の図の左側と右側では、問い合わせの頼み方が違います。図の左側では、PCがキャッシュDNSサーバに「知らなくてもいいので、とにかく代わりに調べて最終的な答えだけ返して」と頼みます。この頼み方を再帰問い合わせと呼びます。頼まれたキャッシュDNSサーバは、自分で最後まで調べ切る責任を負います。

図の右側では、キャッシュDNSサーバがルート・TLD・権威の各サーバに「知っていれば答えて、知らなければ次に聞くべき場所を教えて」と頼みます。この頼み方を反復問い合わせと呼びます。

ルートDNSサーバやTLDサーバは、「自分は知らないが、この先のサーバなら知っている」という委任情報だけを返します。調べ切る責任は、キャッシュDNSサーバ側に残ったままです。

世界中のアクセスのたびにルートDNSサーバまで問い合わせていては、ルートDNSサーバが負荷に耐えられません。そこでキャッシュDNSサーバは、一度得た答えを保存しておきます。同じ質問が来たら、ルートまで聞きに行かずに、保存した答えをそのまま返します。

答えを保存してよい期間は、答えと一緒に届きます。DNSの応答には、秒単位の有効期間が付いているからです。この有効期間をTTL（Time To Live）と呼びます。日本語では生存時間と訳します。

TTLが切れると、キャッシュDNSサーバは答えを破棄します。改めて調べ直すのは、次に同じ質問が来たときだけです。

ただし、.comなどTLDサーバの委任情報は、別途長いTTLで残っていることが多いです。その場合は、ルートDNSサーバまで戻らずに、TLDサーバから先だけを調べ直します。

名前解決の例で、権威DNSサーバは www.example.com のIPアドレスとして 203.0.113.50 を返しました。DNSサーバは、このような名前と情報の対応を1件ずつ持っています。この1件ずつの情報をレコードと呼びます。

レコードにはいくつかの種類があります。よく出てくる5種類を説明します。

ここまでの例の、名前からIPアドレスを引く動きには、AレコードとAAAAレコードを使います。

CNAMEは、あるドメイン名を別のドメイン名に付け替えるための別名です。最終的には、付け替え先のドメイン名がAレコードで解決されます。CDNを使うサイトは、CNAMEで名前をCDN側に向けます。送信側のメールサーバは、MXレコードで宛先のサーバを探します。その流れはメールが届く仕組みで説明しています。文字列を入れるTXTレコードは、メールの送信元を確かめるSPF・DKIM・DMARCの記事で使います。

1つの名前に、複数のAレコードを登録することもできます。答えの並び順を問い合わせごとに入れ替えれば、利用者のつなぎ先を複数のサーバに分けられます。この方法をDNSラウンドロビンと呼びます。専用の装置で振り分ける方法との違いは、ロードバランサの記事で比べています。

AWSのマネージド型のDNSサービスには、Amazon Route 53があります。Route 53でルーティングポリシーを使って振り分け先を変える方法は、Route 53の記事にあります。

DNSの問い合わせと応答は、通常UDPの53番ポートを使います。UDPは、1回のやり取りで完結する軽い通信に向いています。多くのDNS問い合わせは、UDPで十分です。

応答のデータサイズが大きい場合は、TCPの53番ポートに切り替わります。サーバ間で大量のデータをやり取りする場合も同じです。TCPは、届いたかどうかを確かめながら送る方式です。

TCPとUDPの違いはTCP/UDPの記事で、ポート番号の基本はポート番号の記事で確認できます。DNSサーバに実際に問い合わせて答えを見るには、dig や nslookup を使います。出力の読み方は、netstat・ss・digの記事を見てください。

DNSの応答は、問い合わせより大きくなることがあります。送信元を偽装した問い合わせでこの性質を悪用する攻撃が、DoS攻撃・DDoS攻撃の記事で説明する増幅攻撃です。

問い合わせと応答が実際のパケットとしてどう見えるかは、Wiresharkの記事で確かめられます。