요약

  • RFC 897은 호스트의 도메인 스타일 이름과 그 이름을 변환하는 메커니즘을 분리하여, 응용 프로그램이 HOSTS.TXT를 버리기 전에 이름이 먼저 바뀔 수 있도록 했다.
  • RFC 921은 이후 마일스톤 점수표를 공개했다. 이름 변경은 일정대로 이루어졌지만 서버는 늦게 도착했고, 도메인 표, 새 도메인, 응용 프로그램 전환 및 호스트 표 폐지에는 여전히 작업이 필요했다.
  • 이 전환은 수년간 커뮤니티별·응용 프로그램별로 남았다. 가동 중인 서버, 적재된 데이터베이스, 전환된 메일러, 폐지된 폴백은 각각 별개의 증명이었다.

교체되는 시스템은 단순히 한 장비에 있는 텍스트 파일이 아니었다.RFC 810은 네트워크 정보 센터에서 관리되는 기계 판독 가능 호스트 표를 규정했다. 수신하는 각 사이트는 여전히 그 표를 받아 자체 소프트웨어가 사용할 수 있는 로컬 형식으로 바꿔야 했다.RFC 811은 개별 질문에 답하거나 전체 표를 반환할 수 있는 호스트네임 서버를 추가했다. 중앙 출판, 성공적 전송, 로컬 설치, 응용 프로그램 사용은 이미 서로 다른 네 가지 사건이었다.

제안된 도메인 시스템은 답의 근원과 질문의 형태를 모두 바꿨다.RFC 881은 배포의 딜레마를 설명했다. 소수의 조직이 점 표기 이름을 내보내기 시작하면 그 이름들이 메일과 다른 트래픽에 어디서나 나타날 것이다. 그러나 모든 프로그램이 준비될 때까지 기다리는 것은 시기적절한 마이그레이션을 비현실적으로 만들었다. 그 브리지는 의도적으로 불완전했다. 일반 표 옆에 도메인 스타일 표를 게시하고, 나중에 일반 표를 교체하고, 최종적으로는 호스트 표 라이브러리 호출을 리졸버로 대체하여 대부분의 응용 프로그램이 주소를 어떻게 찾았는지 알 필요가 없도록 하는 것이었다.

RFC 882와RFC 883은 분산 서비스(이름, 유형화된 데이터, 서버, 존, 레퍼럴, 리졸버, 캐시)를 기술했다. 그러나 프로토콜 설계만으로는 특정 메일러가 여전히 파일을 훑는지 알 수 없었다. 그 간극에서 구현 일정이 역사적으로 중요해졌다.

진실의 근원이 바뀌기 전에 먼저 바뀐 라벨

1984년 2월에 발행된RFC 897은 쉽게 혼동될 수 있는 두 가지 변경을 식별했다. 하나는USC-ISIF같은 평면 문자열을USC-ISIF.ARPA같은 계층적 형태로 바꾸는 것이었다. 다른 하나는 하나의 완전하고 중앙 관리되는 표의 로컬 사본에 대한 주소 조회를, 데이터베이스의 일부를 보관하는 분산 서버에 대한 동적 접근으로 바꾸는 것이었다.

4단계 계획은 이 두 변경의 독립성을 드러냈다. 먼저 기존 이름에.ARPA를 붙인다. 그다음 소수의 도메인을 도입한다. 셋째로 중앙 표 조회를 네임 서버로 교체한다. 넷째로 다수의 도메인을 허용한다. 따라서 점 표기 이름은 리졸버가 호출되었다는 증거가 아니었다. 전환 기간 동안 HOSTS.TXT 자체가 점 표기 이름을 담을 수 있었다.

초기 고정 접미사는 모호성을 줄였지만 이름 변경 비용을 흡수하지는 못했다. RFC 897은 구 이름을 일시적으로 별명으로 남겨두는 것을 허용했다. 이는 이름이 바뀐 호스트로 들어오는 조회에는 도움이 될 수 있었다. 그러나 원격 사용자가 저장한 주소를 다시 쓰거나, 모든From,To,Cc필드를 고치거나, 다른 곳에 보관된 메일링 리스트를 갱신할 수는 없었다. 식별자가 한 번 복사되면 마이그레이션 상태의 일부는 이름이 바뀐 호스트의 통제 밖에 놓였다.

분산 데이터베이스는 사용자가 이미 기대하던 속성도 보존해야 했다. 주소가 주어지면 주 이름을 되찾을 수 있어야 한다는 것이다. 별명은 자격 증명이 아니었고, 역방향 매핑은 인증이 아니었다. 그것은 이제 여러 관리자가 유지하는 데이터에 걸친 일관성 의무였다.

정책에는 날짜와 커뮤니티, 예외가 있었다

RFC 897은 이 변경에 달력 좌표를 부여했다. 도메인 스타일 이름은 1984년 3월 14일에 주 이름이 되기로 했다. 구 스타일 이름은 5월 2일까지 사라지기로 했다. 일반 다층 도메인은 6월 6일에, 조직 이름은 7월 18일에 열리고, ARPA 연구 커뮤니티를 위한 전체 호스트 표는 9월 5일에 불필요해지기로 했다. DDN 계획은 10월 3일까지 제출되어야 했다.

이 날짜들은 모두에게 동일한 기술적 의무를 부과하지 않았다. ARPA 연구 커뮤니티는 전체 전환을 수행하기로 했다. DDN 운영 커뮤니티는 동일한 일정에 따라 도메인 스타일 이름을 채택했지만 같은 시점에 표 조회를 포기할 필요는 없었다. DDN 프로그램 사무소가 나중에 방침을 정하고, NIC는 그 커뮤니티를 위해 중앙 표를 계속 제공하기로 했다.

이 구분은 중요하다. 두 호스트가 모두 새 스타일 이름을 표시하면서 하나만 분산 조회를 사용할 수 있었다. 공유 네임스페이스가 공유 구현 상태를 의미하지 않았고, 정책 날짜가 완료된 전환을 증명하지 않았다.

RFC 921은 놓친 날짜를 증거로 바꾸었다

10월이 되자 일정은 감사 기록이 되었다.RFC 920은 드디어 도메인 설립 요건을 공개하고 최상위 계획을 수정했다. 그것은 RFC 897이 예상한 2월이 아니라 10월에 도착했다.

RFC 921은 새 일정표를 발표하는 것보다 더 드문 일을 했다. 기존 일정표를 덧붙여 결과를 표시한 것이다. 초기 도메인 스타일 표와 3월의 주 이름 변경은 일정대로 완료되었다. 여러 ARPA 도메인 서버가 가동 중이었지만 4월이 아니라 9월에야 그렇게 되었다. 최상위 도메인 표, 새 도메인, 다층 및 조직 도메인, 호스트 표 폐지, DDN 계획은 아직 완료되지 않았다.

수정된 문서는 세 구현 단계를 분리했다. 기계장치는 서버와 리졸버의 존재를 의미했다. 데이터베이스는 관련 데이터가 설치되었음을 의미했다. 응용 프로그램 전환은 메일러, 텔넷, FTP 등의 프로그램이 실제로 새 절차를 사용함을 의미했다. 1984년 10월 기준 기계장치는 순조로웠고 데이터베이스에는 ARPA와 다른 최상위 도메인의 초기화가 있었지만, 사용자 프로그램을 바꾸는 작업은 거의 이루어지지 않았다.

새 날짜들은 1984년 12월부터 1985년 10월까지 이어졌다. 그것은 소급적 사실이 아니라 계획이었다. RFC 921의 가장 강한 기여는 완료 어휘였다. 완료됨, 지연됨, 미완료라는 표현을 명명된 계층에 붙이고, 단일한 백분율 안에 숨기지 않은 것이다.

공존은 마지막 한 구간을 응용 프로그램으로 옮겼다

별도의 DDN 경로는 빨리 닫히지 않았다.RFC 1031은 1987년 11월에 MILNET 전환을 공존하는 세 단계로 기술했다. 표 전용, 표와 DNS 혼용, DNS 전용이다. 같은 호스트의 응용 프로그램들이 서로 다른 시점에 건너갈 수 있었다. 텔넷과 FTP는 DNS를 사용하면서 메일은 표를 유지할 수도 있고, 순서가 반대일 수도 있었다.

RFC 1031은 당시 대부분의 호스트가 여전히 표 전용이었으며, 오래된 아키텍처나 수정 불가능한 소프트웨어는 영원히 전환하지 못할 수 있다고 인정했다. 공유 표가 끝난 후 그런 시스템은 양자 간, 커뮤니티 또는 로컬에서 유지되는 대체물이 필요했다. 폴백은 더 이상 무료 인프라가 아니었고, 명명된 소유자를 가진 새 의존성이 되었다.

RFC 1034는 이후 중앙 파일이 확장할 수 없는 이유를 요약하면서, 기존 호스트 표 호출과 유사한 응용 프로그램 대면 리졸버 함수를 유지했다. 인터페이스 수준의 호환성 덕분에 답의 근원이 바뀌면서도 모든 호출자를 한꺼번에 다시 쓸 필요가 없었다. 그러나 운영자가 호출 경로를 들여다보지 않는 한 구현 상태는 덜 가시적이 되었다.

긴 꼬리는 여전히 중요했다.RFC 1401은 1992년 서신을 재수록했는데, 그중 IAB는 MILNET 전환이 여전히 불완전하며 표 기반 매핑과 DNS 기반 매핑이 불일치하여 연결성 실패를 초래했다고 경고했다. 그 문서는 채택 인구조사가 아니라 옹호 서신이다. 그럼에도 1984년에 분할된 일정이 8년 뒤에도 제도적 여운을 가지고 있음을 보여준다.

출처와 한계

이 글은 RFC 810, 811, 881, 882, 883, 897, 920, 921, 1031, 1034, 1401을 사용한다. 이들은 명세, 정책 날짜, 명시적 마일스톤 감사, 후속 문서화된 관찰을 확립한다. 그러나 단일한 보편적 전환 날짜, 모든 사이트의 준수, 현재 제품 동작, 인증된 신원, 현재 연결성, 성공적인 응용 프로그램 작업을 증명하지는 않는다.