要約

  • RFC 1123 は先頭が数字の Internet ホスト名を合法にしたが、RFC 1178 は既存ソフトが数値アドレスと誤認し得るため、その選択をなお避けるよう勧めた。
  • RFC 1178 にとって名前は任意の札だった。人、プロジェクト、場所、役割を札に埋め込むと、機械や組織が動いた後に意味だけが古くなった。
  • 有効な label は、アプリが選んだ解析経路、短名を補ったドメイン、DNS 応答、応答主体の同一性、改名後の依存関係移行を証明しなかった。

規格の許可と運用上の選択

RFC 1178 は1990年8月に FYI 5 として発行された。以前の随筆を再掲した情報文書であり、標準ではない。RFC Editor の記録と IETF Datatracker は発行事実と状態を示すが、本文の逸話を独立した障害報告にはしない。

RFC 1123 は別の役割を持った。第2.1節は従来の制限を緩め、ホスト名の先頭を英字または数字とし、ホストソフトウェアに対応を要求した。RFC Editor の情報 は Host Requirements としての位置を示す。

それでも RFC 1178 は数字で始めないよう勧めた。同じ入力欄で名前と数値 Internet アドレスを受け取るプログラムの中には、両者を正しく区別できないものがあった。十六進数字だけでできた語にも同様の危険があった。規格は実装が到達すべき条件を示し、命名指南は更新速度の違う実装群で曖昧さを減らしたのである。

したがって「構文上有効」は DNS が呼ばれた証拠ではない。アプリケーションがその前にアドレスと判定した可能性を、実行記録で確かめる必要がある。

名前は機械の履歴書ではなかった

RFC 1178 は名前を任意の tag とみなす。最初のプロジェクト名を機械につければ、二台目が加わり、仕事が分かれ、元の機械が別の部署へ移った時に札が嘘をつく。末尾の 2 や 3 は区別にはなるが、持続する意味にはならない。

人名を使うと会話で人と機械が混ざる。所有者やハードウェアが変わっても同じ札を再利用すれば、旧機の周辺装置やデータベースを前提にしたプログラムは新しい対象へ古い期待を持ち込む。

ホスト名が示せるのは、ある label が設定または公開されたことまでである。現在の用途、管理者、装置、サービス、所有権、時間的連続性は別の台帳と観測を要する。

DNS の前に入力分類があった

RFC 1123 は、利用者がホストのドメイン名またはドット区切り十進 IP アドレスを入力できるよう勧めた。数値形式を先に構文判定し、その後で DNS を調べる。名前解決の手前に分岐が置かれていた。

旧 RFC 952 の DoD host table は英字で始めることを求めた。その RFC Editor 記録 には RFC 1123 による更新関係がある。規則が変わった日と、すべてのプログラムや script が旧前提を捨てた日は一致しない。

調査では、入力文字列、アプリと版、名前/アドレス分岐、生成された query、RR type、resolver 設定、cache、応答、選択アドレス、接続を順に残すべきである。合法性はこの最初しか答えない。

短名はローカル環境から意味を借りた

RFC 1034 は絶対名と相対名を分ける。相対名は local origin や search list によって補われ、ユーザーインターフェースでの解釈は実装ごとに異なり得る。RFC Editor の情報 は特定端末の検索順を証明しない。

RFC 1178 は一語だけのメール宛先でこの差を示した。ある mailer は local domain を足し、別の実装は他 domain の名として扱う。画面上の文字が同じでも、実効的な宛先は文脈によって変わる。

同じ label は異なる親の下で再利用できる。DNS が禁じるのは同じ親の sibling 重複であって、木全体の重複ではない。短名は global identity ではない。FQDN でさえ typed resource data の node を示すのであり、応答した機械や service を認証しない。

人が使えることも信頼性の一部だった

短さ、普通の綴り、case、命名 theme への助言は DNS の新しい長さ制限ではない。電話で伝える、障害時に打つ、alarm で見つける、命名者以外が読むという運用コストを扱う。変わった綴りは正しくても復旧を遅らせる。大小文字は別の同一性を作らない。有限の theme は機械の増設で尽きる。

名前は会話、ticket、command、mail、log、画面、backup label を渡る。そのたびに意味が揺れ得るため、構文適合だけでは品質判定にならない。

改名は隠れた参照を探す作業だった

RFC 1178 は、目立たないソフトウェア、外部の通信相手、古い backup media の札に旧名が残ると警告する。authoritative record を変えても、それらのコピーは書き換わらない。

RFC 952 は通常の nickname を勧めなかったが、改名の移行中には旧名と新名の併存を認めた。alias は継続を助けても、移行完了を証明しない。

完全な証拠には、決定権者、公開時刻、互換期間、cache 失効、code、certificate、access control、monitoring、文書、外部利用者の移行、旧名利用の減少、例外所有者、終了条件が必要になる。これは RFC 1178 の逐語的手順ではなく、同文書が示した依存の帰結である。

出典