要約

  • RFC 5395はDNSのOpCode、RCODE、ヘッダービット、RRTYPE、QTYPE、Meta-TYPE、CLASSなどを別の意味空間として整理し、同じ整数幅を一つの自由領域とは見なさなかった。
  • 未割り当て、予約、Private Useは異なる状態である。Private Useは局所利用を許す代わりに、世界的な衝突回避を提供しない。
  • 信頼できる証跡は、フィールドと文脈、番号、割り当て手続、時点付きレジストリ、実装の挙動、相手側の解釈、利用者の結果を分離する。

ビット図は設置済み機器の目録ではない

DNSヘッダーの模式図を見ると、意味が定義されていない位置は空き地に見える。しかしRFC 5395は、一部の実装が問い合わせヘッダーを応答の初期値として複写し、各ビットを十分に消去しないことを指摘した。問い合わせ専用だった状態が応答にも現れるなら、その位置へ新しい応答意味を置いた瞬間、古い残留値が正規の信号に化ける。

Zビットにはさらに古い履歴があった。かつての実装は、問い合わせでそのビットが立つとプライマリサーバーからの回答を要求されたと解釈した。RFC執筆時点では現行実装が無視すると考えられていたが、それでも新しい意味にはStandards Actionを要求した。世界中の実装が安全だと、一社の試験室では証明できないからである。

ここで「running codeを優先する」は先に出荷した実装へ所有権を渡すという意味ではない。実際のコードは、文書だけでは見えない占有を発見する証拠である。一方、公共の意味を定める権限は、合意された割り当て手続に残る。実装調査と権限判断は互いの代替ではない。

数字だけを保存すると診断を失う

RCODE 16は、数字の一致が意味の一致ではないことを示す。OPT文脈では未対応バージョンを表すBADVERS、TSIG文脈では署名失敗を表すBADSIGとなる。RFC 6895はこの例外を維持し、RCODE 9にも応答の文脈による違いを記した。

監視基盤がrcode=16だけを保存すれば、カウンター自体は正しくても、障害の所有者を決める情報が消える。プロトコル版の不一致と認証失敗では、調査対象も危険度も対処も違う。ヘッダーか拡張フィールドか、OPTかTSIGか、有効ビット幅はいくつか、どの相手とどの仕様が支配したかを残す必要がある。

同じ原則はデータベースにも及ぶ。汎用的なcode列を複数レジストリの結合キーにすると、同じ16を同じ対象だと誤認する。番号の身元は、名前空間とワイヤ上の位置を含む複合キーである。表示画面が整数だけを見せるなら、証拠層では失われた次元を保持しなければならない。

未割り当ては許可ではない

IANA表の空欄が答えるのは、その時点で割り当てが記録されているかどうかだけだ。誰が、どの手続で、どの意味クラスに割り当てられるかは別の問いである。RFC 5395はOpCode、RCODE、ヘッダービット、TYPE、CLASS、AFSDB subtypeごとに異なる政策を示した。

予約値は再利用への強い制約を持つ。未割り当て値は適用される手続を経て初めて公共の意味を得る。Private Useは局所意味を選べるが、IANAがサイト間衝突を防がないという明確な取引である。この三つを「空いている」と一括りにすると、観測を権限へ変換してしまう。

例えば二つの組織が独立に65300を選ぶ。一方は健全性表明、他方はポリシートークンとして扱う。隔離中は両方とも正常に動く。接続後は同じRRTYPEが異なるRDATAを運び、どちらが正しいかを決める公共台帳は存在しない。Private Useの成功は局所協力の証拠であり、先使用権の証拠ではない。

透明な転送は意味の実行ではない

RFC 3597は未知のRRをTYPEと十進番号、\#、長さ、16進RDATAで表現する汎用形式を定めた。圧縮や比較にも制約を設け、意味を知らないサーバーでもデータを壊さず保存・転送できるようにした。この設計により、新しいTYPEは全中間装置の同時更新を待たずに導入できる。

ただし、バイトが往復したことは機能が働いた証明ではない。セカンダリが未知RRを保持したなら保管は成功した。リゾルバーが返したなら検索は成功した。アプリケーションが内容を検証し、期待された処理を行って初めて意味の実行が確認できる。

試験は入力、ワイヤ符号化、ゾーン転送、キャッシュ、API、アプリケーション、最終結果に分けるべきだ。既知TYPEを汎用形式で入力した場合も、読み込み後はTYPE固有処理を受けなければならない。表現経路を変えて既知の危険な意味を「未知の不透明データ」に格下げすることはできない。

専門家の承認は配備の領収書ではない

RFC 5395が導入しRFC 6895が整理したRRTYPEのExpert Reviewでは、申請者が完全なテンプレートを提出し、指定専門家が承認または理由付き却下を行い、承認文書が公開保存される。普通のデータTYPEならRFC 3597に従って未知RRとして扱えること、Meta-TYPEなら任意処理で安全に捨てられることなどが評価される。

承認が証明するのは、安全に識別子を割り当てる判断が行われたことだ。製品ロードマップ、権威サーバーの構文対応、プロビジョニング、転送、リゾルバー、SDK、利用者結果は証明しない。逆に、ある実装が動くことも、公共の番号を取得した証明にはならない。

二種類の証拠を混ぜないことは双方を守る。レジストリは全ベンダーの出荷まで番号確保を待つ必要がなく、運用者は番号確保を完成済み機能として売らずに済む。割り当てテンプレートは仕様上の領収書、パケットとアプリ結果は実行上の領収書である。

古い表と現在の表には別の時刻がある

RFC 5395は2008年のBCP 42であり、2011年にRFC 6195、2013年にRFC 6895へ置き換えられた。主な変更には公開レビューリスト、RRTYPE手続の簡素化、AFSDB subtypeレジストリの閉鎖が含まれる。本稿で凍結したIANA DNS Parametersは2026年8月28日更新と表示され、当然ながら2008年には存在しなかった割り当ても含む。

古いRFC表は当時の政策を示す一次証拠であり、現在の在庫表ではない。IANA表は現在状態を示すが、取得日時なしでは再現できない。HTML、XML、テキスト、社内キャッシュ、生成コードも同期失敗でずれる可能性がある。

監査は、政策を作ったRFC、後継RFC、実際のIANA処理、採用した実装を一本の継承鎖として扱うべきだ。古い文書だけなら状態を凍結し、現在表だけなら決定の根拠を失い、コードだけなら権限を失う。正しい結論には三者の時刻が必要である。

証拠の境界

凍結資料が証明するのは、RFC 5395、6195、6895の本文と継承、RFC 3597の未知RR処理、RFC 8126のレジストリ用語、および取得時のIANA表である。現在の特定製品の対応、運用者の採用、現実の衝突事故、障害原因は証明しない。

結論は限定できる。コードポイントは、局所選択、権限ある割り当て、IANA記録、中間装置の保全、アプリケーションの理解、利用者結果という異なる時点で「使える」ようになる。一つの空白、一つの承認、一つの成功試験だけで全部を済ませてはならない。