요약

  • RFC 1101은 네트워크 이름, 번호, 중첩된 서브넷에 대한 DNS 매핑을 제안했다. 이 문서는 호스트 제로IN-ADDR.ARPA이름에 PTR 레코드를 두고, 서브넷 단계가 더 이어질 때는 A 레코드를 마스크 운반체로 사용했다.
  • 이 제안은 로컬에서 선택한 이름과 중앙에서 할당한 번호 기록을 분리했다. DNS 응답은 자신의 범위 안에서 하나의 결합을 기술할 수 있었다. 그러나 번호를 할당하거나, 이후의 이름 변경을 자동으로 따라가거나, 현재의 통제를 증명하거나, 네트워크의 어떤 결과를 확립하지는 않았다.

DNS가 물려받지 못했던 기능

P. Mockapetris의 1989년 4월 문서DNS Encoding of Network Names and Other Types는 좁은 공백에서 시작한다. DNS는 확장 가능했고 이미HOSTS.TXT의 많은 기능을 넘겨받았지만, 네트워크 이름과 번호 사이의 매핑은 그 밖에 남아 있었다. RFC 1101은 이 매핑에 대한 구체적 방법을 제안했고, 별도로 보다 일반적인 식별자-번호 색인에 대한 실험적 아이디어를 담았다.

상태 구분이 시사하는 바가 크다. 네트워크 이름 방법은 제안 표준(proposed standard)이었고, 광범위한 “Yellow Pages” 아이디어는 실험적(experimental)이었다. 이 RFC는 모든 번호가 하나의 보편적인 인간적 의미를 가질 수 있다고 말하지 않았다. 대신 관리자가 DNS의 정의된 영역 안에서 번호 옆에 선택한 레이블을 게시할 수 있는 방법을 제공했다. 진단 화면은 소유권, 통제권, 라우팅 또는 서비스를 확정했다는 주장 없이도 더 이해하기 쉬워질 수 있었다.

이름을 고를 권리는 이름 곁에 남았다

네트워크 이름은 행정적 질문을 드러냈다. 구문의 구식 형태는 평면적 공간으로, 중앙 할당 기관이 번호를 규제하듯 이름도 규제하는 구조와 양립했다. RFC 1101은 다수 의견이 오히려 로컬 통제를 선호했다고 보고한다. 이 문서는 확장된 호스트 이름 구문을 전제하고, 관리자가 자신이 통제하는 도메인 안에서 네트워크 이름을 만들 수 있게 했다.

대가는 복잡성이었다. 네트워크 이름은 호스트 이름만큼 복잡해지게 된다. 얻는 것은 레이블을 맥락이 알려진 곳에서 유지할 수 있다는 점이었다. 따라서ARPANET.ARPA.같은 역사적 예는 RFC 안에서의 네이밍 선택의 사례일 뿐, 자원의 영구적 정의도 아니고, 레코드가 우연히 가리킨 번호에 대한 부여도 아니다.

역방향에는 또 다른 장소가 필요했다. 로컬에서 선택한 레이블만으로는 독자가 IP 주소에서 어디서부터 시작해야 하는지 알 수 없다. RFC 1101은 기존의IN-ADDR.ARPA트리를 재사용해, 이미 위임된 주소 지향 공간이 역방향 기술을 담도록 했다. 이 유한한 결합을 게시하기 위해 두 번째 전역 이름공간을 발명할 필요는 없었다.

호스트 제로는 파일을 두는 위치지, 호스트가 아니었다

이 제안은 호스트 제로 주소에 해당하는 이름에 정보를 두었다. 일반 PTR 형식은 다음과 같다.

<reversed-host-zero-number>.IN-ADDR.ARPA. PTR <network-name>

네트워크 이름은 상호 PTR을 갖는다. 네트워크에 더 깊은 서브넷 단계가 있으면 호스트 제로 항목의 A 레코드가 서브넷 마스크를 담는다. RFC는 이 형태의 예로0.0.0.10.IN-ADDR.ARPA.와0.0.2.128.IN-ADDR.ARPA.를 든다. 이 문자열들은 역사적 예일 뿐, 현재의 관찰이 아니다.

호스트 제로가 사용 가능한 엔드포인트가 된 것은 아니다. 이 관례는 조직이 기술적 데이터를 붙이고 독자가 그 데이터의 존재를 확인할 수 있는 DNS 트리 안의 인식 가능한 장소를 만들었을 뿐이다. PTR은 번호 모양의 항목을 로컬에서 유지되는 이름과 연결한다. 라우터를 프로그래밍하거나 권리를 부여하거나 그 이름을 번호의 법적·운영적 신원으로 만들지는 않는다.

A 레코드 역시 마찬가지로 경계가 분명하다. 여기서 A 레코드는 호스트 이름이 주소를 가졌다는 일반적 증명이 아니라 마스크 운반체였다. RFC가 기술한 클래스 A/B/C 절차에서 독자는 IP 주소를 마스킹하고, 옥텟을 뒤집고, PTR을 질의하고, A 레코드 마스크를 사용해 다음 서브넷 단계를 위해 과정을 반복한다. A 레코드가 나타나지 않으면 중첩은 거기서 끝난다. 이는 역사적 조회 알고리즘이지, 현재 토폴로지나 도달 가능성의 증명서가 아니다.

유용한 세 방향은 여전히 세 가지 다른 서술이었다

RFC 1101은 조직 이름이 하나 이상의 호스트 제로 네트워크 항목을 가리키는 PTR 레코드를 갖는 것도 허용했다. 이름이 번호 모양 항목으로 이어질 수 있고, 그 항목이 선택된 이름으로 이어질 수 있으며, 조직 레이블이 여러 네트워크 기록으로 이어질 수 있다. 이 삼각형이 유용한 이유는 바로 화살표들이 분리되어 있기 때문이다.

공개된 조직-기록 결합은 그 게시에 대한 증거다. 네트워크 레이블은 네이밍 선택에 대한 증거다. 응답은 알고리즘과 특정 시점에 대한 증거다. 이 어느 것도, 혹은 새 증거 없이 겹겹이 쌓인 것도, 현재 소유권, 기업 관계, 물리적 보관, 승인, BGP 경로, 패킷 수신 또는 응용 성공을 증명하지 않는다. RFC 1101은 그 보다 큰 주장들을 레코드 밖에 두는 방식으로 레코드를 더 유용하게 만든다.

이 문서는 실용적 긴장도 인식했다. 중앙에서 유지되는 표는 더 일관성 있을 수 있고, 분산된 데이터는 더 시의성 있고 유지보수하기 쉬울 수 있다. 레코드 형식이 사실을 정확하게 유지하는 일을 없애는 것은 아니다. 그 작업에 범위를 부여하고, 독자가 어떤 서술이 어디서 왔는지 볼 수 있게 한다.

할당된 번호가 이후의 로컬 이름을 강제하지는 않았다

실험적 YP 섹션은 이 한계를 가장 직접적으로 진술한다. RFC 1101은 포트 니모닉과 포트 번호, 자율 시스템 식별자와 번호, 할당된 네트워크 이름과 IP 주소 같은 쌍을 위한 DNS 도메인 색인을 상상했다. 키는 “from”과 “to” 자료형을 모두 말해야 했다. 그 맥락 없는 번호는 충분하지 않았다.

할당된 네트워크에 대해서는 NIC가 자신의 할당 결정을 문서화하는 쌍을 이룬 YP 도메인을 유지할 수 있었다. 그러나 RFC는 그 기록이 조직이 이후 스스로 선택한 이름이 아니라할당된이름과 번호를 매핑한다고 말한다. 그 기록은 새 소유자에 의한 이름 변경을 자동으로 따라가지 않는다. 할당 이력과 로컬 네이밍은 의도적으로 구별되는 사실이었다.

중앙 목록은 그 할당자의 결정에 대한 강한 증거가 될 수 있다. 로컬 존은 로컬에서 유지되는 레이블에 대한 강한 증거가 될 수 있다. 그러나 어느 쪽도 현재 운영자, 서비스, 경로 또는 거래 결과로 가는 지름길이 되지는 않는다. 레코드는 자신의 경계 안의 현실을 기술할 뿐, 독자가 그것에 붙이려 할 수 있는 모든 현실을 만들어내지는 않는다.

RFC를 역사적 규모로 읽기

RFC 1101은 1989년 제안에 대한 증거다. 그 클래스 기반 절차, YP 도메인, 예시 조직은 현재 DNS 배포의 묘사가 아니다. 그 규율은 여전히 건전하다. 매핑을 검사 가능하게 만들고, 방향과 범위를 밝히며, 레코드가 한 번도 담지 않은 결정을 레코드에 지우지 않는 것이다.

인터넷은 부분적 사실을 보존하는 법을 배우면서 조사하기 쉬워졌다. 독자가 그 한계들을 보존할 때 인터넷은 계속 조사 가능하다. 레이블과 번호를 기술할 수 있는 레코드가 있고, 할당, 현재 통제, 실시간 라우팅, 결과는 여전히 각자의 증거를 요구한다.

출처와 증거 경계

이 역사적 분석은RFC 1101,RFC 1034및RFC 1035를 사용한다. 이들은 1989년 제안, 그 레코드 형식, 할당과 로컬 이름의 구분을 뒷받침한다. 그러나 현재의 DNS 데이터, 현재 통제권, 소유권, 신원, 라우팅, 도달 가능성, 권한 또는 서비스 성과를 확립하지는 않는다.