DNSSECとは？仕組み・導入手順・確認方法・診断基準をわかりやすく解説

DNSSECとは

DNSSEC（DNS Security Extensions）とは、DNSの応答にデジタル署名を付け、受け取ったリゾルバが「その応答がゾーン管理者の作成したものから改ざんされていないか」を検証できるようにする仕組みです。署名の信頼はルートゾーンから .jp、さらに各組織のゾーンへと、親ゾーンに登録したDS（Delegation Signer）レコードで連鎖します。

DNSSECの検証に対応したリゾルバ（Google Public DNS、多くのISPリゾルバ等）は、検証に成功するとAD（Authenticated Data）ビットを立てて応答し、署名が不正な場合はSERVFAILを返して偽の応答を利用者に渡しません。これにより、キャッシュポイズニングなどでWebサイトやメールの宛先をすり替える攻撃への耐性が高まります。

この項目は、診断対象ホスト名の名前解決がDNSSECで検証済みとなるかを確認します。

DNSSECの主なレコードの役割

DNSSECの仕組み：信頼の連鎖と検証結果

仕組みの要点

• ゾーン管理者（DNS事業者）がゾーンにDNSKEY・RRSIG・NSEC/NSEC3を追加して署名します。
• 署名鍵のハッシュ（DS）を、レジストラ（JPドメインでは指定事業者）経由で親ゾーンに登録します。JPRSは2010年10月にJPゾーンの署名を開始し、同年12月にルートゾーンへJPのDSを登録したうえで、2011年1月16日にJPドメイン名サービスへDNSSECを導入しました。
• 検証リゾルバは、ルートの信頼アンカーから順にDS→DNSKEY→RRSIGを検証し、すべて成功した場合にADビットを付けます。
• Google Public DNSのJSON APIは、応答の AD フィールドに「応答データ全体がDNSSECで検証されたか」を返し、検証失敗時は Status: 2（SERVFAIL）を返します。

検証結果の3つの状態（Secure・Insecure・Bogus）

• Secure：信頼の連鎖が最後までつながり、署名が正しい。ADビットが立つ。
• Insecure：親ゾーンにDSがない（未署名）ことが証明されている。応答は通常どおり返るがADは立たない。現在の多くのドメインがこの状態です。
• Bogus：DSがあるのに署名が不正・期限切れ・鍵不一致。検証リゾルバはSERVFAILを返し、利用者は名前解決できなくなります。

DNSSECを「導入していない」状態（Insecure）は不便を生みませんが、「導入して運用に失敗した」状態（Bogus）はサービス停止に直結します。この非対称性が、DNSSEC導入の判断を難しくしている主な理由です。

CNAMEとADの関係

ホスト名がCDN等へCNAMEされている場合、ADが立つのはCNAMEの連鎖全体が検証できたときです。自治体のゾーンを署名していても、CNAME先のCDNのゾーンが未署名ならADは立ちません。

DNSSECについてよくある誤解

• 「DNSSECで通信が暗号化される」：DNSSECは真正性・完全性の保証であり、問い合わせ内容は暗号化しません（暗号化はDoH/DoT等の役割です）。
• 「HTTPSがあればDNSSECは不要」：偽サイトに誘導されてもTLS証明書の検証で多くは防げますが、ドメイン認証型の証明書の不正取得、メール配送（MX）の改ざん、HTTPのみのリンク等に対しては、DNSSECが追加の防御になります。
• 「署名すれば終わり」：鍵の更新（ロールオーバー）や署名の有効期限切れ、DS登録の不整合で検証が失敗すると、検証リゾルバ利用者からドメイン全体が名前解決できなくなるという強い副作用があります。運用体制が前提です。

DNSSECの診断基準（セキュリティAIチェッカー）

取得方法

• 診断の最終URL（リダイレクト追跡後）のホスト名そのもの（www. を含む）について、Google Public DNSのDNS over HTTPS（JSON API）でAレコードを照会します（DNSSEC検証は既定で有効）。
• 通信失敗・非2xx応答時は短い待機を挟んで最大3回試行します。

判定条件

× 要改善（fail）はありません。DNSSECは導入・運用の負担が大きく、未導入の組織も多いことから「導入を検討すべき改善項目」として △ にとどめています。IPアドレスで指定した診断ではDNS項目全体が対象外になります。

判定の限界

• ADが立たない理由（未署名／CNAME先が未署名／署名不正）は区別していません。Status: 2 が返る場合は署名不正の可能性があるため、DNSViz等で確認してください。
• 公開リゾルバ1か所の結果に基づきます。
• 確認するのはWebサイトのホスト名のA応答だけです。メールドメインやMXが署名されているかは、別途 dig +dnssec MX 等で確認してください。

自治体サイトでの判定例

DNSSECがないとどんなリスクがあるか

• キャッシュポイズニング：偽のDNS応答をリゾルバのキャッシュに注入し、住民を偽サイトへ誘導する攻撃です。2008年に公表されたカミンスキー型攻撃以降、ソースポートのランダム化等で難度は上がりましたが、DNSSECは応答そのものの真正性を検証できる根本的な対策です。
• メールの宛先改ざん：MXレコードがすり替えられると、自治体宛てのメールが攻撃者のサーバーに届く可能性があります。
• 証明書の不正取得との組み合わせ：CAのドメイン認証時のDNS応答が改ざんされると、不正発行につながり得ます。RFC 8659がCAA確認でのDNSSEC検証を強く推奨し、CA/Browser ForumがBallot SC-085v2で、DNSSECが設定されたドメインについてCAA・ドメイン認証のDNS照会時の署名検証を2026年3月15日からCAに義務付けたのはこのためです。発行できるCAの制限は「CAAレコード」の項目で確認します。
• 導入時のリスク：一方で、鍵管理の失敗は自組織のサイトとメールを全面停止させます。署名が壊れた状態ではCAの検証も失敗するため、サーバー証明書の発行・更新もできなくなります。リスク評価では「攻撃に対する防御」と「運用ミスによる停止」の両面を考慮します。

DNSSECの導入手順と確認方法（クラウドDNS・BIND）

1. 前提を確認する

• 利用中の権威DNS事業者（自治体情報セキュリティクラウド、LGWAN-ASP事業者、クラウドDNS等）がDNSSEC署名と鍵の自動更新に対応しているか。
• ドメインの登録を管理する指定事業者（レジストラ）がDS登録の取次に対応しているか。
• CNAME先（CDN、CMSのSaaS）がDNSSECに対応しているか。対応していなければ、Webのホスト名単位ではADは立ちません（メールやその他のレコードは保護されます）。

2. 一般的な導入手順

1. DNS事業者の機能で署名を有効化する（多くは管理画面の操作で、アルゴリズムはECDSA P-256 = アルゴリズム13が一般的。SHA-1を使うアルゴリズム5・7はRFC 9905で使用禁止となったため、古いゾーンで残っていれば移行する）。
2. 生成されたDSレコード（またはDNSKEY）を指定事業者経由で親ゾーンに登録する。
3. 検証が通ることを確認する。
4. 鍵の更新（ZSK/KSKロールオーバー）の手順と担当、事業者変更時の手順（DSの削除・付け替え）を文書化する。

Cloudflare、Amazon Route 53、Azure DNS（対応状況は各社の最新ドキュメントで確認）など主要クラウドDNSは署名機能を提供しています。BIND等で自前運用する場合は dnssec-policy による自動署名を使うと鍵更新の負担を減らせます。

// BIND 9.16以降の例（named.conf）
zone "city.example.lg.jp" {
    type primary;
    file "db.city.example.lg.jp";
    dnssec-policy default;
    inline-signing yes;
};

3. 確認方法（ADフラグ・DS・DNSViz）

# ADフラグ（flags: に ad が含まれるか）
dig +dnssec www.city.example.lg.jp A @8.8.8.8

# DS登録の確認
dig +short DS city.example.lg.jp

# 本診断と同じ取得経路
curl -s "https://dns.google/resolve?name=www.city.example.lg.jp&type=A" | grep -o '"AD":[a-z]*'

DNSViz（https://dnsviz.net/）で信頼の連鎖を図示して確認するのも有効です。Bogusの疑いがあるときは、検証を無効にした照会（`cd=1`）と比較すると切り分けできます。

# 検証あり（Bogusなら Status 2）
curl -s "https://dns.google/resolve?name=www.city.example.lg.jp&type=A"
# 検証なし（cd=1）。こちらで応答が返るなら署名側の問題
curl -s "https://dns.google/resolve?name=www.city.example.lg.jp&type=A&cd=1"

設定後は、セキュリティAIチェッカーで再診断し、根拠欄が「DNSSEC検証済み応答です。」になっていることを確認します。

4. 運用チェックリスト

名前解決を止めないための注意点（ガードレール）

• DS登録は署名が正しく公開された後に行う。順序を誤ると検証失敗でドメイン全体が名前解決できなくなります。
• DNS事業者を移行するときは、先にDSを外すか、新旧の鍵を両方公開する手順を踏む。旧事業者の解約でDNSKEYが消えると、DSが残ったまま検証不能になります。
• 署名の有効期限切れを監視します（多くのマネージドDNSでは自動）。
• 停止時の影響が大きいため、メール・Web・各種システムの担当者と事前に切り戻し手順（DSの削除と、TTL経過までの待機）を共有します。

よくある質問（FAQ）

参考資料

• RFC 4033 DNS Security Introduction and Requirements
• RFC 9364 DNS Security Extensions (DNSSEC)
• RFC 9905 Deprecating the Use of SHA-1 in DNSSEC Signature Algorithms
• RFC 8659 DNS Certification Authority Authorization (CAA) Resource Record
• CA/Browser Forum Ballot SC-085v2
• JSON API for DNS over HTTPS (DoH)（Google Public DNS）
• JPRS deploys DNSSEC in .jp
• JPRS DNSSEC情報
• DNSViz
• @IT「RPKI」「DNSSEC」「DMARC」のガイドライン策定に込められた思い

「DNSSEC」と関連する診断項目

• CAAレコードlow
• SPFレコードmedium
• SPFの終端ポリシーmedium
• DMARCレコードhigh
• DMARC強制ポリシーmedium
• DMARC集計レポート送信先low
• SPFの一意性・構文・DNS参照数high
• MTA-STSmedium