要約

  • WKSは一つのIPv4アドレス、IPプロトコル番号、ポートごとのビットマップをDNSに格納した。値が1ならサーバーが待ち受けているはずだと示したが、その瞬間の観測ではなかった。
  • RFC 974はSMTPの表示がないMX宛先を除外するよう勧めた。RFC 1123は普及不足を理由にこの手順を撤回し、サービスの存在は実際の利用を試して確認するよう求めた。
  • 番号の登録、DNSへの公開、プロセスの稼働、ネットワークの許可、アプリケーションの確認は別々の主体が担う。一つの保存済みビットでは、そのすべてを証明できない。

最初のパケットより前の判断

初期のメール転送プログラムが、複数のMX宛先を前にしている。まだTCPの接続要求は送っていない。それでもDNSへWKSを問い合わせれば、各宛先でSMTPが動いているか分かるように見えた。

返答にはアドレス、プロトコル番号、ビット列が入っている。TCPを選び、ゼロから数えて25番目を見る。そこが1ならポート25でSMTPサーバーが待ち受けているはずだ。0なら、そのアドレスではSMTPを提供していない。接続する前に候補を絞れるなら、失敗する試行の待ち時間を省ける。

しかし、省いた接続は、本来確かめたかった事実を観測する機会でもあった。DNSサーバーは返答の瞬間に相手のプロセスを調べていない。問い合わせ元から経路をたどり、途中のフィルターを通過できるか確認するわけでもない。ゾーンの管理者が公開した情報を、場合によってはキャッシュから返しているだけだった。

ビットの意味は明確でも、現実のサービスの状態はそれだけでは決まらない。WKSが浮き彫りにしたのは、符号化の曖昧さではなく、記録された説明と現在の動作の違いである。

1983年のサービス一覧はアドレスに結び付いていた

RFC 883は1983年11月にWKSを定義した。RFC 1035も1987年に同じ骨格を維持した。データ部分は32ビットのInternetアドレス、8ビットのIPプロトコル番号、そして長さが8ビットの倍数となる可変長のビットマップで構成される。

各位置が、そのプロトコルのポート番号に対応する。最初はポート0、次はポート1で、送信されたビット列の末尾より先は0とみなす。仕様のSMTPの例では、TCPの26個目の位置がポート25を表す。値が1ならサーバーが待ち受けているはずであり、0ならそのアドレスでサービスを提供していないと説明されている。

ここで記録されるのは、後からアドレスを引ける宛先名ではない。IPv4アドレスそのものである。複数のアドレスを持つホストには複数のWKSが必要で、TCPとUDPにも別々の記録が必要になる。サービスをホストから独立した存在として名付けるのではなく、特定のアドレスとプロトコルの組について一覧を作る方式だった。

ビットマップは途中を省略できない。必要な長さはサービスの個数より、最も大きいポート番号に左右される。離れた二つのポートだけを示したくても、その間の位置をすべて保持する。末尾の連続した0は省けるが、途中の0を飛び越えることはできない。これは形式から導かれる算術であり、当時の通信量を測った結果ではない。

よく知られたサービスが低い番号に集まり、ホストの役割が安定している環境なら合理的だった。一方、優先順位、同順位内の重み、予備の宛先、保守中の状態、特定の実体に割り当てた別ポートなどを表す欄はない。記録を増やせば一覧は広がるが、どれを先に選ぶべきかという手順は得られない。

メールの宛先を消す権限を与えられた0

1986年1月のRFC 974は、WKSにメール配送上の役割を与えた。各MXについてWKSを調べ、目的のメールサービスを提供しない名前を候補から除く。必須ではないが、強く推奨された手順だった。

一覧が完全で最新なら、0は有用な否定である。SMTPのない相手に接続して待つ必要はない。ところがWKSの公開は、SMTPを動かすための条件ではなかった。サービスは正常に動いていても、管理者が一覧を作っていない可能性がある。

更新がずれることもある。DNSとサーバーを別の担当者が管理している。MXだけ変更し、WKSを直し忘れる。新しい待ち受けプロセスが動き始めても、問い合わせ先には以前の内容が残る。ゾーンの複製やキャッシュが古いままの時間もある。仕様はこれらの操作を一つの不可分な更新として結び付けていない。

そのため、欠けている記録が「サービスはない」という判定に化ける。動作中のメールサーバーが、最初のパケットを受け取る前に配送計画から消える。失敗を避けるための最適化が、実際に試せば成功したかもしれない通信を止めてしまう。

1の側にも限界がある。TTLの途中でプロセスが停止することも、フィルターが特定の接続元を遮断することもある。アドレスが別のホストへ移り、同じポートを違うプログラムが使うかもしれない。TCP接続が成立しても、期待したSMTPであること、相手の身元、メールの受け入れまでは証明されない。

これはキャッシュが悪いという話ではない。毎回公開元へ問い合わせずに済むことが、DNSの拡張性を支えている。その仕組みを利用する記録を、同時に現在の動作を測る検査とみなすことはできない。

1989年の修正は、実際に試すことだった

RFC 1123は1989年10月、運用で得られた結論を記した。InternetのサイトはWKSをあまり使っていないため、あるアドレスの全サービスを正確に示す記録が見つかると期待してはならない。サービスが存在するか確認するには、それを使ってみるべきだとした。

メールについても明確に訂正した。RFC 974が勧めたWKSによるMX確認は、その後の経験で広い対応が得られていないと分かったため、使うべきではない。新しい複雑なビット列を導入したのではない。一覧に与えていた、接続を未然に拒む権限を取り戻したのである。

この判断は、すべてのWKSが誤りだという宣言ではない。適切に維持された記録は正しい場合もある。また、DNSのタイプ11が削除されたわけでもない。現在のIANA DNSパラメーター登録簿にもWKSは残っている。番号を維持することは衝突を避け、古いデータを解釈可能にするが、今日の利用状況を示すものではない。

変わったのは推論の強さだった。任意で、しかも疎らな一覧に載っていないことは、ネットワーク上に存在しないことを意味しない。メールでは有効な宛先を誤って捨てる損失が、一度余分に接続する費用より大きい。確認は記録の外側、相手との通信へ戻る必要があった。

一つの主張に隠れていた五つの問い

「このアドレスはSMTPを提供する」という文章を分解すると、WKSの境界が見える。

ポート番号には、独立した実装同士が同じ意味で使うための登録がある。これは語彙の調整であって、個々のホストの観測ではない。DNSの管理者はゾーン内の設定意図を公開するが、プロセスを起動し続けるわけではない。ホストの管理者が待ち受けを動かし、ネットワークの管理者が経路と許可を決める。最後に、アプリケーションの通信と認証が、何者が応答したかを確認する。

DNS上で正当な発行元のデータでも、運用上は古いことがある。ローカルでは正しい設定でも、外部から到達できないことがある。開いているポートだけでは、期待するアプリケーションだとは分からない。世界中へ同じように公開される一つの記録には、すべての経路ごとの許可を収める欄がない。

後のRFC 6335は、登録の意味を明確にした。サービス名やポートの割り当ては製品への推奨ではなく、そのポートを通る通信が安全だとも、登録されたサービスのものだとも限らない。管理者は番号の割り当てだけでなく、通信内容についての知識から方針を決めるべきだと述べる。

これは後年の説明であり、1983年の設計者の言葉として扱うものではない。ただし、共通の番号を実際の活動と同一視してはいけないという区別は、WKSの限界をよく照らしている。番号表は許可証でも、身元証明でもない。

SRVはサービスの場所を別の単位で表した

RFC 2782のSRVでは、問い合わせ名がサービス、伝送プロトコル、ドメインを示す。返答は優先順位、重み、ポート、宛先名を持つ。宛先は独自のアドレス記録を持つホスト名であり、サービス記録の中の32ビットアドレスに固定されない。

これにより、サービスを複数ホストへ配置し、主系と予備を区別し、各宛先に使うポートを明示できる。クライアントは一台の全サービス一覧ではなく、特定のサービスについて限定された候補集合を受け取る。サービスはビット位置だけで表される存在ではなくなった。

RFC 6335は、SRVなどが実行時にポートを見つける場合、固定ポートなしでサービス名だけを登録することも認めた。名前を与える行為と番号を割り当てる行為は、関係を保ちながら分離された。

それでもSRVは稼働監視ではない。重みは現在の負荷ではなく、キャッシュされた宛先は途中で停止し得る。名前を解決し、接続し、アプリケーションを確認する責任はクライアントに残る。進歩したのはDNSの全知性ではなく、公開する意図と検証する事実の分け方だった。

公式資料で分かる範囲

本稿の閉じた資料群はRFC 883、974、1035、1123、2782、6335とIANA登録簿である。初期定義、形式、MXでの推奨、その撤回、後の名前による位置指定、タイプ11の継続を確認できる。

これらは現在のWKS問い合わせ数、公開ゾーン数、製品の対応、実装の適合性を測っていない。特定の歴史的記録が古かった証拠でもなく、すべてのメール実装がRFC 974に従ったとも示さない。ビットマップの長さは形式からの算術であり、実測した遅延や帯域の評価ではない。

WKSの教訓は、DNSを信用してはいけないという単純なものではない。記録は管理者が何を公開したかを正確に伝えられる。しかしプロセスを生かし、経路を開き、相手を認証することはできない。欠けたビットが、より強い証拠を得るための接続を阻まなくなったとき、ネットワークはより堅牢になった。