태그 보관물: rfc

rfc

RFC 7505 (Null MX)가 필요한 이유는 무엇입니까? 들어 nomail.example.com. 86400 IN MX

IETF RFC 7505 는 명시 적으로 이메일을받지 않아야하는 도메인 / 호스트에 대한 MX 레코드를 설명합니다. 이것은 도메인 이름 시스템 루트에서 MX를 가리켜 서 수행됩니다. 예를 들어

nomail.example.com. 86400 IN MX 0 "."

왜 이것이 필요한가요? 내 이해에는 TLD 아래의 도메인을 사용하여 명시 적 반박을 사용할 수 있습니다 invalid. 예를 들어

nomail.example.com. 86400 IN MX 0 "spam.invalid."
nomail.example.com. 86400 IN MX 10 "null.invalid."

RFC 2782 (DNS SRV)도 마찬가지로 ‘A Target of’. ‘ 이 서비스는이 도메인에서 서비스를 이용할 수 없다는 것을 의미합니다. ” 그래서 내 질문은 다음과 같습니다.

invalid이미이 기능을 수행 할 때 “사용할 수 없음”을 의미하기 위해 DNS 루트를 사용해야하는 이유는 무엇 입니까?



답변

그게 당신이 사용해야하는 것이 아니기 때문입니다 .invalid. 마찬가지로 .example그것은 지역 테스트 및 문서를위한 것입니다.

또한 .invalid계속해서 사용 하면 추가 작업이 발생합니다. 추가 DNS 조회 및 메일 서버에서 대기 모드에서 다시 시도하기 위해 메일 서버에서 대기 중입니다.

"."형식을 사용하면 즉각적인 하드 오류가 발생합니다. MTA로 인해 배달 시도가 즉시 중지됩니다. 최소한 그것이 RFC 입문 방식입니다.


답변

이 질문은 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) :

  1. 널 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는 사람이 소비하기위한 것입니다. 소프트웨어에서 이것을 특별히 다루는 것을 정의하는 선례는 없습니다.

확실히 그것은 다른 방식으로 구현되었을 수 있지만 .유효한 호스트 이름이 아니므로 정상적인 사용을 방해하지 않는 최소한의 사용 방법을 사용하기로 결정했습니다 .


답변