受理条件とレース — ID / port / TTL / time window
応答受理条件と race window を、ID / source port / TTL の数字で捉える。
前章のおさらい: 第 2 章では、referral / glue / bailiwick を分け、Additional の追加データをどこまで信じてよいかを整理しました。本章ではその前提に立ち、resolver が「どんな条件で応答を受理するか」、そして条件をすり抜けるための race window と entropy の関係を数字で捉えます。
受理条件は 1 個ではない
resolver は、返ってきた packet が「いま待っている query に対する応答か」を複数の属性で照合します。ID だけ見ているわけではありません。question、source / destination address、source / destination port まで含めて初めて「同じ transaction」とみなします。
小問 3-1 — 何を照合するのか
「transaction ID 16 bit だから弱い」という説明だけで止めると、port や address の意味を見落とします。RFC 5452 は「DNS 応答の偽造に対する耐性を高めるための対策をまとめた RFC」で、応答受理時に何を照合すべきかを定義しています。
Q1. RFC 5452 の説明に沿って、再帰リゾルバが応答受理時に照合する属性としてあてはまらないものはどれですか。
DNS は HTTP のヘッダを受理判定に使いません。
RFC 5452 は、question section、transaction ID、送信元 / 宛先アドレス、送信元 / 宛先ポートの照合を求めています。HTTP Host header は HTTP レイヤの値で、DNS 応答の受理条件には含まれません。
Q2. transaction ID が 16 bit だけなら、候補は何通りですか。
2 の 16 乗です。
16 bit の transaction ID は 65,536 通りです。これだけでは off-path の guessing に対して十分な広さとは言いにくいため、source port など他の一致条件も重要になります。
race window は短いが、ゼロではない
off-path の forged response が意味を持つのは、本物の authoritative response がまだ到着していない短い時間窓です。実際の network 条件は多様ですが、概念としては「待ち時間のあいだに先に合うものが来ると危険」と捉えるのがよいです。
| タイムライン上の点 | 意味 |
|---|---|
| query 発行 | resolver が outstanding query を抱え始める |
| forged response 群 | 到着した偽応答。受理条件に合えば cache に入り得る |
| authoritative response | 本物の応答が届くと、以降の偽応答は受理されない |
小問 3-2 — race window と entropy
off-path の forged response が意味を持つのは、本物の authoritative response がまだ到着していない短い時間窓です。
Q3. off-path の forged response が勝つには、どの時間帯が特に重要ですか。
本物の応答がまだ届いていない「待ち時間」を意識します。
重要なのは、query が outstanding なあいだ、つまり本物の authoritative response が届く前の短い race window です。この時間窓に先に一致条件を満たす偽応答が入ると危険になります。
簡易モデルで見る race と entropy
RFC 5452 の考え方を説明用に単純化した概念モデルを頭の中で組み立てます。実装差や network 条件は無視し、「一致させる空間が広いほど当てにくい」「試行回数が多いほど危険が上がる」を直感的に理解します。
| 入力 | 役割 |
|---|---|
| transaction ID bits | 最大 16 bit の照合空間を提供 |
| source port bits | 高エフェメラルポート帯で最大 16 bit 弱の追加空間 |
| 追加 entropy（例: 0x20） | ラベルの大文字小文字変化などで数 bit 上乗せ |
| 1 window あたりの forged packets | 攻撃側が race window に投げ込める数 |
| identical outstanding queries | 同一問いを並行で保持する本数 |
| attempts | fresh miss を起こして race を繰り返す回数 |
0x20 エンコーディングとは: DNS の名前解決は本来 case-insensitive（大文字小文字を区別しない）です。たとえば www.example.com と WwW.ExAmPlE.cOm は同じ名前として扱われます。この性質を逆手に取り、resolver が問い合わせ時にラベルの各文字をランダムに大文字小文字混在で送り、応答でも同じ並びが返ってくるかを検証することで、ラベルの文字数ぶんの bit を追加 entropy として使えます。これを 0x20 エンコーディング（大文字／小文字の ASCII 差が 0x20 であることに由来）と呼びます。
1 回の成功確率が小さくても、attempts が増えるほど累積成功確率は上がる、という関係を覚えておきます。
port entropy と NAT
source port randomization は有効な hardening ですが、外から見える port 空間が狭ければ効果は目減りします。NAT や middlebox が sequential / small-range の port へ書き換える場合、この点に注意が必要です。
小問 3-3 — port entropy と NAT
source port randomization は有効な hardening ですが、外から見える port 空間が狭ければ効果は目減りします。
Q4. 送信元ポートを問い合わせごとにランダム化する主な効果はどれですか。
ID に加えて、何を当てなければいけなくなるかを考えます。
source port randomization は、transaction ID 以外にも一致させるべき空間を増やし、forged response の当て推量を難しくします。DNSSEC とは別の hardening です。
Q5. recursive resolver の外向き UDP source port を NAT が小さな連番範囲へ書き換えると、何が起こりやすいですか。
本当に外へ出ていく port の多様さが保たれるかが重要です。
NAT が外向き source port を小さな予測しやすい範囲へ丸めると、実効的な entropy が減ります。内部で random でも、外から見える port 空間が狭ければ hardening 効果は落ちやすくなります。
復習コラム — TTL の残り秒数を秒で追う
本章の主題（受理条件・entropy・race window）からはやや外れますが、第 1 章で扱った TTL の数え方を改めて確認しておきます。残り秒数を即答できる感覚は、第 6 章の運用観察で stale なのか異常なのかを切り分けるときに繰り返し使います。
復習コラム — TTL の残り秒数を秒で追う
race / entropy の本筋からはやや外れますが、第 1 章で扱った TTL の数え方を改めて確認します。残り秒数を即答できる感覚は、第 6 章の運用観察でも繰り返し使います。
Q6. ある誤答が 13:00:00 に TTL 240 秒でキャッシュされました。13:02:30 の残り TTL は何秒ですか。
2 分 30 秒は 150 秒です。
TTL 240 秒から経過 150 秒を引くので、残り TTL は 90 秒です。運用では「いま見えている値があと何秒残るか」を秒数で追えると、stale なのか異常なのかを整理しやすくなります。
第 3 章のまとめ
- DNS 応答受理は ID だけでなく、question / address / port を含む
- 重要なのは authoritative response より前の短い race window
- source port randomization は有効だが、NAT が entropy を潰すことがある