요약

  • RFC 3663은 비정규화된 LDAP 디렉터리 표현을 직접 구축할 경우 약 2,000만 개의 관계형 데이터베이스 객체가 1억 1,500만 개 이상의 디렉터리 객체로 늘어날 수 있다고 추정했습니다.
  • 레퍼럴은 관계와 운영 경계를 보존할 수 있다고 약속했지만, 클라이언트 간 일관성 부족과 레퍼럴 루프로 인해 파일럿은 정규화된 백엔드 위에 맞춤형 비정규화 뷰를 두는 방향으로 전환했습니다. 클라이언트는 여전히 해당 디렉터리 트리 구조를 이해해야 했습니다.

두 번 설계된 디렉터리

첫 번째 설계 문제는 도메인을 검색하는 방법이 아니었습니다. 문제는 도메인 주변의 관계를 어떻게 표현할 것인가였습니다. 도메인에는 연락처와 네임서버가 있을 수 있고, 하나의 네임서버는 여러 도메인을 서비스할 수 있으며, 레지스트리와 레지스트라는 행정 기록의 서로 다른 부분을 관리합니다. 각 관계를 트리에 직접 배치하면 공유되는 항목이 여러 번 반복될 수 있습니다.

2003년 12월의 실험 메모에서 Andrew Newton은 VeriSign의 Referral LDAP Service를 LDAP과 익숙한 LDAP 타입을 통해 도메인 등록 데이터를 제공하려는 파일럿으로 소개했습니다. 제안된 비정규화 Directory Information Tree(DIT)는 RFC의 추정에 따르면 약 2,000만 개의 관계형 데이터셋을 1억 1,500만 개 이상의 디렉터리 객체로 확장하게 됩니다. 이것은 실측된 배포 결과가 아닙니다. 디렉터리 모델을 명명 방식의 문제가 아니라 운영상의 질문으로 만든 규모 추정치입니다.RFC 3663

프로젝트는 역사적 순서에서 출발했습니다. 원래의 InterNIC 계약은 행정 도메인 데이터를 위한 X.500 디렉터리를 요구했습니다. 이용 가능한 X.500 서버 구현의 문제로 인해 임시 NICNAME/WHOIS 서비스가 제공되었습니다. RWhois는 이후 이 모델을 확장하려 했으나, RFC 3663은 도메인 데이터 분야에서 널리 받아들여지지 않았다고 말합니다. 메모 자체의 개입은 더 좁았습니다. 레지스트리와 레지스트라 책임 분리, 데이터 마이닝 우려, WHOIS 출력의 기계 판독 곤란이라는 상황 속에서 LDAP을 더 구조화된 인터페이스로 시도하는 것이었습니다.RFC 954RFC 2167RFC 3663

레퍼럴은 복잡성을 바깥으로 밀어냈다

초기 DIT 설계는 최상위 도메인 트리와 별도의 네임서버·연락처 트리 사이에 레퍼럴을 사용했습니다. 이를 통해 모든 공유 레코드를 복제하지 않을 수 있었고, 데이터를 여러 서버에 분산할 가능성도 열어 주었습니다. 그러나 LDAP 레퍼럴은 단순한 또 하나의 행이 아닙니다. 클라이언트는 이를 따를지, 어떻게 따를지 결정하고, 검색의 의도를 다른 서버로 전달하며, 돌아오는 결과를 처리해야 합니다.

ldapsearch를 이용한 테스트는 레퍼럴 동작에 대한 해석이 클라이언트마다 일관되지 않음을 드러냈습니다. 일부 클라이언트는 루프에 빠질 수 있었습니다. 파일럿은 이에 따라 데이터를 정규화된 형태로 유지하면서 클라이언트에게는 비정규화된 뷰를 제시하는 맞춤형 백엔드를 채택하여 문제가 되던 서버 내부 레퍼럴을 피했습니다. RFC 3663에 따르면 대규모 데이터셋에는 이러한 맞춤형 백엔드가 필요할 가능성이 높고, 더 작은 데이터셋은 기성 서버로 충분할 수 있습니다. 이 설계가 레코드 간 연결을 없앤 것은 아닙니다. 그 연결을 조립해야 하는 위치를 옮긴 것입니다.RFC 3663

레지스트리와 레지스트라 서버 사이의 레퍼럴은 다른 목적을 담당했습니다. 두 서비스는 서로 다른 조직, 기기 또는 네트워크에서 운영될 수 있다는 조직적 분할을 나타낸 것입니다. 그러나 검색 결과에는 제공된 필터 범위 밖의 레퍼럴이, 흔히 50개 항목이라는 크기 제한에 걸릴 때까지 채워질 수 있었습니다. 쿼리는 사용자가 기대한 레코드 대신 목적지 목록을 돌려줄 수 있었습니다. 메모는 이를 LDAP 프로토콜의 결함에 대한 증거가 아니라 서비스 모델의 분산 문제로 다룹니다.RFC 3663RFC 2251

범용 프로토콜, 특정 지도

이 실험은 “범용 클라이언트”라는 표현에도 한계를 발견했습니다. LDAP은 공통 접근 프로토콜을 제공했지만, 클라이언트는 서비스의 DIT와 스키마에 대한 알고리즘적 지식이 필요했습니다. 그래픽 클라이언트는 수정 없이 다른 LDAP 디렉터리에 연결해서는 그 데이터를 온전히 활용할 수 없었습니다. 구조적 차이를 모두 숨기는 클라이언트는 정보를 덜 노출하거나 일반적인 사용에는 지나치게 복잡해질 수밖에 없었습니다.RFC 3663

이 격차는 코드에서만 아니라 인터페이스에서도 나타났습니다. 웹 클라이언트는 일부 사용자에게 자신이 데이터에 접근하는 유일한 경로인 것처럼 느껴졌고, LDAP 프로토콜과 레지스트리–레지스트라–등록인 구조는 검색 결과에서 설명하기 어려운 부분으로 남았습니다. C와 Java 클라이언트는 중첩 쿼리와 레퍼럴 추적을 수행할 수 있었지만, 반복적으로 문제가 된 것은 라이브러리 능력이 아니라 사용성이었습니다. RFC는 인기 측정조차 정확하게 할 수 없다고 경고합니다. 이것들은 파일럿 관찰이지 모수 연구가 아닙니다.RFC 3663

이 서비스가 공개 데이터를 둘러싼 통제 문제를 해결한 것도 아니었습니다. 임의의 LDAP 검색은 비용이 너무 클 수 있었기에 특정 쿼리 형태만 허용했지만, 사용자들은 그 한도를 우회하기 위해 이름을 재귀적으로 추측하는 방법을 문의했습니다. 메모는 많은 WHOIS 운영자가 이런 사전식 쿼리를 데이터 마이닝으로 간주했다고 기록합니다. 보안 절은 이례적으로 직설적입니다. 실증된 distinguished-name/비밀번호 통제는 프로덕션 모델로서 충분하지 않다는 것입니다. 이 실험을 현대적인 접근 통제 권고로 읽어서는 안 됩니다.RFC 3663RFC 2026

교훈은 배치에 관한 것이었다

RFC 3663의 가장 오래 지속되는 역사적 가치는 공학적 솔직함입니다. 디렉터리 기술은 이식 가능한 사용자 경험을 제공하지 않고도 익숙한 작업을 제공할 수 있었습니다. 데이터 정규화는 객체 증식을 줄였지만, 클라이언트가 필요로 하는 뷰는 맞춤형 백엔드가 다시 만들어야 했습니다. 레퍼럴은 서버 간 경계를 보존했지만, 그 유용성은 클라이언트 동작, 쿼리 한도, 그리고 레지스트리·레지스트라·등록인 사이의 사회적 분업에 좌우되었습니다.

메모는 사용자가 특정 레지스트라나 등록인을 원하더라도 검색은 여전히 레지스트리 계층에서 시작된다는 점, 그리고 DNS SRV 또는 NAPTR 기반 탐색은 구현되지 않았다는 점을 밝혔습니다. LDAP 서버 조사도 경계가 분명했습니다. 네 개의 존 파일, 도메인 이름과ldap또는dir호스트명에 대한 389 포트 프로브, SRV 조회 없음이 전부였습니다. 보고된 추정치 — 해당 표본의 활성 도메인 중 약 0.5%에 LDAP 서버가 있었다는 것 — 는 현재 시점이나 인터넷 전체의 통계로 취급할 수 없습니다.RFC 3663

그 트레이드오프는 “트리냐 데이터베이스냐”의 문제가 아니었습니다. 관계형 레코드, 디렉터리 뷰, 레퍼럴 대상, 사용자의 질문 사이의 번역을 누가 담당할 것인가의 문제였습니다. 파일럿은 수백만 번 반복되는 객체나 취약한 레퍼럴 체인 대신, 그 일부를 맞춤형 서버와 전용 클라이언트에 집중시켰습니다. 공통 프로토콜은 조각들을 알아볼 수 있게 만들었습니다. 그러나 지도의 필요성을 없애지는 못했습니다.

출처