요약

  • draft-ranjbar-regext-rdap-subordinate-referrals-01은 레지스트리가 보유한 대상에서, 그 홀더가 하위 이름·네트워크·주소에 대해 지정한 RDAP 서비스로 향하는 방향성 링크와 리디렉션을 제안한다.
  • 다운스트림 데이터는 레지스트리 운영자가 아니라 홀더가 주장하는 것이다. 엄격한 하위 관계, 역방향 링크, 1홉 제한이 추천이 발화할 수 있는 범위를 묶어 주며, 홀더는 자신에게 도달한 질의를 가시화할 수 있게 된다.
  • RDAP 클라이언트는 권한 경계(seam)를 유지해야 한다. 레지스트리의 포괄 대상 주장과 홀더의 하위 주장을 별개의 계층으로 표시하고, 이를 잇는 지정·리디렉션·검색·프라이버시·폴백 근거를 함께 보여 주어야 한다.

일반적인 RDAP 경로는 안심이 되는 형태를 지닌다. 클라이언트는 IANA 부트스트랩 정보에서 출발해 최상위 도메인 또는 번호 자원 범위를 담당하는 서비스에 도달하고, 그 서비스가 보유한 가장 구체적인 기록을 요청한다. 각 단계가 인정된 등록 계층 구조 안에서 질문을 좁혀 가기 때문에 이 사슬은 권위 있는 것처럼 느껴진다.

그러나 이 사슬에는 의도적인 멈춤 지점도 있다. 도메인 레지스트리는 등록된 도메인은 보유하더라도 그 아래 프로그래매틱하게 생성된 모든 이름을 갖고 있지 않을 수 있다. RIR은 포괄적 할당이나 집계된 배정을 보유하더라도 그 안에 배정된 더 구체적인 모든 네트워크나 개별 주소를 갖고 있지 않을 수 있다. 누락된 세부 정보가 반드시 오류인 것은 아니다. 변동이 잦은 하위 데이터를 중앙 레지스트리 밖에 두는 것은 의도된 역할 분담일 수 있다.

이 새로운 개인 드래프트는 다음 정보원을 찾을 수 있게 만들려고 한다. 하위 데이터를 유지하는 자원 홀더는 자신이 운영하거나 자신을 위해 운영되는 RDAP 서버를 지정할 수 있다. 레지스트리 운영자의 응답은 그 서비스를 아래로 가리킬 수 있고, 홀더의 응답은 포괄 레지스트리 서비스를 위로 가리킬 수 있다. 클라이언트는 중앙 레지스트리에 빠르게 변하는 하위 데이터베이스를 수용하도록 강요받지 않으면서 유용한 세부 정보로 가는 경로를 얻게 된다.

공학적 이득은 분명하다. 거버넌스 비용은 인터페이스가 이 경계를 없앨 때 나타난다.

방향은 권한의 상속이 아니다

개정판 01은 두 개의 제안된 링크 관계를 명명한다.rdap-base-down은 RDAP 대상에서 하위 또는 위임 데이터를 보유한 다운스트림 서비스의 기본 URL을 가리킨다.rdap-base-up은 그 다운스트림 서비스에서 포괄 레지스트리 서비스의 기본 URL로 되돌아가는 방향을 가리킨다. 이 이름들은 서비스 간의 방향을 기술할 뿐, 다운스트림 운영자를 레지스트리로 승격시키지 않는다.

드래프트는 이 한계를 명시한다. 홀더가 지정한 서버는 참조 대상에 완전히 종속된 자원에 한해서만 후보 정보원이다. 그 대상은 HTTPS여야 하며, 클라이언트는 그 경계 밖의 어떤 것에 대해서도 이를 권위 있는 것으로 취급해서는 안 된다. 역방향 링크는 상위 권한으로 가는 경로를 보존하고, 클라이언트는 따르는 홀더 수준 추천의 수를 제한해야 한다. 기술된 사용 사례에는 한 홉이면 충분하다.

이러한 규칙은 한 홀더가 동일한 추천을 통해 형제 프리픽스, 상위 할당 또는 무관한 도메인을 주장하는 것을 막는다. 그러나 모든 하위 주장이 정확하다는 것을 증명하지는 않는다. 경계가 정해진 네임스페이스에 대한 권한은 여전히 홀더가 하는 주장이다. 레지스트리 운영자의 행위는 더 좁다. 그것은 지정을 기록하거나 출력하며, 대상이 홀더의 자원에 대해 적합한 RDAP로 동작하는지 확인할 수 있다.

따라서 추천은 하나가 아니라 두 개의 명제를 전달한다. 레지스트리는 사실상 "이 홀더가 이 대상 아래의 데이터를 위해 지정한 서비스다"라고 말하고, 홀더는 "이것이 내가 유지하는 하위 기록이다"라고 말한다. 결합된 결과를 단순히 "레지스트리 데이터"로 표기하는 클라이언트는 첫 번째 명제를 두 번째 명제의 보증으로 바꾸어 버린다.

하위 호환성이 경계를 보이지 않게 만들 수 있다

이 제안은 구형 클라이언트를 고아로 남기지 않도록 설계되었다. 홀더 포인터가 등록되면 레지스트리 서버는 여전히 하위 조회를 지정된 서비스로 리디렉션한다. 새 링크 관계를 이해하지 못하는 클라이언트도 가장 구체적인 답변을 계속 받을 수 있다. 유능한 클라이언트는rdap-base-down을 발견하고 경계를 의도적으로 넘을 수 있으며, 레지스트리 자체의 포괄 기록을 원하는 클라이언트는 함께 진행 중인 명시적 추천 드래프트에서 논의되는 리디렉션 억제 아이디어를 사용할 수 있다.

이것은 실용적인 호환성 설계다. 동시에 근거(provenance)를 프로토콜 전문가에게만 맡길 수 없는 이유이기도 하다. 변경되지 않은 클라이언트의 사용자는 포괄 기록이나 응답 기관이 바뀌는 지점을 영원히 보지 못할 수 있다. 표준 HTTP 리디렉션은 시각적으로 조용하고, 라이브러리는 흔히 자동으로 따라간다. 결과는 출처, 가용성 운영 주체, 프라이버시 결과, 증거적 지위가 도중에 바뀌었음에도 단일 조회의 외관을 유지할 수 있다.

함께 진행 중인 워킹그룹 드래프트인draft-ietf-regext-rdap-referrals-04는 관련 RDAP 기록으로의 명시적 리디렉션을 요청하는 방식을 정의한다. 적합한 링크가 하나 존재하고 클라이언트가 권한을 갖추었을 때, 응답은 일반적인 HTTP 리디렉션 상태와Location헤더를 사용한다. 관계 선택, 콘텐츠 협상, 캐싱, 다중 홉 제한도 다룬다. 이 장치는 링크 하나를 뽑아내기 위해 전체 기록을 주고받는 부담을 클라이언트와 서버에서 덜어 준다. 그러나 리디렉션된 발언자를 독자가 어떻게 이해해야 하는지는 결정하지 않는다.

홀더는 정보원이자 관찰자가 된다

보안 섹션은 근거 규칙을 단언한다. 홀더가 지정한 서버가 제공하는 데이터는 레지스트리 운영자가 아니라 홀더가 주장하는 것이다. 그 데이터를 제시하는 클라이언트는 이 둘을 구분해야 한다. 이는 표면적 귀속 표기가 아니다. 누가 기록을 정정할 수 있는지, 누가 연속성 의무를 부담하는지, 분쟁에서 어떤 근거를 신뢰할 수 있는지, 캐시된 결과가 얼마나 오래 의미를 유지해야 하는지를 결정한다.

추천은 질의 가시성도 바꾼다. 클라이언트가 홀더의 인프라에 도달하면 홀더는 자신의 하위 자원에 대한 관심을 관찰할 수 있다. 드래프트는 그 가시성을 DNS 운영자가 자신의 존(Zone)에 대해 이미 보는 것과 비교하고, 기밀성이 중요한 클라이언트는 따르기를 거부할 수 있다고 말한다. 이 선택지는 소프트웨어가 무음 리디렉션 전에 이를 노출할 때, 그리고 사용자가 여전히 레지스트리의 포괄 기록을 얻을 수 있을 때만 의미가 있다.

가용성도 같은 방식으로 갈린다. 홀더 서비스에 접근할 수 없으면 추가 하위 데이터가 사라지지만, 레지스트리 운영자 자신의 응답은 영향을 받지 않는다. 어느 계층이 실패했는지 밝히지 않고 "RDAP 사용 불가"라고만 보고하는 클라이언트는 유용한 구분을 지워 버린다. 레지스트리 장애, 깨진 지정, 홀더 측 장애는 소유자가 서로 다른 서로 다른 사건이다.

지정 채널은 표준화되지 않은 경첩

드래프트는 홀더가 어떤 서버를 사용할지 레지스트리 운영자에게 알리는 방법을 명시하지 않는다. 포털이나 미래의 EPP 확장이 단지 예시로 제시될 뿐이다. 초점이 맞춘 RDAP 문서에서 이러한 생략은 합리적이지만, 가장 영향력 큰 행정 절차를 전송 형식 바깥에 남겨 둔다.

누가 포인터를 만들 수 있는가? 어떤 자격 증명이 홀더의 권한을 증명하는가? 대행자가 지정을 변경할 권리를 얻지 않고도 서버를 운영할 수 있는가? 새 대상은 언제 효력을 발생하는가? 긴급 폐지는 어떻게 처리되는가? 상위 도메인이나 번호 자원의 이전이 기존 포인터를 자동으로 무효화하는가? 악의적이거나 잘못된 지정이 질의를 잘못된 서비스로 보냈을 때 어떤 기록이 남는가?

드래프트는 레지스트리 운영자가 추천을 출력하기 전에 적합성을 검증해야 한다고 말한다. 적합성은 필요하지만 소유권은 아니다. 서버는 자신이 통제해서는 안 되는 데이터에 대해 잘 구성된 RDAP를 반환할 수 있다. 레지스트리에는 지정을 둘러싼 수명 주기, 즉 인증된 생성, 범위 증명, 대상 검증, 활성화, 갱신, 변경, 폐지, 이전 정리가 필요하다. 클라이언트는 자신이 따라간 링크가 그 수명 주기의 어느 버전에서 생겼는지에 대한 근거를 필요로 한다.

재사용 가능한 관계에는 보이는 목적이 필요하다

제안된 관계는 의도적으로 일반적이다. "자원 홀더" 역할이 아니라 다운스트림 또는 포괄 기본 URL을 명명하기 때문에, 동일한 쌍이 위임형 또는 하이브리드 RPKI 서비스와 RWhois·SWIP의 현대적 대체재를 발견하는 데도 도움될 수 있다. 드래프트는 RDAP RPKI 작업에서 쓰이는 관계와의 조정도 유도한다. 이런 재사용은 프로토콜 난잡함을 줄일 수 있다.

그러나 해석 위험을 넓힐 수도 있다. "다운스트림"은 법적 위임, 데이터 품질, 서비스 수준, 보증이 아니라 토폴로지를 기술한다. 홀더가 유지하는 하위 이름을 위한 링크와 위임된 RPKI 데이터를 위한 링크는 서로 다른 정책 합의를 넘나들 수 있다. 클라이언트는 동일한 링크 유형이 모든 곳에서 동일한 신뢰 모델을 만든다고 가정하지 말고, 관계의 적용 맥락을 보존해야 한다.

RFC 9224 부트스트랩은 등록된 자원을 어디서 시작해야 하는지 알려 준다. RFC 9910은 레지스트리 계층 구조 안에서 대상을 탐색하는 데 쓰이는 관계를 정의한다. 제안된rdap-base-down과rdap-base-up쌍은 다른 사건, 즉 서비스 간, 그리고 흔히 발언자 간의 경계 통과를 표시한다. Web Linking의 재사용은 경계가 여전히 읽을 수 있을 때만 기술적으로 경제적이다.

권한 경계를 보존하라

나는 따라가는 모든 홀더 추천에 대한 권한 경계 기록을 제안한다. 이는 드래프트의 일부가 아니며, 탐색이 무음 승인이 되지 않도록 클라이언트나 다운스트림 데이터베이스가 필요로 하는 근거다.

첫 번째 계층은 레지스트리 주장을 기록한다. 부트스트랩 경로, 포괄 대상, 레지스트리 서비스, 관계, 지정된 대상, 지정 채널, 인증된 주체, 활성화 시각, 범위, 최근 적합성 확인. 행정 인터페이스가 이 중 일부 필드를 노출하지 않으면, 기록은 그것을 발명하는 대신 알 수 없음이라고 명시한다.

두 번째 계층은 경계 통과를 기록한다. 조회 경로, 클라이언트가 일반 리디렉션을 따랐는지 명시적 관계를 따랐는지 여부, 리디렉션 상태, 억제 선택, 대상 URL, TLS 결과, 검색 시각, 홉 수. 사용자에게 홀더가 질의를 관찰할 수 있다는 경고가 주어졌는지 여부도 기록한다.

세 번째 계층은 홀더 주장을 별도로 기록한다. 응답 서비스, 하위 대상, 응답 시각, 적용 가능한 적합성 토큰, 캐시 수명, 포괄 레지스트리로의 역방향 링크. 표시는 유용한 세부 정보를 보여 주면서도 "홀더가 주장함"이라고 밝힐 수 있다. 상위 기록을 대체하는 대신 나란히 보여 줄 수 있다.

실패 경로도 똑같이 중요하다. 홀더 서비스에 접근할 수 없으면 클라이언트는 포괄 레지스트리 응답을 유지하고 실패한 하위 계층을 식별해야 한다. 포인터가 폐지되었거나 상위 소유자가 바뀌면, 캐시된 하위 주장에는 제한된 수명이 필요하다. 응답이 엄격한 범위를 벗어나면 클라이언트는 추천을 통해 그것을 세탁하는 대신 거부해야 한다.

개정판 01은 2026년 7월 21일자 활성 개인 Internet-Draft다. Datatracker는 이것이 공식 IETF 지위, 스트림, 의도된 RFC 상태를 갖지 않는다고 밝히는 반면, 렌더링된 헤더는 Standards Track이라고 표시한다. 저자는 그 실질이 REGEXT 워킹그룹 추천 드래프트에 병합되기를 선호한다. 구현 섹션은 홀더 측 서비스가 운영 중이라고 보고하면서도 레지스트리 측 추천이 빠진 홉이라고 지적한다. 이는 유용한 구현 맥락이지, 광범위한 배포나 채택된 합의의 증거가 아니다.

이 제안은 실제 공백을 다룬다. 중요한 하위 기록이 부트스트랩 계층 구조가 찾을 수 없는 곳에 존재할 수 있다. 지속 가능한 답은 모든 데이터를 위로 끌어올리도록 강요하는 것이 아니다. 권한이 눈에 보이는 계층으로 남은 채 탐색이 아래로 내려가도록 하는 것이다. 경계 없는 인터페이스는 두 발언자가 하나처럼 들리지 않게 만들 때만 좋은 설계다.

출처