DKIM 검증은 DNS 통해 공개 검증 자료를 검색하는 것에 달려 있습니다. 서명은 암호화 방식으로 잘 구성되어 있지만 관련 조회를 사용할 수 없는 경우 확인할 수 없는 상태로 남아 있을 수 있습니다. 키를 교체하거나 메시지 내용을 변경하기 전에 DNS 경로와 수신자의 시도 시간을 조사하세요.
사고 후 성공적인 조회는 유용한 복구 증거이지만 실패한 시도 중에 발생한 일을 입증하지는 않습니다. 원래 인증 결과, 메시지, 타임스탬프 및 사용 가능한 확인자 로그를 보존합니다. 목표는 보유하지 않은 수신기의 인프라에 대한 가시성을 주장하지 않고 관찰된 오류를 설명하는 것입니다.
정확한 조회 및 결과 설정
영향을 받은 곳에서 d와 s를 읽습니다. DKIM-Signature 그리고 구성 선택자 d의 _domainkey 에서 조회합니다. 아래에 RFC 6376 §3.6.2.1 그리고 RFC 1034 §3.6.2, 지원되는 설정이 CNAME, 체인 및 최종 확인 답변을 캡처합니다. 가능한 경우 응답 코드, 시간, 확인자 및 권한 있는 서버를 포함하세요.
RFC 6376 §6.1.2 응답하지 않는 쿼리와 존재하지 않는 키 레코드를 구별합니다. 전자는 TEMPFAIL을 생성하고 이후 시도를 수행할 수 있습니다. 후자는 해당 서명에 대해 키가 없는 PERMFAIL이 필요합니다. RFC 8601 §2.7.1 temperror 마찬가지로 일시적인 확인 오류가 발생할 수 있음을 설명합니다. 모든 DNS 관련 오류를 하나의 기록 누락 진단으로 전환하지 마십시오.
과장하지 않고 조회수를 비교하세요.
권한 있는 영역과 대표 재귀 확인자를 확인하세요. 차이점은 오래된 캐시 데이터, 위임 불일치 또는 DNS 경로의 일부에 도달하는 문제를 가리킬 수 있습니다. 공급자 관리 대상이 관련된 경우 해당 대상과 고객 제어 별칭을 조사하십시오.
오류 레이블에서만 하나를 선택하는 대신 잠재적인 원인에 대한 증거를 기록하십시오. 예를 들어 확인자의 SERVFAIL 추가 진단이 필요합니다. 이는 키가 삭제되었다는 증거가 아닙니다. DNSSEC 검증(참조 RFC 4035 §5.5), 위임 및 전송 문제에는 DNS 운영자의 로그와 전문 지식이 필요할 수 있습니다. 단순히 한 번의 조회를 성공시키기 위한 기본 수정 사항으로 유효성 검사를 비활성화하지 마십시오.
시간 기반 예시를 따르세요.
예시 순서: 수신기는 10시에 active1._domainkey.sender.example 검색하려고 시도하고 임시 키 검색 오류를 보고합니다. 10시 5분에 관리자는 다른 확인자로부터 유효한 키를 검색합니다. 두 가지 관찰이 모두 사실일 수 있습니다. 두 번째는 5분 전 첫 번째 수신자에 대한 가용성이 아니라 10:05에 해당 쿼리에 대한 가용성을 설정합니다.
이와 대조적으로, 사고 당시 신뢰할 수 있는 답변을 통해 활성 선택기가 없다고 확인된 경우 일시적인 중단이 해결될 때까지 기다리면 구성 문제가 해결되지 않을 수 있습니다. 기록이 복원되면 다음의 네거티브 캐싱이 수행됩니다. RFC 2308 §5 다른 확인자가 이를 관찰하는 경우에도 영향을 미칠 수 있습니다. 이 예는 측정된 중단이나 약속된 복구 간격이 아닌 진단 타임라인입니다.
복구 후 나머지 검증 확인
수행원 RFC 6376 §6.1.2 그리고 RFC 6376 §6.1.3, 키 검색이 작동하면 반환된 레코드가 사용 가능하고 서명자와 일치하는지 확인하세요. 검색된 키는 여전히 취소되거나, 형식이 잘못되었거나, 호환되지 않을 수 있습니다. 일치하는 키는 서명 후 수정된 콘텐츠를 보상할 수 없습니다. 조회, 키 검증, 본문 해시 검증 및 서명 검증을 사고 기록의 별도 단계로 유지하십시오.
여러 서명이 존재하는 경우 한 번의 조회 실패로 인해 정렬된 모든 인증 경로가 반드시 제거되는 것은 아닙니다. 아래에 RFC 9989 §5.3.5, 다른 서명을 검사하고 SPF 결론을 내리기 전에 DMARC 실패한. 아래에 RFC 6376 §6.3 그리고 RFC 9989 §5.4, 수신기 배달 정책은 또 다른 별도의 결정입니다. 일시적인 DKIM 문제는 연기 또는 수락을 보장하지 않습니다.
통제된 테스트로 중단을 해결하세요
DNS 운영자의 승인된 복구 후 관련 뷰를 통해 영향을 받은 조회를 테스트하고 원래 경로를 통해 새 메시지를 보냅니다. 예상된 결과와 관찰된 결과를 기록합니다. 원인이 관리 범위를 벗어나는 경우 DNS 및 공급자 사고 증거를 요청하십시오.
다음 경고가 올바른 팀에 전달될 수 있도록 위임된 선택기 대상 및 해당 소유자의 인벤토리를 유지합니다. 실제로 실패한 종속성을 모니터링하되 모니터링 범위를 솔직하게 설명하세요. 정기적인 공개 쿼리는 모든 수신자의 캐시, 네트워크 또는 유효성 검사 동작을 재현하지 않습니다. 종결에는 무엇이 회복되었는지, 진단을 뒷받침하는 증거는 무엇인지, 아직 관찰되지 않은 것은 무엇인지 명시해야 합니다.
제한된 결론 유지
10:00 실패와 10:05 성공을 각각 확인자, 쿼리 이름, 결과 및 가시성 제한이 포함된 두 개의 레코드로 유지합니다. 5분 간격은 예시일 뿐 회복 목표는 아닙니다. DNS TTL은 전체 해지 기한이 아닌 새로 고침 간격입니다. RFC 8767 §4 적격한 오래된 사용을 허용합니다. 리졸버 중단, 복구 또는 메일 테스트는 측정되지 않았습니다.