난 당신이 이해 하지 말아야 직접 IP 주소로 MX 레코드를 지적하지만, 해야 대신을 가리 A회전에, 메일 서버의 IP 주소를 가리키는 기록.

그러나 원칙적으로 왜 이것이 필요한가?

MX 레코드 뒤에 전체 아이디어는 지정하는 것입니다 호스트 또는 호스트 도메인에 대한 메일을 받아 들일 수 있습니다. RFC 1035에 지정된대로 MX 레코드는 도메인 이름을 포함합니다. 따라서 DNS에서 확인할 수있는 호스트를 가리켜 야합니다. 규정되지 않은 도메인 이름으로 해석되어 해석 할 수 없으므로 IP 주소를 사용할 수 없습니다.

사양이 처음 작성된 1980 년대의 이유는 오늘날의 이유와 거의 같습니다. 호스트는 여러 네트워크에 연결되어 있고 여러 프로토콜을 사용할 수 있습니다.

80 년대에는 TCP / IP를 사용하는 (상대적으로 새로운) 인터넷과 다른 프로토콜을 사용하는 다른 레거시 네트워크에 모두 연결된 메일 게이트웨이가있는 경우가 드물지 않았습니다. 이 방법으로 MX를 지정하면 인터넷 이외의 네트워크 (예 : Chaosnet) 에서 이러한 호스트에 도달하는 방법을 식별 할 수있는 DNS 레코드가 허용되었습니다 . 그러나 실제로 이것은 거의 일어나지 않았다. 사실상 모든 사람이 네트워크를 다시 엔지니어링하여 인터넷의 일부가되었습니다.

오늘날에는 여러 프로토콜 (IPv4 및 IPv6)과 각 프로토콜의 여러 IP 주소를 통해 호스트에 도달 할 수 있습니다. 단일 MX 레코드는 둘 이상의 주소를 나열 할 수 없으므로 유일한 옵션은 호스트를 가리키는 것입니다. 그러면 해당 호스트의 모든 주소를 조회 할 수 있습니다. (성능 최적화로서 DNS 서버는 호스트에 대한 권한있는 레코드가있는 경우 응답 추가 섹션에서 호스트의 주소 레코드를 전송하여 왕복 시간을 절약합니다.)

메일 교환기가 타사 (예 : Google Apps 또는 Office 365)에 의해 제공 될 때 발생하는 상황도 있습니다. MX 레코드가 호스트 이름을 가리 키지 만 서비스 공급자가 메일 서버의 IP 주소를 변경해야 할 수도 있습니다. 호스트를 지적 했으므로 서비스 제공 업체는이를 투명하게 수행 할 수 있으며 레코드를 변경할 필요가 없습니다.

프로토콜로서의 DNS는 서로 다른 유형의 값을 가지는데,이 값들은 서로 바뀔 수 없습니다.

DNS는 레코드 유형과 해당 레코드가 보유하는 데이터 유형간에 엄격한 매핑을 사용하는 이진 프로토콜이라는 점에 유의해야합니다.

예를 들어
, A레코드에는 IPv4 주소 (4 바이트의 데이터, 고정 길이)가 있습니다. 레코드의 IPv6 주소 (16 바이트의 데이터, 고정 길이)를 보유하고있다.
AAAA

MX기록은, 다른 한편으로는, 보유 이름 (형식에 대한 라벨의 순서 <int number of bytes> <label> <int number of bytes> <label> <int 0>, 가변 길이).

그것은 아니다 가능 에 대한 MX기록이 데이터로 IP 주소를 가지고.

나는 이것을 추측으로 버릴 것이다. 물론 독감에 걸렸을 수도 있습니다.

RFC 974 상태 :

LOCAL 메일러의 첫 번째 단계는 REMOTE에 대한 MX RR에 대한 쿼리를 발행하는 것입니다. 메일러가 메시지를 보내려고 할 때마다이 단계를 수행해야합니다. 도메인 데이터베이스의 변경 사항은 메일러가 빠르게 사용하므로 도메인 관리자는 도메인 데이터베이스를 변경하여 결함이있는 호스트에 대한 전송 메시지를 다시 라우팅 할 수 있기를 희망합니다.

IP 대신 이름을 요구함으로써이 관행을 강력하게 권장합니다. 이름은 동일하게 유지 될 수 있으며로드 밸런싱 또는 DR의 경우 MX 레코드 자체를 변경하고 DNS 전파를 기다리는 것에 대해 걱정할 필요가 없습니다.

exim과 같은 일부 이메일 서버는 특히 순수한 IP 주소를 가리키는 MX 레코드로의 전송을 허용하지 않으므로 FQDN을 사용해야합니다. 대부분의 서버는 MX 레코드가 IP가 아닌 호스트 이름 (A 레코드의 용도)을 포함하기를 기대하기 때문입니다.

편집 : 정교하게 말하자면 DNS에서 각 레코드에는 각 레코드가 보유 할 수있는 데이터 유형에 대한 엄격한 요구 사항이 있습니다. MX 레코드의 경우 호스트 이름 만 입니다.

RFC 1025 MX 레코드에서 A 레코드 또는 CNAME의 RR (자원 레코드) 만 가리 킵니다.

따라서 메일을 보내는 메일 서버는 MX 레코드의 RR을 요청하고, mx 레코드는 서버의 레코드를 나열하고, 메일 서버는 A 레코드를 얻기 위해 정방향 조회를 수행 한 다음 smtp를 통해 다음과 같은 서비스 호스트로 메일을 전달합니다. 메일 서버가 해당 도메인에 대한 메일을 수신 할 의사가있는 경우

질문-메일을 IP 주소로 보낼 수없는 이유

응답-신뢰로 인해

메일에 관한 많은 규칙들이 앞뒤로 전송 된 메시지가 실제로 유효한 도메인 간의 신뢰를 유지하기 위해 발전해 왔습니다. 이 모든 것은 궁극적으로 스팸을 줄이는 것입니다.

• 역방향 IP 조회
• 해당 사안에 대한 정방향 조회

재단이 메일 서버를 구축하는 데 필요한 모든 필수 구성 요소에는 신뢰할 수있는 통신을 만들고 신뢰할 수없는 통신을 줄이는 데있어 최소한의 작은 구성 요소가 있습니다.

참조-RFC 1035 및 974

https://www.ietf.org/rfc/rfc1035.txt35

https://www.ietf.org/rfc/rfc974.txt

MX레코드 의 목적은 응용 프로그램 (메일 전송)이 사용될 호스트에 대해 배울 수 있다는 것입니다. 응용 프로그램 수준에서 호스트 이름 은 IP 주소가 아닌 올바른 이름 입니다.

또한 변형 유형 레코드의 개념을 DNS에 추가하면 복잡한 문제가 발생하여 문제, 구현 문제, 보안 문제의 진입 점이 발생합니다. 예를 들어 1.2.3.4.example.com.유효한 호스트 이름입니다 (예 : RFC1034, 3.5의 관점에서도). MXexample.com의 바인드 구성 파일에서와 같이이 호스트를 지정하면

.  MX 10  1.2.3.4

IP가있는 MX 레코드와 똑같을 것입니다. 심지어 DNS 데이터 그램으로 정보를 전송하기 위해서는 기발한 추가 기능이 필요합니다. 가장 간단한 방법은 명확성을 위해 새로운 리소스 레코드 유형 을 도입하는 것 MXA입니다. 그러나 다시, 왜 때 새로운 레코드 유형과 같은 부담을 소개

. MXA 10 5.6.7.8

항상로 교체 될 수

. MX 10 dummy
dummy A 5.6.7.8

(그리고 MXA레코드를 모르는 DNS 클라이언트에서도 지원 될 것 입니까?)