DNS 구성으로 인해 일부 발신자로부터 메일을받지 못함

Google Apps 도메인의 특이한 동작을 발견했습니다. 대부분의 메일은 예상대로 전달되지만 일정 기간 동안 특정 발신자의 메일이 전달되지 않는다는 결론에 도달했습니다 . 메일이 발송되지 않는 발신자를 식별 한 후 이메일을 보내달라고 요청하고 "배달 실패"-응답을 일반 Gmail에 전달하도록 요청했습니다.

배달 실패 응답에 다음 스 니펫이 포함되었습니다.

----- 세션 성적이 다음과 같습니다 -----
<myusername@GHS.L.GOOGLE.COM>... 지연 : ghs.l.google.com과의 연결 시간이 초과되었습니다.

이를 통해 빠른 검색을 수행하여 Google Apps 도움말 포럼 의이 페이지로 이동 하여 문제를 식별 할 수 있었습니다. 실제로 도메인의 DNS 레코드를 확인했으며 @ghs.google.com으로 설정되었습니다. (CNAME), 안됩니다. @ 74.125.93.121 (A)*로 변경 하면 문제가 해결되었습니다.

메일이 도착하지 않는 경우 도메인 이름이 CNAME 조회를 통해 정식 이름으로 대체되어 메일이 myusername@ghs.l.google.com대신 로 전송되었음을 이해합니다 myusername@mydomain.com. 그러나 대다수의 발신자에게 왜 효과가 있었습니까? 메일이 도착하지 않은 발신자가 다른 종류의 메일 프로토콜, 이상한 DNS 설정을 사용 했습니까?

Google에서 문제를 조사하여 볼 수있는 것에서, 이것은 널리 퍼져있는 문제 인 것 같습니다 (전투에서 나온 이메일에 대해 불평하는 사람들이 많지 않습니다). 문제는 발신자 측이 아닌 자체 DNS 설정에 있다는 것을 알고 있어야합니다.

어떻게 이것을 설명 할 수 있습니까?

^{* 여기서 읽은 내용 때문에이 IP를 사용 했지만 모든 IP가 트릭을 수행한다고 생각합니다. 누구든지 이것을 확인할 수 있습니까? 단순히 @레코드 를 제거해도 문제가 해결되지 않았으므로 변경해야했습니다.}

RFC 2821 "단순 메일 전송 프로토콜", 섹션 5 "주소 확인 및 메일 처리":

조회는 먼저 이름과 연관된 MX 레코드를 찾으려고 시도합니다. CNAME 레코드가 대신 발견되면 결과 이름은 초기 이름 인 것처럼 처리됩니다.

일반적으로 CNAME 작동 방식입니다. 그것들은 종종 잘못 사용되거나 잘못 이해되고 잘못 구현됩니다. :-)

도메인이 example.com 인 경우 일반적인 Google Apps 호스트를 가리키는 기존 MX 레코드가있을 수 있습니다.

example.com. MX 10 ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT1.ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT2.ASPMX.L.GOOGLE.COM.
example.com. MX 30 ASPMX2.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX3.GOOGLMAILE.COM.
example.com. MX 30 ASPMX4.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX5.GOOGLEMAIL.COM.

다음과 같이 항목이있는 것 같습니다.

example.com. CNAME ghs.l.google.com.

섹션 3.6.2 "별칭 및 정식 이름"의 RFC 1034 "도메인 개념 및 기능"상태는이 구성을 권장하지 않습니다.

CNAME RR이 노드에 있으면 다른 데이터가 없어야합니다. 이는 표준 이름 및 별명에 대한 데이터가 다를 수 없도록합니다.

붙여 넣은 오류가 발생하면 발신 측의 메일 서버 및 / 또는 DNS 서버가 도메인 example.com에 대한 MX 레코드를 찾으려고 시도했으며 ghs.l.google을 가리키는 CNAME을 찾았습니다. com. 그런 다음 ghs.l.google.com에 대한 MX 레코드를 찾으려고했습니다. 해당 도메인에는 현재 MX 레코드가 없으므로 메일 서버가 ghs.l.google.com의 A 레코드로 넘어 갔을 것입니다. 해당 IP 주소가 SMTP 포트에서 수신 대기하지 않아서 "ghs.l.google.com으로 연결 시간이 초과되었습니다"라는 오류가 발생합니다.

CNAME 레코드를 제거하면 메일 문제가 해결되었습니다. 대신 정의한 IP 주소가 Google 측에서 변경되면 문제가 발생할 수 있습니다.

대신 www.example.com의 cname을 정의 할 수 있습니다.

www.example.com. CNAME ghs.l.google.com.

example.com을 가리키는 IP에서 작은 웹 서버를 실행 하십시오. HTTP는 단순히 http://www.example.com/으로 리디렉션됩니다 .

그것이 효과가 있었지만 효과가 있다는 것이 다소 놀랍습니다. Postel의 법칙은 거기에서 약간의 신용을 얻습니다. :-)

RFC 1034 (으)로 돌아 가기 2.6.2 :

CNAME RR은 DNS 소프트웨어에서 특별한 조치를 유발합니다. 이름 서버가 도메인 이름과 연관된 자원 세트에서 원하는 RR을 찾지 못하면 자원 세트가 일치하는 클래스가있는 CNAME 레코드로 구성되어 있는지 확인합니다. 그렇다면 이름 서버는 응답에 CNAME 레코드를 포함하고 CNAME 레코드의 데이터 필드에 지정된 도메인 이름에서 쿼리를 다시 시작합니다. 이 규칙의 한 가지 예외는 CNAME 유형과 일치하는 쿼리가 다시 시작되지 않는다는 것입니다.

따라서이 경우 MX 레코드가 없으면 DNS 서버가 MX 조회에서 CNAME을 따르지 않아야한다고 주장 할 수 있습니다.

메일을 보낼 때 Sendmail 및 qmail (및 기타)은 기본적으로 이메일 주소의 오른쪽에 사용 된 모든 CNAME을 표준 이름으로 다시 쓰려고 시도합니다.

실제로 일부 사이트는이 동작에 의존했습니다. djb는 사람들이 "메일의 CNAME 레코드"문서에 의존하지 말아야하는 이유에 대해 자세히 설명 합니다 .

@BIND 레코드 의 기호는 도메인을 작성하는 간단한 방법입니다. 당신이 기록을 위해 만드는 경우 example.com, 다음 @단지의 별칭입니다 example.com. @레코드가 IP 여야 한다고 말하는 것은 중요한 정보가 누락 된 진술입니다. 어떤 유형의 레코드인지 알려주지 않았습니다.

게재 보고서에서 원격 메일 서버가 도메인을 ghs.l.google.com에 다시 쓰도록하기 위해 DNS로 무언가를 한 것 같습니다. 매우 이상합니다 (PS, A 레코드 는 IP, CNAME 레코드 여야 함) IP 또는 다른 CNAME 레코드 가 아니 어야합니다 ).

개인 메일 서버가 사용자의 주소를 다시 쓰는 이유는 이상합니다. 해당 사용자가 명시 적으로 다시 쓰라고 지시하지 않는 한 그렇게해서는 안됩니다. MX 레코드는 메일 서버가 메일의 경로를 알아내는 방법이므로 MX 레코드를 찾을 수 없다면 도메인의 IP가 무엇인지 전혀 신경 쓰지 않아야합니다.

제공된 정보가 거의 없기 때문에 이메일에 맞게 DNS를 올바르게 구성하는 방법에 대한 Google 지침을 따르지 않은 것처럼 들립니다. 영역 파일에 약간의 오류가있을 수도 있습니다. 유능한 영역 관리자가이를 확인하십시오.