요약

  • ARIN의 11월 4일 누적 이전 원본에 Town of Georgina에서 The Regional Municipality of York로 가는 RESOURCE_TRANSFER 두 행이 추가됐다. 시각은 둘 다 2026-11-03T21:50:57Z다. 두 행은 768개 주소의 동일한 original_set인 199.201.121.0–199.201.123.255를 반복하지만, 실제 transfer_set은 .121/24와 .123/24로 합계 512개다.
  • ARIN RDAP의 .121/24와 .123/24는 RMY에 등록돼 있고, 기관 레코드는 이를 York로 명시한다. .122/24는 CTG-110, 곧 Town of Georgina의 등록이다.

세 칸짜리 기록이 한 줄짜리 요약을 이긴다

숫자만 보면 768개짜리 출발 범위 하나와 이전 두 건이다. 구간을 펼치면 얘기가 달라진다. 199.201.121.0/24는 York, 그 바로 다음 199.201.122.0/24는 Georgina, 이어지는 199.201.123.0/24는 다시 York다. 세 구간은 서로 붙어 있다. 그러나 그 사실은 등록기관이 현재 세 구간에 서로 다른 책임 주체를 적어 놓았다는 사실을 없애지 않는다.

ARIN의 이전 로그 형식 설명에서 original_set은 각 행이 출발한 원래 범위를, transfer_set은 그 행에서 실제 옮긴 주소를 가리킨다. 이번에는 원래 범위가 두 번 나온다. 이를 두 번 더해 1536개가 옮겨졌다고 쓰면 원본 768개보다 큰 거래가 만들어진다. 반대로 York가 768개 전부를 받았다고 쓰면 Georgina에 남은 가운데 256개가 지워진다. 정확한 합계는 York로 간 512개와 Georgina에 남은 256개다.

행정 조직도가 주소 등록부를 대신할 수도 없다. 지역 자치단체와 그 안의 타운이라는 관계는 그럴듯한 지름길을 제공한다. 하지만 어느 기관에 연락해야 하는지는 IP가 세 구간 중 어디에 있느냐에 따라 달라진다. 사고 대응 목록이나 공공 자산 감사에 하나의 상위 범위와 하나의 이름만 저장하면, 가운데 주소를 찾는 사람에게 잘못된 답을 준다.

같은 초의 처리, 아직 없는 계약서

양끝 York 객체의 RDAP 등록 시각은 11월 3일 16:50:56-05:00, UTC로 21:50:56이다. Georgina의 가운데 객체도 그 초에 마지막으로 변경됐다. York의 .123 객체는 다음 초에 다시 변경됐고 이전 로그의 두 행 역시 21:50:57 UTC다. 공개 기록은 일련의 등록 처리가 촘촘히 이뤄졌다는 점을 보여 준다.

왜 양끝만 옮겼는지는 두 자치단체의 날짜가 명시된 서비스 또는 자산 합의서가 있어야 설명할 수 있다. 실제 라우팅은 별도의 경로 자료로 구간마다 확인해야 한다. 그 자료가 없어도 지금 등록 명의가 셋으로 갈라져 있다는 사실은 분명하다. 모르는 이유를 채우려고 등록부의 경계까지 지울 필요는 없다.

공공 기록의 값어치는 기묘한 모양을 지워 버리지 않는 데 있다. 원래 하나였다는 열과 현재 누가 각 조각을 보유하는지 적은 열은 서로 다른 질문에 답한다. 이번 사례에서는 그 차이가 세 칸의 가운데에서 바로 드러난다. 11월 3일 누적 원본과 비교하면 두 행이 새로 들어왔음을 확인할 수 있다. ARIN 이전 절차 안내는 등록 절차를 설명하며, 실제 이전 주소는 공개된 두 행과 현재 RDAP에서 확인한다.