요약

  • REGEXT 작업반의 RDAP 확장 초안은 요청 매개변수를 리디렉션 URL에 무조건 복사하는 행위를 금지한다. 출발 서버는 대상이 매개변수를 처리할 능력과 내용을 받을 적절한 지위를 모두 갖췄음을 알아야 한다.
  • 권한 서버를 찾아 기관 경계를 넘어야 하는 확장 기능은 쿼리 매개변수의 전달을 전제로 할 수 없다. 이미 권한 서버를 알고 직접 보내는 검색에는 매개변수를 쓸 수 있다.

목적지는 맞고 주문서는 바뀌었다

한 클라이언트가 번호 자원의 등록정보를 조회하면서 확장 매개변수로 추가 화면을 요청한다. 첫 서버는 다른 기관이 해당 기록의 권한을 가진다는 사실을 알고 HTTP 리디렉션을 돌려준다. 기본 기록은 도착하지만 추가 화면은 빠질 수 있다. 이는 초안이 다루는 설계 상황이며, 확인된 장애 사례를 묘사한 것은 아니다. 다음 주소를 알려주는 행위가 첫 서버에 들어온 모든 정보를 그 주소로 넘길 권한까지 주지는 않는다.

RFC 9224는 IANA 할당 등록부를 이용해 권한 있는 RDAP 서비스를 찾는 방법을 정의한다. REGEXT 초안은 이 지도에 빠진 것을 짚는다. 자원이 지역 인터넷 등록기관 사이에서 나중에 이전되면 최초 할당 정보만으로는 현재의 담당자를 알 수 없다. 그래서 리디렉션은 실제 권한 RIR을 찾는 일상적인 경로가 된다. 매개변수의 운명은 구석의 예외 상황이 아니라 이 경로 한복판에서 결정된다.

RFC 7480은 모르는 쿼리 매개변수를 서버가 무시하도록 한다. 확장 초안은 리디렉션 URL을 작성하는 서버에 한 걸음 더 요구한다. 원래 요청의 매개변수를 무턱대고 옮겨서는 안 된다. 그 값에는 다음 서버와 무관한 보안 자격 증명이나 추적 정보가 담길 수 있다. 출발 서버는 대상이 매개변수를 처리할 줄 아는지, 그 내용을 받기에 적절한지 둘 다 확인해야 한다. 필드를 읽을 수 있다는 사실만으로 필드의 값을 받을 자격이 생기지는 않는다.

그 결과는 서비스 판매자에게 불편하다. 첫 서버가 정당한 이유로 매개변수를 빼도 클라이언트는 정상적인 기본 기록을 받을 수 있다. 화면에는 ‘조회 성공’이 뜨지만 구매자가 기대한 추가 정보는 없다. 반대로 기능을 살리겠다며 모든 값을 그대로 넘기면 다른 기관에 민감한 내용을 보여줄 수 있다. 완료 건수만 집계하는 대시보드에서는 두 결과가 똑같은 초록색 숫자로 보인다.

직접 검색은 다른 약속이다

초안은 매개변수를 전면 금지하지 않는다. 클라이언트가 권한 서버를 미리 알고 그곳에 직접 조회할 때에는 사용할 수 있으며 검색을 예로 든다. 그러나 권한 서버를 찾아 이동해야 하는 확장 기능이라면, 매개변수가 다음 기관까지 반드시 따라간다고 설계할 수 없다. 자원에 관한 필수 의미를 경계에서 제거될 수 있는 URL 끝부분에만 매달아서는 안 된다.

클라이언트가 리디렉션 응답의 RDAP 내용을 읽고 새 요청을 직접 조립하는 방안도 있다. 초안은 그 비용을 구체적으로 적는다. 일부 브라우저 기반 클라이언트는 리디렉션에 실린 RDAP 내용에 접근하지 못한다. 직접 처리하려면 순환 경로, 매개변수 충돌, URL 인코딩까지 관리해야 한다. 알려진 서버 한 곳에서 성공한 시연과 기관을 건너며 동작하는 기능은 다른 제품이다.

IETF 문서 기록에 따르면 제17판은 2026년 10월 27일자로 등록된 REGEXT 작업반의 활성 Internet-Draft이며 IESG 상태는 ‘I-D Exists’다. 아직 RFC로 발행되지 않았다. 리디렉션 규칙은 이전 판에도 있었다. 지금 주목할 부분은 이번 주에 새 규칙이 생겼다는 이야기가 아니라, 현행 문안이 판단 책임을 어디에 두는가이다.

인용한 자료에는 특정 운영자의 매개변수 유출이나 누락 사례가 제시되지 않는다. 원래 요청, Location URL, 대상의 처리 능력과 정보 수신 방침을 보여주는 실제 거래 기록이 있으면 해당 운영의 선택을 판단할 수 있다.

출처