RFC 9886: 드론 ID, DNS 위임과 레지스트리 증명

요약

RFC 9886은 128비트 IPv6 형식의 DET—로케이터가 아님—를2001:30::/28프리픽스 아래의 역방향 DNS로 매핑합니다.
계층 구조는 등록 할당 기관(RAA)과 HHIT 도메인 기관(HDA)을 분리하며, 위임은3.0.0.1.0.0.2.ip6.arpa아래에 이루어집니다.
DET 이름은 HHIT 레코드로 확인되어야 하며, UAS 원격 ID 용도에서는 BRID 레코드도 함께 존재해야 합니다.
DNSSEC은 최상위 엔터티에 필수이고 다른 엔터티에는 권장됩니다. DNSSEC을 사용할 수 없는 경우 검증은 연속적인 HHIT 조회를 통한 인증서 순회로 대체됩니다.

운영상 기준점은 바이트 문자열 재구성이 아니라 DNS 조사입니다. 역방향 트리 앵커인3.0.0.1.0.0.2.ip6.arpa에서 시작하고, DET에서 파생된 RAA 및 HDA 위임을 찾아 권위 있는 서버에 질의하십시오. DET 이름에서는 HHIT RRType 67과 그 정식 등록 인증서를 확인합니다. UAS의 경우 BRID RRType 68도 확인하며, 여기에는 해당 레코드가 나타내는 정적 Broadcast RID 정보와 서명(endorsement)이 포함됩니다. 인증서 체인을 따라 관련 레지스트리 기관까지 이동하십시오. 통사적으로 존재하는 레이블을 등재 증거로 취급해서는 안 됩니다.

공개/비공개 경계가 중요합니다. RFC 9886은 공개 DRIP 정보와 포인터를 권위 있는 DNS에 두고, 비공개 레지스트리는 별도로 유지합니다. 이 문서는 개인 식별 정보를 보호하는 데 사용되는 AAA 메커니즘을 명시하지 않습니다. 따라서 공개 조회는 특정 DNS 및 인증서 증거를 확립할 수 있지만, 비공개 레지스트리의 신원 통제, 자격 규칙, 가격 정책 또는 관할 정책이 건전함을 입증하지는 못합니다.

DNSSEC은 증거 경로를 바꿉니다. 계층 구조에서 엔터티의 위치가 요구하는 경우 서명된 위임과 레코드를 검증하십시오. DNSSEC이 없으면 클라이언트는 연속적인 HHIT 조회를 통해 인증서 계층을 순회해야 합니다. 어느 경로에서든 조회 성공만으로는 불충분합니다. 신뢰하는 당사자는 끊김 없는 적절한 체인과 요구되는 레코드 집합이 필요합니다.

DET는 서명 검증용 공개 키도 노출합니다. RFC 9886은 실용적인 경우 DET 아래의 레코드 유형 게시를 필요해질 때까지 지연시킬 것을 권장합니다. 정시(just-in-time) 메커니즘은 범위 밖입니다. 이는 노출 지침이며, 익명성의 약속이나 측정된 프라이버시 결과가 아닙니다.

운영자 의사결정 경로:(1) DET를 IPv6 형식의 식별자로 파싱하되 로케이터로 보지 않기; (2)2001:30::/28역방향 DNS 위치를 도출하고 검사하기; (3) 권위 있는 RAA/HDA 위임 확인하기; (4) HHIT 요구하기; (5) UAS 원격 ID에 대해서는 BRID 요구하기; (6) DNSSEC을 검증하거나, DNSSEC이 없으면 인증서 순회 수행하기; (7) 인증서 신선도와 위임 상태를 운영 증거로 기록하기; 그리고 (8) 검증 및 노출 목적이 정당화될 때만 추가 DET 레코드를 게시하기.

이 마지막 수명 주기 점검들은RFC 요구사항이 아니라 Theo March 분석입니다. 위임 통제는 거버넌스 통제 지점입니다. 위임, 레지스트리 레코드 또는 인증서 경로를 변경할 수 있는 자는 신뢰하는 당사자가 수용하는 내용에 영향을 미칠 수 있습니다. 운영자는 오래된 레코드, 철회된 자격 증명, 끊어진 부모-자식 증거, 공개 시점을 모니터링해야 합니다. RFC 9886은 프로덕션 배포, 채택, DIME 또는 레지스트리 가용성과 지연 시간, 구현 범위, 인시던트 이력, 어뷰즈, 프라이버시, 추적성 결과, 또는 어떤 관할별 정책이나 가격도 확립하지 않습니다.