DNS에 대한 간단한 이해
양일등 / FBISKR@orgio.net
안녕하세요! 파워 리눅스 유저 여러분! 무더운 여름의 문턱이 우리에게 좀더 다가온 7월이 됐습니다. 이번 호에서는 우리가 숨쉬는 공기처럼 없어서는 안돼는 것이지만 우리 눈에는 좀처럼 보기 힘든 DNS에 대해서 살펴보겠습니다.
1. DNS는 무엇인가?
우리가 인터넷을 사용하고 있으면 단 한시라도 사용하지 않는 인터넷 서비스가 바로 DNS입니다. 도메인 네임 시스템(Domain Name System)이 그것인데, 사람들이 태어나면 각각 유전자와 지문이 모두 다릅니다. 그래서 사람들의 유일무이 한 이름을 짓기 위해서 그 것을 번호화하여 불렀습니다. 하지만 사람의 기억력은 한 개가 있고 곧 유전자 번호와 상관없지만 이름을 부르는 것이 더 효과적이라는 사실을 알았습니다. 이것은 우리가 매일 접하는 인테넷에서도 마찬가지입니다. (이상한 나라 이야기입니다)
컴퓨터, 즉 TCP/IP를 사용하는 시스템에서는 유일무이 한 IP주소가 필요합니다. 그것은 이 세상에서 자기만이 가지고 있는 숫자입니다. 우리가 흔히 외톨이 호스트라고 부르는 컴퓨터는 인터넷 업체의 서비스를 받고 자기가 필요할 때마다 인터넷에 연결을 시도하는 컴퓨터를 말하는데 이러한 컴퓨터도 그때마다 서비스 업체가 제공하는 IP가 필요한 것입니다. 그런데 우리는 IP를 사용합니까? 아닙니다. 실제로 우리는 이름을 사용합니다. 가령 www.wellc.co.kr이라던가 cippexpo.com과 같이 이름을 사용합니다. 이것이 바로 도메인이라고 불려지는 것입니다.
2. DNS 역사
1980년대 개발된 TCP/IP프로토콜은 ARPAnet의
프로토콜로 채용되면서 많은 대학의 프로토콜로 채용되기 시작했습니다.
인터넷의 역사 1969, 미국방성 ARPANET 개통 |
초기의 소규모의 호스트은 IP와 이름이 맵핑된
정보를 HOSTS.TXT라는 파일로 가지고 있었습니다. 이 파일은 SRI의
NIC(Network Information Center)이 관리하며 SRI-NIC이라는 하나의
호스트에서 배포되었습니다. 이 파일을 다른 호스트들은 주기적으로
백업해서 자신의 호스트 정보를 갱신했습니다. 하지만 이것은 곧
한계에 도달했습니다. 이유는 호스트의 수는 계속 늘어 갔으며 파일의
크기 또한 커져서 네트워크의 트래픽을 증가시키고, 결정적인 마지막
이유는 하나의 호스트의 정보가 갱신될 때마다 모든 호스트가 HOSTS.TXT파일을
갱신해야 했기 때문입니다. 이것은 네트워크의 발전에 크나큰 장애
요인이 아닐 수 없었습니다.
HOSTS.TXT파일 이 파일은 리눅스의 /etc/hosts파일로
아직도 명맥을 유지하고 있습니다. 윈도우에서도 이
파일이 존재하는데 이유는 간단한 정보의 경우에는
DNS보다 효과적이기 때문입니다.
초기에는 HOSTS.SAM파일만이 존재하는데 이것을 HOSTS파일로 복사한 후에 사용하면 됩니다. |
그래서 USC Information Sciences Institute의
Paul Mockapetris가 새로운 시스템의 구조와 설계를 맡았습니다.
1984년 RFC 882와 883을 내놓았고 그 뒤 RFC 1034, 1035로 갱신되었습니다.
RFC RFC는 Request For Comments의 약자로서 인터넷상에서 새로운 기술을 소개하는 문서입니다. 간단히 검색엔진에서 RFC만으로도 우리가 원하는 정보를 가질 수 있는데, 각각의 문서에는 고유번호가 매겨져 있습니다. |
3. DNS의 개요
DNS는 분산 데이터베이스라고 흔히 말합니다. 이것은 UNIX의 파일 구조와 같은 맥락에서 논할 수 있는데, 가장 상위 레벨의 디렉토리를 /(root)라고 하고 그 하부디렉토리로 내려갈 수 있습니다. 이처럼 DNS도 가장 상위의 DNS가 그 아래의 도메인을 관리하고 그 아래 도메인관리자가 그 하부의 도메인을 관리하는 형식을 하고 있습니다. www.cippexpo.com을 예로 살펴보겠습니다. 먼저 우리가 서비스를 요청하므로 클라이언트 되고 우리가 서비스를 받을 곳이 서버가 됩니다. 뒤에서부터 검색을 시작하여 루트도메인을 검색합니다. 이것은 보통 IP주소를 시스템에 가지고 있습니다. 전세계에 흩어져 있는 루트 네임서버에게 com도메인을 질의합니다. 그러면 루트 네임서버는 com의 주소를 알려주고 다시 클라이언트는 이 정보를 가지고 com의 도메인을 관리하는 네임서버에게 cippexpo의 질의를 수행합니다. 그러면 com의 네임서버는 cippexpo의 의 네임서버 주소를 리턴하며 마지막으로 www의 질의를 수행하고 최종적으로 클라이언트는 www.cippexpo.com의 IP를 리턴합니다. 대개의 ISP 업체의 경우 한 대의 호스트에 기타 서비스들과 각각의 도메인들이 모두 같은 주소를 사용하기 때문에 위의 경우가 불필요하다가 생각될 수도 있습니다. 하지만 기업형 네트워크나 좀 규모가 큰 네트웨크의 경우 하나의 호스트에 하나의 서비스를 하는 것이 보통 입니다.
그러니까 www.cippexpo.com과 cippexpo.com의 주소는 다른 것이 리턴되는 것입니다. 그리고 DNS도 다른 호스트에서 서비스를 합니다.
< 그림 > 클라이언트 요청 질의 순서
다시 정리를 하면 최상의 루트 도메인은 우리가 상위 도메인이라고 알고 있는 com, org, net등의 도메인을 관리하고 각각의 com, org, net등의 도메인서는 그 아래 하부 도메인을 관리하는 것입니다. 이것은 바꾸어 말하면 우리도 도메인을 줄 수 있다는 이야기가 됩니다. 즉 우리가 IP를 가지고 있고 상위 도메인 서버에 등록된 상태라면 우리도 하부 도메인을 생성할 수 있으며, 또한 그 관리를 위임할 수도 있습니다.
IP : 203.232.212.214
도메인 : wellc.co.kr
하부도메인 love.wellc.co.kr
sky.wellc.co.kr
blue.wellc.co.kr
verywell.iloveyou.wellc.co.kr
< 그림 > 도메인 관리 체계
도메인 등록에 관하여 Korea Internet Information Service V1.0 ( created by KRNIC, 1999.6 ) query: wellc.co.kr # KOREAN 도메인 이름 :
WELLC.CO.KR 1차 네임서버 정보 |
담당하는 상위 도메인 네임서비스가 다르기 때문에 해당 도메인을 얻기 위해서는 각각의 도메인 관리 센터에 문의를 해야 합니다. InterNIC은 com, edu, gov, mil, net, org로 끝나는 도매인을 관리하며 KRNIC(KoRea Network Information Center, www.krnic.net)에서는 우리가 많이 보는 kr로 끝나는 도메인을 관리합니다.
4. DNS에서는 어떻게 운영되는가?
우리가 웹이라고 부르는 것은 WWW이라고 표기하듯이 DNS자체는 어떠한 소프트웨어 이름이 아닙니다. 즉 소프트웨어가 필요한데, DNS의 표준으로 자리잡은 BIND라는 소프트웨어가 그것입니다. 도메인 네임 시스템이 처음으로 구현된 것은 Paul Mockapetris에 의해 개발된 JEEVES라는 것이었습니다. 그 뒤에 구현된 것이 BIND로서 Kevin Dunlap에 의해 4.3BSD UNIX용으로 작성되었습니다. 현재는 ISC(Internet Software Consortium)에서 관리하고 있습니다. BIND(Berkeley Internet Name Domain)의 줄임 말로서 이것을 설치 관리함으로서 우리도 DNS서비스를 할 수 있습니다.
우선 www.bind.org에 접속하면 http://www.isc.org/products/BIND/ 로 이동되면서 BIND의 관한 설명이 나옵니다. 요즘 나오는 대부분의 배포판에는 bind가 필수 소프트웨어로 배포되고 있지만 가장 최신의 소프트웨어를 사용하려면 역시 만든 곳에서 소스로 설치하는 것이 가장 빠르고, 버그 및 보안에 대해서 정보를 받을 수 있습니다. 이 글을 읽는 독자 여러분들은 모두 파워 유저들이기 때문에 설치에 관한 사항은 다루지 않겠습니다.
가장 최신의 BIND 버전 : BIND Version 8.2.2 patchlevel 5 (Released November 12th, 1999)
5. 그외 DNS관한 사항
리졸버(resolver)
리졸버는 네임 서버를 액세스하는 클라이언트를 말합니다. 도메인 네임 공간의 정보를 필요로 하는 호스트 내의 프로그램들은 리졸버를 이용하며 다음과 같은 것들을 처리합니다.
·네임 서버에 질의(query)를 보낸다
·응답(리소스
레코드이거나 에러)을 해석한다.
·요청을 했던 프로그램에게
정보를 되돌려 준다.
리졸버는 특정한 프로그램을 지칭하는 것이 아니고 해당 DNS 소프트웨어의 라이브러리 루틴형식으로 배포됩니다. 아주 간단하고 깔끔하며 질의를 생성하고 서버로 전송하며 응답을 기다리며 대답이 없으면 질의를 다시 전송하는 것이 전부입니다. 질의에 대한 해답을 찾는 일의 대부분은 네임 서버의 몫입니다.
캐싱
재귀적 질의에 대한 대답을 찾기 위하여 네임 서버는 꽤 여러 번의 질의를 해야 할 수 있습니다. 그러나 네임 서버는 그 과정에서 해당 도메인 네임 공간에 대한 아주 많은 정보를 발견하게 됩니다. 그 과정에서 네임서버는 그러한 정보를 저장하고 나중에 같은 질의가 있을 경우에 캐싱된 정보를 찾습니다.
6. 마치며
이것으로 간단히 DNS에 대해서 알아보았습니다. TCP/IP의 한 부분으로 소개되는 DNS는 그 자체만으로도 몇 권의 내용이 될 만큼 많은 내용을 가지고 있습니다. 여기서 소개되지 못한 내용은 독자여러분의 몫으로 남겨놓겠습니다.
