Summary

  • 1999년 6월 Best Current Practice로 나온 RFC 2606은 .test, .example, .invalid, .localhost에 서로 다른 역할을 부여했다. IANA가 예시용으로 보유한 example.com, example.net, example.org도 기록했다.
  • 실험실에서 지은 이름이 훗날 전 세계 DNS의 실제 이름이 될 수 있고, 설명서의 예시가 운영 코드로 옮겨질 수도 있다. 예약은 그때 일어날 주소 충돌을 막기 위한 경계였다.

기술 문서의 ‘예를 들어’는 생각보다 멀리 간다. 필자는 설명을 위해 주소 하나를 꾸민다. 독자는 그 줄을 복사한다. 가상의 주소라는 문장은 문서에 남고, 이름만 설정 파일에 실려 다른 컴퓨터로 이동한다. DNS에는 그 문자열이 농담으로 태어났다는 출생 신고가 없다. 누군가 같은 이름을 실제로 쓰게 되면 설명서는 뒤늦게 바뀌어도 프로그램은 계속 옛 주소를 찾아간다.

D. Eastlake와 A. Panitz가 쓴 1999년 6월 RFC 2606은 이 문제를 BCP 32, 즉 Best Current Practice로 다뤘다. 문서는 연구실이 DNS 코드를 시험하려고 당시 비어 있는 최상위 이름을 내부적으로 만든 경우를 제시한다. 훗날 그 이름이 전 세계 DNS에 등장하면 연구실의 로컬 영역이 실제 영역을 가릴 수 있다. 반대로 시험 프로그램이 닫힌 환경 밖으로 나가, 작성자가 가상이라고 여겼던 이름으로 요청을 보낼 수도 있다. 실험이라는 표지는 네트워크 경계에서 자동으로 따라오지 않는다.

RFC가 마련한 네 칸은 용도가 각각 다르다. .test는 DNS 관련 코드를 시험할 때 권장한다. .example은 설명과 문서용이다. .invalid는 누구나 무효임을 알아볼 수 있는 이름을 만드는 데 쓴다. .localhost는 호스트 구현에서 루프백 주소와 이어 온 로컬 관례를 보존한다. 네 이름을 그냥 ‘특수 도메인’이라고 묶으면 설계의 핵심이 빠진다. 시험 문제, 견본 주소, 오류 입력, 로컬 참조에는 다른 서랍이 필요했다.

RFC는 세 개의 2차 도메인도 적었다. IANA가 예시로 남겨 둔 example.com, example.net, example.org다. 설명서가 평범한 웹 주소 모양을 보여 주어야 할 때 유용하다. .com이나 .net을 쓰면서도 아직 만나지 못한 실제 등록자의 이름을 빌릴 필요가 없다. 가상의 상점에 진짜 세트장 출입증을 주는 셈이다.

층위는 구분해야 한다. shop.example은 끝의 .example 전체가 예시용으로 예약된 이름 공간에 들어간다. example.com은 일반적인 .com 아래의 특정 이름만 따로 보유한다. 두 방식은 서로 다른 문서 장면에 맞는다. 하나는 가상의 세계 전체를 보여 주고, 다른 하나는 일상적인 URL 형식을 안전하게 시연한다.

보안 관련 부분에서는 왜 이런 문서가 필요했는지 더 또렷해진다. 시험 소프트웨어가 실제 DNS로 나올 수 있다. ‘문서에서만’ 쓰던 예시가 실행 코드에 들어갈 수 있다. 무심코 지은 이름은 언젠가 소유자를 만나고 그 이름에 얽힌 권리 문제까지 만들 수 있다. RFC는 사고 통계를 제시한 것이 아니라 예방할 경로를 적었다. 해결책은 소박했다. 몇 이름을 고르고, 각 용도를 쓰고, 일반 할당에서 빼 두는 것. 인터넷은 허구를 안전하게 만들려고 장부부터 펼쳤다.

IANA의 현재 안내에 따르면 이 예시 도메인은 사전 협의 없이 문서에 사용할 수 있으며 등록이나 이전 대상이 아니다. IANA가 운영하는 안내용 웹페이지도 있지만, 애플리케이션이 그 HTTP 서비스의 가동에 의존하지 말라고 권한다. 예시 주소를 유지하는 일과 그 주소에서 서비스가 계속 돌아가는 일은 관리 목적부터 다르다.