요약

  • RFC 3088은 LDAP 식별 이름의 자격 있는 도메인 컴포넌트 접미사를 DNS 도메인으로 변환해_ldap._tcpSRV 레코드를 조회하고, LDAP URL을 레퍼럴로 반환했습니다.
  • 루트 서비스는 전역 디렉터리 데이터베이스가 아니라 부트스트랩 지점이었습니다. RFC는 클라이언트가 로컬 서비스를 사용하고, 레퍼럴을 받았을 때만 루트를 찾도록 권고했습니다.

디렉터리 경로의 최상위 서버가 디렉터리 자체를 저장할 필요는 없었습니다. 2001년 4월, OpenLDAP 프로젝트는 LDAP 클라이언트가 도메인 기반 이름을 소유할 수 있는 서버를 찾도록 돕는 실험적 "루트 서비스"를 소개했습니다. 그 결과물은 레퍼럴, 즉 다음에 갈 수 있는 주소 목록이었지, 찾고자 하는 사람이나 조직 레코드가 아니었습니다.

이 구분이 중요했던 이유는 LDAP 이름이 신뢰할 수 있는 등록과 서비스 위치 메커니즘이 없는 계층 구조를 따를 수 있었기 때문입니다. RFC 2247의 도메인 기반 명명은 식별 이름이 DNS 레이블에 대응하는DC컴포넌트를 담을 수 있게 했습니다. RFC 3088은 이 구조를 다리로 사용했습니다. 이름을 검사하고, 규칙이 허용하는 범위에서 도메인을 도출한 뒤, DNS에 LDAP 서비스 위치 레코드를 질의했습니다.

이 파싱은 "사용자명을 떼어내고 나머지를 쓴다"보다 훨씬 좁았습니다. RFC의 알고리즘은 상대 식별 이름을 왼쪽에서 오른쪽으로 훑으며 자격 있는 단일 값 도메인 컴포넌트 RDN을 누적합니다. 도메인이 아닌 컴포넌트가 나오면 후보는 초기화됩니다. 예시들은 왜 형태가 중요한지 보여줍니다. 어떤 이름은 사용 가능한 접미사를 만들고, 어떤 이름은 도메인을 만들지 못하며, 특수 표기DC=.는 도메인 트리 루트에 대한 제안된 매핑을 다룹니다. 따라서 레퍼럴 서비스는 정확한 명명 형식에 의존했고, 어느 부분이 도메인처럼 보이는지에 대한 사람의 직관에는 의존하지 않았습니다.

example.net같은 도메인의 경우 서비스는_ldap._tcp.example.net을 질의합니다. RFC 2782는 DNS SRV 메커니즘을 제공합니다. 이 레코드는 대상 호스트와 포트를 식별하고 우선순위와 가중치를 담을 수 있습니다. RFC 3088은 반환된 대상들로 LDAP URL을 만들어 레퍼럴로 돌려주었습니다. 그러나 RFC에서 기술한 구현은 레코드를 리졸버 순서 그대로 반환했고, SRV 우선순위나 가중치를 스스로 적용하지는 않았습니다. DNS 데이터의 형태와 서비스 동작은 별개의 사실이었습니다.

루트 서비스는 클라이언트를 대신해 모든 레퍼럴을 따라가거나, 결과를 병합하거나, 반대편 데이터를 보증하지 않았습니다. 기본 LDAP 작업은 대상이나 검색 기준이 서비스 URL로 매핑될 수 있을 때 레퍼럴을 반환했습니다. 클라이언트나 레퍼럴을 보내는 서버는 여전히 작업을 계속해야 했고, 레퍼럴을 받은 서버가 그것을 처리해야 했습니다. 성공적인 첫 교환은 다음 질문을 물을 경로를 만들 수 있었습니다. 그러나 최종 엔트리가 존재하는지, 최신인지, 완전한지, 클라이언트가 신뢰해야 하는 권위에서 왔는지는 보장하지 못했습니다.

그래서 RFC 3088은 로컬 우선 경로를 권고했습니다. LDAP 서버는 상위 요청을 OpenLDAP 루트 서비스로 레퍼럴하도록 구성할 수 있었고, 클라이언트는 직접 접속할 수도 있었지만 RFC는 그렇게 하는 것을 만류했습니다. 클라이언트는 로컬 서비스를 사용하고 레퍼럴을 받았을 때만 루트에 도달해야 했습니다. 이렇게 해서 중앙 서비스는 조정 역할에 머물렀습니다. 별개의 디렉터리 섬들을 연결하는 데 도움을 주되, 모든 조회의 의무적인 첫 홉이나 보편적 저장소가 되지는 않았습니다.

이 제안은 명시적으로 실험적이었습니다. RFC는 그 메커니즘이 최종 확정이 아니며 이후 Standards Track 문서가 필요하다고 밝혔습니다. 예시 서비스는 TCP/IPv4 위에서 LDAPv3와 LDAPv2+를 사용했습니다. LDAPv2는 레퍼럴을 전혀 표현할 수 없었고, LDAPv2+는 다른 표현 방식을 사용했습니다. 이 호환성 세부사항은 당시 시절에 국한된 것이며, 이후 모든 LDAP 클라이언트에 대한 주장이 아닙니다.

보안 경계 역시 분명히 드러나 있었습니다. 기술된 서비스는 익명 바인드를 받아들이고 다른 바인드 시도는 거부했으며, 암호화나 정보 무결성을 제공하지 않았습니다. 공개 DNS에서 파생된 데이터를 공개했지만, RFC는 이 설계가 DNS 스푸핑과 서비스 거부에 여전히 노출되어 있다고 경고했습니다. 또한 LDAP 세션 무결성만으로는 DNS 파생 정보의 무결성에 대한 잘못된 확신을 만들 수 있다고 경고했습니다. 레퍼럴 프로토콜 홉은 그것을 만들어낸 이름-서버 매핑의 증명이 아니었습니다.

RFC 자체의 "교훈" 절은 단일 호스트에 대해 보고하고, 필요하다면 일반적인 부하 분산으로 서비스를 확장할 수 있다는 저자들의 믿음을 전했습니다. 이는 문서가 자신의 실험에 대해 말한 것이지, 용량 테스트나 서비스 보장, 채택 조사가 아닙니다. 이 글의 역사적 주장은 거기서 멈춥니다. RFC 3088은 DNS가 도메인 기반 LDAP 탐색의 접착제 역할을 할 수 있음을 보여주었지만, 최종 레코드와 로컬 정책, 클라이언트의 계속 진행은 다른 곳에 남겨 두었습니다.

출처