基礎から理解するCDN入門: 第4回 DNSの仕組みを理解する

本記事では、CDNの要素技術であるDNS(Domain Name System)について掘り下げます。DNSは、エッジサーバーにユーザーの端末をルーティングする時に必須の技術です。CDNの導入を安心して行うために、この回でDNSの基礎を押さえます。

目次

DNS(Domain Name System)とは

DNSは人間にとって覚えやすいドメイン名(例えば、”www.bloomblock.net” )を、IPアドレス(例えば、”13.32.50.71″)に変換する役割を担います。このプロセスを「名前解決」と呼びます。

ブラウザのアドレスバーにWebサイトのアドレスを入力すると、DNSサーバーがこのドメイン名をIPアドレスに変換し、その結果をブラウザに返します。これにより、ブラウザは正しいサーバーに接続し、見たいWebページを表示できるのです。

名前解決が行われるのは、Webブラウザに限りません。 スマートフォンのアプリケーションがサーバーと通信する際も、ブラウザと同じように名前解決でIPアドレスを取得してからサーバーに接続します。

DNSの階層構造について

上の図では、ユーザーが1台のDNSサーバーに問い合わせてIPアドレスを取得していました。実際には、これは正確ではありません。 実際のDNSは木構造の階層システムで構成されています。

以下はDNSの階層構造です。

  1. ルートドメイン(.): DNS階層の最上位に位置し、全てのトップレベルドメイン(TLD)を含みます。ドットで表されますが、省略されることも多いです。
  2. トップレベルドメイン(TLD): ルートドメインの直下に位置するドメイン。.com.net.org.jpなどの一般的なドメインや、.gov(政府機関用)、.edu(教育機関用)などの特別な用途のドメインが含まれます。
  3. セカンドレベルドメイン: TLDの下に位置するドメインで、一般にビジネスや組織名が使われます。例えば、bloomblock.netにおけるbloomblockがセカンドレベルドメインです。
  4. サブドメイン: セカンドレベルドメインの下に位置し、特定のサービスや部門を識別するために使われます。例えば、www.bloomblock.netwwwがサブドメインです。

それぞれのレベルのドメインを管理するDNSサーバーが存在し、委任(Delegation)によってそれぞれのゾーンの管理を別のDNSサーバーに任せます。

DNSでは、この管理単位のことをゾーン(Zone)と呼びます。

“www.bloomblock.net” の名前解決を行う時は、ルートDNSサーバー、.netを管理するDNSサーバー、bloomblock.netを管理するDNSサーバーと再帰的に問い合わせを行い、最終的なIPアドレスを取得します、

DNSサーバーの種類

しかし、これでもまだ完全に正確ではありません。一般的には、ユーザーのWebブラウザでDNSサーバーへ再帰的に問い合わせてIPアドレスを取得することはなく、ユーザーが契約しているISPが用意しているDNSサーバーが代わりにこの役割を担います。

そのため、ユーザーのWebブラウザは、名前解決されたIPアドレスを受け取ります。

ISPが用意する再帰問い合わせを行うDNSサーバーのことをキャッシュDNSサーバーリゾルバ(Resolver)と呼びます。

これに対して、ドメイン名の情報を管理し、キャッシュDNSサーバーからの問い合わせに答えるDNSサーバーのことを権威DNSサーバーと呼びます。

DNSキャッシュとは

キャッシュDNSサーバーは、名前が表す通り、一度問い合わせた結果をキャッシュし、再利用します。これにより、名前解決にかかる時間を短縮できます。

この「キャッシュ」はCDNの文脈で使われる「キャッシュ」とは異なります。CDNの文脈のキャッシュは正確には「HTTPキャッシュ」のことを指しています。そのため、混同しないように注意しましょう。

キャッシュの有効期限は、レスポンスされたレコード(後述します)内のTTL(Time To Live)と呼ばれるフィールドで指定されます。

TTLが長いほど、長くキャッシュされるので、ユーザーからは名前解決が高速化する、権威サーバーからは問い合わせの数が減ってサーバーの負荷が下がるというメリットがあります。

一方で、ドメインに対するIPアドレスを変更した時に全てのユーザーが新しいIPアドレスにルーティングされるまでにかかる時間が長くなるというデメリットがあります。

そのため、既存のWebサイトにCDNを導入する時は、TTLを一時的に短くし、全てのユーザーがCDN経由で接続するようにします。

代表的なレコードタイプ

DNSでは、問い合わせを行った時のレスポンスとして、DNSレコードと呼ばれるデータが返ってきます。

例えば、AレコードはIPアドレスを含んでおり、これによってユーザーはドメイン名に対するIPアドレスを取得できます。

下記では、CDNに関連する代表的なDNSレコードについて説明します。

Aレコード(Address Record)

  • 用途: ドメイン名をIPv4アドレスにマッピングする。
  • : www.bloomblock.net13.32.50.25

AAAAレコード(Quad-A Record)

  • 用途: ドメイン名をIPv6アドレスにマッピングする。
  • : www.bloomblock.net 2600:9000:21c5:3c00:1d:2555:4900:93a1

CNAMEレコード(Canonical Name Record)

  • 用途: 一つのドメイン名を別のドメイン名にエイリアス(別名)として関連付ける。
  • : mail.bloomblock.netwww.bloomblock.net

NSレコード(Name Server Record)

  • 用途: ドメインのDNSサーバーを指定する。
  • : bloomblock.net のDNSサーバーは ns-428.awsdns-53.com。

SOAレコード(Start of Authority Record)

  • 用途: DNSゾーンの基本的な情報、例えばゾーン管理者の連絡先、ゾーンの更新頻度などを保持する。
  • : bloomblock.net ゾーンのSOAレコードには、管理者のEメールアドレスや更新間隔の情報が含まれる。

名前解決のプロセス(DNSレコード表記)

それでは、これまで見てきた名前解決のプロセスをDNSレコードで表記してみましょう。

ルートDNSサーバーから目的のドメインを管理するDNSサーバー(bloomblock.netを管理するDNSサーバー)まで、NSレコードとAレコードを順に要求することで委任先のDNSサーバーのIPアドレスを取得することを繰り返しています。

目的のドメインを管理するDNSサーバーはAレコードを返し、問い合わせていたIPアドレスをユーザーは受け取ります。

digコマンドで名前解決の様子を見る

dig コマンドは、DNSクエリ(問い合わせ)を実行するために使用できるツールです。このコマンドを使って、ドメイン名に関連するさまざまな種類の情報を取得できます。これには、対応するIPアドレス、ネームサーバーの詳細、メールサーバーの情報などが含まれます。

dig コマンドの +trace オプションは、DNSの名前解決のプロセスを提供します。このオプションを使用すると、ルートDNSサーバーから始めて、ドメイン名の解決に関与するすべてのDNSサーバーに順番に問い合わせ(再帰問い合わせ)を行います。

通常の dig コマンドは、ISPのキャッシュDNSサーバーを使用して情報を取得しますが、+trace オプションを使うと、digを実行したマシンが再帰問い合わせを行います。

それでは、再帰問い合わせの様子を見てみましょう。

$ dig +trace www.bloomblock.net

; <<>> DiG 9.10.6 <<>> +trace www.bloomblock.net
;; global options: +cmd
.                       267116  IN      NS      b.root-servers.net.
.                       267116  IN      NS      g.root-servers.net.
.                       267116  IN      NS      a.root-servers.net.
.                       267116  IN      NS      i.root-servers.net.
.                       267116  IN      NS      f.root-servers.net.
.                       267116  IN      NS      h.root-servers.net.
.                       267116  IN      NS      e.root-servers.net.
.                       267116  IN      NS      c.root-servers.net.
.                       267116  IN      NS      j.root-servers.net.
.                       267116  IN      NS      k.root-servers.net.
.                       267116  IN      NS      l.root-servers.net.
.                       267116  IN      NS      m.root-servers.net.
.                       267116  IN      NS      d.root-servers.net.
;; Received 525 bytes from fe80::569b:49ff:fe5a:3b40%12#53(fe80::569b:49ff:fe5a:3b40%12) in 53 ms

ルート(.)ドメインを管理するルートDNSサーバーのリストが、NSレコードで返却されています。

net.                    172800  IN      NS      a.gtld-servers.net.
net.                    172800  IN      NS      b.gtld-servers.net.
net.                    172800  IN      NS      c.gtld-servers.net.
net.                    172800  IN      NS      d.gtld-servers.net.
net.                    172800  IN      NS      e.gtld-servers.net.
net.                    172800  IN      NS      f.gtld-servers.net.
net.                    172800  IN      NS      g.gtld-servers.net.
net.                    172800  IN      NS      h.gtld-servers.net.
net.                    172800  IN      NS      i.gtld-servers.net.
net.                    172800  IN      NS      j.gtld-servers.net.
net.                    172800  IN      NS      k.gtld-servers.net.
net.                    172800  IN      NS      l.gtld-servers.net.
net.                    172800  IN      NS      m.gtld-servers.net.
;; Received 1175 bytes from 199.7.91.13#53(d.root-servers.net) in 88 ms

netドメインを管理するDNSサーバーのリストがNSレコードで返却されています。このレスポンスは、d.root-servers.netから受け取っていることが最後の行から分かります。

digコマンドの結果には表示されていませんが、d.root-servers.netのIPアドレス199.7.91.13を取得するためにAレコードも取得されています。


bloomblock.net.         172800  IN      NS      ns-428.awsdns-53.com.
bloomblock.net.         172800  IN      NS      ns-891.awsdns-47.net.
bloomblock.net.         172800  IN      NS      ns-1167.awsdns-17.org.
bloomblock.net.         172800  IN      NS      ns-1933.awsdns-49.co.uk.
;; Received 557 bytes from 192.12.94.30#53(e.gtld-servers.net) in 11 ms

www.bloomblock.net は、ns-428.awsdns-53.com他3つのDNSサーバーで管理されていることが分かります。

DNSサーバーは冗長化されており、この例でも4つのDNSサーバーがNSレコードで返ってきています。

弊社は、Amazon Route53を自社ドメイン管理のDNSサーバーとして使っているため、XXX.awsdns-YYYの形式のDNSサーバー名になっています。

www.bloomblock.net.     60      IN      A       13.32.50.102
www.bloomblock.net.     60      IN      A       13.32.50.25
www.bloomblock.net.     60      IN      A       13.32.50.71
www.bloomblock.net.     60      IN      A       13.32.50.30
bloomblock.net.         172800  IN      NS      ns-1167.awsdns-17.org.
bloomblock.net.         172800  IN      NS      ns-1933.awsdns-49.co.uk.
bloomblock.net.         172800  IN      NS      ns-428.awsdns-53.com.
bloomblock.net.         172800  IN      NS      ns-891.awsdns-47.net.
;; Received 248 bytes from 205.251.199.141#53(ns-1933.awsdns-49.co.uk) in 12 ms

最後にns-1933.awsdns-49.co.ukからwww.bloomblock.net.は、13.32.50.102を含む4つのIPアドレスでアクセスできることがAレコードが返ってきたことで分かりました。

内容が重複するので割愛しますが、下記のようにAAAAをレコードタイプとして指定するとIPv6アドレスを知ることもできます。

dig AAAA +trace www.bloomblock.net

(補足)ルートDNSサーバーのIPアドレスについて

ここまでで、ルートDNSサーバーから目的のドメインまでNSレコードとAレコードを順に要求し、委任先のDNSサーバーのIPアドレスを取得することを見てきました。

では、最初に問い合わせをするルートDNSサーバーのIPアドレスはどうやって知るのでしょうか?

答えはルートDNSサーバーのIPアドレスが変更されることはほとんどないので、静的にハードコードされているということです。

ルートDNSサーバーのIPアドレスの一覧は、IANAのページに記載があります。

DNSサーバーの実装で有名なBINDのソースコードでは、ハードコードされていることが見て取れます。

まとめ

本記事では、CDNの要素技術であるDNSの仕組みについて基礎から確認していきました。

この記事で特に覚えて頂きたいことは、次の2点です。

  1. DNSでの名前解決は再帰的に行われている
  2. DNSの名前解決の結果はTTLで示された時間だけキャッシュされる

特に、キャッシュされることは、CDNの導入時(および問題が発生した時の切り戻し時)に意識しておきたいことです。

キャッシュされることを知っていると、ユーザーの接続先をオリジンサーバーからエッジサーバーに切り替えてもすぐには切り替わらないので、DNSキャッシュが期限切れになるまでは様子見する期間にする。その間、エンジニアの体制は確保しようといった意思決定ができます。

次回は、今回学んだCNAMEレコードでユーザーをCDNへルーティングする仕組みについて解説します。

あわせて読みたい
基礎から理解するCDN入門: 第5回 CNAMEレコードでユーザーをCDNへルーティングする 前回の記事では、DNSの基礎について学びました。 本記事では、前回学んだDNSを使って、ユーザーをCDNにルーティングする方法について解説します。 まずは、第3回で解説...

CDN入門記事の一覧ページはこちらです。

あわせて読みたい
基礎から理解するCDN入門 記事一覧 総務省の統計によると、インターネットを流れる全トラヒックの70%以上が、CDN(Content Delivery Network)を経由して配信されています。このことから、CDNは年々トラヒッ...
よかったらシェアしてね!

CD

目次