MX 레코드
MX record메일 교환기 레코드(MX 레코드)는 도메인 이름을 대신하여 이메일 메시지 수락을 담당하는 메일 서버를 지정한다.DNS(Domain Name System)의 리소스 기록이다.로드 밸런싱과 중복성을 위해 메일 서버의 배열을 가리키는 여러 MX 레코드를 구성할 수 있다.
개요
자원 기록은 DNS(Domain Name System)의 기본 정보 요소다.MX 레코드는 다음 중 하나이며, 도메인은 다음과 같이 하나 이상을 설정할 수 있다.
도메인 TTL 클래스 유형 우선 순위 호스트 example.com. 1936 IN MX 10 onemail.example.com.example.com. 1936 MX 10 twomail.example.com.
MX 레코드의[1] 특징적인 페이로드 정보는 환경설정 값("우선순위"로 표시된 위)과 메일 서버의 도메인 이름("위 호스트")이다.
우선순위 필드는 어떤 메일 서버가 선호되어야 하는지를 식별한다. 이 경우 값은 둘 다 10이므로, 메일은 twomail.example.com과 twomail.example.com으로 고르게 흐를 것으로 예상된다. 즉, 공통 환경설정이다.호스트 이름은 DNS에 있는 하나 이상의 주소 레코드(A 또는 AAAA)에 직접 매핑되어야 하며, CNAME 레코드를 가리켜서는 안 된다.[2]
인터넷을 통해 전자우편 메시지가 전송되면, 송신 메일 전송 에이전트(MTA)는 도메인 네임 시스템에 각 수신인의 도메인 이름에 대한 MX 레코드를 조회한다.이 쿼리는 해당 도메인에 대한 수신 메일을 승인하는 메일 교환 서버의 호스트 이름 목록과 해당 환경설정을 반환한다.그런 다음 전송 에이전트는 SMTP 연결을 설정하여 가장 낮은 "우선순위" 값을 가진 호스트를 먼저 시도한다.이 시스템은 필요에 따라 하나의 도메인에 대해 메일 게이트웨이의 고가용성 클러스터를 구축할 수 있도록 한다.[3]
MX 메커니즘은 대체 포트 번호에 대한 메일 서비스를 제공할 수 있는 능력을 부여하지 않으며, 각 서버에 가중치를 할당하여 우선순위가 같지 않은 메일 서버 집합에 메일 배달을 분산시킬 수 있는 기능도 제공하지 않는다.
MX 기본 설정, 거리 및 우선 순위
RFC 5321에 따르면 번호가 가장 낮은 레코드가 가장 선호된다.[4]이 표현은 혼동될 수 있으므로 선호 번호를 거리라고 부르기도 한다: 작은 거리가 더 바람직하다.이전 RFC인 RFC 974는 두 서버의 기본 설정 번호가 같을 때 우선순위가 같으므로 이 두 용어는 서로 교환하여 사용한다는 것을 나타낸다.
기본은
가장 간단한 경우, 도메인은 하나의 메일 서버만 가질 수 있다.예를 들어, MTA가 example.com에 대한 MX 레코드를 조회하고 DNS 서버가 mail.example.com으로만 회신하면, MTA는 목록에 있는 서버로 메일 배달을 시도한다.이 경우, 숫자 50은 SMTP 규격에서 허용하는 정수일 수 있었다.
MX 쿼리에 대해 둘 이상의 서버가 반환되면 우선 순위가 가장 작은 서버를 먼저 시도해야 한다.동일한 기본 설정 번호의 MX 레코드가 두 개 이상 있는 경우 우선 순위가 낮은 항목으로 이동하기 전에 모두 시도해야 한다.SMTP 클라이언트는 배달 시도가 성공할 때까지 목록의 각 관련 주소를 순서대로 시도하고 재시도할 수 있어야 한다.[4]
부하분포
수신 메일의 로드를 서버 배열에 분산시키는 표준 접근법은 집합의 각 서버에 대해 동일한 환경설정 번호를 반환하는 것이다.메일을 발송할 동등한 선호의 서버를 결정할 때, 명확한 이유가 없는 한, "발신인-SMTP는 특정 조직의 다중 메일 교환기에 부하를 분산시키기 위해 임의로 발송해야 한다".[4]
다른 접근방식은 한 호스트가 여러 개의 IP 주소를 반환하는 멀티호메드 서버를 사용하는 것이다.[3]이 방법은 부하 분산을 수행하기 위해 SMTP-sender가 아닌 DNS 시스템에 부담을 주는데, 이 경우 메일 교환기의 A 레코드를 쿼리하는 클라이언트에 특정 순서로 IP 주소 목록을 제시한다.RFC는 SMTP-sender가 A 레코드 쿼리에 주어진 순서를 사용하도록 요구하기 때문에, DNS 서버는 라운드 로빈 DNS, 메일 서버 부하 또는 일부 공개되지 않은 우선 순위 체계를 포함한 어떤 방법을 통해서든 그 균형을 신중하게 조작할 수 있다.
"백업" MX
일부 도메인에는 "백업"을 위한 여러 MX 레코드가 있을 것이며, 그 중 하나는 일반적으로 전자 메일 배달의 대상으로 선택되지 않도록 더 높은 기본 설정 번호를 가진 "백업"을 목적으로 한다.
그러나 하위 호스트(일부 종류의 중단으로 인해 발생)에서 오류가 발생할 경우 이메일 서버를 전송하면 "백업" 호스트인 queue.example.com에 아래 예시처럼 전달된다.
도메인 TTL 클래스 유형 우선 순위 호스트 example.com. 1936 IN MX 10 onemail.example.com.example.com. 1936 MX 10 twomail.example.com.example.com. 1936 MX 100 queue.example.com.
백업 서버가 사용자 편지함에 직접 액세스할 수 있는 경우, 메일은 그곳에서 진행되지만, 그렇지 않으면 운영 중단이 해결될 때까지 queue.example.com에 대기할 가능성이 높다.
이런 종류의 배열이 없을 때, 도메인의 메일 서버가 모두 오프라인일 때, 송신 서버는 나중에 다시 시도하기 위해 해당 도메인으로 향하는 메시지를 대기열에 넣어야 한다.그러나 이러한 발송 서버는 이전에 오프라인 도메인의 서버를 사용할 수 있다는 통지를 받을 방법이 없으므로, 투표 일정에 의존하며 다음 번 배달 시에만 도메인이 사용 가능함을 발견하게 된다.따라서 수신 도메인의 서버가 온라인 상태가 될 때와 지연된 메시지가 최종적으로 배달될 때 사이의 지연은 송신 서버의 재시도 일정에 따라 분 단위에서 일 단위까지 발생할 수 있으며, 수신 도메인은 이에 대한 가시성이나 통제가 없다.
스팸메르스
스팸 발송자는 먼저 도메인의 백업(고거리) MX 서버 중 하나에 메일을 의도적으로 보낼 수 있으며, 이러한 서버가 덜 효과적인 안티스팸 필터를 가질 것이라고 가정할 수 있다.놀리기라고 불리는 안티스팸 기술은 이러한 행동을 가정하는 것에 기초한다.
납품 실패 처리
SMTP RFC는[4] 더 먼 MX 레코드(선호도 값이 더 높은 레코드)를 통해 전달을 재시도해야 하는 배달 실패의 종류가 정확히 모호하다.
서버가 명시적으로 4xx 오류를 전송하거나 예기치 않게 연결을 종료하여 일시적인 장애를 나타낼 때(RFC의 섹션 3.8에 따라 451 오류로 처리되어야 함) 섹션 4.5.4.1은 다음과 같이 말한다.
한 번의 시도가 실패한 후 보낸 사람은 특정 목적지 재시도를 지연해야 한다.
그러나, 발신인이 재시도할 때, RFC는 이것이 동일한 서버에 대한 것이어야 하는 것인지, 아니면 더 "이상한" MX 레코드여야 하는지에 대해 침묵한다.5.1절에 다음과 같이 명시되어 있다.
조회가 성공하면, 매핑은 다중 MX 레코드, 멀티호밍 또는 둘 다로 인해 단일 주소가 아닌 대체 배달 주소 목록을 생성할 수 있다.신뢰할 수 있는 메일 전송을 제공하기 위해, SMTP 클라이언트는 배달 시도가 성공할 때까지 이 목록에 있는 각각의 관련 주소를 순서대로 시도하고 재시도할 수 있어야 한다.
일부 서버(예: Sendmail 및 Postfix 2.1 이상)[5]는 인사말 오류와 같은 일부 유형의 임시 배달 실패 후 가장 먼 다음 MX 서버를 시도한다.[6]다른 서버(qmail, Postfix 2.0 이하)는 최단거리 MX 레코드에 지정된 서버에 전혀 접속할 수 없는 경우에만 더 먼 MX 레코드를 사용한다.차이에도 불구하고, RFC는 구체적이지 않기 때문에 두 행동 모두 유효하다.
주소 레코드로 돌아가기
MX 레코드가 없을 경우, 전자 메일 보낸 사람은 주소 레코드(예: example.com)로 배달하려고 할 것이다.
이는 다음과 같은 RFC 5321초 5.1에 기반한다.
- SMTP 클라이언트는 MX 레코드를 조회해야 함.
- 도메인에 대한 MX 레코드가 없는 경우(그리고 있는 경우에만 해당 도메인을 대상 호스트 이름으로 하고 기본 설정 값이 0인 MX 레코드를 가진 것처럼 처리하십시오.
- 대상 호스트 이름의 IP 주소를 결정하기 위해 필요에 따라 A 또는 AAAA 조회를 수행하십시오.
역사적 배경
RFC 821은 1982년에 출판되었다.HOST에서 전환되는 시점에 DNS에 대한 참조만 전달한다.DNS에 대한 TXT는 아직 시작되지 않았다.DNS에 대한 첫 번째 설명인 RFC 883은 1년 후인 1983년 말에 출판되었다.그것은 실험적이고 거의 사용되지 않는 MD와 MF 기록을 기술했다.RFC 897과 RFC 921에 따르면, DNS로의 전환은 1983년에 시작되었지만 HOST에 의해 시작되었다.TXT는 1985년 말까지 단계적으로 폐지될 예정이었고 1990년대 후반까지 완전히 폐지되지 않았다.
1986년 1월, RFC 973과 RFC 974는 MD와 MF 레코드를 부정하고 MX로 대체하며, MX 조회를 A로 대체하고, MX 조회를 정의하였다. RFC 974는 클라이언트가 각 MX 호스트에서 WKS 조회를[7] 실시하여 SMTP를 실제로 지원하는지 확인하고, 그렇지 않으면 MX 항목을 폐기할 것을 권장한다.그러나 RFC 1123은 WKS를 견제해서는 안 된다고 변경했다.
이는 HOST를 사용하여 최소 1년 이상 SMTP가 사용되었음을 의미한다.TXT, 그리고 MX가 나오기 전에 A, MD, MF를 사용한 또 다른 2년.MD와 MF는 사용하기 어려웠기 때문에 대부분의 사람들은 A 레코드만 사용했다.상황이 이렇다 보니 A 레코드를 이용한 메일 서버의 설치 기반이 상당하기 때문에 A에 대한 대비가 없는 MX는 작동하지 않았을 것이다.MX의 초기 이용은 다른 네트워크로의 게이트웨이를 식별하기 위한 것이었지만, 1990년대 초 DNS가 잘 구축될 때까지 널리 쓰이지 않았다.[8]
표준 문서
- RFC 1035(1987), 도메인 이름 - 구현 및 사양
- RFC 1912(1996), 공통 DNS 작동 및 구성 오류
- RFC 5321(2008), 단순 메일 전송 프로토콜
- RFC 7505(2015), 메일을 수신하지 않는 도메인에 대한 "Null MX" 서비스 리소스 레코드 없음
오발렛:
- RFC 2821(2001), Simple Mail Transfer Protocol(RFC-5321에 의해 보호됨)
- RFC 974(1986), 메일 라우팅 및 도메인 시스템(RFC-5321에 의해 차단됨)
참고 항목
참조
- ^ 이러한 예에서 관련 도메인 이름은 첫 번째 열에 있고, 두 번째 열에 TTL(생존 시간)이 있고, 세 번째 열에 "레코드 클래스"(이 경우 인터넷의 경우 IN)가 있고, 그 다음에 MX가 기록 유형을 식별한다.TTL은 권한 있는 이름 서버에서 정보를 새로 고쳐야 하는 시기를 나타내는 유효 기간이다.
- ^ RFC 2181, 섹션 10.3, DNS 규격의 명확화, R. Elz, R. Bush(1997년 7월)
- ^ a b HowTO - 라운드 로빈 및 로드 밸런싱 구성, 페이지 수정:2014년 2월 28일, zytrax.com
- ^ a b c d RFC 5321
- ^ 기본 MX가 응답하지만 중간 트랜잭션에 실패하는 경우, Postfix 1.2와 2.0은 백업 MX를 시도하지 않는다. Wayback Machine에서 Archived 2009-06-23, From: Victor Duchovni(빅토르)는 우선순위가 낮은 mx로 변경되지 않는다.DuchovniMorganStanley.com) 날짜:2005년 11월 11일 금요일
- ^ 인사말 실패는 표준 SMTP 인사말 핸드셰이크 대신 또는 응답으로 전송되는 오류 코드다.
- ^ Craig Partridge (January 1986). MAIL ROUTING AND THE DOMAIN SYSTEM. IETF. doi:10.17487/RFC0974. RFC 974. Retrieved 18 November 2011.
For each MX, a WKS query should be issued to see if the domain name listed actually supports the mail service desired. MX RRs which list domain names which do not support the service should be discarded. This step is optional, but strongly encouraged.
- ^ 이 섹션은 Wayback Machine에 2008-06-01 보관된 John Levine ietf-smtp 메시지로부터 수정되었다.