요약

  • 9월 13일 관측에 따르면.ps의 루트 글루는 이제 해당 RIPE NCC AuthDNS 호스트명의 현재 IPv6 주소와 일치합니다..ne,.sd,.tj는 여전히 8월에 확인된 이전 IPv6 글루를 그대로 담고 있었습니다.
  • RIPE NCC는 IANA가 해당 ccTLD 담당자의 승인 없이는 요청을 처리할 수 없다고 밝혔습니다. 따라서 서로 다른 결과는 하나의 복구 배치가 아니라 네 개의 개별 위임 워크플로와 부합합니다.
  • 서비스 중단은 확인되지 않았습니다. RIPE NCC는 모든 위임에 대해 대체 IPv6 및 IPv4 글루를 보유하고 있다고 보고했습니다. 빠져 있는 공개 통제는 각 사례의 상태와 처리 결과를 보여주는 프라이버시에 안전한 접수증입니다.

사고 목록에서 4라는 숫자는 만족스럽습니다. 시작점이 있고 공통 원인이 있고 결국 하나의 마무리 행으로 끝나는 집합을 암시하니까요. 그러나 루트 존 유지보수는 그만큼 순순하지 않습니다.

8월 15일, Patrik Wallstrom은 RIPE DNS 워킹 그룹에 루트가 여전히cctld.authdns.ripe.net아래 네 개의 호스트명, 즉.ne,.ps,.sd,.tj를 서빙하는 이름들에 대해 이전 IPv6 글루를 담고 있다고 보고했습니다. RIPE NCC는 1월에 AuthDNS IPv6 재번호화가 완료되었고 이전/48이 완전히 철회되었으며 대부분의 정리가 끝났다고 발표한 바 있습니다. 네 개의 레코드는 그 잔여물이 RIPE NCC 자체 네트워크 밖에서도 보이게 만들었습니다.

RIPE NCC의 8월 20일 답변은 중요한 경계를 제시했습니다. 이메일, 전화, 지역 연락망을 통해 시도했고 IANA에 요청을 개설했지만, 그 요청들은 해당 ccTLD 담당자의 승인 없이는 처리될 수 없었습니다. RIPE NCC는 TLD 관리자들이 자신들의 루트 존 글루를 최신 상태로 유지할 책임이 있다고 언급했습니다.

이것은 라우팅 변경에 덧붙여진 관료적 마찰이 아닙니다. 이것이 바로 승인 모델입니다. 네임서버 운영자는 자신의 주소가 바뀌었다는 것을 알 수 있지만, 루트 존 유지보수자는 다른 관리자의 위임을 변경하라는 무승인 제3자의 지시를 받아들일 수 없습니다.

개수는 줄었지만, 하나의 개수로서가 아니라

9월 12일 17:14 UTC(상하이에서는 이미 9월 13일)에 이 연구는a.root-servers.net과b.root-servers.net의 레퍼럴을1.1.1.1과8.8.8.8이 반환한 호스트명 응답과 비교했습니다.

ps.cctld.authdns.ripe.net의 경우 두 루트 서버 모두 글루로2a13:27c0:30::105를 제공했습니다. 두 재귀 리졸버 모두 해당 호스트명에 대해 동일한 현재 AAAA 주소를 제공했습니다. IANA의.ps위임 페이지에도 같은 주소가 표시되었고 페이지 수준 업데이트 날짜는 9월 8일이었습니다.

나머지 세 개는 여전히 갈라져 있었습니다. 루트는.ne에 대해2001:67c:e0::101,.sd에 대해2001:67c:e0::109,.tj에 대해2001:67c:e0::117을 제공했고, 해당 호스트명 응답은 각각2a13:27c0:30::101,::109,::117이었습니다. 이들의 IPv4 글루와 호스트명 주소는193.0.9.101,.109,.117에서 서로 일치했습니다.

유용한 결론은 절제된 결론입니다. 8월의 네 개 불일치가 세 개가 되었다는 것. 이 관측은.ps변경을 누가 제출했고 누가 승인했는지, 또는 루트가 언제 처음 그것을 서빙했는지 식별하지 않습니다. 페이지 수준 업데이트 날짜는 어떤 필드가 바뀌었는지 알려주지 않습니다. 그러나 이 차등적 결과는 명시된 통제 경로와 부합합니다. 한 TLD 관리자는 승인된 변경을 완료할 수 있고, 다른 세 개의 위임 레코드는 서로 다른 상태에 남을 수 있습니다.

연속성이 곧 정확성은 아니다

RIPE NCC는 영향을 받은 모든 위임에 작동하는 IPv6 글루 레코드가 최소 하나, 작동하는 IPv4 글루 레코드가 여러 개 있어 리졸버가 위임을 따라가며 이름을 해석할 수 있다고 밝혔습니다. 불일치 자체를 서비스 중단이라고 부르는 데 강력히 반하는 증거입니다.

이 연구는 이전 IPv6 주소로 어떤 패킷도 보내지 않았습니다. 도달 가능성, 재시도 지연, 사용자에게 보이는 영향을 측정하지 않았습니다. 라임 위임, DNSSEC 실패, 리졸버 실패, 권위 서비스 상실을 주장할 근거를 찾지 못했습니다. 대체 글루는 연속성 통제이며, 모든 리졸버가 지연 없이 같은 경로를 선택했다는 증명이 아닙니다.

이 구분은 경보가 교훈을 파괴할 수 있기 때문에 중요합니다. 이전 글루는 수정되어야 하며, 특히 이전 프리픽스가 철회된 후에 그렇습니다. 그러나 루트가 승인되지 않은 변경을 거부하는 것도 안전 속성입니다. 운영 목표는 “네 행을 한꺼번에 바꾸는 것”이 아니라, “서비스와 증거 궤적을 보존하면서 승인된 모든 행을 수렴시키는 것”입니다.

오래된 종결은 현재의 대기열이 아니다

IANA의 2025년 7월 루트 운영 감사는 네 개 호스트명 모두와 관련된 네임서버 변경 요청이 2025년 7월 18일자로Administratively Closed(행정 종결)로 기록되어 있음을 보여줍니다. 이 표는 각 종결의 사유를 밝히지 않습니다. 이 항목들은 과거의 결과이며, RIPE NCC가 언급한 이후 요청에 대한 실시간 상태판으로 취급될 수 없고, 이후의.ps정합을 설명하지도 않습니다.

바로 이 때문에 배치 모양의 서사는 부적절합니다. 공개 감사는 오래된 요청이 끝났다는 것을 보여줄 수 있습니다. 위임 페이지는 현재 어떤 데이터가 게시되는지 보여줍니다. DNS 질의는 어느 한 순간 서버가 무엇을 반환했는지 보여줍니다. 그중 어느 하나만으로 요청자, 관리자의 승인, 기술 검사, 처리 결과, 관측된 루트 결과를 하나의 사례 이력으로 묶을 수 없습니다.

각 위임에 자체 접수증을 부여하라

프라이버시에 안전한 접수증은 TLD, 네임서버 호스트명, 이전 주소와 요청된 주소, 요청자 역할, 공개에 안전한 요청 식별자, TLD 관리자 승인 상태와 타임스탬프, 기술 검사 결과, 최종 상태, 사유 범주를 담아야 합니다. 여기에 루트 존 시리얼 또는 관측 시각, 현재 서빙 중인 글루, 다음 조치, 그리고 대체되는 요청이 있으면 더합니다.

개인 연락처 정보는 노출될 필요가 없습니다. 접수증이 외부인에게 TLD 관리자를 우회하도록 유도해서도 안 됩니다. 그 목적은 더 좁습니다. 운영자, 관리자, 감사자가 “승인 대기”를 “기술 검사 실패”, “철회”, “구현됨”, “대체됨”과 구별할 수 있게 하는 것입니다.

RIPE 91 회의록은 재번호화를 운영 개선으로 기술하고, 종료 후 이전 IPv6 주소로 전송된 질의를 후속 조치 가능성을 위해 캡처하겠다는 계획을 기록합니다. 그 관측은 계속되는 사용을 식별할 수 있습니다. 위임별 접수증은 그 사용을 퇴역시키는 데 필요한 권한과 결정을 식별할 수 있습니다. 둘을 합치면 정확하지 않은 정리 목록이 네 개의 책임 있는 경로가 됩니다.

이제 산술은 3이라고 말합니다. 그러나 거버넌스는 여전히 네 개의 사례라고 말합니다.

출처