요약

  • MX 레코드는 메일 주소의 도메인을 해당 이름의 기계에 연락하라는 지시가 아니라 안정적인 신원으로 만들었습니다. DNS는 사용자 이름을 바꾸지 않고도 발신자를 하나 이상의 다른 교환기로 보낼 수 있었습니다.
  • 공통 규칙은 얇게 유지되었습니다. 발신자는 MX 데이터를 조회하고, 낮은 숫자 우선순위를 먼저 시도하고, 동일한 값을 대등한 피어로 다루고, 자기 자신을 경유하는 경로를 제거하고, 재시도 결정을 로컬에서 내렸습니다. 교환기 자신의 MX 레코드가 숨겨진 책임 사슬을 만들지는 않았습니다.
  • 이 간접화는 운영상의 힘을 만들었지만 주권적 진실은 아니었습니다. 권위 있는 DNS를 제어하는 자는 수신 메일을 재지향할 수 있고, 캐시는 변경을 비동기화하며, 여러 교환기 이름이 하나의 실패를 공유할 수 있고, MX는 인증도 기밀성도 제공하지 않습니다.

주소가 아직 기계처럼 보이던 시절

RFC 974는 한때 유용했던 가정으로 시작했습니다. 메시지가LOKI.BBN.COM의 사서함으로 주소된 경우, 메일러는 보통LOKI.BBN.COM으로 SMTP 연결을 열어 메시지를 전달할 수 있었습니다. 주소의 오른쪽은 공개 목적지와 그것을 구현하는 호스트를 동시에 지명하는 것처럼 보였습니다.

이 가정은 결코 보편적이지 않았습니다. 일부 UUCP와 CSNET 호스트는 인터넷에 직접 연결되어 있지 않았습니다. 메일러는 특수한 구성 규칙을 사용했고, 한 가지 일반적인 예외는 CSNET 메일을CSNET-RELAY.ARPA로 전달하는 것이었습니다. 1982년 RFC 821로 표준화된 SMTP는 이미 릴레이, 게이트웨이, 소스 경로를 알고 있었습니다. MX는 스토어 앤 포워드 메일을 발명하지도 않았고, 직접 전달 전용 네트워크를 구하지도 않았습니다.

바뀐 것은 예외의 비용이었습니다. 각 발신자의 구성에 담긴 경로는 일관되게 갱신하기 어려웠습니다. 목적지의 소유자가 공개 사실 하나를 바꾼다고 독립적인 메일러들이 그것을 학습할 것이라 기대할 수 없었습니다. 도메인 이름이 안정적인 주소 형태가 되면서, 네트워크는 주소만으로는 더 이상 결정되지 않는 질문에 대한 표준 답을 필요로 했습니다. 현재 이 도메인의 메일을 수신하는 호스트는 어느 것인가?

두 레코드 유형이 하나의 순서 문장으로

RFC 882와 RFC 883의 초기 도메인 시스템은 유형화된 리소스 레코드를 저장했습니다. 메일 라우팅은 처음에 두 유형을 사용했습니다. 메일 목적지를 위한 MD와 메일 포워더를 위한 MF였습니다. 이 구분은 목적지를 먼저 시도하고 필요할 때 포워더를 사용한다는 단순한 계층을 인코딩했지만, 여러 대안으로 자연스럽게 일반화되지 않았습니다.

RFC 973은 둘 다 MX로 대체했습니다. 하나의 Mail Exchanger 레코드는 도메인에 두 값을 결합했습니다. 부호 없는 16비트 우선순위와 교환기의 호스트명입니다. 낮은 숫자가 높은 숫자보다 먼저 시도되었습니다. 여러 레코드가 동일한 우선순위, 따라서 동일한 우선권을 가질 수 있었습니다.

이 변경은 DNS 유형 표를 정리한 것 이상이었습니다. MD와 MF는 역할을 지명했습니다. MX는 가능한 수신자의 순서화된 집합을 공개했습니다. 직접 호스트는 여러 교환기 중 하나일 수 있었고, 릴레이는 선호되거나, 보조이거나, 대등할 수 있었습니다. 수신 도메인은 모든 원격 발신자에게 사이트별 예외를 설치하도록 요구하지 않고 현재 전달 표면을 서술했습니다.

RFC 1035는 이후 컴팩트한 와이어 형식과 마스터 파일 형식을 보존했습니다. 우선순위 하나와 교환 도메인 이름이 뒤따르는 형식입니다. 이 레코드는 전체 경로, 서비스 계약, 건강 상태 보고서를 담지 않았습니다. 발신자가 행동할 만큼의 공통 데이터만 담았습니다.

이름은 기계를 살아남다

Craig Partridge의 RFC 974는 개념적 단절을 명확히 서술했습니다. 도메인 이름은 보통, 그러나 항상 그런 것은 아니지만, 호스트입니다. 도메인 체계에서 메일러는 사서함의 이름에 단순히 접속할 수 없었습니다. 먼저 도메인 시스템에 그 이름을 위한 메시지가 어디로 가야 하는지 물어야 했습니다. 답은 완전히 다른 호스트이거나 여러 대안 중 하나의 선택일 수 있었습니다.

이 간접화는 조직에 내구성 있는 메일 신원을 부여했습니다. 운영자가 사서함을 이동시키고, 하드웨어를 교체하고, 필터링 게이트웨이를 계약하고, 백업 교환기를 추가하고, 전달을 다른 시설로 옮기는 동안 사용자는 하나의 도메인에서 주소를 유지할 수 있었습니다. 발신자는 내부 이야기를 알 필요가 없었습니다. 최신 MX 답과 그 대상에 대한 도달 가능한 주소만 필요했습니다.

이것이 신원을 형이상학적으로 만든 것은 아닙니다. 도메인과 그 존에 대한 제어가 수신 메일에 대한 실질적인 제어 표면이 되었습니다. 악의적이거나 실수로 인한 MX 변경은 전달을 재지향할 수 있었습니다. 그러나 설계는 같은 수명을 가져서는 안 되는 두 가지를 분리했습니다. 대응자들이 수신자를 알아보는 공개 이름과, 오늘 우연히 그것을 서비스하는 기계입니다.

한 번 공개되어 모든 곳에서 실행되는 경로

RFC 974는 메일러가 전달을 시도할 때마다 MX 레코드를 조회하도록 강력히 권고했습니다. 이유는 의례가 아니라 운영이었습니다. 기본 호스트가 실패하면 목적지 관리자는 DNS를 변경하고 원격 큐에 대기 중인 메시지를 재라우팅할 수 있었습니다. 각 발신자는 캐시된 데이터에 따라 다음 조회에서 새 지시를 학습했습니다.

발신자는 그 목록을 로컬에서 해석했습니다. 가장 낮은 숫자 우선순위를 시도해야 했습니다. 교환기가 메시지를 수락하거나 사용 가능한 목록이 소진될 때까지 더 높은 값을 계속 시도하도록 권장되었습니다. 여러 교환기가 가장 낮은 값을 공유하면, 메시지가 미전달로 선언되기 전에 모두가 시도되어야 했습니다.

RFC 5321의 현대 SMTP는 행동을 강화하면서 같은 기본 정산을 유지합니다. 클라이언트는 관련 주소를 시도하고 재시도할 수 있어야 합니다. 대등한 우선순위의 목적지가 선택 이유를 제공하지 않으면, 발신자는 그들 사이에서 무작위화하여 부하를 분산시키며, DNS 순서가 우연한 영구 선호로 굳어지지 않게 합니다.

우선순위는 종종 성능 점수로 오독됩니다. 그것은 지연 시간, 지리적 거리, 서버 부하, 기관의 서열이 아닙니다. 10이 20보다 선호되는 이유는 도메인이 그 순서를 공개했기 때문입니다. 높은 우선순위의 백업이 물리적으로 더 가깝고 기술적으로 더 빠를 수 있습니다. 그러나 그것은 여전히 관리적 전달 순서에서 나중입니다.

이것은 강한 의미에서 로컬 실행입니다. 공통 계층은 작은 순서화된 집합을 공개합니다. 중앙 메일 라우터가 각 패킷의 경로를 선택하지 않습니다. 독립적으로 운영되는 수천 개의 발신 MTA가 규칙을 적용하고, 재시도를 스케줄하고, 언제 일시적 실패가 반송이 되는지 결정합니다.

친절한 릴레이가 루프가 되지 않게 막는 규칙

순서화된 대안은 새로운 실패를 만듭니다. 두 메일러가 서로에게 메시지를 계속 넘길 수 있습니다. 그래서 RFC 974는 발신자가 MX 집합 안에서 자기 자신의 위치를 찾게 했습니다. 로컬 호스트가 교환기로 나타나면, 자신의 레코드와 동일하거나 더 높은 숫자 우선순위를 가진 모든 레코드를 버렸습니다. 자기보다 선호되는 교환기 쪽으로만 메시지를 넘길 수 있었습니다.

우선순위 10의 기본과 20의 백업을 가진 도메인을 생각해 보십시오. 백업이 도메인의 메일을 보유하면, 우선순위 10의 기본을 시도할 수 있습니다. 그러나 책임을 옆으로 또는 뒤로 보낼 수 있는 20이나 30의 다른 경로를 따라서는 안 됩니다. 우선순위 목록은 단순한 페일오버 순서가 아니라, 상대적 위치가 누가 누구에게 메일을 넘길 수 있는지 정의합니다.

RFC 974는 더 미묘한 허점도 막았습니다. MX 조회는 원래 목적지에 대해 이루어집니다. 발신자는 교환기 대상의 MX 레코드를 조회해 그것을 추가 릴레이 사슬로 다루지 않습니다. 어떤 호스트가 어떤 릴레이의 MX라 해도, 그것이 그 릴레이가 서비스하는 모든 도메인에 대한 책임을 조용히 부여하지는 않습니다.

이 비전이성은 동의를 보호합니다. 특정 지명된 목적지의 메일을 수락하는 것은 명시적인 운영 책임입니다. 임의의 DNS 관계 사슬을 통해 상속될 수 없습니다.

캐시는 변경을 감당할 수 있게 하되 불완전하게 한다

도메인 이름 시스템은 캐싱으로 확장되었습니다. 그것은 변경된 MX 집합이 모든 발신자에게 동시에 도달하지 않음을 의미했습니다. RFC 974는 리졸버 캐시가 만료되는 동안 오래된 레코드가 일시적 루프나 거짓 전달 실패를 만들 수 있음을 인정했습니다.

한 이론적 치료법은 모든 메일러가 매번 권위 있는 서버에 물어보고 캐시된 답을 거부하게 하는 것이었습니다. RFC는 이를 비실용적이라 거부했습니다. 캐싱을 제거하면 메일이 지나치게 비싸지기 때문입니다. 대신 운영상의 주의를 요구했습니다. 관리자는 호스트를 교환기로 추가하기 전에 조율해야 하고, 메일러는 완전한 답을 수락하고 잘린 데이터그램 조회를 신뢰할 수 있는 가상 회선으로 반복해야 했습니다.

이 트레이드오프는 여전히 가치 있는 교훈입니다. 캐시는 정책과 현실 사이에 놓인 단순한 낡은 관료제가 아닙니다. 그것은 확장성 메커니즘의 일부입니다. 운영자는 동시 글로벌 스위치가 아니라 TTL과 전환 계획을 통제합니다. 안전한 변경은 분산된 지식이 수렴할 만큼 오래 구·신 서비스를 겹쳐 운영해야 합니다.

그것은 공개가 즉시 명령이라고 가장하는 것보다 정직한 모델입니다. DNS 레코드는 많은 리졸버와 실행 중인 메일러를 통해, 서로 다른 시점에, 경계 지어진 로컬 상태에 따라 효력이 발생합니다.

침묵이 '어쨌든 주소를 시도'를 의미하던 때

1986년 설계는 호환성 규칙을 담고 있었습니다. 조회가 MX 레코드를 반환하지 않으면, 메일러는 그 도메인을 자기 자신을 가리키는 우선순위 0의 MX를 가진 것처럼 다뤘습니다. 현대의 RFC 5321은 이를 암묵적 MX라고 부릅니다. 발신자는 그다음 도메인의 A 또는 AAAA 레코드를 해석하고 그곳에서 SMTP를 시도합니다.

이 폴백은 도메인이 MX를 즉시 공개하지 않고도 새 시스템에 들어오도록 도왔습니다. 그러나 부재를 모호하게 만들었습니다. MX가 없다는 것은 오래되었으나 동작하는 구성, 실수, 또는 처음부터 메일을 받을 의도가 없는 도메인을 의미할 수 있었습니다. 발신자는 침묵에서 '서비스 없음'을 추론할 수 없었습니다. SMTP 리스너가 없는 웹 주소나 다른 주소를 상대로 큐잉하고 재시도했습니다.

RFC 5321은 명시적 데이터에 경계를 그립니다. MX 레코드가 존재하지만 어느 것도 사용할 수 없으면, 발신자는 오류를 보고해야 하며, 공개된 집합을 무시하고 도메인의 주소로 폴백할 수 없습니다. MX 대상은 주소 레코드로 해석되어야 하고, CNAME을 통해 해석되는 대상은 현대 표준 밖입니다. 명시적 라우팅 정보는 부재가 지지지 않는 의무를 담습니다.

드디어 메일 없음을 의미하게 된 점

2015년, RFC 7505는 누락된 상태를 null MX로 채웠습니다. 이메일을 받지 않는 도메인은 교환기가 DNS 루트 라벨, 즉 점으로 표기된 우선순위 0의 MX 하나를 공개합니다. 다른 MX 레코드를 공개해서는 안 됩니다.

그 점은 죽은 서버가 아닙니다. 메일 교환기가 존재하지 않는다는 명시적 진술입니다. 발신자는 A나 AAAA로 폴백하고 메시지를 큐잉하고 RFC 7505가 통상 일주일이라 서술한 기간 동안 재시도하는 대신 즉시 실패할 수 있습니다. 그 결과는 발신자 자원을 절약하고, 발신자가 아직 주소를 바로잡을 수 있는 동안 유용한 오류를 돌려줍니다.

Null MX는 RFC 974 이후 29년에 도착했으므로, 원래 설계에 기록될 수 없습니다. 그것은 정확히 후대의 교정으로서 가치 있습니다. 호환성은 불참을 누락된 구성과 구분할 수 없게 만들었습니다. 새로운 명시적 상태가 운영자에게 '이 도메인은 그 서비스를 제공하지 않는다'고 말할 능력을 회복시켰습니다.

이 레코드에도 한계가 있습니다. 메일 회신 주소에 사용되는 도메인은 null MX를 함부로 광고해서는 안 됩니다. 수신자는 전달 실패가 돌아올 수 없는 메시지를 거부할 수 있기 때문입니다. Null MX는 SMTP의 null reverse-path가 아니며, 위조되거나 도달 불가능한 신원을 정당화하지 않습니다.

무고함 없는 간접화

MX는 강력한 비대칭을 만들었습니다. 관리자가 수신 스택 전체를 바꾸는 동안 사용자는 같은 주소를 유지할 수 있었습니다. 그 이식성은 한 기계에 대한 의존을 줄였지만, 그러나 중대한 결정을 DNS 제어에 집중시켰습니다. 권위 있는 존을 바꿀 수 있는 자는 수신 서신을 새 운영자 쪽으로 향하게 할 수 있습니다.

여러 MX 이름이 그 위험을 자동으로 수리하지 않습니다. 그들은 하나의 공급자, 네트워크, 시설, 관리 계정 또는 필터링 정책을 공유할 수 있습니다. 백업 교환기는 장애 중에 메일을 수락하는 동시에 메시지 메타데이터나 내용에 접근권을 얻을 수 있습니다. DNSSEC는 공개된 레코드의 무결성을 보호할 수 있지만, 수신자의 법적 신원이나 교환기의 내부 행동을 인증하지 않습니다.

MX가 전달을 완성하지도 않습니다. 성공적인 SMTP 전송은 교환기가 하나의 프로토콜 경계에서 책임을 수락했음을 보여줄 뿐입니다. 최종 사서함이 메시지를 저장했는지, 사용자가 보았는지, 기밀성이 모든 릴레이를 살아남았는지 증명하지 않습니다.

레코드의 정당성은 더 좁고 더 강합니다. 그것은 도메인이 현재 인터넷 메일러들에게 어디에서, 어떤 순서로, 서비스가 없을 때 책임의 이전을 요청하는지를 말합니다. 독립적인 시스템들의 조율에는 충분합니다. 그러나 존 운영자를 신원이나 진실의 주권자로 만들기에 충분하지 않습니다.

가장 작은 유용한 메일 지도

MX 정산은 서로 다른 세 수명을 결합했습니다. 주소는 내구성을 유지할 수 있었습니다. 전달 인프라는 교체될 수 있었습니다. 라우팅 지식은 통제된 일정에 따라 캐시에서 만료될 수 있었습니다. 이들을 분리해 두면 모든 대응자가 이주에 참여하지 않고도 변경이 가능했습니다.

공통 계층은 압축된 채 유지되었습니다. 목적지 도메인, 교환기 이름, 우선순위, TTL, 몇 가지 루프 및 폴백 규칙. 그 외 모든 것—큐 규율, 재시도 간격, 전송 보안, 내부 사서함 배치, 사업 관계—은 자기 시스템을 운영하는 운영자에게 남았습니다.

그렇기에 메일 주소는 서버보다 오래 살았습니다. DNS가 그것을 위한 영구적인 집 하나를 발견해서가 아니라, 아키텍처가 그 집을 명시적이고 교체 가능한 매핑으로 만들었기 때문입니다. 공개가 로컬 코드가 행동할 만큼의 현실을, 그리고 그 이상을 설명할 때 신원은 기계를 살아남았습니다.

출처와 증거의 한계

SMTP와 초기 도메인 주소의 맥락은RFC 821,RFC 882,RFC 883에서 옵니다. MD/MF에서 MX로의 변경은RFC 973에 문서화되어 있습니다. 1986년 1월의 라우팅 알고리즘, 캐시 트레이드오프, 루프 규칙, 비전이적 책임은RFC 974에 있습니다.

레코드 형식은RFC 1035에 보존되어 있으며, 호스트 요구사항과 교정은RFC 1123에 있습니다. 성숙한 SMTP 조회, 암묵적 MX, 대등 우선순위 행동은RFC 5321에서 옵니다. 명시적 무서비스 상태는RFC 7505입니다.

이 출처들은 서로 다른 프로토콜 시대를 기술합니다. 후대의 규칙은 성숙과 교정을 보이기 위해 사용되며, 1986년 메일러에 귀속되지 않습니다. 사양을 넘어서는 운영적 결과는 모든 배치에 대한 측정된 주장이 아니라 경계 지어진 추론으로 제시됩니다.