ネットワーク●●○○○

DNS

ドメイン名をIPアドレスに変換する、インターネットの電話帳。

概要

DNS(Domain Name System)は、人間が覚えやすい「example.com」のようなドメイン名を、通信に実際に必要なIPアドレスへ変換する仕組みです。ブラウザにURLを打ち込んだとき、最初に走るのがこの「名前解決」で、変換が終わって初めてサーバへの接続が始まります。電話帳にたとえられますが、実体は世界中のネームサーバが階層的に問い合わせを分担し合う、インターネット最大級の分散データベースです。

Webサービスを公開する側にとっても、DNSは必ず触れる領域です。「ドメインを取得してAレコードを設定する」「レコードの伝播を待つ」「CNAMEとAレコードのどちらを使うか」——こうした作業語彙の中心にDNSがあります。障害対応の格言に「原因は結局DNSだった(It’s always DNS)」という冗談があるほど、静かに、しかし決定的にすべての通信を支えています。

なぜ生まれたか

初期のインターネット(ARPANET)では、名前とアドレスの対応表は「HOSTS.TXT」という1つのテキストファイルで管理され、スタンフォード研究所が一元的に配布していました。接続組織が数十のうちはそれで回りましたが、ホストが増えるにつれ、ファイルの肥大化、更新の反映遅れ、名前の重複、配布サーバへの負荷集中と、一元管理の限界があらゆる面で露呈します。

そこで1983年、ポール・モカペトリスが設計したのがDNSです。核心のアイデアは「名前空間を階層に区切り、各階層の管理を委任する」こと。com の下の example.com のことは example.com の管理者だけが責任を持ち、他の誰の承認も要らずにレコードを更新できます。中央の台帳を捨てて権限を分散したこの設計が、その後ホスト数が億の単位に爆発しても破綻しなかった理由です。

詳細

階層構造と問い合わせの流れ

ドメイン名は右から左へ階層を表します。「www.example.com」なら、頂点のルート、その下の「com」(TLD: トップレベルドメイン)、その下の「example.com」という木構造です。各階層には、その部分の情報に責任を持つ「権威サーバ」がいます。ただし利用者のPCが自力でこの木をたどるわけではなく、間に「フルリゾルバ(キャッシュDNSサーバ)」が立ち、代理で再帰的に問い合わせてくれます。

リゾルバが階層を上から順にたどる再帰問い合わせの往復は、次のようになります。

権威サーバcomのTLDサーバルートサーバフルリゾルバブラウザ権威サーバcomのTLDサーバルートサーバフルリゾルバブラウザまず自分のキャッシュを確認 あれば即答www.example.com のIPアドレスは?問い合わせcomのことはcomのサーバに聞いて問い合わせexample.comの権威サーバはこちら問い合わせ203.0.113.5 です回答を返しキャッシュにも保存

この問い合わせは通常、一往復で済む軽さを活かしてUDPで行われます(応答が大きい場合やゾーン転送ではTCP/IPのTCPを使用)。近年はプライバシー保護のため、リゾルバへの問い合わせをHTTPSで暗号化するDoH(DNS over HTTPS)も広がっています。

この階層をたどる往復と、2回目の問い合わせでキャッシュが効く様子を、次のステッパーで1ステップずつ確かめられます。

⚡ 体験: example.com を引いてみる
ブラウザあなたのPC
フルリゾルバキャッシュDNS
ルートサーバ階層の頂点
TLDサーバcom を管理
権威サーバexample.com を管理
「次へ」で名前解決を始めます
1回目(キャッシュなし)0 / 5

ブラウザが example.com の IP アドレスを知りたがっています。リゾルバのキャッシュは空の状態から始めます。

キャッシュとTTL

毎回ルートから聞いていてはルートサーバが持ちません。DNSを実用たらしめているのは徹底したキャッシュです。各レコードには管理者が設定するTTL(Time To Live、キャッシュしてよい秒数)が付いており、リゾルバはその間、権威サーバに聞き直さず手元の答えを返します。

これが実務でいう「伝播待ち」の正体です。レコードを変更しても、世界中のリゾルバが古いキャッシュを抱えている間は旧い答えが返り続けます。サーバ移転の前にはTTLをあらかじめ短く(例: 300秒)しておき、切り替え後に戻すのが定石です。「変更したのに反映されない」の多くは障害ではなく、単にTTLがまだ切れていないだけです。

主要なレコードタイプ

DNSはIPアドレス以外にも様々な情報を名前に紐付けます。実務で頻出するのは次のあたりです。Aレコードは名前からIPv4アドレスへの対応(IPv6はAAAA)。CNAMEは「この名前は別の名前の別名」という参照で、CDNやPaaSのホスト名にサブドメインを向けるときの常套手段です。MXはメールの宛先サーバ、TXTは任意のテキストで、ドメイン所有権の確認やメールの送信元認証(SPF/DKIM)に使われます。NSは「このゾーンの権威サーバはどれか」という委任情報そのものです。なおCNAMEはドメインの頂点(example.com そのもの)には原則置けないという制約があり、各DNSサービスがALIASなどの独自拡張で回避しています。

インフラとしてのDNSと落とし穴

DNSは単なる変換にとどまらず、トラフィック制御の道具でもあります。1つの名前に複数のAレコードを持たせて応答を巡回させる素朴な負荷分散(DNSラウンドロビン)や、問い合わせ元の地域に応じて最寄りの拠点のアドレスを返すCDNの経路誘導は、その代表です。より本格的な分散はロードバランサの領分ですが、その入口の名前を配るのはやはりDNSです。

一方で、DNSが止まればIPアドレスに到達できず、サーバ自体が健在でもサービスは全滅します。大手DNSプロバイダの障害が有名サービスを軒並み巻き込んだ事例は何度もあり、DNSは可用性設計の単一障害点になりがちです。セキュリティ面でも、偽の応答をキャッシュに注入するキャッシュポイズニングや、ドメイン登録の乗っ取りといった攻撃対象であり続けており、応答の正当性を署名で検証するDNSSECなどの対策が整備されています。「名前解決は速くて当たり前、しかし壊れるとすべてが壊れる」——DNSはインターネットの縁の下で、その緊張感を一手に引き受けている仕組みです。