요약

  • RFC 1480은.US하에서 세 가지 등록 상황을 기술했다. 위임된 분기, IP 호스트에 대한 직접 A 레코드 항목, 그리고 IP가 아닌 호스트에 대한 MX 기반 직접 항목이 그것이다. 눈에 보이는 이름만으로는 그 뒤에 어떤 권한 기관이나 전송 방식이 있었는지 알 수 없었다.
  • 위임은 한 분기의 책임을 지정된 관리자에게 넘기고 계속되는 의무를 수반했다. 동등한 대우, 기술적 역량, 정확한 운영, 이중화된 서버, 커뮤니티 서비스, 합의된 이관 절차가 그것이다. 부모 데이터베이스에 놓인 레코드는 그 자체로 이 중 어떤 것도 수행하지 않았다.

같은 접미사가 서로 다른 메커니즘을 감추고 있었다

1993년 6월에 발표된RFC 1480은 지리적·기능적 분기로 나뉘어 가던 미국 국가코드 도메인을 문서화했다. 학교는K12.<state>.US아래에, 도서관은LIB.<state>.US아래에, 기업은 지역명 아래에 나타날 수 있었다. 오른쪽 끝에서 보면 이 이름들은 하나의 질서 있는 문법을 공유했다.

이 문법은 성장하는 네임스페이스를 검색 가능하고 행정적으로 분할 가능하게 만들었기 때문에 유용했다. 동시에 동일한 점(dot)들 뒤에 서로 다른 여러 메커니즘을 숨길 수도 있었다. 그래서 RFC 1480은 등록 섹션을 열며 두 가지 방식을 명시하고, 그중 하나를 다시 둘로 나누었다.

한 분기는 네임 서버를 운영하는 조직에 위임될 수 있었다. 또는 정보가 주.US데이터베이스에 직접 입력될 수도 있었다. 직접 입력은 주소를 가진 IP 호스트에 속할 수도 있고, 포워더(전달자)를 통해 전자 메일로 접근되는 IP가 아닌 호스트에 속할 수도 있었다.

이는 세 가지 상태를 만들어 낸다. 하나의 성숙도 사다리가 아니다. 직접 등록은 불완전한 위임이 아니었다. 메일이 전달되는 이름은 결함 있는 IP 호스트가 아니었다. 각 방식은 서로 다른 운영상 필요에 답했고, 책임을 서로 다른 위치에 두었다.

직접 항목은 권한을 부모에게 남겨 두었다

IP 호스트의 경우 직접 사례는 기술하기에 충분히 단순했다. 그 주소가 DNS 데이터베이스의 A 레코드에 대응했다. 부모 관리자가 신청을 접수하고 자신이 운영하는 주 데이터에 레코드를 놓았다.

이름은 해석될 수 있었다. 그러나 그것이 등록자에게 자식 영역에 대한 통제권을 준 것은 아니었다.RFC 1034는 통제를 별개의 행정 행위로 기술했다. 적절한 부모가 트리의 일부를 위임하는 데 동의해야 했다. 그 분할점이 존재하기 전까지, 부모는 레코드를 게시하는 원천으로 남았다.

RFC 1035는 와이어상의 증거도 똑같이 좁게 유지했다. A 레코드는 32비트 인터넷 주소를 운반한다. NS 레코드는 소유자 이름에서 시작되는 영역에 대해 권한을 가진 것으로 기대되는 호스트를 명명한다. 전자는 후자를 증명하지 않고도 호스트 주소를 보이게 할 수 있다. 긍정적인 A 응답은 영역 관리의 증명서가 아니다.

이 구분은 운영상 중요했다. 직접 항목에 대한 수정은 부모 데이터베이스를 유지 관리하는 관리자를 통해서 이루어졌다. 위임된 관리자는 위임의 의무를 조건으로 자신의 영역 내에서 변경을 할 수 있었다. 동일한 접미사가 동일한 변경 권한을 의미하지는 않았다.

메일 주소는 호스트가 넘지 않은 경계를 넘을 수 있었다

RFC 1480은 IP가 아닌 호스트, 특히 UUCP 세계의 시스템도 인정했다. 일부는 인터넷에 연결된 포워더와 직접 통신했고, 다른 일부는 한 대 이상의 중계 기계를 거쳐 도달했다. 이들의 사용자는 여전히 인터넷 방식의 이름을 받을 수 있었다.

DNS 레코드는 명명된 기계가 IP 주소를 획득했다고 주장하지 않았다. 대신 교환기(exchange) 역할을 수행하기로 한 인터넷 호스트로 메일을 보냈다.RFC 1035가 바로 그 역할로 MX 레코드를 정의했고,RFC 974는 발신자가 메일 익스체인저를 어떻게 선택하는지 설명했다.

RFC 1480은 균일한 주소가 통신 상대가 밑에 깔린 네트워크 경계를 알게 되는 일을 피하게 해 준다고 말했다. 그럼에도 경계는 인터페이스 뒤에서 활성 상태로 남았다. IP가 아닌 호스트는 포워더와의 행정적 합의와 메일 중계를 위한 기술적 절차가 필요했다. 포워더의 라우팅 테이블에는 해당 호스트를 위한 규칙이 필요했다. 경로에 다른 UUCP 시스템이 있었다면 그 시스템도 메시지를 중계하는 방법을 알아야 했다.

따라서 DNS 조회는 메일 경로가 광고되고 있음을 증명할 수 있었다. 그러나 포워더가 동의를 유지하고 있는지, 각각의 사설 중계 규칙이 최신인지, 전화 접속 경로가 성공했는지, 수신자가 메시지를 받았는지는 증명할 수 없었다. 이름은 주소 문법을 통일했을 뿐, 배달에 필요한 모든 사건을 통일한 것은 아니었다.

위임은 단순한 NS 레이블이 아니라 관리자를 수반했다

RFC 1480의 위임 예에는K12.TX.US,berkeley.ca.us,LIB.MN.US가 포함되었다. 그 목적은 행정적 규모였다. 하나의 레지스트라가.US로 끝나는 모든 이름을 무기한 배정할 수 없었기에, 작업과 권한의 일부를 밖으로 옮겨야 했다.

그러나 이 문서는 위임을 서버 이름 두 개를 넣는 것에 지나지 않는다고 기술하지 않았다. 공평하고, 정직하고, 유능한 일을 할 수 있는 지정된 관리자를 요구했다. 권한은 지역 도메인과 글로벌 인터넷 커뮤니티를 위한 수탁(trusteeship)으로 규정되었으며, 책임과 서비스가 소유권 주장에 우선했다.

관리자는 요청에 동일한 규칙을 적용하고, 관련 네트워크 제공업체의 고객을 우대하지 않으며, 특정 메일 시스템, 프로토콜 또는 제품에 등록을 묶지 않아야 했다. 실질적으로 이해관계가 있는 당사자들이 그 관리자가 적절하다고 인정해야 했다. 상위 관리자는 일반적으로 경쟁 당사자들의 합의를 기다리면서, 개입은 중대한 방치의 경우로 한정했다.

기술적 의무는 관찰 가능했다. 관리자는 시의적절하게 응답하고, 정확한 데이터를 유지하고, 견고하게 운영해야 했다. 프라이머리 서버와 세컨더리 서버는 인터넷 연결이 필요했고, 상태와 데이터베이스 정확성에 대해 점검 가능해야 했다. 지역 재난이 서비스 전체를 지우지 않도록 서로 다른 물리적 위치가 권장되었다.

NS 응답만으로는 이 사회적·운영적 계약이 충족되었는지 보여 줄 수 없다. NS는 기대되는 권한을 명명할 뿐이다. 역량, 동등한 대우, 서버 독립성, 커뮤니티의 수용에는 다른 기록이 필요하다.

이관은 의무의 관리자를 바꿨다

이 문서는 또한 위임과 그 이후의 이관을 분리했다. 지정 관리자 수탁권을 옮기기 위해서는 이전 조직과 새 조직 양쪽의 통신이 필요했으며, 상위 관리자에게 변경이 상호 합의된 것이고 후계자가 책임을 이해하고 있음을 확신시켜야 했다. 영향을 받는 당사자의 의견도 유용했다.

이것은 사적 거래만으로 자동 완성되는 재산 매각이 아니었다. 책임 있는 기관을 조용히 바꾸는 서버 교체도 아니었다. 상위 기록, 이전 관리자의 동의, 새 관리자의 수락, 이해관계자의 우려, 실제 서버 운영은 이 사건의 서로 다른 부분에 속했다.

RFC 1591은 이후 이 일반 원칙을 더 넓게 밝혔다. 국가 도메인 관리자는 공공 서비스를 수행하며, 지정된 관리자는 국가와 글로벌 인터넷 커뮤니티 양쪽을 위한 수탁자라는 것이다. 이후의 이 문헌은 제도적 논리를 확인하는 데 도움을 준다. 그러나 RFC 1480에서 상정된 모든 분기가 위임되었거나, 모든 지정 관리자가 기준을 충족했다는 것을 증명하지는 않는다.

그 계층 구조는 1993년의 운영 제안이었다

RFC 1480은 6개월 전에 같은 도메인을 기술했던RFC 1386을 대체했다. 그 빠른 개정은 성장기에 정책 문서가 유지 보수되고 있었다는 증거다. 배포 상황의 조사(census)가 아니다.

이 RFC는 누구에게나 가장 짧거나 가장 명백한 이름을 보장하는 것보다 관리 가능한 세분화를 우선했다. 정치적 지리, 학교 학년, 도서관, 일반 단체가 분기가 된 것은 작업을 그룹화하면 하나의 데이터베이스 관리자에 대한 부담이 줄어들기 때문이었다. 이 설계는 그 시점에 네이밍이 어떻게 확장될 수 있는지에 대한 견해를 기록했다.

RFC Editor 정보 기록은 여전히 이 메모를 Informational로 분류한다. 보안 섹션은 보안 문제가 논의되지 않았다고 밝혔다. 이중화된 서버와 수탁자 의무는 운영 규율을 개선했지만, 그것은 인증, 권한 부여 또는 보안 증명이 아니었다.

훨씬 나중에 등록된검증된 정오표는 부록 I의 BNF에 빠진 선택(alternation) 기호를 추가한다. 이 수정은 기록된 문법을 고친다. 어떤 등록, 위임 또는 메일 경로를 소급하여 증명하지는 않는다.

유용한 감사는 이름이 어떤 종류의 사실인지 묻는 데서 시작한다

지속되는 교훈은 계층적 이름이 기만적이었다는 것이 아니다. 그 추상화가 바로 성과였다. 하나의 안정적인 문법이 매우 상이한 네트워크와 행정적 방식을 함께 사용 가능하게 만들 수 있었다.

그 사용성의 대가는 관찰자가 이름을 그 뒤에 있는 시스템에 대한 완전한 진술로 취급할 때 나타난다. 이름은 부모 관리자가 A 레코드를 입력했기 때문에 존재할 수 있다. 부모가 입력한 MX 레코드의 익스체인저가 다른 네트워크 너머로 이어지기 때문에 존재할 수도 있다. 다른 관리자가 운영하는 위임된 영역 안에 있을 수도 있다. 점들은 어느 경우가 적용되는지 말해 주지 않는다.

따라서 증거 대장에는 소유자 이름, 리소스 레코드 유형, 레코드를 게시한 영역, 위임 분할점, 지정 관리자, 서버 세트, 관찰 시점, 의도된 서비스를 각각 별도로 기록해야 한다. 메일의 경우 포워더의 동의, 사설 중계 상태, 시도 및 수신도 필요하다. 거버넌스의 경우 관리자 선정과 이관 기록이 필요하다. 그래야만 눈에 보이는 이름을 누군가가 끌어내려는 더 좁은 결론과 연결할 수 있다.

출처