요약

  • RFC 9975는 페어런털 에이전트가 관찰 집합을 상위 측 위임 내 하위 위임으로부터 구성하고, CDS/CDNSKEY 또는 CSYNC 데이터에 따라 동작하기 전에 목록에 등록된 모든 권위 서버의 모든 주소를 조회하도록 요구합니다.
  • NODATA는 증거이며, 응답 없음은 재시도를 요구하고, 불일치에는 하나의 안전한 결과만 있습니다. 요청된 변경이 건드렸을 상위 레코드를 생성·삭제·변경하지 않고 작업을 중단하는 것입니다.
  • 서버 간 합의는 일관된 요청을 보여줄 뿐, 신원·조직적 권한·올바른 구현·보편적 배포·성공적인 DNSSEC 검증을 증명하지 않습니다. RFC 10026은 요청 일관성과 지속 검증을 별개의 검사로 유지합니다.

한 권위 서버는 새 키를 상위 측에 반영해야 한다고 말합니다. 두 번째 서버는 아무 말도 하지 않습니다. 두 응답 모두 정당하게 서명되었을 수 있고, 두 서버 모두 정상일 수 있습니다. 상위 측이 첫 번째 응답을 수용하면, 하위 서비스가 아직 게시를 끝내지 않은 변경을 자동화할 수 있습니다. 두 번째 응답을 거부권으로 취급하면, 완전히 정당한 롤오버를 지연시킬 수 있습니다.

이 지름길이 유혹적인 이유는, 평범한 DNS 해석은 모든 서버에 묻지 않기 때문입니다. 리졸버는 사용 가능한 응답을 찾습니다. DS, NS 또는 글루 데이터를 변경하려는 페어런털 에이전트는 다른 일을 합니다. 즉, 관찰된 하위 상태를 네임스페이스의 더 높은 지점에 반영되는 지속적 변경으로 전환하는 것입니다.

Peter Thomassen의 RFC 9975(2026년 5월 공개)는 이 차이를 프로토콜 안으로 옮깁니다. CDS/CDNSKEY 또는 CSYNC 레코드에 따라 동작하기 전에, 페어런털 에이전트는 상위 측 위임이 기술하는 권위 서비스 전반에 걸쳐 그럴듯한 일관성을 확립해야 합니다. 이 표준은 서버를 입법자로 만들지 않습니다. 고결과 자동화가 공유된 요청과 부분적 관점을 구분할 만큼 충분한 증거를 수집하도록 만듭니다.

하나의 응답은 결코 하위 존 전체가 아니었다

CDS와 CDNSKEY는 하위 존이 상위 측에 게시하기를 원하는 DS 상태를 기술하게 해 줍니다. CSYNC는 하위 존이 NS와 연관 주소 같은 위임 데이터에 대한 변경 의사를 신호로 보낼 수 있게 합니다. 이 메커니즘은 티켓과 자격 증명 공유를 줄여 주지만, 동시에 해석의 순간을 소프트웨어 안으로 옮깁니다.

이전 절차는 소비자가 리졸버가 보통 그러하듯 한 권위 서버만 조회할 여지를 남겼습니다. 모든 서버가 이미 같은 존을 갖고 있다면 그것은 효율적입니다. 그러나 복제 지연, 다중 공급자 전환, 부분 장애 또는 구성 분열 상황에서는 위험합니다.

단일 응답은 그 서버로부터의 응답으로서는 진실일 수 있으면서도, 상위 위임이 지명하는 서비스를 대표하지 못할 수 있습니다. 한 공급자가 새 CDS 키를 게시하는 동안 다른 공급자가 여전히 NODATA를 노출한다면, 상위 측은 일관된 교체 요청을 관찰한 것이 아닙니다. 한 CSYNC 응답이 네임서버 교체를 요청하는 동안 다른 응답이 현상 유지를 고수한다면, 더 빠른 응답을 선택하는 것은 도착 순서에 결정 권한을 조용히 부여하는 셈입니다.

RFC 9975는 요구되는 결과를 "그럴듯한 일관성(plausible consistency)"이라고 부릅니다. 이 단어는 절제되어 있습니다. 상위 측은 모든 곳으로 보내진 모든 패킷이 동일할 것임을 증명할 수 없습니다. 다만 현재 위임에서 도출한 주소들을 조회하고, 관련 레코드와 결정 상태를 비교하며, 불일치로부터 변경을 추론하지 않을 수 있습니다.

상위 위임이 누구에게 물어야 하는지 정의한다

이 검사는 요청에 포함된 서버 목록에서 시작되지 않습니다. 페어런털 에이전트는 하위 존을 알고, 상위 측 위임에서 하위 존의 NS 호스트명을 읽습니다. 검증 리졸버를 통해, 이용 가능한 글루를 포함해 각 호스트명의 모든 IP 주소를 얻은 뒤, 관련 질의를 그 모든 주소로 보냅니다.

이 순서는 미묘한 공백을 닫습니다. 하위 측 신호가 자신의 증인 집합을 정의할 수 있다면, 잘못 구성되었거나 적대적인 소스가 여전히 이전 상태를 갖고 있는 서버를 생략할 수 있습니다. 현재 상위 위임은 상위 측이 인터넷에 사용하라고 지시한 권위 서비스가 어느 것인지에 대한 운영 기록입니다.

주소 목록도 중요합니다. 하나의 호스트명은 여러 주소를 가질 수 있고, 그 주소들은 서로 다른 인스턴스나 네트워크 경로에 도달할 수 있습니다. 하나의 재귀 리졸버를 통해 이름을 확인하는 것은 이 표준의 목적상 확인된 전체 집합에 접촉하는 것과 동등하지 않습니다.

그래도 이것은 유한한 증거입니다. 애니캐스트는 같은 주소 뒤에서 서로 다른 두 인스턴스로 이어질 수 있고, 일시적 경로 문제는 도달 가능한 서비스를 가릴 수 있습니다. 따라서 RFC는 다른 네트워크 관찰 지점을 허용하고, 첫 수집이 전지적이라고 가장하는 대신 재시도를 권고합니다.

NODATA는 응답이며, 침묵은 동의가 아니다

페일클로즈드 설계에서 가장 결과가 큰 문장은 흔히 아무것도 정의하지 않는 문장입니다. RFC 9975는 일관성이 수신된 응답 전반에 걸쳐 요구되며, NODATA가 명시적으로 수신된 응답에 포함된다고 말합니다.

NODATA는 서버가 권위적으로 응답했으나 요청된 레코드 타입을 반환하지 않았음을 의미합니다. CDS/CDNSKEY 유지보수에서 그것은 그 관점에서는 자동화 변경이 요청되지 않았음을 뜻할 수 있습니다. 다른 서버가 새 키를 반환했다고 해서 이것을 평균으로 지워서는 안 됩니다.

응답 없음은 다릅니다. 패킷 손실, 라우팅 문제, 필터링 또는 서버 장애가 관찰을 막았을 수 있습니다. 페어런털 에이전트는 서버가 영구적으로 도달 불가능하다고 판단해 제외하기 전에 다시 시도해야 합니다. RFC는 구성 가능한 일정을 권고하고, 지수 백오프(5, 10, 20, 40분 등)를 예로 제시합니다. 두 번째 관찰 지점은 문제가 서버에 속하는지 아니면 하나의 경로에만 속하는지 확인해 줄 수 있습니다.

이 구분은 정반대의 두 오류를 막습니다. 침묵을 NODATA로 취급하면 망가진 경로가 정당한 업데이트를 얼려 버릴 수 있습니다. 침묵을 동의로 취급하면 도달 가능한 부분집합이, 상위 측 자신이 여전히 게시하는 권위 집합을 대변하게 됩니다.

이 표준은 무한한 대기를 요구하지 않습니다. 연산자가 누락된 증인이 영구 도달 불가능이 되는 정책을 노출하도록 요구합니다. 기간, 관찰 지점, 에스컬레이션은 현지 결정으로 남습니다. 증거의 부재가 조용히 긍정적 증거로 변하지 않도록 하는 것입니다.

불일치 시 기존 상위 상태를 유지한다

불일치 상태가 나타나면, 결정은 다수, 최신 시리얼, 가장 빠른 서버를 선택하는 것이 아닙니다. 페어런털 에이전트는 중단해야 합니다. 제안된 작업이 생성했을 레코드를 생성하거나, 제거했을 레코드를 삭제하거나, 기존 집합을 변경해서는 안 됩니다.

이것은 이전 상태를 반드시 최종 진실은 아니더라도 유한한 안전 기본값으로 만듭니다. 상위 측은 이미 그것을 게시하고 있습니다. 서로 충돌하는 두 하위 관점 중 하나로 바꾸는 것은 해석이나 검증을 깨뜨릴 수 있습니다. 유지하는 것은 하위 운영자에게 복제를 마치거나, 공급자 분열을 바로잡거나, 인증된 대역 외 경로를 사용할 시간을 줍니다.

전체 절차는 재시도할 수 있습니다. 재시도는 편리한 부분집합으로부터의 계속이 아니라, 결정이 하나의 일관된 관찰 라운드에 속하도록 질의를 반복합니다. 연산자는 결정 경로가 멈춘 뒤에도 보고 목적으로 계속 질의할 수 있습니다.

조기 종료 사례도 있습니다. 어떤 응답이 현상 유지를 확인한다면(명시적으로 또는 NODATA를 통해), 보류 중인 결정 질의를 큐에서 제거할 수 있습니다. 이후의 어떤 응답도 변경 없음을 확인하거나 불일치를 드러낼 뿐이며, 이 역시 변경을 만들지 않습니다. 이 최적화는 남은 불확실성을 업데이트로 바꿀 수 없기 때문에 불변성을 보존합니다.

CDS와 CDNSKEY는 장식적 동등성이 아니라 키를 비교한다

그럴듯한 일관성은 모든 응답에 걸친 바이트 단위 동일성이 아닙니다. CDS/CDNSKEY의 핵심 질문은, 어디에서든 참조되는 각 적격 키가 다른 모든 곳에서도 참조되는가입니다. 한 서버에는 존재하고 다른 서버에는 없는 키는 상태를 불일치로 만듭니다.

동일한 규율이 완전 제거에도 적용됩니다. 전체 DS 집합 제거를 요청하는 한 응답은, 업데이트를 요청하거나 NODATA를 반환하는 다른 응답과 충돌합니다. 소프트웨어는 표준이 제공하지 않는 명시적 규칙 없이 이를 단계적 삭제로 재해석해서는 안 됩니다.

CDS 다이제스트 처리에는 정의된 경계가 있습니다. 관련 IANA 정책이 식별한 다이제스트 타입만 지정된 대로 일관성 비교에 들어가면 됩니다. 상위 측은 최종적으로 게시할 허용된 다이제스트 형태에 대한 선택을 유지하지만, 로컬 해시 정책은 하위 존이 일관되게 참조한 키 집합을 바꿀 수 없습니다.

Steve Sheng과 Thomassen이 공동 저자이고 2026년 7월에 Best Current Practice로 공개된 RFC 10026은 일관성 옆에 두 번째 관문을 놓습니다. 상위 측은 결과 DS 집합이 유효한 DNSSEC 경로를 보존할지도 검증해야 합니다. 만장일치 요청도 적용하기에 위험할 수 있습니다. 합의는 의도의 증거이고, 지속 검증은 기술적 연속성의 증거입니다.

CSYNC는 정의된 차이를 허용하되 모순은 수용하지 않는다

CSYNC에는 더 정밀한 비교가 필요한데, 모든 필드가 모든 서버에서 동일해야 하는 것은 아니기 때문입니다. immediate 플래그와 타입 비트맵은 수신된 응답 전반에서 일치해야 합니다. SOA 시리얼 값은 일반적인 복제나 다중 공급자 운영 중에는 달라질 수 있으므로, 각 시리얼은 같은 서버에서 얻은 SOA를 기준으로 평가됩니다. 결과 결정, 즉 업데이트가 허용되는지는 일치해야 합니다.

CSYNC가 NS나 주소 레코드 같은 동기화할 데이터 집합을 지목할 때, 관련 서버들은 빈 집합을 포함해 동일한 RDATA 집합을 반환해야 합니다. 네임서버 변경과 글루 변경이 처리되는 순서 등 다른 CSYNC 규칙도 그대로 적용됩니다.

그래서 "모두에게 물어라"는 불완전한 요약입니다. 진지한 구현에는 레코드 계열마다 비교 모델이 필요합니다. 어떤 차이가 허용되고, 어떤 차이가 전환의 증거이며, 어떤 차이가 요청된 상위 변경을 결정 불가능하게 만드는지 알아야 합니다.

알림은 검사를 시작할 뿐, 검사를 이기지 않는다

Thomassen도 저자 목록에 있는 RFC 9859는 하위 존이 CDS 관련 상태가 변경되었다는 일반화된 알림을 보내게 합니다. 이 메시지는 낭비적인 주기 스캔을 없애고, 상위 측이 살펴보기까지의 시간을 단축할 수 있습니다.

그러나 증거 사슬을 건너뛰지는 않습니다. CDS 알림을 받으면 상위 측 수신자는 타이머 뒤에서 사용했을 것과 동일한 DNS 조회와 검증을 시작하도록 지시받습니다. 벨은 감독관을 문으로 부를 수 있지만, 안쪽을 인증할 수는 없습니다.

조직이 지연 시간을 최적화할 때 이 분리가 중요합니다. 알림 성공, 큐 수용, DNS 질의, 서버 간 일관성, DS 검증, 상위 게시, 리졸버에서 보이는 효과는 서로 다른 영수증입니다. 이들을 하나의 초록색 "자동화됨" 배지로 합치면, 사슬의 마지막 메시지가 앞뒤의 모든 단계에 대한 증명처럼 보입니다.

일관성은 권한도, 신원도, 결과도 아니다

합의된 하위 측 레코드 집합은 누가 도메인을 소유하는지, 누가 하위 운영자를 지시할 자격이 있었는지, 공급자 계정이 침해되었는지 증명하지 않습니다. 기존 DNSSEC 검증은 확립된 사슬을 통해 유지보수를 인증할 수 있습니다. 초기 부트스트래핑에는 RFC 9615 같은 방법이 필요한데, 상위 DS 경로가 아직 존재하지 않기 때문입니다. 조직적 승인은 여전히 레코드 비교 밖의 레지스트리, 레지스트라 또는 도메인 소유자 통제를 요구할 수 있습니다.

상위 게시가 모든 재귀 리졸버가 새 상태를 본다는 증명도 아닙니다. 캐시는 TTL이 만료될 때까지 이전 DS나 위임 데이터를 유지합니다. 하위 존은 너무 이른 시점에 다음 롤오버 단계로 넘어갈 수 있습니다. 따라서 RFC 10026은 타이밍, 검증, 롤백, 보고를 일관성에서 자동으로 상속되는 이득이 아니라 운영 작업으로 다룹니다.

RFC 9975는 하위 측 운영자가 합의에 도달하지 못할 때 인증된 대역 외 경로를 열어 둡니다. 그것은 일관성 규칙의 허점이 아니라 다른 권한 경로입니다. 자동화가 첫 번째로 도달한 서버에게 결정권을 주어 거버넌스 또는 공급자 교착을 해결해서는 안 됩니다.

Thomassen의 저자 표시는 기여이지, 통제 평면이 아니다

RFC Editor는 Peter Thomassen을 RFC 9975의 단독 저자로 기재합니다. 그의 공개 IETF 기록은 그가 검토 시점에 deSEC의 설립자이자 최고기술책임자(CTO), SSE의 상무이사, Domain Connect 의장, DNSOP 서기였음을 밝힙니다. 그는 또한 RFC 9615, RFC 9859, RFC 10026의 공동 저자이기도 합니다.

이 사실들은 그를 표준 계보에 문서화된 참여자로 만듭니다. 그러나 그가 모든 페어런털 에이전트를 운영하거나, 레지스트리나 레지스트라를 통제하거나, 구현을 인증하거나, 관찰된 어떤 사건을 일으켰다는 뜻은 아닙니다. RFC는 상호운용 가능한 소프트웨어의 최소 동작을 명시할 수 있습니다. 어떤 코드가 어떤 주소를 조회했는지, 응답을 어떻게 비교했는지, 불일치 시 상위 측이 실제로 변경되지 않았는지는 배포된 증거만 보여줄 수 있습니다.

이 구분은 메커니즘 안의 더 큰 경계와 상통합니다. 지명된 저자는 기여의 증거이지 모든 구현에 대한 권한이 아닙니다. 지명된 권위 서버는 위임 안의 증거 출처일 뿐, 혼자서 상위 측을 다시 쓸 수 있는 주권적 허가가 아닙니다.

진짜 산출물은 결정 영수증이다

표준에 걸맞은 구현은 범위를 정의하는 데 사용된 상위 위임, 해석된 모든 서버 주소, 글루 출처, 질의 시각과 관찰 지점, 관련 응답 또는 NODATA 상태 전체, 검증 결과, 비교 결과, 재시도, 백오프, 영구 도달 불가능으로 제외된 항목을 보관해야 합니다.

그리고 예상 상위 diff, 지속 검증 검사, 중단·유지·적용 결정, 게시 후의 실제 상위 상태를 기록해야 합니다. 비밀 자격 증명은 그 기록에 속하지 않습니다. 결정을 재현하는 데 필요한 증거가 속합니다.

최소 명세는 공통입니다. 불일치한 부분집합으로부터의 위임 변경 추론이 없어야 합니다. 이후의 현지 선택은 달라질 수 있습니다. 재시도 창, 대체 관찰 지점, 보고 채널, 허용 범위 안의 다이제스트 정책, 그리고 상위 측이 자동화를 아예 제공할지 여부.

경계가 문서 밖에도 존재하는지는 실행되는 코드가 결정합니다. 한 서버가 달라질 때 가장 중요한 산출물은 오류 카운터가 아닙니다. 상위 측에서 아무것도 움직이지 않았다는 검증 가능한 기록입니다.

출처