Summary

  • 2026년 10월 29일 RIPE 93 데이터베이스 작업반 회의에서 Kaveh Ranjbar는 더 세부적인 자원 기록의 RDAP 조회를 보유자 서버로 선택적으로 보내자고 제안했다. 그는 영향 분석과 작업반 논의를 요청했으며, 도입 결정은 내려지지 않았다.
  • Leo Vegoda는 방향에 대체로 찬성하면서 두 가지 검증을 요구했다. 위임 서버가 계속 동작해야 하고, RIPE NCC가 조회할 때와 다른 사람이 조회할 때 같은 답을 내놓아야 한다. 회의록은 가능한 위험을 기록할 뿐 실제 조작 사례를 제시하지 않는다.

길을 알려 준 곳과 답을 쓰는 곳

공식 발표 개요에 따르면 현재 RDAP 조회는 RIPE NCC가 가진 가장 구체적인 객체에서 멈출 수 있다. 보유자가 그 아래의 더 자세한 등록 정보를 자체 서버에 보관해도, NCC의 답변에서 그 서버를 찾아갈 수 있는 연결이 없다. Ranjbar의 제안은 상위 객체에 보유자 RDAP 주소를 등록하고, 하위 자원 조회를 그쪽으로 보내며, 위임 링크를 표시하고, 서비스 상태를 계속 확인해 장애가 나면 연결을 철회하는 네 요소로 이뤄진다. 모두 자발적 참여를 전제로 한다.

세부 기록을 관리하는 사람이 직접 공개하면 중앙 데이터베이스에 대량 복사본을 쌓았다가 오래되게 둘 이유가 줄어든다. 그러나 NCC가 주소를 알려 준 순간, 독자는 그 다음 서버의 말에도 NCC의 신뢰를 실을 수 있다. 길을 안내하는 기관과 실제 기록을 작성하는 주체가 갈라지는 셈이다.

Vegoda는 단순 장애와 답변 불일치를 구분했다. 서버가 꺼지면 조회가 실패한다. 하지만 NCC에는 정상 기록을 주고 다른 이용자에게는 잘못된 기록을 준다면, 두 조회 모두 성공으로 표시될 수 있다. 가동률 검사만으로는 이 차이를 잡지 못한다. 그는 누구에게나 동일한 답이 가는지 확인하자고 했고, Ranjbar는 세부 방안을 논의하겠다고 답했다.

회의에서는 독립된 여러 클라이언트의 답을 비교하는 방법도, 불일치가 발견됐을 때 연결을 철회할 기준도 제시되지 않았다. 다음에 확인할 문서는 요청된 영향 분석과 재현 가능한 검증 절차다. 주소를 가리키는 화살표보다 화살표 끝의 답을 확인하는 일이 더 어렵다.

출처: RIPE 93 회의록, 공식 발표 개요, Leo Vegoda의 RIPE Labs 소개.