앞에서 WINS서버를 설치하고 클라이언트를 설정하는 방법을 설명하였다. 지극히 쉬운 방법이지만 이렇게 설정해 놓은 WINS서버가 실패했을 경우 즉 서비스가 멈추는 상황이 발생한다면 큰일이 아닐 수 없다. 회사에서 WINS서버의 활용도가 크면 클수록 문제발생시의 불편함은 커지기 마련일 것이다. 네트워크 상에서 서비스가 구현이 될 때 관리자가 반드시 고려해 봐야 할 부분이 이러한 것이다. 서비스를 하던 서버가 멈췄더라도 여전히 클라이언트는 원하는 작업을 계속할 수 있어야 한다는 것이다. 바로 가용성(Availability)을 고려해야 한다는 것을 의미한다. 또 한가지는 회사에 하나의 서버가 있는데 서버가 수용하기 어려울 정도로 많은 사용자가 서비스를 요청한다면? 당연히 결과는 너무나 느린 응답시간 때문에 사용자들의 불만은 커질 것이고 심한 경우는 서버의 다운으로 까지 이어져서 네트워크가 마비되는 결과를 초래할 수도 있을 것이다. 가용성과 더불어 추가로 고려해야 할 사항이 바로 성능(Performance)이다. 이 두가지 사항을 감안하여 기업 네트워크 상에 어떻게 하는 것이 WINS서버를 구현하는 최선의 방법이 될 것인지 알아보도록 하자.

아래의 <그림6-11>를 보면서 접근해 보자. 예제그림은 서울에 본사가 있고, 부산에 지사가 있는 회사이다. 서울과 부산간에는 상대적으로 느린 WAN 링크를 이용하고 있고, 두 지역간에는 서로간에 자원을 공유해야 할 필요성이 있다. WINS서버를 구현하고자 하는데 가용성과 성능을 고려해서 최적화된 WINS 서비스를 구현하기를 원한다. WINS서버는 몇대를 두고 어디에 배치를 하고, 클라이언트는 어떻게 설정을 해 줘야 할까?

WINS 서비스의 가용성과 성능을 높일 수 있는 방법중 가장 일반적인 것은 서버를 여러대 배치하는 것이다. 하나의 서버가 서비스를 하지 못하더라도 다른 서버가 계속 서비스를 제공할 수 있기 때문이다. 두 대를 배치한다고 가정하면 서울에만 2대의 WINS서버를 두는 것보다는 지역마다 하나씩 두는 것이 바람직할 것이다. 그렇지 않으면 부산에 있는 WINS클라이언트가 자신의 NetBIOS 이름을 등록할 경우, 또는 다른 서버의 NetBIOS 이름해석을 요청할 때마다 상대적으로 느린 WAN 구간을 거쳐야 할 것이다. 여기서 우리가 고려해 보아야 할 점은 두 대의 서버가 각각 정상적으로 동작하고 있는 경우라면 가급적이면 WAN 트래픽이 발생하지 않도록 해야 한다는 것이다.

이를 해결하기 위해서 일단 서울에 WINS-A를 설치하였다. 그리고 서울에 있는 모든 컴퓨터를 WINS-A의 클라이언트로 설정하였다. 다음에 부산에 WINS-B를 설치하고 부산의 모든 컴퓨터를 WINS-B의 WINS클라이언트로 설정하였다. 이렇게 하면 서울에서의 WINS 트래픽은 서울지역에만 국한되고, 부산에서의 WINS 트래픽은 부산지역에서만 발생될 것이다.

여기까지만 구성하면 문제가 발생한다. <그림6-11>에서 부산의 WINS 클라이언트인 RED가 서울에 있는 BLUE 라는 이름의 서버를 찾고자 한다면 어떻게 될 것인지 생각해 보자. RED는 WINS-B에게 BLUE 라는 NetBIOS 이름을 쿼리할 것이다. 하지만 WINS-B는 BLUE의 IP Address를 알 수가 없다. 왜냐하면 BLUE는 자신의 클라이언트가 아니기 때문이다. BLUE의 레코드는 서울의 WINS서버인 WINS-A가 가지고 있을 뿐이다. 서울의 WINS서버와 부산의 WINS서버의 WINS Database는 서로 다르다. WINS-A는 서울의 WINS 클라이언트의 레코드를 가지고 있고, WINS-B는 부산의 WINS 클라이언트의 레코드를 가지고 있다. 서울과 부산간에 자원의 공유가 가능해 지려면 이 두 WINS서버들의 WINS Database가 교환될 필요성이 생긴다. 이 과정을 WINS Database 복제를 설정함으로써 가능하게 만든다.

이들 두 대의 WINS서버는 서로를 WINS Database 복제파트너로 설정하여 자신의 DB를 밀어주고(push partner), 상대방의 DB를 끌어오는(Pull Partner) 형태로 서로 다른 WINS Database를 하나로 통합할 수가 있게 된다. 이렇게 하면 부산에 있는 WINS Client가 자신의 WINS서버에게 서울의 레코드를 요청하더라도 올바른 응답을 받을 수 있게 된다. WINS 데이터베이스 복제파트너는 WINS 관리콘솔에서 '복제파트너'를 통해서 추가할 수 있다. <그림6-12>에서는 redapple이라는 이름의 WINS서버를 복제파트너로 추가하고 등록정보를 열어서 Pull / Push 복제 일정을 확인한 것을 볼 수 있다. 

 <그림6-13. WINS 복제 파트너 추가 >

복제파트너로 구성할 상대방 WINS서버의 이름이나 IP주소를 입력해야 한다. IP주소를 입력하는 것이 좋다.

이번엔 다른 측면을 고려해 보자. 만일 부산에 있는 WINS 서버가 멈춘다면 어떻게 될까? 당연한 얘기지만 부산지역의 WINS 클라이언트는 더 이상 WINS서버를 이용할 수가 없다. 그러면 그 클라이언트들은 부산지역의 서버를 찾을 때는 WINS서버를 이용할 수 없으므로 다음 방법인 브로드캐스트를 이용해서 검색을 할 수도 있겠지만 서울지역에 위치한 컴퓨터들을 찾고자 할 때는 실패할 수밖에 없게 된다. 그렇다면 이러면 되겠다. 부산에 있는 WINS서버가 동작하고 있을 때는 해당 서버를 통해서 서비스를 받고, 만일 부산의 WINS 서버가 문제가 있다면 서울의 WINS 서버를 사용하면 될 것이다. 그렇게 동작하도록 하기 위해서 부산의 WINS 클라이언트들에게 두 번째 WINS서버를 추가로 설정을 해 줄 수 있다. <그림6-15>의 빨간색 표기부분을 보면 2개의 IP Address가 설정되어 있다. [추가]버튼을 이용하여 WINS서버를 추가할 수 있고 오른편의 [화살표]버튼을 이용하여 쿼리순서를 결정할 수 있다. 물론 서울의 WINS 클라이언트들은 두 번째 WINS Server로서 부산의 WINS서버를 이용할 수 있도록 설정해 줘야 한다.

만일 네트워크에 비 WINS 클라이언트가 있다면 그들을 지원해야 할 필요가 있다. 비 WINS 클라이언트는 자신의 NetBIOS이름을 WINS 서버에 등록하지 않는다. 또, 다른 서버의 자원에 접근하기 위해서 NetBIOS이름풀이(name resolution)를 할 때도 역시 WINS서버에게 쿼리하지 않고 브로드캐스트를 이용한다. 아래의 <그림6-7>을 보면서 설명한다.

<그림6-7>의 예제에서는 라우터로서 분리된 2개의 브로드캐스트 도메인을 보여준다. 왼쪽의 세그먼트에는 WINS서버가 있고, WINS 클라이언트인 'Blue'라는 이름의 컴퓨터도 존재한다. 오른쪽의 세그먼트에는 왼쪽의 WINS Server의 클라이언트로 설정된 WINS 클라이언트도 있고, 'Red'라는 이름의 Non-WINS 클라이언트도 존재한다.

첫 번째 상황을 가정해 보자. 예제와 같은 환경에서 Blue가 Red의 자원에 접근을 하고자 한다(①). Blue의 사용자는 \\red\public 이라는 UNC 경로를 사용하여 red에 접근을 시도했다. red 라는 NetBIOS Name은 TCP/IP 통신을 위해서 당연히 IP Address로 매핑 (resolution)되어야 한다. blue는 WINS 클라이언트이므로 NetBIOS 이름풀이 방법으로써 WINS서버에게 요청을 하게 된다(②). 이 요청을 받은 WINS Server는 WINS Database에서 "Red <20>"이라는 NetBIOS 이름을 검색한다. 하지만 red의 레코드를 찾지 못한다. 이유는 Red가 Non-WINS 클라이언트이므로 자신의 NetBIOS Name을 WINS Server에 등록하지 않았기 때문이다. 결국 WINS 서버는 Blue에게 NetBIOS Name Resolution을 하지 못했다는 응답을 하게 되고, Blue는 그 다음 Resolution방법으로 브로드캐스트를 시도하게 된다. 그렇지만, 라우터로 네트워크가 분리되어 있고 Red 는 원격지의 네트워크에 위치해 있으므로 검색에 실패하게 된다. 결과적으로 Blue에서는 "네트워크 경로를 찾지 못했다."라는 에러 메시지를 확인하게 된다. 통신실패를 의미한다.

해결방법은 있다. 기본적으로 WINS 서버는 동적으로 동작하지만 관리자가 수동으로 레코드를 추가할 수도 있다. 정적매핑을 통하여 Red를 WINS 서버에 추가해 주면 된다. WINS 관리콘솔의 왼쪽 패널의 서버이름 아래에 있는 '활성등록'을 선택한 다음 마우스 오른쪽 클릭하여 '새 정적 매핑'을 선택한다. Red 의 IP Address를 할당해 주면 된다. <그림6-8>

<그림6-9>을 보면 정적 매핑으로 추가한 Red 의 레코드를 확인할 수 있다. 이제 WINS 클라이언트인 Blue는 WINS 서버를 통하여 Red 의 IP Address를 쿼리할 수 있게 되었다.

두 번째 상황도 고려해 보도록 하겠다. 이번에는 Non-WINS 클라이언트인 Red가 WINS 클라이언트인 Blue를 찾고자 할 때의 상황을 생각한다. Red의 사용자는 Blue의 Public 공유폴더에 연결하기 위하여 \\blue\public 이라는 UNC를 통해서 접근을 시도했다(③). Red 는 Non-WINS 클라이언트이므로 Blue의 NetBIOS 이름을 찾기 위해 WINS서버에게 쿼리하지 않는다. 브로드캐스트를 이용해서 이름풀이를 시도할 것이다(④). 당연히 라우터의 건너편 네트워크에 존재하는 Blue로부터 응답이 올 수가 없다. 역시 에러 메시지를 받게 될 것이다. 이것을 해결할 방법은 있다. 다행히 오른쪽 편의 네트워크에 WINS 클라이언트가 존재한다. 이 WINS 클라이언트가 Non-WINS 클라이언트를 대신해서 WINS 서버에 요청을 전달해 주게 구성할 수 있다. 이때 이러한 WINS 클라이언트를 가리켜서 'WINS Proxy Agent'라고 부른다. WINS Proxy Agent를 구성하기 위해서는 레지스트리를 직접 편집해 주어야 한다. WINS Proxy Agent로 구성할 시스템에서 레지스트리 편집기(regedt32.exe 혹은 regedit.exe)를 통해서 레지스트리를 열고 \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\ 키를 찾은후 'EnabledProxy' 값을 '1'로 설정하면 된다.<그림6-10>

뭔가 되긴 된 듯해 보이지만 석연찮은 구석이 있다. 이거 WINS 클라이언트가 아닌 녀석이 하나 끼어있으니까 이래저래 번거로운걸? 하는 생각이 들었다면 지금까지 내용을 잘 이해한 독자라는 생각이 든다. 방법은 있다. 아주 간단한 방법. Non-WINS Client를 두지 않고 전체 모든 시스템을 WINS 클라이언트로 만들면 모든 것이 해결된다. WINS솔루션을 구현하자. 하지 못할 이유가 없다.

위에서 WINS서버를 구현하는 방법이 가장 바람직한다는 말을 했다. 그렇다면 이제 WINS서버를 설치하고 구성을 해 보도록 하겠다. WINS서비스를 먼저 추가해 주어야 한다. 제어판àWindows구성요소 추가à네트워킹서비스àWINS를 통해서 추가할 수 있다.<그림6-4>

<그림6-4. WINS 서비스 설치 >

설치가 완료되면 그것으로 WINS서버의 준비는 끝났다. 다음엔 WINS서버에게 자신의 NetBIOS이름을 등록하고 다른 서버의 NetBIOS 이름을 쿼리할 수 있도록 클라이언트 셋팅을 해야 한다. ‘제어판à네트워크 연결’을 통해서 TCP/IP 등록정보를 연 다음, [고급]버튼을 클릭하면 WINS 탭을 볼 수 있다. [추가]를 이용하여 앞에서 WINS서비스를 설치한 서버의 IP Address를 입력한다. 예제에서는 192.168.0.16을 입력했다.<그림6-5>

클라이언트도 구성을 했다. 이것으로써 WINS서버와 WINS클라이언트 구성을 모두 마쳤다. 사실 설치는 너무나 쉽다. 그것보다는 이러한 서비스들의 필요성을 이해하는 것이 보다 중요한 일이라고 생각한다. 과정을 이해하면 보다 커다란 환경의 네트워크를 만나게 되었을 때도 적절히 대처를 하는 것이 용이할 것이기 때문이다. 이제 WINS서버쪽에서 WINS 관리도구를 열어보면 <그림6-6>에서 보는 것처럼 클라이언트가 등록되어 있음을 알 수 있다. 또 다른 WINS 클라이언트가 BLUEXP라는 NetBIOS 이름에 대한 IP Address를 요청한다면 이 WINS서버는 응답을 할 수가 있게 된다. 이러한 일련의 과정들은 동적으로 동작한다. 관리자는 WINS서비스를 추가해 주고, 네트워크 상의 모든 클라이언트를 WINS 클라이언트로만 구성해 주면 나머지는 WINS서비스가 알아서 처리한다. 말 그대로 ‘서비스’이다.

6-2-1. NetBIOS 이름 등록 및 해제

NetBIOS이름이 사용되기 위해서는 먼저 네트워크에 등록이 되어야 한다. 이름등록을 하는 방법으로는 두가지가 제공된다.

첫 번째 방법은 브로드캐스트를 이용하는 것이다. 시스템이 시작되고 NetBIOS 어플리케이션이 시작되게 되면 이름등록을 진행하게 된다. 이때 브로드캐스트를 통해서 네트워크에 자신의 이름을 등록하게 된다. 만일 사용하고자 하는 이름을 누군가 미리 등록해서 사용하고 있다.면 이름충돌의 에러메시지를 받게 되고, 해당 이름등록은 실패하게 된다.

두 번째 방법은 NetBIOS Name 서버에게 이름등록을 요청하는 방법이다. 네트워크에 브로드캐스트를 발생시키지 않으므로 보다 권장할 만한 방법이라고 하겠다. NetBIOS이름서버에게 이름등록을 요청하기 위해서 해당 시스템은 NetBIOS이름서버의 클라이언트로 설정되어야 한다.  NetBIOS 이름해제는 반대과정이다. 이것은 NetBIOS 어플리케이션이 중지될 때 발생하는 일이다. 결과적으로는 시스템이 셧다운 될 때 생기는 과정이라고 할 수 있다.

6-2-2. NetBIOS 이름 분해 요청 (Name Resolution Request)

이것은 클라이언트가 자원을 가진 서버의 NetBIOS이름에 해당하는 IP Address를 찾고자 할 때 발생한다. 파일서버의 자원에 접근하기 위해 서버를 검색할 때 혹은 도메인으로 로그온을 시도할 때 등등 여러 가지 상황에서 NetBIOS 이름요청이 활성화된다. NetBIOS 이름 요청 방법도 역시 두 가지가 제공된다. 첫 번째 방법은 브로드캐스트를 이용하는 것이고, 두 번째 방법은 NetBIOS 이름 서버를 통해 찾는 것이다.

하나의 시스템이 NetBIOS Name Server의 클라이언트로 셋팅되면 자신의 NetBIOS 이름을 등록할 때도 NetBIOS 이름 서버를 이용하고, 다른 시스템의 NetBIOS Name을 쿼리할 때도 역시 NetBIOS 이름 서버를 이용한다. 그렇지 못한 클라이언트라면 브로드캐스트 통신방법을 사용하여 NetBIOS 이름을 찾으려는 시도를 한다.

아무런 설정이 필요없이 통신을 위한 기본작업인 “이름을 가지고 주소를 찾기”라는 과제를 해결해 줄 수 있다는 측면에서는 브로드캐스드가 편한 방법이라고도 생각될 수 있지만 그렇게 되면 라우터로 분리된 네트워크에서 라우터 건너편 노드의 NetBIOS이름을 찾는 것은 불가능한 일이 된다. 또 노드수가 많아진다면 그만큼 네트워크에 브로드캐스트가 많아지므로 결과적으로 네트워크에 전체적인 성능저하까지 가져올 수 있게 된다. 따라서 기업 네트워크에서 NetBIOS이름을 필요로 하다면 NetBIOS 이름서버를 사용하는 것이 보다 바람직한 방법이다. 마이크로소프트는 NetBIOS 이름서버로서 WINS (Windows Internet Name Service)서버를 제공해 주고 있다.

BIOS (Basic Input Output System)는 컴퓨터에서 각종 디바이스들의 입출력을 담당하는 표준시스템이다. 컴퓨터 한 대만 있는 환경이 아닌 네트워크 환경을 고려해보면 이것만으로는 부족한다는 것을 알 수 있다. 하나의 시스템에 국한된 환경이 아니라 컴퓨터 대 컴퓨터간의 입출력을 처리해야 할 필요성이 생겼다. 이에 IBM은 Network에서 구현되는 BIOS를 개발했다. 이것이 NetBIOS이다. 이것은 네트워크에 있는 시스템들간의 통신을 위한 컴퓨터 이름 관리, 그리고 지속적인 통신을 위한 세션유지 등을 처리하고 실제 패킷을 전송할 책임이 있는 프로토콜을 호출하는데 필요한 일련의 방법들을 제공하고 있다. 하나의 어플리케이션이 네트워크 상에 있는 다른 컴퓨터의 어플리케이션에게 데이터를 주고 받는 데 필요한 네트워크 통신 부분과의 연결지점 역할을 담당하는 것이다.

그렇다면 이들 NetBIOS 프로토콜을 사용하는 어플리케이션이 상대방 컴퓨터를 찾을 때는 어떤 이름을 사용할까? 그것 역시NetBIOS 표준이름 구현을 통해서 상대방 시스템을 찾게 된다. 이러한 이름체계 역시 NetBIOS 라는 표준에 맞도록 정의되어 있다.

NetBIOS는 16byte로 구성이 되어 있지만 실제로 컴퓨터 이름으로 할당할 수 있는 바이트수는 15바이트로 제한된다. 마지막 16byte째의 플래그는 특별한 용도로 사용된다.

하나의 서버가 하는 일은 다양하다. 예를 들어 네트워크에 자신의 자원을 제공해 줄 수 있는 역할인 '서버 서비스'를 하고 있고, 자신도 클라이언트로서 다른 자원에 접근할 수 있는 '워크스테이션 서비스'도 하고 있고, 또 도메인 컨트롤러라면 도메인 사용자들의 로그온을 처리해 주는 '로그온 서비스'도 하고 있고, 다른 서버로부터 알림 메시지를 받기 위한 '메신저 서비스'도 하고 있을 것이다. 이러한 각각의 서비스를 구별하기 위하여 16byte째의 플래그가 사용된다. 이 16번째의 플래그는 1byte를 차지하며 2자리수의 Hexadecimal (16진수) 값으로 만들어지고 각각 서비스 타입별로 숫자가 지정되어 있다. 자주 볼 수 있는 플래그를 정리해 보면 다음과 같다.

<표6-1. NetBIOS Name Flag >

아래의 <그림6-2>은 windowsnetwork 도메인에서 도메인 컨트롤러로 셋팅된 blueapple이라는 이름의 서버에서 nbtstat 명령어를 통해서 blueapple 서버가 등록해서 사용하는 NetBIOS 이름들을 살펴 보았다. Blueapple이라는 이름이 여러개 등록되어 있는 것이 보이고 이름의 뒤쪽에는 <00> <20>등의 숫자가 보인다. 이것이 NetBIOS이름의 16번째 byte에 해당하는 플래그이다. 그리고 이것은 blueapple서버가 어떤 서비스를 하고 있는지 서버의 역할을 나타낸다.

실제로 이러한 NetBIOS 이름이 어떤 경우에 사용되는지 예를 들어보자. 클라이언트가 blue라는 이름의 서버의 공유폴더에 접근하고자 한다면 사용자는 '\\blueapple\공유이름' 의 형태로 접근을 하게 된다. 이때 실제로 네트워크 상에 요청을 확인해 보면 'BLUEAPPPLE <20>'을 찾는 것을 확인할 수 있다. 서버로서의 blueapple을 찾는 요청이기 때문이다. 또, Windows98혹은 NT4.0 사용자가 windowsnetwork 도메인으로 로그온을 시도한다면 도메인에서 로그온을 받아주는 서버, 즉 도메인 컨트롤러를 찾아야 한다. 그때의 요청은 실제로는 'WINDOWSNETWORK<1C>'가 된다.

이렇듯 클라이언트가 특정 서버의 NetBIOS 이름을 찾기 위해서는 선행되야 할 일이 있다. 당연히 네트워크에 서버의 NetBIOS이름이 등록되어 있어야 찾을 수가 있을 것이다. 그렇다면 서버는 어떤 방법으로 네트워크에 자신의 NetBIOS 이름을 등록하는 것일까? 또, 클라이언트는 어떤 방법으로 네트워크에 등록된 NetBIOS 이름을 찾을 수가 있는 것일까? 여기서 WINS의 필요성은 출발 할 수 있다.

마이크로소프트는 자사의 네트워크에서 NetBIOS를 채택하고 꾸준히 이를 지원해 왔다. 그리고 NetBEUI (NetBIOS Extended User Interface)프로토콜을 개발하여 NetBIOS를 지원했다. NetBEUI는 NetBIOS를 지원하기 위해서 개발된 프로토콜이므로 NetBIOS를 완전하게 지원할 수 있는 잘 동작하는 프로토콜이다. 하지만 이 프로토콜의 통신방법은 NetBIOS 이름기반의 브로드캐스트에 의존하고 있고, 이것은 라우터로 브로드캐스트 도메인이 분리된 확장된 네트워크 환경에서는 큰 문제점을 안고 있다. 라우팅이 되지 않기 때문에 네트워크의 확장성이 매우 떨어지게 되는 단점이 있는 것이다. 더불어 인터넷 표준 프로토콜로써 TCP/IP프로토콜이 사용이 되고 회사의 네트워크가 더 이상 로컬 LAN에만 국한되어 단순히 파일이나 프린트 공유정도만을 요구하지는 않는다. 대부분의 시스템에서 인터넷에 접근을 하는 것이 기본적인 사항이 되어가고 있으니 NetBEUI를 사용하는 클라이언트라도 추가로 TCP/IP를 설치하여 사용할 필요성이 생기게 되었다. 마이크로소프트 역시 TCP/IP를 지원하고 있다.

여기서 한가지 고려해 봐야 할 것이 있다. NetBIOS 어플리케이션은 브로드캐스트 통신방법에 기초한 NetBIOS이름을 이용해서 통신을 한다. 하지만, TCP/IP환경에서는 IP Address로써 각각의 시스템을 구분하고 IP Address를 근거해서 통신을 한다. 마이크로소프트에서 TCP/IP를 지원한다고 하더라도 여전히 기존의 어플리케이션이 NetBIOS를 필요로 하고 있고, 이것을 TCP/IP에서도 지원해 주어야만 호환성에 문제가 발생하지 않을 것이다. 그래서 TCP/IP 프로토콜의 구조를 살펴보면 'NetBT'라는 프로토콜이 포함되어 있음을 알 수 있다. NetBIOS over TCP/IP를 줄인 표기이다. TCP/IP상에서 NetBIOS를 구현하기 위한 인터페이스를 제공하고 있다.

위에서 보듯이 NetBIOS 어플리케이션들은 NetBT 인터페이스를 통해서 TCP/IP의 TCP나 UDP를 호출하는 것이 가능해진다. 그렇지만 통신상에서 구별하는 이름에는 여전히 차이가 있다. NetBIOS 어플리케이션에서는 NetBIOS이름을 통해서 상대방 시스템을 찾으려 시도할 것이고, TCP/IP 프로토콜에서는 그러한 이름을 알 수가 없다. 누군가가 이 문제점을 해결해 주어야 한다. 이것을 해결하기 위한 인터넷 표준이 두 가지 마련되어 있다. 하나씩 알아보도록 하자.

마이크로소프트의 네트워크 환경에서 여러 가지 서비스를 하는 서버들이 있지만, 역시 빼 놓을 수 없는 서비스가 하나 있다. Windows NT4.0 에 비하면 Windows 2000 환경에서는 그 역할이 많이 줄어들었지만 여전히 기업네트워크에서는 중요한 서비스중 하나임에는 틀림없다. WINS서버가 왜 필요하고, 네트워크에서 수행하는 역할은 무엇인지, 최적화된 관리방법은 무엇인지 차근차근 접근해 보도록 하겠다.

5-6-1. DNS Round Robin (라운드 로빈) 구현

당신의 회사가 쇼핑몰을 운영하고 있다고 가정을 하자. 당연히 회사에서는 웹서버가 적절한 성능을 제공해야만 할 것이다. 1대의 서버만 운영하다가 사용자들이 느린 성능문제로 불만이 많아짐에 따라 1대의 웹서버를 증설하고 동일한 컨텐츠로서 웹서버를 셋팅해 두었다. 그 다음에 해야 할 일은? 당연히 쇼핑몰을 찾는 클라이언트들이 두 대의 서버를 찾아올 수 있도록 구성을 해 주어야 할 것이고, 거기다가 가급적이면 골고루 찾아올 수 있게 해 줄 필요가 있을 것이다. 이때 가장 저렴하고 간단하게 구현할 수 있는 방법이 DNS서버의 Round robin 기능을 이용하는 것이다.

사실 DNS가 하는 일이 복잡한 기능은 아니다. 단지 누군가가 이름을 물어왔을 때 그 이름의 서버가 어디에 있는지를 가르쳐 주면 되니까. 하지만 그것이 네트워크에서 차지하는 비중은 엄청나다 할 것이다. 제아무리 웹서버가 안정적으로 구현되어 있다고 하더라도 DNS서버가 부실하면 사용자들이 그 웹서버까지 찾아갈 수가 없기 때문에 무용지물이 되고 마는 것이다. 웹서버 두대를 설치해 두었다면 클라이언트들은 그 웹서버를 찾기 위해 DNS쿼리를 하게 될 것이고 그때 DNS서버는 두개의 웹서버를 번갈아 찾아갈 수 있도록 해 주면 될 일이다. 이론상으로 이해하면 너무나 쉬운 기능이다. 구현하는 것도 역시 간단하다.

그림은 DNS관리콘솔의 서버이름을 마우스 오른쪽 클릭하여 등록정보를 열었을때의 화면을 캡처한 것이다. ‘고급’탭을 확인하면 위와 같은 화면을 볼 수 있다. 하이라이트된 부분을 보면 “라운드 로빈 사용”이라는 옵션이 보인다. 기본적으로 Windows2000 DNS서버는 이 옵션이 활성화되어 있다. 다음에 할일은 웹서버 두대에 대한 www 레코드를 생성해 주면 된다. 주의할 것은 www 라는 레코드는 CNAME 레코드로 만들어서는 안 된다는 것이다. www라는 동일한 이름의 A (Address)레코드를 두 개 만들어 준다. <그림5-75>에서는 secure.pe.kr 도메인에 www레코드가 두개 생성되어 있고 두개의 레코드는 각각 다른 IP Address가 설정된 것이 보인다. 웹서버 두대에 대한 레코드가 만들어진 것이다.

이렇게 간단히 DNS만으로 웹서버 두대를 효율적으로 운영할 수 있다는 장점이 있기는 하지만 이 DNS라운드 로빈을 이용하는 방법은 한가지 단점을 가지고 있다. 만일 하나의 웹서버가 다운이 되었다면 관리자는 다운된 서버의 IP에 해당하는 www 레코드를 DNS영역에서 삭제를 하게 될 것이다. 그렇게 해서 잘 동작하는 다른 웹서버로만 요청이 가도록 하기 위함인데, 그것이 마음같이 움직여주지는 않는다. 이 DNS서버로부터 www레코드가 2개라는 사실을 응답받은 상대방의 DNS서버는 그 정보를 자신의 서버에 캐쉬한다. 캐쉬의 TTL이 만료될때까지는 새롭게 요청이 오는 것이 아니라 기존 DNS정보를 그대로 사용하기 때문에 현재는 동작하지 못하는 웹서버로 계속해서 클라이언트들의 요청이 올 수도 있다는 것을 의미한다. www 레코드의 TTL을 “0”으로 만들어 주면 문제는 줄어들지만, 몇몇 ISP의 DNS서버들이 캐쉬를 임의로 길게 설정하여 사용하는 경우가 있기 때문에 그 동안에는 현재 동작하지 못한 웹서버의 IP를 담고 있는DNS로부터 웹서버의 IP주소를 얻은 웹클라이언트들은 웹서버에 접근할 수 없게 된다.

이것은 어디까지나 문제가 되는 상황을 가정했을때의 상황이고 보통의 경우에는 큰 탈없이 운영할 수가 있다. 한번쯤 고려해 볼 만한 방법이다. 그러나 회사가 인터넷쇼핑몰 등을 운영하는 것으로서 수익을 얻고 있는 경우라면 이러한 방법을 써서는 불안하다. 웹서버가 몇시간 다운 되는 상황이 생기면 그것은 바로 회사의 금전적인 손해로 이어지기 때문에 심각한 문제가 될 수도 있기 때문이다. 이럴 경우는 NLBS (Network Load Balancing Service), L4스위치를 이용한 로드밸런싱을 구현하는 것이 올바른 방법이라 할 것이다.

5-6-2. DNS서버 보안의 기본

여러분의 네트워크를 누군가가 공격할 준비를 하고 있다고 가정하자. 공격자는 어떤 작업을 먼저 해야 할까? 네트워크에 어떤 컴퓨터들이 있는지를 파악하는 것은 아주 기본적인 작업이 된다. DNS서버는 네트워크에 존재하는 컴퓨터들의 각각의 역할과 IP Address를 가지고 있어서 사내의 컴퓨터들의 역할을 짐작할 수 있게 해 주기 때문이다. DNS서버는 기본적으로 이러한 위험에 노출되어 있다. Nslookup을 통한 테스트결과를 설명과 함께 기록하였다.

이 “영역전송허용”의 기본값은 ‘아무서버로’로 되어 있다. 이것은 주DNS서버와 보조DNS서버간의 영역전송을 가능하게 만들어 주는데, 보조DNS서버가 없다면 아예 해제를 할 일이고 만일 보조DNS서버가 있다면 특별히 보조DNS서버의 IP Address를 기록하여 영역전송이 가능하도록 해 주어야 한다.

5-6-3. DNS서버의 백업파일로부터 복구

DNS서버를 관리할 때는 DNS관리메뉴를 통해서 GUI환경에서 관리되지만 이것은 실제로는 파일단위로 동작한다. %systemroot% (일반적으로는 winnt 폴더를 가리킨다.)아래의 system32\dns 폴더를 확인하면 DNS관리콘솔을 통해서 추가한 관리영역에 해당하는 DNS파일을 확인할 수 있다. 이 파일만 백업하여 유지하고 있다면 언제든지 관리자는 파일로부터 DNS영역을 복구하는 것이 가능하다.

백업된 파일로부터 DNS영역 설치과정은 다음의 절차를 따른다.

1 단계, 백업받아둔 파일을 %systemroot%\system32\dns 폴더에 저장한다.

2단계, 영역추가과정은 일반적인 방법과 다를바가 없다. 다만, ‘영역파일’선택화면에서 기본설정인 ‘다음 이름으로 새 파일 만들기’대신에 ‘다음 기존 파일 사용’옵션을 선택한다. <그림5-77참고>

5-6-4. DNS서버 캐쉬 삭제하기

DNS서버는 클라이언트의 DNS쿼리를 받은후 상대방 DNS서버로부터 레코드정보를 얻은후 로컬DNS캐쉬를 유지한다. 클라이언트로부터 동일한 레코드에 대한 요청이 들어올 때 캐쉬로부터 응답함으로써 효율성을 높이기 위함인데 가끔은 이런 캐쉬 때문에 말썽이 생길수도 있다. 계속해서 DNS서버가 오동작을 한다라고 생각이 되었다면 그때는 DNS서버의 캐쉬를 삭제해 줄 필요가 있다. DNS관리콘솔에서 서버이름을 클릭하고 마우스 오른쪽 버튼을 누르면 ‘캐시 지우기’를 이용할 수 있다.

5-5-1. DNS Server 모니터링 툴

DNS Server가 시작되어 있는데 제대로 응답을 하지 못하다면, Windows Server 2003 DNS Server가 제공하는 모니터링 툴을 사용하여 상태를 점검해 볼 수 있다. <그림5-72>을 통해서 접근한다.

<그림5-73>의 '테스트종류선택'에서 '이 DNS서버에 대한 단순쿼리'를 선택하고 <지금테스트>버튼을 누르면 클라이언트의 요청에 응답할 수 있는지를 파악할 수 있다. 그림에서는 '성공'이라는 결과를 보여준다. '다른 DNS서버로의 재귀쿼리'를 선택하고 <지금테스트>버튼을 누르면, 해당 DNS Server가 외부로 root name server(그림에서 루트힌트 탭에 리스트된 서버들)로 쿼리를 보낼 수 있는지를 파악할 수 있다. 역시 '성공'이라는 결과를 보여주고 있다.

문제가 발생했다면, ’관리도구à이벤트표시기àDNS Server’ 항목을 통해서 문제점을 볼 수 있다. DNS Server오동작의 상당부분은 DNS Service재시작을 통해서 해결된다. 명령프롬프트를 열고 "net stop dns"를 실행하고,다시 "net start dns"를 입력하면 DNS Server Service를 재시작할 수 있다.

5-5-2. NSLOOKUP

DNS를 진단하는데 있어서 대표적인 유틸리티라고 할 수 있다. NSLOOKUP을 사용하는 방법으로는 크게 2가지를 들 수 있다. Interactive(대화형)와 non-interactive(비대화형)로 나누어 사용해 본다.

5-5-2-1. Non-Interactive

호스트이름이든 IP Address이든 원하는 정보를 그대로 물어보는 가장 간단한 사용법이다. 단순한 정보를 알아보는 데 효과적인 방법이라고 하겠다. 아래의 표에서는 사용방법을 보여주고 있다. 명령프롬프트에서 작업한 내용을 편집하여 옮겼다. 굵게 표기한 부분이 필자가 직접 입력한 부분이고, 나머지는 명령에 따른 결과이다.

5-5-2-2. Interactive

대화형으로 접근하여 보다 자세한 레코드를 요청하고, 어느 서버가 문제가 있는 것인지를 진단해 볼 수 있는 방법이다. 아래의 표를 예제로 설명을 하겠다. 역시 명령프롬프트를 통해서 접근한다. 사용법을 꼭 익혀두자. DNS서버의 문제점을 해결할 때 아주 유용한 유틸리티이다.(참고: 진한색으로 표기된 부분이 직접 입력한 부분이며, 그밖은 명령에 의한 결과값이다. 괄호로 묶인 부분은 필자의 부연설명이다.)

5-5-3. ipconfig/flushdns

Windows 2000은 클라이언트에서도 DNS서버로부터 얻은 호스트이름에 대한 응답을 캐쉬에 저장한다. 간혹 이것 때문에 문제를 일으킬 수도 있다. 잘못된 정보를 제공받은 클라이언트가 DNS서버에서 레코드가 바뀌었음에도 불구하고 계속해서 캐쉬로부터 잘못된 정보를 사용하게 됨으로써 정상적인 이름풀이를 하지 못하는 상황이 있다. 이런 경우 클라이언트의 cache를 비워주는 명령어를 사용하면 된다. 아래의 표를 참고하자.

5-4-1. DNS Zone Transfer

앞에서 DNS서버 셋업에 관련된 작업을 다루어 보았다. 하나의 DNS Server를 가지고 있는 회사가 있었는데 만일 그 서버에 이상이 생겼다면 어떻게 될까? 당연히 외부에서의 접근도, 내부에서 외부로의 연결도 하지 못하게 될 것이다. 또, 조직이 아주 커서 하나의 DNS Server로써 모든 클라이언트의 요청을 효율적으로 처리하기가 어려운 상황이 되었다면 어떻게 해야 할까? 당연히 결론은 "추가 DNS Server"를 설치함으로써 DNS서버 이중화를 고려해야 할 것이다. 하지만, 한가지 고려되어야 할 점은 그 추가 DNS Server는 반드시 첫 번째 DNS Server와 동일한 레코드를 가지고 있어야 하다는 것이다. 그래야만 DNS 클라이언트의 요청을 각각의 DNS서버가 처리하더라도 클라이언트는 동일한 응답을 받을 수 있을 것이기 때문이다.

그렇기 때문에, 회사에서 백업을 고려하여 위해서 추가 DNS서버를 셋업하는 것은 첫 번째 DNS 서버의 설치와는 다르다. 첫번째 DNS서버가 가지고 있던 원본을 복제하는 작업을 해야 하고, 그런 이유로 당연히 첫 번째 서버가 정상적으로 동작하고 있는 상태에서 추가할 수 있다. 이때 백업서버를 가리켜서 Secondary DNS Server라고 부르고, 그 서버가 가지고 있는 도메인영역을 Secondary Zone(보조영역)이라고 부른다.

5-4-1-1. Secondary DNS Server 설치

예제에서는 REDAPPLE라는 이름의 서버에 DNS Service를 추가하고, secure.pe.kr 도메인을 관리하는 Secondary DNS Server를 구성하고자 한다. 이 과정이 성공적으로 진행되기 위해서는 원본을 가지고 있는 DNS Server에서는 Zone database를 전송해 줄 수 있도록 보안설정이 되어 있어야 한다. <그림5-67>의 Zone등록정보를 통해서 확인할 수 있다. 그림에서는 192.168.0.47 IP주소를 가진 DNS서버에게 영역전송을 허용하도록 설정했다. Secondary DNS서버의 IP주소이다.

준비가 되었으면 이제 Secondary DNS Server를 설치해 보자. 과정은 지난 장에서 소개한 것과 큰 차이가 없으므로 어렵지 않을 것이다.

< 그림5-57. Secondary DNS서버에 DNS Zone 추가 1 >	‘정방향 조회 영역’에서 마우스 오른쪽 클릭하고 ‘새 영역’을 선택한다.
< 그림5-58. Secondary DNS서버에 DNS Zone 추가 2 >	다음 그림에서 "보조영역"을 선택해야 한다. 보조DNS서버를 추가하기 위한 과정이다.
< 그림5-59. Secondary DNS서버에 DNS Zone 추가 3 >	영역이름을 먼저 추가해야 한다. 현재 설치하고 있는 DNS서버가 Primary DNS서버의 DNS 클라이언트로 되어 있다면 <찾아보기>를 통해서 접근할 수도 있다. 별 차이는 없다. 이름항목에 정확히 도메인명을 입력한다.
< 그림5-60. Secondary DNS서버에 DNS Zone 추가 4 >	마스터 DNS서버의 IP를 주어야 한다. 마스터DNS서버는 영역의 원본을 제공해 줄 수 있는 DNS서버를 의미한다. 먼저 설치했던 blueapple.secure.pe.kr의 IP주소를 입력했다.
< 그림5-61. Secondary DNS서버에 DNS Zone 추가 5 >	이제 secondary DNS의 설치가 완료되었다.

다음의 <그림5-62>를 보면, 콘솔 오른쪽에 많은 정보가 전송되어 왔음을 확인할 수 있다. 이제부터 REDAPPLE라는 이름의 DNS서버는 secure.pe.kr 도메인의 Secondary Zone(보조영역)을 가지고 서비스를 할 수 있게 되었다. 

5-4-1-2. Zone Transfer (영역전송)

두번째 DNS서버가 추가되는 과정에서 영역전송이 진행된다. Zone transfer는 엄밀히 따지면 서버대 서버의 작업이 아니다. 서버의 Zone과 Zone간의 작업이라고 하는 편이 정확하겠다. 영역전송과정은 자동으로 일어난다. 이 과정에 대한 설정 역시 DNS서버에서는 하나의 레코드로 처리되고 있다.  "SOA(Start of Authority)"레코드가 바로 그것이다. 

Secondary DNS가 마스터DNS를 통해서 영역전송을 하고자 할 때 처음 요청하는 레코드가 바로 이 SOA레코드이다. <그림5-63>은 마이크로소프트의 네트워크모니터 툴을 사용해서 Zone transfer과정을 캡춰한 내용을 보여준다.

그림에서 하이라이트된 부분이 Secondary DNS Server가 마스터DNS Server에게 SOA레코드를 요청하는 패킷이다. 바로 아래에는 마스터로부터의 응답이 오고 있는 것이 보여진다. Secondary DNS에서 마스터DNS Server로부터 영역전송을 받기 전에 가장 먼저 SOA레코드에 대한 요청이 이루어졌다. SOA레코드에 어떤 정보가 담겨 있는지 확인해본다.<그림5-64>

Secondary DNS Server에서는 SOA레코드를 받아서 "일련번호"정보를 알아야 한다. 그림에서는 일련번호로 '248'라는 숫자를 보여주고 있다. 일련번호가 의미하는 것은 DNS Zone에 대한 변경사항의 번호이다. Zone에서 레코드의 추가, 삭제등의 변경사항이 생길 때마다 일련번호는 1씩 증가한다. Secondary DNS Server는 일련번호를 비교해서 자신이 앞선 전송과정 이후에 바뀐 내용이 있는지 확인할 수가 있게 된다. 예를 들어서 저번 영역전송때 일련번호가 '120'이었다면 이번에는 121부터 248까지 바뀐 레코드에 대한 전송을 요청할 수 있게 된다.

NT4.0의 DNS의 경우는 DNS Zone transfer과정마다 전체 레코드에 대한 복제가 이루어졌다(Full Zone Transfer ; AXFR). 반면에 Windows 2000 DNS는 기본적으로 바뀐 레코드만 복제하는 방법을 사용한다(Incremental Zone Transfer ; IXFR ). 지극히 당연한 것처럼 보이지만, Windows 2000서버에서부터 개선된 점중의 하나이다.

Secondary DNS서버에서는 자동적으로 SOA레코드에 있는 정보중에서 "새로고침간격"마다 마스터DNS Server에 접근하여 변경사항을 확인하게 되는데, 여러분이 직접 현재 상태를 반영시키는 업데이트를 강제로 진행하고 싶다면, 수동으로 처리하는 방법도 있다. <그림5-65>

 < 그림5-65. 수동으로 영역전송 진행시키기 >

Secondary DNS Server를 구성하였다면 클라이언트 컴퓨터의 TCP/IP설정도 조정해야 한다. 아래의 그림처럼 구성되면 Primary DNS가 오프라인 상태라도 정상적인 DNS서비스를 받을 수 있게 된다. 첫 번째 DNS서버가 정상적으로 동작하고 있는 동안에는 보조DNS서버로 요청을 보낼 일이 없다. 어디까지나 백업 차원에서 제공되는 것이다.

위와 같이 구성하면 4장.DHCP 를 설명하면서 언급을 했던 ‘기업 네트워크에서 네트워크 서버 배치시 고려할 사항’중에서 성능,가용성,기능성 측면을 모두 만족하는 서버배치를 하고 이를 구현하는 것이 가능해 진다. 잘 고려해 보자.

5-4-2. SRV Record

처음에 전반적인 개요를 설명할 때 Windows 2000서버 이상의 DNS는 그 기능이 휠씬 확장되었다는 이야기를 했다. 그러면 Windows2000과 DNS가 어떤 관계에 있는지를 알아보겠다. NT4.0때만 하더라도 마이크로소프트 네트워크에서 DNS의 영향은 그다지 크지 않았다. 보통의 경우라면 인터넷에 접근해야 하는 경우에만 사용하는 것이 일반적이었고, 유닉스 네트워크와 혼합된 환경이라면 유닉스기반의 네트워크에 접근하기 위해서 이름서비스를 제공하는 것이 DNS의 주된 기능이었다. 마이크로소프트의 윈도우기반의 네트워크에서는 DNS가 아닌 WINS라고 하는 다른 형태의 이름풀이를 처리하는 서비스가 주된 임무를 수행했다. 하지만, Windows 2000이상의 환경에서는 WINS 가 처리하던 서비스를 이제는 DNS가 처리해야 한다. 당연히 클라이언트는 DNS에게 쿼리를 던져서 원하는 정보를 찾아야 하는 것이다.

마이크로소프트는 기업네트워크를 위해서 "도메인"이라는 이름의 작업그룹을 이용한다. MS가 도메인모델을 통해서 추구하고자 하는 것은 "디렉토리 서비스"를 통하여 도메인내의 모든 사용자들은 최초 한번의 로그온만으로 도메인내의 모든 서버에 접근을 용이하게 하겠다는 것이다. NT4.0에서는 이러한 마이크로소프트의 "도메인"과 DNS상에서의 "도메인"을 별개로 취급했었다. 그래서 회사환경의 "도메인"에 대한 이름풀이 서비스로서 "WINS"라고 부르는 네임서버를 두었고, 인터넷 DNS상의 "도메인"에 대한 이름풀이 서비스로서 "DNS"라는 네임서버를 두고 이원화 되어 있는 구조를 사용했던 것이다. 하지만, Windows 2000부터는 두 도메인을 따로 생각하지 않고 통합시킨 구조를 사용한다.

엄밀히 말하면 통합이라고 표현하기에는 상당한 이해가 필요해진다. 결국 통합되었다는 표현은 다음과 같이 정리한다. 기업내부 네트워크를 구성하기 위한 도메인을 만드는데 있어서, 그 도메인이름을 인터넷상의 DNS Domain Name을 사용하게 되었다. 바로 이름이 통합되었다는 얘기다. 즉, 회사에 존재하는 사용자, 그룹, 컴퓨터 등 모든 정보들은 Active Directory라고 부르는 디렉토리 데이터베이스에 저장하고, 그들을 가지고 있는 서버를 찾는 작업에 있어서 DNS가 서비스를 제공하고 있는 것이다. 결국 DNS가 하는 서비스는 Active Directory위치를 찾아주는 "Locator Service"라고 할 수 있다.

그렇다면 Windows2000에서 지원하는DNS에는 뭔가 큰 변화가 있었을 거라는 짐작이 간다. 하지만 실제로 들여다보면 그다지 큰 변화는 없다. 단지 "SRV"라고 하는 레코드를 지원하고 있다는 것을 알 수 있다. 그 SRV는 이름 그대로 "서비스를 하고 있는 서버"라는 뜻이 된다. <그림5-67>

<그림5-67>에서 _msdcs로 시작하는 도메인이 최초로 Active Directory가 설치된 도메인 컨트롤러가 부팅을 하면서 자동업데이트를 통해 등록한 도메인이다. 그 하위에는 dc, domains, gc, pdc 등의 도메인이 있고, 오른쪽에 보이는 "_ldap"이라는 호스트이름이 "서비스위치"라는 레코드 유형으로 등록되어 있는 것을 볼 수 있다. 그것이 바로 "SRV"라는 레코드이다.(Windows 2000서버를 사용하는 독자는 폴더구조가 약간 다르다는 것을 알 것이다. 큰 차이는 없다) 그림에서 보여지고 있는 정보는 "ldap"서비스를 하는 서버가 "blueapple.windowsnetwork.msft"라는 사실을 알려주고 있다. "ldap"서비스는 사용자 로그온을 처리하는 도메인컨트롤러가 제공하는 서비스이다. 사용자가 로그온을 할 때, 사용자 컴퓨터는 로그온을 받아주는 서버가 누구인지를 알아야만 한다. Windows 2000 기반의 클라이언트는 그 정보를 바로 DNS Server에게 요청을 하게 되는데, 그때 요청은 결국 "나를 인증해 줄 로그온을 받아줄 서버는 누구인가?"라는 요청이 되고, DNS Server는 등록된 레코드중 해당 서비스를 하는 서버로 등록된 레코드를 알려주게 되는 것이다. 이들 레코드에 대한 자세한 정보는 Active Directory를 통해서 공부하도록 한다.

5-4-3. Dynamic Update (동적 업데이트) 사용

Windows2000에서와 마찬가지로 Windows Server 2003 DNS서버도 동적업데이트를 지원한다. 이것은 당연한 결과라고 보여진다. 앞에서 설명한 바와 같이 DNS가 기업 내부네트워크까지 적극적으로 반영하고 있기 때문에 NT4.0에 비해서 상당히 많은 양의 정보를 제공해야만 한다. 이것을 예전 버전처럼 일일이 수동으로 작업을 하다면 상당히 번거로운 작업이된다. 이러한 문제점을 Windows 2003 DNS Server는 dynamic update protocol을 사용함으로써 관리작업을 단순화 시켜 주고 있다. 관리자라면 당연히 사용해야 할 옵션중의 하나이다. 작업에 대한 과정은 이미 앞에서 설명한 바 있다.

5-4-4. DHCP Service와의 연동

만일 동적업데이트 프로토콜을 통해서 등록되는 DNS 클라이언트가 DHCP 클라이언트라면 어떻게 될까? DHCP 클라이언트는 매번 다른 IP Address를 사용할 수도 있는 유동적인 시스템이다. 이에 DNS서버는 이러한 DHCP 클라이언트에게 IP를 제공하는 역할을 하고 있는 DHCP Server와 연동을 시키는 방법을 사용한다. 탁월한 방법입니다

아래의 <그림5-68>를 참조한다.

5-4-5. Active Directory 통합영역 사용

DNS를 설치하고, 관리할 도메인에 대한 관리영역(zone)을 추가하다 보면 영역의 종류를 결정하는 항목이 나온다. 아래의<그림5-70>을 참고한다.

'Active Directory에 영역저장'이란 말 그대로 도메인 컨트롤러가 가지고 있는 Active Directory에 DNS 영역 데이터베이스를 통합하겠다는 뜻이다. 그렇게 했을 때 얻는 이점이 무엇이 있을지 생각해 본다.

앞서서 Secondary DNS Server의 필요성과 설정방법에 대해 설명하였다. 분명히 백업의 측면을 고려한 설정이긴 하지만 부족한 점이 있다. Primary DNS Server는 DNS영역 데이터베이스의 원본을 가지고 있고, Secondary DNS Server는 복사본을 가지고 있다. 실제로 DNS영역 데이터베이스 변경에 영향을 줄 수 있는 서버는 오로지 Primary DNS Server일 뿐이다. Secondary DNS Server는 수동적으로 Primary server에 변경이 있으면 그 내용을 복제하는 역할을 하고 있을 뿐이다. 만일 Primary DNS Server가 문제가 있어서 다운이 되었다면, Secondary DNS Server는 DNS 클라이언트에게는 정상적인 서비스를 할 수 있겠지만, DNS 영역 데이터베이스의 변경작업은 더 이상 할 수가 없다. 다시 말하면 새로운 레코드를 추가하거나, 삭제, 레코드 수정 등의 작업은 하지 못하다는 뜻이다.

이러한 문제를 해결할 수 있는 방법이 있다. 바로 'Active Directory통합영역'을 사용하는 방법이다. 비록 Active Directory를 가지고 있는 도메인컨트롤러에서만 구현되는 방법이긴 하지만, 어떤 DNS Server든지 레코드 변경작업이 가능하다는 장점이 있다. 추가로 DNS영역전송도 더 이상 필요가 없다. 도메인컨트롤러간의 Active Directory 복제 과정에 DNS 복제프로세스가 통합되기 때문에 보다 유연한 Active Directory복제 토폴러지의 장점을 이용할 수 있게 되는 것이다. 또 한가지 장점이라면 Active Directory통합영역을 사용하면 승인받은 클라이언트만 DNS에 접근하게 만드는 ‘보안된 업데이트’ 기능도 제공하기 때문에 보안의 측면에서도 보다 효과적인 방법이다.

'Active Directory통합영역'으로의 변경작업은 DNS 콘솔의 해당 Zone의 등록정보를 통해서 수정할 수 있다. <그림5-71> 'Active Directory통합영역'을 사용하면 동적업데이트 옵션에서 "보안된 항목만"을 사용할 수 있게 된다.

지금까지 Windows Server 2003의 DNS 를 기준으로 몇가지 기능과 관리방법에 대해서 설명하였다. 다음 장에서는 마지막으로 DNS Server의 문제점을 해결할 수 있는 진단도구와 해결방법에 대해서 알아보겠다.  

5-3-1. DNS Service 설치

이번 장에서는 한글 Windows Server 2003을 기준으로 DNS를 설치하고 구성하는 방법에 대해서 설명한다. 앞에서 살펴보았듯이, DNS를 사용하기 위해서는 먼저 우리가 원하는 도메인을 등록해야 한다. 도메인 관리는 InterNIC에서 담당하고 있다. 국외 도메인의 경우(.com .net .org등)는 ICANN (The Internet Corporation for Assigned Names and Numbers / http://www.icann.org )에서 등록을 할 수 있고, 국내의 도메인의 경우(.co.kr .pe.kr등)는 KRNIC (Korea Network Information Center / http://www.nic.or.kr )에서 등록할 수 있다. 하지만, 일반적으로는 직접 등록을 하지 않고, 등록대행기관을 통해서 하고 있다. 특히 국외 도메인의 경우는 기타 제반서류가 영문으로 처리가 되어야 하므로 국내의 도메인등록 대행기관을 통해서 하는 것이 훨씬 수월하다. 국내 도메인등록 대행기관이라면 WHOIS, iNames, NETPIA 등 많은 업체가 있다. 일반적으로 도메인을 등록할 때는 아래의 몇가지 정보를 제공해 주어야 한다.

  ① 회사 혹은 개인의 이름

  ② 주민등록번호 혹은 사업자 등록번호

  ③ 주소

  ④ 관리자

  ⑤ Name Server (= DNS Server)

이 장에서 DNS설치의 예제로 사용할 도메인은 필자가 등록한 Secure.pe.kr 이라는 도메인이다. 다음 페이지에 캡춰해 놓은 그림을 살펴본다.

 많은 도메인 등록사이트를 통해서 도메인등록 정보를 알아볼 수 있다. 위의 그림은 www.inames.co.kr를 통해서 조회한 화면이다. <그림5-12>에서 중요한 정보는 secure.pe.kr를 관리하는 네임서버(DNS Server)의 정보이다. 그림에서 볼 수 있듯이 secure.pe.kr 도메인은 ns2.secure.pe.kr이라는 FQDN을 가진 1차 네임서버에 의해 관리되고 있으며 IP Address는 211.234.93.250이다. 2차 네임서버는 ns.feelanet.com으로 되어 있는 것을 확인할 수 있다. 이제 DNS서버를 설치할 수 있는 기본준비가 되었다. 일반적인 DNS설치과정은 아래의 순서를 따른다. 자세한 사항은 설치하면서 하나씩 알아가도록 하자.

위에서 secure.pe.kr의 네임서버로 등록한 서버의 IP Addres는 211.234.93.250이다. 이 서버가 DNS 서비스를 할 수 있도록 하기 위해서 먼저 DNS Service를 추가해 보자. Windows Server 2003에서 서비스라고 하는 것은 백그라운드에서 동작하도록 만들어진 네트워크 어플리케이션을 말한다. 오피스와 같은 프로그램을 포그라운드 어플리케이션이라고 하는 것과 비교하면 이해를 할 수 있을 것이다. ‘시작à제어판à프로그램추가/제거àWindows구성요소’를 통해서 아래의 그림으로 접근할 수 있다. 설치중 Windows Server 2003 원본CD가 필요하다.<그림5-14>

DNS 를 설치하면, 관리도구에 DNS관리콘솔이 등록된다. 실행해 본다.<그림5-15>

처음 만나게 되는 그림이다.<그림5-16> DNS라는 항목아래에 Blueapple이라는 이름의 서버가 있고, 그 아래에는 정방향조회영역(Forward Lookup Zone)과 역방향조회영역(Reverse Lookup Zone)이라는 항목을 볼 수 있다.

DNS에서의 영역(Zone)은 DNS Server가 관리하는 하나의 관리단위이다. 하나의 DNS서버는 여러개의 도메인을 관리 할 수 있는데, 그 때 하나하나 도메인들을 가리켜서 Zone이라고 부른다. 알고 넘어가야 할 것이 있다. Zone이라는 것은 알겠는데 그렇다면 정뱡향조회, 역방향조회 라는 것이 무얼 말하는가? 원어로는 Forward Lookup, Reverse Lookup이라고 되어 있다. 필자도 개인적으로는 영어를 잘하지도 못하고 좋아서 쓰지는 않는다. 하지만 인터넷 관련된(물론 컴퓨터 자체가 그렇지만) 거의 모든 용어가 영어로 되어 있다. 물론 번역을 해서 표기를 하고 있지만, 가급적이면 본래 용어로 기억을 하도록 하자. 그편이 정신건강에 도움이 된다.

DNS의 기본기능을 생각해 보자. 앞장에서 설명한 대로 DNS가 하는 일의 가장 주된 기능이라면  www.secure.pe.kr등의 hostname을 IP Address로 풀이하는 일이었다. Forward Lookup Zone은 그러한 기능을 제공하기 위한 영역이다.

그렇다면 Reverse Lookup Zone은 무엇일까? 만일 우리가 이번에는 IP Address를 가지고 거꾸로 Hostname을 알고 싶다고 하면 어떻게 해야 할까?  물론 DNS Server가 알아서 해주길 바라겠지만 컴퓨터는 우리가 제공하지 않은 정보까지 스스로 알진 못한다. 누군가 Hostname에 대한 IP Address를 묻는 것 대신에 IP Address를 통해서 Hostname을 알고자 했을 때(Inverse Query) DNS서버가 그 정보를 제공하기 위해서는 해당 정보를 가지고 있어야 한다. DNS서버는 Reverse Lookup Zone에 거꾸로 물어보기(Inverse Query)에 응답하기 위한 레코드를 저장하게 된다.

관리하고자 하는 도메인을 추가한다. 예제에서는 위에서 등록했던 secure.pe.kr이라는 도메인을 등록해 보도록 하겠다. <그림5-17>

< 그림5-17. Zone 추가 >

영역을 선택하는 그림이 나온다.<그림5-18> 기본설정은 ‘주영역’으로 되어 있다. 기본설정을 그대로 두도록 한다.

 < 그림5-18. DNS 영역형식 설정 >

다음에 영역이름을 입력해 준다<그림5-19>. secure.pe.kr이라고 입력하였다. 처음 DNS를 공부하는 사람들이 도메인이름과 호스트이름을 구별하지 못해 어려움을 느끼는 경우가 많다. 도메인이름은 논리적인 그룹을 표기하는 것이고, 호스트이름은 실제 서버에 주어진 컴퓨터의 이름이다. 명확히 정리를 하고 넘어갈 필요가 있다. 예제에서 secure.pe.kr도메인을 관리하는 서버의 이름은 blueapple.secure.pe.kr이지만, 도메인의 이름은 'secure.pe.kr"이다. 만일 이 항목에 blueapple.secure.pe.kr이라고 입력했다면, 그것은 secure.pe.kr의 하위도메인인 blueapple.secure.pe.kr 이라는 별도의 도메인으로서 인식된다. 여기서 www라는 레코드가 만들어진다면 그 서버의 FQDN은 www.blueapple.secure.pe.kr이 될 것이다.

DNS 데이터베이스는 파일형태로 저장된다. <그림5-20>에서는 파일이름을 결정하는 항목이다. 기본적으로 도메인이름.dns라는 파일로서 생성이 된다. 좋은 설정이다. 바꾸어도 되겠지만, 굳이 그럴 이유는 없다. 설치가 끝난다음, %systemroot%\system32\dns 폴더를 검색해 본다. "도메인이름.dns"라는 파일을 찾을 수 있을 것이다. 메모장을 통해서 열어볼 수 있는 텍스트파일이다.

[다음]을 누르면 동적 업데이트를 설정하는 화면이 나온다.(그림5-21) 기본설정은 ‘동적 업데이트 허용 안 함’이다. 외부로 노출되는 DNS서버라면 기본설정을 그대로 두는 것이 바람직하다. 뒤에서 다루어지는 동적업데이트는 아주 유용한 설정이긴 하지만 경우에 따라 보안상 문제가 될 소지를 담고 있기 때문이다.

자. 이제 영역이 만들어졌다. <그림5-23>에서 만들어진 secure.pe.kr 영역을 확인할 수 있다. 콘솔 오른쪽에는2개의 레코드가 등록되어 있는 것이 보인다.

이어서 Reverse Lookup Zone에 대해서도 구성을 해 본다. <그림5-24>

위에서 설명한 바와 같이 이번에는 문자도메인이 아니다. IP Address로 구성된 도메인을 만들어야 한다. 예제에서 DNS서버의 IP Address인 192.168.0.16은 “C"class에 해당하는 IP Address이므로 192.168.0까지가 네트워크ID이다. 네트워크 ID부분만을 입력해 준다. 아래부분에 있는 "역방향 조회 영역 이름"을 살펴보면, "0.168.192.in-addr.arpa"라고 표기되는 것을 확인할 수 있다. 그것이 바로 생성될 영역의 이름이다.

< 그림5-25. Reverse Lookup Zone 등록 >

☞ Reverse Lookup Zone / Inverse Query   이 영역에 대해서는 이미 약속이 되어 있다. DNS라는 것이 마이크로소프트만이 사용하는 것이 아닌 인터넷 표준이기 때문에 모든 DNS간에는 호환성이 유지되어야만 한다. 그래서 IP주소를 이용해서 호스트이름을 확인하는 inverse query(역질의)를 발송할 때, "in-addr.arpa"도메인명을 이용하도록 약속된 것이다. 만일 외부의 DNS Server가 218.55.9.26를 사용하는 서버의 hostname을 요청했다면 실제 요청은 "26.9.55.218.in-addr.arpa" 로서 날아오게 된다. 아래의 그림은 DNS Server에서 Inverse Query를 Windows2000이 제공하는 Network Monitor Tool을 사용하여 캡쳐한 그림이다. 진한부분을 보면 요청하는 이름을 확인할 수 있다. 도메인명은 "9.55.218.in-addr.arpa"가 되고, "26"은 forward lookup zone의 레코드 형태로 하나의 호스트이름에 해당되는 내용이다. <그림5-26, Network Monitor를 통해서 본 Inverse Query>

다음 과정은 역시 Reverse Lookup Zone에 대한 데이터베이스를 저장할 파일이름을 결정해 준다.

 < 그림5-27. Reverse Lookup Zone Database File 결정 >

Reverse Lookup Zone설치를 하고 나면 <그림5-28>에서 보는 바와 같이 blueapple이라는 DNS Server는 2개의 Zone을 관리하는 DNS Server로서 설치가 되었다.

 < 그림5-28. DNS Server 관리콘솔 >

지금까지 DNS Service를 설치하고, DNS Server가 관리할 Domain을 구성하는 작업을 해 보았다. 막상 하고 나면 뭐가 이렇게 쉽나? 하는 생각이 든다.( 돌 날아오는 소리가 들리는 것 같다 ^^;) 마이크로소프트의 Windows기반의 OS의 가장 큰 장점은 사용자 인터페이스가 쉽다는데 있다. 관리자 입장에서도 마찬가지이다. 개념을 이해하는 과정이 조금 까다로울 뿐이지 막상 관리작업은 너무나 쉽다.

5-3-2. DNS 레코드 등록

DNS의 기본구성을 했는데 그 다음엔 무엇을 해야 할까? 한가지만 생각해 보자. 지금 DNS서버를 구성하고 관리영역(도메인)을 추가하는 작업을 왜 한 것일까? 누구를 위해서?? 지금까지의 용도로 본다면 원격지의 클라이언트가 다른 DNS서버를 통해서 secure.pe.kr도메인에 속해있는 서버들의 IP Address를 알 수 있도록 하기 위한 구성이었음을 알 수 있을 것이다. 그렇다면 당연히 추가작업을 생각할 수 있다. 바로 웹서버, 메일서버, FTP서버 등 실제 외부에서 접근해야할 서버들을 도메인에 추가하는 작업을 해야 할 것이다. 도메인에 등록되는 이들 서버들의 정보를 "레코드(record)"라고 부른다.

결국 해야할 작업은 관리할 도메인에서 "레코드"를 추가하는 작업을 해야 하다는 얘긴데, 여기에는 중요한 원칙이 한가지 들어있다. 아래의 그림을 보고 설명하도록 하겠다.

<그림5-29>에서는 wssong@secure.pe.kr 이라는 E-mail을 쓰는 사용자가 dcpromo@mscs.co.kr 에게 메일을 전송하는 과정에서 DNS Server가 어떻게 동작하는지를 보여주고 있다. wssong이라는 사용자로부터 메일전송요청을 받은 secure.pe.kr의 메일서버는 mscs.co.kr의 메일서버의 IP를 알아야만 메일을 전송할 수 있다. 이 때 메일서버의 IP주소를 알아내기 위해서 DNS 클라이언트로서 동작한다. 자신의 DNS Server로 설정된 DNS Server에게 yahoo.co.kr의 메일서버의 IP를 요청하게 되고, 요청을 받은 DNS서버는 iterative query를 통하여 메일서버의 IP를 알아오게 된다. 이 과정이 선행되지 않으면 메일서버들끼리 메일전송은 있을 수 없는 일이다.

이때 DNS Server가 상대방 mail server의 IP정보를 가지고 있는 DNS Server에게 IP요청을 할 때 어떤 형식으로 요청을 해야 할까? 무작정 "당신 회사의 메일서버가 누구인지 가르쳐 주세요"라고 우리가 쓰는 말처럼 물어볼 수는 없는 노릇이다. 역시 DNS Server간에 약속된 어떤 표기법이 필요하다는 것이다. 이러한 이유로 DNS Server에 등록되는 하나하나의 레코드 마다 별도의 레코드 유형을 정의해 둠으로써 호환성을 이루어 내고 있는 것이다. 그래서 메일서버는 메일서버(MX)로서, Name Server는 Name Server(NS)로서 각각 하는 역할에 맞는 레코드 유형으로 등록되어 있어야 한다. <그림5-30. DNS Record Type참고>

DNS서버가 가지고 있는 레코드는 크게 두가지 종류로 구분해 볼 수 있다. 첫번째는 “위치”이고, 두번째는 “역할”이다. 잘 이해하면 DNS의 레코드를 명확히 하는데 도움이 된다.

첫번째의 “위치”라고 하는 것은 클라이언트가 호스트 이름에 해당하는 컴퓨터가 어디에 있는지, 즉 무슨 IP Address를 사용하고 있는지를 물어볼 때의 응답을 의미한다. 예를 들어서 클라이언트가 www.secure.pe.kr 의 IP Address가 무엇인지를 묻는 경우에 해당한다. 이 요청을 받은 DNS서버는 www.secure.pe.kr 서버의 IP Address가 무엇인지를 응답함으로써 위치정보를 가르쳐 주게 된다. 이것에 해당하는 레코드가 바로 DNS서버의 “A(Address)레코드”이다.

두번째의 “역할”이라는 것은 다른 의미를 가진다. 클라이언트가 호스트이름을 내밀고 위치를 묻는것과는 달리 클라이언트는 컴퓨터의 이름을 모르는 상황이다. 이를 테면, “내가 메일을 보내고 싶은데 메일서버의 역할을 하고 있는 컴퓨터의 이름은 뭐니?” 라는 형태이다. 또는 “내가 도메인 컨트롤러를 찾고자 하는데 도메인 컨트롤러로서 서비스를 하는 컴퓨터의 이름은 뭐니?”라는 형태의 요청을 말한다. 첫번째의 “위치”를 묻는 것과는 조금 다르게 생각될 것이다.

이러한 요청을 받은 DNS서버는 다음과 같이 응답해야 한다. 예를 들어서 secure.pe.kr의 메일서버를 찾는 요청이 들어왔다면 DNS서버는 “Secure.pe.kr도메인에서 메일서버의 역할을 수행하는 서버는 mail.secure.pe.kr이야”라고 응답을 할 것이다. 그렇다면 클라이언트가 이 정보만으로 메일을 주고 받을 수 있을까? 당연히 뭔가 부족함을 느낄 것이다. 클라이언트가 궁극적으로 필요한 것은 메일서버의 IP Address이다. Mail.secure.pe.kr라는 메일서버의 이름만으로는 메일을 주고 받을 수가 없다는 것이다. 그렇기 때문에 “역할”을 묻는 DNS쿼리의 경우에 대한 응답은 항상 이중으로 구성된다. “메일서버로 동작하는 서버는 mail.secure.pe.kr이고(MX레코드), mail.secure.pe.kr은 192.168.0.15라는 위치에 있어(A레코드)”라고 응답해야 함을 의미한다. DNS관리자는 이러한 것들을 잘 고려하고 실수를 하지 말아야 한다. 메일서버를 DNS서버에 등록하기 위해 MX레코드를 추가해 주고 나서 만일 해당 메일서버의 A레코드는 만들지 않게 되면 메일서비스는 동작하지 못하게 되는 것이다. 상대방 입장에서 보자면 메일서버가 mail.secure.pe.kr라는 것은 알았지만 mail.secure.pe.kr가 어디에 있는지, 즉 어떤 IP Address를 사용하는지를 알수 없어서 통신이 불가능하기 때문이다.

DNS Server를 통해서 이름풀이가 되어야 할 호스트를 추가한다<그림5-31>. 호스트를 추가할 도메인 영역을 통해서 접근한다. 여러 가지 메뉴가 나온다. 어떤 레코드를 추가할 것인지에 따라 각각 다른 메뉴를 사용한다.

<그림5-32>의 <이름>란에 호스트이름을 입력한다. 그림에서는 'bluexp'라고 입력하였다. 그렇다면 이 호스트의 FQDN은 'bluexp.secure.pe.kr'이 된다. IP주소 아래에 "연결된 포인터(PTR)레코드 만들기"라는 체크박스가 있다. 기본적으로는 비워둔 상태이다. 체크를 하게 되면 호스트 레코드를 등록을 작업 한번만으로 동시에 Reverse Lookup Zone에 PTR 레코드까지 생성해 주는 옵션이다. 이 작업이 제대로 되기 위해서는 먼저 reverse Lookup Zone이 구성되어 있어야 한다. 그렇지 않다면 나중에 추가해 주면 된다.

작업을 마치면 DNS관리콘솔의 오른쪽에 bluexp라는 호스트 레코드가 추가된 것을 확인할 수 있다.

다음에 이번에는 메일서버를 등록해 보자. DNS관리콘솔의 관리영역인 Secure.pe.kr에서 마우스 오른쪽 클릭을 이용하여 “새 메일 교환기(MX)”를 선택하여 추가한다.

 <그림5-35>에서는 메일서버를 위한 레코드를 추가하고 있다. <찾아보기>버튼을 눌러서 메일서버의 호스트이름을 찾는다. 메일서버 우선순위는 '10'이 기본값이다. 메일서버가 여러대 있다면 우선순위를 별도로 할당해 줄 수 있다. 숫자가 낮을수록 우선순위는 높다. '호스트 또는 도메인'항목은 공백으로 두었다. 예제에서 사용하게 될 메일주소는 username@secure.pe.kr형태이다. 만일 username@mail.secure.pe.kr등의 형태를 사용하고 싶다면, 공백 대신에 'mail'이라고 기록해 준다. 비워둔 상태를 사용하는 것이 일반적이다.

< 그림5-36. CNAME 레코드 추가 >

<그림5-36>에서는 많이 사용하는 레코드중의 하나인 CNAME을 등록하는 작업을 보여주고 있다. 일반적으로 흔히 볼 수 있는 www, ftp, pop3, mail 등의 이름들이 CNAME을 사용한다. 한 컴퓨터가 orange.secure.pe.kr이라는 호스트이름을 이미 가지고 있다면, 그 서버가 추가로 web, ftp등 여러서비스를 하고 있을 때, 각각 호스트이름을 등록하는 것 대신에 별칭을 사용하는 것이 좋다.

CNAME 레코드도 위에서 설명한 “역할”에 해당하는 레코드이므로 독립적으로는 동작할 수 없다. 반드시 A레코드와 한쌍으로 이루어져 있어야 한다. <그림5-37>을 보면 별칭으로 www를 사용하고 있고, 별칭에 해당하는 실제 호스트의 이름은 blueapple.secure.pe.kr 라고 등록을 하고있다. 이 경우 만일 클라이언트가 “www.secure.pe.kr 의 IP Address를 가르쳐 줘”라고 묻는다면 DNS서버는 “www.secure.pe.kr 즉 secure.pe.kr의 웹서버는 blueapple.secure.pe.kr이고 blueapple.secure.pe.kr의 IP Address는 218.55.9.26이야”라고 응답해 주어야 한다. 아래의 <그림5-38>에서 www.secure.pe.kr에 ping을 보냈지만, 실제로 응답하는 서버는 blueapple.secure.pe.kr임을 주목하자.

5-3-3. DNS 동적 업데이트(Dynamic Update)

작업을 하면서 답답함을 느낄 것이다. 회사에 등록해야 할 서버가 100대라면 100번을 반복해야 하는 것인가? 이런 번거로움을 Windows DNS Server는 간단히 해결해 주고 있다. 바로 동적 업데이트 기능이다. Windows DNS는 Dynamic Update Protocol로써 레코드를 자동으로 업데이트하는 기능인 Dynamic DNS (DDNS)를 제공한다. 설정방법은 간단한다. 아래의 <그림5-39,40>을 참고하면, 메뉴를 확인할 수 있다. 동적업데이트 옵션을 "보안되지 않음 및 보안됨"으로 바꿔주면 동적업데이트가 진행된다. 관리자의 작업이 상당부분 경감되게 될 수 있다.

DNS서버에서 동적업데이트를 허용하면 DNS클라이언트는 자동적으로 DNS서버에게 자신의 정보를 보내서 등록하는 작업이 이루어진다. 클라이언트 컴퓨터의 TCP/IP설정에서 DNS서버의 IP가 이 DNS서버로 설정되어야 함은 당연한 일이다.

지금까지 도메인을 등록하고, 설치하고, Zone을 구성하는 방법에 대해서 알아보았다. 대부분의 기업환경에서는 위와 같은 설정으로 DNS를 마무리 할 수 있다. 하지만, 보다 복잡한 기업환경에서는 DNS를 확장시키는 방법을 사용할 수 있다. 자신의 하위도메인을 등록해서 도메인을 확장시켜서 사용할 수도 있다. 추가로 다루어 보자. 지금까지의 설명이 조금 벅차게 생각되는 독자는 아래의 부분은 일단 건너뛰어도 좋다. 앞의 내용을 이해하고 나서 다시 다음 내용을 공부하자. DNS에 대해서만 다룬 서적도 수백페이지 이상 되는 책이 많을 정도로 DNS는 많은 내용을 담고 있다. 급하게 생각하지 말고 기초부터 튼튼히 하자는 얘기다.

5-3-4. 하위 도메인(Subdomain)

하위도메인이 무엇을 의미하는지 이해를 돕기 위해서 아래의 <그림5-41>을 참고하자. 

<그림5-41>에서는 youngjin.com도메인을 예제로 DNS구조를 간소화시켜 놓았다. 왼쪽편이 DNS부분이고, 오른쪽편이 해당 도메인에 등록된 레코드들이다. 그림이 다소 복잡해보이지만 차근차근 접근해 보자. youngjin.com도메인은 com.도메인으로부터 youngjin이라는 이름을 등록받았고, 자기 자신은 Seoul, japan, shopping이라는 하위도메인들을 등록해 주었다. 이들 세 도메인들은 youngjin.com의 하위도메인들이다. shopping도메인 입장에서의 도메인이름은 "shopping.youngjin.com"이 된다. 그 도메인에서 'www'라는 이름의 웹서버를 가지고 있다면 오른쪽에 표기된대로 웹서버의 FQDN은 www.shopping.youngjin.com이 되어야 한다.

이들 하위도메인을 등록하는데, "com."이나, ".(root)"같은 상위도메인과 연관성이 있는가? 전혀 그럴필요가 없다. 하위도메인을 등록하는 작업은 오로지 youngjin.com을 관리하는 DNS Server에서만 생성되면 그만인 작업이다. 앞 장에서 보았던 DNS Process를 이해했다면 알 수 있는 사실이었다.

그렇다면 이러한 하위도메인은 언제 사용하게 될까? 회사가 각각 별도의 관리가 이루어지는 여러개의 관계회사를 가지고 있다고 가정했을 때, 하나의 도메인이름을 쓰는 것보다 별도의 도메인이름을 사용함으로써 대외적으로 명확한 구분을 지어주고 싶을 수도 있을 것이다. 하지만 또 한편으로는 처음에 등록한 회사를 대표하는 도메인이 있을 것이고 그 도메인의 하부로 관계회사의 이름을 연장시킴으로써 회사의 실제 조직구조에 맞게 도메인을 배치하고 외부적으로 통일된 이름체계를 유지하는 것도 가능하다. 이러한 도메인을 서브도메인이라고 부른다.

또한 Active Directory 도메인에서 DNS의 도메인구조를 그대로 따르게 되면서 서브도메인은 Active Directory Multi domain환경을 구축할 때 반드시 필요한 하나의 기능이 되었다.

하위도메인의 필요성에 대해서 이야기했다. 그렇다면 하위도메인은 어떻게 만드는 것일까? 여기에는 관리방법에 따라 두가지 방법이 제공된다. secure.pe.kr도메인이 본사, jeju.secure.pe.kr이 지사라는 가정을 해 보겠다. 본사에서 지사의 도메인까지 관리를 해 주는 방법이 있겠고, 지사 역시 별도의 IT조직이 있기 때문에 도메인에 대한 독자적인 관리권한을 가지고 별도의 DNS Server를 관리하는 경우도 있을 것이다.

5-3-5-1. 하위 도메인(Subdomain) 등록

< 그림5-42. 새 도메인 추가 >	Secure.pe.kr 관리영역에서 마우스 오른쪽 클릭하여 ‘새 도메인’을 선택한다.
< 그림5-43. 새 도메인 추가 >	‘새 도메인’화면에 생성하고 싶은 도메인명을 입력한다. 예제에서는 'jeju'를 입력하였다.
< 그림5-44. 하위도메인에 새 호스트 추가 1 >
< 그림5-45. 하위도메인에 새 호스트 추가 2 >	Secure.pe.kr 영역 밑에 jeju 폴더가 생긴 것을 볼 수 있다. 이것이 서브도메인이다. 서브도메인의 이름은 jeju.secure.pe.kr 이 된다. 이 서브도메인에 새로운 호스트를 추가하기 위해 마우스 오른쪽 클릭하고 ‘새 호스트’를 선택했다. 위치에 있는 항목을 눈여겨 보라. jeju.secure.pe.kr 이라는 서브도메인이 보일 것이다. 여기서 www라는 호스트이름을 생성하고 있다.
< 그림5-46. 하위 도메인에 새 호스트가 추가된 화면 >	www호스트가 생성되었다. 이 호스트의  FQDN은 www.jeju.secure.pe.kr이 된다.
< 그림5-47. 하위 도메인의 레코드 Ping 테스트 >	명령프롬프트를 열고 ping 테스트를 해 보았다. 제대로 응답이 오는 것을 확인할 수 있다.

5-3-5-2. 하위 도메인(Subdomain) 위임(delegation)

두 번째 방법은 별도의 DNS Server를 통해서 하위도메인을 관리하는 방법이 있다. 이때 상위도메인의 DNS Server에서는 하위의 도메인을 생성하고, 그 도메인을 관리할 별도의 DNS Server를 지정해 주어야 한다. 이 과정을 가리켜서 도메인 위임(delegation)이라고 한다. 관리권한을 다른 DNS서버에게 위임한다는 뜻이다.

< 그림5-48. 하위 도메인의 위임(delegation) 작업 1 >	이번에는 새 도메인을 만들긴 하지만 위임을 시킬 것이다. 상위도메인에 해당하는 Secure.pe.kr을 마우스 오른쪽 클릭하고 ‘새 위임’을 선택한다.
< 그림5-49. 하위 도메인의 위임(delegation) 작업 2 >	새 위임 마법사가 시작된다.
< 그림5-50. 하위 도메인의 위임(delegation) 작업 3 >	위임할 도메인 이름을 입력하면, 정식도메인이름 부분이 바뀐다. 'Japan'이라고 입력했더니 <정규화된 도메인 이름(FQDN)>은 jeju.secure.pe.kr이 되었다.
< 그림5-51. 하위 도메인의 위임(delegation) 작업 4 >	서브도메인인 jeju.secure.pe.kr 의 관리를 할 이름서버(NS)를 지정해 주어야 한다. 위에서 ‘새 도메인’을 선택했을 때의 과정과 비교를 해 보라. 서버의 이름은 크게 중요하지 않다. 중요한 것은 이름서버의 정확한 IP Address를 입력하는 것이다. jeju.secure.pe.kr 도메인의 이름서버이니 이름은 ns.jeju.secure.pe.kr 정도로 해 주면 무방하다.
< 그림5-52. 하위 도메인의 위임(delegation) 작업 5 >	이름서버가 보인다. 다시 [추가]를 눌러서 다른 이름서버를 추가할 수도 있다.
< 그림5-53. 하위 도메인의 위임(delegation) 작업 6 >	이제 하위도메인을 위임시키는 작업을 완료하였다.

<그림5-54>를 보면, secure.pe.kr밑에 "jeju"이라는 폴더가 생성된 것을 확인할 수 있다. 비교를 위해 생성해둔 "shopping"도메인과 폴더모양이 다른 것을 확인한다. shopping.secure.pe.kr은 blueapple이라는 DNS서버가 직접 관리하고 있는 도메인이지만, "jeju.secure.pe.kr"은 더 이상 blueapple이 관리하는 도메인이 아니다. 위에서 지정해준 "ns.jeju.secure.pe.kr"이라는 이름의 DNS Server가 관리하는 도메인이 된 것이다. 만일, 외부의 DNS Server에서 "www.jeju.secure.pe.kr"이라는 호스트이름에 대한 IP주소를 요청하다면, blueapple DNS Server는 호스트이름에 대한 IP주소를 응답할 수 없다. 다만, jeju.secure.pe.kr도메인을 관리하는 DNS서버의 IP주소만을 응답할 수 있을 뿐이다. 그러면 외부의 DNS서버는 jeju.secure.pe.kr을 관리하는 DNS서버를 다시 찾아갈 것이다. 쿼리가 하나 더 늘어나게 된다.

물론 그 다음과정이 정상적으로 처리되기 위해서는 jeju.secure.pe.kr도메인의 관리를 위임받은 DNS Server에서 서버구성을 해 두어야 할 것이다. 그 과정은 앞에서 우리가 다루어보았던 blueapple이 secure.pe.kr도메인을 구성하였던 것과 동일하다. 다만, 도메인 이름이 "jeju.secure.pe.kr"이라고 한단계 아래로 내려갔을 뿐, 그 이상의 차이는 없다.

위에서 앞선 [그림5-19]의 과정에서 다음의 이름을 입력하면 된다. 나머지 과정 및 각종 레코드 등록과정은 동일하다.

지금까지 Windows Server 2003을 기준으로 DNS Service를 추가하고, 서비스를 위한 기본구성을 마쳤다. 이전 버전의 서버를 가지고 작업하더라도 큰 차이는 없다. 단지 인터페이스 상에서 약간 차이를 보이고 있을 뿐이다. 다음장에서는 Windows Server 2003의 DNS Service의 기능과 추가구성에 관한 설명을 한다.

앞에서 우리는 Hostname을 IP Address로 풀이(Name resolution)하는 방법으로 hosts.txt파일을 이용했을 때 생기는 몇가지 문제점을 살펴 보았다. 이름중복이라는 문제점을 해결하고, 현재상태의 컴퓨터의 호스트이름들을 반영할 수 있어야 하고, 관리적인 측면에서도 가장 손쉽게 접근할 수 있는 방법이라면 어떤 방법을 이용해야 할까? 이 점이 해결해야 할 중점과제이다.

한가지 예를 들어본다. 회사에는 수많은 부서가 존재한다. 그렇듯 부서를 나누는 이유는 무엇일까? 물론 여러 가지 이유가 있겠지만 관리적인 측면을 무시할 수 없을 것이다. 모든 사원들을 사장이 혼자 관리하는 것보다는 당연히 부서를 나누고 부서장이 관리를 하다면, 보다 효율적인 관리를 할 수가 있을 것이다. 또 부서가 없는 경우에 한 개인은 "000"라는 형식으로 개개인의 이름을 가지지만, 부서로서 개인을 조직하게 되면 "00부서의 000"로서 불리우게 될 것이다. 한 회사에 "송원석"이라는 이름을 가진 사람이 둘이 있다고 하자. 부서의 개념이 없을 때는 단순히 "송원석"하고 부르면 누구를 가리키는 것인지 헷갈릴 수밖에 없다. 하지만 그들을 구별해 주는 부서가 있다면 "00부서의 송원석"이라는 식으로 어긋나지 않게 원하는 사람을 구별할 수 있게 된다.

앞에서 문제가 되었던 이름중복은 조금만 생각을 바꾸면 해결이 가능한다. 이름을 평면적인(flat) 이름으로 사용하는 것 대신에 부서처럼 다른 이름을 하나쯤 더 붙이면 되지 않을까? 예를 들면 "www"라는 이름 대신에 "A회사의 www"로서 등록을 한다는 것이다. 그렇다면 모든 회사의 웹서버가 "www"라는 이름을 사용하더라도 더 이상 이름의 충돌은 염려하지 않아도 될 것이다.

hosts파일크기의 증가로 인한 네트워크 트래픽을 줄이고, 빠른 업데이트를 가능하게 하기 위해서는 관리를 분산시킬 수 있는 구조가 최선이라는 해결책을 찾고 결국 호스트들을 그룹화하는 작업을 하게 되었다. 그 그룹을 바로 "도메인(domain)"이라고 부른다. 여기서의 도메인은 Microsoft가 사용하는 도메인이라는 용어와는 구별을 해야 한다. Microsoft의 도메인은 어디까지나 마이크로소프트의 NT라는 운영체제가 제공하는 보안의 경계영역을 구분하는 회사의 작업그룹인 반면에, DNS에서의 도메인은 전 세계에서 구분할 수 있는 작업그룹이다.

DNS의 도메인은 수없이 많은 종류가 있을 수 있다. 대표적으로는 여러분들이 속해 있는 회사를 생각할 수 있고, 국가를 구분할 수도 있고, 특별한 단체를 구분지을 수도 있다. 인터넷에 연결되고 자신들의 집단을 구분할 수 있는 이름을 가지고자 한다면 어느 누구라도 도메인이라는 하나의 작업그룹을 할당받을 수 있다는 이야기다. 추가로 이러한 그룹 역시 또 다른 그룹에 소속되어 있고, 최상위에 모든 그룹은 하나의 그룹으로 묶이게 된다. 회사의 조직구조와 비슷한다. 회사안에는 몇 개의 사업본부가 있고, 사업본부 안에는 몇 개의 부서가 있고, 부서 아래에 팀이 있고, 팀 안에 팀원들이 소속되어 있는 구조와 같다. 실제 구조를 살펴보면 우리가 윈도우 탐색기를 통해서 볼 수 있는 폴더구조와 흡사한다. 최상위에 root(c:)가 있고, 그 밑에 폴더가 있으며 폴더밑에는 또 다른 폴더가 있고, 최종적으로 폴더 밑에는 파일이 들어있다. 이러한 형태의 구조를 우리는 계층구조라고 부른다. DNS는 계층구조로 구성되어 있다.

결국 최종적으로 만들어진 DNS의 구조를 살펴보면 아래의 <그림5-8>과 같다. 

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

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

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

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

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

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

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

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

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

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

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

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

루트네임서버는 요청을 받았으니 응답을 해야 할텐데, 자신 역시 모든 정보를 알고 있는 것은 아니다. 자신이 알고 있는 것은 "com"도메인을 관리하는 네임서버의 정보를 알고 있을 뿐이다. 그래서 하나로통신의 DNS Server가 원하는 것에 대한 100% 정답은 아닌, "com"도메인을 관리하는 네임서버의 정보를 제공해 주게 된다. (그림5-11-③)

하나로통신의 DNS Server는 한번의 query를 통해서 com도메인을 관리하는 네임서버의 정보를 알 게 되었다. 아직 완전한 정보는 얻지 못했기 때문에 계속해서 책임을 완수하고자 한다. 계속해서 "com"도메인의 네임서버에게 www.feelanet.com. 의 IP정보를 요청한다. (그림5-11-④)

하지만 'com'도메인의 네임서버 역시 하나로통신의DNS Server 가 요청한 호스트이름에 대한 IP정보를 알지는 못한다. 그렇지만 feelanet을 관리하고 있는 네임서버의 정보는 알고 있다. 자신이 관리하고 있는 하위도메인이기 때문이다. 그래서 요청에 대한 응답으로feelanet.com.의 정보를 알려 주게 된다. (그림5-11-⑤)

Feelanet.com.도메인의 네임서버정보를 얻은 하나로통신의 DNS Server는 feelanet.com의 네임서버에게 www.feelanet.com이라는 자신의 클라이언트가 요청했던 호스트에 대한 IP정보를 요청한다. (그림5-11-⑥)

이 요청을 받은 feelanet.com.의 네임서버는 요청한 FQDN이 자신이 관리하고 있는 도메인에 소속된 호스트이기 때문에 IP Address정보를 응답해 줄 수가 있다.(그림5-11-⑦)

몇 번의 query를 통해서 DNS 클라이언트가 요청한 정보를 알게 된 하나로통신의 DNS Server는 www.feelanet.com의 IP Address를 제공해 줄 수가 있게 되었다.(그림5-11-⑧)

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

글로써 기록하니 상당히 복잡해 보인다. 하지만 실제로 사용자 입장에서 본다면, 사용자는 웹 브라우저의 주소창에 친숙한 이름표기법에 따르는 이름을 입력했을 뿐이고, 내부사정은 잘 모르겠지만 어찌됐건 원하는 웹사이트의 홈페이지를 볼 수 있게 되었다. 이러한 작업을 가능하게 하기 위해서 DNS Server는 부지런히 발로(?) 뛰며 서비스를해 주고 있었던 것이다. DNS가 없었다면 이런 일이 가능했을까? 실로 DNS의 위력은 엄청나게 보이다. 필자는 감히 인터넷을 이끌어가고 있는 것은 바로 DNS라고 말하고 싶다. 그만큼 인터넷에 있어서 DNS의 기능은 필수적이기 때문이다. 하는 일은 크지 않지만 어떤 것보다도 중요한 역할을 담당하고 있다. 만일 DNS가 없다면 지금 우리가 사용하는 인터넷이라는 환경이 상당히 많이 다를 거라고 생각한다. TV에서 하고 있는 광고중의 상당수는 도메인이름을 알리는 광고를 하고 있다. DNS가 없다면 업체에서는 도메인이름을 알리는 광고가 아니라 IP Address를 알리는 광고를 해야만 할 것이다.

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

그래서 ‘도메인등록’이라는 용어를 풀어본다면, "회사에서 사용하기를 희망하는 도메인 이름을 관리하는 DNS Server의 정보를 상위 도메인을 관리하는 DNS Server에 등록하는 작업"이라고 보여진다.

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

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

굳이 기업네트워크의 전문가가 아니더라도 여러분들이 컴퓨터 앞에 앉아 있다면, 늘 DNS의 도움을 받고 있다. DNS는 수많은 사람들의 노력의 결과이며, 현재도 그렇고 앞으로도 DNS의 영향력은 점점 더 증가하게 될 것이라고 감히 말하고 싶다. 마이크로소프트는 Windows제품군으로 기업용 네트워크 운영체제인 NT에 이어서 Windows 2000, 2003이 나오면서 DNS의 쓰임새가 대폭 확장되었고, 윈도우 네트워크를 제대로 이해하기 위해서는 필수적으로 DNS에 대해 숙지하고 있어야 하게 되었다.

필자는 DNS의 기능과 개념 등에 대해서 설명하고자 한다. 알고 나면 그다지 어려운 개념은 아니지만, 필자의 경험상으로 봤을 때 많은 사람들이 어려워하는 내용중 하나이기도 하다. 어느 정도 지식이 있는 사람이 보기에는 "나를 뭘로 알고...?"라는 생각이 들 정도로 아주 기초적인 내용부터 접근해 보도록 할 것이다. 차근차근 익히다 보면 이 내용이 끝났을 때 여러분은 많은 내용을 얻을 수가 있을 것이다.

일단 단적으로 이해를 돕기 위해 DNS의 한가지 주된 용도에 대해서 알아보겠다. 우리는 인터넷에 접근하기 위하여 인터넷 익스플로러, 넷스케이프 같은 웹 브라우저를 이용한다. 아래의 그림을 보자.

<그림5-1. 영진닷컴 홈페이지 – www.youngjin.com  >

그림에서 주소창을 보면 찾아가길 원하는 서버의 주소를 입력하는 창을 볼 수 있다. 지금 예제에서는 " www.youngjin.com"이라는 웹서버를 찾아서 홈페이지를 보고자 한다. " www.youngjin.com"이라는 것은 결국 영진닷컴이라는 회사의 홈페이지를 담고 있는 컴퓨터의 이름인 것이다. 보통 유저라면 "흠.. 당연한거 아닌가?" 라고 생각할 수도 있다. 그렇다면 아래의 그림도 살펴보자.

<그림5-2. 영진닷컴 홈페이지 - 211.174.185.67 >

출력되는 그림에는 차이가 없지만, 주소란은 분명히 차이가 보이다. <그림5-1>에서의 주소와 비교해 보면, <그림5-1>에서는 우리에게 친숙한 문자가 쓰인 반면에, <그림5-2>에서는 외우기엔 조금 어려워 보이는 몇자리의 숫자가 적혀 있다. 바로 서버의 주소를 가리키는 IP Address이다. IP Address라는 것에 대해서 용어가 생소하다면, 먼저 IP Address라는 것에 대해 충분한 이해를 한 뒤 DNS를 배우도록 하는 것이 바람직하다.

위에서 확인해 본 바로는 문자로서 입력하든, 숫자로서 입력하든 하나의 서버로 접근해서 동일한 내용을 얻을 수 있다는 사실을 알게 되었다. 그렇다면 사용자 입장에서 볼 때 어느 것이 보다 편하게 쓸 수 있는 주소일까? 여러분이 남들로부터 "쟤는 많이 특이해.."라는 소리를 듣지 않는 이상 <그림5-1>의 경우가 보다 편하다는것을 느낄 수 있을 것이다.

TCP/IP환경에서 IP Address라는 것을 가지고 각각의 시스템을 구분하게 해 주고 있다. 웹서버도 마찬가지고, 여러분이 집에서 사용하는 컴퓨터도 마찬가지이다. IP Address라는 것을 가지고 서로를 구분하고 네트워크 상에서 통신이 가능하다는 것이다. 문제는 이러한 IP Address라는 것이 쉽게 외워서 쓰기에는 다소 부담스러운 숫자형태로 되어 있기 때문에 이 숫자를 대신할 수 있는 문자를 할당해서 www.youngjin.com과 같은 문자를 사용하고 있는 것이다. 하지만, 숫자를 대신할 수 있는 문자를 할당했다고 해서 IP Address라는 숫자는 쓰이지 않아도 된다는 것은 결코 아니다. 우리가 컴퓨터이름을 사용해서 통신을 시도했다고 할 지라도 실제 통신을 위해서는 반드시 해당 컴퓨터 이름을 가지고 있는 컴퓨터의 IP Address를 알아야만 하는 것이고, 특별한 서버를 둬서 그러한 일만 전문적으로 처리하도록 역할을 맡기게 된 것이다. 그 서버가 바로 DNS서버이다.

그렇다면 여러분이 www.youngjin.com이라는 컴퓨터이름을 입력했는데 어떻게 211.174.185.67이라는 IP Address를 알아내서 통신이 이루어 진 것일까? 여러분은 단지 이름하나 치고 <Enter>키 한번 눌렀을 뿐인데? 실체를 확인하기 위해 여러분 컴퓨터의 TCP/IP설정을 확인해 보라. <그림5-3>은 Windows XP의 네트워크 등록정보이다. 다른 인터페이스는 무시하고 넘어가도 좋다.

OS마다 조금씩 다르지만 별 차이는 없다. 중요한 것은 DNS서버 항목에 역시 IP Address가 적혀 있다는 것이다.

이러한 DNS서버의 IP정보를 담고 있는 컴퓨터를 가리켜서 DNS 클라이언트라고 부를 수 있다. DNS서버를 사용하는 클라이언트라는 의미이다. DNS클라이언트는 DNS서버의 도움이 필요한 어떤 작업을 해야 할 경우가 있을 때마다, 설정된 IP Address의 컴퓨터를 찾아가서 문의를 한다. 위에서 확인했던 웹 브라우저를 통해서 웹서버에 접근하는 작업이 대표적인 예이다.

DNS클라이언트가 있다면 반대편엔 분명히 이러한 응답을 처리해야 할 DNS서버가 있어야 한다.  <그림5-5>에서 확인할 수 있다. DNS서버로 설정된 서버를 살펴보면 그림처럼 DNS Server라고 하는 서비스(Application)가 동작하고 있음을 확인할 수 있을 것이다.

정리하면, 사용자가 www.youngjin.com이라는 컴퓨터이름을 주소창에 입력하면, 사용자의 컴퓨터가 DNS클라이언트로 설정되어 있기 때문에 설정된 DNS서버로 www.youngjin.com이라는 컴퓨터이름에 해당하는 서버가 무슨 IPAddress를 사용하고 있는지 문의를 하게 되고, 설정된 DNS서버는 사용자의 요청에 대해 211.174.185.67이라는 응답을 한다. 이 과정을 통해서 사용자는 IP Address를 알아냈기 때문에 이 IP Address를 가지고 통신을 시도하고, 해당 서버에 접속하여 홈페이지를 받아올 수 있었던 것이다.

개념상으로는 단순해 보이지만, 이러한 DNS가 동작할 수 있도록 하기까지 수많은 사람들의 노력이 있었다. 조금 더 구체적으로 접근해 보도록 하자. DNS는 왜 생겨났을까? 탄생배경에 대해서 아는 것은 DNS를 공부하는데 상당히 도움이 된다.

DNS의 필요성을 이해해보도록 하자.

먼저 말했던 것처럼 TCP/IP프로토콜을 사용하는 모든 컴퓨터(보통 ‘호스트’라고 부른다)들은 네트워크상에 각각 컴퓨터들을 구분하는 방법으로 고유하게 할당된 IP Address를 사용한다. 우리는 분명히 컴퓨터들을 지칭할 때 그들에게 할당한 컴퓨터이름을 이야기하지만, TCP/IP세계에서는 이름보다는 IP Address가 보다 절대적이다. 학교의 한 학급을 예로 들어보자. 한반에 동명이인은 있을 수도 있지만, 번호가 같은 학생은 있을 수 없다.  더 생각해 보면, 1학년4반의 13번과, 1학년2반의 13번은 분명히 다른 학생이다. 13번이라는 번호는 같지만, 반이 틀려서 서로를 유일하게 구분해주고 있는 것이다. 이것과 IP Address는 개념이 유사한다. 한 학생이 학교에 입학해서 번호를 부여받게 되면 결국 그 학생은 학교내에서 고유하게 구분될 수 있는 "학번"이라는 것이 할당된다. 이렇듯 IP Address는 네트워크에서 유일한 주소인 것이다.

IP Address는 각각 8bit단위마다 .(dot)로 구분된 32bit체계로 이루어져 있다. 실제로 표기할 때는 2진수보다는 보기가 용이한 10진수로서 기록하고 있다. 예를 들어서 192.168.200.100 과 같은.. 그래서 컴퓨터들은 IP주소를 보고 서로를 구분하고 통신을 해야만 하는데, 문제는 이러한 IP주소가 사용자가 기억해서 쉽게 입력하고 접근하기에는 조금 까다로운 숫자 형태라는데 있다.(숫자 좋아하는 사람이 얼마나 있겠는가?) 그래서 이러한 주소를 조금 더 쉽게 표현할 수 있는 방법이 없을까 하고 연구한 결과, IP address마다 별도의 이름을 할당을 하게 되었다. 예를 들면 www, ftp, smtp, mail, korea 등이 그것이다. 당연히 사용자 입장에서 보면 숫자보다는 보기 편한 문자로 되어 있기 때문에 접근하기가 용이할 것이다.

또 여러분의 회사의 웹서버가 IP Address가 바뀌는 상황이 발생했을때는 어떤가. IP Address만으로 통신을 진행할 때는 웹서버의 IP Adddress가 바뀌었음을 인터넷 세상에 알려야 할 것이다. 쉽지 않은 일이다. 이것을 해결하는 방법으로는 IP Address에 추가로 이름을 할당하는 방법이 있다. 웹서버의 이름을 www라고 붙여 놓게 되면 사용자들은 www를 이용하여 웹서버에 연결하게 될 것이고, 설사 IP Address가 바뀌더라도 www라는 이름은 바뀔 필요가 없는 것이다. 이러한 이름을 가리켜 "호스트이름(Host name)"이라고 부르며, 별명(Alias)이라는 표현을 한다. IP address대신 붙이는 별명이라는 뜻이다.

아래에 TCP/IP통신의 기본흐름을 도식화해 보았다. 거추장스러운 추가 프로토콜을 모두 생략하고, DNS를 이해하는데 필요한 핵심내용만 정리한 그림이다. 우리가 웹 브라우저를 가지고 웹서버에게 데이터를 보내는 과정을 생각해 보자. 웹 브라우저는 Application이다. 실제로 네트워크에 데이터를 날려보내는 것은 물론 네트워크 어댑터카드(NIC)이다. 그 둘을 연결시켜 주는 것이 무엇일까? 그것이 바로 Protocol인 것이다. 결국 어플리케이션을 가지고 통신을 하기 위해서는 반드시 프로토콜을 도움을 받아야 하고, 마지막으로 네트워크 어댑터카드라는 물리적인 장비를 통해서 상대방 컴퓨터와 통신을 할 수 있게 되는 것이다.

앞에서 보았던 IP Address와 Hostname의 관계를 생각하고, <그림5-6>을 보면 이해를 도울 수 있다. 결국 어플리케이션이 hostname을 사용한다고 하더라도 실제 통신을 위해서는 거쳐야 할 단계가 IP Address라는 사실을 알수가 있게 된다. MAC Address라는 것은 그 다음 단계이다. 위의 단계에서 작업이 더 이상 진행되지 않는다면 더 이상 통신을 수행할 수 없다.  아래의 <그림5-7>을 예제로 설명한다.

<그림5-7>의 예제는 A회사의 hostA컴퓨터를 사용하는 사용자가 B회사의 hostC라는 이름을 가진 웹서버에 연결하여 서비스를 제공받고자 한다. A회사와 B회사는 물론 인터넷이라는 네트워크 환경으로 연결되어 있겠지만, hostA의 사용자로서는 자신이 원하는 데이터를 가지고 있는 서버가 이 지구상에 도대체 어디에 존재하는지 알 턱이 없다. 다만 알고 있는 정보라고는 오직 하나, 서버이름을 알고 있을 뿐이다. 앞에서 설명할 때 서버이름을 알고 있더라도 통신을 위한 다음단계는 분명히 IP Address라는 것을 알아야 한다고 했다. 그렇다면 어떤 방법으로 서버이름을 통해서 IP Address를 얻어 낼 수 있을 것인가?

이것을 가능하도록 하기 위해서 인터넷초기에는 다음과 같은 방법을 사용하게 되었다. 인터넷에 연결되는 모든 컴퓨터들은 각각 SRI-NIC이라는 컴퓨터의 hosts.txt라는 파일에 자신의 hostname과 IP Address정보를 등록하고, 각 회사에서는 FTP를 이용해서 이 파일을 다운로드 받아서 각각 외부에 통신할 때 이 파일에서 원하는 hostname에 대한 IP Address 정보를 찾아서 통신을 하는 방법이다. 충분히 가능한 일일 것이다. 전세계 인터넷에 연결된 모든 호스트가 하나의 서버에 등록될 것이기 때문에 당연히 사용자는 원하는 정보를 찾는데 큰 어려움이 없게 될 것이기 때문이다. 하지만, 여기에는 몇가지 문제점이 내포되어 있다.

첫 번째 문제점은 업데이트가 늦다는 것이다. B회사에 새로운 호스트가 추가되었다고 가정하면, 그 정보를 A회사에서 알기 위해서는 몇가지 절차가 필요하다. B회사에서는 새로운 호스트의 정보를 역시 Hosts.txt파일에 등록해야 하고, A회사는 새롭게 바뀐 파일을 다운로드 받아야만 비로소 사용할 수가 있게 되는 것이다. 처음엔 가능했을지 모르지만 요즘같은 폭발적인 인터넷 발전속도를 따라가기엔 당연히 역부족일 수밖에 없다.

두 번째 문제점은 네트워크 트래픽이다. 파일에 등록된 호스트이름이 늘어갈수록 파일크기는 커질 수밖에 없고 인터넷이 FTP관련된 불필요한 트래픽으로 가득 차는 우스운 일이 생길 수밖에 없다. 이에 데이터베이스를 한곳에 집중시키는 문제점을 해결하기 위한 방안이 필요해졌다. 가장 좋은 방법은 데이터를 분산시키는 방법일 것이다.

세 번째 문제점은 IP Address를 대신할 컴퓨터의 호스트이름 짓기가 너무 힘들다는 것이다. 모든 컴퓨터의 이름이 평면적인 구조로(www, ftp, A회사 등) hosts.txt파일에 등록이 되었기 때문에 당연히 사용하고자 하는 이름은 hosts.txt파일내에서 유일해야만 정상적인 통신을 할 수가 있게 된다. 만일 어떤 회사가 자신의 회사의 웹서버의 이름을 "www"로 지어서 등록을 했다면 전세계의 어떤 컴퓨터도 더 이상 www라는 이름을 사용할 수 없을 것이다. 당연한 결과이다. 이러한 문제점도 역시 해결을 해야할 필요성이 생겼다.

인터넷을 관리하는 사람들은 이러한 문제점을 해결할 필요성을 느꼈고, 위의 몇가지 문제점을 해결할 수 있는 "분산된 데이터베이스 형태의 새로운 방법"이 필요해진 것이다. 그 결과로 나온 것이 바로 "DNS (Domain Name System)"이다.

'빨리 DNS사용법이나 이야기하지 무슨 사설이 이렇게 긴가'라고 생각할 수도 있겠다. 하지만, DNS가 단순히 사용법만 알아서 사용할 만큼 단순한 서비스가 아니다. 여러분들이 한번만 DNS에 대해서 체계적인 이해를 하여 둔다면 적어도 향후 몇 년간은 두고두고 도움을 받을 수 있는 중요한 서비스인 만큼 이런 내용을 소홀히 할 수가 없기 때문임을 이해해 주기 바란다. 길었던 사설은 이제 마무리 하겠다. 이제 DNS라고 하는 녀석의 구조를 알아보고, 접근방법, 설치, 구성 등에 대해서 차례대로 알아보도록 하자.

지금까지는 DHCP의 기능과 구성에 대해서 살펴보았다. 위의 내용만으로도 구현하는 것은 얼마든지 가능하겠지만, 이제부터는 조금 다른 측면을 고려해 볼까 한다. 회사의 네트워크 환경이 적어도 2개 이상의 세그먼트로 네트워크가 분리되어 있는 상황을 고려해 보고, 하나의 DHCP서버가 서비스를 하지 못하는 상황이 발생했을때를 고려하여 그러한 경우라도 클라이언트가 정상적인 IP를 할당받는데 차질이 없도록 하기 위한 서버의 중복배치를 고려해 보고자 한다.

 4-5-1. DHCP서비스의 확장 구현

 

아래의 <그림4-56>과 같은 네트워크 구성을 가진 회사가 있다. 

<그림4-56. 복수 네트워크를 가진 회사의 DHCP서비스 1>

 

그림에서 보는 바와 같이 회사는 2개의 네트워크를 가지고 있고 각각 192.168.5.0 192.168.10.0 네트워크ID를 사용한다. 두개의 네트워크에서 호스트들은 IP를 구성하는 방법으로 DHCP를 사용하고 있다. 이 경우 안정적으로 DHCP서비스를 제공하기 위한 회사의 디자인은 <그림4-56>에서 보는 바와 같이 배치할 수 있다.

 

일단 첫번째 고려해야 할 것은 두개의 네트워크에 있는 클라이언트들이 IP를 할당받을 수 있어야 한다는 기본적인 기능적인 측면(Functionality)에 만족해야 한다는 것이다. DHCP프로세스를 잘 이해했다면 답이 나온다. DHCP는 브로드캐스트를 사용하여 초기화를 한다는 것을 배운바 있는데 이것 때문에 어느 한쪽 네트워크에만 DHCP서버가 있어서는 곤란하다는 것이다. DHCP서버가 없는 쪽의 네트워크에서 DHCP클라이언트가 DHCP서버를 찾는 Request 브로드캐스트를 날리게 되면 라우터에서 이 메시지를 통과시키지 않기 때문에 클라이언트는 IP를 할당받지 못하게 되기 때문이다. 이 때 가장 좋은 방법은 각 네트워크마다 DHCP서버를 배치하는 방법이다. 이것은 가장 좋은 성능을 제공할 수 있는 방법이기도 하다. <그림4-56>의 예제에서 DHCP서버A와 B를 각각 배치한 것을 볼 수 있다. DHCP서버A는 192.168.5.0 네트워크를 위한 IP영역을 설정하였고, DHCP서버B에는 192.168.10.0 네트워크를 위한 IP영역을 설정해 주었다.

 

두번째로 고려할 점은 가용성(Availability)을 제공해야 한다. 예를 들어서 DHCP서버A가 문제가 생겨서 DHCP서비스가 멈추었다면 어떻게 될까? 192.168.5.0 네트워크의 DHCP클라이언트들은 IP를 임대받지 못하게 되고 APIPA기능으로 169.254.0.0 네트워크의 IP대역이 할당될 것이다. 당연히 정상적인 통신은 하지 못하게 된다. 기업네트워크에서 이것은 곤란한 일이다. 하나의 서비스가 문제가 생겼더라도 다른 방법으로 해결을 할 수 있어야 한다. 여기에 대한 방안으로 서버의 중복을 고려할 수 있다. 각각 네트워크마다 DHCP서버를 두대씩 구성하면 되는 것이다. 그러면 하나의 DHCP서버가 다운되었더라도 여전히 클라이언트들은 IP를 할당받는 것이 가능해 진다. 이 경우 주의할 점은 한 네트워크에 있는 2개의 DHCP서버는 서로 다른 범위의 주소Pool을 유지해야 한다는 것이다. DHCP서버A는 192.168.5.11~192.168.5.100을 구성하고, 새롭게 설치한 DHCP서버C는 192.168.5.201~192.168.5.250을 구성하는 형태가 되어야 한다. 역시 IP충돌을 막기 위한 조치이다. IP Address가 충분해야 할 수 있는 구성이라는 생각이 들 것이다.

 

<그림4-56>에서는 다른 방법으로 구현된 것을 볼 수 있는데 이것은 한가지 예제일 뿐이다. DHCP서버를 중복배치하는 것과 큰 차이는 없지만 관리적인 측면에서는 보다 효율적인 방법이 될 수 있다. 각 네트워크에 DHCP서버 하나씩이 배치되는 것은 차이가 없고, 다만 추가로 한 서버에 DHCP Relay Agent를 구현해 두는 방법이 있다. 이 DHCP Relay Agent는 DHCP클라이언트의 DHCP임대 요청을 받아서 대신 DHCP서버에게 IP임대를 요청하여 클라이언트에게 제공해 주는 “중개인”역할을 맡는다. DHCP클라이언트가 직접 서버에 요청하는 것과 차이가 있다면 DHCP서버와 Unicast (=Direct)통신을 한다는 것이다. 그러므로 라우터 건너편, 즉 원격지의 DHCP서버에게 IP요청을 보내는 것이 가능하다.

 

당연히 DHCP Relay Agent는 DHCP클라이언트로 구성되어서는 안된다. 고정IP가 할당되어야 한다. 예제의 그림에서 만일 DHCP서버A가 어떤 이유에서든지 IP를 임대하지 못하는 상황이 되면 DHCP Relay Agent로 설정된 서버는 192.168.5.0 네트워크의 DHCP클라이언트의 요청을 받아서 건너편에 있는 DHCP서버B에게 DHCP요청을 보내서 IP를 대신 할당해 주는 형태로 동작하게 된다. DHCP서버B에서는 192.168.10.0 인 자신의 네트워크를 위한 IP영역을 생성해 두는 것은 당연한 일이고, 추가로 192.168.5.0의 네트워크를 위한 IP영역도 구성을 해 두어야 한다. 그래야만 이러한 작업이 완전하게 수행될 수 있다.

 

반대쪽에서는 어떨까? 역시 같은 작업을 해 주면 된다. 192.168.10.0네트워크에서도 자신의 네트워크에 있는 DHCP서버B가 서비스를 하지 못할 상황을 대비해서 문제가 있을때는 DHCP 서버A를 찾아가서 IP임대과정을 진행하도록 DHCP Relay Agent를 셋팅해 두어야 한다. DHCP서버A에서는 192.168.5.0뿐만 아니라 192.168.10.0 네트워크를 위해서 추가로 IP영역을 구성해 두어야 한다.

정리하면, DHCP서버A와 DHCP서버B는 각각 192.168.5.0과 192.168.10.0 네트워크라는 2개의 IP범위를 구성해 두면 되는 것이다. 이때 IP구성은 보통 7:3이나 8:2 정도의 구성을 권장한다. 각 네트워크당 DHCP서버에서 관리되는 IP범위에 주소가 100개씩이라면 자신의 서버에 70개, 다른 서버에 30개 정도로 IP범위를 구성하라는 것을 의미한다. 그리고 각 네트워크의 DHCP Relay Agent는 서로 라우터 건너편 네트워크에 있는 DHCP서버를 찾아가서 IP임대를 요청할 수 있도록 구성을 해 두면 된다.

 

 4-5-2. DHCP Relay Agent 설정

 

DHCP Relay Agent를 구성하는 방법은 다음과 같다.

<그림4-57. DHCP Relay Agent 설정–1>

 

관리도구-라우팅 및 원격 액세스를 통해서 접근한다. 이 관리도구에 처음 접근하는 것이라면 <그림4-57>과 같은 화면이 보일 것이다. 화면의 왼쪽 패널을 보면 BLUEAPPLE(로컬)이라는 서버의 서비스가 멈춰져 있음을 보여준다. 마우스 오른쪽 버튼을 이용하여 ‘라우팅 및 원격 액세스 사용 및 구성’을 클릭한다.

<그림4-58. DHCP Relay Agent 설정 – 2 >

5가지의 메뉴가 보이는데 ‘수동으로 구성한 서버’를 선택하고 <다음>을 누른다. 각각에 대한 설명은 후반부의 단원에서 자세히 다룬다.

<그림4-59. DHCP Relay Agent 설정 – 3 >

마법사를 완료했다는 화면이 보인다.

 

<그림4-60. DHCP Relay Agent 설정 – 4 >

 

이제 서비스를 설치했다고 시작하겠다는 메시지를 띄워준다. <예>를 눌러서 라우팅 및 원격 액세스 서비스를 시작시킨다.

 

<그림4-61. DHCP Relay Agent 설정 – 4 >

 

라우팅 및 원격 액세스 관리콘솔에서 왼쪽 패널을 계속 확장해 보면 IP라우팅 아래에 ‘DHCP릴레이 에이전트’메뉴를 확인할 수 있다. 설치는 기본적으로 이루어진다. 이제 구성을 해야 한다. 마우스 오른쪽 버튼을 이용하여 새 인터페이스를 추가한다. 인터페이스는 DHCP클라이언트로부터 요청을 받아들일 NIC에 해당하는 연결을 의미한다.

<그림4-62. DHCP Relay Agent 설정 – 5 >

 

필자는 Private라는 연결을 선택했다. 인터페이스를 선택하면 ‘DHCP패킷릴레이’옵션이 체크된 화면이 팝업되고 홉수임계값, 부팅임계값을 결정하도록 화면을 보여준다. 기본 설정인 ‘4’로 두고 진행하면 된다. 의미있는 값이다. 지금 192.168.5.0네트워크에는 DHCP서버A가 있고, DHCP Relay Agent가 하나 존재한다. DHCP서버A가 잘 동작하고 있을때는 DHCP Relay Agent가 굳이 동작할 이유가 없다. 오히려 동작하지 않는 것이 보다 좋을 것이다. 로컬 DHCP서버가 잘 동작하고 있으니 DHCP트래픽을 원격으로 전달할 이유가 없기 때문이다.

 

홉수임계값은 DHCP요청을 다른 DHCP서버나 DHCP Relay Agent로 넘길 때 몇 단계나 넘어갈 수 있는지를 지정한다. 기본값을 사용하면 적당하다. 부팅임계값은 DHCP Relay Agent가 언제 동작할 것인지를 지정해 주는 값이다. 기본값은 4초로 설정되어 있다. 이 경우 DHCP Relay Agent는 DHCP클라이언트의 DHCP요청 브로드캐스트를 받더라도 DHCP요청을 중계하도록 설정된 DHCP서버에게 즉시 메시지를 중계하지는 않는다. 부팅임계값인 4초동안 기다리게 된다. 그 때까지 네트워크에서 DHCP서버의 응답이 없으면 그때 비로소 DHCP Relay라는 역할을 하게 되는 것이다. 로컬에 DHCP서버가 있을때는 외부로 DHCP를 넘기지 않는다는 것을 의미한다. 4초라는 시간이면 DHCP클라이언트가 두차례 DHCP Discover브로드캐스트를 날릴수 있는 시간이다. 정상적으로 DHCP서버A가 서비스하고 있다면 응답이 있어야 할 시간동안 기다려 주는 것이다.

 

<그림4-63. DHCP Relay Agent 설정 – 6 >

 

다음에는 이 DHCP릴레이 에이젼트가 DHCP클라이언트의 DHCP브로드캐스트를 어떤 DHCP서버에게 전달할 것인지를 설정한다. <그림4-63> 라우팅 및 원격 액세스 관리콘솔의 왼쪽패널에서 IP라우팅 아래에 있는 DHCP릴레이 에이젼트의 등록정보를 클릭한다.

<그림4-64. DHCP Relay Agent 설정 – 7 >

 

DHCP서버를 추가한다. 예제에서는 192.168.10.0 네트워크에 있는 DHCP서버의 IP를 추가해 주었다.

이렇게 하면 DHCP Relay Agent의 구성을 모두 마쳤다. Windows NT 4.0 Server로써 DHCP Relay Agent를 구현해도 잘 동작한다. 다만 서비스의 설치방법이 다르다. NT 4.0 Server에 DHCP Relay Agent를 구성하려면 바탕화면의 ‘네트워크환경’à’등록정보’à’서비스’탭을 통해서 서비스를 추가해 주어야 한다. 나머지 구성방법은 동일하다.

4-5-3.  Multi-homed DHCP Server 구성

 

<그림4-65. 복수 네트워크를 가진 회사의 DHCP서비스 2>

 

동일한 예제에서 다른 구성을 해 보았다. 가장 저렴하게 구현이 가능한 방법이기도 하다. 192.168.5.0 네트워크에 설치된 DHCP서버에 NIC를 하나 더 설치하여 192.168.10.0 네트워크에 연결한다. 이렇게 했을 때 DHCP서버는 각각의 NIC를 통해서 들어온 DHCP클라이언트들의 DHCP Discover 브로드캐스트 요청에 대하여 응답이 가능하다. 이렇게 네트워크 어댑터가 여러 개 장착된 컴퓨터를 가리켜서 Multi-Homed computer라고 부른다. 멀티홈 DHCP서버 하나만으로 2개의 네트워크에서 DHCP서비스가 가능해 졌다. 이 서버가 다운이 되었을 상황을 고려한다면? 해결방법은 간단하다. 멀티홈 DHCP서버를 하나 더 설정하는 방법이 있을 것이다. 이렇게 하는 것은 각각의 네트워크마다 DHCP서버를 두 대씩 설치했던 것과 동일한 디자인을 보여줌을 알 수 있다. <그림4-65>과 같은 구성은 물리적인 네트워크 구성이 가능할 때 구현할 수 있는 방법이다.

 

이상 DHCP서비스를 구성하는 몇가지 방법을 살펴 보았다. 네트워크에서 서비스를 구성하기 전에 가장 우선시 해야 할 것이 ‘네트워크 디자인’이라고 이야기 했지만 현실적으로 디자인을 제대로 하기 위해서는 그것들에 대한 기능적인 부분을 전반적으로 이해해야만 가능할 것이라는 생각이 들 것이다. 기능을 완전하게 이해한 후 앞에서 설명한 바 있는 가용성, 성능, 보안, 기능성의 측면을 두루 만족할 수 있는 네트워크 디자인을 할 수 있다면 더 바랄것이 없다. 두 가지 네트워크 구성도만이라도 완전하게 이해를 하도록 하자.