아래에 RFC 9989 §9.2, 임시 DMARC 오류는 평가에서 나중에 해결될 수 있는 문제가 발생했음을 의미합니다. 도메인에 정책이 없거나 합법적인 메일이 인증에 실패했다는 의미는 아닙니다.
결과를 해결 조사의 시작으로 간주합니다. 어떤 필수 조회가 실패했는지, 데이터가 해당 권한에 존재하는지 여부, 수신 시스템이 사용 가능한 응답을 얻지 못하게 방해한 요소를 확인합니다.
실패한 평가 캡처
신뢰할 수 있는 전체 결과 또는 반환된 SMTP 응답, 시간, 보낸 도메인 및 전송 경로를 저장합니다. 오류가 속한 인증 방법을 기록해 두십시오. 임시 SPF 또는 DKIM 문제는 dmarc=와 자동으로 동일하지 않습니다.temperror.
로그에 노출될 때 정확한 조회 이름과 레코드 유형을 유지합니다. 정책 TXT 쿼리, SPF 종속성 및 DKIM 선택기 조회에는 다양한 이름과 권한이 포함될 수 있습니다. 도메인 루트만 테스트하면 실패한 종속성을 놓칠 수 있습니다.
변경하기 전에 작은 증거 패킷을 보존하십시오. 반복된 쿼리는 사고 이후에 성공할 수 있으므로 이후의 정상적인 답변이 원래 실패 기록을 대체할 수 없습니다.
대응 기반 결정 경로 따르기
이는 DNS 상태에서 하나의 이메일 처리로의 보편적인 매핑이 아닌 진단 결정 테이블입니다.
- 쿼리 관찰: NOERROR와 관련된 완전한 답변; 설정 내용: 해당 쿼리는 당시 사용 가능한 데이터를 반환했습니다. 다음 조사: 수신자의 이전 관찰과 비교
- 쿼리 관찰: 데이터 없는 응답을 완료합니다. 설정 내용: 요청한 레코드 세트를 해당 응답 컨텍스트에서 찾을 수 없습니다. 다음 조사: 정확한 이름, 권한, 별칭 및 검색 확인
- 쿼리 관찰: 별칭 복잡도가 없는 NXDOMAIN ; 설정 내용: 쿼리된 소유자 이름이 존재하지 않습니다. 다음 조사: 쿼리 범위 및 적용 가능한 대체 확인
- 쿼리 관찰: SERVFAIL ; 설정 내용: 해결이 성공적으로 완료되지 않았습니다. 다음 조사: 권한, 위임, 유효성 검사 및 확인자 로그 검사
- 쿼리 관찰: 거부됨; 설정 내용: 서버가 쿼리를 거부했습니다. 다음 조사: 쿼리 정책 및 서버의 의도된 역할 확인
- 쿼리 관찰: 시간 초과; 설정 내용: 시도 제한 내에서 사용 가능한 응답이 도착하지 않았습니다. 다음 조사: 연결 가능성, 전송, 손실 및 서버 상태 확인
DNS 응답 코드는 다음과 같이 정의됩니다. RFC 1035 §4.1.1; 부정적인 답변 RFC 2308 §2.1 그리고 RFC 2308 §2.2. _dmarc.example.com 에 대한 쿼리는 해당 소유자 이름과 관련됩니다. 부정적인 대답 자체가 example.com 존재하지 않는다는 것을 입증하지는 않습니다. 부재를 원래 쿼리된 이름에 귀속시키기 전에 별칭 체인을 따르십시오.
신뢰할 수 있는 경로와 재귀 경로 비교
먼저 위임된 하위 도메인을 포함하여 올바른 권한 있는 서버를 식별합니다. 각 기관에서 해당 명칭을 테스트하고 답변을 비교해 보세요. 당국이 동의하지 않는 경우 해당 구역의 서비스 제공 상태와 최근 변경 사항을 조사하세요.
그런 다음 증거를 사용할 수 있는 영향을 받는 수신 시스템에서 사용되는 재귀 경로를 검사합니다. 쿼리 시간, 상태, 답변 및 TTL을 비교합니다. 운영자의 로컬 확인자와 원격 수신기는 서로 다른 캐시 또는 유효성 검사 상태를 가질 수 있습니다.
다음 가상의 축약된 성적표는 비교를 보여줍니다.
14:02 UTC | 재귀 리졸버 R | _dmarc.example.com TXT | SERVFAIL 14:04 UTC | 권한 있는 서버 A | 같은 이름/유형 | NOERROR, 정책이 14:04 UTC를 반환했습니다. | 권한 있는 서버 B | 같은 이름/유형 | NOERROR, 정책이 14:09 UTC를 반환했습니다. | 수리 조사 후 리졸버 R | 같은 이름/유형 | 노에러이러한 관찰은 재귀 또는 개입 경로에 대한 조사 범위를 좁힙니다. 로그 없이는 원인을 증명할 수 없으며 모든 수신자가 경험한 내용을 입증하지도 않습니다.
조사에 DNSSEC 검증 포함
아래에 RFC 4035 §5.5, 검증 확인자는 실패한 데이터를 거부할 수 있습니다. DNSSEC 권한 있는 서버에 대한 직접 쿼리가 텍스트를 반환하는 경우에도 유효성 검사가 가능합니다. 담당 DNS 팀이 지원하는 도구와 로그를 사용하여 키 또는 서명 변경을 포함한 위임 및 검증 증거를 확인하세요.
기관의 직접적인 답변 자체가 수신자의 검증 결정을 재현하지는 않습니다. 마찬가지로 하나의 SERVFAIL DNSSEC 문제를 증명하지 않습니다. 여러 가지 원인이 있을 수 있습니다.
확립된 검증 결함이 있는 경우 수정합니다. 증상을 숨기기 위해 유효성 검사를 비활성화한다고 해서 의도한 보안 해결 경로가 복구되었다는 증거는 아닙니다.
해당되는 경우 UDP와 TCP를 모두 테스트하세요.
DNS 전송이 실패의 일부일 수 있습니다. 작은 UDP 쿼리가 성공한다고 해서 더 큰 응답, 잘린 응답 재시도 또는 TCP가 동일한 경로를 따라 작동한다는 사실은 입증되지 않습니다.
RFC 7766 RFC 7766 §5 UDP와 TCP를 모두 지원하려면 범용 DNS 구현이 필요합니다. 연결 가능성이나 크기 관련 오류를 진단할 때 각 전송에 대해 관련 이름과 유형을 비교하세요. 모든 시간 초과의 원인이 동일하다고 가정하기보다는 잘림 플래그와 네트워크 증거를 검사하십시오.
운송 테스트는 진단 관찰입니다. 검토된 설계 없이 의도된 해결 프로그램이나 검증 경로를 우회하는 프로덕션 해결 방법으로 전환되어서는 안 됩니다.
부재 및 실패한 해결 방법을 별도로 유지
아래에 RFC 2308 §5, 긍정적인 데이터와 마찬가지로 부정적인 답변도 캐시될 수 있습니다. 새로 추가된 레코드는 이전 부정 캐시 상태가 만료될 때까지 재귀 보기에 없는 상태로 남아 있을 수 있습니다. 이는 권한 있는 서버에 연결할 수 없는 것과는 다릅니다.
관찰된 오류가 임시 오류로 분류된 상태로 유지되는 동안 구성 결함이 지속될 수도 있습니다. "임시"는 평가 범주를 설명하는 것이지 기다리면 손상된 위임이나 서명이 복구된다는 약속이 아닙니다.
사용 분실기록 안내 결석이 확인된 경우 및 출판 작업 흐름 실제 이름과 권한을 확인합니다.
정책을 재검토하기 전에 복구 확인
현재의 RFC 9989 §4.10.1 정책 조회 DNS 오류 처리는 수신자에게 맡깁니다. 평가지침은 RFC 9989 §5.3.6 DNS 오류로 인해 필수 DNS 쿼리가 완료되지 않았으며 DMARC 통과 또는 실패를 설정하지 못하며 해당 불완전한 결과에 도메인 소유자 평가 정책을 적용할 수 없다고 말합니다. 수신기 처리는 여전히 다를 수 있습니다.
p를 변경해도 연결할 수 없는 필수 조회는 복구되지 않습니다. 먼저 사용 가능한 해상도를 복원한 다음 동일한 경로를 다시 테스트하고 새로운 방법별 결과를 검사하십시오. 비즈니스 복구 결정을 별도의 범위 변경으로 유지합니다.
최종 기록에서는 실패한 종속성, 확립된 원인, 수리 및 복구 후 수신자 증거를 식별해야 합니다. 이를 통해 작업 정책을 반사적으로 약화시키지 않고도 다음 간헐적인 실패를 더 쉽게 진단할 수 있습니다.
결정과 증거를 분리하여 보관하십시오.
가상의 14:02~14:09 성적표의 경우 인증 성공 범위가 좁아지지만 실패한 구성 요소를 식별하지는 않습니다. DNSSEC , 전송 또는 특정 서버를 원인으로 지정하기 전에 실제 확인자 또는 네트워크 검색이 필요합니다. RFC 8767 §4 적격한 오래된 답변 사용을 허용합니다. 신선함만으로는 보편적인 중단이나 복구 시계가 아닙니다. 이러한 관찰은 수행된 테스트가 아니라 교육 도구를 고안한 것입니다.