要約

  • Ray Bellisが単独で執筆したRFC 5625は、単純なDNSプロキシが現在と将来の全機能を実装できないことを前提にする。未知のフラグ、ラベル、問い合わせ型、クラス、リソースレコードを通し、完全な応答、EDNS、TC、TCP、認証に関わるバイトを保全する一方、壊れた入力や明示的なポリシーは観測可能な形で扱う。
  • 文書は2009年にBCP 152となったが、現在の機器が従っていることを証明するものではない。透過転送もDNSSEC検証そのものではない。価値は権限の分離にある。意味は仕様と端点が所有し、プロキシは限定された転送状態、インターフェース、明示的なローカル判断だけを所有する。

新しい値が古い予約規則に止められる

あるDNSヘッダービットは、機器の出荷時には「ゼロでなければならない予約領域」だった。数年後、そのビットに正式な用途が割り当てられる。新しいクライアントも上流リゾルバーも用途を理解している。ところが、その間にあるゲートウェイだけが古い規則を守り、問い合わせを捨てる。

端点同士の互換性は成立している。それでも古いファームウェアが、プロトコル進化の事実上の承認者になってしまう。

2009年8月発行のRFC 5625は、DNS Proxy Implementation Guidelinesと題されたBest Current Practice 152である。著者は当時Nominet UKに所属していたRay Bellis。文書は、住宅用ルーターの計算資源が限られ、ファームウェアの更新周期が長く、将来のDNS拡張を事前に実装できないことを率直に認める。

そこで完全な理解を要求するのではなく、役割を薄くする。LANから受け取った問い合わせを既知の上流再帰リゾルバーへそのまま送り、応答全体を元のクライアントへそのまま返す。プロキシはクライアントとの対応付けや上流選択を行うが、経路上にいるという理由だけで意味を再定義しない。

2008年の24台が残した範囲付きの証拠

SAC035の要約と報告書全文には、2008年7月と8月に行われた24台の住宅用ルーターまたは小規模オフィス向けファイアウォールの制御試験が記録されている。

24台すべてが、DNSSEC問い合わせを上流へ直接ルーティングできた。22台はDNSプロキシ機能も持ち、そのうち6台がDNSSEC関連フラグまたは検証済み応答で問題を示した。18台はUDP応答を512バイトまたはMTUに関係するサイズに制限し、4096バイトまで返せたのは4台、TCPでDNSを中継できたのは1台だけだった。標準設定で完全に互換だったのは6台で、さらに9台は設定変更によってプロキシの非互換性を回避できた。

これは現在の市場比率ではない。試験は2008年、対象は24台であり、製品も運用環境も変わった。数字が証明するのは当時の標本で起きた挙動に限られる。ただし、端点が対応済みでも、古い中間装置が機能を消せるという構造は残る。

IETFの承認記録は、DNS Extensionsワーキンググループに強い合意があり、ベンダーと購入者に関心があったと述べる。これは標準化過程の証拠であって、実装率や調達後の遵守率ではない。

「知らない」と「壊れている」を分ける

RFC 5625の中心は、未知の値を不正な値と同一視しないことにある。プロキシが理解しないDNSヘッダーフラグは、自分の処理では無視しながら、パケット自体は転送する。ラベルの表現、QTYPE、QCLASS、リソースレコードのTYPEとCLASSについても、未知であることを拒否理由にしない。

現在のレジストリーだけを埋め込んだパーサーに、将来の割り当てを判断させてはならない。RFC 3597は未知のリソースレコード型について、RDATAを非構造のバイナリとして扱い、変更せず保存・転送する原則を示す。理解したふりをせず、理解できる構成要素まで情報を残す方式である。

一方、無効な圧縮ポインターや内容と両立しないセクション数は、未知の拡張ではなく、メッセージ自体が不正である。RFC 5625は破棄を認める。それでも安全なら、無言で捨てるよりSERVFAILを返すことを勧める。クライアントは無駄な再送を止められ、運用者は拒否地点を推定できる。

明示されたセキュリティまたはネットワークポリシーも例外になり得る。ただし、意図した制御はポリシーとして帰属可能でなければならない。不完全なパーサーが偶然落とした結果を、方針や仕様適合と呼び替えることはできない。

応答の大きさと運び方も意味を持つ

UDP応答を512バイトで切りながらTCを立てないプロキシは、単に末尾を失うだけではない。不完全な応答を完全だと見せる。上流が付けたTCを消せば、TCPで再試行するための合図まで失わせる。

RFC 5625は、512バイトを超えたという理由だけで切り詰めるべきではないとする。ローカル制約で切るならTCを設定し、上流から来たTCは削除しない。明示された制約は回復できるが、成功に見せかけた制約は誤った確信を生む。

TCPも転送契約の一部である。プロキシはDNS over TCPを受信し、上流へ転送できなければならない。クライアントがTCPを選んだなら、上流側もTCPを使い、いったんUDPに戻して切り詰めを誘発しない。Bellisを含む5人が後に執筆したRFC 7766は、DNS実装にTCP対応を要求した。標準上の継続性は示すが、全ゲートウェイの遵守を示すものではない。

EDNSのOPTレコードは拡張を運ぶ。RFC 5625はOPTがあるだけで拒否してはならないとする。RFC 6891はさらに、適合するミドルボックスがUDPを512バイトに制限してはならず、単純なフォワーダーが双方向のOPT内容を変更・削除してはならないと定める。2009年文書の4096バイト推奨は当時の実装目標で、永続的な上限ではない。

透過的でも、運用責任は消えない

薄いプロキシにも状態がある。問い合わせをクライアントに対応付け、保持時間を決め、上流を選び、送信時のQuery IDを変えることがある。どのインターフェースで受け付け、DHCPで何を通知するかも決める。

RFC 5625は、偽造応答への耐性についてRFC 5452を参照し、Query IDと送信元ポートのランダム化を勧める。これは攻撃面を減らすが、応答を認証せず、DNSSECの代わりにもならない。

TSIGで保護されたメッセージは、許容されたQuery IDの扱いを除き、DNS内容を変えると検証に失敗する。プロキシはそのまま保全するか、認証規則を完全に実装する必要がある。部分的な書き換えは便利機能ではなく、検出可能な破損である。

インターフェースの境界も重要だ。LAN向けのプロキシは、標準でWAN側から到達可能にすべきではない。外部に開けば反射攻撃の経路になり得る。RFC 5358は、オープンな再帰サーバーが反射に使われる背景を示す。正当な内部利用者への透過性と、インターネットへの公開は別の判断である。

さらに、明示的なポリシーが禁じない限り、利用者が指定した上流リゾルバーへ直接問い合わせる経路を残すべきだ。あらゆる代替経路を強制的に捕捉すれば、便利な代理は回避不能な意味の関門に変わる。

Bellisが設計した「未知の値」の受入試験

IETF DatatrackerのRay Bellisのページには、RFC 5625を含む10件のRFCが載る。ISCのチームページは現在、BellisをDirector of DNS Operationsとして紹介する。文書が機能数より障害の見え方を重視するのは、運用に根ざした視点と読める。

受入試験は既知の一覧だけで作れない。未知のフラグは通るか、未知のレコード型は同じバイトで戻るか、TCとOPTは残るか、TCPは上流まで続くか。ポリシーによる拒否と実装の無知を別々の証拠として観測できるか。

Mark AndrewsとBellisによる後のRFC 8906は、想定外のフィールド、型、EDNSのバージョン、オプション、フラグ、切り詰め、TCPを明示的な試験項目にした。沈黙しか得られなかった問題を、比較可能な結果に変える。

透過転送だけでDNSSEC検証、プライバシー、可用性が得られるわけではない。RFC 5625は上流選択や明示的なポリシーも否定しない。守ろうとする境界はもっと限定的だ。中間にいる実装が、自分の知らないものを禁止する権限まで持たないようにする。プロキシは経路を預かる。意味そのものは預かっていない。

出典