要約

  • DNSOPのGREASE草案第03版は、未割り当て値をDNSの拡張点で継続的に使い、実装やミドルボックスが現在の値だけを許す状態に固まるのを防ごうとしている。現時点では作業中のInternet-Draftであり、RFCでも導入命令でもない。
  • GREASE失敗後の順次再試行は遅延を増やし、通常問い合わせとの並行送信は遅延を守る代わりに権威側の負荷を増やす。応答側から始める場合、下流で起きた失敗を応答者が観測できないこともある。
  • 既定化の前に、対象拡張点、値の選択法、通信量、除外対象、遅延と追加問い合わせの上限、テレメトリー、指紋対策、終了日、停止条件、復旧責任者を結ぶ期限付き憲章が要る。これはDaniel Kadeの提案であり、IETFの規定ではない。

拡張点は、空いているだけでは使えるとは限らない。長く新しい値が現れないと、実装は見慣れた値を「現行の一覧」ではなく「唯一の正解」として扱い始める。途中の装置も同じ仮定を学ぶ。日々の通信は壊れないため、誤りは広がる。新機能を割り当てた日に初めて、帳簿上の空間が実ネットワークでは閉じていたと判明する。

GREASEは、その発見を前倒しする仕組みだ。プロトコル上の役割を持たず、受信者が無視すべき値を日常的に混ぜる。RFC 8701ではTLSの複数の拡張点に疎な予約値を置き、クライアントが提示する。正しいサーバーは交渉を続け、未知値を拒むサーバーは、本物の新機能が必要になる前に欠陥を見せる。

DNSOPのGreasing Protocol Extension Points in the DNSは、この考えをDNSへ持ち込む。第03版は2026年7月6日公開、2027年1月7日失効予定のワーキンググループ草案である。更新も置換もあり得る。予約範囲について合意はなく、値を提案する節はまだ空欄に近い。リゾルバーとサーバーの詳細動作、エラー検知、フォールバック、テスト終了日、項目別停止、テレメトリー共有も「作業中」と明記されている。

未完成であることは、試す価値がないという意味ではない。むしろ、実装可能性と運用上の委任を分ける理由になる。コードにスイッチがあることと、本番通信でそのスイッチを入れる権限があることは別だ。

一つの名称の下に、異なる実験がある

候補は、DNSヘッダーの残るフラグ、Opcode、EDNSバージョン、EDNSヘッダーフラグ、Class、リソースレコード型、EDNSオプションコードである。空間の大きさは、残り一ビットから約六万以上の未割り当て値まで幅がある。IANAの割り当てが進めば数も変わる。

RCODEと拡張RCODEは対象外だ。応答状態そのものを変えれば、問い合わせ側が答えをどう解釈するかを変えてしまう。GREASEの前提は、構造上は許される未知値を、適合する相手が透過的に無視できることにある。

したがって、これは壊れたパケットを投げるテストではない。値に実用的な意味がないことは意図された性質である。受信側が無視して通信を続ければ、将来用の関節が動く。失敗すれば、未知値への不寛容が見つかる。ただし、その一回の失敗だけで、途中のどの装置が原因かまでは分からない。

さらに、EDNSオプションにはコードだけでなくデータがある。RR型の試験では別の問い合わせを組み立てる場合もある。一ビットの空間に、十六ビット空間と同じ予約アルゴリズムは置けない。運用承認の単位は「DNS GREASE全体」ではなく、方向、拡張点、値生成、制御問い合わせを含む個別試験でなければならない。

成功する再試行が、最初の失敗を隠す

草案は、GREASE付き問い合わせが失敗したとき、拡張を外して再試行する道を示す。サービスは継続しやすいが、利用者は最初の失敗時間を待つ。最終応答だけを見る監視では、互換性問題が「成功」に埋もれる。

別の道は、通常問い合わせとGREASE問い合わせを同時に出すことだ。通常側の答えを利用者へ返し、実験側は測定だけに使う。待ち時間への影響を減らせる一方、権威サーバーと経路は追加の通信を処理する。

順次方式が使うのは遅延予算であり、並行方式が使うのは問い合わせ量と計算予算である。ログ、分析、障害対応の人員はどちらにも必要だ。実験者が得る知見と、相手方が引き受ける負担は同じ場所にない。

第03版は高トランザクションのリゾルバーなら小さな標本で粗い像が得られるとし、「1000件に1件か？」という未確定の例を置く。この疑問符を外してはならない。小規模な社内リゾルバーと世界規模の公開サービスでは、同じ比率でも絶対量と宛先集中が違う。

統治ルールには比率と絶対上限の両方が要る。全体だけでなく宛先別の上限も必要だ。障害対応中、遅延に敏感な用途、脆弱と分かっている権威サービスは除外できるようにする。段階拡大は、通常サービスの健全性と実験データの有用性を別々に確認してから行う。

応答側の実験は、結果の見えない場所へ届く

リゾルバー起点なら、発信者は送った値と近接した結果を記録し、通常問い合わせと比較できる。原因の装置までは特定できなくても、試験の入口と戻り口は手元にある。

権威サーバー側から、未知のフラグやオプションを応答へ入れる方法もある。対象を限定した測定には役立つ。しかし応答者は、問い合わせ側が受け入れたのか、別サーバーへ再試行したのか、そのまま諦めたのか、最終アプリケーションが停止したのかを必ずしも観測できない。

草案が応答側GREASEを既定で無効にすべきだとする理由はここにある。この境界を製品画面の一つのチェック欄に畳んではならない。再帰サービスで送信試験を許可した運用者が、権威サービスで応答を変える試験まで許可したことにはならない。

応答側には、試験ゾーンや対象名の明記、外部クライアント観測、より低い上限、即時停止と復旧確認が必要だ。下流失敗が見えない以上、ローカルのアラームが静かであることは拡大の根拠にならない。

予約する危険と、予約しない危険

GREASE専用値を予約すれば、パケット上で見つけやすく、後に本物の機能が割り当てられる衝突も避けられる。だが受信実装が、その既知範囲だけを特別扱いする可能性がある。GREASE値だけは無視し、それ以外の未知値を拒み続ければ、試験の緑ランプは一般的な拡張耐性を意味しない。

現在の未割り当て空間から無作為に選べば、既知の白リストを超えて試せる。今度は、その番号が将来IANAによって実用途へ割り当てられる危険が生じる。古い実装は「捨てる値」として学習したまま、新しい意味も捨てるかもしれない。

草案が挙げる既定の試験終了日は、衝突を抑えるための安全装置だ。期限切れで停止すれば、更新時に新しいレジストリー状態を確認しなければならない。無期限実行は、将来の監視義務を、何年後に担当するか分からない人へ押しつける。

調査時点のIANA DNS Parametersは2026年8月28日更新で、Class、RR TYPE、Opcode、EDNSオプション、フラグ、バージョンを別々に管理している。そこには、草案で未決のDNS横断GREASE予約が完成形として存在するわけではない。

承認時のIANAスナップショットを保存すれば、「その時点で何を未割り当てと判断したか」を検証できる。永久使用権にはならない。新規割り当てと交差した試験値は自動で退役し、再承認なしに別の値へ勝手に移ってはならない。

観測は、加えた揺らぎを説明できるか

目的は障害を増やすことではなく、修正可能な証拠を得ることだ。頻度が低すぎれば通常エラーへ埋もれ、高すぎたり規則的すぎたりすれば相手がGREASEだけを見分ける。一般的なGREASE草案は、この両極を警告する。

DNSでは、フォールバック後の成功と、実験の失敗を分離しなければならない。記録すべき最小単位は、拡張点、値の分類、生成アルゴリズム版、方向、時刻、近接応答、所要時間、再試行か並行か、利用者へ返した通常結果である。

証拠の言い方にも上限がある。タイムアウトはミドルボックスを名指ししない。FORMERRは拒否地点を示さない。対照との再現可能な差は調査を始めるには十分でも、特定事業者への帰責には足りない。

値の予測可能性は指紋になる。第03版は、非ランダムな値が特定のリゾルバー実装を識別させ得ると述べる。一般草案も、パラメーター変更全般が指紋へ影響し得るとする。一方、TLSの先例では、接続ごとの完全な変化が再試行で不具合を隠し、リリース期間中の安定が再現性を高めるという別の問題がある。

完全なランダム性と完全な再現性を同時に約束してはいけない。一定の期間内でパターンを保ち、期間ごとに回す。問い合わせ名を最小化し、生ログは診断期間だけ保持し、共有は集約する。何を取らないかまで書いて初めて、プライバシー方針になる。

フォールバックの撤回は別の決定である

未知の拡張を外してやり直す方法は、古い相手との通信を守ってきた。だが拒否した側は修正しなくても通信でき、更新コストを送信側全体へ転嫁できる。

セキュリティ拡張が外される場合はさらに危険だ。第03版は、攻撃者が互換性問題を利用して保護機能を黙って無効にする可能性を指摘する。GREASEは、その弱点を本物の新拡張より先に見つけ、将来的にフォールバック依存を減らすための材料になる。

それでも、不寛容の観測、当面のサービス維持、フォールバック撤回は別々の権限だ。試験者が故障装置を更新できるとは限らない。観測した瞬間に互換性を切れば、技術負債が利用者障害へ変わる。

記録には、観測済み、影響抑制中、撤回承認済みという状態を分け、それぞれの所有者を置くべきだ。赤いグラフは調査開始の根拠であって、広い停止を命じる決議ではない。

期限付きの実験憲章

憲章の先頭には人を置く。本番通信を対象にする承認者、実装担当、結論の責任者、直ちに止められる復旧担当を明記する。ベンダーがコードを出荷した事実は、運用者の同意記録にならない。

次に線上の対象を固定する。拡張点、値集合または選択法、付随データ、方向、実装版、参照したIANA表の版である。予約、実験用、私用、未割り当てを一つの「空き値」にまとめない。

通信範囲には、対象と除外、比率、全体と宛先別の絶対上限、展開段階、観測期間を置く。順次再試行か並行対照かを明記し、遅延、タイムアウト、追加問い合わせ、計算、ログ、アラートを別予算にする。

証拠の節は、成功と失敗の意味、対照方法、保存期間、共有先、問い合わせ名の扱い、指紋の評価、異議申立てを定める。曖昧なタイムアウトを相手方の不具合として公表しない。

最後に時間を閉じる。開始、既定終了日、更新責任者、レジストリー再確認、試験別キルスイッチ、自動停止条件、復旧手順を置く。利用者エラー、宛先過負荷、対照欠落、指紋化、割り当て衝突のいずれかが閾値を超えたら、拡大ではなく停止が既定動作になる。

GREASEは、まだ存在しない将来の機能のために今の通信を使う。その時間差こそ、憲章が必要な理由だ。今日の小さな失敗を誰が引き受けるかを明らかにできない実験は、明日の柔軟性を語る前に統治を失っている。

出典

  1. Greasing Protocol Extension Points in the DNS — 第03版
  2. DNS GREASEのDatatracker記録
  3. DNS GREASE文書履歴
  4. DNSOPの作業中文書
  5. DNSOP憲章
  6. RFC 8701 — TLSへのGREASE適用
  7. RFC 6891 — DNS拡張機構
  8. Maintaining Protocols Using Grease and Variability — 第06版
  9. IANA DNS Parameters