다음을 통해 공유


DANE(명명된 엔터티)의 SMTP DNS 기반 인증 작동 방식

SMTP 프로토콜은 메일 서버 간에 메시지를 전송하는 데 사용되는 기본 프로토콜이며 기본적으로 안전하지 않습니다. TLS(전송 계층 보안) 프로토콜은 수년 전에 SMTP를 통해 암호화된 메시지 전송을 지원하기 위해 도입되었습니다. 일반적으로 요구 사항이 아닌 기회적으로 사용되며, 많은 이메일 트래픽을 일반 텍스트로 남겨 두고 사악한 행위자의 가로채기에 취약합니다. 또한 SMTP는 스푸핑 및 MITM(Man-in-the-Middle) 공격에 취약한 공용 DNS 인프라를 통해 대상 서버의 IP 주소를 결정합니다. 이 취약성으로 인해 이메일을 보내고 받기 위한 보안을 강화하기 위해 많은 새로운 표준이 생성되었으며, 이러한 표준 중 하나는 DANE(명명된 엔터티)의 DNS 기반 인증입니다.

SMTP RFC 7672 용 DANE는 도메인의 DNS 레코드 집합에 TLSA(전송 계층 보안 인증) 레코드가 있는 것을 사용하여 도메인 및 해당 메일 서버가 DANE를 지원한다는 신호를 보냅니다. TLSA 레코드가 없는 경우 DANE 검사를 시도하지 않고도 메일 흐름에 대한 DNS 확인이 평소와 같이 작동합니다. TLSA 레코드는 TLS 지원을 안전하게 신호로 표시하고 도메인에 대한 DANE 정책을 게시합니다. 따라서 메일 서버를 보내면 SMTP DANE를 사용하여 합법적인 수신 메일 서버를 성공적으로 인증할 수 있습니다. 이 인증을 통해 다운그레이드 및 MITM 공격을 방지할 수 있습니다. DANE에는 공개 키 암호화를 사용하여 DNS 조회에 대한 레코드를 디지털 서명하여 작동하는 DNSSEC에 대한 직접 종속성이 있습니다. DNSSEC 검사는 클라이언트에 대한 DNS 쿼리를 만드는 DNS 서버인 재귀 DNS 확인자에서 발생합니다. DNSSEC는 DNS 레코드가 변조되지 않고 정통인지 확인합니다.

도메인에 대한 MX, A/AAAA 및 DNSSEC 관련 리소스 레코드가 DNS 재귀 확인자로 DNS 재귀 확인자로 반환되면 보내는 메일 서버에서 MX 호스트 항목 또는 항목에 해당하는 TLSA 레코드를 요청합니다. TLSA 레코드가 있고 다른 DNSSEC 검사를 사용하여 인증된 것으로 입증된 경우 DNS 재귀 확인자는 TLSA 레코드를 보내는 메일 서버에 반환합니다.

정품 TLSA 레코드가 수신되면 송신 메일 서버는 정품 TLSA 레코드와 연결된 MX 호스트에 대한 SMTP 연결을 설정합니다. 보내는 메일 서버는 TLS를 설정하고 서버의 TLS 인증서를 TLSA 레코드의 데이터와 비교하여 보낸 사람에게 연결된 대상 메일 서버가 합법적인 수신 메일 서버인지 확인합니다. 인증에 성공하면 메시지가 전송됩니다(TLS 사용). 인증이 실패하거나 대상 서버에서 TLS가 지원되지 않는 경우 Exchange Online은 15분 후에 동일한 대상 도메인에 대한 DNS 쿼리로 시작하는 전체 유효성 검사 프로세스를 다시 시도한 다음, 그 후 15분 후에 다음 24시간 동안 매시간 다시 시도합니다. 24시간 재시도 후에도 인증이 계속 실패하면 메시지가 만료되고 오류 세부 정보가 포함된 NDR이 생성되어 보낸 사람에게 전송됩니다.

E5 고객이 아닌 경우 90일 Microsoft Purview 솔루션 평가판을 사용하여 조직이 데이터 보안 및 규정 준수 요구 사항을 관리하는 데 도움이 되는 추가 Purview 기능을 살펴보세요. Microsoft Purview 규정 준수 포털 평가판 허브에서 지금 시작하세요. 등록 및 평가판 조건에 대한 세부 정보를 알아봅니다.

DANE의 구성 요소는 무엇인가요?

TLSA 리소스 레코드

TLSA(TLS 인증) 레코드는 서버의 X.509 인증서 또는 공개 키 값을 레코드가 포함된 도메인 이름과 연결하는 데 사용됩니다. 도메인에서 DNSSEC를 사용하도록 설정한 경우에만 TLSA 레코드를 신뢰할 수 있습니다. DNS 공급자를 사용하여 도메인을 호스트하는 경우 DNSSEC는 도메인을 구성할 때 제공되는 설정일 수 있습니다. DNSSEC 영역 서명에 대한 자세한 내용은 DNSSEC 개요 | 링크를 참조하세요. Microsoft Docs.

TLSA 레코드 예제:

TLSA 레코드 예제

TLSA 레코드 형식에 고유한 4개의 구성 가능한 필드가 있습니다.

인증서 사용 필드: 보내는 전자 메일 서버가 대상 전자 메일 서버의 인증서를 확인하는 방법을 지정합니다.

머리글자어 설명
01 PKIX-TA 사용되는 인증서는 X.509 트러스트 체인의 trust-anchor 공용 CA입니다.
11 PKIX-EE 확인된 인증서는 대상 서버입니다. DNSSEC 검사는 해당 신뢰성을 확인해야 합니다.
2 DANE-TA 신뢰 체인의 트러스트 앵커에 의해 유효성을 검사해야 하는 X.509 트리에서 서버의 프라이빗 키를 사용합니다. TLSA 레코드는 도메인에 대한 TLS 인증서의 유효성을 검사하는 데 사용할 트러스트 앵커를 지정합니다.
3 DANE-EE 대상 서버의 인증서와만 일치합니다.

1 Exchange Online은 SMTP를 사용하여 DANE를 구현할 때 인증서 사용 필드 값 0 또는 1을 사용하면 안 된다는 RFC 구현 지침을 따릅니다. 인증서 사용량 필드 값이 0 또는 1인 TLSA 레코드가 Exchange Online에 반환되면 Exchange Online은 사용할 수 없는 것으로 처리합니다. 모든 TLSA 레코드를 사용할 수 없는 경우 Exchange Online은 전자 메일을 보낼 때 0 또는 1에 대한 DANE 유효성 검사 단계를 수행하지 않습니다. 대신, TLSA 레코드가 있기 때문에 Exchange Online은 대상 전자 메일 서버가 TLS를 지원하거나 대상 전자 메일 서버가 TLS를 지원하지 않는 경우 전자 메일을 보내거나 전자 메일을 삭제하고 NDR을 생성하는 데 TLS를 사용하도록 적용합니다.

예제 TLSA 레코드에서 인증서 사용 필드는 '3'으로 설정되므로 인증서 연결 데이터('abc123... xyz789')는 대상 서버의 인증서와만 일치합니다.

선택기 필드: 대상 서버 인증서의 어느 부분을 확인해야 하는지 나타냅니다.

머리글자어 설명
0 인증서 전체 인증서를 사용합니다.
1 SPKI(주체 공개 키 정보) 인증서의 공개 키 및 사용할 공개 키가 식별되는 알고리즘을 사용합니다.

예제 TLSA 레코드에서 선택기 필드는 '1'로 설정되므로 인증서 연결 데이터는 대상 서버 인증서의 공개 키와 사용할 공개 키가 식별되는 알고리즘을 사용하여 일치합니다.

일치 형식 필드: 인증서가 TLSA 레코드에 표시되는 형식을 나타냅니다.

머리글자어 설명
0 Full TSLA 레코드의 데이터는 전체 인증서 또는 SPKI입니다.
1 SHA-256 TSLA 레코드의 데이터는 인증서 또는 SPKI의 SHA-256 해시입니다.
2 SHA-512 TSLA 레코드의 데이터는 인증서 또는 SPKI의 SHA-512 해시입니다.

예제 TLSA 레코드에서 일치 형식 필드는 '1'로 설정되므로 인증서 연결 데이터는 대상 서버 인증서의 주체 공개 키 정보의 SHA-256 해시입니다.

인증서 연결 데이터: 대상 서버 인증서와 일치하는 데 사용되는 인증서 데이터를 지정합니다. 이 데이터는 선택기 필드 값과 일치하는 형식 값에 따라 달라집니다.

예제 TLSA 레코드에서 인증서 연결 데이터는 'abc123.로 설정됩니다. xyz789'. 예제의 선택기 필드 값은 '1'로 설정되므로 대상 서버 인증서의 공개 키와 함께 사용할 것으로 식별되는 알고리즘을 참조합니다. 또한 예제의 일치 형식 필드 값은 '1'로 설정되므로 대상 서버 인증서에서 주체 공개 키 정보의 SHA-256 해시를 참조합니다.

Exchange Online 고객은 SMTP DANE 아웃바운드를 어떻게 사용할 수 있나요?

Exchange Online 고객으로서 아웃바운드 전자 메일에 대해 이 향상된 전자 메일 보안을 구성하기 위해 수행해야 하는 작업은 없습니다. 이 향상된 전자 메일 보안은 사용자를 위해 빌드된 것이며 기본적으로 모든 Exchange Online 고객에 대해 ON이며 대상 도메인이 DANE에 대한 지원을 보급할 때 사용됩니다. DNSSEC 및 DANE 검사를 사용하여 전자 메일을 보내는 이점을 활용하려면 이러한 표준을 사용하여 이메일을 받을 수 있도록 DNSSEC 및 DANE를 구현해야 하는 전자 메일을 교환하는 비즈니스 파트너와 통신합니다.

Exchange Online 고객은 SMTP DANE 인바운드를 어떻게 사용할 수 있나요?

현재 인바운드 SMTP DANE는 Exchange Online에서 지원되지 않습니다. 인바운드 SMTP DANE에 대한 지원은 조만간 제공될 예정입니다.

SMTP DANE에 대한 RFC 구현 지침에 따라 인증서 사용량 필드가 3으로 설정되고 선택기 필드가 1로 설정되고 일치 형식 필드가 1로 설정된 TLSA 레코드가 권장됩니다.

SMTP DANE를 사용하여 온라인 메일 흐름 교환

아래 흐름 차트에 표시된 SMTP DANE를 사용하는 Exchange Online의 메일 흐름 프로세스는 DNSSEC, 대상 메일 서버의 TLS 지원을 통해 도메인 및 리소스 레코드 보안의 유효성을 검사하고 대상 메일 서버의 인증서가 연결된 TLSA 레코드에 따라 예상되는 인증서와 일치하는지 확인합니다.

SMTP DANE 오류로 인해 이메일이 차단되는 시나리오는 두 가지뿐입니다.

  • 대상 도메인은 DNSSEC 지원에 신호를 보냈지만 하나 이상의 레코드가 인증되지 않은 것으로 반환되었습니다.

  • 대상 도메인에 대한 모든 MX 레코드에는 TLSA 레코드가 있고 대상 서버의 인증서가 TSLA 레코드 데이터에 따라 예상된 것과 일치하지 않거나 대상 서버에서 TLS 연결을 지원하지 않습니다.

SMTP DANE를 사용하여 온라인 메일 흐름 교환

기술 추가 정보
메일 전송 에이전트 - MTA-STS(Strict Transport Security) 는 대상 전자 메일 서버가 TLS를 지원하는지 여부와 TLS를 협상할 수 없을 때 수행할 작업(예: 전송 중지)을 지정하는 도메인 정책을 설정하는 메커니즘을 제공하여 다운그레이드 및 중간 중간 공격을 저지하는 데 도움이 됩니다. 인바운드 및 아웃바운드 MTA-STS에 대한 Exchange Online의 향후 지원에 대한 자세한 내용은 올해 말에 게시될 예정입니다.

Microsoft Ignite 2020의 Exchange Online 전송 뉴스 - Microsoft Tech Community

rfc8461(ietf.org)
SPF(보낸 사람 정책 프레임워크) 는 IP 정보를 사용하여 대상 전자 메일 시스템이 사용자 지정 도메인에서 보낸 메시지를 신뢰하도록 합니다. SPF(보낸 사람 정책 프레임워크)가 스푸핑을 방지하는 방법
DKIM(DomainKeys 식별 메일) 은 X.509 인증서 정보를 사용하여 대상 전자 메일 시스템이 사용자 지정 도메인에서 보낸 아웃바운드 메시지를 신뢰하도록 합니다. 사용자 지정 도메인에서 전자 메일에 DKIM을 사용하는 방법
DMARC(도메인 기반 메시지 인증, 보고 및 규칙) 는 보낸 사람 정책 프레임워크 및 DomainKeys 식별 메일과 함께 작동하여 메일 보낸 사람의 인증을 받고 대상 전자 메일 시스템에서 도메인에서 보낸 메시지를 신뢰하도록 합니다. DMARC를 사용하여 전자 메일, 설정 단계의 유효성 검사

SMTP DANE를 사용하여 전자 메일 보내기 문제 해결

현재 Exchange Online을 사용하여 전자 메일을 보낼 때 DANE에 대한 네 가지 오류 코드가 있습니다. Microsoft는 이 오류 코드 목록을 적극적으로 업데이트하고 있습니다. 오류는 다음에서 표시됩니다.

  1. 메시지 추적 세부 정보 보기를 통해 Exchange 관리 센터 포털.
  2. DANE 또는 DNSSEC 오류로 인해 메시지를 보내지 않을 때 생성된 NDR입니다.
  3. 원격 연결 분석기 도구 Microsoft 원격 연결 분석기.
NDR 코드 설명
4/5.7.321 starttls-not-supported: 대상 메일 서버는 메일을 받으려면 TLS를 지원해야 합니다.
4/5.7.322 인증서 만료: 대상 메일 서버의 인증서가 만료되었습니다.
4/5.7.323 tlsa-invalid: 도메인이 DANE 유효성 검사에 실패했습니다.
4/5.7.324 dnssec-invalid: 대상 도메인이 잘못된 DNSSEC 레코드를 반환했습니다.

참고

현재 도메인이 DNSSEC를 지원하지만 DNSSEC 검사에 실패한다는 신호를 받으면 Exchange Online은 4/5.7.324 dnssec 잘못된 오류를 생성하지 않습니다. 제네릭 DNS 오류가 생성됩니다.

4/5.4.312 DNS query failed

이 알려진 제한을 해결하기 위해 적극적으로 노력하고 있습니다. 이 오류 문이 수신되면 Microsoft 원격 연결 분석기로 이동하여 4/5.4.312 오류를 생성한 도메인에 대해 DANE 유효성 검사 테스트를 수행합니다. 결과는 DNSSEC 문제 또는 다른 DNS 문제인지 여부를 표시합니다.

4/5.7.321 starttls-not-supported 문제 해결

이 오류는 일반적으로 대상 메일 서버의 문제를 나타냅니다. 메시지를 받은 후:

  1. 대상 전자 메일 주소가 올바르게 입력되었는지 확인합니다.
  2. 대상 서버가 TLS를 사용하여 메시지를 받도록 올바르게 구성되어 있는지 확인할 수 있도록 이 오류 코드를 수신했음을 대상 전자 메일 관리자에게 경고합니다.
  3. 전자 메일을 다시 보내고 Exchange 관리 센터 포털에서 메시지에 대한 메시지 추적 세부 정보를 검토합니다.

4/5.7.322 인증서 만료 문제 해결

만료되지 않은 유효한 X.509 인증서를 보내는 전자 메일 서버에 제공해야 합니다. X.509 인증서는 만료 후 일반적으로 매년 갱신해야 합니다. 메시지를 받은 후:

  1. 이 오류 코드를 수신했음을 대상 전자 메일 관리자에게 알리고 오류 코드 문자열을 제공합니다.
  2. 대상 서버 인증서를 갱신하고 새 인증서를 참조하도록 TLSA 레코드를 업데이트할 시간을 허용합니다. 그런 다음, 전자 메일을 다시 보내고 Exchange 관리 센터 포털에서 메시지에 대한 메시지 추적 세부 정보를 검토합니다.

4/5.7.323 tlsa-invalid 문제 해결

이 오류 코드는 TLSA 레코드 구성 오류와 관련이 있으며 DNSSEC 인증 TLSA 레코드가 반환된 후에만 생성할 수 있습니다. 레코드가 반환된 후 발생하는 DANE 유효성 검사 중에 코드가 생성될 수 있는 많은 시나리오가 있습니다. Microsoft는 각 시나리오에 특정 코드가 있도록 이 오류 코드에서 다루는 시나리오를 적극적으로 작업하고 있습니다. 현재 이러한 시나리오 중 하나 이상이 오류 코드를 생성할 수 있습니다.

  1. 대상 메일 서버의 인증서가 인증된 TLSA 레코드에서 예상한 것과 일치하지 않습니다.
  2. 인증 TLSA 레코드가 잘못 구성되었습니다.
  3. 대상 도메인이 공격을 받고 있습니다.
  4. 기타 모든 DANE 실패입니다.

메시지를 받은 후:

  1. 이 오류 코드를 수신했음을 대상 전자 메일 관리자에게 알리고 오류 코드 문자열을 제공합니다.
  2. 대상 전자 메일 관리자가 DANE 구성 및 전자 메일 서버 인증서의 유효성을 검토할 시간을 허용합니다. 그런 다음, 전자 메일을 다시 보내고 Exchange 관리 센터 포털에서 메시지에 대한 메시지 추적 세부 정보를 검토합니다.

4/5.7.324 dnssec-invalid 문제 해결

이 오류 코드는 대상 도메인이 DNSSEC 인증이라고 표시했지만 Exchange Online에서 DNSSEC-authentic로 확인할 수 없을 때 생성됩니다.

메시지를 받은 후:

  1. 이 오류 코드를 수신했음을 대상 전자 메일 관리자에게 알리고 오류 코드 문자열을 제공합니다.
  2. 대상 전자 메일 관리자가 도메인의 DNSSEC 구성을 검토할 시간을 허용합니다. 그런 다음, 전자 메일을 다시 보내고 Exchange 관리 센터 포털에서 메시지에 대한 메시지 추적 세부 정보를 검토합니다.

SMTP DANE를 사용하여 전자 메일 수신 문제 해결

현재 수신 도메인의 관리자가 이러한 표준을 사용하여 Exchange Online에서 전자 메일을 받기 위해 DNSSEC 및 DANE 구성의 유효성을 검사하고 문제를 해결하는 데 사용할 수 있는 두 가지 방법이 있습니다.

  1. RFC8460 도입된 SMTP TLS-RPT(전송 계층 보안 보고) 채택
  2. 원격 연결 분석기 도구 사용 Microsoft 원격 연결 분석기

TLS-RPT https://datatracker.ietf.org/doc/html/rfc8460 는 보낸 사람이 해당 대상 도메인의 DANE 및 MTA-STS 성공 및 실패에 대한 세부 정보를 대상 도메인 관리자에게 제공하는 보고 메커니즘입니다. TLS-RPT 보고서를 받으려면 보고서를 보내려는 이메일 주소 또는 URI를 포함하는 도메인의 DNS 레코드에 TXT 레코드만 추가하면 됩니다. Exchange Online은 TLS-RPT 보고서를 JSON 형식으로 보냅니다.

예제 레코드:

예제 레코드

두 번째 방법은 원격 연결 분석기 Microsoft 원격 연결 분석기를 사용하는 것입니다. 이 분석기는 Exchange Online이 서비스 외부로 전자 메일을 보낼 때 수행하는 DNS 구성에 대해 동일한 DNSSEC 및 DANE 검사를 수행할 수 있습니다. 이 방법은 이러한 표준을 사용하여 Exchange Online에서 전자 메일을 수신하기 위해 구성에서 오류를 해결하는 가장 직접적인 방법입니다.

오류를 해결하는 경우 아래 오류 코드가 생성될 수 있습니다.

NDR 코드 설명
4/5.7.321 starttls-not-supported: 대상 메일 서버는 메일을 받으려면 TLS를 지원해야 합니다.
4/5.7.322 인증서 만료: 대상 메일 서버의 인증서가 만료되었습니다.
4/5.7.323 tlsa-invalid: 도메인이 DANE 유효성 검사에 실패했습니다.
4/5.7.324 dnssec-invalid: 대상 도메인이 잘못된 DNSSEC 레코드를 반환했습니다.

참고

현재 도메인이 DNSSEC를 지원하지만 DNSSEC 검사에 실패한다는 신호를 받으면 Exchange Online은 4/5.7.324 dnssec 잘못된 오류를 생성하지 않습니다. 제네릭 DNS 오류가 생성됩니다.

4/5.4.312 DNS query failed

이 알려진 제한을 해결하기 위해 적극적으로 노력하고 있습니다. 이 오류 문이 수신되면 Microsoft 원격 연결 분석기로 이동하여 4/5.4.312 오류를 생성한 도메인에 대해 DANE 유효성 검사 테스트를 수행합니다. 결과는 DNSSEC 문제 또는 다른 DNS 문제인지 여부를 표시합니다.

4/5.7.321 starttls-not-supported 문제 해결

참고

이러한 단계는 SMTP DANE를 사용하여 Exchange Online에서 전자 메일 수신 문제를 해결하는 전자 메일 관리자를 위한 것입니다.

이 오류는 일반적으로 대상 메일 서버의 문제를 나타냅니다. 원격 연결 분석기에서 연결을 테스트하는 메일 서버입니다. 일반적으로 이 코드를 생성하는 두 가지 시나리오가 있습니다.

  1. 대상 메일 서버는 보안 통신을 전혀 지원하지 않으며 암호화되지 않은 일반 통신을 사용해야 합니다.
  2. 대상 서버가 잘못 구성되고 STARTTLS 명령을 무시합니다.

메시지를 받은 후:

  1. 이메일 주소를 확인합니다.
  2. 문과 연결된 메일 서버를 식별할 수 있도록 오류 문과 연결된 IP 주소를 찾습니다.
  3. 메일 서버의 설정을 확인하여 SMTP 트래픽(일반적으로 포트 25 및 587)을 수신하도록 구성되어 있는지 확인합니다.
  4. 몇 분 정도 기다린 다음 원격 연결 분석기 도구를 사용하여 테스트를 다시 시도합니다.
  5. 그래도 실패하는 경우 TLSA 레코드를 제거하고 원격 연결 분석기 도구를 사용하여 테스트를 다시 실행합니다.
  6. 오류가 없는 경우 이 메시지는 메일을 받는 데 사용하는 메일 서버가 STARTTLS를 지원하지 않으며 DANE를 사용하기 위해 수행하는 메일 서버로 업그레이드해야 할 수 있음을 나타낼 수 있습니다.

4/5.7.322 인증서 만료 문제 해결

참고

이러한 단계는 SMTP DANE를 사용하여 Exchange Online에서 전자 메일 수신 문제를 해결하는 전자 메일 관리자를 위한 것입니다.

만료되지 않은 유효한 X.509 인증서를 보내는 전자 메일 서버에 제공해야 합니다. X.509 인증서는 만료 후 일반적으로 매년 갱신해야 합니다. 메시지를 받은 후:

  1. 연결된 메일 서버를 식별할 수 있도록 오류 문과 연결된 IP를 확인합니다. 식별한 전자 메일 서버에서 만료된 인증서를 찾습니다.
  2. 인증서 공급자의 웹 사이트에 로그인합니다.
  3. 만료된 인증서를 선택하고 지침에 따라 갱신하고 갱신 비용을 지불합니다.
  4. 공급자가 구매를 확인한 후 새 인증서를 다운로드할 수 있습니다.
  5. 연결된 메일 서버에 갱신된 인증서를 설치합니다.
  6. 메일 서버의 연결된 TLSA 레코드를 새 인증서의 데이터로 업데이트합니다.
  7. 적절한 시간을 기다린 후 원격 연결 분석기 도구를 사용하여 테스트를 다시 시도합니다.

4/5.7.323 tlsa-invalid 문제 해결

참고

이러한 단계는 SMTP DANE를 사용하여 Exchange Online에서 전자 메일 수신 문제를 해결하는 전자 메일 관리자를 위한 것입니다.

이 오류 코드는 TLSA 레코드 구성 오류와 관련이 있으며 DNSSEC 인증 TSLA 레코드가 반환된 후에만 생성할 수 있습니다. 그러나 레코드가 반환된 후 발생하는 DANE 유효성 검사 중에 코드가 생성될 수 있는 많은 시나리오가 있습니다. Microsoft는 각 시나리오에 특정 코드가 있도록 이 오류 코드에서 다루는 시나리오를 적극적으로 작업하고 있습니다. 현재 이러한 시나리오 중 하나 이상이 오류 코드를 생성할 수 있습니다.

  1. 인증 TLSA 레코드가 잘못 구성되었습니다.
  2. 인증서가 아직 유효하지 않은 시간/이후 기간 동안 구성되지 않았습니다.
  3. 대상 도메인이 공격을 받고 있습니다.
  4. 기타 모든 DANE 실패입니다.

메시지를 받은 후:

  1. 오류 문과 연결된 IP를 확인하여 연결된 메일 서버를 식별합니다.
  2. 식별된 메일 서버와 연결된 TLSA 레코드를 식별합니다.
  3. TLSA 레코드의 구성을 확인하여 보낸 사람에게 기본 DANE 검사를 수행하라는 신호를 보내고 올바른 인증서 데이터가 TLSA 레코드에 포함되었는지 확인합니다.
    1. 불일치를 위해 레코드를 업데이트해야 하는 경우 몇 분 정도 기다린 다음 원격 연결 분석기 도구를 사용하여 테스트를 다시 실행합니다.
  4. 식별된 메일 서버에서 인증서를 찾습니다.
  5. 인증서가 유효한 기간을 확인합니다. 이후 날짜에 유효성을 시작하도록 설정된 경우 현재 날짜에 대해 갱신해야 합니다.
    1. 인증서 공급자의 웹 사이트에 로그인합니다.
    2. 만료된 인증서를 선택하고 지침에 따라 갱신하고 갱신 비용을 지불합니다.
    3. 공급자가 구매를 확인한 후 새 인증서를 다운로드할 수 있습니다.
    4. 연결된 메일 서버에 갱신된 인증서를 설치합니다.

4/5.7.324 dnssec-invalid 문제 해결

참고

이러한 단계는 SMTP DANE를 사용하여 Exchange Online에서 전자 메일 수신 문제를 해결하는 전자 메일 관리자를 위한 것입니다.

이 오류 코드는 대상 도메인이 DNSSEC 인증이지만 Exchange Online에서 DNSSEC 인증으로 확인할 수 없는 경우 생성됩니다. 이 섹션은 DNSSEC 문제를 해결하는 데 포괄적이지 않으며 도메인이 이전에 DNSSEC 인증을 통과했지만 지금은 그렇지 않은 시나리오에 중점을 둡니다.

메시지를 받은 후:

  1. DNS 공급자(예: GoDaddy)를 사용하는 경우 문제 해결 및 구성 변경 작업을 수행할 수 있도록 DNS 공급자에게 오류를 경고합니다.
  2. 자체 DNSSEC 인프라를 관리하는 경우 이 오류 메시지를 생성할 수 있는 많은 DNSSEC 잘못된 구성이 있습니다. 영역이 이전에 DNSSEC 인증을 전달했는지 확인하는 몇 가지 일반적인 문제:
    1. 부모 영역에 자식 영역에 존재하지 않는 항목을 가리키는 DS 레코드 집합이 있는 경우 트러스트 체인이 끊어졌습니다. DS 레코드의 이러한 포인터는 확인자의 유효성을 검사하여 자식 영역이 가짜로 표시될 수 있습니다.
      • 자식 도메인 RRSIG 키 ID를 검토하고 부모 영역에 게시된 DS 레코드의 키 ID와 일치하는지 확인합니다.
    2. 도메인에 대한 RRSIG 리소스 레코드가 유효하지 않거나 만료되었거나 유효 기간이 시작되지 않았습니다.
      • 유효한 시간 범위를 사용하여 도메인에 대한 새 서명을 생성하여 해결합니다.

참고

이 오류 코드는 Exchange Online이 대상 도메인에 대한 TLSA 쿼리의 DNS 서버에서 SERVFAIL 응답을 수신하는 경우에도 생성됩니다.

아웃바운드 전자 메일을 보낼 때 수신 도메인에 DNSSEC가 사용하도록 설정된 경우 도메인의 MX 항목과 연결된 TLSA 레코드를 쿼리합니다. TLSA 레코드가 게시되지 않은 경우 TLSA 조회에 대한 응답은 NOERROR(이 도메인에 대해 요청된 형식의 레코드 없음) 또는 NXDOMAIN(이러한 도메인이 없음)이어야 합니다. DNSSEC에는 TLSA 레코드가 게시되지 않은 경우 이 응답이 필요합니다. 그렇지 않으면 Exchange Online은 응답 부족을 SERVFAIL 오류로 해석합니다. RFC 7672에 따라 SERVFAIL 응답은 신뢰할 수 없으며 따라서 대상 도메인이 DNSSEC 유효성 검사에 실패합니다. 이 전자 메일은 다음 오류와 함께 지연됩니다.

450 4.7.324 dnssec-invalid: Destination domain returned invalid DNSSEC records

전자 메일 보낸 사람에서 메시지 수신을 보고하는 경우

DNS 공급자(예: GoDaddy)를 사용하는 경우 DNS 공급자에게 DNS 응답 문제를 해결할 수 있도록 오류를 경고합니다. 자체 DNSSEC 인프라를 관리하는 경우 DNS 서버 자체 또는 네트워크에 문제가 있을 수 있습니다.

질문과 대답

Exchange Online 고객으로서 DNSSEC 및/또는 DANE 사용을 옵트아웃할 수 있나요?

우리는 DNSSEC 및 DANE가 서비스의 보안 위치를 크게 높이고 모든 고객에게 이익이 될 것이라고 강력히 믿습니다. Microsoft는 지난 1년 동안 이 배포가 Microsoft 365 고객에게 미칠 수 있는 잠재적 영향의 위험과 심각도를 줄이기 위해 부지런히 노력했습니다. 배포가 출시될 때 부정적인 영향을 최소화할 수 있도록 배포를 적극적으로 모니터링하고 추적합니다. 이로 인해 테넌트 수준 예외 또는 옵트아웃을 사용할 수 없습니다. DNSSEC 및/또는 DANE 사용과 관련된 문제가 발생하는 경우 이 문서에 설명된 오류를 조사하는 다양한 방법이 오류의 원인을 식별하는 데 도움이 됩니다. 대부분의 경우 문제는 외부 대상 당사자와 관련이 있으며 이러한 표준을 사용하여 Exchange Online에서 전자 메일을 수신하기 위해 DNSSEC 및 DANE를 올바르게 구성해야 함을 이러한 비즈니스 파트너와 통신해야 합니다.

DNSSEC는 DANE와 어떤 관련이 있나요?

DNSSEC는 공개 키 인프라를 적용하여 DNS 쿼리에 대한 응답으로 반환된 레코드가 정품인지 확인하여 DNS 확인에 신뢰 계층을 추가합니다. DANE는 수신 메일 서버가 정품 MX 레코드에 대해 합법적이고 예상되는 메일 서버인지 확인합니다.

SMTP용 MTA-STS와 DANE의 차이점은 무엇인가요?

DANE 및 MTA-STS는 동일한 용도로 사용되지만, MTA-STS는 인증 기관을 사용하는 동안 DANE에는 DNS 인증에 DNSSEC가 필요합니다.

기회 TLS가 충분하지 않은 이유는 무엇인가요?

기회적 TLS는 두 엔드포인트가 모두 지원하는 데 동의하는 경우 두 엔드포인트 간의 통신을 암호화합니다. 그러나 TLS가 전송을 암호화하더라도 도메인에 대한 실제 엔드포인트 대신 악의적인 행위자의 엔드포인트를 가리키도록 DNS 확인 중에 도메인을 스푸핑할 수 있습니다. 이 스푸핑은 DNSSEC를 사용하여 MTA-STS 및/또는 SMTP DANE를 구현하여 해결되는 이메일 보안의 차이입니다.

DNSSEC가 충분하지 않은 이유는 무엇인가요?

DNSSEC는 메일 흐름 시나리오에 대한 중간자 공격 및 다운그레이드(TLS에서 텍스트 지우기) 공격에 완전히 저항하지 않습니다. DNSSEC와 함께 MTA-STS 및 DANE를 추가하면 MITM 및 다운그레이드 공격을 모두 저지하는 포괄적인 보안 방법이 제공됩니다.

도메인 또는 DNS 레코드를 추가한 후 문제 찾기 및 해결

DNSSEC 개요 | Microsoft Docs

DMARC를 사용하여 전자 메일 유효성 검사, 설정 단계 - Office 365 | Microsoft Docs

사용자 지정 도메인에서 전자 메일에 DKIM을 사용하는 방법 - Office 365 | Microsoft Docs

SPF(보낸 사람 정책 프레임워크)에서 스푸핑을 방지하는 방법 - Office 365 | Microsoft Docs

Microsoft Ignite 2020의 Exchange Online 전송 뉴스 - Microsoft Tech Community

rfc8461(ietf.org)