요약

  • ARPANET과 DCNET의 합친 표에는 1981년에 이미 이름과 별칭이 400개 넘게 있었다. Mills는 모든 호스트가 모든 미래 호스트를 하나의 평면 목록에 보관하는 대신 이름 도메인을 제안했다.
  • 한 컴퓨터가 COMSAT와 INTELPOST의 메일 전달기를 함께 운영하면 Mills@HOST는 두 개의 다른 사서함일 수 있다. 기계의 인터넷 주소는 답장의 도메인을 정해 주지 못한다. 완전한 사서함 이름과 돌아오는 경로가 그 차이를 보존해야 했다.

우편 분류대 하나에 Mills@HOST라고 쓴 편지가 두 통 놓였다. 하나는 COMSAT, 하나는 INTELPOST로 가야 한다. 어느 쪽 소속인지 적힌 띠를 떼어 버리면 분류대가 아무리 빠르게 돌아도 정답은 나오지 않는다. D. L. Mills가 1981년 9월 RFC 799에서 다룬 상황이 바로 이렇다. ARPANET과 DCNET의 이름·주소 표에는 이미 이름과 별칭이 400개 넘게 실려 있었다. 목록을 여러 권으로 나누는 생각은 쉽다. 편지와 답장이 나뉜 목록 중 정확한 한 권을 계속 찾게 만드는 일이 어려웠다.

Mills의 이름 도메인은 ARPA, UCL, COMSAT 같은 기관에 대응할 수 있었다. 서로 겹칠 수 있고 모든 주소를 덮을 필요도 없었다. 글에서는 도메인 한 단계를 가정했지만, 표준 사서함 표기 <user>.<host>@<domain>은 오른쪽부터 세 부분으로 읽힌다. COMSAT 안에서는 Mills@COMSAT-DLM만으로 충분할 수 있다. 밖으로 나갈 때는 Mills.COMSAT-DLM@COMSAT라고 써야 어느 도메인의 이름표인지 드러난다. 도메인이 다르면 같은 로컬 별칭을 다시 써도 되었다. 끝에 붙은 도메인은 꾸밈이 아니라 분류 기준이었다.

각 도메인에는 하나 이상의 메일 전달 프로세스를 둔다. 전달기는 자기 도메인의 모든 호스트 이름과 다른 도메인마다 적어도 한 전달기의 이름을 기억한다. 보통 호스트는 전달기 이름을 기본으로 가지고, 자주 쓰는 상대를 더해도 된다. 한 호스트가 여러 도메인에 속하거나 인터넷 주소를 여럿 가지거나 여러 전달 프로세스를 돌리는 일도 허용됐다. Mills는 전달기를 복제하면 견고해질 수 있다고 적었지만 그에 따른 경로의 복잡함은 더 논의할 일로 남겼다. 로컬에서 이름을 고를 자유가 있었기에, 경계를 넘을 때는 어느 로컬 규칙을 쓰는지 더 분명해야 했다.

전달기가 있다고 모든 메일을 그곳에 들르도록 한 설계는 아니었다. Mills는 대부분의 메일이 발신 호스트에서 수신 호스트로 곧장 갈 것으로 봤다. 중간 보관은 두 호스트가 동시에 접속하지 못하거나, 발신자가 이름을 주소로 바꿀 자원이 부족하거나, 직접 연결에 규제·경제·보안상 제약이 있거나, 한쪽이 TCP이고 다른 쪽이 NCP인 경우에 필요했다. 단순 중계기는 메시지를 보관해 다시 보내면 됐지만, 전달기처럼 모든 도메인의 이름 표를 갖출 필요는 없었다. 우편 자루를 맡는 사람과 모든 주소록을 책임지는 사람은 다른 직책이다.

RFC는 두 경로를 나란히 놓는다. MRCP to:<@COMSAT,Mills@HOST>와 MRCP to:<@INTELPOST,Mills@HOST>는 서로 다른 사서함으로 갈 수 있다. 두 전달 프로세스가 같은 컴퓨터에서 돌아도 그렇다. 그 컴퓨터가 양쪽에서 모두 FORWARDER라는 이름을 쓴다면 MRCP to:<@FORWARDER,Mills@HOST>에서는 결정적 정보가 빠진다. 인터넷 주소로 기계를 확인해도 도메인은 돌아오지 않는다. 주소는 컴퓨터를 가리키지, 그 메시지에서 컴퓨터가 수행한 COMSAT 또는 INTELPOST 역할까지 말해 주지 않는다.

답장은 같은 함정에 걸린다. Mills가 검토한 당시 RFC 780 절차에서는 수신자가 직전 전달 호스트의 인터넷 주소로부터 발신 경로의 이름을 만들었다. 공유 전달기의 주소만 남으면 어느 도메인을 거쳤는지 복원할 수 없다. Mills는 발신 호스트가 수신 경로와 발신 경로를 함께 갱신해야 한다고 주장했다. 받은 수신 경로의 첫 항목을 돌아가는 경로의 맨 앞에 복사하는 것이다. 영수증에는 건물 번호뿐 아니라 접수 창구도 남겨야 한다.

오래된 메일 시스템은 짧은 이름을 계속 썼다. Mills는 중간중간 RFC 733 머리말을 뜯어고치는 일을 피하자고 했다. 내용 전체를 깊이 분석해야 하는 침습적 작업이기 때문이다. 새 시스템은 처음부터 완전한 이름을 쓸 수 있다. 기존 ARPANET 메일이라면 인터넷 메일 시스템에 처음 들어오는 곳에서 로컬 <anything>@<host>를 <anything>.<host>@ARPA로 고치고, 이미 도메인 이름으로 알려진 <anything>@<domain>은 그대로 둔다. 짧은 이름의 출신을 아직 알고 있는 곳이 바로 입구였다.

RFC 799는 토론을 청하며 끝난다. 훗날의 DNS 배포 보고서가 아니라 1981년의 제안이다. 하지만 하나의 컴퓨터가 두 도메인의 우편 창구가 된다는 예시는 한계를 선명히 드러낸다. 32비트 주소가 컴퓨터 하나를 정확히 가리켜도, 그 컴퓨터가 이 편지에서 맡은 사서함 역할은 여럿일 수 있다. 400개 넘는 이름이 평면 목록을 압박했고, 한 책상 위의 두 편지가 회신 경로를 시험했다.