Namefi
すべての用語に戻る

DNS

人間が読めるドメイン名をコンピューターがインターネット上でトラフィックを転送する際に使用するIPアドレスに変換する、階層型の命名システム。

Namefi TeamNamefi Team著者Victor ZhouVictor Zhou編集者Chie KudōChie Kudō翻訳者2025年6月30日
  • glossary

DNS（Domain Name System）は、インターネットの分散型・階層型命名システムであり、example.com のような人間が読めるドメイン名を、ネットワーク機器がインターネット上でパケットを転送する際に使用するIPアドレスへと変換する。DNS がなければ、ユーザーはアクセスしたいサイトごとに数値アドレスを記憶しなければならない。1987年に IETF が発行した RFC 1034 および RFC 1035 で定義され、今日もなおインターネットの中核プロトコルの一つであり続けている。

DNS の役割

DNS は名前解決を担う。ドメイン名を受け取り、そのドメイン名に対応するリソースレコードを返す。最も一般的なのはIPアドレスであり、ブラウザやアプリケーションが接続先を把握するために使用する。このシステムはメールの転送（MX レコード）、ドメイン所有権の検証（TXT レコード）、特定のサーバー群へのゾーン権限の委任（NS レコード）にも利用される。

DNS は更新よりも参照の頻度がはるかに高いため、即時の一貫性よりも、世界中の数百万台のサーバーに分散されたキャッシュによる高速な読み取りに最適化されている。

DNS ルックアップの仕組み

ブラウザに example.com と入力すると、複数のステップからなる名前解決プロセスが始まる。

  1. ローカルキャッシュの確認。 オペレーティングシステムはまず自身の DNS キャッシュを確認する。有効な回答がキャッシュに存在すれば、ルックアップはその場で完了する。

  2. 再帰的リゾルバー。 キャッシュに回答がない場合、クエリはDNS リゾルバーへ転送される。これは ISP、企業（Cloudflare の 1.1.1.1 や Google の 8.8.8.8 など）、または組織が運営するサーバーである。このリゾルバーが代わりに回答を探す作業を引き受ける動作を再帰的解決と呼ぶ。

  3. ルートネームサーバー。 リゾルバーにもキャッシュされた回答がない場合、13 の論理的なルートゾーンネームサーバークラスター（a から m のラベルが付く）のいずれかに問い合わせる。ルートサーバーは最終的な回答を持たないが、.com や .org などの関連するトップレベルドメイン（TLD）を管理するネームサーバーへの参照を返す。IANA がルートゾーンデータベースを公開・管理している。

  4. TLD ネームサーバー。 リゾルバーは TLD ネームサーバーへ問い合わせる。TLD ネームサーバーは、特定のドメイン（example.com）の権威ネームサーバーへの参照を返す。

  5. 権威ネームサーバー。 リゾルバーはドメインの権威ネームサーバーへ問い合わせる。権威ネームサーバーは実際の DNS レコードを保持しており、リソースレコード——たとえば IPv4 アドレスを含む A レコード——を返す。

  6. 応答とキャッシュ。 リゾルバーはクライアントへ回答を返し、レコードのTTL（Time to Live）で指定された期間だけその結果をキャッシュする。TTL の有効期間中に同じ名前への後続クエリはキャッシュから応答され、レイテンシーの低減と上位サーバーへの負荷軽減に貢献する。

このパターン——リゾルバーが反復的な探索作業を担い、クライアントは一つのサーバーとのみ通信する——を再帰的解決と呼ぶ。対して反復的解決は、クライアント自身が階層の各レベルを順番に問い合わせる方式で、実際にはほとんど使われないが、リゾルバーが内部的に階層を辿る仕組みはこれに当たる（RFC 1034 §5.3）。

DNS の階層構造と主なレコードタイプ

DNS は逆ツリー構造として編成されている。頂点にはルート（.）があり、その下に TLD（.com、.net、.io、.de などの国別コード）が続く。各 TLD の下にはセカンドレベルドメイン（example.com）があり、さらに任意の深さのサブドメイン（mail.example.com）を持てる。

このツリーの各ノードをゾーンと呼び、あるゾーンの権威ネームサーバーはそのゾーンのリソースレコードを保持する。よく使われるDNS レコードタイプは以下のとおりだ。

レコード用途値の例
A名前を IPv4 アドレスにマッピング93.184.216.34
AAAA名前を IPv6 アドレスにマッピング2606:2800:21f:cb07::1
CNAMEある名前を別の正規名にエイリアスwww → example.com
MXドメインのメールサーバーを優先度付きで指定10 mail.example.com
NSゾーンを一連のネームサーバーへ委任ns1.example.com
TXT任意のテキストを格納。SPF、DKIM、ドメイン確認に使用"v=spf1 include:…"
SOAStart of Authority — ゾーン自体のメタデータシリアル番号、更新間隔、リトライ間隔など

CNAME レコードはゾーンの頂点（ベアドメイン example.com）には配置できない。CNAME はその名前の唯一のレコードでなければならないが、頂点には NS と SOA も必要だからだ。多くの DNS プロバイダーは独自の「CNAME フラット化」や ALIAS/ANAME という疑似レコードタイプでこの制限を回避している。

DNS の運営主体

DNS のガバナンスと運営は複数の階層の主体に分散されている。

  • ICANN / IANA。 Internet Corporation for Assigned Names and Numbers はルートゾーンを監督し、グローバルな DNS 名前空間を調整する。ICANN の機能の一つである IANA は、全 TLD とその権威ネームサーバーを記載したルートゾーンデータベースを管理している。

  • レジストリ。 レジストリは特定の TLD の権威データベースを運営する。たとえば Verisign は .com と .net を、Public Interest Registry は .org を運営している。レジストリは各ドメインのネームサーバーを指し示す NS レコードを公開・管理する。

  • レジストラー。 レジストラーは ICANN（または関連するレジストリ）から認定を受け、一般にドメイン名を販売し、顧客に代わって登録データをレジストリに提出する組織だ。

  • 再帰的リゾルバー。 DNS リゾルバーは ISP、公開 DNS サービス（Cloudflare、Google、Quad9）、企業、家庭用ルーターが運営する。上述の反復的ルックアップを処理し、クエリのレイテンシーを低減するために結果をキャッシュする（Cloudflare Learning — What is DNS?）。

  • 権威ネームサーバー。 ドメイン所有者またはその DNS プロバイダーがホストし、実際のゾーンファイルを保持してリゾルバーのクエリに確定的な回答を返す。

セキュリティ

DNS の元々の仕様は信頼性とスケールを重視して設計されており、セキュリティは考慮されていなかった。その後、いくつかの脆弱性と保護機構が登場した。

キャッシュポイズニング。 リゾルバーのキャッシュに偽造した DNS 応答を注入できた場合、攻撃者は利用者を正規サイトから悪意あるサイトへ気づかせることなく誘導できる。2008年のカミンスキー攻撃はこれを大規模に実証し、ポートランダム化と DNSSEC の普及を後押しした。

DNSSEC。 RFC 4033〜4035 で定義される DNS Security Extensions は、DNS レコードに暗号署名を追加する。DNSSEC 署名を検証するリゾルバーは改ざんされた応答を検出できる。普及は進んでいるものの均一ではなく、2024年時点でルートゾーンと主要 TLD の約 90% が署名済みだが、エンドツーエンドの検証にはチェーン内のすべてのゾーンが署名されていること、およびリゾルバーが署名を検証することが必要だ。

DNS ハイジャック。 レジストラーのアカウント、レジストリのシステム、または ISP のリゾルバーが侵害された攻撃者は、DNS 応答を大規模にリダイレクトできる。防御策としては、レジストラー側の多要素認証、レジストリロック（EPP の serverTransferProhibited）、予期しない NS や A レコードの変更に対する監視が挙げられる。

DNS over HTTPS / DNS over TLS（DoH / DoT）。 これらのプロトコルはクライアントとリゾルバー間の DNS クエリを暗号化し、通信経路上での盗聴やクエリの改ざんを防ぐ。データの整合性を扱う DNSSEC を補完するプライバシー保護の仕組みだ。

DNS とトークン化ドメイン

Ethereum Name Service などのブロックチェーンベースのドメインシステムの中には、従来の DNS 階層とは独立して名前とアドレスのマッピングをすべてオンチェーンで管理するものもある。また、通常の方法で登録されたドメインの所有権を表すオンチェーントークンを発行するものもあり、その場合は基盤となる DNS ゾーンファイルは引き続き標準的なネームサーバーでホストされる。後者の場合、DNS の名前解決は上述の通常のルックアップフローで機能し、ブロックチェーン上のレコードは所有権を証明するが名前解決のパスには含まれない。オンチェーンの所有権レコードとグローバル DNS は、共存またはゲートウェイリゾルバーを通じて橋渡しできる別々のレイヤーだ。

出典: RFC 1034, RFC 1035, IANA Root Zone Database, Cloudflare Learning — What is DNS?, ICANN — What is DNS?

関連キーワード

  • DNS
  • ドメインネームシステム
  • 名前解決
  • DNSルックアップ
  • DNSレコード
  • ネームサーバー
  • 再帰的リゾルバー
  • DNSSEC
  • インターネットインフラ
  • DNSとは
  • DNSの意味
  • DNSの定義

執筆・編集メンバー

Namefi Team著者
Namefiチーム • Namefi
LinkedInTwitter

Namefiは、エンジニア、デザイナー、オペレーション担当者からなるコレクティブです。 オンチェーンドメイン名を手間なく管理できるツールづくりに、ひたむきに取り組んでいます。

Victor Zhou編集者
創業者・標準仕様エディター • Namefi
WebsiteBlogGitHubLinkedIn

Victor Zhouは、デジタルアイデンティティと信頼を専門とするテクノロジー企業の創業者で、 標準仕様のエディターでもあります。Namefiを創業し、Ethereum Improvement Proposalsの 編集に携わっています。以前はGoogle Labsでスマートコントラクトのアーキテクチャ設計を 率いていました。

彼の仕事は、ネーミング、所有権、そして人々がオンラインで自らのアイデンティティを 確立するために使うシステムが交わる場所にあります。だからこそ、名前が個人的な意味、 社会的な認知、デジタルインフラの間をどのように行き来するのかに強い関心を持っています。

Namefiでは、永続的なデジタルアイデンティティとしてのドメインについて編集・執筆して います。名前が所有可能なオンチェーン資産になる仕組み、トークン化が保管と信頼をどう 変えるのか、そして人々がオンラインでアイデンティティを確立するために使うシステムから ネーミングが何を学べるのかを扱っています。

Chie Kudō翻訳者
日本語ローカライゼーション翻訳者 • Namefi

Chie Kudō（工藤 知恵）は、福岡を拠点とする30代の翻訳者です。電機メーカーで ハードウェアQAエンジニアとして製品資料の作成と確認に携わった後、英語と日本語の 間で技術記事や編集記事をローカライズする仕事に転じました。

品質保証で身につけた習慣は、今の仕事にも生きています。用語の一貫性はもちろん、 ブランド名を漢字、かな、ローマ字のどれで表すか、半角と全角をどう使い分けるか、 借用元の英語とは異なる意味を持つ和製英語をどう扱うかといった、日本語組版ならではの 細部を厳しく確認します。小さなベランダ菜園を楽しみ、週末にはボルダリングをします。

Namefiでは、ドメインとネーミングに関する記事を日本語にローカライズしています。 名前がページ上でどう読めるか、そして最初から正しく入力してもらえるかに目を配っています。