DNS 개요

DNS 등장 배경

1960년대 말 등장한 미국 ARPANET이 인터넷의 기원이다. ARPAnet은 미국의 주요 연구기관을 연결한 광역 컴퓨터망으로써 미국 국방부의 ARPA(Advanced Research Project Agency)가 투자하여 개발하였다. TCP/IP 프로토콜은 1980년대 초에 이르러 개발되었다. IP는 'Inetnet Protocol'의 약자로서 산재한 컴퓨터 네트워크 간에 상호 연동을 하기 위한 프로토콜이다. (※ TCP/IP는 하나의 통합 프로토콜 스택으로 개발되었으나 나중에 TCP와 IP로 분리되었다. 아직도 IP 프로토콜 군을 TCP/IP라 부르고 있는 것은 초기의 명칭에 연유한다.) TCP/IP 프로토콜은 빠른 속도로 ARPANET에서 컴퓨터 네트워킹의 표준 프로토콜이 되었다. 이 당시만 해도 DNS는 존재하지 않았다. 버클리 대학의 BSD Unix에 TCP/IP 프로토콜이 탑재되면서 ARPANET에 연결된 호스트 수가 급격히 증가하기 시작했다. 당시 BSD Unix는 거의 무료로 대학에 배포되고 있었다. ARPANET에 연결된 호스트들은 기관 내부의 LAN에 연결되었으며 이 LAN에는 상당한 수의 호스트가 설치되었다. 1974년 기준 ARPANET은 50Kbps의 X.25 백본 네트워크로 총 23개의 호스트만이 존재하고 있었다. ARPANET에 연결된 호스트는 1981년에는 213개, 1983년에는 562개, 1984년에는 1024개, 1985년에는 1961개, 1986년 2308개, 1987년 28174개로 기하급수적인 증가세를 보였다. 이렇듯 TCP/IP를 기반으로 형성된 지역 및 광역 네트워크를 인터넷(Internet)이라 부르게 되었다. TCP/IP 표준 프로토콜의 등장과 BSD Unix의 TCP/IP 지원으로 인한 호스트 증가는 새로운 문제를 낳게 되었다. 그것은 바로 기하급수적으로 증가하는 호스트의 네임을 어떻게 구성, 관리할 것인가의 문제였다. 초기 ARPANET 환경에서는 각 호스트의 주소를 모두 외울 수 있었다. 호스트 수가 증가함에 따라 니모닉(mnemonic)을 호스트별로 부여하여 쉽게 기억할 수 있게 하였다. 니모닉 네임(mnemonic name)과 네트워크 주소의 매핑 테이블이 사용되었다. 호스트마다 설정하는 호스트 네임(host name)은 여기서부터 유래하였다. 1981년 ARPANET의 호스트들은 213개에 달하고 있었다. 이 시기에 각 호스트들은 HOSTS.TXT 파일에 ARPANET의 모든 호스트 네임과 네트워크 주소 테이블 정보를 갖고 있었다. 이 HOSTS.TXT 파일은 각 호스트에서 지정된 SRI NIC의 FTP 서버(SRI-NIC)에서 주기적으로 다운받아 업데이트를 하는 방식으로 관리되었다. Unix 계열 호스트에서 볼 수 있는 /etc/hosts 파일은 이 HOSTS.TXT에서 연유한 것이다. (RFC 952, "DOD INTERNET HOST TABLE SPECIFICATION") 호스트 수가 급격히 증가하면서 HOSTS.TXT 파일로 모든 호스트 정보를 관리하는 것은 점차 불가능하게 되었다.

	DNS의 역할
	HOSTS.TXT 기반 체계의 가장 큰 문제점은 확장성이 부족하다는 점이었다. HOSTS.TXT 파일을 중심으로 한 관리체계는 ARPANET NIC(Network Information Center)에 의한 일관성 있는 관리가 가능했다. 그러나 호스트 수가 급증하면서 HOSTS.TXT의 다운로드 트래픽과 시스템 부하로 인한 HOSTS.TXT 업그레이드 절차에 문제가 발생하기 시작했다. HOSTS.TXT 파일에 대한 로컬 호스트 내에서의 수정과 정보 변경에 의해 네임의 일관성 유지가 힘들었다. 급증한 호스트들 가운데 IP 주소를 변경하거나 새로운 호스트가 발생하여 모든 호스트의 HOSTS.TXT 정보를 동일하게 유지하는 것이 불가능하게 되었다. DNS(Domain Name System)은 위와 같은 HOSTS.TXT 체계의 문제점을 극복하는 새로운 네임체계이다. 1984년 USC Information Sciences Institute의 Paul Mockapetris에 의해 DNS(Domain Name System)가 제시되었다. (RFC882 & RFC 883, 이후에 이 2개의 RFC는 각각 RFC1034 & RFC1035로 개정) DNS(Domain Name System)의 가장 본질적인 특징은 ‘분산구조의 데이터베이스(distributed database)’이라는 점이다.

	DNS 구성
	DNS는 계층적 구조를 갖는 분산구조 데이터베이스이다. 분산구조 데이터베이스라는 것은 각 도메인 네임 영역(Zone)별로 독자적으로 관리 유지한다는 것을 의미한다. .KR 도메인 영역의 경우, 한국의 도메인 관리기관이 전적으로 관리한다. 또한 .KR 도메인을 등록받은 각 기업은 자신의 도메인 영역(Zone) 내의 정보를 독자적으로 관리한다. DNS는 다음의 3가지 핵심요소로 구성된다. 1. 도메인네임 공간(Domain Name Space)과 리소스레코드(Resource Record) 2. 네임서버(Name Servers) 3. 리졸버(Resolvers) [ 도메인네임 공간(Domain Name Space) ] 도메인네임은 트리(tree) 구조의 이름(naming)체계를 갖는다. 아래 그림은 루트 도메인 아래 트리 구조에 속한 .KR 도메인 구조를 예시하고 있다. (도메인체계의 설명은http://domain.nic.or.kr참조) 그림출처:http://domain.nic.or.kr [ 리소스레코드(Resource Record) ] 리소스레코드는 각 도메인 네임에 대하여 특정정보 속성(attribute)을 표현한다. 아래는 "www.nic.or.kr"이라는 도메인 네임의 IPv4 주소와 Text 정보를 지정한 리소스 레코드의 예시이다.
	Domain Name TTL CLASS TYPE RDLength Resource Data www.nic.or.kr. 1800 IN A 4 202.30.50.90 www.nic.or.kr. 1800 IN TXT 17 "KRNIC WEB SERVER"
	도메인네임은 유일한 값을 갖는 키워드 역할을 하며, 리소스레코드는 이 키워드에 매핑된 정보를 유형별로 표현하는 역할을 한다. [ 네임서버(Name Servers) ] 네임서버는 도메인 트리구조 정보와 리소스레코드 정보를 보유하고 있는 프로그램을 지칭한다. 흔히 알고 있는 DNS 서버 또는 네임서버를 지칭한다. [ 리졸버(Resolvers) ] 클라이언트의 요청에 의해 네임서버로부터 정보를 검색, 조회하는 프로그램을 지칭한다. 이때 클라이언트란 TELNET, FTP와 같은 사용자 프로그램을 의미한다. 도메인네임 공간(Domain Name Space)과 리소스레코드(Resource Record)가 도메인 데이터베이스 구조체계를 의미한다면, 네임서버(Name Servers)와 리졸버(Resolver)는 이 데이터베이스 시스템 구현방식을 의미한다고 할 수 있다. [ 스터브 리졸버(Stub Resolvers) ] 단말 호스트의 경우, 리졸버(Resolver) 전체기능을 구현하는 것은 비경제적이다. 그래서 캐슁(caching) 기능이 있는 리졸버(Resolver) 서버를 두고, 단말 호스트는 단순한 DNS 질의요청만 수행하도록 구현한다. 이때, 단말 호스트에 구현된 단순화된 리졸버(Resolver) 루틴을 스터브 리졸버(Stub Resolver)라 한다. PC나 호스트에 기본적으로 내재된 리졸버(Resolver)는 스터브 리졸버(Resolver)의 기능을 수행한다. [ DNS 프로토콜 ] DNS 프로토콜은 네임서버(Nname Servers)와 리졸버(Resolver)간 DNS 질의응답을 위한 프로토콜이다. 리졸버(Resolver)와 클라이언트(Client, 사용자 프로그램)간에는 프로토콜이 필요하지 않다. DNS 프로토콜 규정은 RFC1034와 RFC1035를 참조. RFC1034, "DOMAIN NAMES - CONCEPTS AND FACILITIES" RFC1035, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"