언제 DKIM 키가 DNS 제어판에 표시되지만 확인에 실패하면 확인기가 실제로 검색하는 답변을 검사합니다. 스크린샷은 잘린 값, 중복된 도메인 접미사 또는 여러 개의 독립적인 기록을 숨길 수 있습니다. 임무는 서명자를 변경하기 전에 정확한 소유자 이름과 키 바이트를 설정하는 것입니다.
받은 서명에서 시작
읽다 d= 그리고 s= 영향을받은 것으로부터 DKIM-Signature. 조회 이름은 이를 다음과 같이 결합합니다. 선택자. _domainkey.signing-domain. 다음과 같은 합성 메시지 d=example.com 그리고 s=notify 따라서 사용 notify._domainkey.example.com. 다음 위치에 게시된 키 notifications._domainkey.example.com 수리하지 않습니다.
서명의 알고리즘과 수신자의 정확한 이유를 기록하세요. 누락된 키, 잘못된 키, 부적합한 알고리즘, 서명 불일치, 본문-해시 불일치는 서로 바꿔서 사용할 수 없는 진단입니다. 여러 서명이 있는 경우 선택기와 결과를 별도로 유지하세요.
하나의 TXT 레코드를 올바르게 재구성
DNS TXT 레코드 여러 문자열을 포함할 수 있습니다. RFC 6376 §3.6.2.2 사용하기 전에 공백을 추가하지 않고 단일 레코드 내의 해당 문자열을 연결해야 합니다. 하나의 레코드에 있는 여러 문자열에 걸쳐 긴 키를 분할하는 것은 각각 하나의 조각을 포함하는 여러 TXT 레코드를 생성하는 것과 다릅니다. 후자는 하나의 DKIM 키를 게시하는 안전한 방법이 아닙니다. 섹션 3.6.2.2 에는 고유한 TXT 레코드가 필요합니다. 선택자 다중 레코드 결과를 정의되지 않은 상태로 둡니다. 섹션 6.1.2의 검증자 선택은 조각을 구성 가능하게 만들지 않습니다.
DNS 도구에 표시된 인용 청크는 레코드의 표현입니다. 표시 따옴표가 문자 그대로의 키 바이트라고 가정하지 말고 DNS 인터페이스에서 문자를 무분별하게 제거하지 마십시오. 지원되는 항목 형식에 따라 권한 있는 DNS 쿼리하고 재구성된 값을 생성된 공개 값과 비교합니다. RFC 1035 §3.3.14 TXT 문자열 표현을 정의합니다.
인터페이스 제한의 잘림, 붙여넣은 줄 레이블, 구분 기호 누락, 실수로 base64 값을 편집했는지 검사합니다. 긴 레코드에는 처음과 마지막 몇 문자를 육안으로 검사하는 것이 아니라 정확한 비교가 필요합니다. 해당 비교를 위해 원래 생성된 공개 값을 유지합니다. 개인 키 파일을 대체하지 마십시오.
태그와 키 자료를 함께 검증하세요
아래에 RFC 6376 §3.6.1, p= 태그는 공개 키 데이터를 전달합니다. 값이 비어 있으면 설정이 부분적으로 완료된 것이 아니라 취소되었음을 의미합니다. 그만큼 k= 태그는 RFC 6376 에서 RSA를 기본값으로 사용하여 키 유형을 식별합니다. Ed25519 다음에 의해 정의된 확장자를 사용합니다. RFC 8463 §4.2. RFC 6376 섹션 3.6.1은 공식적으로 키 레코드를 표시합니다. v= RECOMMENDED 태그를 지정하세요. 태그가 없을 경우 DKIM1 기본값으로 사용됩니다. 포함된 경우 첫 번째 태그여야 하며 해당 값은 정확히 DKIM1 이어야 합니다. 해당 값은 대소문자를 구분합니다.
유지 관리되는 DKIM 인식 유효성 검사기를 사용하여 전체 기록을 구문 분석하고 디코딩된 공개 자료가 명시된 키 유형에 적합한지 확인하세요. 유효한 base64만으로는 콘텐츠가 적합한 RSA 또는 Ed25519 공개 키임을 증명할 수 없습니다. 마찬가지로 구문적으로 유효한 레코드는 활성 개인 서명자의 잘못된 공개 키를 보유할 수 있습니다.
서명 계층에서 발행 계층을 분리합니다.
예시적인 실패에는 다음이 포함됩니다. 2048비트 RSA 공개 키가 두 개의 별도 TXT 레코드에 복사되었습니다. DNS 공급자가 지원하는 다중 문자열 단일 레코드 형식으로 표현을 복구한 다음 답변을 다시 읽어보세요. 원인과 보안 영향을 검토하지 않고 인터페이스 오류를 침묵시키기 위해 키를 단축하지 마십시오.
올바른 공개 키가 그대로 확인되었지만 메시지가 여전히 실패하는 경우 활성 선택기 매핑, 일치하는 키 쌍, 알고리즘 및 서명된 메시지 변경 사항을 조사하세요. 증거가 다른 곳을 가리키는 동안 동일한 DNS 데이터를 계속해서 다시 게시하지 마십시오. 공급자가 관리하는 CNAME 최종 주요 기록을 추적해야 합니다. 일반 구문 해결 방법으로 로컬 복사본으로 대체해서는 안 됩니다.
새로운 메시지로 수리를 증명하세요
캐시된 오래되었거나 반복적인 결과를 고려하여 신뢰할 수 있고 반복적인 결과를 기록합니다. 부정적인 답변. 영향을 받는 응용 프로그램을 통해 전송하고 신뢰할 수 있는 수신자의 결과를 검사합니다. 수정된 소유자 이름, 재구성된 공개 값 또는 해당 다이제스트, 생성된 값 비교 및 테스트 증거를 유지합니다. 단지 DNS 편집자가 양식을 수락할 때가 아니라 검색된 키와 실제 서명자가 동의하면 복구가 완료됩니다.
실제 키 없이 구조 확인
예시적인 단일 레코드 프레젠테이션: " v=DKIM1; k=rsa; p=AB" "CD". 연결하면 v=DKIM1; k=rsa; p=ABCD, AB와 CD 사이에 공백이 삽입되지 않았습니다. ABCD는 의도적으로 유효한 사용 가능한 RSA 공개 키가 아닙니다. 이 예는 TXT 구조만 보여주기 때문에 게시해서는 안 됩니다. p=AB 로 끝나고 CD를 포함하는 두 개의 별도 레코드는 동일하지 않습니다. 실제 생성된 값을 재구성한 후에도 DKIM 인식 파서는 태그와 디코딩된 키 자료의 유효성을 검사해야 합니다.
관련 독서
DKIM TXT 및 CNAME 게시: 공급자의 키 관리 모델을 따릅니다. · DKIM 키 길이 및 알고리즘: 현재 수신기 지원을 확인하세요..