제안을 평가하기 전에 상황 보고 날짜를 읽어보세요.
도메인 관계 정책 프레임워크는 도메인이 관계를 설명하고 상호 확인하는 방법을 제안합니다. 이는 유사한 로고, 공유 웹사이트 디자인 또는 추론된 기업 연관성보다 신뢰 당사자에게 더 명확한 정보를 제공할 수 있습니다. 그러한 정보가 이메일 결정에 영향을 미치는지 여부는 단순히 게시 여부가 아니라 해당 정보의 권위, 확인 규칙 및 소비자 행동에 달려 있습니다.
프로젝트의 상태 페이지, 2026년 11월 9일에 검사되었으며 상태가 2024년 7월 1일로 명시되어 있습니다. 여기에는 공개 고려를 위해 제안된 프레임워크가 설명되어 있으며 다음 단계로 설명적인 인터넷 초안 제출이 나열되어 있습니다. 해당 날짜는 별도로 유지되어야 합니다. 현재 읽을 수 있는 페이지는 상태 설명을 최신 상태로 만들지 않습니다. 이 평가에 대해서는 향후 최종 프로젝트 상태, 표준 결과 또는 수신자 채택이 확인되지 않았습니다.
그만큼 프로젝트 홈페이지 임시 개발을 설명하고 배포 세부 사항이 누락되었음을 인정합니다. 에이 J. Trent Adams의 2024년 2월 개발자 계정 마찬가지로 이 작업을 초기 제안이라고 부릅니다. 표준화에 관한 언어는 그러한 맥락에서 읽어야 합니다. 이 기사에서는 문서화된 모델을 평가합니다. 구현된 표준을 발표하거나 프로덕션 DNS 레코드를 규정하지 않습니다.
검색 메커니즘과 정책 의미를 분리하세요.
제안된 건축학 작은 DNS TXT 어설션이 있고 필요한 경우 더 풍부한 정책 문서가 있습니다. 어설션은 기본 관계를 표현하거나 자세한 정책을 검색하는 데 도움이 될 수 있습니다. 문서는 메타데이터를 정책 콘텐츠와 구별하고 어휘를 통해 다양한 종류의 관계를 설명할 수 있습니다. 대부분의 통역 작업은 신뢰 당사자에게 속합니다.
그 이별이 중요해요. 문서를 찾는다고 해서 두 명의 소비자가 해당 문서의 어휘를 동일하게 해석하는 것은 아닙니다. 소비자는 지원되는 용어와 알 수 없는 용어에 대한 동작을 포함하여 평가 중인 관계에 대해 합의된 프로필이 필요합니다. 사용 가능한 페이지는 하나의 완전한 상호 운용 가능한 문법을 설정하기보다는 가능성을 보여줍니다. 최소한의 주장 내용에 대한 서로 다른 설명을 고안된 필수 형식으로 조용히 해결해서는 안 됩니다.
한 가지 아키텍처 설명에는 DNS 자격도 필요합니다. RFC 1035 섹션 3.3 및 3.3.14 TXT 데이터를 각각 1옥텟 길이를 갖는 하나 이상의 문자열로 정의합니다. 255옥텟 콘텐츠 경계는 전체 TXT 리소스 레코드에 대한 범용 최대 255자가 아닌 개별 문자열에 적용됩니다. 이 수정은 DRPF의 누락된 게시 또는 구문 분석 프로필을 제공하지 않습니다.
구체적인 주장으로 상호확인을 검토
개발자 계정은 양방향 확인을 설명합니다. 즉, 다른 도메인을 명명하는 어설션에는 해당 도메인의 해당 문이 있어야 합니다. 이는 일방적인 연관성 주장에 이의를 제기합니다. 이는 법적 소유권, 두 관리자 계정의 무결성 또는 이메일로 받은 결제 지침의 안전성을 독립적으로 설정하지 않습니다.
평가자는 각 출판사가 실제로 통제하는 권한이 무엇인지, 검색을 보호하는 증거가 무엇인지 식별해야 합니다. 손상된 시스템에서 나온 두 가지 상호 일관된 진술은 지원되지 않는 주장을 하는 한 도메인과 다른 문제로 남아 있습니다. 따라서 보안 검토에는 위협 모델, 신뢰성 가정 및 정의된 오류 처리가 필요합니다. 이는 여기서 평가 요구 사항일 뿐 제안서나 이 문서에 대해 테스트된 구현에서 입증된 기능은 아닙니다.
가상의 브랜드 관계를 종단 간 매핑
가상의 도메인인 brand.example 및 parent.example 생각해 보세요. 브랜드 관리자는 하위 주장을 게시합니다. 상위 관리자는 해당 확인서를 게시합니다. 가상의 보안 애플리케이션은 소비자입니다. 제안된 작업은 메시지 인증과 별도로 청구된 비즈니스 연관을 유지하면서 동일한 관계에 대해 두 개의 지시문을 비교하는 것입니다.
프로젝트의 관련 도메인 사용 사례 두 가지 검색 접근 방식을 보여줍니다. 소비자는 부모의 어설션을 통해 부모의 정책을 검색하거나 자식이 더 직접적으로 제공하는 정책 위치를 따를 수 있습니다. 이 페이지는 구조화된 JSON-LD 문서도 보여줍니다. 이는 개념적 예일 뿐 명명된 기업이 DRPF를 배포하거나 해당 샘플 라벨이 안정적인 와이어 형식을 형성한다는 증거는 아닙니다.
이 가상 지도의 경우 소비자는 특정 지점에서 관계를 뒷받침하는 문서와 해석을 기록합니다. 부모가 확인을 철회하면 관계는 더 이상 동일한 상호 지원을 받을 수 없습니다. 이러한 가상 도메인에 대한 기록은 게시되거나 검색되지 않았으며 파서, 서명 확인 또는 신뢰 당사자 동작은 테스트되지 않았습니다.
철회 능력을 넘어서는 수명 주기가 필요함
아키텍처는 확인을 변경하여 관계를 끊는 것을 설명합니다. 이는 유용한 개념적 철회 메커니즘이지만 모든 곳에서 즉각적인 철회를 설정하지는 않습니다. 캐시된 어설션, 보관된 정책 문서 및 일시적으로 사용할 수 없는 게시자는 소비자가 신뢰할 수 있는 결정을 내리기 전에 명시적인 처리가 필요합니다.
검토자는 증거를 사용할 수 있는 기간이 얼마나 되는지, 한쪽만 변경되면 어떤 일이 발생하는지, 사용할 수 없는 정책이 의도적인 철회와 어떻게 다른지 질문해야 합니다. 게시자 손상 및 충돌하는 정책 체인 이후의 복구에도 정의된 결과가 필요합니다. 이러한 질문은 상호 게시가 모든 후속 상태 전환을 해결한다는 낙관적인 가정이 아니라 문서화된 수명 주기 규칙과 승인된 테스트를 생성해야 합니다.
이메일 인증과 비즈니스 승인을 별도로 유지하세요
두 개의 개별 도메인 간에 선언된 관리 관계는 변경되지 않습니다. DMARC 조정 그 자체로. RFC 9989 섹션 4.4 인증된 식별자와 작성자 도메인 간의 정렬을 정의합니다. 관계 클레임은 관련되지 않은 전달 서명을 정렬된 서명으로 바꾸지 않으며 이 평가는 DRPF를 예외로 처리하는 수신자 규칙을 설정하지 않습니다.
마찬가지로 받은 편지함 배치 혜택, 상속된 평판 또는 공급업체에 대한 지불 권한이 입증되지 않습니다. 미래의 소비자가 관계 정보를 사용하는 경우, 그것이 영향을 미치는 정확한 결정을 문서화하고 메시지 인증 및 비즈니스 승인에 대한 독립적인 제어를 유지하십시오. 가능한 미래 신호가 조용히 허용 목록 항목이 되거나 기존 정책을 약화시키는 이유가 되어서는 안 됩니다.
확인되지 않은 내용을 기록하세요.
제안된 관계 맵은 분석 아티팩트로 제공되지만 상태 요구 사항은 계속 열려 있습니다. 정확한 요구 사항은 다음과 같습니다. 하나의 제안된 관계, 해당 게시자, 소비자, 유효성 검사 및 해지 모델을 매핑합니다. 현재 프로젝트 상태를 확인합니다. 커미셔닝 게이트는 다음과 같습니다. 현재 프로젝트 및 채택 상태를 확인합니다. 채택된 IETF 표준으로 제시하지 않고 제안을 설명합니다.
연결된 소셜 계정과 Datatracker 검색에 액세스할 수 없어 재시도되거나 우회되지 않았습니다. 검색 부재는 이후 작품이 존재하지 않는다는 것을 증명할 수 없습니다. 더 강력한 결론을 내리거나 발표하려면 현재 상태 확인, 전문가 검토, 구현 및 상호 운용성 테스트, 실시간 프레젠테이션 검토 및 소유자 승인이 여전히 필요합니다.