요약

  • RFC 9537은 RDAP 서버가 레닥션(redaction)한 필드, 사용된 방법, 레닥션 전후 형태와 연관된 경로를 식별할 수 있게 합니다. 이는 응답에 남은 모호성을 좁혀줄 뿐, 보호된 값을 공개하거나 독립적으로 검증해 주지는 않습니다.
  • reason은 선택 사항이고, 정책 내용은 RFC 범위 밖이며, 필드의 존재 자체를 인정하는 것조차 정보를 유출할 수 있는 경우 서버는 레닥션 신호를 생략할 수 있습니다. 건전한 감사를 위해서는 쿼리, 서버, 접근 등급, 원시 응답, 시각, 경로 평가, 정책 버전을 별개의 영수증으로 보존해야 합니다.

하나의 빈칸, 여러 역사

등록자 전화번호를 모두 생략한 두 개의 도메인 조회를 생각해 봅시다. 첫 번째 기록에서는 아무도 전화번호를 제공하지 않았습니다. 두 번째에서는 레지스트리가 전화번호를 보유하고 있지만 공개 클라이언트는 그것을 볼 자격이 없습니다. 독자에게 전달되는 JSON은 똑같이 비어 보일 수 있지만, 그 뒤에 있는 역사는 실질적으로 다릅니다.

이 모호성은 인터페이스 설계 이상의 의미를 갖습니다. 등록 데이터 완전성을 측정하는 연구자는 둘 다 누락으로 셀 수 있습니다. 조사자는 두 번째 값이 애초에 존재한 적이 없다고 가정할 수 있습니다. 컴플라이언스 시스템은 침묵을 제한이 적용되지 않았다는 증명으로 취급할 수 있습니다. 이런 결론은 각각 응답에 담기지 않은 사실 하나를 더합니다.

2024년 3월에 발표된 RFC 9537은 이 좁은 문제를 다룹니다. RDAP 객체에redacted멤버를 정의하여 서버가 제거했거나, 비웠거나, 일부만 감추었거나, 다른 값으로 대체한 필드를 식별할 수 있게 합니다. 이 문서는 James Gould, David Smith, Jody Kolker, Roger Carney가 저술했습니다. 2026년 9월 7일 기준으로 이 기사를 위해 수집된 Gould의 IETF 기록은 등록 프로토콜 분야의 열세 편의 RFC를 나열합니다. Registration Operations Workshop은 그를 도메인 레지스트리 서비스의 아키텍처·기술 방향을 책임지는 Verisign 펠로로 소개합니다. 이 사실들은 이 작업을 오랜 등록 프로토콜 실무 안에 자리매김합니다. 그러나 Gould를 유일한 발명자로, 또는 다른 누군가의 배포를 보증하는 사람으로 만들지는 않습니다.

이 설계의 강점은 절제에 있습니다. 서버에 출력에 관한 단 하나의 단언을 위한 구조화된 어휘를 제공합니다. 그것을 둘러싼 정책 논쟁을 해결한다고 주장하지는 않습니다.

redacted멤버가 말할 수 있는 것

이 확장을 사용하는 응답은rdapConformance에redacted를 광고합니다. 객체에 레닥션된 필드가 하나 이상 있으면 보통 레닥션 설명 배열이 포함됩니다. 각 설명에는 필수인 논리적name이 있으며, 등록된 유형 또는 미등록 서술 텍스트로 제공됩니다.

경로는 이 이름을 응답 형태와 연결합니다.prePath는 필드가 제거되기 전에 차지하던 위치를 가리킬 수 있으며, 정의상 클라이언트가 받은 JSON에서는 해석되지 않아야 합니다.postPath는 남아 있는 빈 값, 부분 값 또는 대체 값을 가리킵니다. 둘은 상호 배타적입니다. 다른 필드가 대체값을 담고 있을 때replacementPath가 그 위치를 찾아줄 수 있습니다. JSONPath가 기본 표현식 언어인데, 이는 클라이언트에 공통 문법을 제공하면서도 사람이 읽는 레이블을 영구적인 스키마 좌표처럼 다루지 않게 합니다.

이것은 유용한 증거입니다. 서버는 더 이상 클라이언트가 단순히 구멍만 보고 레닥션을 추론하도록 강요하지 않습니다. 클라이언트는 서버가 필드 이름을 지정하고, 방법을 선택하고, 경로와 연결했다는 사실을 기록할 수 있습니다. IANA의 RDAP 레지스트리는 널리 쓰이는 확장 식별자, 이름, 이유, 경로 언어 값을 여러 구현에서 재사용 가능하게 만듭니다.

그러나 이 단언에는 한계가 있습니다.prePath는 그 자리에 있던 바이트를 담고 있지 않습니다. 논리적 이름은 기저 기록이 정확했다는 증명이 아닙니다. 방법은 올바른 접근 규칙이 선택되었다는 증명이 아닙니다. 인증된 응답조차 그 연결과 접근 맥락에서 응답한 서비스가 단언한 것만을 증명합니다. 감춰진 데이터베이스 행의 공증된 사본이 아닙니다.

네 가지 방법이 남기는 서로 다른 네 가지 잔재

RFC 9537은 네 가지 레닥션 방법을 구분합니다. “보이지 않음”이 JSON에서 단일한 상태가 아니기 때문입니다.

제거(removal)는 전달된 응답에서 필드나 객체를 삭제합니다. 위치 자체에 의미가 있는 배열을 깨뜨리는 경우를 제외하고,method가 없을 때의 기본 방법입니다. 위치 기반 jCard 데이터에서는 빈 값으로 배열을 유지하면서 보호된 자리를 빈 문자열이나 null로 바꿀 수 있습니다. 부분 값 레닥션은 주소 레이블의 일부 같은 형식화된 나머지를 남깁니다. 대체 값 레닥션은 익명화된 이메일이나 연락 폼처럼 다른 값이나 다른 필드로 대체합니다.

이런 잔재들을 증거 시스템에서 평탄화해서는 안 됩니다. 제거된 객체는 남아 있는 빈 위치와 같은 방식으로 검사할 수 없습니다. 부분 주소는 여전히 무언가를 공개합니다. 연락 URI는 원래 메일박스를 드러내지 않으면서 연락 가능성을 보존할 수 있지만, 그것은 등록자의 이메일 주소가 아닙니다. RFC 9537은 또한 임의 텍스트가 필드 형식을 위반하고 신뢰할 수 없는 신호를 만들 수 있어서 문자 반복 채움을 레닥션 기법으로 거부합니다.

실용적인 시험은 간단합니다. 화면이 보여주기로 선택한 것이 아니라 클라이언트가 실제로 받은 것을 기록하십시오. 사용자 인터페이스는 네 경우를 모두 “레닥션됨”으로 렌더링할 수 있습니다. 감사에는 그 레이블을 뒷받침하는 방법, 경로, 원시 응답 형태가 필요합니다.

이유는 정책 판정이 아니다

각 레닥션 설명은reason을 담을 수 있습니다. 그 이유는 등록된 유형이나 자유 서술 텍스트를 사용할 수 있습니다. 그러나 설명이 처리 의존성이 되는 것은 명시적으로 금지되어 있습니다. 이는 사람을 위해 쓰인 문구 위에 결과를 좌우하는 자동화를 세우지 말라는 경고입니다.

같은 분리가 정책에도 적용됩니다. 서버는 레닥션 정책을 게시할 수 있지만, RFC 9537은 그 내용을 사양 밖으로 남겨 둡니다. 이 RFC는 어느 클라이언트에게 전화번호를 줄지, 동의가 유효한지, 법원 명령이 어떻게 적용되는지, 특정 공개가 계약상 요구되는지를 결정하지 않습니다. RFC 7481은 인증과 등급별 접근 메커니즘을 로컬 승인 정책 아래 제공할 뿐, 하나의 보편적 접근 정책을 RDAP의 일부로 만들지 않습니다.

ICANN의 2024년 gTLD 응답 프로파일은 한 이해관계 집단이 더 구체적인 계층을 추가하는 방식을 보여줍니다. 이 프로파일은 이름이 지정된 등록 데이터 요소를 RFC 9537 기법에 매핑하고 이메일 같은 필드에 특정 처리를 요구합니다. 그 프로파일은 그 범위 안의 서비스에 중요한 운영 증거입니다. 그러나 기본 확장이 아니며, 모든 레지스트리, 레지스트라, 지역 인터넷 레지스트리에 투영될 수 없습니다.

또 하나의 비대칭이 있습니다. “등록자 필드가 존재하지만 숨겨져 있다”고 말하는 것 자체가 정보를 드러낼 수 있습니다. 따라서 RFC 9537은 존재 신호가 프라이버시 문제를 일으킬 때 서버가 레닥션 항목을 생략하는 것을 허용합니다. 침묵은 레닥션의 반대말이 아닙니다. 표시가 없는 응답은 완전할 수도 있고, 확장을 구현하지 않은 서버에서 왔을 수도 있고, 보호된 필드의 존재를 인정하지 않기로 의도적으로 피한 것일 수도 있습니다. 독자가 그 설명들 중 하나를 고르려면 더 많은 증거가 필요합니다.

운영자가 보존해야 할 영수증

가장 작은 유용한 감사 기록은 응답 본문 이전에 시작합니다. 정확한 조회 또는 검색 URI, 권위 있는 서버와 모든 리디렉션, 검색 시각, 전송 신원, 클라이언트의 인증·승인 등급을 보존하십시오. 공개 익명 쿼리와 권한 있는 인증 쿼리는 같은 도메인을 요청하더라도 서로 다른 관찰입니다.

그다음 원시 응답 바이트 또는 검증 가능한 해시를 보존하십시오.rdapConformance, RDAP 기록 식별자, 그리고 모든 레닥션 항목의 name, 경로 언어, 경로, 방법, 이유를 추출하십시오.postPath가 받은 객체에 대해 해석되었는지,prePath는 어떻게 해석되었는지 기록하십시오. 후자는 더 이상 존재하지 않는 형태를 서술하기 때문입니다. 디코더와 JSONPath 구현 버전을 남기십시오. 그렇지 않으면 경로 평가의 변화가 서버 변화처럼 위장할 수 있습니다.

응답이 정책으로 링크되어 있으면 그 시점에 관찰된 정확한 URL과 버전을 기록하십시오. 나중의 정책 페이지가 이전 응답에 적용된 규칙의 증거가 되지는 않습니다. 두 개의 뷰를 비교할 때는 익명 JSON 문서를 빼고 그 차이를 공개 결정이라 부르는 대신, 각각을 자신의 접근 등급과 타임스탬프에 결합하십시오.

RFC 9082의 조회와 검색 구분도 영수증에 들어갑니다. RFC 9537은 레닥션 설명을 조회의 단일 객체와 검색 결과의 개별 객체에 붙입니다. 검색의 최상위 잘림은 한 결과에서 필드가 제거된 것과 서로 바꿔 쓸 수 없습니다. RFC 9083의 notices와 remarks는 응답 전체 또는 객체 단위 조건을 설명할 수 있지만, 필드별 구조화 신호를 대체하지 않습니다.

이렇게 모은 묶음은 절제된 결론을 지지합니다. 이 서버는, 이 쿼리와 접근 맥락에서, 이 필드를 이런 방식으로 레닥션되었다고 서술했다는 것입니다. 그보다 강한 진술은 다음 영수증—정책 권위, 원천 기록 무결성, 클라이언트 자격, 공개 검토—를 필요로 합니다.

출처