<그림8.Domain Name Space의 계층구조>

위의 그림에서 볼 수 있는 것처럼 DNS는 뚜렷한 계층구조를 가지고 있다. 최상위에는 모든 도메인의 근본이 되는 root domain을 두고, null라벨(공백의 문자, " ")로서 이름을 할당하였다. 이것을 가리켜서 root-level domain이라고 부른다. root-level domain 아래에는 top-level domain을 두는데, 우리에게 친숙한 이름이 보일 것이다. kr, com, net, org등이 그것이다. 각각의 top-level domain은 특별한 원칙을 가지고 있다. 어느 집단이 사용을 하는 이름인지를 알아볼 수 있게 만든 것이다. 현재 약 250여개 정도의 top level domain이 사용되고 있다.<표1참고>

<표1.top level domain 이름구조>

이들 root domain과 top level domain은 우리가 등록해서 사용할 수 있는 이름이 아니다. InterNIC에서는 이미 전세계의 도메인들의 밑바탕이 될 이름을 등록하였고, 실제로 우리가 사용하게 될 이름은 이들 top level domain 아래의 도메인부터라고 할 수 있다.

< 그림8>에서 볼 수 있는 것과 같이 top level domain 아래에는 second level Domain이 있고, 거기에서 실제로 우리의 회사의 이름을 반영하는 이름들을 찾아볼 수 있게 된다. 우리가 도메인 등록을 한다고 이야기를 하면 바로 그러한 이름을 이야기하는 것이다. 물론 COM이나 Net과 같은 도메인 아래에 여러분의 회사를 등록한다면 바로 second level에서 등록하는 것이 가능하겠지만, 우리나라를 가리키는 Kr 도메인 아래에 회사를 등록하고자 한다면, 우리는 한단계 더 아래로 내려갈 수밖에 없다. Kr 아래에 또 다시 영리회사를 가리키는 "co"라는 이름이 second level로서 등록되고, 여러분이 원하는 회사이름은 그 아래에 등록되어야 하기 때문이다. 왜 그래야 할까? 답은 뻔하지 않은가! 미국에서 만들어서 사용하고 그네들이 발전시켜 오고 있는 것이기 때문에 우리는 그들이 할당해준 kr 이라는 top level domain을 우리나라 입장에서는 root로 삼고, 다시 그 안에서 분리작업을 해야 하기 때문인 것이다. 아쉬운 일이지만 힘을 키우는 도리밖에 어쩔 수가 없는 노릇이다.

이 러한 계층구조를 가진 분산데이타베이스 구조를 가리켜서 DNS(Domain Name Space혹은 Domain Name System)라고 부른다. 그렇다면 이들 DNS는 실제로 어디에 존재하는 것일까? 질문이 너무 막연해 보인다. 여러분이 즐겨찾는 인터넷이라는 공간을 가리켜 우리는 사이버공간이라고 부른다. 실체는 없는 가상공간이라는 뜻이다. 실제로 존재하는 것은 클라이언트 시스템으로서 사용하는 PC가 있고, 그들이 접속해서 사용하는 Web server라는 것이 있다. 전세계에 네트워크에 연결된 이들 모든 컴퓨터들이 어우러져서 InterNet이라고 부르는 하나의 커다란 가상공간이 존재하게 된 것이다. DNS도 마찬가지이다. 어느 한곳에 DNS라는 이름이 기록되고 관리되고 있는 형태는 아닌 것이다. 실체로 본다면 역시 물리적인 시스템인 서버가 존재하겠지만, 이들 모든 서버들이 만들어 내고 있는 하나의 가상공간인 셈이고, 이러한 가상공간을 제공하는 서비스를 DNS를 관리하는 서버, 바로 DNS Server가 이루어놓고 있는 것이다. 결국 <그림8>에서 각각의 그룹을 가리키는 도메인이라는 녀석이 존재하고 있었는데, 그 도메인의 중심에는 바로 DNS Server라고 하는 컴퓨터가 차지하고 있게 된다.

DNS를 정리해보면 "각각 회사를 구분해주는 도메인 이름을 관리하는 DNS Server들이 모여서 만들어낸 가상이름공간"이라고 요약을 해 볼 수 있겠다.

다 음은 DNS의 표기법에 대해서 알아보자. 이름충돌의 문제를 해결한다는 예제를 가지고 생각해 보자. <그림8>에서 second level domain중에 "idc2000"이라는 이름이 있고, 그 회사가 가지고 있는 서버중에 "www"라는 웹서버가 있다. 또한 Chollian이라는 회사도 역시 "www"라는 웹서버를 가지고 있다. 이들은 어떻게 똑같은 이름을 가질 수가 있게 되는가? 바로 DNS에서 바라보는 서버의 이름체계가 이 문제점을 해결해 주고 있다. 이제 더 이상 인터넷에 연결된 서버들은 서로를 구분하는데 있어서 평면적인 www라는 형태의 단순한 이름체계로 사용되지는 않는다. 인터넷상에서 서버들의 이름은 아래와 <표2>의 표기법을 사용하기 때문이다.

<표2.Fully qualified Domain Name>

결 과적으로 idc2000의 웹서버인 www서버는 www.idc2000.net과 같이 표기되고, 천리안의 웹서버는 www.chollian.net과 같이 표기되고 구별되기 때문에 전혀 다른 이름을 가지게 되는 것이다. 예전에 사용했던 평면적인 이름체계에서 벗어나 계층구조의 이름을 가짐으로써 이름충돌에 대한 문제점을 해결하게 된 것이다.

한 가지 고려사항은 여전히 남아있다. 같은 계층에 2개의 같은 도메인이 있을 수가 있을까? 라는 것이다. 예를 들면 net이라고 하는 도메인에 chollian이라는 도메인이 등록되어 있다. 또 다른 회사에서 역시 그들도 chollian이라는 이름을 사용하고자 한다면 당연히 허용해 주어선 안될 일이다. 이러한 문제 때문에 새로운 신기술이 나오면 서로 먼저 그 이름을 이용한 도메인을 등록하기 위해서 도메인전쟁이라고까지 표현되는 등록싸움이 발생하고 있는 것이다. 그렇다면 왜 도메인 등록을 하여야 할까. 그냥 우리가 사용하고 싶은 이름을 마음대로 쓰면 되는 것 아닌가? 라고 생각한다면 다음에 설명할 DNS의 이름분해과정을 이해하면 생각을 바꿀 수가 있을 것이다.

지금부터는 DNS Server가 어떤 과정을 통해서 이름분해 과정을 진행하는 지에 대해서 설명하도록 하겠다.

< 그림9>의 예제에서 DNS Client로 표기된 PC에 앉은 사용자는 www.idc2000.net이라는 이름을 가진 IDC2000회사의 웹서버에 접근해서 웹서비스를 받고자 한다. 사용자가 www.idc2000.net의 IP Address를 알고 웹 브라우저를 통해서 이름이 아닌 IP주소로 접근을 했다면 간단하겠지만, 사용자가 그런 주소를 알 필요는 없다. 이 사용자의 PC는 천리안의 DNS서버를 사용하는 DNS클라이언트로 셋팅이 되어 있다. DNS Client에 대한 부분은 1장에서 확인한 바 있다.


<그림9.DNS Name Resolution Process>

사 용자는 웹 브라우저의 주소창에 http://www.idc2000.net 이라고 입력하고 [Enter]를 누른다. 이 요청은http라는 프로토콜을 가지고 www.idc2000.net이라는 이름의 서버에 요청을 보내겠다는 뜻이다. 결국 웹서비스를 요청하는 메시지이다. 이 요청을 처리해 주기 위해서 사용자의 시스템은 먼저 www.idc2000.net의 IP Address를 알아야 한다. 하지만, 스스로 알 수 있는 방법이 없다. 그런데 DNS Client로 셋팅이 되어 있기 때문에 DNS Server로 셋팅된 서버에게 질문을 던질 수가 있다.

사 용자의 시스템은 자신의 TCP/IP등록정보에 DNS Server로 셋팅된 IP Address의 서버에게 www.idc2000.net의 IP Address를 요청하게 된다.(그림9-①) 이 요청을 가리켜서 resursive query(재귀적질의)라고 한다. resursive query라고 함은, 이 요청을 받은 서버가 '모 아니면 도' 둘중의 하나의 응답을 해야만 하는 Query를 말한다. IP Address를 가르쳐주거나, 에러메시지를 반납하거나.

① 의 요청을 받은 DNS Server는 응답을 해야 하는데, 자신 역시 자신이 관리하는 이름을 알 뿐이지 어디 있는지도 모르는 idc2000이라는 회사의 웹서버의 IP Address를 알 턱이 없다. 그래서 먼저 DNS Server는 Cache라고 부르는 데이터베이스에서 클라이언트가 요청하는 정보가 있는지를 확인해 본 다음, 없다면 다른 DNS에게 질문을 던져서 클라이언트의 요청을 해결하려는 시도를 하게 된다. Windows2000 시스템에 DNS Service를 추가하고, DNS Server로 동작하게 되면 그 서버에는 한가지 정보가 기본적으로 추가된다. 바로 Root Domain을 관리하고 있는 DNS Server들의 목록이다. 서버는 그 정보를 이용해서 root domain의 DNS Server에게 클라이언트가 요청한 www.idc2000.net 에 대한 이름분해 요청을 보내게 된다. (그림9-②) 이 때의 Query를 가리켜서 Iterative Query (반복적 질의)라고 부른다. Recursive Query와는 조금 성격이 틀린 것을 알 수 있을 것이다.

Root name server는 요청을 받았으니 응답을 해야 할텐데, 자신 역시 모든 정보를 알고 있는 것은 아니다. 자신이 알고 있는 것은 "net"도메인을 관리하는 DNS Server의 정보를 알고 있을 뿐이다. 그래서 천리안의 DNS Server가 원하는 모든 정보에 대한 응답이 아닌, "net"도메인을 관리하는 DNS Server의 정보를 제공해 주게 된다. (그림9-③)

천 리안의 Name Server는 한번의 query를 통해서 net도메인의 Name server의 정보를 알 게 되었다. 아직 완전한 정보는 얻지 못했기 때문에 임무에 충실할 책임을 다한다. "net"도메인의 DNS Server에게 www.idc2000.net. 의 IP정보를 요청하게 된다. (그림9-④)

하 지만 'net'도메인의 DNS Server역시 천리안의 Name server가 요청한 호스트이름에 대한 IP정보를 알지는 못한다. 그렇지만 idc2000을 관리하고 있는 DNS서버의 정보는 알고 있다. 자신이 관리하고 있는 도메인이기 때문이다. 그래서idc2000.net 의 DNS서버의 정보로서 요청에 응답해 주게 된다. (그림9-⑤)

idc2000.net. 도메인의 Name server정보를 얻은 천리안의 name server는 idc2000.net의 name server에게 www.idc2000.net.이라는 자신의 클라이언트가 요청했던 호스트에 대한 IP정보를 요청하게 된다. (그림9-⑥)

이 요청을 받은 idc2000.net.의 DNS Server는 요청한 FQDN이 자신이 관리하고 있는 도메인에 소속된 호스트이기 때문에 IP Address정보를 응답해 줄 수가 있게 된다.(그림9-⑦)

몇 번의 query를 통해서 DNS Client가 요청한 정보를 알게 된 천리안의 DNS Server는 www.idc2000.net의 IP Address를 제공해 줄 수가 있게 되었다.(그림9-⑧)

그 렇다면 이제 사용자는 DNS Server를 통해서 원하는 웹서버에 대한 IP Address를 알 게 되었기 때문에 TCP/IP통신을 할 수가 있게 되었다. http프로토콜로써 웹서버에게 서비스를 요청하고, 웹서버는 홈페이지를 서비스해 주게 되는 것이다.

글로 써 기록하니 상당히 복잡해 보인다. 하지만, 실제로 사용자 입장에서 보자면, 사용자는 웹 브라우저의 주소창에 친숙한 이름표기법에 따르는 이름을 입력했을 뿐이고, 내부사정은 알바가 아니지만 홈페이지를 볼 수가 있게 되었다. 이러한 작업이 가능하게 만들어지게 하기 위해서 DNS Server는 부지런히 발로 뛰며 서비스를해 주고 있었던 것이다. DNS가 없었다면 이런 일이 가능했을까? 실로 DNS의 위력은 엄청나게 보인다. 필자는 감히 인터넷을 이끌어가고 있는 것은 바로 DNS라고 말하고 싶다. 그만큼 인터넷에 있어서 DNS의 기능은 대단하다고 할 수 있기 때문이다.

만 일 DNS가 없다면 지금 우리가 사용하는 인터넷이라는 환경이 상당히 많이 다를 거라고 생각한다. TV에서 하고 있는 광고중의 상당수는 도메인이름을 알리는 광고를 하고 있다. DNS가 없다면 업체에서는 도메인이름을 알리는 광고가 아니라 IP Address를 알리는 광고를 해야만 할 것이다. 채림이가 나와서 hihome.com이라는 점(.)을 내세운 광고를 하고 있지만, 그것도 안될 말이고, 수많은 dot com으로 대변되는 벤쳐기업들도 이름자체가 애매해졌을 것이다.

그 렇다면 앞서서 가졌던 한가지 의문중에 "왜 반드시 원하는 도메인이름을 등록해야만 사용할 수 있을까"라는 것을 생각해 보자. <그림9>의 예제에서 웹서버 입장을 생각해 보자. idc2000이라는 회사는 자신의 웹서버를 통해서 회사를 홍보하고, 몇가지 서비스를 판매하는 일을 하고 있다고 가정해 보자. 사용자가 자신의 웹서버의 IP Address를 알고 찾아오게 하는 일은 가장 중요한 일이라고도 할 수 있다. 그런데 앞에서 보았듯이 사용자가 자신의 웹서버의 IP주소를 알기 위해서는 어떤 과정이 있었는가? idc2000의 DNS Server까지 요청이 와야 하는데, 그것보다 선행되었던 작업이 net도메인의 DNS Server를 찾는 과정이었다. 만일 net도메인의 DNS서버에 idc2000의 도메인의 정보가 등록되어 있지 않았다면 당연히 net도메인의 DNS Server는 천리안의 name서버의 요청에 그런 도메인은 없다라는 에러메시지를 전송해야만 했을 것이다. 당연히 천리안의 DNS Server는 이름분해를 처리하지 못했기 때문에 사용자에게 에러메시지를 반송할 수밖에 없게 되는 것이다.

도메인등록이라는 용어를 풀어본다면, "회사에서 사용하고 싶은 도메인 이름을 관리하는 DNS Server의 정보를 상위 도메인을 관리하는 DNS Server에 등록하는 작업"이라고 생각할 수 있겠다.

처 음 볼 때는 상당히 번거로운 작업이라는 생각이 들 수도 있다. 하지만, 이러한 DNS의 진행과정은 2장에서 보았던 hosts.txt파일을 이용한 이름분해의 과정이 가졌던 모든 문제점을 해결할 수 있는 방법이 되고 있다. 문제점과 비교해서 DNS의 이름분해과정을 연관시켜서 정리해 보길 바란다.

지금까지 DNS의 구조와 이름분해과정(name resolution process)에 대해 설명하였다. 다음장에서는 본격적으로 Windows2000 DNS의 설치와 구성을 다루어보도록 하겠다.

출처: http://www.secure.pe.kr