요약

  • RFC 9083은port43을, 포함하고 있는 등록 객체를 찾을 수 있는 WHOIS 서버의 호스트명 또는 IP 주소로 정의했다.
  • 이 필드는 URI가 아니었고, 해당 WHOIS 엔드포인트가 살아 있거나, 동등한 데이터를 반환하거나, 클라이언트가 실제로 사용한다는 보장도 하지 않았다.

구식 서비스는 작은 와이어 포맷을 갖고 있었다

1982년 SRI-NIC의 NICNAME/WHOIS는 짧은 트랜잭션을 통해 접근하는 네트워크 디렉터리로 기술되었다. 클라이언트는 TCP 43번 포트에 접속해 CRLF로 끝나는 명령줄 하나를 보내고, 결과를 받으면 서버가 연결을 닫았다. 같은 초기 사양은 소켓 43을 통한 NCP 접근도 문서화했다. 그 독자는 사람이었고, 응답은 이름, 메일박스, 기타 디렉터리 정보를 텍스트로 담았다. 물음표를 보내면 서버가 현재 질의 지침을 알려 주었으며, 문법은 진화할 것으로 예상되었다.

1985년 개정판은 이 청중의 경계를 명시적으로 만들었다. WHOIS는 이름, 핸들, 메일박스를 검색할 수 있었고, 앞에 별표를 붙이면 그룹의 전체 구성원 목록이나 호스트의 모든 승인된 사용자를 요구할 수 있었다. 이 RFC는 큰 목록은 시간이 오래 걸릴 수 있다고 경고했다. 질의 언어는 조회 범위를 크게 넓힐 수 있었지만, 응답은 여전히 안정적인 객체 모델로 구문 분석하는 대신 사람이 읽도록 의도된 것이었다.

이 역사가 중요한 이유는port43이 옛 응답의 사본을 담지 않기 때문이다. 이 필드는 그 객체를 가지고 있을 수 있는 구식 서비스를 이름으로 지정한다. 여기서의 차이는 데이터 표현과, 그에 대한 데이터를 반환할 수 있는 다른 시스템으로의 경로 사이의 차이다.

RDAP는 교환의 형태를 바꿨다

2004년에 발행된 RFC 3912는 WHOIS 사양을 와이어 상 프로토콜로 좁혔다. 서버는 여전히 TCP 43번 포트에서 대기했고, 클라이언트는 텍스트 요청을 보내고 텍스트를 받았다. 연결 종료가 응답의 끝을 표시했다. 프로토콜 자체는 표준화된 결과 스키마, 문자셋 표시, 접근 제어, 무결성 메커니즘, 기밀성 메커니즘을 제공하지 않았다. 이러한 한계는 해당 RFC에 문서화되어 있으며, 모든 역사적 WHOIS 서비스가 동일하게 동작했거나 모든 기록이 부정확했다는 뜻은 아니다.

2015년 RDAP 작업은 전혀 다른 공통 표면을 제시했다. RFC 7480은 등록 데이터 서비스의 HTTP 동작을 규정하고 표준화된 질의와 응답, 리디렉션, 국제화된 이름과 지역화된 등록 정보 지원을 요구했다. RFC 7481은 RDAP가 다른 프로토콜 계층을 통해 사용할 수 있는 인증 및 접근 제어를 포함한 보안 서비스를 기술했다. 2021년에는 RFC 9082가 질의 패턴을, RFC 9083이 JSON 응답 구조를 규정했다.

기록은 구식 서비스가 사라졌다고 가장할 필요가 없었다. RFC 9083 4.7절은port43이라는 멤버를 정의한다. 이는 포함하고 있는 객체 인스턴스를 찾을 수 있는 WHOIS 서버의 완전한 호스트명 또는 IP 주소를 담는 문자열이다. 문서는 정확한 한계도 덧붙인다. WHOIS URI 스킴이 존재하지 않기 때문에 이 값은 URI가 아니다. 예시에는whois.example.net같은 서버 이름이 이 필드에 들어간다.

포인터는 다리가 아니다

이 필드는 전환을 기록 자체 안에서 보이게 만든다. 클라이언트는 구조화된 RDAP 객체를 받으면서 그 객체와 연관된 WHOIS 서버가 있음을 알 수 있다. 이는 호환성 단서이지 전송 방식의 변환이 아니다.port43은 WHOIS 명령도, 질의 문법도, 응답 형식도, 자격 증명도, 옛 결과와 새 결과가 같은 현재 등록을 가리키는지 판단하는 규칙도 담지 않는다.

표현도 한정되어 있다. 그 서버에서 객체를 "찾을 수 있을" 뿐이다. 이 필드는 서버에 도달 가능하다는 요구, 권위 있음의 증명, RDAP와 같은 값을 반환한다는 인증을 요구하지 않는다. RDAP 클라이언트가 이 포인터를 따라간다는 보장도 없다. 이 문제들은 레지스트리 운영자, 그들이 공개하는 데이터, 클라이언트 정책에 남아 있다.

이 경계는 두 프로토콜이 모두 등록 데이터를 노출하기 때문에 놓치기 쉽다. 그러나 JSON 속의 호스트명은 살아 있는 조회가 아니며, 살아 있는 조회도 기록의 권위나 정확성의 증거가 아니다. RDAP의 구조화된 응답은 인터페이스의 형태를 개선했고,port43은 그 뒤에서 서비스들을 통합한다고 주장하지 않은 채 이웃 서비스의 이름을 남겨 두었다.

운영자가 주목해야 할 것

두 인터페이스를 모두 소비하는 시스템에는 구체적인 확인 항목이 유용하다.port43값이 존재하는지, 그 값이 규정된 호스트명 또는 IP 주소로 구문 분석되는지, 예상 정책 하에서 TCP 43번 포트에 도달 가능한지, 그리고 구식 질의가 RDAP 객체와 비교할 수 있는 결과를 반환하는지가 그것이다. 포인터가 바뀌거나 사라지는 것은 의존 관계를 점검하라는 신호이지, 그 자체로 할당이 이동했거나 한 레지스트리가 다른 레지스트리보다 권위를 갖게 되었다는 증거가 아니다.

같은 구분은 통합 계획에도 적용되어야 한다. 클라이언트는 WHOIS를 시도할지, 어떤 질의 문법을 보낼지, 타임아웃을 어떻게 처리할지, 무엇을 불일치로 볼지에 대한 명시적 결정이 필요하다. 이 규칙들을 암묵적으로 두면, 가능한 서버를 식별하도록 설계된 필드가 숨은 런타임 의존성으로 변할 수 있다.

통제는 기록과 엔드포인트에 걸쳐 있다

레지스트리는 RDAP 객체에 어떤 서비스 주소를 넣을지, 그 서비스를 어떻게 유지할지 통제한다. 스키마는 필드의 의미를 정의한다. 클라이언트 작성자는 그것을 사용할지 결정한다. 이 선택 중 어느 하나만으로 두 기록이 동등해지는 것은 아니다.

포인터를 남겨 두면 점진적 전환이 쉬워질 수 있다. 새 클라이언트는 구조화된 데이터를 소비하면서, 여전히 필요한 경우를 위해 구식 경로가 발견 가능한 상태로 남는다. 그 대가는 새 인터페이스가 오래된 엔드포인트에 대한 운영 의존성을 물려받을 수 있다는 점이다. 운영자가 그 서비스를 폐지하면서도 공개된 객체에 낡은 포인터를 남겨 두면, 클라이언트는 더 이상 동작하지 않는 경로를 계속 시도할 수 있다. 이는 아키텍처에서 도출된 그럴듯한 실패 모드이지, 이 RFC들이 문서화한 사건은 아니다.

따라서 2021년 스키마는 종료일을 정하지 않은 채 공존을 기록한다. 구식 서비스를 이름으로 지정하는 필드는 독자가 경계가 어디에 남아 있는지 보는 데 도움이 될 수 있지만, 언제 제거할지는 클라이언트, 데이터 대응성, 서비스 운영에 대한 근거를 요구한다. 표준은 포인터를 정의할 뿐, 운영자를 위한 마이그레이션 결정을 대신 내려 주지 않는다.

출처