「DNSSECって、有効にしないとまずいんですか？」
「ブラウザーのDoHって、社内で使わせて大丈夫なんでしょうか」
DNSは、ほぼすべての通信の入口にあるので、攻撃者にとっても魅力的な標的です。一方で、DNSの事故の多くは、実は高度な攻撃ではなく、消し忘れたレコードや更新忘れのドメインといった運用の隙から起きています。
第8回では、DNSを調べるコマンドを見ました。第9回では、DNSを狙う攻撃と、その守り方を整理します。第8回で見たSERVFAILの原因にもなるDNSSECも、ここで詳しく扱います。
脅威の全体像
まずは、DNSに関わる脅威を一覧にします。
| 脅威 | 狙われる所 | 起きること | 主な対策 |
|---|---|---|---|
| キャッシュポイズニング | キャッシュDNS | 偽の応答が記憶され、偽のサイトへ誘導される | ポートのランダム化、DNSSECの検証 |
| 盗聴・改ざん | 端末〜キャッシュDNSの間 | 閲覧先が漏れる、応答が書き換えられる | DoT／DoH／DoQ |
| リフレクション攻撃 | オープンリゾルバー、権威DNS | 第三者へ大量の応答が送り付けられる | 再帰の制限、RRL |
| ランダムサブドメイン攻撃 | 権威DNS、キャッシュDNS | 存在しない名前の大量の問い合わせで過負荷 | 問い合わせ数の制限、監視 |
| DNSトンネリング | 社内のキャッシュDNS | 問い合わせに載せたデータの持ち出し | ログ監視、DNSファイアウォール |
| サブドメインテイクオーバー | 自社ゾーンのCNAME等 | 他人が自社の名前でサイトを公開する | 不要なレコードの削除、棚卸し |
| ドメインの失効・乗っ取り | レジストラ、NS | ドメインごと他人の管理下に入る | 自動更新、レジストラロック、MFA |
| 悪性ドメインへのアクセス | 利用者の端末 | マルウェア感染、フィッシング | 保護的DNS、RPZ |
上の3つはDNSの仕組みそのものへの攻撃、下の5つは運用の隙やDNSの悪用です。後者は設定と棚卸しで防げるものが多く、日々の運用の範囲です。
キャッシュポイズニングとカミンスキー攻撃
キャッシュポイズニングは、キャッシュDNSサーバーに偽の応答を覚えさせる攻撃です。
キャッシュDNSが権威DNSサーバーへ問い合わせてから本物の応答が届くまでの間に、攻撃者が権威DNSを装った偽の応答を送り付けます。それが先に受け入れられると、偽の情報がTTLの間キャッシュされ、利用者全員が偽のサイトへ誘導されます。受け入れられるには、問い合わせのID（16ビット）などが一致している必要があります。
以前は「すでにキャッシュされている名前は狙えない」ため、機会が限られていました。しかし2008年に公表されたカミンスキー攻撃は違いました。
- 存在しない名前を次々に問い合わせさせる（a001.example.jp、a002.example.jp…）ことで、何度でも試行できるようにした
- 偽の応答にNSレコードを含めて、ドメイン全体を乗っ取る
DNSの仕様上の弱点だったため、主要な製品が一斉に修正版を出す事態になりました。
キャッシュポイズニングへの対策
- ソースポートのランダム化：送信元ポートを毎回ランダムにし、ID（16ビット）とあわせて推測を難しくする。2008年の修正の中心で、現在の製品は標準で行う。ただし、途中のNATやF/Wがポートを連番に書き換えると効果が消える
- 0x20：問い合わせる名前の大文字・小文字をランダムに混ぜ（wWw.ExAmPle.jP）、応答が同じ並びかを確かめる。一部のリゾルバーが実装
- 無関係なレコードを受け入れない：問い合わせと関係の無いドメインの情報はキャッシュしない
- SAD DNS（2020年）への対処：OSのICMPの応答数の制限を手掛かりにポートを突き止める手法。OSとリゾルバーの修正で対処されており、OSも含めて更新を当てる
- DNS Cookies（RFC 7873）：なりすました応答を見分けやすくする（第4回）
ただし、以上はすべて推測を難しくする対策で、確率を下げるだけです。応答の中身が本物であることを確かめられるのは、DNSSECだけです。
DNSSECの仕組み
DNSSEC（DNSセキュリティ拡張）は、応答に電子署名を付け、改ざんされていないことを受け取った側が確かめる仕組みです。暗号化はしません。
| レコード | 置かれる場所 | 役割 |
|---|---|---|
| DNSKEY | 署名したゾーン | ゾーンの公開鍵。KSK（鍵署名鍵、フラグ 257）と ZSK（ゾーン署名鍵、256） |
| RRSIG | 署名したゾーン | 同じ名前・型のレコードの組（RRset）ごとの署名。有効期間を持つ |
| DS | 親のゾーン | 子の KSK のハッシュ値。親から子へ信頼を受け渡す |
| NSEC | 署名したゾーン | 「この名前・型は存在しない」ことの証明。次の名前を示す |
| NSEC3 | 署名したゾーン | NSEC の名前をハッシュ化し、ゾーン内の名前を列挙しにくくする |
| CDS／CDNSKEY | 子のゾーン | 親に登録してほしい DS を子の側で公開する |
署名は、データ → ZSK → KSK → 親のDSと上へつながっています。
www.example.jp. 300 IN RRSIG A 13 3 300 20261009000000 20260925000000 12345 example.jp. （署名）RRSIGは左から、対象の型、アルゴリズム、ラベル数、元のTTL、有効期限、署名開始、鍵タグ、署名者です。期限が切れると検証に失敗するため、署名の自動更新が欠かせません。
信頼の連鎖と検証
検証するリゾルバー（バリデーター）は、ルートゾーンのKSKを信頼アンカーとして最初から持っています。
ルートのDNSKEYをこのアンカーで確かめ、ルートが署名したjpのDS、それと一致するjpのDNSKEY……と親から子へたどり、最後にwww.example.jpのRRSIGを確かめます。これが信頼の連鎖です。
- 途中で署名の期限切れやDSと鍵の不一致があると、応答は「偽物の可能性がある」と判定される。それを返せばDNSSECの意味が無くなるため、リゾルバーは答えを返さずSERVFAILを返す
- 検証に成功すると応答にADビットが付き、クライアントがCDビットを付けると検証を止めた結果を受け取れる（第8回の
+cd） - 親にDSの無いゾーンは「署名されていない」と扱われ、通常どおり解決される
アルゴリズムと鍵の運用
| 項目 | 現在の推奨と動向 |
|---|---|
| アルゴリズム 13（ECDSA P-256） | 署名と検証の両方で実装必須。署名が小さく、新規に署名するときの第一候補 |
| アルゴリズム 15（Ed25519） | 推奨。署名は小さいが、検証側の対応状況を確かめてから使う |
| アルゴリズム 8（RSA/SHA-256） | 引き続き利用できる。ルートや多くのTLDが使用。応答は大きめ |
| アルゴリズム 5・7（RSA/SHA-1） | RFC 9905（2025年）で署名への使用を非推奨。SHA-1の検証をやめたOSもある |
| KSK と ZSK | KSKはDNSKEYの組を署名しDSで親とつながる。ZSKはゾーンのデータを署名する |
| 鍵の更新 | ZSKは親の手続き不要。KSKは親のDSの差し替えが必要で、事故が起きやすい |
| CDS／CDNSKEY | 子が公開した値を親が確かめてDSを自動で更新する（RFC 7344・8078。対応はレジストリー次第） |
| KeyTrap（2024年） | 細工した鍵と署名で検証の計算量を膨らませるDoS。各製品が修正済みで、更新を当てる |
いちばん事故が起きやすいのが、KSKの更新です。
- 新しいKSKをDNSKEYに追加する
- CDSを公開 → 親がDSを追加する（手作業も）
- 親のDSのTTLだけ待つ
- 古いKSKと古いDSを削除する
②を飛ばして④を行うと、親には旧DSしか無いのに子には新KSKしか無い状態になり、信頼の連鎖が切れて、検証するリゾルバーからドメイン全体がSERVFAILになります（第8回のEDE 9）。新旧の鍵とDSが重なる期間を必ず作るのが鉄則です。なお、アルゴリズムの推奨は、RFC 9904（2025年）からIANAの一覧で管理されるようになりました。
ルートKSKの更新（KSK-2024）
DNSSECの起点であるルートのKSKも、更新が進んでいます。
| 時期 | 内容 |
|---|---|
| 2024年4月 | 新しいKSK（KSK-2024、鍵タグ 38696）を生成 |
| 2025年1月 | KSK-2024をルートゾーンに公開。現行のKSK-2017（鍵タグ 20326）と並ぶ |
| 2026年10月11日 | ルートの署名をKSK-2024に切り替える |
| 2027年1〜3月（予定） | KSK-2017を失効させ、ルートゾーンから取り除く |
この記事を書いた2026年9月25日の時点では、ルートのDNSKEYに20326と38696の両方があり、署名は20326でした。切り替え後に38696を信頼していない検証リゾルバーは、すべての名前がSERVFAILになります。
自社の検証リゾルバーの信頼アンカーに38696があるかを確かめましょう。
- BIND：
rndc managed-keys status - Unbound：
root.keyのファイル - Knot Resolver：
root.keys - Windows ServerのDNS：
Get-DnsServerTrustAnchor -Name .
多くのリゾルバーはRFC 5011の手順で新しい鍵を自動で取り込みます（新しい鍵を30日間観測してから信頼）。ただし、鍵の保存先に書き込めない、長く止めていた仮想マシンやイメージから起動したという場合は、取り込めていないことがあります。自動更新を使わない機器は、IANAが公開する信頼アンカー（root-anchors）で手作業で更新します。今の状態はdig . DNSKEY +multi（PowerShellはResolve-DnsName . -Type DNSKEY）で確かめられます。
リフレクション攻撃とオープンリゾルバー
リフレクション攻撃は、送信元のIPアドレスを攻撃対象に偽った小さな問い合わせをDNSサーバーへ大量に送り、その応答を攻撃対象へ送り付けるDDoS攻撃です。
応答は問い合わせよりずっと大きいため、攻撃の量が数十倍に増幅されます。攻撃者の回線は細くても、増幅率×踏み台の数で被害者があふれます。
- 踏み台になりやすいのが、誰からの再帰問い合わせでも受け付けるオープンリゾルバー。キャッシュDNSは再帰に応じる相手を社内に限り、クラウドでもセキュリティグループで送信元を絞る
- 権威DNSは誰からの問い合わせにも答える必要があるため、同じ応答を短時間に繰り返し返さないようにするRRL（応答レート制限）を使う
- 何でも返すANYの問い合わせは増幅に悪用されたため、RFC 8482（2019年）で最小限の応答で済ませてよいことになった。
dig ANYで全部のレコードは取れない
第7回で「権威とキャッシュを兼ねない」と書いた理由の1つが、ここにあります。
ランダムサブドメイン攻撃とDNSトンネリング
| ランダムサブドメイン攻撃（水責め攻撃） | DNSトンネリング | |
|---|---|---|
| 手口 | x7q2k.example.jp のような存在しない名前を大量に問い合わせる。キャッシュが効かず、すべて権威DNSまで届く | 送りたいデータを名前に埋め込んで問い合わせ、応答（TXT 等）で受け取る |
| 目的 | 権威DNSや途中のキャッシュDNSを過負荷にする | F/Wを迂回したデータの持ち出し、マルウェアの遠隔操作 |
| 兆候 | 特定ドメインへのNXDOMAINの急増、応答待ちの増加 | 長くランダムな名前、1つのドメインへの大量の問い合わせ、TXTの多用 |
| 対策 | リゾルバーの問い合わせ数の制限、権威DNSの増強・エニーキャスト | 問い合わせログの監視、DNSファイアウォール、外部への53番の直接通信を禁止 |
どちらも1件ずつは普通の問い合わせに紛れるため、問い合わせログを残し、平常時の量を知っておくことが検知の前提です。DNSSECで署名されたゾーンでは、NSECを使って存在しない名前をキャッシュから答える仕組み（RFC 8198）が負荷の軽減に役立ちます。
サブドメインテイクオーバー
ここからは「運用の隙」です。サブドメインテイクオーバーは、使わなくなったDNSのレコードが残っていたために、他人に自社のサブドメインを使われてしまう問題です。
典型例は次の流れです。
shop.example.jpをCNAMEでクラウドのサービスの名前（例：shop-prod.service.example）に向けていた- サービス側のリソースだけを削除し、CNAMEを残した
- 攻撃者がサービス上で同じ名前を取得すると、
shop.example.jpで偽のページを公開できる
自社のドメインで表示されるため、フィッシングやCookieの盗用に悪用され、証明書まで取られることがあります。解放したIPアドレスを指すAや、削除したゾーンへのNSも同じです。
対策は、リソースを消す前にDNSのレコードを消すという順序を守ることと、定期的にレコードの向き先を棚卸しすることです。DNSのレコードは、リソースを消しても自動では消えません。
ドメインの失効・乗っ取り
- 更新忘れによる失効：失効したドメインは第三者が取得でき、Web・メールの受信・過去のリンクがすべて他人のものになる。自動更新、請求先と通知先の複数化、期限の台帳管理で防ぐ
- NSに使っている他社ドメインの失効：
ns1.old-provider.exampleのようなNSのドメインが失効すると、それを取得した者がゾーンの応答を自由に決められる。使っていない委任や古いNSを放置しない - 委任先のDNSサービスの解約：NSが契約の終わったDNSサービスを指したままだと、他人がそのサービスで同じゾーンを作れることがある。2024年にもこの手口の大規模な悪用が報告されている
- レジストラのアカウントの乗っ取り：NSを書き換えられるとドメインごと奪われる。多要素認証（MFA）、担当者の限定、変更の通知を設定する
- レジストラロック・レジストリロック：移管やNSの変更を止めるロック。重要なドメインは、変更に人手の確認を挟むレジストリロックも検討する
状態の確認は、WhoisやRDAPで有効期限とロックの状態（clientTransferProhibited等）を見ます（第2回）。どの段を奪われても、ドメインごと他人の管理下に入ります。
DNSの暗号化（DoT・DoH・DoQ）
| 方式 | 規格 | 通信 | 特徴 |
|---|---|---|---|
| DoT（DNS over TLS） | RFC 7858（2016年） | TLS、TCP 853 | 専用のポートで区別しやすく、F/Wで制御しやすい |
| DoH（DNS over HTTPS） | RFC 8484（2018年） | HTTPS、TCP 443（HTTP/3 は UDP） | Webの通信に紛れる。ブラウザーが実装を先導した |
| DoQ（DNS over QUIC） | RFC 9250（2022年） | QUIC、UDP 853 | 接続が速く、再送の遅れの影響を受けにくい。対応は広がり中 |
| DDR（指定リゾルバーの発見） | RFC 9462（2023年） | _dns.resolver.arpa の SVCB | 設定済みのDNSサーバーが暗号化に対応しているかを自動で見つける |
暗号化で守られるのは主に端末とキャッシュDNSの間で、キャッシュDNSと権威DNSの間は多くが平文のままです。また、暗号化は盗聴と途中での改ざんを防ぎますが、権威DNSが出した内容そのものの正しさは確かめません。それはDNSSECの役割です。
冒頭の「DNSSECは必要？」への答えがここにあります。暗号化は通り道を、DNSSECは中身を守る。片方では足りない、補い合う関係です。
OS・ブラウザーの対応と社内DNSの迂回
| 対象 | 暗号化DNSへの対応 | 企業での制御 |
|---|---|---|
| Windows 11、Windows Server 2022 以降 | DNSクライアントがDoHに対応（既知のサーバー一覧に追加して使う） | グループポリシー「Configure DNS over HTTPS (DoH) name resolution」 |
| Windows Server 2025 の DNSサーバー | 2026年6月の更新（KB5094125）から、クライアントからのDoHを受け付けられる | 転送先への通信とゾーン転送は暗号化されない |
| macOS 11 以降 | 構成プロファイルでDoH・DoT。macOS 13以降はDDRにも対応 | MDM（端末管理）でプロファイルを配布 |
| Chrome・Edge | 「セキュアDNS」。OSのDNSサーバーがDoH対応なら自動で切り替える | ポリシー DnsOverHttpsMode（off／automatic／secure）。管理下の端末では未設定だとDoHを使わない |
| Firefox | 米国・カナダ等では既定でDoH | ポリシー DNSOverHTTPS、canary domain |
冒頭のもう1つの疑問です。ブラウザーが外部のDoHサーバーを直接使うと、社内DNSを迂回し、次のような問題が起きます。
- 社内の名前が引けない
- スプリットホライズンが効かない
- フィルターやログが素通りになる
DoHはWebと同じ443番なので、ポートで止めにくく、端末の設定で制御します。ポリシーで明示的に設定し、Firefox向けにはuse-application-dns.netにNXDOMAINを返します（既定でDoHが有効な場合のみ効きます）。
保護的DNS・RPZ・DNSファイアウォール
最後に、DNSを「守りの道具」として使う方法です。DNSはほぼすべての通信の最初に使われるため、悪性ドメインへの接続をここで止めることができます。
- 保護的DNS：マルウェアの配布元、フィッシングサイト、遠隔操作の指令サーバーとして知られるドメインへの問い合わせに、NXDOMAINやブロックページのIPアドレスを返すキャッシュDNSのサービス
- RPZ（応答ポリシーゾーン）：自社のキャッシュDNSで同じことを行う仕組み。ブロックする名前と動作をゾーンとして書き、ゾーン転送で配る。BINDやUnbound等が対応
- DNSファイアウォール：クラウドでの提供形態（Route 53 Resolver DNS Firewall、第10回）
名前を引く段階で止めるので、接続そのものが始まりません。問い合わせログは感染端末を見つける手掛かりにもなります。ただし、DoHや直接の通信は素通りするため、外部への53番・853番の通信の制限と組み合わせます。
考えてみよう
- 自社の検証するキャッシュDNSが、ルートKSKの更新に追従できているかを、どのコマンドで確かめますか。追従できていなかったら何が起きますか。
- 検証用のクラウド環境を削除することになりました。DNSの側で、削除の前後に何を確かめますか。
- 社内の端末で、ブラウザーのDoHが外部のサーバーを使っていることが分かりました。どんな問題が起き、どう制御しますか。
ヒント：この記事の「ルートKSKの更新」「サブドメインテイクオーバー」「社内DNSの迂回」が、それぞれの答えにつながります。
まとめ
- 推測を難しくする対策は確率を下げるだけ。中身が本物かを確かめられるのはDNSSECだけ
- DNSSECはルートのKSKから親→子へたどる。切れるとSERVFAIL
- KSKの更新は新旧の鍵とDSを重ねる。ルートKSKは2026年10月11日にKSK-2024へ
- キャッシュDNSは再帰を社内に限る。権威DNSはRRL
- 消し忘れたCNAMEと更新忘れのドメインは、それだけで乗っ取りの入口になる
- 暗号化は通り道、DNSSECは中身。ブラウザーのDoHはポリシーで制御
次回は、Route 53やAD統合DNS、Kubernetesなど、クラウドと社内環境でのDNSの使い方を扱います。
連載「DNS入門」全12回
- DNSとは？名前解決の全体像と3つの登場人物
- ドメイン名の階層と委任
- 名前解決の流れ
- DNSメッセージとトランスポート
- リソースレコード 前編
- リソースレコード 後編
- 権威DNSサーバーの運用
- コマンドで調べる
- DNSのセキュリティ（この記事）
- クラウド・社内環境のDNS
- DNSトラブルシュート
- DNS設計演習
コメント