要約

  • RFC 1464はDNS TXTレコードの中に解析可能な 名前=値 の約束事を置き、既存サーバーをほぼ変えずに属性を配布できるようにした。しかし属性名の世界共通の意味や登録制度は定義しなかった。
  • TXT文字列が返ったという事実から、発行者の現実世界での権限、値の現在性、DNSSEC検証、利用した解析規則、下流処理の成功までを推論することはできない。それぞれに別の証拠が要る。

RFC 1464の魅力は、等号そのものではなかった。周囲のDNS基盤を変えずに済む、という約束にあった。

1993年5月、DNSにはアドレスやメール交換先のような型付きリソースレコードがすでにあった。新しい種類のデータを運ぶなら、通常は新しいRRタイプを定め、サーバー、リゾルバー、運用ツールが対応するまで待たなければならない。実験的RFCだった1464は近道を示した。印字可能なASCIIを既存のTXTに入れ、<属性名>=<属性値> と書けば、多くのネームサーバーは意味を知らなくても保存し、返答できる。

導入コストは確かに下がる。しかし解釈の仕事は消えない。運搬層を汎用のままにした分だけ、定義、合意、検証、判断はアプリケーション側へ移る。その境界こそ、この短い提案が後世へ残した重要な記録である。

一本の文字列を二つの欄に分ける

外部形式は、所有者名、クラス、TTL、TXT型、引用された文字列から成る。文字列の中では、引用されていない最初の等号が属性名と値を分ける。それ以後の等号は値の一部である。属性名は大文字小文字を区別せず、先頭と末尾の空白やタブは、引用されていない限り無視される。グレーブアクセントは属性名の中の等号、またはグレーブアクセント自体を引用するために使われた。

値側は別の規則を持つ。印字可能なASCIIが許され、後続の等号は通常の文字であり、空白はすべて呼び出し元へ返る。その空白を有意とみなすかはアプリケーションの判断だ。検証済み正誤表5193は、値の中でグレーブアクセントを二重化していた例を訂正した。最初の区切りより後では、その文字に引用機能はない。文書更新時修正扱いの5194は表の位置ずれであり、機構を変えるものではない。

この細部によって解析境界は決定的になった。引用されていない等号を含まないTXT文字列や、空の属性名を持つ文字列は無視できる。専用のリゾルバー補助関数は、名前側の引用を外し、同じ属性の複数値や複数属性を返せる。それでも、同じバイト列が、RFC 1464を実装した解析器には属性として見え、実装しないクライアントには単なるテキストに見える。別のプロファイルを採用するプログラムなら、さらに別の意味を読むかもしれない。

DNS応答が決めるのはRRsetである。どの解釈を採用すべきかは、消費側の契約で決まる。

未設置の登録簿が相互運用性の限界になった

RFC 1464は、広く使う属性名について登録があれば衝突を減らし、相互運用性を高められると認めていた。定期的に更新する一覧や、公開されたオブジェクト識別子のような仕組みも候補に挙げた。しかし登録制度そのものは定義しなかった。

その判断は実験開始時の負担を小さくした。新しい型表も、試す前の許可も不要になる。一方、二つの発行者、二つの解析器、二つの運用組織が同じ属性名について合意するとき、回避した費用が戻ってくる。

color=blue を例にすればよい。RFC 1464は color と COLOR が同じ名前で、値が blue だと切り分けられる。だが、それがプリンター、利用者の好み、ケーブル、警告灯、管理区分のどれを表すかは教えない。blue が管理語彙のトークンか自由記述かも、誰がその性質を宣言する権限を持つかも、消費者が何を実行すべきかも教えない。

構文によって属性は読めるようになった。共有スキーマがなければ、相互運用できる意味にはならない。

TXTは私有名前空間ではなく共有容器だった

RFC 1035はTXTのRDATAを一つ以上の文字列として定義し、その意味は置かれたドメインに依存すると説明する。RFC 1464は、その汎用容器の内部に小さな型体系を置いた。属性名が選択子のように働いても、DNS問い合わせが選ぶ単位は所有者名、クラス、RRタイプである。TXTを問い合わせるクライアントはTXT RRset全体を受け取り、その中を検索しなければならない。

IABのRFC 5507は、後にこの方式の構造上の弱点を整理した。レコード内サブタイプでは、クライアントは必要な項目だけを問い合わせられず、RRset全体を取得してから選別する。DNSSEC署名もRRset全体を対象とするため、一つの用途の変更が共有集合全体の再署名につながる。TXTについて同文書は、標準化された選択欄のないRR型にRFC 1464が汎用選択子を作ろうとしたが、成功しなかったと評価した。

これは実装例が一つもなかったという証明ではない。汎用的な約束事が普遍的な意味層にならなかった理由の説明である。同じ所有者名とTXT型を複数用途が共有すれば、内容、解析前提、サイズ制限が衝突する。一方には雑音に見える文字列が、他方には必須設定かもしれない。

TTL内の正しさと現在の意思は同じではない

属性をDNSへ置くと、DNSの時間も一緒に入ってくる。権威サーバー、再帰リゾルバー、アプリケーションキャッシュは、同じレコードの異なる時点を見せうる。人が元の意思を変えた後でも、肯定応答はTTLとリゾルバーの規則に従って正当に再利用される。

したがって、応答中の status=open だけでは、いつゾーンが更新され、いつ権威サービスが新しい値を出し始め、いつ再帰リゾルバーが取得し、残りTTLがいくつで、いつアプリケーションが動いたかは分からない。後の問い合わせが異なるバイト列を返しても、先の観測が偽だったことにはならない。逆に、プロトコル上有効なキャッシュが、秒単位で変わる運用判断には古すぎることもある。

「DNSがそう言った」は監査記録として不足する。問い合わせ名、クラス、型、完全なRRset、観測時刻、残りTTL、リゾルバー経路、そして一つの文字列を選んだ解析規則が必要だ。これらを欠けば、複数の時計が一つの無時間的な主張へ圧縮される。

DNSSECが証明するのは来歴と完全性であって命題ではない

RFC 1464はセキュリティ上の問題を論じなかった。後のDNSSECアーキテクチャは、信頼の連鎖の下でデータ起源を認証し、完全性を保護する仕組みをDNSへ与えた。RFC 4033は同時に、機密性は提供しないと明記する。

検証成功は重要な事実である。採用したトラストアンカーからたどった認証済み委任経路にRRsetが属し、経路上で検知不能に改変されなかったことを示せる。しかしゾーン変更者が、商取引、安全、本人性に関する主張を行う現実世界の権限まで持つとは証明しない。属性を定義せず、値と物理世界の一致も、運用上の意味が変わった後の現在性も保証しない。

安全に検証された結果でも、アプリケーション構文には不適合かもしれない。構文に適合し安全に検証された結果でも、対象世界では誤りうる。未署名の結果も、弱い証拠状態を記録するローカル方針の下では役立つ。これは一つの真偽尺度の強弱ではなく、別々の問いである。

後継設計は文脈を狭めた

DNSはアプリケーションデータを運ぶのをやめなかった。その代わり、どこでどの規則により解釈するかを狭くした。

RFC 6763のDNS-Based Service DiscoveryもTXTのキーと値を使うが、サービス型を指定するPTR、SRV、TXTの体系の中で使う。一つの構成文字列に一つの組を置き、キーはサービスプロファイル内で定義する。未知キーは無視し、重複キーは最初を採用する明示規則がある。ホストとポートはTXTへ重ねずSRVに残す。能力をアプリケーションプロトコル自身で交渉できるとき、TXT情報は最適化として扱われる。

これはRFC 1464がそのままDNS-SDへ成長したという意味ではない。似た句読法の周囲に、後のアプリケーションが小さく明確な意味世界を作ったのである。

RFC 6950は、TXTなら新しいRRタイプを登録せずにデータを追加できる一方、別々の用途のレコードを区別するのが難しかった歴史をたどる。用途別の所有者名構造が、TXTを解釈すべき範囲を限定した。RFC 8552は、アンダースコア付きAttrLeafについてその方向を制度化した。アンダースコア名とRRタイプの組を登録し、未分化なTXTの塊ではなく関係するRRsetを直接問い合わせられるようにする。それでも内容の全規則は場所から自動生成されず、アプリケーション仕様が定める。

歴史の流れは「無構造から自己説明」ではない。汎用運搬から、明示された範囲、登録、プロファイル、解析動作への移行だった。

句読法をプロトコルにするのは稼働コードである

RFC 1464はExperimentalだった。四ページの文書は、等号を含む全TXT文字列が突然インターネット属性になったとは宣言していない。提案したのは約束事と、ライブラリ用インターフェースの案である。相互運用には、両端が互換解析を実装し、求める属性名の定義を共有する必要があった。

文書の公開は提案が記録へ入ったことを証明する。サンプル解析器は入力を変換できることを証明する。展開状況を語るなら、どのプログラムが、どの属性を、どの名前で、いつ使ったかという資料が要る。アプリケーションの受領記録は、一つの解析値が現実の判断に影響したことを示す。これらは互いの代用にはならない。

RFC 1464の価値は普及を誇張することではなく、取引条件を明確にした点にある。運搬層との互換性は、運搬層が検証できない意味を外へ残すことで得られた。