要約

  • DNS は ASCII 文字の大小を区別せずに名前を比較する一方、応答の Question セクションでは問い合わせ時の表記がそのまま返ることが多かった。DNS-0x20 は、その完全な反復を一時的なトランザクション識別に使う提案だった。
  • 増えるのは対象文字一つにつき最大一ビットで、経路上の正規化、圧縮とキャッシュ、フォールバックが効力を左右した。これは認証ではなく、2008年に失効した Internet-Draft であって最終 RFC ではない。

検索するときは同じ、受け取るときは同じであってはならない

リゾルバーが問い合わせ名の各文字をランダムに大文字または小文字へ変えたとする。権威サーバーは、その並びに意味を与えず、すべて小文字で送られた場合と同じ RRset を探す。ところが応答を受けるリゾルバーは、名前の意味が等しいだけでは足りないと考える。自分が送った大小の並びまで完全に戻ったかを確認する。

ここには二つの比較がある。DNS 名前空間では大小を折り畳む。未完了問い合わせの表では、今回だけ作った表記を区別する。経路外の偽造者が問い合わせ名を知っていても、その瞬間に選ばれた表記まで知らなければ、もう一つ当てるものが増える。

DNS-0x20 は、大文字に新しい命名上の権利を与える案ではなかった。名前の意味から切り離されていた表現を、応答が戻るまでの短い状態として借りる案だった。

初期 DNS が残した二層構造

1987年の RFC 1035 は、公式プロトコル部分の文字列比較を大小非依存とした。ASCII の大文字・小文字だけが違う名前は同一である。同時に、入力された大小は可能な限り保存し、その損失を最小にするよう求めた。

これは矛盾ではなく、識別と表示の分業だった。利用者が大小を正確に覚えなければ到達できない名前空間では相互運用が壊れる。一方、保存できる表記まで消す必要はない。DNS は同一性を折り畳んだが、すべての転送表現を必ず小文字にするとは決めなかった。

RFC 4343 は、この規則が ASCII の A-Z と a-z に関するものだと明確にした。自然言語一般の大小変換でも IDNA の代用でもない。また、出力の表記保存は保証されない。大小だけが異なるデータは同じ格納位置を使い、名前圧縮ではメッセージ内の別位置にあるラベル表現が再利用されることもある。

つまり、0x20 が利用したのは規格で予約されたセキュリティ領域ではない。「識別には無関係だが、実装上はしばしば残る」という条件付きの隙間だった。

QNAME の中に問い合わせ固有の選択を置く

2008年3月の Internet-Draft Use of Bit 0x20 in DNS Labels は、QNAME 内の各 ASCII 文字について、大小を分ける 0x20 ビットをランダム化する方法を示した。応答側はどの組み合わせも同じ名前として扱う。要求側は問い合わせが生きている間だけ、それぞれを別の値として記憶する。

前提は Question セクションの正確なコピーだった。草案の著者は、当時試験した主要な権威実装が要求の Question をビット単位で応答へ写したと報告した。しかし、その動作を当時の DNS 仕様が義務づけていたわけではない。実際、すべて小文字へ揃える少数の実装も観測された。

RFC 5452 が示す応答照合は、16ビット ID だけではない。問い合わせ名、アドレス、ポート、クラス、タイプも一致しなければならない。十分にランダムな 16ビット ID でも平均 32768 回の推測という有限の標的であり、送信元ポートの予測不能性は探索空間を広げる。大小パターンは QNAME の既存バイトを使い、さらに同時に当てる選択を足そうとした。

ただし、追加されるのは推測コストである。署名も共有秘密も生まれない。すべてを偶然当てた偽応答は依然として受理され得るため、データの由来を証明する仕組みとは呼べない。

ビット数は設定ではなく名前が決めた

対象になる ASCII 文字一つが持てる選択は最大一ビットである。数字やハイフンには大小がなく、その分は増えない。文字の多い長い名前は組み合わせが増え、短い名前や数字の多い名前は少ない。草案自身も、名前によって六ビットと十二ビットの差が出る例を挙げた。

したがって、「0x20 有効」という一つのフラグは防御強度を表さない。問い合わせごとに対象文字数を数え、選択が予測不能か、何ビットが応答まで残ったかを見る必要がある。

国際化ラベルに言語固有の大文字・小文字規則を足してビット数を増やすこともできない。RFC 4343 は ASCII 比較と IDNA を分けている。別の変換を線上の名前へ適用すれば、同じ名前の表現を変えるのではなく、処理対象そのものを変える恐れがある。

正しい中継装置がチャレンジだけを壊す

問い合わせをすべて小文字にするフォワーダーを考える。名前の検索結果は正しく、利用者は目的の RRset を受け取れる。基礎的な DNS 意味論では問題がない。しかし 0x20 検査では、リゾルバーが置いた状態は途中で失われている。

この食い違いにより、実装慣行が経路全体の依存条件となる。パターンを作るのはリゾルバーだが、保存の可否は権威サーバー、フォワーダー、検査装置に分散している。2008年の製品試験は、その後のすべての経路に約束を課す証拠ではない。

不一致の原因も一つではない。偽造、固定的な小文字化、特定経路だけの変換、ソフトウェア障害のいずれもあり得る。草案は記録を残し、該当応答を捨て、別の権威アドレスを試すよう述べた。文字一つの変化だけで攻撃を断定する設計ではなかった。

一時表現をキャッシュへ持ち込まない

DNS の名前圧縮では、Answer、Authority、Additional の名前が Question 内のバイトを指すことがある。ランダムな大小を残したまま他セクションを展開すれば、その表記がポインター経由でキャッシュへ入り、後続の応答にまで現れ得る。

そのため草案は、元の質問名を別に記憶し、受信パターンを検査した後、他セクションを展開する前に Question を元へ戻すよう求めた。チャレンジは未完了トランザクションの属性であり、RRset や名前の恒久的属性ではない。

この順序は、ランダム化より重要な設計境界を示す。表現上の余白を nonce として使うなら、それを捨てる地点まで規定しなければならない。生成だけを実装して共有状態へ流せば、防御が通常の表示を汚染する。

フォールバックは可用性設定ではなく降格面だった

厳格に不一致を拒否すると、小文字化する権威サーバーに届かなくなる恐れがある。最初の不一致で検査を止めれば到達性は守れるが、攻撃者が不一致を作って弱いモードへ落とす余地が生まれる。

草案は、まず他の権威サーバーを試し、それでもすべて失敗するなら、新しい ID と他のランダム要素で系列全体を繰り返す方法を提案した。サーバー順も変え、他の要素は何度も正しく戻るのに大小だけが一貫して変わるなら、互換性問題と判断する根拠が強くなる。

これは無料ではない。遅延と問い合わせ数が増え、小文字化するサーバーには数倍の負荷がかかり得る。乱数生成器の出力も多く外へ現れる。防御の実体はビットそのものではなく、再試行・記憶・例外の方針にあった。

DNSSEC は同じ差を消して認証する

RFC 4034 の DNSSEC 正規形は、圧縮を展開し、関係する ASCII 大文字を小文字へ変換する。署名者と検証者が同じオクテット列を作るため、偶然の表記差を署名対象から除く。

0x20 は一回の往復でランダムな差を保ちたい。DNSSEC は RRset を認証するため、その差を消したい。前者の正確なエコーは推測が当たらなかった可能性を高めるだけであり、後者の有効な署名が持つ権限連鎖とは別物である。

失効した提案が残した問い

DNS-0x20 文書は2008年9月に失効した。最終 RFC でも、現在の導入率を示す調査でもない。製品についての記述は草案著者がその時点で行った試験として扱う必要がある。

それでも歴史的価値は明確だ。プロトコルが同一性のために捨てた区別は、表現として残っていれば短期状態に転用できる。ただし、有効ビットを測り、経路依存を知り、不一致を攻撃と同一視せず、降格を制御し、永続化前に状態を除去できる場合に限られる。

大文字は名前の意味を変えなかった。一つの問い合わせについて、どの応答を受け入れるかだけを変えた。

出典と限界

本稿は RFC 1035、RFC 4343、RFC 5452、RFC 4034、および2008年3月の DNS-0x20 Internet-Draft に基づく。これらは現在の製品既定値、世界的な導入率、全経路の互換性を立証しない。