要約

  • RFC 2219は、人やプログラムがサービスを探すときに推測していたDNSラベルを集め、サーバーを移してもサービス名を保ちやすくした。
  • 同文書は、そのラベルが証明しないものも明記した。アドレス、待受プロセス、想定ポート、クライアントへの応答、そして完全なサービス・ディレクトリーである。

名前から受ける印象と、DNSが示す事実

ブラウザーにwww.example.orgと入力すると、行き先が確定したように感じる。しかし、DNSの応答だけではそう言えない。応答にアドレスがないこともある。返されたアドレスのマシンがHTTPを待ち受けているとは限らず、待受ポートも80とは限らない。サーバーが稼働していても、個別のリクエストを拒むことはできる。1997年10月、RFC 2219は、利用者がすでに推測していたサービス名を整理しようとしながら、この隔たりを明確にした。

慣行には分かりやすい利点があった。マシン名を知らなくても、www、ftp、mailを試せる。プログラムも同じ推測ができる。管理者にとっては、ホストやアドレスが変わっても、サービス向けの名前を維持できることが重要だった。利用者は移転のたびに別の名前を覚えずに済む。RFC 2219は、この間接参照によってサービスを別のマシンへ移せること、また組織があるサービスを提供している可能性を示す手掛かりになることを説明した。

このBest Current Practiceは、新しいDNSレコード型でも、万能なサービス・ディレクトリーでもない。著者はエイリアスの慣行が当時ほぼ普遍的になっていたと記したが、これはRFC自身の同時代の評価であり、ここで独立に測定した普及率ではない。文書はwww、ftp、gopher、ldap、mail、news、ntp、pop、whoisなどを既定名として列挙し、そこにないプロトコルはその仕様で名前を提案するよう求めた。標準化したのは語彙であって、その語の先で何が動いているかを検査する取引ではなかった。

この留保は脚注ではない。wwwというDNSエントリーはWebサービスの登録を意味しない。名前がIPアドレスへ解決される必要もない。HTTPを待ち受けるホストが必要なわけでも、80番ポートを使う必要もない。すべて満たしても、サーバーが任意のクライアントを受け入れる保証はない。RFC 2219はエイリアスを有用な「ヒント」と呼び、実装者にそのように扱うよう促した。組織のDNSゾーンにある記録と、サービスの実際の動作は別の事実である。

また、このヒントは発見の連鎖の後段にある。まず利用者は組織のドメイン名を知っていなければならない。RFC 2219は組織名、所在地、事業内容からドメインを見つける方法を提供しない。ホスト名以外の情報が要るサービスも解決しない。例として挙げるLDAPでは、有意義な対話に検索ベースの指定が必要だ。エイリアスは既知のドメインに到達しやすくするが、DNSを汎用ディレクトリーにはしない。

名前の移動には運用上の選択が伴う

RFC 2219はサービス名を公開する方法として、CNAMEとAレコードを示した。CNAMEならph.example.orgをマシンの正式名の別名にでき、ホスト移転時にアドレスを重複して保守せずに済む。その一方、DNSの規則上、CNAMEの所有者名にはMXなど別のデータを共存させられない。もう一つは、サービス名そのものに一つ以上のAレコードを置く方法だ。アドレスはその名前の下で明瞭になるが、実際のホストとの同期が必要になる。RFCはどちらかを常に推奨せず、サイトごとの要件によるとした。

便利さは運用上の負債にもなる。エイリアスを使えば、転送先を最新に保ち、ホストがなくなれば記録を削除しなければならない。古いポインターは健康確認にはならない。Aレコードを直接公開するなら、ホスト構成が変わるたびにサービス名のアドレス集合も合わせる。複数のアドレスは複製サイトに使える。文書はDNSが応答順を変えたり、クライアントが独自のヒューリスティックで選んだりすると述べたが、それで可用性や同一性が証明されるわけではない。複製先が完全なコピーである場合に適する、とRFCは限定した。

セキュリティ上の注意も同じ境界にある。DNS応答は偽装され得る。存在しないアドレスでサービス妨害を起こすことも、正規サーバーを装う接続先へ利用者を誘導することも可能だ。この命名慣行自体に認証機能はない。安心感のある名前が、接続先の確認や機微な通信の保護を代替することはない。

RFC 2219は、よく知られたラベルが特定サービスを探す長期的な解決策ではないとも認めた。Server Location Resource Recordの作業、当時のRFC 2052を挙げている。時系列を正確に見る必要がある。SRV案はRFC 2219より先にあり、同文書は大きな発見問題に対する別の取り組みとして言及した。その後、RFC 2782がRFC 2052を置き換え、サービス、プロトコル、優先度、重み、ポート、ターゲットを持つレコードを定義した。ただし、クライアントがそれを使うには、該当するアプリケーション・プロトコルの仕様が指示しなければならない。後年のレコードがwwwを遡ってサービス登録証明に変えたわけではない。

RFC 2219の貢献は控えめで、だからこそ正確だ。分かりやすい名前は管理者の意図を見つけやすくし、ホストを置き換えやすくする。しかし、その名前は向こう側の事実を保証しない。ゾーン管理者はヒントを公開し、ホスト運用者は待受プロセスを管理し、クライアントは接続して応答を判断する。記号上の入口は移せる。実際に応答する相手がいるかどうかは、依然として運用の問題だ。

出典：RFC 2219、RFC EditorのRFC 2219記録、IETF Datatracker：BCP 17、RFC 1912、RFC 1034、RFC 1035、RFC 2052、RFC 2782、RFC 1123。