要約

  • MXにより、アドレスのドメインは同名ホストへの接続命令ではなく、安定した識別名になった。配送機械を替えても利用者のアドレスを変更せずに済む。
  • 送信MTAはMXを問い合わせ、小さいpreferenceから試し、同値を同格として扱い、自分へ戻る経路を除外した。MX対象のMXをたどって責任を連鎖させてはならない。
  • DNSは重要な制御面だが、権威そのものではない。キャッシュは切替を非同期にし、複数名が同じ障害を共有しうる。MXは組織を認証せず、本文を暗号化しない。

名前をそのまま機械だと思えた時代

RFC 974はLOKI.BBN.COMの例を挙げた。そこにあるmailbox宛てなら、同名ホストへSMTP接続するのが通常だった。公開名と受信機械が一致していた。

例外はすでにあった。直接インターネットへ接続しないUUCPやCSNETホストには、各mailerの設定でrelayを用意した。CSNET宛てをCSNET-RELAY.ARPAへ送る例もある。RFC 821のSMTPはrelay、gateway、source routeを知っていた。MXが中継を発明したのではない。

問題は例外が送信側に散在することだった。受信側が一つの機械を替えても、遠隔の設定ファイルを一斉更新できない。ドメインを長期的な住所にするなら、「現在どこが受け取るか」は別に公開する必要があった。

二つの役割から、一つの順序へ

RFC 882とRFC 883の初期DNSは、型付きresource recordを使った。メールにはMD（mail destination）とMF（mail forwarder）があり、直接配送先と転送先を別の型で表した。

RFC 973は両方をMXへ置き換えた。MXは16ビットの符号なしpreferenceとexchangerのhostnameを持つ。小さい値を先に試し、同じ値は同じ優先度である。

これは型の整理以上の変化だった。MD/MFは機械に役割を与えた。MXは候補の集合に順序を与えた。直接ホスト、relay、backupを同じ仕組みで表せる。RFC 1035はこの小さな形式を引き継いだ。

レコードには完全な経路、負荷、契約はない。独立した送信者が動ける最小限だけが共通化された。

識別名は残り、実装は交換できる

RFC 974はdomain nameが通常はhostだが、常にそうではないと述べる。mailerはmailboxの名前へ直接接続せず、DNSへ配送先を聞く。答えは別の機械かもしれず、複数かもしれない。

組織は利用者のアドレスを保ったまま、hardware、facility、filter gateway、providerを替えられる。送信者は内部移行を知らず、現在のMXとそのaddressだけを使う。

ただしDNS制御者は今後のメールを変更できる。MXは法的identityを証明しない。それでも、相手が知る名前と、今日その名前を実装する機械を別の寿命にできた。

公開された順序を各送信者が実行する

RFC 974は配送を試すたびにMXを問い合わせるよう強く勧めた。受信ホストが故障したとき、domain administratorがDNSを変えれば、遠隔queueのメールも次の試行で新経路を学べるからだ。実際の時刻はcacheの期限に左右される。

mailerは最小のpreferenceから試し、必要なら後続へ進む。同じ最小値の交換機は、配送不能とする前にすべて試す。RFC 5321は関連addressを試行・再試行できることを要求し、同じpreferenceに差がなければrandomizeして負荷を分散する。

preferenceはlatency、距離、load、権力の尺度ではない。10が20より前なのは、domainがそう宣言したからである。20のbackupの方が近くても、その順序は変わらない。

中央のメール配車役はいない。DNSは薄い候補集合を示し、各MTAが解決、queue、retry、bounceをローカルに決める。

自分の位置を知ることでloopを切る

代替先は循環を作りうる。RFC 974では、ローカルhostがMX集合に含まれる場合、自分自身と、同じか大きい数値のMXを削除する。小さい値、つまり自分より前の交換機にしか渡せない。

backup 20はprimary 10を再試行できるが、20や30へ横流しして戻ってくる経路は作れない。preferenceはavailabilityの順序だけでなく、責任が進める向きを定める。

さらにMX対象のMXを再帰的にたどらない。あるhostがrelayのMXであっても、そのrelayが受け持つ全domainへの責任を自動的に引き継がない。元のdestinationに対する受信責任は明示されなければならず、推移しない。

キャッシュは遅延を伴う規模の仕組み

DNSはcacheによって拡張した。MX変更後、古い答えを持つ送信者と新しい答えを持つ送信者が共存する。RFC 974は、その間にloopや誤ったdelivery failureが生じうることを認めた。

すべてのmailerが毎回authoritative serverだけを問い合わせれば古さは減るが、コストが過大になる。そこで、exchanger追加前の調整、完全な回答の利用、UDP応答がtruncatedなら信頼できる回線での再問い合わせを求めた。

cacheは単なる欠陥ではない。同期性とscaleの交換条件である。安全な移行はTTLを下げ、旧新を重ね、rollbackを残す。世界同時の切替を想定しない。

MXがないときも、試行は続いた

RFC 974は空のMX集合を、元domainへ向くpreference 0の暗黙MXとして扱った。RFC 5321もimplicit MXとして残し、AまたはAAAAを解決してSMTPを試す。

旧構成との互換性は得られたが、沈黙が曖昧になった。MXなしは、古い正常構成、設定漏れ、メールを受けない意思のどれでもありうる。送信者はweb用addressなどへ何日も試行することがあった。

明示MXがある場合は逆に、その集合を無視してdomain自身のA/AAAAへfallbackしてはならない。MX targetはaddress recordへ直接解決すべきで、CNAMEを返すtargetは現行標準の範囲外である。

ドットが「サービスなし」を明示した

RFC 7505は2015年にnull MXを定義した。メールを受けないdomainは、exchangeがDNS root . でpreference 0のMXを一つだけ公開する。他のMXと共存できない。

ドットは壊れたserverではなく、exchangerが存在しないという状態である。送信者はA/AAAAへfallbackせず、RFCが典型的には約一週間と記したretryを避け、すぐ失敗を返せる。

これは1986年の機能ではなく、互換性が残した曖昧さへの29年後の修正である。null MXはSMTPのnull reverse-pathとも違い、返信不能なdomainを送信元に使うことを正当化しない。

小さなレコードに宿る制御

MXによるportabilityはDNSへの依存でもある。zoneを奪えば将来の受信先を変えられる。複数hostnameも同じprovider、facility、network、accountに依存しうる。backupはcontinuityを増やす一方、本文やmetadataへ触れる主体も増やす。

DNSSECが証明するのは公開データのintegrityであり、受信組織の法的identityや内部処理ではない。SMTP acceptanceも責任を一段渡した証拠であって、最終mailbox保存や閲覧の証明ではない。

MXの正当な範囲は狭い。domainが誰にどの順序で配送責任を渡してほしいか、またはサービスがないことを示す。それは独立運用者の協調に十分だが、DNS運用者をidentityの主権者にはしない。

最小限の配送地図

アドレス、機械、cacheされた知識は別々の速度で変わるようになった。名前は長く残り、serverは交換され、経路知識はTTLで収束する。対応関係が公開された可変状態だから、通信相手は移行に参加しなくてよい。

共通層はdomain、exchanger、preference、TTL、loopとfallbackの規則だけである。queue、security、mailbox配置、契約は各operatorに残る。

アドレスがserverより長く生きたのは、DNSが永遠の家を発見したからではない。家を明示的で交換可能な現在状態にしたからである。ローカルcodeが動くために必要な現実だけを共有した。

情報源と証拠の限界

SMTPと初期domainの文脈はRFC 821、RFC 882、RFC 883。MD/MFからMXへの変更はRFC 973。1986年のalgorithm、cache、loop、非推移責任はRFC 974による。

形式はRFC 1035、host要件はRFC 1123。成熟したlookupとimplicit MXはRFC 5321、no-service状態はRFC 7505。

文書は異なる時代に属する。後期規則を1986年へ遡及させず、仕様外の運用影響は限定された推論として扱う。