要約

  • draft-levine-dnsextlang-14 は、RRTYPE の構文を TXT レコードで記述し、多くの新しい型を設定データとして扱う案である。現時点では個人提出の Internet-Draft であり、RFC でも稼働中の IANA サービスでもない。
  • 特別な処理を要する型には X を付けるが、この印は処理コードを供給しない。サーバーがその機能を持たない場合に拒否するための手掛かりである。
  • DNSSEC が証明できるのは、検証ポリシーの下での RRset の出所と完全性である。意味の正しさや実装互換性は、二つの名前の照合、ローカル上書きの開示、パーサーテスト、隔離ロード、権威応答の読み戻しで確かめる必要がある。

この提案を評価する最良の場面は、レジストリの画面ではなく、ゾーンを再読込する直前である。取得した TXT レコードは有効に署名され、五つのフィールドも文法どおりで、プロビジョニング画面まで生成できた。それでも運用者は止まるべきだ。いま動いているバイナリは同じテキストを期待どおりの RDATA に変換するのか。保存、署名、AXFR、再読込を経ても同じオクテットなのか。型固有の処理を必要とするのに、単に構文を読めただけではないのか。

草案が解こうとする負担は実在する。新しい RRTYPE のたびに権威サーバーとプロビジョニング製品がマスターファイル構文を実装すると、普及は製品のリリース周期に縛られる。提案する extension language では、stanza が型名、番号、フラグ、フィールド列を記述する。サーバーは人が読めるマスターファイルをバイナリ表現へ変換し、AXFR から得たデータをテキストへ戻せる。入力フォームと構文検査にも同じ記述を使える。

これは実装の消滅ではなく移動である。コンパイル済みコードの一部が、パーサーによって解釈される設定データになる。したがって、そのデータを取得した瞬間ではなく、動作へ昇格させる瞬間に統制が必要になる。

二重の名前は更新時に分岐する

DNS 上の stanza は、数値を使う RRTYPE.ARPA と記号名を使う RRNAME.ARPA の二か所に、同一の TXT として置く。片方を CNAME にすることもできる。言語タグ付きの別名は説明文をローカライズし、接頭辞なしのレコードが既定値になる。

検索には便利だが、一貫性は自動ではない。独立した二つの RRset を同時に更新できなければ、キャッシュ A は新しい数値定義を、キャッシュ B は古い記号定義を返し得る。言語版と既定版も別の時点で切り替わる。草案は「同一」と要求する一方、不一致を観測したクライアントがどちらを採用すべきか規定していない。

さらに、ディレクトリーの説明は _LIST.RRTYPE.ARPA を指すが、例は _LIST.RRNAME.ARPA になっている。これは実装ごとの自由度ではなく、後続版で解消すべき文面上の矛盾である。現段階の実装は、暗黙に片方を正解とせず、どちらを照会したかを記録して閉じた失敗にすべきだ。

TTL も世代の同時切替を保証しない。RFC 8767 は権威側を更新できない特定条件で stale data を返す選択肢まで定めている。草案が stale 運用を命じているわけではない。しかし実行証跡には、権威から直接得た現行値、TTL 内のキャッシュ値、期限後の回復用値を区別する欄が必要だ。

任意のローカルファイルはデバッグと上書きに使える。中央側の障害から離れて試せる点は重要だが、ファイルのハッシュと優先順位が見えなければ、同じ DNS 応答を得た二台が異なるスキーマを実行する。ローカル判断を残すことと、ローカル判断を不可視にすることは同じではない。

DNSSEC は意味検査ではない

セキュリティ節は、DNS から取り込む定義がスプーフィングで改変される危険を挙げ、DNSSEC を防御策の一つとする。RFC 4033 が提供するのは RRset の出所認証とデータ完全性であり、信頼アンカーと認証チェーンに依存する。

検証成功が示すのは、認証されたゾーンがそのバイト列を公開し、途中で検出不能な改変を受けなかったということだ。フィールドの組合せが正しい、二つの名前が一致する、対象パーサーが安全に処理できる、運用者が有効化を承認した、という意味ではない。誤った定義も正しく署名できる。

従って、公開・認証・有効化を一つの「信頼」にまとめてはいけない。公開者は主張を置く。検証器は由来を確認する。サービスに影響を与える権限は運用者が付与する。それぞれの主体と記録が必要である。

X は機能ではなく境界標識である

追加処理が必要な型には X が付く。DNAME や DNSSEC のような型を理解しないサーバーは、その型を含むゾーンをエラーにできる。I と A はクラス適用範囲、O と E は廃止・実験状態を表す。

しかし X はプラグインを配布しない。必要なモジュールやバージョンを指定せず、適合試験も含まない。ワイヤ上のフィールドを読めても、追加節の生成や検証など型固有の仕事を実行できない場合がある。ここでの安全な自動化は、推測して通すことではなく、理由付きで止めることである。

RFC 3597 は比較の基準になる。未知型は以前から TYPEnn \# length hex という一般表記でマスターファイルに保存でき、サーバーやリゾルバーは透過的に扱う必要がある。未知型には追加節処理がない。extension language の新規性は、人間向け構文、フォーム、検証、表駆動変換を改善する点にあり、未知の RDATA を運べるようにすること自体ではない。

この一般表記は保守的な退路でもある。読みやすいスキーマの照合に失敗したり、必要な処理が実装されていなかったりしても、適切な場面では不透明なワイヤ表現を保持できる。「便利な構文を拒否する」と「レコードを失う」を同一視する必要はない。

実行証跡はバイトから応答までを結ぶ

草案は、不正なフィールド定義が十分に検査しないサーバーやプロビジョニングソフトで奇妙なバグを起こし得ると明記する。また、任意レコードを表現できるため、利用者に許す型を制限しているシステムでは認可境界にも影響する。

そこで一つの定義に対し、少なくとも次の連鎖を残す。草案の版と文書状態、ディレクトリー回答、数値名・記号名・言語版の各ハッシュ、DNSSEC 検証結果と信頼ポリシー、TTL・キャッシュ年齢・stale の有無、ローカルファイルのハッシュ、サーバーとパーサーのビルド、使用可能なフィールド型、X ごとの実装モジュール、正常系と異常系の試験、テキストからワイヤへの変換と逆変換、隔離ゾーンのロード、権威問い合わせの実測、そして有効化範囲とロールバック結果である。

これは本稿の運用提案であり、草案の規範文ではない。価値は、前段の証拠が後段の成功を代行しない点にある。署名はパーサーテストではない。パーサーテストはゾーンロードではない。ロードは応答ではない。一台の応答はフリート全体の収束ではない。

障害も正しい場所へ戻せる。二つの名前の差は照合、未知 token は能力判定、往復で変わるバイトは変換、隔離では通って本番で失敗するなら配備の問題だ。すべてを「新型非対応」と呼ぶ運用は、局所修復の機会を失う。

共通仕様は薄く、実行判断は手元に置く

中央で共通にすべきなのは、可搬な文法、名前と番号の結合、フィールド意味、言語選択、登録手続、互換性に不可欠な不変条件である。製品固有のデータベース構造、資源上限、有効化時刻、特殊処理、ロールバックまで中央が決める必要はない。

Heng Lu の最小初期仕様という考え方に沿えば、交換に不可欠な部分だけを共通化し、その後の判断は結果を負う場所へ残す。自発的採用は、レジストリに項目があることではなく、稼働するコードが同じ結果を再現できることから成立する。

この分離は革新を遅らせない。ローカル stanza で先行実験し、プロビジョニング製品だけ先にフォームを作り、非対応サーバーは RFC 3597 表記を使える。複数経路の存在が問題なのではない。どの経路・どの世代・どのバイトを実行したか分からないことが問題なのである。