요약

  • RIPE NCC에 따르면 주 부하 분산기의 네트워크 링크가 잠시 끊겨 예비 장비로 전환됐다. 설정 오류로 새 Whois 갱신 DB 연결은 읽기 전용 DB로 갔고, 기존 애플리케이션 연결은 주 DB에 남았다.
  • 발표된 10월 28일 갱신 실패 구간은 UTC 11:42~19:40이다. 후속 조사에서 실패한 역방향 위임 요청은 변경이 없거나 zonemaster 사전 검사에 실패해 실제 위임을 바꾸지 않았을 것이라고 RIPE NCC는 밝혔다.

살아 있는 예비 장비, 막힌 새 쓰기

RIPE NCC가 11월 3일 공개한 사후 보고서는 원인을 단계별로 적었다. 주 부하 분산기의 네트워크 링크가 짧게 끊겼고 예비 장비가 선택됐다. 하지만 예비 경로의 잘못된 설정은 새로 생긴 Whois 갱신 연결을 주 DB가 아니라 읽기 전용 DB로 보냈다. 기존 애플리케이션 연결은 주 DB에 계속 붙어 있어 영향을 받지 않았다.

같은 서비스에서 어떤 갱신은 되고 어떤 갱신은 실패한 이유가 여기 있다. DB 전체가 무작위로 켜졌다 꺼진 것이 아니다. 연결을 언제 열었느냐가 목적지를 갈랐다. 읽기 전용 복제본은 조회에 적합하지만 등록 객체의 수정은 받아들일 수 없다. 예비 분산기가 네트워크 상으로 정상이어도 새 갱신의 목적지 역할이 틀리면 레지스트리 업무는 실패한다.

RIPE NCC는 10월 28일 UTC 11:42부터 19:40까지 갱신이 간헐적으로 실패했다고 기록했다. 당시 상태 공지는 일부 갱신이 처리되지 않았고 역방향 DNS와 관련된 도메인 객체도 언급했다. 새 연결의 목적지 오류는 이후 보고서에서야 공개됐다. 어느 설정 항목이 잘못됐는지, 새 연결이나 갱신 몇 건이 실패했는지, 제출 방식별로 영향이 어땠는지는 나오지 않았다. 설정 변경 기록과 방식별 결과가 공개되면 범위를 셀 수 있다.

역방향 위임 요청에는 별도의 결론이 붙어 있다. RIPE NCC는 실패 요청을 재검토한 결과 변경 내용이 없거나 zonemaster 사전 위임 검사에서 거부될 것이어서 위임을 바꿀 요청은 없었다고 했다. 쓰기 경로 오류는 실제였지만, 이 요청 묶음이 유효한 역방향 위임 변경의 손실을 보여 주지는 않는다.

확인해야 할 것은 객체의 결과

RIPE의 객체 처리 안내는 제출된 각 객체를 따로 처리하고 결과 확인을 보낸다고 설명한다. 확인 응답 안내에 따르면 Syncupdates의 HTTP 200에도 개별 객체 오류가 포함될 수 있다. 운영자에게 필요한 증거는 의도한 수정의 성공 내역과 등록 객체의 재조회 결과다. 분산기의 녹색 상태 표시는 그 증거를 대신하지 못한다.