Dev Study
← DNSを運用する側から見る
レッスン 6 / 8·約 9 分·第9期 DNSを運用する側から見る

DNSSECは何を保証しないか — 署名の連鎖と、機密性の不在

リクエストがアプリケーションに届くまで
  1. ブラウザURL入力
  2. DNS名前→IP今ここ
  3. ルータ経路選択
  4. ロードバランサ振り分け
  5. Nginx受け口
  6. アプリ処理
  7. DB保存

前回は偽の応答が通ってしまう条件を見ました。今回はその応答に署名を付けて検証する仕組みです。弾けるものと弾けないものが、規格の側で分かれています。

まず結論

DNSSECが応答に付けるのは署名です。検証できるのは「このデータはその名前の権威が作ったもので、途中で書き換えられていない」という**出所と完全性**だけです。

中身は隠れません。RFC 4033 §4「Services Not Provided by DNS Security」が、機密性を与えないことを名指しで書いています。偽の応答は検証で弾ける一方、第三者に読まれることは変わりません。

? 読む前に予測

DNSSECを有効にしたゾーンへの問い合わせを経路上の第三者が見ています。何が読めるでしょうか。

当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。

抽象原理

署名が与えるのは「誰が作ったか」だけ

前回、偽の応答が本物として通る条件を見ました。受け取った側に、それが本物かを確かめる材料が無いことが根にあります。

DNSSEC はその材料を足します。RFC 4033 §3「Services Provided by DNS Security」は、与えるものをこう書きます。

The Domain Name System (DNS) security extensions provide origin authentication and integrity assurance services for DNS data, including mechanisms for authenticated denial of existence of DNS data.

出所の認証と、完全性の保証。 それに「存在しないことの認証された証明」です。そのために4つのレコード型(RRSIG・DNSKEY・DS・NSEC)と2つのヘッダビット(CD と AD)が足されます。

裏返すと、ここに無いものは与えられません。同じ RFC の §4 は、与えないものを名指しします。

具体実物

親から子へ、2本の出力で連結点が見える

実物で見ます。まず jp の鍵です。

$ dig +dnssec +noall +answer jp DNSKEY(macOS、DiG 9.10.6、2026-09-17 取得。鍵の本体は省略)コマンド出力
jp.			27668	IN	DNSKEY	256 3 8 AwEAAZJ0BegKKLC8eGzqbqXTu0RBWX28ss7Y (略)
jp.			27668	IN	DNSKEY	257 3 8 AwEAAcuIsYAw2o8hVO+bvsQxrhx8f2wJogMi (略)
jp.			27668	IN	DNSKEY	256 3 8 AwEAAcOk3/LC5YQWPqID3mwm05nhBQjMtiqv (略)
jp.			27668	IN	RRSIG	DNSKEY 8 1 86400 20261104184500 20260904184500 33631 jp. HJiYbJr4AB5I (略)

鍵が3本と、それを覆う署名(RRSIG)が1本。署名の行の 33631 が、この署名を作った鍵のキータグです。

次に、親の側が持つものです。

$ dig +noall +answer jp DS(同環境・同日)コマンド出力
jp.			27668	IN	DS	33631 8 2 B54097461F9DBC3D9D87E74552C76314B421D178A18D8CB74DD2D97F 34FBADBE

33631 が一致しています。 DS は親ゾーン側に置かれ、中身は子の DNSKEY のハッシュです。「親が指した鍵で子の鍵の束が署名されている」という連結が、2本の出力を並べるだけで見えます。

RFC 4033 §2 は、この連なりをこう定義します。

Authentication Chain: An alternating sequence of DNS public key (DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of signed data, with each link in the chain vouching for the next.

DNSKEY と DS が交互に並ぶ連鎖で、各環が次の環を保証する。上の2本は、その環が噛み合うところの実物です。値は取得時点のものです。

✓ ここまでの確認

`jp DS` に出てくるキータグ 33631 は、何を指していますか。

抽象原理

257 と 256、そして起点の呼び方

先の出力に 257 が1本、256 が2本ありました。これを「257 が KSK、256 が ZSK」と読む説明をよく見ます。語そのものは規格にあります。 ただし定義文の後半が、そのまま注意書きです。

Designating an authentication key as a key signing key is purely an operational issue: DNSSEC validation does not distinguish between key signing keys and other DNSSEC authentication keys, and it is possible to use a single key as both a key signing key and a zone signing key.

純粋に運用上の指定であって、検証は区別しない。RFC 4034 §2.1.1「The Flags Field」も、bit 15 についてこう規定します。

This flag is only intended to be a hint to zone signing or debugging software as to the intended use of this DNSKEY record; validators MUST NOT alter their behavior during the signature validation process in any way based on the setting of this bit.

検証側はこのビットで挙動を変えてはならない(MUST NOT)。数は bit 7 だけなら 256、bit 15 が加わって 257 です。「奇数なら KSK」と書くのは RFC 6781(Informational)で、しかも Given the assumption that for KSKs the SEP flag is set という条件付きです。

同じ注意が起点の呼び方にも及びます。「連鎖はルートの KSK から」と説明されますが、RFC 4033 §2 が起点として定義するのはトラストアンカーです。

Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A validating security-aware resolver uses this public key or hash as a starting point for building the authentication chain to a signed DNS response.

同 RFC は If the configured trust anchor is a zone signing key... と、アンカーが ZSK である場合まで書いています。実運用では通じる言い方ですが、規格の言葉ではありません。

具体実物

無いことの証明も、中身は隠さない

存在しない名前を署名付きで引きます。

$ dig +dnssec +noall +authority nonexistent-test-xyz.jp(同環境・同日。署名の本体と一部の行は省略)コマンド出力
jp.			900	IN	SOA	z.dns.jp. root.dns.jp. 1789651802 3600 900 1814400 900
jp.			900	IN	RRSIG	SOA 8 1 86400 20261012174503 20260912174503 31878 jp. exk99NYgmuPZ (略)
B9CCVLLHT15JM5HET57BQ8MLBAAKPI82.jp. 900 IN NSEC3 1 1 0 - B9GCLVHJOFB3318PIQ42MAJLDH459SFM  NS SOA RRSIG DNSKEY NSEC3PARAM
QOR26J0ENC7C3SRM0JVTSU9R30S6E6IT.jp. 900 IN NSEC3 1 1 0 - QP08PKCTPEMQKT8A3M15D0DPBL5E4VJE  NS DS RRSIG
 (これに加えて、各 NSEC3 を覆う RRSIG が並ぶ)

読みどころは所有者名です。読める名前ではなくハッシュ値になっています。RFC 5155 の Abstract はこう書きます。

This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones.

measures against(対策) であって、prevents(防ぐ)ではありません。同じ RFC はハッシュを総当たりする道が残ることにも触れ、元の NSEC を辿るより費用が高くつくとしています。

肝心なのは、この応答自体が平文で流れていることです。署名は増えましたが、引いた名前も返った内容も、第三者からは読めます。

✓ ここまでの確認

「DNSKEY のフラグが 257 なら KSK、256 なら ZSK。検証する側はこれを見て処理を分ける」——この説明はどこが不正確ですか。

⇄ 2つを見比べる
具体例 A

DNSSEC の認証チェーン

検証するリゾルバは、設定されたトラストアンカーから出発し、DNSKEY と DS が交互に並ぶ連鎖を辿ります。親が子の DS を持つ構造上、順路は委任の木に重なります。

起点と、辿る順路表
起点        設定された DNSKEY または DS ハッシュ
順路        委任の木に沿って親から子へ1段ずつ
連結点      親の DS のキータグ = 子の署名者キータグ
具体例 B

証明書のチェーン(第34週)

第34週『証明書は誰が更新するのか — ACMEと期限』で見たとおり、有効期間の上限を決めるのは CA/Browser Forum で、実際の期間は各CAの方針でした。辿る順路も、その名前がどのCAから発行を受けたかで変わります。

起点と、辿る順路(第34週より)表
起点        検証する側が手元に持つ証明書の集合
順路        発行元をたどって起点の1つに合流する
上限を決める CA/Browser Forum の Baseline Requirements

どちらも、手元の起点から署名の連なりを辿って出所を確かめます。起点の決まり方の違いは、何を変えているでしょうか。

「ある名前を検証するとき、辿る順路がどう定まるか」を両方で考えてみてください。順路が違えば、誰の運用を信じたことになるかも違います。

抽象原理

連鎖を1枚の図にする

トラストアンカーから、jp の応答の署名まで
トラストアンカー設定された DNSKEY または DS ハッシュ
DNS の外側で得る
アンカーが指す
ルートの DNSKEYアンカーと突き合わせる
ルートの鍵で検証
jp の DS(親が持つ)子の DNSKEY のハッシュ。キータグ 33631
DS のハッシュと照合
jp の DNSKEY(子が持つ)ハッシュが一致する鍵
認証済みの鍵で検証
応答に付いた RRSIG署名者キータグでどの鍵かが分かる
  • ・鎖の各環が次の環を保証する(RFC 4033 §2 の Authentication Chain)
  • ・起点だけは署名で証明されず、設定として与えられる
  • ・出所と完全性の経路であり、「隠す」段はどこにも無い

連鎖が長くなっても、確かめるのは一貫して誰が作ったかです。

この章のまとめ

  • DNSSEC が与えるのは 出所の認証と完全性、そして存在しないことの認証された証明(RFC 4033 §3)。
  • 与えないものは §4 が名指しする。機密性・問い合わせ元の区別・DoS への保護。設定不足ではなく設計目標の外。
  • 連鎖は DNSKEY と DS が交互に並ぶ。親の DS のキータグと子の署名者キータグが一致する点が連結点で、dig 2本で見える。
  • KSK / ZSK の語は RFC 4033 §2 にある。 ただし定義文自身が「純粋に運用上の指定」と述べ、RFC 4034 は検証側がこのビットで挙動を変えることを禁じる。
  • 起点は トラストアンカー。「ルートの KSK から」は実運用の言い方で、規格の記述ではない。
  • NSEC3 の所有者名はハッシュ値。RFC 5155 の語は measures against zone enumeration で、防ぐとは書かれていない。
  • DNSSEC と DoT/DoH は 独立で完全に両立する(RFC 7858 §8)。片方はもう片方の代わりにならない。

語彙の網羅は、既存のクイズ群「DNS(名前解決)」の DNS V(セキュリティ) に譲ります。

自分の現場で確かめる

読んだだけでは身につきません。手元の環境で実際に見てみてください。

環境:

理解度チェック

読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。

問題 1 / 4正解: 0

RFC 4033 §4 が「DNSSEC は提供しない」と挙げているものの組み合わせはどれですか。

用語集(5語)
認証チェーン (authentication chain)
RFC 4033 §2 の定義では、DNSKEY の RRset と DS の RRset が交互に並ぶ、署名されたデータの連鎖。鎖の各環が次の環を保証する。
トラストアンカー (trust anchor)
RFC 4033 §2 の定義では「設定された DNSKEY RR、または DNSKEY RR の DS RR ハッシュ」。初期値は DNS プロトコルの外側の手段で得ることになる。
DS (Delegation Signer)
親ゾーン側に置かれ、子ゾーンの DNSKEY のハッシュを持つレコード。RFC 4033 §3 が挙げる4つの追加レコード型の1つ。
KSK / ZSK
RFC 4033 §2 に定義がある語。ただし定義文自身が「KSK への指定は純粋に運用上の問題であり、検証は KSK と他の鍵を区別しない」と述べる。DNSKEY のフラグ欄は bit 7 のみなら 256、SEP(bit 15)が加わると 257。
NSEC3
RFC 5155 が定める、存在しないことの証明を与えるレコード。所有者名がハッシュ化され、Abstract は measures against zone enumeration と述べる。防ぐとは書かれていない。

出典(一次ソース)