[ DKIM ]

DKIM 키를 취소하고 누락된 DNS 레코드와 취소를 구별합니다.

DNS 및 서명 증거를 사용하여 진단 이유와 인증 결과를 혼동하지 않고 의도적인 해지와 누락된 키를 구별합니다.

EmailAuth 연구팀 제공

[ 핵심사항 ]

  • 빈 p 값은 키를 취소합니다. 누락된 키와 취소된 키는 모두 해당 키를 사용한 확인을 방지합니다.
  • 응답하지 않는 DNS 쿼리와 별도로 영구적인 키 없음/취소된 결과를 유지합니다.
  • 서명자 액세스를 포함하고 손상된 키를 교체합니다. DNS 만으로는 서명자를 보호하지 못합니다.
이 페이지에서

취소된 DKIM 키와 누락된 키 기록은 운영자에게 다른 정보를 제공할 수 있지만 둘 다 사용 가능한 확인 키를 제공하지 않습니다. RFC 6376 §3.1 키를 취소하는 것과 서명 확인을 위해 해당 레코드를 제거하는 것 사이에 의미상 차이가 없음을 명시적으로 정의합니다. 가동 중단을 진단하거나 손상에 대응할 때 이러한 구별을 유지하십시오.

다양한 관찰을 인식

DKIM 키 레코드에서 비어 있는 p= 값은 취소를 나타냅니다. 구문적으로 적합한 예시적인 RSA 취소 값은 다음과 같습니다. v=DKIM1; k=rsa; p=. 여기에는 개인 키가 포함되어 있지 않으며 대체 키가 아닙니다. 정확한 것을 사용하세요 선택자 영향을 받은 서명에서 소유자 이름을 찾아 플랫폼에서 지원되는 프로세스를 따릅니다.

키 레코드가 존재하지 않는 경우, RFC 6376 §6.1.2 특별한 이유 없이 영구적인 실패를 요구합니다. 공개 키 값이 비어 있으면 키 취소로 인해 영구적인 오류가 발생합니다. 응답하지 못하는 DNS 쿼리는 다른 조건이며 일시적인 오류를 일으킬 수 있습니다. 모든 조회 문제 취소를 호출하지 마세요.

운영 의도에는 여전히 증거가 필요합니다. 빈 키는 승인된 긴급 변경이거나 게시 실수일 수 있습니다. 누락된 기록은 의도적인 폐기, 잘못된 선택 또는 우발적인 삭제를 반영할 수 있습니다. 원인을 규명하기 전에 신뢰할 수 있는 DNS 상태, 반복 응답, 타임스탬프 및 승인된 변경 내역을 비교하세요.

사건에 따른 대응을 선택하세요

정기적인 폐기의 경우 합법적으로 지연된 메시지에 여전히 이전 공개 키가 필요할 수 있는 기간에 맞춰 서명 종료를 조정하세요. 개인 키 손상이 의심되는 경우 연속성과 억제가 충돌할 수 있습니다. 인시던트 프로세스를 호출하고 변경을 승인할 수 있는 사람을 설정하고 선택한 대응이 비례적인 이유를 문서화합니다.

취소는 캐시 전체에서 즉시 이루어지지 않습니다. RFC 1034 §3.6 캐시된 레코드의 TTL을 설명합니다. 확인자는 캐시 수명이 끝날 때까지 이전의 긍정적인 데이터를 유지할 수 있습니다. 사고 후 TTL을 줄여도 캐시된 모든 복사본이 소급하여 단축되지는 않습니다. 일부 해석기는 오래된 데이터를 다음과 같이 제공할 수 있습니다. RFC 8767 §4 새로 고침을 사용할 수 없는 경우 이전 TTL은 전 세계적으로 절대적인 취소 기한이 아닙니다. DNS 편집으로 인해 이전 답변을 사용한 모든 후속 확인이 즉시 방지된다고 주장하지 마십시오.

손상된 서명자를 중지하는 것과 무단 액세스를 제한하는 것은 별도의 작업입니다. DNS 변경만으로는 유출된 개인 키를 복구하거나 이를 노출한 계정을 보호할 수 없습니다. RFC 6376 §8.3 서명 키가 손상될 위험에 대해 설명합니다. 공급자 관리형 CNAME의 경우 최종 주요 데이터를 제어하는 ​​사람과 영향을 받는 선택기를 폐기하는 지원되는 작업을 식별합니다. 충돌하는 내용을 추가하지 마세요. TXT 레코드 즉석 수정으로 별칭과 함께; 보다 RFC 1034 §3.6.2.

증거 중심 사례 작업

합성 사고에서 메시지는 다음을 사용합니다. d=example.com; s=oldbilling. 이제 신뢰할 수 있는 답변에 빈 내용이 포함됩니다. p=, 하나의 재귀 확인자는 여전히 이전 공개 키를 반환합니다. 사건 기록에는 승인된 취소가 표시됩니다. 이는 캐시 전환 설명을 지원합니다. 모든 수신자가 이미 이전 서명의 유효성 검사를 중지했음을 입증하지는 않습니다.

두 번째 테스트에서는 s=old-billing, 의도한 선택자에 하이픈이 없습니다. 해당 이름의 기록이 없습니다. 조회 실패는 실제이지만 의도한 선택기가 취소되었음을 증명하지는 않습니다. 정확한 명칭은 이 두 사건이 하나의 사건으로 축소되는 것을 방지합니다.

노출을 복원하지 않고 교체 확인

지속적인 전송이 승인된 경우 안전하게 생성된 새 키와 지원되는 선택기 전환을 사용하세요. 신뢰할 수 있는 게시를 확인하고 영향을 받는 각 응용 프로그램에서 받은 테스트를 검사합니다. 복구 스크립트, 활성 서명자에게 복원된 백업, 복사된 구성 템플릿에서 손상된 키를 보관하세요.

자동 롤백 대상이 아닌 접근이 제한된 사고 증거로 이전 구성을 보존합니다. 손상된 서명 비밀을 복원하는 롤백으로 문제가 재현될 수 있습니다. 변경 권한, 영향을 받은 선택자, 격리 조치, 캐시 관찰 및 새 서명 증거에 대한 권한으로 사건을 종료합니다. 의도적으로 확인이 희생된 오래된 합법적인 메시지를 기록하십시오.

작업을 선택하기 전에 조회를 분류하세요.

실제 도메인의 결과가 아닌 합성 진단 분기로 다음을 사용하십시오.

  • 완전 일치 선택기는 빈 p 값을 반환합니다. 즉, 키가 명시적으로 취소됩니다. RFC 6376 에는 PERMFAIL(키 취소됨)이 필요합니다.
  • 정확한 선택기에는 키 레코드가 없습니다. RFC 6376 에는 PERMFAIL이 필요합니다(서명을 위한 키 없음). 철자, 위임 및 승인된 퇴직 내역을 확인하세요.
  • 쿼리가 응답을 받지 못합니다. RFC 6376 TEMPFAIL(키 사용 불가)을 허용합니다. 이 관찰만으로는 철회가 입증되지 않습니다.

이러한 결과는 해당 서명과 관련이 있습니다. 다른 서명과 그 결과를 별도로 보존합니다. 메시지에는 다른 인증 경로가 있을 수 있습니다.

DKIM DNS 위임: 공급자에게 부여된 제어 범위를 평가합니다. · 서명 시스템 전반에 걸쳐 DKIM 개인 키를 저장하고 보호합니다..

[ 테이크아웃 ]

빈 p 값은 키를 취소합니다. 누락된 키와 취소된 키는 모두 해당 키를 사용한 확인을 방지합니다. 응답하지 않는 DNS 쿼리와 별도로 영구적인 키 없음/취소된 결과를 유지합니다. 서명자 액세스를 포함하고 손상된 키를 교체합니다. DNS 만으로는 서명자를 보호하지 못합니다.

[ 역할별 ]

이것이 당신에게 의미하는 바

실용적인 다음 단계를 위해 역할을 선택하세요.

IT/메일 관리자

진단 이유를 그대로 유지합니다.

키 없음, 취소된 키 및 조회 시간 초과는 서로 다른 관찰입니다.

다음 단계

  1. 정확한 d 및 s 이름을 쿼리합니다.
  2. 캐시 차이를 기록합니다.
  3. 깨끗한 대체 서명자를 확인하십시오.

CISO/SecOps

DNS 뿐만 아니라 액세스도 포함합니다.

철회는 손상된 서명 계정을 보호하거나 노출된 비밀을 삭제하지 않습니다.

다음 단계

  1. 서명자를 제한합니다.
  2. 손상된 키 롤백을 피하세요.
  3. 접근이 제한된 상황에서 사건 증거를 보존합니다.

창립자 / 비기술자

연속성 트레이드오프를 승인합니다.

긴급 퇴직은 적법하게 대기 중인 메일에 영향을 미칠 수 있으므로 결정에는 명확한 소유자가 필요합니다.

다음 단계

  1. 영향을 받는 비즈니스 흐름의 우선순위를 지정하세요.
  2. 허용된 영향을 기록합니다.
  3. 예상되는 고객 영향을 전달합니다.

[ 자주 묻는 질문 ]

자주 묻는 질문

빈 p 값은 무엇을 의미합니까?

DKIM 키 레코드에서 공개 키를 취소된 것으로 표시합니다.

RFC 6376 §3.6.1

취소된 키는 누락된 레코드처럼 작동합니까?

둘 다 해당 키를 사용한 성공적인 확인을 방지합니다. RFC 6376 의미상 차이를 정의하지 않지만 진단 이유는 다릅니다.

RFC 6376 §6.1.2

DNS 시간 초과가 해지 증거입니까?

아니요. 조회 가용성 문제입니다. 실제 오류를 보존하고 지원되는 진단 프로세스에 따라 다시 시도하십시오.

RFC 6376 §6.1.2

키를 삭제하면 모든 메시지가 즉시 무효화되나요?

아니요. 캐시된 이전 답변은 계속 사용할 수 있으며 이전에 기록된 전달 시간 결과는 소급하여 변경되지 않습니다.

RFC 1034 §3.6 RFC 8767 §4

손상 중에 이전 키를 유지해야 합니까?

일상적인 유지 관리 중복을 자동으로 적용하지 마십시오. 승인된 사건 결정을 통해 억제와 합법적인 메일 영향의 균형을 맞추십시오.

CNAME 옆에 해지 TXT 게시할 수 있나요?

별칭 소유자에게 충돌하는 레코드를 생성하지 마십시오. 공급자가 관리하는 은퇴 프로세스를 따르십시오.

RFC 1034 §3.6.2

이전 개인 키를 복원하는 것이 안전한 롤백인가요?

손상될 수 있는 경우에는 그렇지 않습니다. 증거물을 별도로 보관하고, 승인된 클린 복구 경로를 이용하세요.

회복을 확인하는 것은 무엇입니까?

영향을 받은 경로의 교체 서명자로부터 격리 증거, 해결된 선택기 상태 및 수신된 메시지 확인.

[ 출처 ]

출처

  1. RFC 6376

    섹션 §1 · §3.1 · §3.5 · §3.6.1 · §6.1.2 · §8.3

  2. RFC 1034

    섹션 §3.6 · §3.6.2

  3. RFC 8767

    섹션 §4

[ 어휘 ]

어휘

DKIM
수신자가 공개 키 데이터로 확인하는 선택된 메시지 헤더 및 본문 콘텐츠에 대한 도메인 관련 서명입니다.

RFC 6376 §1

선택자
DKIM 확인 데이터를 찾기 위해 서명 도메인과 함께 사용되는 s 값입니다.

RFC 6376 §3.5

키 취소
레코드 제거와 의미론적 확인 차이 없이 빈 p 값을 사용하여 DKIM 공개 키를 명시적으로 폐기합니다.

RFC 6376 §3.6.1 RFC 6376 §3.1

DNS 캐시
새로 변경된 신뢰할 수 있는 답변과 다를 수 있는 일시적으로 유지되는 DNS 응답입니다.

RFC 1034 §3.6

기업 출처

최고의 금융 기관과 정부가 필요한 이유 이메일 보안 대시보드를 폐기했습니다.

기존 이메일 인증 플랫폼은 대시보드를 판매하고 엔지니어에게 작업을 요청합니다. 위험이 높은 환경에서 수동 감독은 시행 지연, 구성 드리프트 및 모니터링되지 않는 섀도우 도메인을 의미합니다.

EmailAuth 는 에이전트 이메일 출처 플랫폼입니다. 우리 대리인은 집행합니다 p=reject, 제3자 발신자를 정렬하고 도메인을 전체로 이동하세요. RFC 9989 인간 참여형 감사 기능을 갖춘 새로운 DMARC 표준을 준수합니다.

정부 대기업 1등급 금융기관

SaaS · 전용 테넌시 · Air-Gapped 온프레미스 · BYOK 암호화

기술 자료