요약

  • 데이터베이스에 변경이 기록돼도 공개 DNS가 바로 바뀌지는 않는다. RIPE NCC는 역방향 DNS 업데이트가 2026년 8월 2일 00:06 UTC부터 8월 4일 12:30 UTC까지, 총 60시간 24분 지연됐다고 밝혔다. 수리 뒤 대기 중인 업데이트는 모두 처리됐다.
  • RIPE 93에서 Ed Shryane은 문자 디코딩이 RPSL 객체에 줄바꿈을 더해 데이터 형식을 깨뜨렸다고 설명했다. 수정은 그 문자를 손대지 않고 남기는 것이었다. 팀은 최근 객체 1,000개와 응답의 마지막 표시까지 확인했다.

분석

RIPE Database의 기록부와 인터넷에 공개된 역방향 DNS는 같은 순간 갱신되지 않는다. 역방향 DNS는 IP 주소에 연결된 이름을 찾아주는 응답이다. 이 장애 때는 등록된 변경이 공개 DNS까지 전달되는 길에서 60시간 넘게 늦어졌다.

변경을 미러 서버에 전달하는 통로가 NRTM, Near Real Time Mirroring이다. 이름 그대로 데이터베이스 복사본에 변경을 빠르게 보내는 흐름이다. 한 줄이 깨져 다음 시스템이 읽지 못하면 새 변경은 다음 단계로 넘어가지 못한다.

RIPE NCC가 8월 6일 Database 작업 그룹에 보낸 공지는 시작 시각을 8월 2일 00:06 UTC, 종료 시각을 8월 4일 12:30 UTC로 기록했다. 총 60시간 24분이다. 공식 상태 기록은 사건을 중대 장애로 분류했다. 수리 뒤 RIPE NCC는 밀린 변경을 처리했고, 후속 기록에서 역방향 DNS 서비스 복구를 알렸다.

데이터베이스 엔지니어 Ed Shryane은 RIPE 93의 Database 세션에서 고장 지점을 짚었다. 레지스트리 객체는 RPSL이라는 규칙에 따라 여러 줄로 구성된다. 프로그램은 문자 안의 이스케이프 표기를 풀어 읽으려다가 줄을 하나 더 삽입했다. 줄바꿈도 객체 구조의 일부라서, RIPE NCC가 받아들인 객체를 다음 단계의 파서가 읽지 못하게 됐다.

팀은 그 문자 변환을 끄고 표기를 입력 그대로 남겼다. 이어 최근 객체 1,000개를 다시 흘려보내며 각 객체가 정상적으로 읽히는지 확인했다. 응답 끝에 완료 표시가 있는지도 별도로 점검했다. 하나는 내용이 온전한지, 다른 하나는 미러가 전달분을 끝까지 받았는지 알려준다.

이 사례에서 등록 기록과 공개 DNS 사이를 잇는 전달 통로가 핵심이었다. 공개 자료에는 지연 시간과 복구 결과가 있지만 영향을 받은 미러나 도메인의 수는 없다. 그 수치가 있어야 RIPE NCC 밖에서의 영향 범위를 좁힐 수 있다.

출처

RIPE 93 Database 세션 기록; RIPE 93 세션 페이지; RIPE NCC 장애 기록; RIPE NCC의 Database 작업 그룹 공지; RFC 2622.