2025年11月21日·1 分
ポール・モカパトリスとDNS：インターネットが人間にわかる名前を得た経緯
ポール・モカパトリスが扱いにくいホスト一覧を置き換え、拡張可能な命名システムであるDNSを作った経緯を学びます。DNSの仕組み、キャッシュの重要性、基本的なセキュリティについても解説します。
ポール・モカパトリスが扱いにくいホスト一覧を置き換え、拡張可能な命名システムであるDNSを作った経緯を学びます。DNSの仕組み、キャッシュの重要性、基本的なセキュリティについても解説します。
ウェブアドレスを入力したりリンクをクリックしたりメールを送るたびに、次の単純な考えに頼っています：人間は覚えやすい名前を使い、コンピュータが正しい機械を探す作業をする。
DNSは日常的な問題を解決します：コンピュータは 203.0.113.42 のような数値（IPアドレス）で通信しますが、人は数字の羅列を覚えたくありません。あなたは example.com を覚えたいのであって、そのサイトが今日使っているアドレスを覚えたいわけではありません。
ドメインネームシステム（DNS）は、人間に優しいドメイン名をコンピュータが接続に使うIPアドレスに翻訳するインターネットの“住所録”です。
この翻訳は小さなことに思えるかもしれませんが、インターネットを使いやすく感じさせるか、数字だらけの電話帳のように感じさせるかの違いになります。
このガイドは非専門家向けです。ネットワークの事前知識は不要。次を順に見ていきます：
途中で、1980年代初頭にDNSを設計したエンジニア、ポール・モカパトリスに出会います。彼の仕事が重要だったのは、単に新しい名前形式を作ったからではなく、小さな研究ネットワークが数十億の人々に利用される規模へと拡大しても動き続けるシステムを設計したからです。
サイトが「落ちた」経験、ドメインの変更が「伝播」するのを待った経験、メール設定に謎めいたDNSエントリが含まれているのを見た経験があれば、あなたはすでに外側からDNSに触れています。この記事の残りでは、舞台裏で何が起きているのかをわかりやすく、専門用語を抑えて説明します。
馴染みのあるウェブアドレスが存在するずっと前、初期のネットワークではもっと単純な問題がありました：特定の機械にどうやって到達するか。コンピュータは IPアドレス（例: 10.0.0.5）で互いに通信できましたが、人は MIT-MC や SRI-NIC のような覚えやすい ホスト名を好みました。
初期のARPANETでは、解決策は HOSTS.TXT という単一の共有ファイルでした。それは実質的にルックアップ表で、ホスト名とIPアドレスの対応一覧です。
各コンピュータはこのファイルのローカルコピーを保持していました。名前で接続したければシステムが HOSTS.TXT を調べ、対応するIPアドレスを見つけていました。
ネットワークが小さく、変更が比較的少なく、更新の入手先が明確だったため、この方式は当初は機能しました。
組織が増えると次第にこの方法は限界を見せ始めました：
HOSTS.TXT のコピーが古ければ、ホスト名が誤ったアドレス、またはどこにも向かないことがあった。核心は調整の難しさでした。HOSTS.TXT は世界共通のアドレス帳のようなものでした。もし誰もが同じ本に頼るなら、修正は世界規模の編集を必要とし、誰もが最新版を素早くダウンロードする必要があります。ネットワークがある規模を超えると、「一つのファイルで全部管理する」モデルは遅すぎ、中央集権的すぎ、そしてミスが起きやすくなりました。
DNSは、名前を数値にマッピングする考え自体を置き換えたのではなく、そのマッピングの保守と配布方法という脆弱な仕組みを置き換えました。
1980年代初頭、インターネットは小さな研究ネットワークからより大きく、複雑で広く共有される存在へと移行していました。機械は増え、組織は自律性を求め、人々は数字のアドレスを覚えるよりもサービスに到達する簡単な方法を必要としていました。
その状況で作業していたポール・モカパトリスは、DNSの設計者として広く認められています。彼の貢献は派手な製品ではなく、非常に実利的な問いへの工学的な回答でした：ネットワークが拡大し続けるとき、どうすれば名前を使いやすいまま保てるのか？
命名システムは単純に思えますが、当時の「単純」が意味していたのは：全員がダウンロードして最新に保たなければならない一つの共有リストでした。その方式は、変更が常態化すると破綻します。新しいホスト、名前の変更、修正のたびに全員が協調する必要が生まれるからです。
モカパトリスの重要な洞察は、名前は単なるデータではなく「共有された合意」であることでした。ネットワークが拡大するなら、その合意を作り配布する仕組みも拡大しなければならない—すべてのコンピュータが常にマスタリストを取得する必要がないように。
DNSは「一つの権威あるファイル」の発想を分散設計に置き換えました：
ここにある静かな妙技は、DNSは賢く作ろうとしたわけではなく、実際の制約（帯域の限界、頻繁な変更、多数の独立した管理者、成長し続けるネットワーク）の下でも動き続けるように設計された点です。
DNSは単なる小手先の発明ではなく、初期インターネットの成長で明らかになった具体的で実用的な問題を解決するために設計されました。モカパトリスのアプローチは、まず明確な目標を設定し、その後で数十年にわたって追従できる命名システムを構築することでした。
重要な概念は**委任（delegation）**です：名前ツリーの異なる部分を別々のグループが管理します。
例として、.com 配下の管理はある組織が行い、レジストラが example.com を取得する手助けをし、あなた（あるいはDNSプロバイダ）が www.example.com や mail.example.com のレコードを管理します。責任をきれいに分割することで、成長によるボトルネックを防ぎます。
DNSは問題が起きることを前提に設計されています—サーバは落ちるし、ネットワークは分断され、経路は変わります。だから多くの権威サーバとリゾルバのキャッシュに依存し、短期的な障害が即座に全ての名前解決を壊さないようにしています。
DNSは人間に優しい名前を技術的なデータ（主にIPアドレス）に翻訳するサービスです。それ自体が「インターネットそのもの」ではなく、デバイスがどこに接続すればよいかを見つけるための命名・検索サービスです。
DNSは名前をツリー状に整理することで管理可能にしています。全ての名前がグローバルに一意である必要がある大きなリストの代わりに、DNSはレベルごとに分けて責任を委譲します。
DNS名は右から左に読まれます：
www.example.com. は技術的には末尾に . を持ちます。.com、.org、.net、国別コードの .uk など。example（example.com の example 部分）。www（www.example.com の www 部分）。つまり www.example.com は次のように分解できます：
com（TLD）example（その .com 配下に登録されたドメイン）www（ドメイン所有者が作成・管理するラベル）この構造により、名前の衝突が減ります。親の範囲内で一意であればよいので、多くの組織が www というサブドメインを持てます（www.example.com と www.another-example.com は衝突しない）。
また作業負荷が分散されます。.com の運営者がすべてのウェブサイトのレコードを管理する必要はなく、example.com の責任者だけに委任するだけです。
ゾーンとはそのツリーの管理可能な一部分で、誰かが公開する責任を負っているDNSデータのまとまりです。多くのチームにとって「我々のゾーン」は example.com とその下位のサブドメインのDNSレコードを指し、権威サーバに保存されます。
ブラウザにウェブサイト名を入力するとき、実際には「インターネットそのもの」に直接尋ねているわけではありません。いくつかの専門的な役割が仕事を分担して、答えが迅速かつ信頼できる方法で見つかるようにしています。
**あなた（端末とブラウザ）**は単純な要求を出します：「example.com に対応するIPアドレスは？」あなたの端末は多くの場合まだ答えを知らず、何十ものサーバに自分で問い合わせたくありません。
**再帰的リゾルバ（recursive resolver）**があなたに代わって探します。これは通常あなたの ISP、職場/学校の IT、もしくは パブリックリゾルバ によって提供されます。利点は過去の問い合わせ結果をキャッシュして再利用できることです。
権威DNSサーバはドメインの正確なレコードを保持する最終的な情報源です。これらは「検索」するのではなく、そのゾーンに関する公式の答えを提供します。
example.com を尋ねる。再帰的リゾルバを図書館員に例えると、あなたの代わりに調べてくれて人気のある答えを覚えている人です。一方 権威サーバ は出版社の公式カタログで、自分の本に関する事実だけを記載している存在です。
ブラウザに example.com と入力すると、ブラウザは名前そのものを探しているわけではなくIPアドレス（例: 93.184.216.34）を必要としています。DNSは「この名前に対応する番号を教えて」という仕組みです。
まずブラウザはコンピュータ/スマホのOSに「example.com のIPをすでに知っているか？」と尋ねます。OSは自身の短期記憶（キャッシュ）をチェックし、新鮮な答えがあればここで終了します。
OSに無ければ、設定された DNSリゾルバ に問い合わせを転送します。リゾルバはあなたの「DNSコンシェルジュ」のような存在で、端末が自分で何百もの問い合わせをするのを防ぎます。
リゾルバが答えをキャッシュしていない場合、導かれるように検索を始めます：
.com）についてどこに問い合わせればよいかを尋ねます。ルートは最終的なIPを返すわけではなく、次に訊ねるべきサーバ（TLDサーバ）を紹介します。.com）：次にTLDサーバに example.com をどのサーバが扱っているかを尋ねます。ここでも最終的なIPは返りませんが、次に問い合わせるべき権威サーバを教えます。A や AAAA レコード（IPアドレス）を返します。リゾルバがIPをOSへ返し、その後ブラウザが接続します。多くのルックアップが瞬時に感じられるのは、リゾルバや端末がTTLで定められた期間だけ答えをキャッシュするからです。
シンプルな流れは：ブラウザ → OSキャッシュ → リゾルバキャッシュ → ルート（紹介） → TLD（紹介） → 権威（答え） → ブラウザ です。
毎回最初から複数のサーバに問い合わせるならDNSは非常に遅く感じるでしょう。代わりにDNSはキャッシュ（最近の検索結果の一時記憶）に依存しているので、多くのユーザーはミリ秒単位で答えを得られます。
端末が example.com をリゾルバに尋ねると、最初はリゾルバがいくらかの作業をする必要があります。答えを学ぶとそれをキャッシュに保存します。次に同じ名前を誰かが尋ねれば、即座に応答できます。
キャッシュの目的は二つです：
各DNSレコードには TTL（Time To Live） が設定されています。TTLは「この答えをX秒間保持し、その後は再度問い合わせてください」と指示するものです。
TTLが300であれば、リゾルバは最大5分間その応答を再利用するかもしれません。
TTLはバランスの問題です：
サイトを新しいホストへ移す、CDNを切り替える、あるいはメールの切り替え（MXレコード変更）を行う場合、TTLがユーザーがいつから新しい先へ行くかを決めます。
一般的な方法は、計画的な変更の前にTTLを下げておき、切り替えを行い、安定したらTTLを上げることです。これがDNSが普段は高速で、更新直後に「頑固」に感じられる理由です。
DNSダッシュボードにログインすると、多くの場合いくつかのレコードタイプを編集することになります。各レコードはインターネットに対して小さな指示を出します：人をどこに送るか（ウェブ）、メールをどこに届けるか、あるいは所有確認のための値を示すなど。
| レコード | 役割 | 簡単な例 |
|---|---|---|
| A | 名前をIPv4アドレスに向ける | example.com → 203.0.113.10（ウェブサーバ） |
| AAAA | 名前をIPv6アドレスに向ける | example.com → 2001:db8::10（同じ目的、次世代アドレス） |
| CNAME | ある名前を別の名前のエイリアスにする | www.example.com → example.com（両方同じ場所へ） |
| MX | ドメイン宛てのメールをどこへ配信するか指示する | example.com → mail.provider.com (priority 10) |
| TXT | 機械が読む「メモ」を保存（所有確認、メールポリシー） | example.com に v=spf1 include:mailgun.org ~all のようなSPF |
| NS | どの権威サーバがゾーンをホストしているか示す | example.com → ns1.dns-host.com |
| SOA | ゾーンのヘッダ：プライマリNS、管理者連絡先、タイミング値 | example.com のSOAは ns1.dns-host.com とリトライ/失効タイマーを含む |
いくつかのDNSエラーは繰り返し発生します：
example.com など）：多くのDNSプロバイダはこれを許可しません。ルート名は NS や SOA を持つ必要があるためです。ルートをホスト名に向けたい場合は A/AAAA レコード、またはプロバイダがサポートする「ALIAS/ANAME」機能を使ってください。CNAME と A を同時に設定しないでください（例：同じ www に両方設定するなど）。片方の方法を選びましょう。mail.provider.com の一文字の誤りでもメールが壊れます。ドットの有無やホストフィールド（例：@ と www の違い）を間違えるとアウトページが発生します。チームにDNSガイダンスを共有するなら、上のような小さな表をドキュメントやランブックに置いておくとレビュやトラブルシューティングが格段に速くなります。
DNSが機能するのは多くの組織に責任が分散されているからです。この分散は、プロバイダを切り替えたり設定を変えたりしても、インターネット全体に許可を求める必要なく名前を維持できる理由でもあります。
ドメインを登録することは、一定期間その名前（例: example.com）を使う権利を買うことです。ラベルを予約するようなイメージ。
DNSホスティングは、その名前がどこに向かうか（ウェブ、メールプロバイダ、検証レコードなど）を指示する設定を公開することです。ドメインをある会社で登録し、別の会社でDNSをホストすることも可能です。
.com や .org、.uk などのTLDを運営する組織。各TLDの公式データベースを保ち、どの名前が誰のものでどのネームサーバが責任を持つかを管理する。ルートサーバはDNSの最上位に位置します。彼らはあなたのウェブサイトのIPアドレスを知らないし、あなたのドメインのレコードを保存しているわけでもない。仕事は限定的で、リゾルバに各TLDを扱う権威サーバがどこにあるかを教えることです。
レジストラでドメインの「ネームサーバ」を設定すると、それがデリゲーションを作ります。.com レジストリ（それの権威サーバ）は example.com の問い合わせをあなたが指定したネームサーバに向けます。
その瞬間から、そのネームサーバがインターネットの残りに提供する答えを制御します—あなたがデリゲーションを変更するまで。
DNSは信頼の上に成り立っています：名前を入力すると、その答えが本物のサービスに向かうと期待します。多くの場合期待通りですが、DNSは攻撃の定番の場所でもあります。なぜなら「その名前がどこに向かうか」を少し変えるだけで多くの人を誤誘導できるからです。
古典的な問題は 偽装（spoofing）やキャッシュポイズニング です。攻撃者がリゾルバを騙して偽の答えを保存させると、正しいドメイン名を入力してもユーザーは誤ったIPに送られます。フィッシングページやマルウェア配布、中間者攻撃の原因になります。
別の問題は レジストラでのドメイン乗っ取り です。誰かがあなたのレジストラアカウントに侵入すれば、ネームサーバやDNSレコードを変更してドメインを実質的に奪うことができます。
そして日常的な危険は 設定ミス です。余計な CNAME、古い TXT、間違った MX はログインフローやメール配信、所有権検証を壊します。こうした障害は「インターネットの障害」に見えることがありますが、実態は小さなDNS設定ミスです。
DNSSEC はDNSデータに暗号的署名を付けます。平たく言えば：DNSの応答が改ざんされておらず、本当にそのドメインの権威あるサーバから来たことを検証できるようにします。DNSSECはDNSの内容を暗号化したり匿名化したりするものではありませんが、多くの種類の偽装応答が受け入れられるのを防げます。
従来のDNSクエリはネットワーク上で観察されやすいです。DNS-over-HTTPS（DoH） や DNS-over-TLS（DoT） は端末とリゾルバ間の接続を暗号化し、盗み見や途中改ざんのリスクを減らします。これらはDNSを「匿名化」するものではありませんが、誰がクエリを見たり改ざんしたりできるかを変えます。
レジストラでMFAを有効化し、ドメイン／トランスファーロックを設定し、DNSを編集できる人を制限してください。DNSの変更を本番デプロイのように扱い、レビューを必須にし、変更ログを残し、レコードやネームサーバーの変更を監視して異変を早く知る仕組みを作りましょう。
DNSは「設定して忘れる」ものに見えがちですが、小さな変更でサイトやメールが落ちることがあります。幸い、いくつかの習慣を守ればDNS運用は予測可能になります—小規模チームでも実行可能です。
まず繰り返し使える軽量なプロセスを決めましょう：
多くのDNS問題は複雑ではなく、ただ発見が遅れるだけです。
頻繁にアプリをデプロイするチームでは、DNSもリリースプロセスの一部になります。たとえば、Koder.ai のようなプラットフォームからカスタムドメインを接続してデプロイする場合でも、同じ基本が必要です：正しい A/AAAA/CNAME ターゲット、切り替え時の妥当なTTL、間違った先を指してしまったときの明確なロールバック経路。
ドメインからメールを送る場合、DNSはメッセージが受信箱に届くかどうかに直接影響します。
人に優しい名前はインターネットを小さな研究コミュニティから大規模な共有インフラへと成長させました。DNSを共有インフラとして扱い、事前に小さな注意を払えばサイトは到達可能なまま、メールは信頼され続けます。
DNS（Domain Name System）は、人に覚えやすい名前（例: example.com）をコンピュータが使うIPアドレス（例: 93.184.216.34）に変換する仕組みです。
DNSがなければ、使うすべてのサイトやサービスの数字のアドレスを覚える必要があります。
初期のネットワークでは、ホスト名とIPアドレスを対応付ける単一の共有ファイル（HOSTS.TXT）に頼っていました。
しかしネットワークが成長するにつれて、更新が頻繁になり、名前の競合が増え、古いコピーによる障害が発生するようになりました。DNSは「世界共通の一つのファイル」方式を分散型のシステムに置き換えました。
ポール・モカパトリスは1980年代初頭にDNSを設計し、急速に成長するネットワーク上での命名のスケーリング問題を解決しました。
彼の重要なアイデアは*委任（delegation）*です：責任を多くの組織に分割して、単一のマスターリストや管理者がボトルネックとならないようにしたことです。
DNS名は右から左に読まれる階層構造になっています：
www.example.com..comexample.comwww.example.comこの階層構造がデリゲーションと運用管理を実現し、グローバルスケールでの管理を可能にします。
**再帰的リゾルバ（recursive resolver）**はあなたに代わって答えを探し、結果をキャッシュします（ISP、職場、またはパブリックプロバイダが運用）。
**権威あるDNSサーバ（authoritative DNS server）**はそのドメインの正しいレコードを保持する「最終的な答えの源」です。リゾルバは検索して答えを集め、権威サーバは自分のゾーンに関する正確な情報を返します。
典型的な名前解決の流れは次の通りです：
.com）→ ドメインの権威サーバ。A / AAAA などのレコードを返します。TTL（Time To Live）は、リゾルバがDNSの応答をどのくらいの間キャッシュしておくかを決める値です。
「伝播（propagation）」と呼ばれる現象は主に、世界中のキャッシュがそれぞれ異なるタイミングで期限切れになることを指します。
一般的に扱うレコードは次の通りです：
A / AAAA: 名前をIPv4/IPv6アドレスに向ける（ウェブやサーバー）**レジストラ（registrar）**はドメイン名を登録・更新する場所で、あなたがその名前を一定期間占有する権利を管理します。
**DNSホスティング（DNS hosting）**は、そのドメインがどこに向かうかを示すレコードを公開するサービスです。
登録先とDNSホストは別でも構いません。登録側で NS を変更して、別のプロバイダに委任できます。
DNSには次のようなリスクがあります：
MX や余計な CNAME、タイプミスで機能が壊れる。防御策としては、レジストラでのMFAやトランスファーロック、DNS変更のレビューとロールバック手順、可能ならの導入、そしてクライアントとリゾルバ間の暗号化（DoH/DoT）などがあります。
CNAME: あるホスト名を別のホスト名の別名にする（一般的に www）MX: ドメインのメール配送先TXT: 所有確認やメール認証（SPF, DKIM, DMARC）NS: そのドメインの権威サーバーを示す実務上のルール：同じホスト名に CNAME と A を同時に設定しないこと。