--- > [!NOTE] 目次 ```table-of-contents title: minLevel: 0 maxLevel: 0 includeLinks: true ``` --- > [!NOTE] リスト掲載用文字列 - [DSレコード有効1%——.JPドメインを守るDNSSEC｜「TLDは対応している」のに導入が進まない理由](https://innovatopia.jp/infrastructure/infrastructure-news/81645/)【innovaTopia -（イノベトピア） - ーTech for Human Evolutionー】(2026年03月02日) --- > [!NOTE] この記事の要約（箇条書き） - .JPドメインにおけるDNSSECの有効化率が約1%と非常に低い現状を指摘。 - DNSSECは、DNS応答に電子署名を付与し、改ざん検知と真正性検証を可能にする重要なセキュリティ技術である。 - .JPのTLDゾーン自体はDNSSECに完全対応しており、JPRSも導入を推奨している。 - 普及が進まない主な理由として、レジストラ（指定事業者）がDNSSECを「有料オプション」または「サービスの一部」として提供していることが挙げられる。 - DNSSECは、もはや「オプション」ではなく、基本的なITインフラのセキュリティ要素であると強調されている。 - キャッシュDNSサーバの脆弱性（DNSキャッシュポイズニングなど）から保護するためにも、DNSSECの導入と検証が不可欠である。 - 導入推進のためには、DNSSECに対するユーザーと事業者の意識向上が求められる。 > [!NOTE] 要約おわり --- \[公開\] \[更新\]2026年3月2日  .JP ドメインのゾーンは DNSSEC に守られている。しかし移譲された多くのゾーンは未だ DNSSEC 署名されていない。 『JANOG 57』（日本のインターネット運用に携わる技術者のミーティング）が2026年2月11日（水・祝）から13日（金）まで開かれた。JANOG 57 でも、DNSの不正利用防止などについて議論が行われた。近年でも、ドメインの乗っ取りが後を立たない。多くはlame delegation（意図せず移譲されたままになっているドメイン）やドメインスクワッティング（失効したドメインの第三者による再取得など）が原因となっているが、 **ネットワークレベルの攻撃者に対しては、DNSSECという技術が、DNSを電子署名することで完全性を担保する、最後の砦となる。** ここでは、 **DNSのセキュリティの要となる、DNSSEC** の、日本における普及状況として、**.JPドメイン** に的を絞って、最新の状況を見ていく。 **.JP** は、DNS上で日本に割り当てられた **ccTLD（国別トップレベルドメイン）** である。 **JPRS（株式会社日本レジストリサービス）がレジストリとして管理しておいて、.JP ゾーンの権威DNSサーバはDNSSECで完全に電子署名されている** 。また、**.JP ドメインはDSレコードによるネームサーバの安全な移譲に完全に対応** している。しかし、 **Internet Week 2024 DNS Day 資料が明かすのは、.JPドメインのうち、DNSSEC署名されているのは、約1%に過ぎないという不都合な事実だ。その他の約99%のドメインは、安全ではない** 。 **これは、先進国の国別ドメインでは、極めて低い数値である** 。この記事では、なぜこのようなことが起きるのか、日本のDNSの最前線から、その理由を解き明かしていきたい。 ## DNSSECとは 元来、インターネット上で名前解決を行うDNSは、本質的に「問い合わせに対して応答を返す」だけの仕組みであり、暗号学的な完全性保護を前提として設計されたものではありません。そのため、ネットワーク経路上にいる攻撃者や、キャッシュポイズニングのような攻撃に対しては、本来きわめて脆弱でした。 **ここで重要になるのがDNSSECです。DNSSECはDNS応答に電子署名を付与することで、「そのデータが正当な権威サーバから発行され、改ざんされていないこと」を検証可能にする仕組みであり、ネットワークレベルの攻撃者に対する完全性確保の最後の砦と言えます。** DNSは階層構造に基づいて動作しています。 `www.example.co.jp.` のような名前はラベルごとに区切られ、右側から順に `.`（ルート）→ `jp.` → `co.jp.` → `example.co.jp.` → `www.example.co.jp.` という論理的な階層を形成します。ただし、各ラベルごとに必ずゾーンが存在するわけではありません。例えば `co.jp.` は登録単位として広く使われていますが、独立したゾーンとして運用されているわけではありません。DNSは、あるゾーンが下位のゾーンを別の権威サーバへ「委任」することで成り立っています。この委任はNSレコードによって示され、名前解決はこの階層的な委任をたどることで進みます。 しかし、従来のDNSでは、この「どこへ委任するか」という情報自体が改ざんされていない保証はありませんでした。DNSSECでは、各ゾーンが自らの公開鍵でゾーンデータに署名し、その公開鍵の正当性を上位ゾーンがDS（Delegation Signer）レコードによって保証します。具体的には、子ゾーンの公開鍵のハッシュ値を親ゾーンがDSレコードとして署名付きで保持し、それをたどっていくことで、最終的にルートゾーンに格納された信頼の起点（トラストアンカー）まで連なる「信頼の鎖」が成立します。この鎖が成立してはじめて、利用者側は「この応答は正当な権威から来たものである」と検証できるのです。 一方で、DNSSECはあくまで「完全性と真正性」を保証する技術であり、通信内容の秘匿や盗聴対策は別の層の課題です。そこで重要になるのが、キャッシュDNSとの通信を暗号化するDoT（DNS over TLS）やDoH（DNS over HTTPS）です。DoT/DoHは利用者とリゾルバ間の通信経路を暗号化し、盗聴や改ざんを防ぎます。そして、そのリゾルバがDNSSEC検証を行うことで、権威サーバから得た情報の完全性を確認します。 **すなわち、DoT/DoHとDNSSECは役割が異なりながらも相補的であり、ネットワークレベルの攻撃者に対抗するDNSセキュリティの「双璧」と位置づけられます** 。 ルートから各ゾーンへと続く署名付き委任の鎖が確立され、かつ利用者が信頼できるリゾルバと暗号化通信を行ってはじめて、DNSは現在の脅威環境に耐えうる基盤となります。 **DNSSECは単なる追加機能ではなく、階層的に構築されたDNSという仕組みを暗号学的に補強するための根幹技術** なのです。 ## Internet Week 2024 DNS Day 資料を読み解く **Internet Week は日本のインターネットの番号資源の管理をしているJPNIC（一般社団法人日本ネットワークインフォメーションセンター）が主催し、毎年開かれる日本のインターネット運用に携わる人向けのイベント** です。有料のイベントであり資料は約1年遅れで公開されるので、この記事では、公開されている DNS Day (2024年) の資料から、.JPゾーンにおけるDNSSECの普及状況を見ていきますが、2025年の資料でも、2026年2月現在でも、大きな変化はありません。 **JP DNS Update / 池田 和樹(株式会社日本レジストリサービス)** [https://www.nic.ad.jp/ja/materials/iw/2024/proceedings/d2/d2-1-ikeda.pdf](https://www.nic.ad.jp/ja/materials/iw/2024/proceedings/d2/d2-1-ikeda.pdf) この講演は、2024年11月26日に行われたもので、スライドのp.10、「DSあり委任数の状況」を見ると、DNSSECが有効化されている（DSレコードが移譲に存在する）.JPドメインの総数が分かります。この統計は、汎用.JPドメイン（素の.JPドメイン）、都道府県型.JPドメイン（ `example.tokyo.jp` のような）、属性型.JPドメイン (`example.co.jp` / `example.go.jp` のような)、地域型.JPドメイン（新規登録は廃止された）を合わせた総数です。 この10ページにあるグラフを見ると、 **2023年半ばにDNSSECが有効化されたドメインが約14,000個近くに達して以来、横ばいになっているのが分かります。.JPドメインの総数は、「2023年11月1日現在：1,769,106件」とあります。つまり、DNSSECが有効になった移譲がされている.JPドメインは、.JPドメインの総数の1%に満たないのです。** この状況は、IW2025の発表でも、また関係者によれば2026年2月現在の.JPゾーンにおいても、大きく変わっていません。 ## .JPゾーン自体はDNSSECに完全対応 JPRSが管理する.JPのTLDゾーン自体はDNSSECで完全に署名されており、また、レジストリであるJPRSは、DSレコード付きの署名された（DNSSECが有効な）移譲をサポートしていますし、強く推奨しています。 DNSSECは決して新しい技術ではありません。この技術は、10年以上にわたって、国際的に広く運用されてきました。 では、なぜ.JPドメインにおいて、DNSSECの普及が進まないのでしょうか。 ## DNSSECを「オプション」である「サービス」として提供する事業者 .JPドメインの登録は、基本的には、レジストリであるJPRSに対して直接するのではなく、 **「レジストラ」と呼ばれる事業者（指定事業者、JPNICにおけるIPアドレス管理指定事業者とは別の概念）** を通して（取り次がれて）行われます。 → [指定事業者 五十音順 一覧｜JPRS](https://jprs.jp/registration/list/meibo/meibo_a.html) 「あ行」から順番に見ていくと分かるのですが、 **DNSSECの「署名鍵」の欄に○が付いている事業者は、非常に少なく** なっています。また、DNSの登録のみを単体で提供するのではなく、多くの事業者が、「ホスティングサービス」としてドメイン名登録の取り次ぎを行っており、それが唯一のオプションである事業者も多い状況です。 さらに、 **DNSの単体登録が可能な事業者でも、DNSSECは「有料のDNSホスティングサービスを利用時のみ利用可能なオプション」として提供されていることが少なくありません** 。つまり、DNSSEC は本来インフラレベルの問題であるのに、サービスの問題になってしまっているのです。 これが問題となるのが、自社でインフラを構築するときはもちろん、外部のサービスを利用するときです。外部のホスティングサービスや、Cloudflare のような CDN を利用するときには、そのサービスの権威DNSサービスを使う必要があることが少なくありません。 **DNSホスティングでしかDNSSECを利用できない事業者で登録を行っていると、このような外部のサービスを利用するときに、DNSSEC が利用できない** ということになります。 ### キーポイント ## DNSSECは基本的なインフラセキュリティ——「オプション」ではない **DNSSECは、もはや一部の高度な運用者だけが導入する付加機能ではなく、基本的なITインフラを構成するセキュリティ要素のひとつです。サイバー攻撃が日常化し、名前解決を標的とした改ざんやフィッシングが現実的な脅威となっている現在、DNSの応答が正当な権威サーバから発信されたものであることを暗号学的に検証できる仕組みは不可欠なもの** です。DNSSECは、完璧ではないことをしばしば指摘されるものの、インターネットの基盤であるDNSに対して完全性と真正性を与える、最も根源的な防御策です。 さらに、 **HTTPS証明書がACMEプロトコルによって自動発行・自動更新されることが当たり前になった現代において、Webの暗号化だけが進み、名前解決の信頼性が取り残されるのは危険です。DNSが信頼できないなら、途中経路でDNSが乗っ取られた状態で不正な証明書が第三者に発行される可能性も** あります。HTTPSなどで通信経路を暗号化するだけでは不十分であり、その通信先の名前解決自体が信頼できなければ意味がありません。また、DNSはSPFやDKIM、DMARCなど、迷惑メールを防ぐ基盤にも使われています。DNSSECは、もはや「有効にするかどうかを選ぶサービスのオプション」ではなく、インターネットサービスを提供する上で前提となるべき基盤的安全対策なのです。 ## 【用語解説】 **DNSSEC（Domain Name System Security Extensions）** DNS応答に電子署名を付与し、改ざん検知と真正性検証を可能にする仕組み。 **DSレコード（Delegation Signer）** 親ゾーンが子ゾーンの公開鍵情報を保証するためのレコード。信頼の鎖を構成する要素。 **信頼の鎖（Chain of Trust）** ルートから各ゾーンへと署名が連なることで成立する検証構造。 **レジストリ／レジストラ** レジストリはTLDを管理する主体、レジストラは利用者の登録を取り次ぐ事業者。 **DNSaaS（DNS as a Service）** DNSをホスティング型サービスとして提供する形態。 **キャッシュポイズニング（DNSキャッシュ汚染）** 偽のDNS応答をキャッシュに保存させる攻撃手法。 **lame delegation（不正な委任状態）** 委任先ネームサーバが正しく応答しない状態。意図せず移譲が残っている場合などに起きる。 **DoT / DoH（DNS over TLS / HTTPS）** 利用者とリゾルバ間の通信を暗号化する技術。DNSSECとは役割が異なる。 **トラストアンカー（Trust Anchor）** 検証の起点となる公開鍵（通常はルートゾーンの鍵）。 ## 【関連記事】 ## 【参考リンク】 **株式会社日本レジストリサービス (JPRS)** [https://jprs.jp](https://jprs.jp/) **JPDirect – JPRS** [https://jpdirect.jp/](https://jpdirect.jp/) – JPRSによる.JPドメインの直販サービス。基本的にはDNSをサービスとしてではなく、純粋な移譲として提供し（DNSホスティングは実験的オプション）、DNSSECの移譲も標準サポートされている。 **DNS cache poisoning(DNSキャッシュポイズニング)とは – JPNIC** [https://www.nic.ad.jp/ja/basics/terms/DNS-cp.html](https://www.nic.ad.jp/ja/basics/terms/DNS-cp.html) **DNS Day – Internet Week 2024 – JPNIC** [https://www.nic.ad.jp/ja/materials/iw/2024/proceedings/d2/](https://www.nic.ad.jp/ja/materials/iw/2024/proceedings/d2/) **（緊急）BIND 9.xの脆弱性（DNSキャッシュポイズニングの危険性）について（CVE-2025-40778）** – JPRS [https://jprs.jp/tech/security/2025-10-23-bind9-vuln-cachepoisoning.html](https://jprs.jp/tech/security/2025-10-23-bind9-vuln-cachepoisoning.html) → 前回見つかった有名DNSサーバソフトの脆弱性。DNSSEC があれば、キャッシュDNSサーバにおいて、このような脆弱性の影響を減らすことができる。 ## 【編集部後記】 DNSはドメイン名をホストする階層構造の「権威DNSサーバ」と、利用者が名前解決をするのに直接利用する「キャッシュDNSサーバ/リゾルバ」の2種類のサーバによって動いています。キャッシュDNSサーバの実装には、定期的に **DNSキャッシュポイズニング** などを許してしまう脆弱性が見つかっています。これは、DNSSECを有効化し、検証することが常に求められているということです。 ドメイン名（名前解決）の安全性を担保するための仕組みはDNSSECであり、すでにあります。しかし、.JPドメインにおいては、事業者（レジストラ）が対応を見送っていることで、導入は進んでいません。これを変えるには、DNSSECに対するひとりひとりの意識を高めることで、事業者がDNSSECを標準で提供するような空気を作っていく必要があるのではないでしょうか。 ---