Domain Name System이란 이름과 IP 주소를 매핑하여주는 거대한 분산 네이밍 시스템이다. 인터넷에서 사용되는 IP(Internet Protocol), 그리고 IP의 상위에서 동작하는 넷스케이프 같은 응용들은 210.105.79.103 과 같이 표현되는 IP 주소만을 인식하게 되는데, 이러한 IP 주소는 기계입장에선 해석하기 수월하지만 기억하기가 어렵고, IP 주소만으로는 서비스 유형을 예측하기 힘들다는 단점이 있다. 인터넷의 도입 시절인 ARPANET 시절부터 IP Address를 이름으로 명명하여 사용하고자 하는 노력이 시도되었고, 많은 시행착오는 지금의 DNS 메커니즘으로 발전하였다.
ARPANET 시절에는 호스트의 수가 많지 않았기에 NIC(Network Information Center)으로부터 일정 주기마다 호스트 명단 파일(HOSTS.TXT)을 받아 /etc/hosts에 저장하여 사용하였다. 그러나 점차 인터넷의 규모와 호스트 수가 증가함에 따라 새로운 이름 명명 체제의 필요성이 대두되었고, 1983년 Paul Mockapetris가 RFC882, RFC883(현재는 RFC1034로 대체됨)에 새로운 명명 체제에 대한 구현을 공식 발표하며, 크게 네임스페이스의 계층 구조, 분산 데이터베이스, Email 라우팅 개선을 주안점으로 DNS가 탄생하였다.
ARPANET의 중앙 관리 체제에서는 하나의 파일로 모든 호스트들을 관리하였지만, DNS에서는 이것을 각 도메인 별로 트리화 하여 [그림 1]과 같은 형태로 관리한다.
[Image]
[그림 1] Namespace 예제
디렉토리 구조와 유사함을 알 수 있는데, Root domain(도트로 표시되는)은 Top level 도메인에 관한 정보를, Top level 도메인은 그 하위 도메인에 관한 정보를 유지/관리하는 구조를 취한다. 이러한 정보의 계층구조로 인하여 정보는 각 도메인의 네임서버(NS:Name Server)로 분산, 관리된다.
예로 YAHOO.COM 도메인은 COM 네임서버에 등록되어 있고, WWW.YAHOO.COM은 YAHOO.COM 네임서버에 등록, 관리된다. 따라서 AV.YAHOO.COM을 등록하기 위해서는 YAHOO.COM 도메인을 관리하는 네임서버의 관련 레코드만을 수정함으로써 가능하다. 이러한 위임구조는 증가하는 인터넷 호스트에 대한 관리를 효율적으로 가능하게 해준다.
[Image]
[그림 2] 도메인 'WWW.YAHOO.COM'에 대한 IP Resolving
통신을 위한 TCP/IP 패킷엔 도메인명을 위한 공간이 없다. 따라서 도메인명에 대한 IP 변환작업(Resolving)을 선행하게 되는데, [그림 2]는 이러한 Resolving 과정을 보여준다.
'A-Z', 'a-z', '0-9', '-' 가 사용될 수 있다. 도메인명은 반드시 숫자나 문자로 시작하여야 하며, 전부 숫자여서는 안 된다. (초기 [RFC1035]에서는 도메인명이 반드시 문자로 시작하도록 제한하였지만, [RFC1123 p12]에서 완화되어 3com.com 같은 도메인 사용이 허락되었다.) 또한 하이픈이 앞/뒤에 사용될 수 없고, 도트로 분리되는 각 문자열(Each segment)은 최고 63 단어(octet)까지 사용할 수 있도록 구현되어 있으며(NIC에서는 12단어 이하로 사용하기를 권장), 대/소문자는 구분되지 않는다.
덧붙여, 도메인명은 등록기관(KRNIC, INTERNIC 등)에 따라, 조금씩 상이한 규칙이 적용됨을 유의하자. KRNIC은 숫자로 시작하는 도메인명을 허용하지 않는 반면 세그먼트를 63자까지 풀어주지만, INTERNIC에서는 숫자로 시작하는 도메인이 허용되고, 세그먼트가 22자로 제한한다.
참고로 도메인명은 통상적으로 Email에도 사용되므로 RFC822 규칙도 준수해야 할 필요가 있음을 알아야 한다. 하지만, 이는 충분히 자유로워 앞의 규칙을 포용하므로, 크게 신경쓸 필요는 없겠다.
(제작되는 소프트웨어들은 표준의 규격보다 확장되고 유연하게 구현되어 실제 숫자로만 된 도메인(예:411.com)도 존재한다. 하지만 표준에 위배되는 것은 모든 응용에서 통용되리라 기대할 수 없다는 말이기도 하다)