요약

  • 1984년 버클리의 BIND 보고서는 분산 유닉스 환경을 위한 네임 서비스를 기술했습니다. 버클리가 DNS를 발명했거나 최초의 서버를 작성했다고 주장하지는 않았습니다.
  • 1987년까지 BIND는 4.3BSD와 함께 배포되는 소프트웨어로 문서화되었습니다. 2년 뒤 인터넷 가이드는 이를/etc/hosts기반 호스트명 조회를 대체하는 통합 방식으로 설명했습니다.
  • 변화는 운영적 성격이었습니다. 사양은 상호운용 가능한 동작을 기술했고, 소프트웨어 배포와 로컬에서 유지되는 존 데이터 덕분에 관리자들이 자신의 네트워크에서 이름을 응답하도록 만들 수 있었습니다.

설계에는 디스크 위의 주소와 호스트 위의 프로세스가 필요했다

네임 시스템은 종이 위에서는 우아해도 일상적인 관리를 바꾸지 못할 수 있습니다. 누군가는 서버를 설치하고, 데이터를 제공하고, 그 데이터를 최신 상태로 유지하며, 로컬 프로그램이 그 서버에 질문하도록 만들어야 합니다. 버클리가 떠오르던 도메인 이름 시스템에 기여한 것은 바로 이 작업을 유닉스 환경에 맞게 만든 것이었습니다.

1984년, Douglas Terry, Mark Painter, David Riggle, Songnian Zhou는 버클리 인터넷 네임 도메인 서버에 관한 버클리 기술 보고서를 발표했습니다. 그 초록은 분산 유닉스 시스템에서 자원의 이름을 정하는 표준 방식, 관련 정보의 저장과 조회, 행정 주체를 반영하는 도메인으로 위계적 네임스페이스를 나누는 방법을 설명합니다. 이는 소프트웨어와 운영 모델이지 DNS를 발명했다는 주장이 아닙니다. Paul Mockapetris의 이전 서버인 Jeeves는 이미 USC-ISI와 SRI-NIC에서 실행되고 있었으며, ISC의 후대 역사 기록은 이를 버클리 프로젝트와 구분하고 있습니다.

BIND의 실용적 질문은 데이터가 여러 행정 도메인에 걸쳐 존재하는 네이밍 시스템에 유닉스 호스트가 어떻게 참여할 수 있는지였습니다. 답은 서버와 로컬 파일, 그리고 호스트의 기존 리졸버 경로를 결합한 것이었습니다. 도메인 운영자는 트리의 일부에 대한 권위적 레코드를 유지할 수 있고, 리졸버는 위임 체인을 따라 서버에 질문하고 응답을 캐시할 수 있었습니다. 네임스페이스가 분산된 이유는 책임과 데이터가 분산되어 있었기 때문이지, 각 사용자가 모든 기계의 위치를 알아야 했기 때문이 아니었습니다.

작동하는 네트워크가 문서를 바꿨다

연대기가 중요합니다. 최초의 DNS 기술은 1983년 RFC 882와 RFC 883으로 등장했습니다. 1986년 1월 무렵에는 Paul Mockapetris의 RFC 973이 이미 당시 운영 중이던 시스템의 변경 사항, 운영 지침, 관찰된 문제점과 미비점을 기록하고 있었습니다. 이 문서는 이미 광범위하게 사용 중인 변경 사항은 사양의 일부로 다루어야 한다고 말합니다. 이는 완성된 표준이 누군가의 실사용보다 먼저 도착한 순서가 아니라, 구현과 운영자의 피드백이 프로토콜 문서가 되어가는 기록입니다.

수정된 사양인RFC 1034와RFC 1035는 1987년 11월에 등장했습니다. 이들은 DNS 개념과 구현 세부 사항을 기술했습니다. 그 중요성은 실재했습니다. 독립적으로 관리되는 서버들에는 이름, 레코드, 질의, 캐싱, 위임에 대한 공통 규칙이 필요했습니다. 그러나 RFC는 관리자가 설치할 수 있는 패키지가 아니었습니다. 그 역할은 소프트웨어와 운영 문서가 맡았습니다.

버클리의 1984년 보고서는 BIND를 분산 유닉스 자원을 위한 서비스로 다뤘습니다. ISC의 회고적BIND 역사문서는 초기 버클리 팀을 밝히고, Computer Systems Research Group이 버전 4.8.3까지 BIND를 유지보수했다고 기록합니다. 회고록은 프로젝트의 DARPA 지원과 후기 기여자들도 기록합니다. 이 사실들은 개발 계보를 보여주지만, 각 릴리스가 얼마나 많은 시스템에서 사용되었는지는 측정하지 않습니다.

BSD 릴리스가 서비스를 손이 닿는 곳에 두었다

동시대의 운영적 단서는 1987년 11월 도메인 운영 가이드인RFC 1033에 나타납니다. 그 부록은 명시적으로 4.3 BSD UNIX와 함께 "배포되는" BIND를 다룹니다.named.boot를 포함한 구현별 부트 및 캐시 파일을 설명하고 존 데이터의 예를 제공합니다. 이 가이드는 모든 BSD 설치가 네임 서버를 실행했다고 말하지는 않습니다. 다만 운영자가 익숙한 유닉스 배포판의 일부로 BIND를 받아 설정 지침을 찾을 수 있었다는 점을 보여줍니다.

그 패키징은 시스템을 시도하는 비용을 바꿨습니다. 관리자는 도메인을 정의하기 전에 DNS 서버를 직접 작성할 필요가 없었습니다. 서버는 부트 파일에서 시작해 존 데이터를 적재하고, 로컬 질의에 응답하고, 이름이 자신의 권한 밖에 있으면 다른 서버에 문의할 수 있었습니다. 도메인 소유자에게는 여전히 할 일이 있었습니다. 레코드는 정확해야 했고, 위임은 상위 도메인과 일치해야 했으며, 갱신은 신중하게 다뤄야 했습니다. BIND는 자동 정확성이 아니라 작동하는 도구를 제공한 것입니다.

가장 구체적인 당대 기록은 2년 뒤 나옵니다.RFC 1118에서 Ed Krol은 BIND가 4.3BSD와 통합되어 호스트명, 주소, 메일 에이전트 등 다른 호스트 정보를 조회하고 저장하는 데 사용된다고 설명했습니다. 그는 이것이/etc/hosts기반 조회를 대체했다고 말했습니다. 일리노이대학교 어배너-섐페인의 예는 규모의 변화를 이해하기 쉽게 만듭니다. SRI가 배포하는 호스트 표에는 몇 개 기계만 등장했지만, 대학 도메인의 대부분의 이름은 로컬 BIND 테이블에 보관되어 있었습니다. 이들은 BIND나 다른 DNS 리졸버를 실행하는 다른 호스트에서도 여전히 접근 가능했습니다.

이는 하나의 데이터베이스와 무협조 사이의 선택이 아니었습니다. SRI는 여전히 호스트 테이블을 배포했고, DNS는 기관이 더 큰 로컬 네임스페이스를 유지하고 공유된 질의 규칙을 통해 그것을 노출할 수 있는 방법을 더한 것입니다. RFC 1118은 또한 BIND가 UUCP를 통해 접근되는 기계를 포함해 IP로 직접 도달할 수 없는 내부 호스트의 메일 라우팅 정보를 공개할 수 있다고 언급합니다. 호스트의 물리적 또는 네트워크 위치가 바뀌어도 이름은 서비스 참조를 유지할 수 있었습니다.

무엇이 로컬이 되었고 무엇이 공유되었는가

운영 경계는 '분산'이라는 단어가 때때로 암시하는 것보다 정확했습니다. 버클리와 이후 유지보수자들은 소프트웨어를 배포했습니다. 프로토콜 문서는 공통 동작을 기술했습니다. 도메인의 관리자들은 트리에서 자신의 부분에 대한 레코드를 통제했습니다. 질의는 리졸버와 서버가 수행했습니다. 어떤 구성요소도 다른 구성요소를 대체하지 않았습니다. 로컬 레코드가 낡으면 서버는 일관되게 응답하면서도 틀릴 수 있었고, 위임 데이터가 불일치하면 BIND 자체가 작동 중이더라도 이름이 실패할 수 있었습니다.

여기서 Lu Heng이 나중에 강조한 '작동하는 코드'의 관점은 BIND 작성자의 의도에 대한 주장이 아니라 유용한 질문을 제공합니다. 운영자가 실제로 무엇을 받고 무엇을 했는가? 근거는 설계 보고서부터, 운영 경험으로 형성된 진화하는 시스템을 거쳐, 4.3BSD와 함께 패키지되어 로컬 이름을 유지하는 데 쓰인 소프트웨어에 이르는 흐름을 보여줍니다. 출판이 중요했지만 출판만으로 대학의 존을 채우거나 사용자의 질의에 응답할 수는 없었습니다.

기록에는 한계도 있습니다. RFC 1033은 4.3BSD와의 배포를 확립하고, RFC 1118은 통합과 한 대학의 사례를 문서화합니다. 이들은 보편적인 설치, DNS 채택의 단일 원인, 모든 평면적 호스트 파일의 소멸을 확립하지 않습니다. 역사적으로 방어 가능한 지점은 더 작고 더 유용합니다. BIND는 DNS를 프로토콜 계열에서 관리자가 운영할 수 있는 평범한 유닉스 서비스로 바꾸는 데 도움을 주었다는 것입니다. 그 경로는 이름에 대한 권한을 실제로 더 세분화했는데, 각 도메인의 운영자가 자신의 부분을 유지하면서도 더 넓은 트리와 상호운용 가능했기 때문입니다.

출처