要約

  • 1981年のARPANETとDCNETの合同表には、すでに四百を超える名前と別名があった。Millsは全ホストが全ホストを覚える平らな名簿を、ドメインに分けようとした。
  • COMSATとINTELPOSTの転送窓口が同じ機械で動くと、Mills@HOSTはドメインごとに別の郵便箱になりうる。機械のIPアドレスは返信先のドメインを教えない。完全な宛名と往復の経路がその情報を運ぶ必要があった。

同じ受付に、同じ「Mills@HOST」宛ての手紙が二通届く。片方はCOMSAT、もう片方はINTELPOSTの箱へ入れる。受付の机は一つでも、宛先は二つだ。D. L. Millsの1981年9月のRFC 799は、この種の問題をインターネットのメール名で扱った。ARPANETとDCNETの合同の名前表には、すでに四百を超える名前と別名が載っていた。大きな表を分割するだけなら考えやすい。手紙と返事が分割後も正しい箱へ行くようにするのが難しかった。

Millsの名前ドメインは、ARPA、UCL、COMSATなどの組織に対応し、互いに重なってもよく、全アドレスを覆う必要もなかった。本文では一段のドメインを想定する。一方、標準的な宛名 <user>.<host>@<domain> は右から三段に読める。COMSATの内部なら Mills@COMSAT-DLM で通じても、外から送るときは Mills.COMSAT-DLM@COMSAT がドメインまで伝える。別のドメインで同じ局所の別名を使える以上、末尾の名前は飾りではない。

各ドメインには一つ以上のメール転送プロセスを置く。その窓口は、自分のドメインに属する全ホストの名前と、ほかの各ドメインの窓口を少なくとも一つ知る。普通のホストは窓口名の集合を持ち、必要な相手だけ追加で記憶すればよい。一台のホストが複数ドメインに属し、複数のインターネットアドレスを持ち、いくつもの転送プロセスを動かすこともできる。局所的な自由を認める設計だったからこそ、窓口では「いま、どのドメインの名前として読むか」を落とせなかった。

窓口があるからといって、全メールを中継させる計画ではなかった。Millsは大半を送信元から受信先へ直接届けると考えた。中継が要るのは、両ホストが同時に接続できない、送信側に名前変換の資源がない、規制・経済・安全上の理由で直通が難しい、あるいはTCPとNCPのように通信手順が異なる場合だ。単なる中継は保存して送り直せればよく、すべてのドメインの名前表を持つ転送窓口とは役割が違う。

RFCの核心は二つの経路例にある。MRCP to:<@COMSAT,Mills@HOST> と MRCP to:<@INTELPOST,Mills@HOST> は、同じ機械が両方の転送プロセスを担当していても、異なる郵便箱を指しうる。機械が両ドメインで FORWARDER と呼ばれると、MRCP to:<@FORWARDER,Mills@HOST> ではどちらを選ぶかが消える。機械のIPアドレスを調べても戻らない。アドレスが示すのは機械であり、その手紙を受け取ったドメインの役割ではない。

返信ではこの欠落がもっと痛い。当時のRFC 780の扱いでは、受信側が直前に渡してきたホストのインターネットアドレスから差出人経路の名前を組み立てる。しかし共同窓口のアドレスからはCOMSATかINTELPOSTかを再生できない。Millsは、送信ホストが受信者経路だけでなく差出人経路も更新し、受け取った受信者経路の最初の項目を差出人経路の先頭に写すべきだと論じた。帰りの伝票に、行きで通った窓口の名前を残すのである。

古いメール形式との接続にも場所がある。MillsはRFC 733のヘッダーを経路上で何度も書き換えることを避けた。解析が大がかりになるからだ。新しいシステムは最初から完全な宛名を使える。既存のARPANETメールでは、インターネットのメール系へ最初に入る場所で、局所の <anything>@<host> を <anything>.<host>@ARPA に直す。既知の <anything>@<domain> はそのままにする。略称がどこの名簿から来たか、まだわかる入口で補う判断だった。

RFC 799は最後に議論を求めて終わる。後年のDNSの完成報告ではなく、1981年のメールを動かすための提案だ。その実例が突きつけたことは明快である。32ビットのアドレスが機械を一つに決めても、その機械の郵便窓口の役割までは一つに決めない。四百件を超える名簿が分割の理由になり、一台で二役の転送機が返信の条件を教えた。