.RU 2024 DNSSEC 롤오버 실패가 존 서명 검증을 책임성 시험으로 만든 이유

요약

• 2024년 1월 30~31일의.RU 사건은.RU 국가코드 최상위 도메인에서 발생한 DNSSEC 서명 실패였으며, 입증된 공격, 파괴 행위, 검열 조치, 러시아 인터넷 전역의 장애, 또는 DNSSEC 프로토콜 자체의 일반적 실패가 아니었다. 공식 기술 경계는 더 좁다. 계획된 존 서명 키(zone-signing-key, ZSK) 롤오버가 검증 확인자(validating resolver)가 거부하도록 되어 있던 비일관적 서명 존 상태를 만들었다는 것 [2][5].
• 공식 포스트모템에 보고된 주요 공개 장애 구간은 2024년 1월 30일 모스크바 기준 18:28~21:00이었다. 이 구간은 사용자에 대한 영향이 제거된 기간을 설명하며, 같은 기록은 근본적인 키 상태 교정과 정상 공개 모드 복귀가 1월 31일까지 이어졌다고 별도로 밝히고 있다 [5].
• 롤오버 순서가 중요하다. 계획된.RU ZSK 교체는 1월 24일에 시작되었고, 새 공개 키 자료는 1월 26일에 공개되었으며, 1월 30일에 구 키가 비활성화되고 새 키가 활성화되었다. 따라서 실패는 예정된 보안 유지보수 조치에 위치하며, 등록인의 일반적인 네임 호스팅에 있지 않았다 [5].
• 공식 설명에 따르면 시스템 내 두 키 쌍이 동일한 키 태그(key tag)를 가졌다. 이는 키가 동일하다는 뜻이 아니다. 키 태그는 후보 DNSKEY 레코드를 식별하는 데 도움을 주지만, 어떤 공개 키가 특정 RRSIG를 만든 개인 키에 대응한다는 암호학적 증명은 아니다. 이 경우 서명은 구 개인 키로 생성되었는데 존에는 새 공개 키가 나타났으므로, 키 태그가 일치하더라도 검증이 실패할 수 있었다 [5][14].
• 재귀 DNSSEC 검증이 숨겨진 서명 불일치를 가시적 실패로 만들었다. 검증 확인자는 인증 체인을 확인할 수 없는 데이터를 거부하도록 되어 있다. 그래서 SERVFAIL 증거가 중심적이다. 이는 위조 DNSSEC 데이터에 대한 fail-closed 확인자 동작을 가리키며, 모든 하위.RU 웹·메일·애플리케이션 서버가 멈췄다는 증명이 아니다 [7][13][15].
• Cloudflare는 피크 시 자사 확인자 요청의 68.4%가.RU 네임에 대해 SERVFAIL을 반환했다고 보고했다. 이는 중요한 외부 텔레메트리이지만 하나의 공개 확인자 환경과 그 관측 트래픽 구성에 한정된다. 이를 전체 러시아 사용자, 전체 확인자, 전체.RU 도메인 또는 전체 인터넷 서비스의 비율로 환산할 수 없다 [7].
• 러시아 국가 도메인 네임 시스템(National Domain Name System) 확인자에서 DNSSEC 검증을 긴급 비활성화한 것은 보안 비용을 수반하는 가용성 조치였다. 사용자가 다시 네임에 도달하도록 도울 수 있었지만, 서명된.RU 존이 정확하다는 것을 증명하지는 못했다. 따라서 이후 검증 재활성화는 책임성 기록의 일부이며 부수적 세부사항이 아니다 [3][5].
• 책임 있는 통제 표면은 서명 공개 체인이다. 키 인벤토리, 키 선택, 서명, 공개 전 암호학적 검증, 활성화, 롤백, 확인자 정책, 교정 증거가 그것이다. 등록인과 최종 사용자는 무효한 상위 존 보안 메타데이터의 영향을 받을 수 있었지만, 상위 존의 DNSKEY와 RRSIG 불일치를 복구할 수는 없었다 [5][19].
• 조정센터(Coordination Center)는.RU의 공개 레지스트리이자 행정 참조 지점이며, 공개 기록은 복원 작업에서 Technical Center of Internet과 MSK-IX도 언급한다. 제공된 증거는 소프트웨어 소유권, 승인 권한, 모니터링 임계값, 키 스토어 상태, 개별 결정 책임을 완전히 배분하지 않으므로, 이 글은 과실이나 법적 책임을 만들어내지 않으면서 통제를 매핑해야 한다 [1][2][19].
• 지속 가능한 교훈은 공개 전 검증이다. 레지스트리 위임 원장은 재귀 확인자가 실제로 검증하는 바이트에서 정확해야 한다. 중복 권위 서버, 문서화된 롤오버 캘린더, 사후 성명은 충돌 없는 키 식별, 독립적인 서명 존 linting, 카나리아 검증, 검증된 롤백, 긴급 검증 우회가 되돌려졌다는 증거를 대체할 수 없다 [12][16][17][20].

이 사건이 네트워크 책임성에 속하는 이유

2024년 1월의.RU 사건은 실패가 레지스트리 거버넌스와 가동 중인 DNS 인프라의 경계에 놓여 있었기 때문에 책임성 사례이다. 국가코드 최상위 도메인은 단순한 웹사이트나 기업 애플리케이션이 아니다. 그것은 등록인, 재귀 확인자, 네트워크 운영자, 호스팅 제공자, 그리고 레지스트리의 내부 서명 시스템과 직접 관계가 없는 일반 사용자가 사용하는 상위 존 위임 및 보안 메타데이터 계층이다. 그 상위 존 계층이 내부적으로 불일관한 DNSSEC 아티팩트를 공개하면, 많은 하위 당사자가 서명 키, 존 생성 로직, 검증 정책 또는 롤백 결정을 통제할 수 없이 경성 실패를 겪을 수 있다.

이것을 실용적 통제 질문으로 만든다. 키 저장소는 누가 통제했는가? 서명에 사용된 키를 선택한 소프트웨어나 구성은 누가 통제했는가? 공개 전에 DNSKEY 레코드와 RRSIG 레코드가 일치함을 누가 확인했는가? 새 상태가 활성화되는 시점을 누가 결정했는가? 서명 존이 배포된 후 검증기 결과를 누가 모니터링했는가? 검증된 상태로 롤백할 수 있는 이는 누구인가? 확인자 환경에서 일시적으로 검증을 비활성화할 수 있는 이는 누구인가? 그리고 서비스가 복원된 후 근본 오류가 캐시 동작이나 긴급 확인자 정책에 의해 단지 가려진 것이 아니라 교정되었음을 누가 증명할 수 있는가?

공개 답은 부분적으로 존재하고 부분적으로 알려져 있지 않다. 조정센터는 공개 성명을 발표했고.RU의 레지스트리 측 제도적 참조 지점으로 남아 있다. 그 초기 성명은 정상 운영 복원에 관여한 기술 운영자 중 Technical Center of Internet과 MSK-IX를 명명했다 [1]. 영어 원인 진단 성명과 공식 포스트모템은 DNSSEC 롤오버 실패, 키 태그 충돌, 복원 조치, 제한적 교정 성명을 기술한다 [2][5]. IANA 루트 위임 레코드는 별도로.RU를 전역 루트 데이터베이스에 고정시키며, 이 위임을 일반 호스팅 서비스가 아닌 상위 존 레코드로 식별한다 [19]. 이 기록들은 통제 표면 지도를 뒷받침한다. 개인의 비난, 고의적 위법, 법적 위반에 대한 주장은 뒷받침하지 않는다.

이 사건은 실패 양상이 인프라 회복력에 대한 흔한 안도 서사를 무너뜨리기 때문에 네트워크 책임성에 속한다. 권위 서버 중복성은 필요하지만, 나쁜 서명 아티팩트를 유효하게 만들 수는 없다. 모든 권위 서버가 동일한 내부 불일관 존을 제공하면, 중복성은 무효한 상태를 효율적으로 분배할 수 있다. 검증 확인자는 권위 서버의 수를 인증하지 않는다. 수신한 답에 대한 DNSSEC 체인을 인증한다. 서명이 공개된 키와 맞지 않으면 확인자는 데이터를 거부해야 한다. 그래서.RU 사건은 일반적인 가동시간 이야기가 아니다. 그것은 서명 바이트 정확성 이야기이다.

경계는 좁게 유지되어야 한다. 이 글은 2024년 1월 30~31일의.RU ccTLD DNSSEC ZSK 롤오버 실패와 그 공개 증거에 관한 것이다. 다른 레지스트리와 결함 있는 공개 이력이 관여한 2009년.se 사건과 구별된다. 2019년 8월의.RU 장애와도, 이후 또는 별개의 DENIC 보도와도, 그리고 중심 메커니즘이 키-서명 일관성이 아니라 트래픽 포화 또는 분산 서비스 회복력인 루트 DNS DDoS 사건과도 구별된다. 국가 네트워크 통제에 관한 정치적 논쟁과도 구별된다. 일부 보도는 이해할 수 있게 이 사건을 더 넓은 러시아 인터넷 맥락에 놓았지만, 여기에 문서화된 실패 메커니즘은 DNSSEC 서명·검증 문제이며 고의적 접속 차단이나 검열의 증명이 아니다 [6][9][10][11].

롤오버 연대기

가장 강력한 연대기는 DNS 운영 커뮤니티에 배포된 공식 기술 포스트모템과 사건 전후의 레지스트리 및 정부 성명에서 나온다..RU 운영자는 사전 공개(pre-publish) 절차로 연간 4회 존 서명 키를 교체했다. 그러한 절차에서는 새 공개 키가 서명 검증에 사용되기 전에 도입되어, 확인자와 캐시가 활성화 전에 예정된 키 자료를 볼 수 있게 한다. 포스트모템에 따르면 관련 순서는 1월 24일에 계획된 ZSK 롤오버가 시작되면서 시작되었다. 1월 26일 새 공개 자료가 공개되었다. 1월 30일 구 ZSK가 비활성화되고 새 ZSK가 활성화되었다 [5].

중요한 점은 이것이 DNS 서버의 갑작스러운 부재가 아니었다는 것이다. 그것은 상위 존에서 예정된 보안 유지보수 변경이었다. 캘린더 자체는 과실을 증명하지 않는다. 정기적 키 교체는 정상적인 DNSSEC 운영이다. 책임성 질문은 새 상태가 활성화되는 시점에 실제 키 상태, 서명 생성, DNSKEY 공개, 검증 검사가 내부적으로 일관되었는가이다. 반복적 유지보수 주기는 공개되는 실제 암호학적 아티팩트에 대한 엄격한 검증이 결합될 때만 놀라움을 줄일 수 있다.

공식 포스트모템은 가시적 문제의 시작을 1월 30일 모스크바 기준 18:28, 즉 새 롤오버 상태에서 서명된 존이 공개된 후로 잡는다. 모니터링은 그 공개 후 문제를 감지했다. 같은 기록은 19:29에.RU에 대한 DNSSEC 검증이 러시아 국가 도메인 네임 시스템 확인자에서 일시 비활성화되었다고 말한다. 21:00에 운영자는 이전 존 파일·키 상태를 복원하고 정상.RU 운영을 보고했다. 그 국가 시스템 확인자의 검증은 1월 31일 01:07에 재활성화되었다. 갱신된.RU 존의 배포는 1월 31일 17:21에 시작되었고 정상 공개 모드는 17:58에 재개되었다 [3][5].

이 시각들은 두 가지 다른 종결 개념을 만든다. 첫째는 사용자 대면 가용성 완화이다. 공식 기록은 주요 사용자 대면 영향이 모스크바 기준 18:28~21:00 사이 약 2시간 30분 만에 제거되었다고 제시한다. 둘째는 근본 원인 교정과 정상 공개 상태 복귀로, 다음 날까지 이어졌다. 진지한 사후 책임성 기록은 둘 다 보존해야 한다. 이 사건을 단지 2시간 30분짜리 사건이라 부르면 키 상태 원인을 정상화하는 데 필요한 시간이 가려질 수 있다. 하루 종일의 총 장애라 부르면 출처가 확립하는 것을 과장하게 된다.

같은 포스트모템은 존 파일 생성 자체는 멈추지 않았다고 말한다. 미묘하지만 중요한 지점이다. 시스템은 그 존 내부의 보안 메타데이터가 검증기에 잘못된 상태에서도 존을 계속 생성·제공할 수 있었다. 또한.ДЕТИ와.TATAR를 제공하는 서버가 일시적 성능 저하를 겪었다고 말한다. 그 성명은 운영자 주장으로 취급해야 하며, 형제 존들에 대한 완전한 독립 측정으로 취급해서는 안 된다. 제공된 패킷은 완전한 쿼리 로그, 모든 확인자 모집단, 캐시 동역학, 지리적 분포, 서비스 수준 손실, 모든 하위 영향의 독립 검증을 노출하지 않는다 [5].

사건을 둘러싼 공개 보도는 대체로 DNSSEC에 뿌리를 둔 설명과 부합한다. The Record는.RU 최상위 도메인과 공식 DNSSEC 성명의 관점에서 장애를 기술했다 [9]. Meduza는 검증기 동작과 러시아 국가 도메인 네임 시스템의 별개 역할을 설명하면서, 기술적 실패와 혼동되어서는 안 될 더 넓은 정책 환경도 논의했다 [10]. RBC는 운영자 포스트모템과 서명 시스템 결함의 세부를 보도했다 [11]. 이후 각부 보도는 외부 개입이 확인되지 않았다고 밝혔으며, 이 경계는 이후 공개 보도에도 반영되어 있다 [8][21]. 이 기록들은 기술적 실패 서사를 뒷받침한다. 공격 귀속은 뒷받침하지 않는다.

서명 존 내부에서 무엇이 실패했는가

DNSSEC는 단순한 서버 가용성이 아니라 인증된 부인(authenticated denial)과 인증된 답을 중심으로 구축된다. 단순화하면, 존은 DNSKEY 자료와 리소스 레코드 세트에 대한 서명을 공개한다. 검증 확인자는 수신한 답이 예상 체인을 통해 인증될 수 있는지 검사한다. 체인을 검증할 수 없으면 확인자는 아무 일도 없었던 것처럼 데이터를 조용히 수락해서는 안 된다. 표준은 DNSSEC가 DNS에 인증과 무결성 서비스를 추가한다고 서술하면서, 특정 검증 결과와 운영 한계를 명확히 한다 [13][15].

공식.RU 설명에 따르면 실패는 시스템 내 두 키 쌍이 동일한 키 태그를 가진 데서 비롯되었다. 시스템은 구 개인 키로 서명을 생성하면서 존에는 새 공개 키를 배치했다. 이것이 실용적 불일치를 만들었다. 확인자는 키 태그가 후보 DNSKEY 값을 가리키는 서명과 마주칠 수 있었지만, 존 내 공개 키는 대응하는 개인 키가 서명 생성에 사용된 키가 아니었기 때문에 그 서명을 암호학적으로 검증하지 못할 수 있었다 [5].

그래서 키 태그 언어는 정밀해야 한다. RFC 4034는 DNSKEY와 RRSIG 필드를 정의하고, 키 태그를 서명을 검증할 수 있는 DNSKEY 선택을 돕는 데 사용되는 식별자로 설명한다 [14]. 키 태그는 완전한 신원 증명이 아니다. 두 키가 같다는 보장이 아니며, 충돌에 면역인 지문도 아니다. 키 태그 충돌은 잘못된 키 선택을 운영상 가능하게 만들 수 있지만, 최종 시험은 여전히 실제 공개 키와 서명 데이터에 대한 암호학적 검증이다..RU 사건에서 문제는 DNSSEC 수학이 작동을 멈춘 것이 아니었다. 문제는 공개된 존과 서명 상태가 검증기가 거부하는 것이 옳은 방식으로 불일관하게 된 것이었다.

이 구별은 책임성 요구를 바꾸기 때문에 중요하다. 레지스트리가 롤오버 절차를 따랐다고 말하는 것만으로는 충분하지 않다. 증명은 실제 바이트를 다뤄야 한다. 존에 존재하는 DNSKEY 레코드, 관련 레코드 세트에 대한 RRSIG 레코드, 키 식별자, 저장된 키 자료, 서명자가 사용한 개인 키 선택, 독립 확인자 구현의 검증 결과가 그것이다. 질문은 단순히 캘린더 이벤트가 발생했는가가 아니다. 질문은 활성화가 규격에 부합하는 검증 확인자가 인증할 수 있는 서명 아티팩트를 공개했는가이다.

잘못된 교훈이 보안을 약화시키기 때문에 이것도 중요하다. 공개 서사가 “DNSSEC가 장애를 일으켰다”가 되면, 운영자는 검증을 위험으로 취급할 수 있다. 그러나 더 안전한 해석은 검증이 무효한 서명 상태를 드러냈다는 것이다. 위조 DNSSEC 데이터에 대해 실패를 반환하는 확인자는 보안 기능을 수행하고 있다. 운영적 고통은 실재하지만, 그것은 검증될 수 없는 보안 메타데이터를 공개하는 고통이다. 통제 문제는 공개 이전, 즉 키 상태 검증과 서명 존 linting에 있으며, 사후에 검증기를 더 관대하게 하라는 데 있지 않다 [13][15][16].

표준은 이 운영 틀을 강화한다. RFC 6781은 DNSSEC 운영 관행과 롤오버 고려사항을 논의하고, RFC 7583은 키 수명 주기 개념과 키를 무차별적 레이블이 아닌 키 상태로 다뤄야 할 필요성을 제시한다 [16][17]. RFC 5011은 대조적으로 유용하다. 그것은 자동화된 트러스트 앵커 갱신 동작에 관한 것이며, 이.RU ZSK 불일치와 혼동되어서는 안 된다 [18]. 공개 기록에서.RU 사건은 루트 트러스트 앵커 갱신 실패가 아니었다. 그것은 서명과 공개 키 상태가 맞지 않은 상위 존 ZSK 롤오버 실패였다.

확인자 동작과 긴급 트레이드오프

확인자 계층은 숨겨진 서명 존 불일치가 사용자에게 가시화되는 곳이다. 사용자는 보통 RRSIG 레코드, DNSKEY 값, 키 태그를 보지 못한다. 사용자는 확인되는 네임 또는 로드되지 않는 서비스를 본다. 검증 재귀 확인자는 그 두 세계 사이에 있다. 확인자가 위조로 간주하는 DNSSEC 데이터를 수신하면, 인증할 수 없는 답을 돌려주는 대신 SERVFAIL을 반환할 수 있다. 그래서 SERVFAIL에 관한 외부 텔레메트리가 이 글과 관련된다 [7][15].

Cloudflare의 분기별 장애 요약은 사건 중 피크 시 자사 확인자의.RU 네임 요청 68.4%가 SERVFAIL을 반환했다고 보고했다 [7]. 이는 중요한 공개 재귀 확인자로부터의 큰 신호이다. 동시에 한정된 신호이기도 하다. 그것은 Cloudflare가 관측한 확인자 트래픽, 즉 사용자가 질의한 네임, 재시도 패턴, 캐시 상태, 클라이언트 분포, 기타 확인자 환경 특성을 반영한다. 전체.RU 도메인의 인구조사가 아니며, 전체 러시아 사용자 수도 아니고, 모든 확인자 뒤의 모든 사용자가 실패를 보았다는 증명도 아니고, 질의된 도메인의 하위 웹·메일 서버가 다운되었다는 증명도 아니다.

정부 네트워크 운영 통지는 또 하나의 계층을 더한다. 그것은 DNS 서버 운영 중 사건을 기술하고 일부 청중의 접속 어려움을 언급했다. 공식 기술 연대기는 이어서 19:29에 러시아 국가 도메인 네임 시스템 확인자에서.RU에 대한 검증이 일시 비활성화되고 1월 31일 01:07에 재활성화되었다고 말한다 [3][5]. 그 선택은 긴급 보안·가용성 트레이드오프로 이해하는 것이 타당하다. 서명 데이터가 깨졌을 때 검증 비활성화는 도달성 복구에 도움이 될 수 있다. 동시에 DNSSEC이 그 검증 결정을 위해 제공하도록 설계된 진위 보호를 제거한다.

그 트레이드오프는 성공으로 재서술되어서는 안 된다. 확인자가 DNSSEC 검증이 비활성화된 후에만 답에 도달한다면, 서명 존이 정확함이 증명된 것이 아니다. 긴급 조치는 가용성 압박 아래 정당화될 수 있지만 보안 자세를 바꾼다. 따라서 책임성은 도달성이 돌아왔다는 증거뿐 아니라 검증이 재활성화되었고 서명 존 상태가 다시 검증을 통과할 수 있었다는 증거를 요구한다. 01:07 재활성화 시각과 1월 31일 정상화 이정표가 중요한 이유는, 긴급 우회가 명시된 종점으로 남지 않았음을 보여주기 때문이다 [5].

국가 시스템 밖의 확인자 운영자는 다른 결정을 할 수 있었다. 어떤 이들은 서명 데이터가 다시 유효해지거나 캐시가 바뀔 때까지 검증을 계속하고 SERVFAIL을 반환할 수 있었다. 어떤 이들은 확인자별 우회를 가질 수 있었다. 일부 사용자는 특정 네임에 대해 캐시 상태로 보호받을 수 있었고, 다른 이들은 서명이 실패한 네임을 반복 질의할 수 있었다. 이러한 차이가 이 글이 전역 장애를 주장해서는 안 되는 이유이다. 공개 증거는 주요 확인자 텔레메트리에 가시적이고 청중의 일부에 영향을 준 실질적 검증 관련 장애를 뒷받침한다. 단일 전역 영향 비율은 뒷받침하지 않는다.

따라서 올바른 통제 지도는 확인자 정책을 포함하되 모든 책임을 확인자로 옮기지는 않는다. 검증 확인자의 무효 데이터 인증 거부는 예상되는 동작이다. 불일치 DNSSEC 자료의 상위 공개가 여전히 트리거이다. 확인자 계층은 오류를 가시화했고, 한 명명된 환경에서 검증이 일시 비활성화되면서 완화의 일부가 되었다. 두 계층 모두 중요하지만 동일한 통제를 보유하지는 않는다.

영향 증거와 그 한계

공개 영향 증거는 심각한 네트워크 인프라 사건을 확립하기에는 충분하고, 전체 손실을 확립하기에는 너무 한정적이다. 공식 성명은 러시아 인터넷 청중의 일부에 대한 올바른 네임-주소 확인 문제, 주요 장애 구간, 복원 조치를 기술한다 [1][2][5]. 정부 통지는 접속 어려움과 검증 처리에 관한 공식 네트워크 운영 관점을 더한다 [3]. Cloudflare는 주요 외부 확인자 측정을 제공한다 [7]. The Record, Meduza, RBC의 보도는 당시 및 포스트모템 맥락을 제공하며, 이후 Interfax와 Rossiyskaya Gazeta의 보도는 외부 개입이 발견되지 않았다고 전함으로써 공격 귀속의 경계를 돕는다 [8][9][10][11][21].

이 출처들은 몇 가지 확고한 결론을 뒷받침한다. 첫째, 사건은 실재했고 사용자와 확인자에게 가시적이었다. 둘째, 메커니즘은.RU ZSK 롤오버 중 DNSSEC 서명 불일치였다. 셋째, 검증 확인자는 결과 데이터를 거부할 수 있었다. 넷째, 긴급 및 롤백 조치가 취해졌다. 다섯째, 공식 공개 기록은 외부 공격을 증명하지 않는다. 여섯째, 기록은 중요한 측정을 미공개로 남긴다.

미공개 측정이 중요하다. 공개 패킷은 영향받은 모든 확인자 모집단을 식별하지 않는다. 확인자·지역·도메인별 완전한 질의 수를 제공하지 않는다. 사용자 경험을 형성한 정확한 캐시 상태를 공개하지 않는다. 모든 하위 서비스 범주를 분리하지 않는다. 등록인이나 호스팅 제공자의 사업 손실을 정량화하지 않는다. 전체 내부 사건 로그를 보여주지 않는다. 검증 때문에 실패를 본 사용자와 재시도 폭풍, 확인자 구성, 캐시된 부정 답, 기타 국지 조건으로 영향받은 사용자를 구분하지 않는다.

그 부재가 사건을 사소하게 만들지는 않는다. 그것은 이 글이 존재하는 증거와 존재해야 할 증거를 통해 책임성을 측정해야 함을 뜻한다. 최상위 도메인 레지스트리는 서비스별 손실 수치를 공개할 수 없으면서도 광범위한 하위 결과를 초래할 수 있다. 반대로 언론인과 분석가는 그 공백을 전역적 주장으로 채워서는 안 된다. 상위 존 DNSSEC 실패가 청중의 일부에 영향을 주었다고 말하는 것이 러시아 인터넷 전체가 불가용했다고 말하는 것보다 정확하다. Cloudflare가.RU 요청에 대해 68.4%의 피크 SERVFAIL 비율을 보았다고 말하는 것이 전체 사용자의 68.4%가 실패했다고 말하는 것보다 정확하다 [7].

영향 경계는 또한 확인 실패와 하위 서비스 실패를 분리한다. 사용자가 DNSSEC 검증 실패 때문에 네임을 확인할 수 없다면, 그 사용자의 관점에서 서비스는 불가용해 보일 수 있다. 그러나 원본 웹 서버, 메일 교환기 또는 애플리케이션 백엔드는 여전히 작동 중일 수 있다. 상위 존 서명 아티팩트는 하위 수준 서비스 자체가 고장 나지 않았음에도 유효한 답이 수락되지 못하게 할 수 있다. 이 구별은 책임성에 중심적이다. 레지스트리 수준 메타데이터 오류가 상위 존 서명 상태를 통제하지 않는 등록인에게 도달성 실패를 강요할 수 있음을 보여주기 때문이다.

2024년 1월의.RU 사건은 또한 근접한 이야기를 흡수해서는 안 된다. 2009년.se 사건은 레지스트리 공개 오류가 네임스페이스 전역 결과를 낳을 수 있음을 일깨워주지만, 다른 기술적 기록에 관한 것이었다. DENIC 보도는 다른 레지스트리와 다른 사건에 관한 것이다. 루트 DNS DDoS 사건은 분산 서비스 용량과 공격 트래픽에 관한 회복력 질문을 제기하며, 불일치 보안 메타데이터를 공개한 ZSK 롤오버에 관한 것이 아니다. 2019년 8월의.RU 사건은 이 기록에 혼합되어서는 안 된다. 정치적 네트워크 통제 논쟁은 이 사건이 주목받은 이유를 설명할 수 있지만, DNSSEC 실패 메커니즘의 증명은 아니다 [6][10].

통제 지도: 누가 무엇을 바꿀 수 있었는가

유용한 책임성 글은 비난이 아니라 능력에서 시작한다. 첫 번째 능력은 상위 존에 대한 레지스트리 거버넌스이다. 조정센터(Coordination Center)는.RU의 공개 행정·정책 참조 지점이며, IANA 루트 데이터베이스가 최상위 도메인의 루트 위임 레코드를 제공한다 [19]. 조정센터의 성명과 연차 보고는 1월 30일 사건을 공개 운영 기록에 배치한다 [1][2][20]. 이는 모든 기술적 행위가 동일한 법인에 의해 수행되었다는 뜻이 아니다. 레지스트리 계층이 상위 존 위임과 DNSSEC 보안 메타데이터를 대표하므로 공개 책임성이 그 계층에 귀속됨을 뜻한다.

두 번째 능력은 서명과 공개의 기술 운영이다. 공개 기록은 복원에 관여한 기술 운영자 중 Technical Center of Internet과 MSK-IX를 명명한다 [1]. 공식 포스트모템은 키 상태 실패와 복원 순서를 기술하지만, 소프트웨어 이름·버전, 정확한 결함 있는 선택 규칙, HSM 또는 키 스토어 상태, 내부 승인 체인을 노출하지 않는다 [5]. 따라서 이 글은 서명·공개 통제 표면이 실패했다고 말할 수 있다. 특정 벤더, 엔지니어, 법적 위반자를 책임감 있게 명명할 수는 없다.

세 번째 능력은 공개 전 검증이다. 서명 환경을 통제한 이는 RRSIG 레코드 생성에 사용된 개인 키가 검증기가 사용할 수 있는 공개된 DNSKEY에 대응함을 증명할 수 있어야 했다. 그 증명은 키 태그만으로 독립적이어야 한다. 키 인벤토리, 충돌 감지, 후보 서명 존의 전체 검증, 둘 이상의 검증기 구현에 의한 시험이 포함되어야 한다. DNSViz는 사건과 키 교체 이후 외부 검증 체인 증거를 제공하지만, 사후 관측은 공개 전 게이트 증거를 대체할 수 없다 [12].

네 번째 능력은 활성화 통제이다. 계획된 롤오버는 시작, 공개 키 공개, 활성화에 별개 날짜를 가졌다 [5]. 그 순서는 새 상태가 활성화되는 결정 지점을 함축한다. 훌쩍은 책임성 기록은 활성화 전 요구 조건, 승인에 제시된 증거, 검증 신호가 악화될 경우의 롤백 기준을 식별할 것이다. 공개 기록은 그 수준의 내부 세부를 제공하지 않는다. 문제가 감지된 후 무슨 일이 있었는지만 기술한다.

다섯 번째 능력은 확인자 정책이다. 국가 도메인 네임 시스템 확인자 환경은.RU에 대한 검증을 일시 비활성화하고 이후 재활성화할 수 있었다 [3][5]. 그 행위는 중요했지만 서명 존을 고치는 통제와는 같지 않았다. 확인자 운영자는 fail-closed할지, 긴급 우회를 적용할지, 상위 복구를 기다릴지 결정할 수 있다. 무효한 상위 존 서명을 유효하게 만들 수는 없다. 따라서 그들의 책임성은 정책, 커뮤니케이션, 측정, 검증 복원에 관한 것이며, 원래의 키 불일치에 관한 것이 아니다.

여섯 번째 능력은.RU 아래의 등록인, 호스팅 제공자, 애플리케이션 운영자에게 속한다. 그들은 자신의 네임서버, 호스팅, 메일, 웹 애플리케이션, 인증서, 연속성 계획을 통제한다. 실패를 모니터링하고, 사용자와 소통하고, 때로 대체 접속 안내를 제공할 수 있다. 그러나 상위 존 DNSKEY와 RRSIG 불일치를 교정할 수는 없다. 상위 존이 검증기가 인증할 수 없는 보안 메타데이터를 공개하면, 올바르게 구성된 하위 도메인도 검증 사용자에게는 도달 불가능할 수 있다. 이 비대칭이 사건이 레지스트리 거버넌스에 중요한 이유이다.

일곱 번째 능력은 사용자에게 속한다. 최종 사용자는 재시도하거나, 네트워크를 바꾸거나, 다른 확인자를 사용할 수 있지만, 대부분은 상위 존 키 상태를 검사할 수 없다. 그들은 네임을 작동 또는 고장으로 경험한다. 책임성은 핵심 실패를 사용자에게 귀속시킬 수 없다. 사용자는 서명 존 공개도 확인자 보안 정책도 통제하지 않았기 때문이다. 그러나 사용자 경험은 여전히 중요하다. 사용자 대면 결과가 암호학적 불일치를 공개 인프라 사건으로 만들기 때문이다.

레지스트리 기록은 원장, 서명 바이트는 현실

레지스트리 위임 레코드는 네임스페이스의 원장으로 기능한다. 어떤 위임 데이터와 보안 메타데이터가 확인의 다음 단계를 승인하는지 기록한다. 그 원장 역할은 의례적이 아니라 실용적이다. 레코드가 DNSKEY가 서명을 검증해야 한다고 말하면, 검증기는 키 자료와 서명 사이의 실제 관계를 시험한다. 제도적 의도를 암호학적 유효성의 대체물로 수락하지 않는다.

여기서 가동 아티팩트가 서면 절차를 지배한다. 예정된 롤오버는 문서화될 수 있다. 구·신 키는 기대 역할을 가질 수 있다. 레지스트리는 캘린더를 가질 수 있다. 권위 서버 플릿은 중복될 수 있다. 그러나 존이 공개되면, 현실 계층은 DNSKEY 레코드, RRSIG 레코드, 위임 상태, 캐시 동작, 확인자 검증 사이의 바이트 수준 관계이다. 그 바이트들이 불일관하면, 모든 조직 문서가 절차가 작동했어야 한다고 말하더라도 사용자는 실패를 볼 수 있다.

이것이 레지스트리가 진실에 대해 주권적이라는 뜻은 아니다. 레지스트리는 공개할 것을 결정할 수 있지만, 무효한 서명을 유효하다고 명할 수는 없다. DNSSEC는 최종 인증 결정을 확인자가 수행하는 암호학적 검사로 밀어 넣는다. 따라서 공개 인프라 계약은 명성보다 엄격하다. 그것은 레지스트리가 공개 시점에 보안 메타데이터가 정확함을, 롤백 상태가 도달성과 진위성을 모두 복원함을 증명할 것을 요구한다.

.RU 사건은 이 원장 원리의 간결한 삽화이다. 공식 이야기는 권위 서비스가 존재를 멈춘 것이 아니다. 서명 아티팩트가 검증기가 감지한 방식으로 잘못되었다는 것이다. 여러 권위 서버가 동일한 무효 상태를 제공할 수 있다. 네임은 작동을 계속하는 등록인 관제 호스팅을 가질 수 있다. 확인자는 완전히 기능할 수 있다. 그러나 상위 존 보안 메타데이터가 검증되지 않으면 체인이 실패할 수 있다. 책임성은 그 상위 존 원장과 검증되었음의 증거에 대한 실질적 통제를 가진 당사자를 따른다.

교정 성명은 유용하지만 한정적이다. 그것은 키 저장소 데이터가 정상화되었고, 검사·공개 절차와 사용된 소프트웨어가 개선될 것이라고 말한다 [2][5]. 그것은 방향의 약속이지 완전한 공개 증명 패킷이 아니다. 정상화 이후의 키 인벤토리, 시험 스위트, 검증기 다양성, 카나리아 결과, 롤백 리허설 증거, 승인 임계값, 이후 독립 감사를 공개하지 않는다. 이런 종류의 사건 후 지속 가능한 신뢰를 원하는 레지스트리는 비밀을 노출하지 않으면서 동일 실패 등급이 폐쇄되었음을 보여줄 만큼 충분한 기술적 증거를 공개할 수 있어야 한다.

향후 롤오버를 위한 검증 게이트

첫 번째 게이트는 충돌 없는 키 식별이다. 새 롤오버 상태를 공개하기 전에 운영자는 각 후보 DNSKEY가 키 저장소, 서명 구성, 존 출력 전반에 걸쳐 고유한 운영 식별을 가짐을 보여야 한다. 키 태그는 그 시야의 일부로 남을 수 있지만 유일한 증거일 수는 없다. 게이트는 완전한 공개 키 자료, 알고리즘, 키 태그, 키 역할, 활성화 상태, 비활성화 상태, 서명 환경 내 기대 개인 키 결합을 포함해야 한다. 요점은 비밀을 공개하는 것이 아니라, 시스템이 짧은 식별자의 충돌만으로 두 키 쌍을 혼동할 수 없음을 증명하는 것이다 [14][17].

두 번째 게이트는 공개 전 키-서명 검증이다. 후보 서명 존은 공개 시스템을 떠나기 전에 전체로서 검증되어야 한다. 게이트는 모든 관련 RRSIG가 의도된 개인 키로 생성되고 공개된 DNSKEY 세트에 대해 검증되는지 확인해야 한다. 구 개인 키가 서명하는 동안 새 공개 키가 제공되는 상태를 잡아내야 한다. 이 검증은 서명자와 동일한 결함 있는 가정을 공유할 수 있는 단일 내부 구성요소에 의존해서는 안 된다.

세 번째 게이트는 독립 검증기 다양성이다. 재귀 확인자가 실제 소프트웨어에서 표준을 구현하므로, 공개 전 시험은 둘 이상의 검증기 구현과 둘 이상의 확인자 구성을 포함해야 한다. 목표는 모든 소프트웨어를 동일하게 동작시키는 것이 아니다. 규격에 부합하는 검증기가 후보 존을 위조로 분류할지 감지하는 것이다. 표준은 기대 검증 동작을 서술하지만, 실제 후보 존을 가동 검증기에 돌리는 것만이 사용자가 경험하기 전에 통합 실패를 노출할 수 있다 [13][15][16].

네 번째 게이트는 카나리아 확인자를 통한 단계적 공개이다. 포스트모템은 사전 공개 롤오버를 기술하지만, 실패는 여전히 사용자에게 도달했다 [5]. 향후 통제는 광범위 배포 전에 소규모 통제 환경에서 활성화를 관측 가능하게 해야 한다. 카나리아 확인자는 일반 도메인 네임, 부정 답, DNSKEY와 DS 체인, 캐시 갱신 동작, 확인자 응답 코드를 시험해야 한다. 카나리아 결과는 새 상태가 일반 공개 상태가 되기 전에 진행 또는 롤백 임계값에 묶여야 한다.

다섯 번째 게이트는 원자적 활성화이다. 롤오버는 내부 상태가 조각으로 움직일 때 실패할 수 있다. 공개 키는 한 곳에, 개인 서명 상태는 다른 곳에, 구성 플래그는 또 다른 곳에, 공개 타이밍은 네 번째 계층에 있을 수 있다. 활성화 단계는 의도된 구·신 상태가 함께 움직임을 증명해야 한다. 구 키가 비활성화되고 새 키가 활성화되면, 서명과 공개된 DNSKEY 데이터는 동일한 상태를 반영해야 한다. 부분 활성화는 바로 키 태그 충돌이 검증기가 결과를 거부할 때까지 숨길 수 있는 조건이다.

여섯 번째 게이트는 검증된 롤백이다. 공식 연대기에 따르면 운영자는 21:00에 이전 존 파일·키 상태를 복원했다 [5]. 중요한 복구 조치이다. 더 강한 공개 책임성 패킷은 사건 전 롤백 리허설 증거, 최초 감지에서 롤백 결정까지의 경과 시간, 롤백 상태의 검증 상태, 정상 롤오버가 재개될 수 있는 조건을 보여줄 것이다. 롤백은 즉흥적 최후 수단이 아니라 시험된 운영 통제여야 한다.

일곱 번째 게이트는 확인자 우회 되돌림 증거이다. 일시적 검증 비활성화는 시간 제한적이고, 측정되고, 되돌려져야 한다. 공개 기록은 국가 시스템 확인자에 대해 1월 31일 01:07의 재활성화 시각을 제공한다 [5]. 향후 공개 보고는 또한 몇 개의 확인자 노드가 영향받았는지, 재활성화 전에 어떤 모니터링이 확인되었는지, 사용자가 불필요하게 오랫동안 약화된 검증 자세에 남았는지를 설명해야 한다. 보안 질문은 긴급 상황에서 사용자가 네임에 도달했는가만이 아니다. 진위 보호가 돌아왔는가이다.

여덟 번째 게이트는 형제 존 격리이다. 포스트모템은.ДЕТИ와.TATAR를 제공하는 서버가 일시적 성능 저하를 겪었다고 말한다 [5]. 이는 그 존들이 동일한 DNSSEC 결함을 가졌음을 증명하지 않는다. 그러나 공유 서명, 공개, 모니터링 또는 제공 인프라에 관한 타당한 통제 질문을 제기한다. 운영자는 형제 존이 키 저장소, 서명 소프트웨어, 공개 큐, 검증 게이트, 롤백 도구를 공유하는지, 한 최상위 도메인의 오류가 운영 압박을 다른 곳으로 전파할 수 있는지 보여줄 수 있어야 한다.

아홉 번째 게이트는 외부 관측이다. DNSViz와 공개 확인자 텔레메트리는 내부 통제의 대체물이 아니지만 가치 있는 공개 증거이다 [7][12]. 향후 롤오버 검증 패킷은 외부 관측자가 변경 전후 DNSSEC 체인 건강을 비교하기 쉽게 해야 한다. 서명 존 시리얼, DNSKEY 상태, 검증 스크린샷 또는 기계 판독 가능 검사, 무엇이 바뀌었는지에 대한 평이한 설명이 포함될 수 있다. 공중은 실패 증상만으로 상태를 전부 추론해야 해서는 안 된다.

열 번째 게이트는 경계 있는 사후 공개이다. 완전한 보고서는 비밀을 공개할 필요가 없지만, 주장된 수리를 시험 가능하게 만들 만큼은 공개해야 한다. 결함 등급, 영향받은 상태, 감지 시각, 롤백 시각, 검증 우회 시각, 검증 복원 시각, 정상화 시각, 내구성 검사, 남은 불확실성이 그것이다..RU 공개 패킷은 특히 연대기와 키 태그 충돌 설명에서 그 기록의 의미 있는 요소를 가진다 [2][5]. 지속 가능한 신뢰에 중요한 공백을 남긴다.

출처가 증명하지 않는 것

출처는 사이버 공격을 증명하지 않는다. 이후 정부 보도는 외부 개입이 확인되지 않았다고 밝혔다 [8][21]. DNSSEC 롤오버 중 기술적 실패는 이미 이 캡슐의 공개 증거를 설명하기에 충분하다. 파괴 행위나 공격 귀속을 더하는 것은 기록을 넘어선다.

출처는 검열이나 고의적 접속 차단을 증명하지 않는다. 사건은 네트워크 통제 논쟁이 주목을 끄는 나라에서 발생했고, 일부 보도는 자연히 그 환경을 논의했다 [10]. 그러나 공개 포스트모템의 기술 메커니즘은 서명 키와 검증 실패이다. 이 글은 정책 맥락을 실패 귀속과 분리해야 한다.

출처는 전역 장애를 증명하지 않는다. Cloudflare의 SERVFAIL 피크는 중요하지만 확인자별 텔레메트리이다 [7]. 공식 성명은 모든 사용자나 모든 확인자가 아니라 러시아 인터넷 청중의 일부를 기술한다 [2][5]. 올바른 결론은 측정이 한정된 실질적 장애이지 전체 불가용이 아니다.

출처는 DNSSEC 암호학이 실패했음을 증명하지 않는다. DNSSEC 검증은 인증될 수 없는 데이터를 거부했다. 실패는 서명·공개 상태에 있었으며, 프로토콜의 기본 보안 목표에 있지 않았다. 표준은 검증기가 인증된 데이터와 위조 데이터를 구분할 것으로 기대되기 때문에 그 구별을 뒷받침한다 [13][15].

출처는 개인의 과실, 명명된 소프트웨어 벤더 결함, 법적 위반, 영구적 시정을 증명하지 않는다. 공개 기록은 키 저장소 데이터가 정상화되었고 검사·공개 통제와 소프트웨어가 개선될 것이라고 말한다 [2][5]. 그 개선의 완전한 지속 증거를 제공하지 않는다. 이후 연차 보고는 2024년 운영 맥락에 사건을 기록하지만, 모든 교정 통제에 대한 독립 기술 감사와 동일하지는 않다 [20].

출처는 검증 비활성화가 서명 존을 고쳤음을 증명하지 않는다. 그것은 긴급 가용성 조치였다. 서명 존 상태에는 롤백과 교정이 필요했다. 검증 비활성화를 성공적인 DNSSEC 결과로 취급하면 보안 논리가 뒤집힌다. 더 나은 결론은 긴급 우회가 사용자 고통을 줄일 수 있지만, 검증된 서명 존 복원과 검증 재활성화만이 보안 루프를 닫는다는 것이다 [3][5].

결론

.RU 2024 DNSSEC 사건은 새로운 인터넷 드라마 등급을 도입했기 때문에 중요한 것이 아니었다. 그것은 오래된 인프라 진실을 정밀하게 노출했기 때문에 중요했다. 상위 존 원장은 검증기가 실제로 검증할 수 있는 서명 바이트만큼만 신뢰할 수 있다는 것이다. 레지스트리는 중복 권위 서버, 계획된 롤오버 일정, 숙련된 운영자를 가지면서도 여전히 규격에 부합하는 확인자가 거부하는 상태를 공개할 수 있다. 그렇게 되면, 가시적 실패는 사용자에게는 평범한 웹사이트 불가용으로 보일 수 있지만, 통제 실패는 영향받은 도메인 위의 네이밍 인프라에 놓여 있다.

그래서 책임성 시험은 증거 기반이어야 한다. 조정센터와 기술 운영자는 공개 연대기, 원인 진단, 교정 방향을 제시했다. 그것은 의미 있는 공개이다. 남은 공개 질문은 다음 롤오버가 활성화 전에 충돌 없음이, 공개 전에 독립적으로 검증되고, 카나리아 확인자를 통해 관측되고, 검증된 서명 상태로 롤백되고, 긴급 검증 우회가 되돌려졌다는 증거가 뒤따를 수 있는지이다.

이 사건은 또한 분석가를 더 규율 있게 만들어야 한다. 2009년.se, 2019년.RU, DENIC 보도, 루트 DNS DDoS 사건, 정치적 통제 논쟁과 병합되어서는 안 된다. 증거 없이 공격, 파괴 행위, 검열, 전역 장애, 법적 위반, 전체 손실로 불려서는 안 된다. 더 좁은 결론이 더 강하다. 안전한 위임은 정확한 보안 메타데이터와 운영 연속성에 의존한다. 레지스트리가 불일관한 서명 존을 공개할 때, 책임성 질문은 DNSSEC이 너무 엄격했는가가 아니다. 레지스트리와 그 운영자가 인터넷에 의존을 요청하기 전에 다음 서명 존이 유효할 것임을 증명할 수 있는가이다.

출처

[1]https://cctld.ru/media/news/kc/35564/[2]https://cctld.ru/en/media/news/kc/35575/[3]https://noc.gov.ru/ru/news/30-yanvarya-zafiksirovan-incident-v-rabote-dns-serverov/[4]https://lists.dns-oarc.net/pipermail/dns-operations/2024-February/022425.html[5]https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20240208/692c9726/attachment-0001.pdf[6]https://archive.fosdem.org/2024/schedule/event/fosdem-2024-3740-observations-on-a-dnssec-incident-the-russian-tld/[7]https://blog.cloudflare.com/q1-2024-internet-disruption-summary/[8]https://interfax.com/newsroom/top-stories/99634/[9]https://therecord.media/russia-top-level-domain-internet-outage-dnssec[10]https://meduza.io/en/feature/2024/02/01/the-russian-internet-s-domain-problems-and-how-the-war-in-ukraine-narrows-the-kremlin-s-options-for-online-controls[11]https://www.rbc.ru/technology_and_media/07/02/2024/65c38fea9a794752176bd3a0[12]https://dnsviz.net/d/ru/ZbpWZg/dnssec/[13]https://www.rfc-editor.org/rfc/rfc4033.html[14]https://www.rfc-editor.org/rfc/rfc4034.html[15]https://www.rfc-editor.org/rfc/rfc4035.html[16]https://www.rfc-editor.org/rfc/rfc6781.html[17]https://www.rfc-editor.org/rfc/rfc7583.html[18]https://www.rfc-editor.org/rfc/rfc5011.html[19]https://www.iana.org/domains/root/db/ru.html[20]https://cctld.ru/files/yr_report/dir_year_report_2024.pdf[21]https://rg.ru/2024/02/20/glava-mincifry-shadaev-sboj-runeta-ne-byl-vyzvan-vneshnim-vmeshatelstvom.html