[ DNS 및 도메인 ]

DNS 롤백 후 인증 레코드 복원

이전 영역을 맹목적으로 복원하는 대신 현재 발신자 종속성과 롤백 스냅샷을 조정하여 인증 DNS 복구합니다.

EmailAuth 연구팀 제공

[ 핵심사항 ]

  • 백업을 복원하기 전에 의도한 현재 상태를 조정하십시오.
  • 폐기된 발신자를 복원하지 않고 승인된 가장 작은 차이를 복구합니다.
  • 정식 복구에는 여전히 캐시 및 메시지 확인이 필요합니다.
이 페이지에서

DNS 롤백은 삭제하는 동안 이전 인프라 상태를 복원할 수 있습니다. 선택자 또는 나중에 도입된 정책. 가져오기 가장 쉬운 백업이 아니라 의도한 현재 메일 구성을 복원합니다. 먼저 영향을 받은 이름을 제공하는 권한과 롤백 중에 변경된 사항을 설정합니다.

수리하기 전에 증거를 동결하세요

참고자료: RFC 6376 §3.5.

롤백 시간, 이전 내보내기, 현재 레코드 세트 및 백업 이후 승인된 변경 사항을 캡처합니다. 정확한 이름, 유형 및 값을 비교하십시오. SPF, DMARC, 선택기, 반환 경로 및 수신 경로. 누락된 기록과 오래되었지만 현재 존재하는 기록은 다른 실패입니다. 영향을 받은 선택기와 서명 도메인을 보여주는 메시지를 보존합니다. 공급업체 대시보드만으로는 어떤 선택기가 아직 활성화되어 있는지 확인할 수 없습니다.

제거된 모든 기록을 다시 도입하지 마십시오. 기록된 SPF 항목은 폐기된 서비스를 승인할 수 있으며, 사용되지 않는 별칭은 원치 않는 종속성을 복원할 수 있습니다. 어떤 발신자와 키가 의도된 것인지 서비스 소유자에게 문의하세요. 무제한 전체 영역 덮어쓰기가 아닌 명명된 예외가 있는 승인된 현재 상태 diff로 복원을 처리합니다.

가장 작은 올바른 세트를 수리하십시오.

참고자료: RFC 7208 §4.5, RFC 4035 §5.

다른 팀의 중간 변경 사항이 손실되지 않도록 diff를 적용하기 직전에 라이브 영역을 다시 읽으십시오. 현재 복구 내보내기를 유지하고 각 추가, 교체 또는 삭제를 기록합니다. SPF 복구 시 손상된 정책과 함께 두 번째 정책을 추가하는 대신 선택한 SPF 정책 하나를 소유자에게 남겨두도록 하세요.

확인해보세요 DNSSEC 롤백이 키나 권한을 변경한 경우 체인. 만료된 서명이 있거나 상위 DS와 호환되지 않는 하위 키가 있는 서명된 레코드를 복원하면 유효한 해결 방법이 복원되지 않습니다. 공급자 관리 서명은 지원되는 워크플로를 통해 복구되어야 하며 검증 증거는 일반적인 DNS 가시성과 별도로 보관되어야 합니다.

3개의 스냅샷 픽스처를 통해 작업

오프라인 픽스처에서 백업 A에는 선택기 s1 및 SPF 포함되어 있습니다. v=spf1 ip4:192.0.2.10 -all. 승인된 상태 B는 해당 발신자를 폐기하고 SPF 다음으로 변경합니다. v=spf1 ip4:192.0.2.20 -all 선택기 s2를 추가합니다. 실수로 인한 롤백 C는 A와 같습니다. 올바른 복원 차이점은 SPF 정책을 대체하고 s2를 복원합니다. s1이 남아 있는지 여부는 문서화된 키 폐기 결정이 필요합니다.

A, B 및 C를 소유자 및 유형별로 키가 지정된 JSON 객체로 나타냅니다. 별도의 값을 유지하면서 정렬된 레코드 값을 비교합니다. TXT 레코드. 예상되는 출력에는 변경된 apex TXT 세트와 누락된 s2 소유자가 포함됩니다. 문서 주소는 합성 주소입니다. 이 예제 정책을 프로덕션 도메인에 적용하지 마십시오.

격리된 DNS 버전의 경우 C를 게시한 다음 승인된 복구를 게시하고 다음을 사용하여 각 기관에 쿼리합니다. 발굴 @AUTH example.test TXT +norecurse 그리고 발굴 @AUTH s2._domainkey.example .test TXT +norecurse. 선택기에 마커 데이터를 사용하고 비암호화 라벨을 붙입니다. 답변과 정확한 수리 차이점을 모두 유지합니다. 실시간 복구 및 서명된 메시지 유효성 검사가 보류 중입니다.

오래된 성공과 오래된 실패에 대한 설명

참고자료: RFC 2308 §5.

해결 프로그램은 롤백 전의 좋은 답변을 유지하고 일시적으로 오류를 숨길 수 있습니다. 다른 하나는 누락된 선택기 응답을 캐시하고 복구 후에도 계속 실패할 수 있습니다. 쿼리 시간, 확인자, 응답 코드 및 TTL 컨텍스트를 기록합니다. 캐시된 보기를 강제로 변경하기 위해 올바른 전거 데이터를 계속 편집하지 마십시오.

정식 복구 후에는 재귀 경로를 관찰하고 영향을 받는 각 서비스를 통해 승인된 무해한 테스트 메시지를 보냅니다. 인증 결과를 원래 헤더 및 알려진 수신자 동작과 비교합니다. 올바른 인벤토리, 롤백 원인 및 백업 보호 장치를 사용하여 사고를 종료합니다. 복원된 DNS 는 전제조건이지 전달 증명이나 광범위한 시행을 제거하기 위한 변명이 아닙니다.

격리된 실험실 증거를 실행했습니다.

2026년 11월 7일에 유지된 격리된 소켓 랩은 백업 상태를 제공한 다음 로컬에서 사전 정의된 합성 복구를 적용했습니다. 실제 UDP 쿼리에서는 수리 전 이전 SPF 주소와 누락된 s2를 관찰했고 이후에는 새로운 SPF 주소와 s2 마커를 관찰했습니다. 롤백 계획은 백업 복원 자료, 현재 의도된 상태, 두 가지 정확한 변경 사항 및 종속성 소유권을 유지합니다. 생산 기록이 변경되지 않았습니다. 캡처 레이블은 Rollback_before_spf입니다. 롤백_before_s2; 롤백_after_spf; 롤백_after_s2. 재현 가능한 러너 및 원본 캡처가 증거 패키지에 포함되어 있습니다. 프로덕션 DNS , DNSSEC 및 SMTP 결과는 테스트되지 않은 상태로 유지됩니다.

2026년 11월 8일 검토를 위해 유지된 전선 캡처 및 수리 차이점을 오프라인으로 확인했습니다. DNS 서버, dig 명령, DNSSEC 유효성 검사 또는 SMTP 테스트가 다시 실행되지 않았습니다.

[ 테이크아웃 ]

정식 복구에는 여전히 캐시 및 메시지 확인이 필요합니다.

[ 역할별 ]

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

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

IT/메일 관리자

세 가지 상태를 조화시키다

백업, 의도한 현재 상태, 실제 롤백 상태를 비교합니다.

다음 단계

  1. 세 개의 스냅샷을 모두 유지합니다.
  2. 가장 작은 검토된 차이를 적용합니다.
  3. 영향을 받는 각 선택기를 테스트합니다.

CISO/SecOps

폐기된 권한 복원 방지

복구는 발신자 신뢰를 자동으로 확대해서는 안 됩니다.

다음 단계

  1. 제거된 SPF 서비스를 검토하세요.
  2. 사용되지 않는 별칭을 확인하세요.
  3. DNSSEC 체인을 확인합니다.

창립자 / 비기술자

현재 비즈니스 상태 복원

이전 스냅샷에서는 합법적인 새 보낸 사람이 생략될 수 있습니다.

다음 단계

  1. 사고 소유권을 할당합니다.
  2. 현재 발송인 인벤토리를 승인합니다.
  3. 복구 일정이 필요합니다.

[ 자주 묻는 질문 ]

자주 묻는 질문

가장 오래되고 알려진 양호한 영역 전체를 복원해야 합니까?

합법적인 이후 변경 사항을 조정한 후에만 가능합니다. 블라인드 임포트로 이를 취소할 수 있습니다.

백업을 통해 만료된 발신자를 복원할 수 있나요?

예. 다시 도입하기 전에 이전 SPF 권한 및 별칭을 검토하세요.

키가 반환된 후에도 DKIM 계속 실패하는 이유는 무엇입니까?

해결 프로그램이 부정적인 답변을 유지하거나 다른 서명 또는 메시지 문제가 있을 수 있습니다.

복구를 위해 두 번째 SPF 레코드를 추가해야 합니까?

아니요. 의도한 단일 선택된 SPF 정책을 복구하십시오.

캐시된 좋은 답변으로 롤백을 숨길 수 있나요?

예. 권위 데이터를 재귀적 관찰과 비교합니다.

기록을 복구하면 DNSSEC 자동으로 수정되나요?

아니요. 키, 상위 DS 및 사용 가능한 서명은 여전히 ​​유효한 체인을 형성해야 합니다.

복원할 선택기를 식별하는 것은 무엇입니까?

인벤토리에서 지원하는 서명 서비스 구성 및 실제 DKIM-Signature 필드입니다.

복구는 언제 완료되나요?

승인된 차이점 후에는 DNS 관찰 및 대표 메일 테스트가 명시적인 종료 기준을 충족합니다.

[ 출처 ]

출처

  1. RFC 7208 : 발신자 정책 프레임워크

    섹션 §3.2 · §4.5

  2. RFC 6376 : 도메인키 식별 메일 서명

    섹션 §3.6.2

  3. RFC 2308 : DNS 쿼리의 네거티브 캐싱

    섹션 §5

  4. RFC 4035 : DNS 보안 확장을 위한 프로토콜 수정

    섹션 §5

  5. BIND 9 발굴 매뉴얼

    섹션 발굴 개요 · 간단한 사용법 · 옵션 · 쿼리 옵션

[ 어휘 ]

어휘

롤백
나중에 유효한 변경 사항이 생략될 수 있는 이전 구성으로 되돌립니다.
네거티브 캐시
이름이나 요청한 데이터가 없다는 정보가 저장되었습니다.
회복 차이
실제 상태를 승인된 상태로 이동하려면 명시적인 변경이 필요합니다.

기업 출처

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

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

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

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

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

기술 자료