合同会社小村ソフト
第 5 章

DNSSEC と多層防御 — 何を守り、何が残るか

DNSSEC の守備範囲と last-hop の限界を押さえ、多層防御として組み立てる。

前章のおさらい: 第 4 章では、2008 年の教訓から短期 hardening（patch、entropy、recursion 制限、監視）の組み合わせを整理しました。本章ではさらに踏み込んで、DNSSEC が何を守り、何を守らないか、そして「最後の一区間（last hop）」に何が残るかを確認します。

DNSSEC は「署名で確かめる」仕組み

DNSSEC は DNS data に署名を付け、resolver がその署名を辿って検証できるようにする仕組みです。中心にあるのは origin authentication と integrity であって、通信内容そのものの秘匿ではありません。

parent DS
親ゾーンから子の DNSKEY を指し示すハッシュ / 参照。
child DNSKEY
そのゾーンで検証に使う公開鍵。
RRset + RRSIG
RRset 本体と、それに対する署名。

親の DS から子の DNSKEY へ、そこから RRset の RRSIG へと trust chain を辿ります。

提供するもの / 提供しないもの

提供するもの
data origin authentication、data integrity、authenticated denial of existence。
提供しないもの
query / response の秘匿、通信路の暗号化そのもの。

小問 5-1 — 何を守り、何を守らないか

『署名による検証』と『秘匿化』を分けます。

Q1. DNSSEC が提供するものにあてはまらないものはどれですか。

Q2. DNSSEC が原則として提供しないものはどれですか。

Q3. DS レコードの役割として最も近いものはどれですか。

secure / insecure / bogus を分ける

signed zone で検証が通れば secure です。親に DS がない unsigned / insecure な zone もあります。一方、親に DS があるのに child の鍵や署名が辿れないときは bogus と考える必要があります。

状態DS / 鍵 / 署名の状況意味
secureDS あり、DNSKEY / RRSIG の検証も通る署名検証が成立している
insecure親に DS がない（unsigned zone）DNSSEC の保証はないが、設計上の想定内
bogusDS はあるのに検証が通らない改ざんや設定不備の疑い、応答として使うべきでない

小問 5-2 — secure / insecure / bogus を分ける

DS の有無と、DNSKEY / RRSIG の検証結果で状態が決まります。

Q4. parent に DS があり、child の DNSKEY / RRSIG の検証が通らないとき、validating resolver はその zone をどう扱うのが最も近いですか。

last hop の問題

recursive resolver が validation していても、stub がその resolver や通信路を十分に信頼できるとは限りません。RFC 4033 は、security-aware stub resolver が DNSSEC の恩恵を実際に使うには、recursive server と channel の両方を信頼する必要があると説明しています。

したがって AD bit は役立つヒントですが、万能のエンドツーエンド証明ではありません。

last hop が信頼できない典型例
(1) 公共 Wi-Fi で、攻撃者が DHCP で偽の DNS サーバを配布する。(2) 不正な DHCP サーバが社内に紛れ込み、recursive resolver の IP を上書きする。(3) stub と recursive のあいだに中間者が割り込み、AD bit を勝手に立てた偽応答を返す。これらでは AD=1 を見ても、stub が見ている「validating resolver」がそもそも本物かが保証されません。

このような環境では、stub と recursive のあいだの通信路を別途保護する仕組み（DoT / DoH や IPsec 経由の信頼できる resolver の固定）と組み合わせて考える必要があります。

署名検証を実例で見る — dig +dnssec の出力

概念だけでは掴みにくいので、実際の dig 出力で確認します。signed zone（例: example.）に +dnssec を付けて問い合わせると、flags に ad が立ち、RRSIG レコードが ANSWER に並びます。

$ dig +dnssec example. SOA

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;example.                       IN      SOA

;; ANSWER SECTION:
example.                3600    IN      SOA     sns.dns.icann.org. noc.dns.icann.org. 2024010101 7200 3600 1209600 3600
example.                3600    IN      RRSIG   SOA 8 1 3600 20260601000000 20260501000000 12345 example. AbCdEf...（署名データ）

ここで注目するのは次の 2 点です。

flags に ad が立つ
validating recursive resolver が署名検証に成功し、AD bit を立てて返したことを示します。
ANSWER に RRSIG が並ぶ
RRset 本体に対応する署名レコードです。stub から見える RRset と RRSIG の組が、recursive 側で検証された結果として返ってきます。

逆に bogus（DS はあるのに検証が通らない）な状況では、status: SERVFAIL となり ANSWER が空になります。「検証に通らない応答は使うべきでない」を実装が体現している例です。

多層防御として組み立てる

DNSSEC だけでも、query matching や port entropy だけでも、単独では十分ではありません。入口（patch、recursion 制限）、一致条件（ID / port / question / bailiwick）、検証（DNSSEC）、運用（監視・ログ） を重ねて考えるのが現実的です。

patch / update
既知の脆弱性と query matching の欠陥を塞ぐ。
ID / port entropy
外から見える port 空間まで含めて広く保つ。
glue / bailiwick hardening
referral の additional を雑に受理しない。
recursion control
recursion は trusted な client にだけ提供する。
DNSSEC validation
可能なら validating resolver を運用する。
監視
random label の急増、検証 failure の連続などを拾う。

小問 5-3 — last hop と多層防御

AD bit と多層防御を、trust の境界を意識して読みます。

Q5. stub resolver から見た AD bit について最も適切な説明はどれですか。

Q6. modern resolver の守り方として最もバランスがよい説明はどれですか。

この章で持ち帰ること

  • DNSSEC は origin authentication / integrity / authenticated denial of existence を提供する
  • confidentiality は別問題で、DNSSEC だけでは得られない
  • AD bit と validating resolver の結果は、last hop の trust 問題と合わせて読む
  • 単独の仕組みに頼らず、patch・entropy・bailiwick・DNSSEC・監視を重ねる