要約

  • RFC 3403 は DDDS 規則を DNS の NAPTR に格納したが、応答内の物理順序を実行順とはしなかった。クライアントは ORDER で権威層を組み立て、同一層内だけを PREFERENCE で選んだ。
  • 一致後に、後から現れた既知サービスを理由として別の ORDER へ移ることはできない。Additional、DNSSEC、下流サービス成功は別々の証拠だった。

DNS の表示は表形式であり、先頭行は特別に見える。パケットキャプチャにも物理的な並びがある。RFC 3403 が DDDS クライアントへ求めたのは、その見かけを規則順と誤認しないことだった。返されたのは候補集合であり、権威順は各レコードの内部にあった。

2002 年 10 月に標準化過程で公開された RFC 3403 は、DNS を DDDS 規則データベースとして定義した。鍵は有効なドメイン名で、クライアントは型 35 の NAPTR を問い合わせる。文書は RFC 2915 と RFC 2168 を置き換え、NAPTR の正式仕様になった。

ORDER は委任の順番を復元する。小さい値から処理し、同じ ORDER のレコードは権威上同一の規則とみなす。異なるサービスを持っていても同じである。一致が見つかれば、DDDS の明示的な複雑サービス選択例外を除き、別の ORDER を検討してはならない。

したがって、最初に到着したレコードに優先権はない。サーバー、キャッシュ、ライブラリは意味を変えず RRset を並べ替えられる。最初に理解できた Services を採用する実装は、管理者の規則構造を転送上の偶然で上書きしてしまう。

PREFERENCE は同一層で働く。DDDS の Priority に相当し、同じ ORDER の候補を小さい値から並べる。優先プロトコルの対応が弱いなどの理由で次候補を選べても、一致後に別の権威層へ越える道具にはならない。

負荷分散の重みでもなかった。権威上同等の規則に品質や選好を示すフィールドである。負荷を分けるなら SRV や複数 A レコードを使う。PREFERENCE に確率動作を読み込むことは、規格にない契約を作る。

Flags と Services の意味はアプリケーション仕様が与えた。どのフラグが終端か、どのサービス値が有効かを DNS データベース一般は決めない。文字列を知っているだけでは、その用途を理解した証拠にならない。

REGEXP と REPLACEMENT は置換式の排他的な二形式だった。REGEXP は元のアプリケーション文字列へ適用する。REPLACEMENT は単純置換用の完全修飾ドメイン名で、名前圧縮を使わない。両方が埋まったレコードは誤りであり、無視またはエラーとすべきだった。

ゾーンファイルから応答へ至る間にも解釈がある。バックスラッシュはマスターファイルのエスケープ文字なので、応答に一つ出すため二つ書く場合がある。管理元とネットワーク上の式を両方保存しなければ、変化点を見落とす。

文字列は UTF-8 を使った。ASCII 等価範囲外ではバイト列でなくコードポイントとして扱う。特定 POSIX ロケールへの依存も禁止された。クライアントの言語設定で意味が変わる式は普遍的な規則にならない。

同じ DNS 名を複数 DDDS アプリケーションが使えば衝突する。対策は、用途別ゾーン、入力固有部分へアンカーした式、または用途固有の Flags と Services である。同居は契約統合を意味しない。

Additional セクションは最適化だった。サーバーは答えと同じ真正性を持つ A や SRV を添付でき、アプリケーションも利用できる。しかし、Additional を一切付けないネームサーバーでも動作しなければならない。不在は次の問い合わせを要するだけで、NAPTR 不完全の証明ではない。

TTL は時間的一貫性を守る。失敗後に以前の規則へ戻るなら、依存する全レコードの有効性を確認する。一つでも期限切れなら最初から再開する。古い前半と新しい後半を接ぐと、同時には存在しなかった規則列になる。

書換え後の問い合わせが失敗した場合、別経路へ後退するより失敗を報告することが強く推奨された。無制限なバックトラックは決定的な委任を探索木へ変え、どの権威で失敗したかを隠す。

DNSSEC は NAPTR を署名・検証できる。それは DNS データの真正性を示すが、式の安全性、並べ替えの正しさ、Services と用途の一致、下流成功までは示さない。式を任意コード実行可能な環境へ無検査で渡さないという警告は別に置かれた。

IANA DNS Parameters は NAPTR を型 35 として記録する。番号の調整証拠であって、実装証明ではない。RFC Editor の現行正誤票は Held for Document Update の編集上の 2868 一件で、Services 説明の this this を一語に直すだけである。

運用証跡には、問い合わせ鍵、完全 RRset、DNSSEC、TTL、受信順、整列後 ORDER 群、PREFERENCE、Flags、Services、REGEXP/REPLACEMENT の妥当性、UTF-8 解釈、ゾーン記述と受信式の比較、拒否、選択規則、使用 Additional、次問い合わせ、終端後の結果が必要になる。

Lu Heng の最小初期仕様は分業を説明する。共有すべき DNS 表現だけを標準化し、サービス意味は用途へ残した。稼働コード優先の試験では RRset を混ぜ、Additional を除き、ロケールを変え、TTL を切らす。それでも権威フィールドに従うことが証明になる。

RFC 3403 は無順序集合から順序ある行為を作ったが、転送順にその仕事を代行させなかった。最初に見えた NAPTR と最初の規則は別物だった。

出典