요약

  • 2026년 11월 3일 20:07~22:50 UTC, RIPE NCC의 RFC 8181 발행 서비스가 등록된 위임 CA를 알아보지 못해 모든 발행 요청에 “Unknown publisher”를 반환했다.
  • 점검 중 재시작한 Krill이 발행자 설정을 사용할 수 있게 되기 전에 올라왔다. 이미 저장된 RPKI 객체는 그대로였고, 복구 뒤 실패했던 CA의 발행은 자동으로 재개됐다.

불은 켜졌지만 명단은 없었다

RIPE NCC 사고 기록의 핵심은 한 박자 빠른 시작이다. 정기 점검으로 시스템을 재시작한 뒤 저장장치가 느려져 Krill에 필요한 설정이 늦게 도착했다. 요청을 받을 프로세스는 살아 있었지만 어느 위임 CA가 발행 권한을 가졌는지 알 수 없었다. 응답은 전부 “Unknown publisher”. 시작부터 해결까지 2시간 43분이었다.

이 창구가 왜 중요한지는 위임 인증기관 안내에 나와 있다. 운영자는 CA와 개인키를 직접 보유하면서 RIPE NCC의 Publication as a Service를 저장소로 선택할 수 있다. CA가 서명한 ROA, 매니페스트, 인증서 폐지 목록을 그 창구로 보내면 RIPE NCC가 저장하고 외부에 제공한다. 서명할 권한과 받아서 배포할 책임이 서로 다른 주체에게 놓인다. 11월 3일 끊어진 곳은 그 사이의 접수 절차였다.

RIPE NCC는 기존 저장소 내용이 영향을 받지 않았다고 밝혔다. 발행에 실패한 위임 CA도 수정 후 자동으로 다시 발행했다. 하지만 이전 파일을 계속 읽을 수 있다는 사실은 새로운 변경을 올릴 수 있었다는 뜻이 아니다. 경로 기원 허가를 바꿔야 하는 운영자에게는 쓰기 창구의 고장이 직접적인 지연이다. 공개 보고서에는 영향을 받은 CA 수와 개별 시도 목록이 없다. 특정 변경이 언제 반영됐는지는 CA의 재시도 기록과 저장소 객체를 맞춰 봐야 한다.

점검 종료 표시가 발행 성공의 증거는 아니다

같은 날 RPKI Dashboard 점검 기록은 21:06 CET, 곧 20:06 UTC에 완료로 바뀌었다. 별도의 발행 사고 기록은 거부가 20:07 UTC에 시작됐다고 적는다. 두 기록은 서비스 표면이 다르고, 사고 보고서도 Dashboard 점검 티켓 자체를 원인으로 지목하지 않는다. 시간의 간격이 보여 주는 것은 분명하다. 프로세스 기동, 점검 종료, 등록된 CA의 실제 발행 성공은 각각 따로 검증해야 한다.

처음 문제를 알린 쪽은 회원이었다. RIPE NCC에 따르면 24시간 대응 엔지니어가 신고를 받고 올바른 설정을 Krill에 제공해 해결했다. 앞으로는 Krill보다 설정을 먼저 준비하고 RFC 8181 구간에 대한 감시를 강화하겠다고 한다. 살아 있는 프로세스만 보는 감시라면 같은 고장을 다시 놓친다. 등록된 발행자의 정상 요청이 저장소까지 도달하는지 확인해야 한다.

공식 서비스 약관은 이 접수 경로의 운영자를 RIPE NCC로 명시한다. 위임 CA가 키를 직접 지킨다는 선택이 의미 있으려면 저장소가 그 CA의 다음 결정을 받아들여야 한다. 등록기관은 기존 객체를 지켰다. 새 객체를 받는 권한 확인은 회원의 신고가 들어올 때까지 실패했다.