DNSSEC とは — DNS応答の改ざんを防ぐ

DNSSEC とは何ですか？

DNSSEC（DNS Security Extensions）は、DNS の各レコードに電子署名を付け、リゾルバが「この応答は正規の権威サーバーが返したもので、途中で改ざんされていない」ことを検証できるようにする拡張です。通常の DNS は応答が本物かを確かめる手段を持たないため、DNSSEC はその欠けていた出所の検証を後付けで補います。

ふだん私たちが URL を入力すると、ブラウザはまず DNS に「このドメインの IP アドレスは何か」を尋ねます。 ところが素の DNS には、返ってきた答えが本当に正規のサーバーから来たものかを確かめる仕組みがありません。 高速化のために応答を鵜呑みにして中継・キャッシュする設計になっているため、途中で誰かがすり替えても、 受け取った側はそれに気づけないのです。

DNSSEC（DNS Security Extensions）は、この「出所を確かめられない」という DNS の根本的な弱点を、 電子署名によって後付けで補う拡張です。ゾーンの管理者が各レコードに署名を付けておき、 リゾルバ（問い合わせを代行するサーバー）がその署名を検証することで、「この応答は正規の権威サーバーが出したもので、途中で書き換えられていない」ことを確認できるようになります。

DNSSEC は何を防ぎますか？

主に DNS キャッシュポイズニング、つまり応答を偽装して利用者を偽サイトへ誘導する攻撃を防ぎます。攻撃者が正規サーバーになりすまして偽の IP アドレスを返しても、署名の検証に失敗するため対応リゾルバはその応答を拒否します。入力した URL は正しいのに別のサーバーへ飛ばされる、という被害を根元で止められます。

DNSSEC が主眼に置くのは、DNS キャッシュポイズニングと呼ばれる攻撃です。 攻撃者は正規の権威サーバーになりすまし、リゾルバに偽の応答を先回りして送り込みます。 これが成功すると、リゾルバのキャッシュには「example.com の IP は攻撃者のサーバー」という偽の対応関係が焼き付き、そのキャッシュを使う利用者はまとめて偽サイトへ誘導されてしまいます。

恐ろしいのは、利用者側に落ち度が無いことです。入力した URL は正しく、ブラウザのアドレスバーの表示も正しい。 それでも名前解決の結果だけがすり替わっているため、フィッシングやマルウェア配布のサイトへ静かに飛ばされます。 DNSSEC が有効なら、攻撃者の偽応答は署名の検証に失敗するため、 対応リゾルバはその応答を採用せずに捨てます。攻撃の成立条件そのものを崩すわけです。

DNSSEC は通信を暗号化しますか？

いいえ。DNSSEC が提供するのは認証と完全性であって、機密性ではありません。応答が本物で改ざんされていないことは保証しますが、DNS の中身は依然として平文で流れ、第三者は誰がどのドメインを引いたかを観察できます。通信内容を隠す暗号化は DoH や DoT の役割で、DNSSEC とは目的が別の仕組みです。

ここは最も誤解されやすい点なので、はっきり分けておきます。DNSSEC が守るのは「答えが本物かどうか（認証）」と「途中で改ざんされていないか（完全性）」の 2 点だけです。「誰が何を引いたかを他人に見せない（機密性）」は範囲外で、DNS の問い合わせと応答は DNSSEC を有効にしても平文のまま流れます。経路上の第三者は、あなたがどのドメインを訪れようとしているかを依然として観察できます。

通信内容そのものを隠したいなら、それは DoH（DNS over HTTPS）や DoT（DNS over TLS）という 別の仕組みの役割です。両者はしばしば混同されますが、目的が異なります。

つまり両者は対立するものではなく補完関係です。DNSSEC で「答えが本物であること」を、 DoH/DoT で「やり取りが覗かれないこと」を、それぞれ担保します。

DNSSEC はどう動きますか？

ゾーンが各レコードに署名（RRSIG）を付け、検証用の公開鍵を DNSKEY として公開します。さらに親ゾーン（レジストリ）に DS レコードを置き、親が子の鍵を保証する形で信頼の連鎖をルートまでつなぎます。リゾルバはルートから順に署名をたどって検証するため、どこか一段でも連鎖が切れると検証は成立しません。

仕組みの中心は 3 種類のレコードです。ゾーンは自分の各レコードに電子署名を付け、それをRRSIG レコードとして公開します。署名を検証するための公開鍵は DNSKEY として公開します。 そして親ゾーン（レジストリ）に DS レコードを置き、「この子ゾーンの鍵は正しい」と親が保証する形で、信頼を上位へつなぎます。

この「親が子の鍵を保証する」構造を、ルートゾーンまで積み上げたものが信頼の連鎖（chain of trust）です。 リゾルバは、あらかじめ知っているルートの鍵を起点に、TLD、そして目的のドメインへと一段ずつ下りながら、 各段の「親の DS」と「子の DNSKEY」を突き合わせて検証していきます。

ルートゾーン (.)
  └─ DS → TLD（com / jp など）の DNSKEY を保証
        └─ DS → example.com の DNSKEY を保証
              └─ RRSIG → example.com の各レコードに署名

リゾルバはルートから順に「親の DS」と「子の鍵」を突き合わせて
下りていく。どこか 1 段でも合わないと、その先は検証不能になる。

重要なのは、この連鎖は一箇所でも切れると成立しないということです。 子ゾーンがいくら正しく署名していても、親に DS レコードが登録されていなければ、 リゾルバは「その鍵を信頼してよい」という根拠を得られません。

DNSSEC はどう有効化しますか？

まず利用中の DNS ホストやレジストラが DNSSEC に対応していることを確認し、ゾーンの署名を有効化します。その後レジストラで DS レコードを登録し、親ゾーンと連鎖させて初めて検証が効くようになります。ゾーンに署名しただけで DS を登録しないと、リゾルバは連鎖を検証できず DNSSEC は機能しません。

有効化はおおむね次の順序で進みます。前段を飛ばすと後段が意味を持たないため、順番が大切です。

• 対応確認 — 利用中の DNS ホストとレジストラの両方が DNSSEC に対応しているかを確認する。片方でも非対応なら導入できない
• ゾーン署名の有効化 — 管理画面で DNSSEC を有効にすると、RRSIG と DNSKEY が生成・公開される
• DS レコードの登録 — 生成された DS（または DNSKEY）を、レジストラ側で親ゾーンに登録し、連鎖をつなぐ

最後の DS 登録が、初心者が最もつまずくところです。ゾーンに署名を付けただけでは、 リゾルバから見れば「署名はあるが、それを信頼してよい根拠が親に無い」状態にとどまります。 DS を親に登録して初めて、ルートからの連鎖が目的のドメインまで届き、検証が有効になります。 なお DNS ホストとレジストラが同じ事業者なら、この登録が自動化されていることもあります。

DNSSEC で名前解決が止まることはありますか？

あります。署名の期限切れや DS の設定ミスがあると、DNSSEC 対応のリゾルバはそのドメインを SERVFAIL として解決不能にします。失敗時は「怪しいので通さない」という厳格な挙動のため、設定を誤ると自サイトが広範囲で開けなくなります。自動再署名や鍵ロールオーバーといった継続的な運用が前提になる点に注意が必要です。

DNSSEC の検証はフェイルクローズ（失敗時は通さない）な設計です。 これはセキュリティ上は正しい態度ですが、運用の観点では諸刃の剣になります。 署名は有効期限を持つため、期限内に再署名し続けなければ切れます。 期限切れの署名、鍵の入れ替え（ロールオーバー）の失敗、DS と実際の鍵の不一致—— こうした事故が起きると、DNSSEC 対応のリゾルバはそのドメインをSERVFAIL として突き返し、 結果として名前解決そのものが不能になります。

しかも影響は自分のリゾルバだけにとどまりません。公開リゾルバの多くが検証を行っているため、 設定を誤ると広い範囲の利用者から一斉にサイトが開けなくなるおそれがあります。 「セキュリティを高めるはずの機能で、自らサイトを落とす」——これが DNSSEC 最大の運用リスクです。

DNSSEC が効いているかどう確認しますか？

対応リゾルバで名前解決できること、そして DS レコードと署名が正しく連鎖していることを確認します。dig コマンドに +dnssec を付ければ RRSIG が返るか、AD（Authenticated Data）フラグが立つかを見られます。オンラインの DNSSEC 検証ツールを使えば、鍵から DS までの連鎖のどこで問題が起きているかを視覚的に確認できます。

有効化した後は、連鎖が本当につながっているかを必ず確認します。 手元で確かめるなら dig が手軽です。+dnssec を付けて問い合わせると RRSIG が一緒に返り、 検証に成功したリゾルバ経由なら応答の flags に ad（Authenticated Data）が立ちます。

# 署名付きで問い合わせ、RRSIG が一緒に返るか見る
dig example.com A +dnssec

# 期待する応答:
#   ANSWER に A レコードと RRSIG が並ぶ
#   flags に ad（Authenticated Data）が立っている
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, ...

# 親に DS レコードが登録されているかを確認
dig example.com DS +short

より確実なのは、DNSSEC 検証ツールで連鎖全体を可視化することです。 ルートから TLD、目的のドメインまでの各段について、DS と鍵の突き合わせが成立しているかを一覧でき、どの段で連鎖が切れているかを切り分けられます。DS を登録した直後は親ゾーンへの反映に時間がかかることがあるため、 少し待ってから再確認するのが安全です。

DNS 周りの守りとしては、証明書の発行元を制限する HTTPS 化や、SPF・DMARC によるメールのなりすまし対策と合わせて考えると、 ドメイン全体の信頼性を底上げできます。DNSSEC は名前解決という一番土台の部分を守る、その中核の一つです。