와일드카드가 의도적으로 확장되는 것
보고서 소비자는 기꺼이 수신할 수 있습니다. DMARC 각 관계에 대해 하나의 권한 부여 소유자를 게시하는 대신 모든 도메인에 대해 보고합니다. RFC 9990 해당 목적을 위해 와일드카드 DNS 레코드를 명시적으로 허용합니다. 그 예는 TXT 레코드 에 *. _report._dmarc.example.com (최소 v=DMARC1. 이는 모든 보고 고객이 심사를 거쳤음을 증명하는 메커니즘이 아니라 수신 도메인의 광범위한 선택입니다.
구별은 운영상 중요합니다. 공급자는 고객에게 데이터를 표시하기 전에 계정 수준 확인을 별도로 요구하면서 합법적으로 광범위한 섭취를 선택할 수 있습니다. DNS 레코드는 이러한 계정 제어를 구현하지 않습니다. 보안 검토에서는 와일드카드가 변경되는 경계와 수신 응용 프로그램 및 해당 소유자의 책임으로 남아 있는 경계를 정확히 식별해야 합니다. RFC 9990 , 섹션 4
와일드카드 아래에 정확한 쿼리가 표시되도록 유지
보고자는 여전히 정책이 검색된 도메인인 _report에서 인증 조회를 구성합니다. _dmarc 레이블 및 대상 호스트. 와일드카드는 이러한 쿼리에 응답할 수 있는 DNS 게시 전략입니다. 쿼리된 소유자나 반환된 값을 이해할 필요가 없어지지는 않습니다. 특정 관계를 확인할 때 정확한 소유자와 응답을 유지하세요.
확인 답변은 필수 첫 번째 v=DMARC1. 버전 값은 필수 대소문자와 함께 DMARC1 유지됩니다. 와일드카드를 사용하려는 관리자의 의도는 배포된 DNS 트리에서 특정 쿼리가 예상대로 해결된다는 증거가 아닙니다. 정확한 이름 기록과 DNS 구조는 실제 해결에 영향을 미칠 수 있으므로 제안된 테스트는 스크린샷이 적용 범위를 입증한다고 가정하는 대신 실제 답변을 유지해야 합니다. RFC 9990 , 섹션 4; RFC 9989 , 섹션 4.7
소유권 및 데이터 액세스와 별도의 섭취 허가
와일드카드는 수신 도메인이 프로토콜 배열에 포함된 보고서를 수신할 의향이 있음을 나타냅니다. 대시보드에 로그인하는 사람이 보고서 내에 명명된 도메인을 제어한다는 사실은 입증되지 않습니다. 또한 업로드된 아티팩트를 보낸 사람이 신뢰할 수 있는지 또는 보고서가 이를 수신하는 계정에 속해 있는지 여부도 입증되지 않습니다.
도메인-테넌트 바인딩, 인증된 액세스, 출처 추적, 중복 처리 및 예상치 못한 도메인 검토 등 애플리케이션 수준 승인 요구 사항을 별도로 정의합니다. 이는 구현된 EmailAuth 플랫폼에 대한 주장이 아니라 제안된 컨트롤입니다. 조직을 언급하는 보고서는 소유권 관계를 자동으로 생성하거나 해당 이름을 주장하는 첫 번째 계정에 데이터를 노출해서는 안 됩니다.
청구, 온보딩 및 데이터 인증을 DNS 추론에서 제외하세요. 트래픽 수신에 대한 광범위한 의지는 조직을 유료 서비스에 등록하거나 관찰된 구성을 게시하는 데 동의하지 않습니다. 워크플로에 이러한 작업이 필요한 경우 와일드카드 기록 이상의 명시적인 결정과 증거가 필요합니다. 검토에서는 단일 DNS 결과를 포괄적인 승인으로 처리하는 대신 각 경계에 대한 책임 소유자를 지정해야 합니다.
남용 및 리소스 압박에 대한 설명
RFC 9990 보고서 내용이 압축 해제기나 XML 파서를 공격할 수 있으며 보고서 데이터가 위조될 수 있다고 경고합니다. 따라서 광범위한 접수 서비스는 보고서 수신 권한이 도착하는 모든 파일을 안전하거나 정확하게 만들지는 않는다는 점을 가정해야 합니다. 용량 계획, 파서 제한 및 출처 확인은 인증 설계와 함께 속합니다.
제한된 메시지 크기, 압축 해제 크기 제한, 구문 분석 시간 예산, 대기열 격리 및 예상치 못한 소스 볼륨에 대한 경고를 제안합니다. 수치 값은 고안된 보편적인 한계에서 복사하기보다는 실제 환경에 대해 선택되고 테스트되어야 합니다. 거부 이유를 보존하고 하나의 시끄러운 소스로 인해 관련 없는 고객 증거가 모호해지는 것을 방지합니다. 이러한 컨트롤 중 어느 것도 여기서 배포되거나 테스트되었다고 주장되지 않습니다. RFC 9990 , 섹션 8.1 및 8.2
철회 및 캐시된 승인
볼륨에 압도된 보고서 소비자는 확인 DNS 레코드를 제거할 수 있지만 RFC 9990 에서는 포지티브 캐싱이 레코드의 TTL만큼 효과를 지연시킬 수 있다고 지적합니다. DNS 변경 후 보고서의 즉각적인 중단을 약속하지 마십시오. 접수 시스템은 새로운 조회 상태와 관계없이 이미 생성되었거나 대기열에 있는 보고서를 처리해야 할 수도 있습니다.
철회 계획에는 기록 소유자, 승인 경로, 관련 TTL 증거, 전환 중 접수 행동 및 의사소통 책임이 명시되어야 합니다. 와일드카드를 제거하면 여러 합법적인 관계에 동시에 영향을 미칠 수 있습니다. 명시적인 도메인별 인증으로의 전환 제안에는 단순히 관계가 아닌 관계 목록과 검증 계획이 필요합니다. 기록 삭제.
DNS 철회와 애플리케이션 액세스 철회를 구분하세요. 수신 권한을 제거한다고 해서 저장된 보고서가 삭제되거나, 고객 계정이 폐쇄되거나, 기존 사용자 세션이 취소되는 것은 아닙니다. 이는 별도의 승인 및 보존에 영향을 미치는 별도의 제어입니다. RFC 9990 , 섹션 4
가상 경계 검토 및 테스트 설계
*를 제안하는 reports.example.net 의 가상 소비자를 생각해 보세요. _report._dmarc.reports.example.net 값 v=DMARC1; . blue.example.com 의 가상 정책의 경우 정확한 쿼리는 blue.example.com._report._dmarc.reports.example.net 입니다. 이 예에서는 쿼리, 게시 또는 DNS 고정 장치가 실행되지 않았습니다.
긍정적인 경우 계획은 정확한 쿼리를 유지하고 반환된 인증 값이 구문 분석을 통과했는지 확인합니다. 부정적인 경우 계획은 신중하게 선택해야 합니다. 일반적으로 와일드카드는 의도적으로 원본 도메인을 다루기 때문에 광범위하게 승인된 동일한 대상으로 향하는 다른 원본 도메인이 반드시 승인되지 않은 것은 아닙니다. 대신, 실제 설비가 승인되고 격리된 경우 허가 없이 별도로 제어되는 대상 호스트가 외부 대상 경계를 표시할 수 있습니다.
워크시트에는 와일드카드 소유자, 예상 적용 범위, 정확한 테스트 소유자, 답변, 버전 구문 분석, 대상 호스트 경계 및 테넌트 액세스 확인이 나열되어야 합니다. 또한 롤백 계획과 보고서 처리 제한도 기록해야 합니다. 예상 결과는 실제 제한된 테스트가 수행되기 전까지의 설계 가설입니다. 단순히 추론이 타당하다는 이유만으로 통과되었다고 표시되어서는 안 됩니다.
해결되지 않은 원본 증거 및 공개 게이트
카탈로그에는 긍정적인 테스트와 승인되지 않은 대상 테스트를 포함하여 정확한 승인 소유자와 답변이 필요합니다. 이러한 원래 관찰은 계속 열려 있습니다. 이 원고는 작동하는 와일드카드 배포나 계정 액세스 평가가 아닌 제안된 테스트 설계와 가상의 이름을 제공합니다.
검증된 운영 가이드로 게시되기 전에 자격을 갖춘 검토자는 실제 DNS 응답을 검사하고 부정적인 테스트가 실제로 의도한 인증 경계를 넘는지 확인해야 합니다. 원본 증거, 인적 검토, 소스 적용 가능성, 생산 경로, 시각적 접근성 및 소유자 공개는 계속 열려 있습니다. 이 작업에는 외부 연락, 보고서 업로드 또는 DNS 수정이 수행되지 않았습니다.