## この記事でわかること

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

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

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

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

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

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

![DNSSEC の仕組み(署名と検証)](/blog/dnssec-basics/dnssec-flow.svg)

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

## DNSSEC が「守らないこと」

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

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

つまり 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 運用上のリスク](/blog/dnssec-basics/risk-flow.svg)

実際、過去には大手レジストラや政府系組織が 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 が機能しません。詳細は[ドメイン管理を外注するメリット](/blog/domain-management-outsource)で扱う「外注先選定」観点も参考になります。

## まとめ

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

## 自社のDNS状態を確認

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

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