요약

  • RFC 1279는 도메인과 조직을 구분하고 메일박스와 사람을 구분하면서 도메인을 X.500 디렉터리에 표현했다. 대상이 서로 달랐기 때문에 이 메모는 별칭(aliasing)을 두 트리 사이의 연결 수단으로 거부했다.
  • AssociatedDomain과AssociatedName이 방향이 있는 관계를 기록했다. 선호되는 도메인 항목은 골격 상태로 유지되며 조직 정보를 복사하는 대신 그 쪽을 가리켰고, 여러 도메인이 여러 조직과 연관될 수 있도록 허용했다.
  • DNS 레코드는 DNS 서버와 디렉터리 시스템 에이전트(DSA) 사이에서 이동할 수 있었지만, 디렉터리에 대한 기록은 DNS가 아닌 속성을 그대로 두어야 했다. 레코드 전송, 보존된 속성, 포인터 삽입, 조회, 신원 확인, 운영 결과는 별개의 근거로 유지되었다.

두 트리는 서로 다른 종류의 대상을 기술했다

RFC 1279는 1991년 11월에X.500 and Domains라는 제목의 실험(Experimental) 제안으로 나왔다. 그 야망은 상당했다. DNS 도메인 계층을 X.500 디렉터리 정보 트리 안에 표현하고, 도메인 정보를 디렉터리 도구에 노출하며, X.500이 결국 DNS의 일부 관리에 도움을 줄 수 있는지 살펴보는 것이었다.

이 제안은 어느 한 명명 시스템을 승자로 선언하며 시작하지 않았다. 초기 실험은 오히려 반대 방향으로 진행될 것으로 예상했다. 정보는 계속 도메인 데이터베이스에서 마스터링된 뒤 디렉터리에 업로드될 것으로 보았다. 도구, 반복 전송, 탐색, 배포가 시험된 후에야 부록은 DNS 계층의 일부를 X.500에서 마스터링하는 단계를 상상했다.

이 시간적 순서가 중요하다. 표현은 이전이 아니었고, 전송은 권한의 변경이 아니었으며, 제안된 최종 단계는 완료된 배포가 아니었다. RFC 1279는 유용성과 성능이 아직 평가되어야 하는 실험을 기술했다.

디렉터리 안에서 도메인 레이블은DomainComponent값이 되었다.CS.UCL.AC.UK같은 이름의 계열은 DNS 모양의 분기 안에서 연속된 항목으로 표현될 수 있었다. RFC 822 메일박스의 로컬 부분은 특수한 종류의 도메인 컴포넌트로 분기를 확장할 수 있었다.

그러나 같은 디렉터리는 조직 분기도 담을 수 있었다. 대학, 부서, 사람, 역할이 각자의 대상 유형에 따라 표현되는 분기였다. 비슷한 단어가 두 분기에 모두 나타날 수 있었다. 그러나 그 시각적 유사성이 레코드를 서로 바꿔 쓸 수 있게 만들지는 않았다.

RFC 1279는 그 이유를 분명히 밝혔다. 도메인은 조직이 아니었다. 사람은 RFC 822 메일박스가 아니었다. 도메인 레이블은 한 네임스페이스 안의 위치를 기술했고, 조직 항목은 디렉터리의 다른 부분에 있는 다른 대상을 기술했다. 따라서 이 설계는 한 항목을 같은 대상의 또 다른 이름처럼 취급하는 별칭 사용을 거부했다.

포인터는 그것이 넘는 차이를 보존했다

별칭 대신 이 제안은 방향이 있는 연관을 사용했다. 조직 항목은 자신과 관련된 도메인을 지명하는AssociatedDomain을 가질 수 있었다. 도메인 항목은 조직 트리 쪽을 가리키는AssociatedName을 가질 수 있었다.

두 방향은 중복이 아니었다. 서로 다른 시작 레코드에서 서로 다른 질문에 답했다. 조직을 보고 있을 때, 어느 도메인이 연관되어 있는가? 도메인을 보고 있을 때, 어느 조직 항목이 더 풍부한 맥락을 제공하는가? 두 진술을 모두 명시적으로 유지하면 역방향 링크가 누락된 상황을 관찰할 수 있었고, 없는 링크를 조용히 만들어내는 일을 막았다.

이 제안은 보편적인 일대일 관계를 가정하지도 않았다. RFC 1279는 하나의 도메인이 여러 조직과, 하나의 조직이 여러 도메인과 연관될 수 있다고 명시했다. 따라서 포인터는 고유성 증명서가 아니라 명시된 관계에 대한 근거였다.

이 경계는 매력적이지만 무효인 여러 결론을 차단한다. 링크된 도메인이 그 자체로 법적 소유를 증명하지 않았다. 조직을 가리키는 도메인 항목이 서비스 운영자를 인증하지 않았다. 메일박스 모양의 항목이@앞의 문자열을 검증된 사람으로 바꾸지 않았다. 디렉터리는 연관을 유지할 수 있었지만, 그 연관이 독자가 원하는 모든 의미를 갖고 있다는 근거를 얻지는 않았다.

이것이 관계와 신원의 차이다. 신원은 대체를 허용한다. 두 레코드가 같은 대상을 나타낸다면 정해진 규칙 안에서 한 이름이 다른 이름을 대신할 수 있다. 관계는 그렇지 않다. 관계에는 서술어, 방향, 출처, 시점이 필요하다. 이 자격 조건들을 제거하면 그래프는 근접성을 권위로 세탁하는 기계가 된다.

골격 항목은 경쟁하는 진실의 수를 줄였다

RFC 1279는 도메인에 진정으로 속하는 정보가 도메인 항목에 남아 있도록 허용했다. 거기에는 DNS 데이터와 도메인 고유의 관리 세부사항이 담길 수 있었다. 그러나 조직 트리에 이미 관련 정보가 있는 경우, 이 메모는 도메인 쪽 레코드가 비교적 골격 상태로 유지되고 더 풍부한 항목을 가리키도록 권고했다.

정보가 중복되어서는 안 된다고 명시했다. 이것은 단순히 저장 공간을 아끼려는 선호가 아니었다. 두 개의 사본은 두 명의 기록자, 두 개의 갱신 시계, 값이 갈라질 때 풀리지 않는 질문을 만든다.

도메인 레코드가 조직 레코드에서 담당자 전화번호를 복사했다고 가정해 보자. 이후 인사 변동으로 조직 쪽만 갱신되고 도메인 쪽은 그대로 남았다. 두 값은 여전히 문법상 유효했다. 검색 결과는 어느 쪽이든 표시할 수 있었다. 두 사본이 하나의 오래된 진술에서 왔음에도 반복은 확인처럼 보였다.

포인터는 관리 소관을 눈에 보이게 유지한다. 조직 항목은 자신의 기술 속성을 소유한다. 도메인 항목은 연관을 소유한다. 소비자는 링크를 따라가 결합된 뷰를 제시할 수 있지만, 그 제시가 어느 쪽 사실의 출처도 다시 쓰지는 않는다.

이것은 수정도 개선한다. 연관이 잘못되었다면 조직을 다시 쓰지 않고 링크만 바꿀 수 있다. 연락처 세부사항이 바뀌었다면 한때 그것을 복사했던 모든 도메인을 훑지 않고 출처에서 수정할 수 있다. 시스템은 대상과 독자가 그 대상에 도달한 이유를 모두 보존한다.

DNS 문법은 DNS 런타임 동작을 함께 가져오지 않았다

RFC 1279는 DNS 자원 레코드를 텍스트 유래 형태로 디렉터리에 저장할 것을 제안했다. 완전히 지정된 도메인 이름과 각 레코드에 명시적인 TTL을 요구했다. 하나의 확장 가능한DNSRecord속성을 두면 DNS에 새 레코드 유형이 생길 때마다 새 디렉터리 속성을 정의할 필요가 없었다.

이 문서는 저장된 DNS 정보가 정확히 동등하기를 원했고, 그래야 데이터가 DNS와 X.500 사이에서 이동할 수 있었다. 그러나 동시에 한계도 그렸다. OSI 디렉터리는 DNS 캐싱이나 TTL 처리를 흉내 내지 않는다. 마스터 항목은 DNS 영역 전송이나 이에 상응하는 방법으로 유지되며, 실험 안에서 권위 있는 것으로 다뤄질 수 있다고 가정했다.

명시적 TTL 필드와 작동 중인 캐시 시계는 같은 레코드가 아니다. RFC 1035는 TTL을 자원 레코드가 다시 원본을 조회하기 전까지 캐시될 수 있는 구간으로 정의했다. DNS 운영에서 권위 있는 영역 데이터, 캐시된 데이터, 갱신 상태, 만료 동작은 서로 다른 역할을 차지한다. 레코드의 문자를 X.500으로 복사하는 것이 그 역할들을 자동으로 재현하지는 않았다.

조사자에게 이것은 필요한 사슬을 만든다. 어느 DNS 출처가 레코드를 제공했는가? 어느 영역 버전이나 전송이 그것을 실어 왔는가? 전송은 완료되었는가? DSA는 언제 기록을 수락했는가? 디렉터리 항목은 나중에 갱신되었는가? 어느 조회가 그것을 돌려주었는가? TTL이라는 레이블이 붙은 필드 하나로는 그 질문들에 답할 수 없다.

이 구분은 복사된 레코드가 그것을 만들어낸 관측보다 오래 남을 때 특히 중요하다. 값은 여전히 숫자를 담고 있을 수 있지만, 그것을 현재 값으로 다루는 운영적 근거는 이미 만료되었을 수 있다. 문법은 그 권위의 유효 기간보다 오래 살아남을 수 있다.

전송 도구는 좁은 임무를 받았다

부록은 DNS 서버와 DSA 사이에서 양방향으로 정보를 옮길 수 있는 영역 전송 도구를 제안했다. 이 제안에는 하나의 정확한 보호 장치가 들어 있었다. DSA에 기록할 때 DNS 레코드가 아닌 속성은 그대로 두어야 한다는 것이었다.

그 한 문장이 관제 표면을 정의한다. 도구는 자신이 운반하는 레코드 계열을 갱신할 수 있었다. 같은 항목에 자리한다는 이유만으로 담당자 세부사항, 전화번호, 조직 기술, 연관 포인터, 그 밖의 인접 속성의 소유자가 되지는 않았다.

DSA에의 성공적인 접속이 완료된 전송을 증명하지 않았다. 완료된 전송이 모든 레코드가 검증을 통과했음을 증명하지 않았다. DNS 레코드 기록이 보호 속성이 보존되었음을 증명하려면 전후 상태가 관측되어야 했다. 이후의 조회가 사용자가 그 결과에 따라 행동했음을 증명하지 않았다.

따라서 유용한 근거는 계층화되어 있다. 원본 영역 상태, 요청된 전송, 수신된 집합, 수락된 기록, 보존된 비(非)DNS 상태, 포인터 상태, 조회 응답, 하류(下流) 행동. 이것들을 하나의 “동기화됨” 플래그로 합치면 RFC 1279가 보호하려던 정확한 경계가 가려진다.

단계적 실험은 아직 존재하지 않는 것에 대해 정직했다

RFC 1279는 실험에 필요한 기제들을 나열했다. 사용자 도구, 절차 라이브러리, 영역 전송 도구, 연결 패칭 도구, DNS 관리자, 메일박스 다운로더, 에뮬레이션 DNS 서버였다. 초기 단계는 영역 전송이 허용된 하나의 DSA에 DNS 공간의 상당 부분을 복사할 수 있었다. 이후 단계는 디렉터리 데이터를 분산하고 성능을 비교할 수 있었다. 최종 단계만이 DNS 계층의 일부를 DIT에서 마스터링했다.

이 목록은 계획이지 운영 영수증이 아니었다. 이 메모는 모든 구성 요소가 만들어졌다거나, 복사된 데이터가 신선하게 유지되었다거나, 역방향 포인터가 완성되었다거나, 사용자가 결과를 신뢰했다거나, DNS가 대체되었다고 보고하지 않았다. 실험(Experimental) 지위는 설계가 상세하더라도 주장을 좁혔다.

RFC 1309는 나중에 더 넓은 X.500 모델을 설명했다. 항목이 속성과 대상 클래스를 통해 대상을 나타내며, 지역 조직이 분산 디렉터리 안의 자신들만의 DSA에서 지역 정보를 마스터링할 수 있다는 것이었다. 그 배경은 RFC 1279의 포인터가 왜 중요한지 명확히 해 주지만, RFC 1279 파일럿을 완성된 글로벌 서비스로 바꾸지는 않는다.

보안 경계도 똑같이 명시적이었다. RFC 1279는 X.500 기능이 더 안전한 접근과 관리를 가능하게 할 수 있긴 하지만 보안 문제를 직접 다루지 않는다고 밝혔다. 가능성은 인증 근거가 아니었다. 포인터도 복사된 DNS 레코드도 그 뒤에 있는 사람, 조직, 운영자를 인증하지 않았다.

출처와 한계

RFC 1279는 도메인 표현, 별칭 거부, 방향성 연결, 비(非)중복 규칙, DNS 레코드 전송 경계, 단계적 실험을 제공한다.RFC 1274는 관련 도메인 대상 클래스와 연관 속성을 확인한다.RFC 1035는 DNS TTL과 영역 작업 맥락을 제공한다.RFC 1309는 일반적인 X.500 항목과 분산 지역 마스터링 맥락만을 제공한다.

이 문서들은 역사적 정의와 제안된 통제를 확립한다. 그러나 지명된 배포, 현재의 디렉터리 내용, 법적 소유, 인증된 신원, 완료된 전송, 신선한 값, 성공적인 조회, 보안 결과, 사용자 행동을 증명하지는 않는다.