이 질문은 RFC7505가 유용한 무언가를 추가하는 이유에 대한 답을 찾기 위해 고려해야 할 몇 가지 다른 측면에 대해 전체적으로 다룹니다.
우선, 메일 전달 방법에 대한 RFC7505 사전 정의에는 주소 레코드가있는 이름에 대해 메일 전달 시도를하지 않아야 함을 명확하게 표시 할 방법이 없습니다.
에서 RFC7505 섹션 1 :
SMTP 클라이언트에는 도메인의 전자 메일을 수락하는 서버를 식별하기 위해 정해진 순서가 있습니다. [RFC5321]의 섹션 5에이 내용이 자세히 설명되어 있습니다. 본질적으로 SMTP 클라이언트는 먼저 DNS MX RR을 조회하고, 발견되지 않으면 DNS A 또는 AAAA RR을 조회합니다. 따라서 전자 메일 서비스 의미가있는 DNS 레코드 (다른 기본 임무가있는)를 오버로드합니다.
도메인에 MX 레코드가없는 경우 발신자는 도메인의 A 또는 AAAA 레코드에있는 주소의 호스트로 메일 배달을 시도합니다. A / AAAA 주소에 SMTP 리스너가없는 경우 보내는 메일 전송 에이전트 (MTA)가 포기하기 전에 일주일 동안 오랜 시간 동안 메시지 배달이 반복적으로 시도됩니다. 메일이 잘못 전송 된 경우 발신자에게 알림이 지연되고 발신자의 리소스가 소비됩니다.
이 문서는 도메인에서 배달 시도 방지 전용 SMTP 리스너를 만들지 않고도 도메인에 대한 모든 메일 배달 시도가 즉시 실패하게하는 null MX를 정의합니다.
그러면 RFC7505가이를 구현하는 방법에 대한 문제가 있습니다 ( IN MX 0 .).
에서 RFC7505 (3) :
널 MX를 지정하는 MX 자원 레코드
도메인이 전자 메일을 수락하지 않음을 나타 내기 위해 기본 설정 번호 0과 마스터 파일에 "로 기록 된 길이가 0 인 RDATA 섹션이 포함 된 단일 MX RR ([RFC1035]의 3.3.9 섹션 참조)을 광고합니다. "을 교환 도메인으로 사용하여 도메인에 대한 메일 교환기가 없음을 나타냅니다. "."이후 유효한 호스트 이름이 아닌 경우 널 MX 레코드를 일반 MX 레코드와 혼동 할 수 없습니다.
"."사용 의사 호스트 이름으로 사용 가능한 서비스가 없음을 의미하는 SRV RR [ RFC2782 ]에서 유사한 의미를 갖습니다.
null MX를 알리는 도메인은 다른 MX RR을 알리지 않아야합니다.
(강조 추가)
여기에 언급 된 바와 같이, "널 MX"의 구현 세부 사항은 SRVRR 유형 으로부터 이미 확립 된 패턴에 기초한다 . SRVRR 유형 이 RR 유형의 일반화 된 버전이므로 이를 모방하는 것이 좋습니다 MX.
따라서 결정은 본질적으로 SRVRR 유형을 정의 할 때 이미 취해졌습니다 .
그렇다면 왜 사용하지 .invalid않습니까?
에서 RFC2606의 제 2 장 :
".invalid"는 유효하지 않은 도메인 이름의 온라인 구성에 사용하기위한 것으로 한눈에 알 수 없습니다.
여기서 볼 수 있듯이이 예약 된 TLD는 사람이 소비하기위한 것입니다. 소프트웨어에서 이것을 특별히 다루는 것을 정의하는 선례는 없습니다.
확실히 그것은 다른 방식으로 구현되었을 수 있지만 .유효한 호스트 이름이 아니므로 정상적인 사용을 방해하지 않는 최소한의 사용 방법을 사용하기로 결정했습니다 .