DNSSECDNSWeb 担当者

DNSSEC とは|Web 担当者の導入判断ガイド

ドメイン番人4 分で読めます
目次

この記事でわかること

  • DNSSEC が解決する問題と、解決しない問題
  • Web 担当者が DNSSEC を導入するべきケース・避けるべきケース
  • 運用上の最大リスク「鍵の管理ミスでドメインが見えなくなる」の対処

DNSSEC は「DNS 応答の電子署名」

DNSSEC(DNS Security Extensions、ディーエヌエスセック)は、DNS の応答に 電子署名を付ける拡張仕様です。RFC 4033 などで標準化されており、目的は DNS 応答の改ざん検出です。

通常の DNS には次の弱点があります。

  • 攻撃者がネットワーク経路上で DNS 応答を書き換えると、ユーザーは偽のサーバーに誘導される
  • これは「DNS キャッシュポイズニング」と呼ばれ、DNS の根本的な脆弱性

DNSSEC を導入すると、ドメインの所有者が 秘密鍵で DNS レコードに署名し、リゾルバ側で 公開鍵による署名検証ができるようになります。署名が壊れていれば応答を破棄するため、改ざんがあれば必ず検出できます。

DNSSEC の仕組み(署名と検証)

仕組みは強力ですが、運用が複雑なため、「使えば必ず安全」というシンプルな話ではない点が中小企業導入のポイントです。

DNSSEC が「守らないこと」

DNSSEC のスコープを正確に理解しておくと、過度な期待や勘違いを防げます。

  • DMARC のような「メールのなりすまし防止」は守らない: メール認証は別仕組み(SPF/DKIM/DMARCの違い参照)
  • TLS / HTTPS のような「通信内容の暗号化」は守らない: DNSSEC は応答の改ざん検出のみ
  • ドメインの不正取得・なりすましドメインの登録は守らない: これはドメイン奪取対策参照

つまり DNSSEC は 「DNS そのものの信頼性を守る」 ピンポイントの仕組みであり、銀の弾丸ではありません。

導入のメリット 3 点

  1. DNS キャッシュポイズニング攻撃への耐性向上: 経路上での DNS 応答改ざんを検出できる
  2. 特定の高度なセキュリティ要件への対応: 政府系・金融系など、ガバナンスとして DNSSEC を要求される業界がある
  3. DANE / SMTP DANE の前提条件: メールサーバー間の証明書検証を強化する DANE は DNSSEC を前提とする

逆に、Web 通信の安全性は HTTPS が圧倒的に重要で、DNSSEC を有効化しなくても日常業務に困ることはほぼありません。サイト運営者ではこの優先順位を見誤らないことが大切です。

運用リスク ─ 「鍵の管理ミスでドメインが見えなくなる」

DNSSEC の最大の運用リスクは 鍵管理ミスによるドメイン全体のダウンです。

DNSSEC では署名鍵(KSK / ZSK)を定期的にローテーションする必要があります。RFC 6781 でも運用実務として推奨されている作業ですが、ここで失敗すると次のような事故が起きます。

  • 署名が無効になり、リゾルバ側が DNS 応答を破棄
  • 結果、ドメイン全体が世界中から見えなくなる(SERVFAIL)
  • 復旧には親ゾーンの DS レコードの再登録が必要で、時間がかかる

DNSSEC 運用上のリスク

実際、過去には大手レジストラや政府系組織が DNSSEC の鍵管理ミスでドメインダウンを起こした事例もあります。「設定して放置」は最もリスクの高いパターンです。

中小企業の導入判断 ─ 3 つの軸

導入すべきかを次の 3 軸で判断できます。

軸 1: 業界・取引先の要件

  • 金融・公共・医療などで DNSSEC を要求される → 導入必須
  • 一般の中小企業 → 必須ではない

軸 2: DNS 運用体制

  • 自社で DNS サーバーを運用 + 専任の運用担当者あり → 鍵管理が回る
  • レンタル DNS サービスを使っており、自社で鍵管理しない → 業者側の自動運用に任せる前提なら導入可
  • 体制が薄く、自社で鍵をローテーションする運用が回らない → 導入見送り

軸 3: コスト感

  • Cloudflare、Google Cloud DNS、AWS Route 53 など主要 DNS サービスは DNSSEC を無料で提供
  • 自前運用なら DNSSEC 専用の運用工数(月数時間)が追加発生

現実解は、「Cloudflare などの主要 DNS サービスを使っているなら、ボタン 1 つで DNSSEC 有効化」が最も無理のない選択肢です。

主要 DNS サービスでの有効化手順(概要)

Cloudflare

  1. ダッシュボードで対象ドメインを選択
  2. DNS → Settings → DNSSEC を有効化
  3. 表示される DS レコード値を レジストラの管理画面に登録

AWS Route 53

  1. Route 53 のホストゾーンで「DNSSEC 署名」を有効化
  2. KSK を作成
  3. DS レコードをレジストラに登録

Google Cloud DNS

  1. ゾーンの設定で DNSSEC を有効化
  2. 自動生成された DS レコードをレジストラに登録

いずれも レジストラ側で DS レコードを登録するステップが必須です。これを忘れると検証チェーンが繋がらず、DNSSEC が機能しません。詳細はドメイン管理を外注するメリットで扱う「外注先選定」観点も参考になります。

まとめ

  • DNSSEC は DNS 応答の改ざん検出を行う仕組み。中小企業の必須条件ではない
  • 主要 DNS サービスを使っていれば無料で有効化できるが、鍵管理ミスでドメインが落ちるリスクがある
  • 業界要件・運用体制・コストの 3 軸で判断し、無理なら導入を見送るのも合理的

自社のDNS状態を確認

DNSSEC を含む DNS インフラの健全性は、無料のドメイン診断で一括チェックできます。NS 冗長性 / DNSSEC / CAA / IPv6 など、DNS 全体の状態を可視化します。

DNSSEC を含む DNS 運用を専門家に任せたい場合は、お気軽にご相談ください。鍵ローテーションを含む継続運用までカバーします。

次の一歩は無料診断から。