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라고 하는 녀석의 구조를 알아보고, 접근방법, 설치, 구성 등에 대해서 차례대로 알아보도록 하자.

기업네트워크에서 어느 위치에 몇대의 서버를 배치할 것인가의 문제는 단순히 서버를 관리하는 것보다 중요한 의미를 가진다. 서버를 설치하고 구성하기에 앞서 먼저 서버의 배치 디자인을 계획해야 할 필요성이 있다. 이때 여러분의 디자인에는 다음의 몇가지 측면이 고려되어야 한다.

(1) 기능성(Functionality) : 디자인에 따라 서버를 배치했을 때 모든 위치에서 기업의 요구사항을 반영할 수 있도록 디자인 되어야 한다는 것을 뜻한다. 가장 실질적인 기능적 측면을 고려해야 한다는 것이다.

(2) 보안(Security) : 근래에 들어서 점점더 비중이 강조되고 있는 부분이다. 그동안 많은 관리자는 보안의 측면은 상대적으로 신경을 쓰지 않았던 것이 사실이다. 하지만 서버의 배치시 잠재적인 위험요소를 고려하여 보안에 초점을 맞추어야 할 것이다.

(3) 가용성(availability) : Downtime을 최소화할 수 있도록 고려해야 한다. 한대의 서버가 문제가 생겼더라도 사용자들은 계속해서 서비스를 받을 수가 있도록 서버를 배치하여야 한다. 무슨 마술인가 싶지만 의외로 간단하다. 서버를 중복배치하면 될 것이다. 한대의 서버가 다운 되었더라도 다른 서버가 그 기능을 계속 대체할 수 있다면 가능한 일이다. 마이크로소프트의 네트워크 환경에서는 그러한 서버들의 중복기능을 기본적으로 포함하고 있다. 관리자가 잘 디자인해 주면 해결이 된다. 최고의 가용성을 제공하는 솔루션으로서는 “클러스터링 기술”을 생각할 수 있지만 상대적으로 비용이 많이 들어가는 방법이다. ( http://www.microsoft.com/korea/windowsserver2003/technologies/clustering/default.asp 사이트 참고)

(4) 성능(Performance) : 사용자가 기대하는 시간안에 응답을 얻을 수 있도록 해야 함을 의미한다. 대부분의 사용자들은 예상치 못한 느린 응답시간을 참을 수 있는 인내력이 없다. 한대의 서버보다는 두대의 서버가, 두대의 서버보다는 세대의 서버가 보다 나은 응답력을 제공한다. 이 항목은 (3)가용성과도 밀접한 관계가 있으니 가용성을 제공하면서 성능까지 챙겨줄 수 있도록 디자인되어야 할 것이다.

여러분이 고려한 네트워킹 서비스의 디자인에 위의 네가지가 모두 고려되었고, 현재의 디자인이 위의 네가지를 만족하고 있다면 잘 구성된 네트워크라고 생각해도 좋다. 그 중에서도 어느쪽에 비중을 더 둘 것인가는 회사의 판단이 요구된다. 모든 것에 최상의 솔루션을 채택하기는 현실적으로 어렵다. 예를 들어서 보안을 중요시하여 서버에 IPSec, VPN등의 암호화 기술을 채택하였다면 상대적으로 그렇지 않을때에 비해 “성능”은 떨어질 수도 있는 것이기 때문이다.  

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

앞에서 설명한 내용만으로도 중,소규모의 네트워크 환경에서 DHCP구성은 가능할 것이다. 이번장에서는 DHCP서버의 몇가지 추가기능에 대해서 설명을 한다.

4-5-1. 복수의 IP 범위 구성

하나의 DHCP서버는 복수의 네트워크의 범위를 가지는 것이 가능하다. 이것은 회사가 물리적으로 여러개의 네트워크로 세그먼트되어 있을 때 하나의 DHCP서버만으로도 전체 네트워크에서 DHCP서비스를 가능하게 만들 수 있다는 것을 의미한다. 물리적인 구성은 뒤에서 살펴보고 여기서는 설정하는 방법을 알아보도록 하자.

서버이름을 클릭하면 새로운 범위를 추가할 수 있다. 구성방법은 처음 구성할 때와 차이가 없다.

<그림4-34>에서는 blueapple이라는 이름의 DHCP서버가 192.168.5.0과 192.168.10.0 이라는 두 개의 네트워크 범위를 가지고 있는 그림을 보여준다.

4-5-2. DHCP클라이언트에게 특정 IP Address 예약

기본적으로 DHCP서버는 클라이언트의 DHCP요청에 대하여 사용가능한 첫 번째 IP를 발급한다. 만일 bluexp라는 이름의 호스트에게 반드시 특별한 IP Address를 발급하고자 한다면 예약을 통해서 구현해야 한다. IP가 변경되어서는 안되는 서비스를 하고 있는 컴퓨터의 경우에는 이러한 방법을 이용할 수 있다.

DHCP관리콘솔의 클라이언트에게 발급할 IP를 포함하고 있는 범위를 클릭하고, '예약'을 클릭한다.

예약이름은 단순한 표기에 지나지 않는다. 관리자가 구별하기 쉬운 이름을 입력해 주면 되지만, IP주소와 MAC주소는 정확히 지정해야 한다. 이 예약할 IP주소는 임대할 IP범위에 포함이 되어 있어야 한다. 192.168.5.11~100까지가 IP범위인데, 192.168.5.120이라는 범위밖의 IP를 예약할 수는 없다는 것이다. 예제에서는 blueXP라는 클라이언트에게 IP 192.168.5.25를 발급하도록 예약하는 그림을 보여준다. DHCP프로세스가 브로드캐스트를 이용한다고 했다. 이때 DHCP서버가 DHCP 브로드캐스트 메시지를 받고 예약된 클라이언트인지 확인하는 근거로는 DHCP클라이언트 NIC의 MAC주소를 사용한다.

MAC(Media Access Control) Address는 IP Address라는 논리적인 주소와는 구별되는 NIC에 할당되는 물리적인 6byte로 구성된 주소이다. MAC주소를 확인하는 방법은 알고자 하는 NIC를 가진 컴퓨터에서 ipconfig/all을 이용하면 간단히 얻을 수 있다. 장치관리자에서 네트워크 어댑터 디바이스 등록정보를 통해서도 확인할 수 있지만 꽤 번거로운 작업이다. 네트워크 상에서 이러한 정보를 얻고자 한다면 'arp'유틸리티를 이용할 수 있다.

ping 192.168.5.11를 하면 4개의 응답이 오는 것을 확인할 수 있는데 이 응답이 온다는 것은 실제로 192.168.5.11 호스트와 물리적인 통신이 이루어졌다는 것을 의미한다. 곧 이어서 'arp -a'를 입력해 보면 시스템의 캐쉬에 저장된 ARP주소 매핑 테이블을 보여준다. <그림4-37>에서 하이라이트된 부분이 192.168.5.11의 MAC Address를 보여주는 부분이고, dynamic 이라는 유형을 가진 것을 확인할 수 있다.

이렇게 상대방 컴퓨터가 가진 NIC의 MAC주소를 알아낸 후 DHCP클라이언트를 예약할 때 이 MAC주소를 그대로 사용하면 된다. <그림4-38>에서 보는 바와 같이 하이픈(-)은 제외하고 12자리의 숫자를 기록한다.

예약을 하면 관리콘솔에서는 예약된 클라이언트의 범위를 확인할 수 있고, DHCP서버는 이 IP를 사용가능한 IP에서 제외시켜서 다른 클라이언트에게는 할당하지 않고 "예약 비활성"상태로만 유지한다.

bluexp DHCP Client에서 ipconfig/renew를 이용해서 IP를 갱신요청을 했더니 기존에 받았던 192.168.5.11을 반납하고 192.168.5.25 라는 예약된 IP를 받아온 것을 확인할 수 있다. 잘 동작해 주고 있다.

관리콘솔에서도 변화가 생겼다. 주소임대 항목을 클릭해 보면 192.168.5.25의 상태가 "활성" 즉 예약된 클라이언트가 IP를 받아갔음을 보여준다.

4-5-3. 사용자 클래스 사용 ; 부서마다 다른 라우터를 사용하게 하자?

DHCP서비스를 사용하는 관리자들이 가끔 이런 생각을 해 왔다. 부서마다 다른 DHCP옵션을 설정할 순 없을까? 한 예로 영업부서 직원들은 192.168.5.1 라우터를 사용하고, 관리부서 직원들은 192.168.5.2 라우터를 사용하게 할 수 있다면 보다 빠른 통신이 가능할텐데.... 혹은 한 네트워크에서도 일부는 192.168.5.200 DNS를 사용하고 일부는 192.168.5.230 DNS를 사용하게 한다면 사용자들은 보다 빠른 응답시간을 제공받을 수 있을텐데... 하는 생각을 할 수 있을텐데,… 이러한 것들이 직접 구현이 가능해 졌다.

DHCP서버에서 제공되는 '사용자 클래스'라는 옵션을 사용하면 가능한 작업이다. 구현을 통해서 설명한다.

먼저 회사에서 특별히 사용자정의해서 사용할 클래스를 정의해야 한다. 예제에서는 sales 라는 클래스를 만들어 보도록 한다. 영업부서 사용자들이 DHCP로부터 할당받을 옵션이라는 뜻으로 sales라고 표기한 것이다. 큰 의미는 없다. 다만 구별하기만 쉬우면 될 것이다. DHCP관리콘솔에서 DHCP서버의 이름을 클릭하고 마우스 오른쪽 버튼을 눌러서 "사용자 클래스 정의"를 선택한다.  

이미 정의된 2개의 사용자 클래스가 있는데, 여기서 sales를 추가해야 한다. <추가>버튼을 눌러서 다음으로 진행한다. 

 표시이름에는 sales라고 입력했다. 복잡한 이름보다는 가급적이면 간결한 이름을 사용한다. 이후에 사용자들의 컴퓨터마다 별도의 설정을 해야 하니 간단한 것이 좋다. 클래스를 구별하기 쉽도록 설명을 달았으며 아래의 바이너리값에는 중복되지 않는 숫자를 할당한다. 예제에서는 "1"이라고만 입력했다. 입력을 마쳤으면 <확인>을 누른다.

 사용자 클래스에 sales라는 클래스가 추가되었음을 보여준다.

DHCP관리콘솔에서 '서버옵션'을 클릭하고 '옵션구성'메뉴를 선택한다.

사용자 클래스 항목을 클릭한 후 위에서 추가한 sales 사용자 클래스를 찾아서 클릭한다.(그림4-46)

선택한 sales 클래스에 별도의 DHCP옵션을 설정하는 것이 가능하다. 예제에서는 라우터 옵션으로 192.168.3.2를 할당하고 있다. 이상으로 DHCP서버 구성을 마쳤다. 이제부터 DHCP서버는 DHCP클라이언트가 요청을 보냈을 때 이 클라이언트가 어떤 클래스에 있는지를 살펴보고 sales 클래스에 소속된 클라이언트라면 sales 클래스를 위해 특별히 설정된 DHCP옵션값을 클라이언트에게 제공한다.

그렇다면 한가지 의문이 생길 것이다. DHCP서버는 클라이언트가 어떤 클래스에 소속되어 있는지를 무슨 근거로 판단하는 것일까? 해답은 클래스를 구분해주는 값이 클라이언트의 DHCP 브로드캐스트 요청에 포함이 되어 있다는데 있다. 그래서 DHCP클라이언트 쪽에서는 특별한 설정을 통해서 자신이 sales 클래스에 속해 있음을 DHCP서버에게 알려줘야 하는데 다음과 같이 설정한다.

ipconfig/?를 이용하여 옵션들을 살펴보니 /showclassid, /setclassid 라는 옵션이 보이다. 이것을 사용하여 DHCP클라이언트는 자신이 속한 클래스를 정의한다.  

DHCP클라이언트쪽에서 'ipconfig/showclassid private'를 명령을 입력해 보았다. 여기서 private는 네트워크 연결의 이름을 가리킨다. NIC를 지정해 주는 것이다. 잠시후 명령에 대한 응답이 오는데 DHCP서버에 추가한 sales 사용자 클래스를 확인할 수 있다.

이번에는 위에서 확인한 sales 클래스를 설정해 보겠다. ipconfig/setclassid를 이용하면 된다.

명령프롬프트에서 'ipconfig/setclassid private sales'를 입력했다. "ipconfig/setclassid + 네트워크연결이름+사용자 클래스 이름"의 형태를 사용하는 것이다. 그러면 <그림4-50>에서 보듯이 DHCP Class ID가 sales 로 정의되는 것을 볼 수 있다. 이때부터 DHCP클라이언트의 DHCP브로드캐스트에는 이러한 sales라는 클래스 값까지 포함되게 되고, DHCP서버는 이 클래스를 기반으로 클라이언트에게 특별한 옵션을 할당해 주는 것이 가능한다.

네트워크 연결 이름 바꾸기 기본적으로 NIC가 추가되면 그 연결의 이름은 "로컬 영역 연결"로 정의된다. 이것을 '이름바꾸기'를 이용해서 이름을 변경해 두면 여러모로 사용이 편리한다. 예제의 Private 라는 이름도 '로컬 영역 연결'의 이름을 바꾼 것 뿐이다. 아래의 그림을 참고한다.    <그림4-51> 네트워크 연결 이름 바꾸기

4-5-4. DHCP옵션의 적용 순서

 위에서 이야기를 하다 보니 DHCP옵션을 설정하는 항목들이 나오는데 DHCP관리콘솔을 이용해서 DHCP옵션을 설정하려고 접근해 보면 꽤 여러 군데에서 옵션설정이 가능함을 알 수 있다.

위에서 보듯이 DHCP서버는 다양한 옵션 구성 메뉴를 가지고 있다. 서버옵션, 범위옵션, 예약된 클라이언트 옵션이 있고, 그런가 하면 마지막에 구성해 보았던 사용자 클래스 옵션도 있다. 이 4가지 옵션들이 어떤 순서로 적용되는 지를 정리한다.

옵션으로 할 수 있는 작업은 DHCP클라이언트에게 Default Gateway, DNS서버, WINS서버 등의 TCP/IP의 추가 구성요소를 설정해 준다고 설명한 바 있다.

* 서버옵션 : DHCP서버에서 생성되는 모든 네트워크 범위에 공통적으로 적용될 옵션

* 범위옵션 : DHCP서버에서 생성되는 각 범위마다 고유한 옵션. 예제의 192.168.5.0 네트워크와 192.168.10.0 네트워크는 서로 다른 DNS서버등의 DHCP옵션을 구성하는 것이 가능하다.

* 클래스 옵션 : 특정한 OS나, 미리 정의된 사용자 클래스를 가지고 있는 클라이언트에게 발급되는 DHCP옵션

* 클라이언트 옵션 : 예약된 클라이언트에게 할당할 수 있는 DHCP옵션

귀찮긴 하지만 테스트를 해 보면 금방 이해할 수 있는 옵션들이다. 기본적인 사용방법은 간단하다. 모든 네트워크에 공통적으로 적용할 옵션은 '서버옵션'으로 부여하고, 003 라우터옵션 같은 각 범위마다 고유해야 하는 DHCP옵션은 범위옵션으로 설정하면 된다. 하나의 네트워크만 지원하는 DHCP서버를 구성하였다면 서버옵션과 범위옵션은 동일하다. 이들이 모두 구성되었을 때 DHCP클라이언트에게 적용되는 순서는 '서버옵션->범위옵션->클래스옵션->클라이언트옵션'와 같이 적용된다. 결국 클라이언트 옵션이 가장 우선시 되는 옵션이다.

4-5-5. APIPA (Automatic Private IP Addressing)

DHCP서비스를 이용하여 IP Address를 관리하는 것은 상당한 편의성을 제공한다. 그렇지만 막상 DHCP서버가 문제가 생겼다면 클라이언트들은 IP Address를 받을 수가 없게 되기 때문에 TCP/IP구성을 제대로 설정할 수 없다. 당연히 네트워크에서 TCP/IP통신은 하지 못하게 되는 것이다.

Windows2000, XP에서는 이러한 경우를 대비하여 한가지 대책을 포함하고 있다. 바로 APIPA라는 기능이다. 이 기능을 통해서 DHCP클라이언트가 서버로부터 IP Address를 받지 못하는 상황에 직면했을 때 클라이언트는 스스로 자신의 IP를 할당하는 방법을 통해서 TCP/IP구성을 마치게 된다. 이때 사용하는 Network ID는 169.254.0.0 이다. 이것은 B Class인 것을 알 수 있는데, 인터넷 환경에서는 찾아볼 수 없다. 개인네트워크를 위한 ID로 예약되어 있다. 기존에 정상적으로 네트워크에서 사용하던 IP와는 구분된다.

DHCP서버가 없는 상태에서 DHCP클라이언트는 1초, 2초, 4초, 8초, 16초 간격으로 계속해서 DHCP서버를 찾는 브로드캐스트를 날리게 되며 결국 마지막까지 DHCP서버로부터 응답이 없으면 169.254.0.0 범위에서 자신의 TCP/IP에 IP Address를 하나 직접 구성하며 그 IP가 현재 네트워크에서 사용되고 있지 않은지 확인한 다음 그때부터 해당 IP를 자신의 IP로 설정해서 사용한다. 완전한 통신은 되지 않지만 적어도 내부 네트워크의 DHCP 클라이언트들과는 통신을 계속 할 수가 있게 된다. 그러면서 이 DHCP클라이언트는 매 5초간격으로 지속적으로 DHCP Request메시지를 네트워크에 발생시키다가 다시 DHCP서버가 IP를 줄 수 있는 상태가 되었다면 DHCP클라이언트는 스스로 할당한 IP Address대신에 DHCP서버를 통해서 정상적인 IP를 받아오게 된다. 이 모든 것은 컴퓨터가 자동으로 처리를 해 주고 있다. 제법 똑똑해졌다. <그림4-54>을 보면 169.254.196.38 IP Address를 사용하던 클라이언트가 잠시후 다시 ipconfig를 해 보았더니 192.168.5.102 라는 IP를 할당받은 것을 보여준다. DHCP서버가 사용 가능해진 것이다.

하지만 DHCP서버가 없을 때 당연히 DHCP클라이언트 컴퓨터에서는 사용자가 꽤 느리다고 생각할 만한 부팅시간이 더 소모되어야 하고, 결국 제대로 통신이 되는 것도 아닌 상태가 되므로 DHCP서버를 중복배치하여 문제를 해결할 노력을 하는 편이 좋을 것이다. 조금 더 확장된 환경에서의 DHCP구성을 다음장에서 다루도록 하겠다.

4-5-6. DHCP서버 고급 옵션

DHCP관리콘솔의 왼쪽패널에서 DHCP서버의 이름을 클릭하고 등록정보를 열어보면 마지막탭에서 <고급>옵션을 찾아 볼 수 있다.

<그림4-55>에서 ‘충돌 감지 시도 횟수’ 옵션이 있는데 기본값은 ‘0’이다. 이것을 사용하면 네트워크에서 사용중인 IP Address를 DHCP클라이언트에게 할당하지 않도록 배려할 수 있다. DHCP프로세스는 단순하여 DHCP클라이언트가 서버에게 IP를 요청했을 때 서버는 자신의 IP영역에서 사용가능한 IP를 클라이언트에게 무조건적으로 할당하고 만다. 이때 만일 DHCP클라이언트가 서버로부터 할당받은 IP가 이미 다른 컴퓨터가 사용중이었다면 IP Address는 충돌이 발생하고 클라이언트는 TCP/IP를 사용하지 못하게 된다.

물론 잘 운영되는 네트워크 환경에서는 IP충돌이 발생하지 않아서 불필요한 트래픽을 유발시킨다고 생각될 수도 있지만 만일을 위해서 사용할 만한 옵션이다. 이 옵션이 체크되어 있으면 DHCP서버는 클라이언트의 IP임대요청을 받고 나서 IP영역에서 클라이언트에게 발급할 IP를 선택한 다음 해당 IP가 현재 네트워크에서 사용중인지 설정된 횟수만큼 체크하는 작업을 한다. 그리고 나서 사용되지 않는다는 것을 확인한 후 IP를 발급해주게 된다.

그 다음 2개의 경로박스는 DHCP서비스가 진행되는 모든 프로세스를 일단위로 로깅을 하는데 기본폴더 위치와, DHCP데이터베이스가 저장되는 위치를 변경할 수 있는 메뉴이다.

마지막의 <바인딩>버튼을 이용하면 DHCP서버의 특정 NIC를 통해서 들어오는 요청만 받아들인다든지, 요청을 거부한다든지 하는 설정을 할 수 있다. 기본적으로 DHCP서버는 모든 NIC로부터 들어오는 DHCP요청을 처리하도록 되어 있다.

DHCP클라이언트는 IP를 발급받을 때 DHCP서버로부터 임대기간도 넘겨받는다. DHCP클라이언트가 서버로부터 IP Address를 발급받고 나서 계속 시스템이 켜져 있다면 IP Address가 계속 필요하게 된다. 이때 DHCP클라이언트는 임대기간이 만료되기 발급받은 IP를 계속 사용하겠다는 연장신청으로 DHCP Request (Unicast)를 발송한다.

그 시점은 임대기간의 50%(1/2)가 되는 시점이다. 이 때의 요청은 맨 처음과는 분명히 다르다. DHCP클라이언트가 이미 서버로부터 발급받은 정상적인 IP Address를 가지고 있으므로 처음처럼 브로드캐스트를 이용하는 것이 아니라 유니캐스트를 이용한 DHCP Server와의 직접적인(direct) 통신을 진행하며, DHCP Process의 4가지 과정중 3,4번째인 Requst, Ack 절차만 진행된다.

그러면 DHCP서버는 연장신청을 받아주고, 새롭게 임대기간을 설정해서 DHCP클라이언트에게 Ack 메시지로서 응답을 한다. 이러한 과정 때문에 DHCP클라이언트는 한번 받은 IP를 지속적으로 쓰는 것이 가능하다. 그런 이유로 안정적인 네트워크에서는 DHCP를 사용하더라도 클라이언트의 IP는 거의 고정 IP를 쓰는 것과 별 차이가 없이 동작한다.

만일 1/2 시점에서 DHCP서비스의 문제로 인하여 클라이언트가 IP Address갱신을 실패한다면? 그렇더라도 클라이언트는 계속해서 기존의 IP Address를 가지고 정상적인 TCP/IP통신을 진행할 수 있다. 그런 다음, 임대기간의 7/8시점에 이르면 다시 DHCP초기과정을 진행한다. <그림4-32>에서 보자면 8일이 임대기간이었으니 7/8, 즉 7일째 되는 시간에 DHCP Request 브로드캐스트를 발생한다. 이때 클라이언트가 사용하던 IP Address를 갱신해줄 DHCP서버가 있다면 IP Address는 갱신이 되지만, 아무 응답이 없으면 다시 클라이언트는 DHCP Discover 브로드캐스트를 내보내어 새로운 DHCP서버를 찾는 작업을 하게 된다. 이때의 DHCP요청은 최초의 DHCP요청과 동일하다.

호스트가 DHCP Server에 IP Address를 요청하게 하기 위해서는 간단한 설정이 필요하다. 바로 DHCP Client로 설정을 해 주어야 하는 것이다.

먼저 TCP/IP등록정보를 실행해야 하는데, 바탕화면의 "네트워크 환경"을 마우스 오른쪽 클릭하여 "등록정보"로 접근한다. <그림4-24> 예제는 Windows XP Professional 이다. OS별로 인터페이스는 약간씩 다르지만 별 차이는 없다. 

만일 바탕화면에서 "네트워크 환경"아이콘을 찾을 수가 없다면 "제어판"을 열고 "네트워크 연결"이라는 메뉴를 찾아본다. 역시 버전마다 조금씩 차이가 있으니 "네트워크"라는 이름이 들어간 아이콘을 찾으면 될 것이다.<그림4-25>

네트워크의 등록정보를 열면 <그림4-26>와 같은 화면을 만날 수 있다.

<그림4-26>의 예제 화면에는 필자가 사용하는 전화접속 어댑터로 "Chollian"이 설치되어 있고, LAN 어댑터로는 Public, Private이라는 두 개의 어댑터가 설치되어 있다. 자세히 보면 "Public"은 "사용안함"상태로 되어 있다. 이것은 NIC가 없는 것과 동일한 상황이다.

기존에 있는 네트워크 연결을 관리할 때도 이 메뉴를 사용하지만 새로운 네트워크 연결을 추가할 때도 역시 이 메뉴를 사용한다. 회사의 전화접속서버에 원격으로 연결해서 회사의 네트워크에 접속을 할 경우나, 집에서 ADSL등의 초고속 인터넷 망에 연결할 때도 이 메뉴를 통해서 관리한다. TCP/IP등록정보로 접근하기 위하여 해당 NIC를 클릭하고 마우스 오른쪽 버튼을 이용하여 "등록정보(속성)"메뉴를 연다. 

이 어댑터 카드에 연결된 항목들의 리스트가 보이는데 인터넷 프로토콜(TCP/IP)을 선택하고 '속성'버튼을 누르면 TCP/IP등록정보로 접근한다.

TCP/IP등록정보를 열면 IP를 구성하는 방법이 두가지임을 알 수 있다. 자동으로 받는 방법과 다음IP주소 사용이라는 수동으로 구성하는 방법이 있다. "여기서 자동으로 IP주소받기"를 선택하면 바로 DHCP클라이언트가 된다. 구성을 하고 <확인>버튼을 누르면 Windows2000 이전버전의 OS에서는 시스템을 재시작해야 한다

"아래쪽에 자동으로 DNS서버주소받기" 옵션도 사용가능한 상태로 되는데 이것만을 별도로 DHCP를 통해서 받지 않고 수동설정도 가능하다. 수동으로 설정하면 DHCP서버가 할당해 주는 것보다는 우선해서 사용된다. 별도로 DNS서버 설정을 따로 할 이유가 없다. 역시 자동으로 할당받도록 구성한다.

이제 DHCP클라이언트 구성을 마쳤다. 클라이언트쪽에서 자신이 할당받은 IP Address를 확인하려면 특별한 명령어를 사용한다. ipconfig 가 그것이다. ipconfig에 대한 자세한 사용법을 원한다면 명령프롬프트를 열고 "ipconfig/?"라고 타이핑해 본다. 명령프롬프트에서 쓸 수 있는 명령어는 꽤 많다. 전체 명령어를 알려면 help 라고만 입력해 본다. help를 통해서 나오는 명령어들 하나하나가 특별한 옵션을 가지고 있는데 각 명령어들의 사용법은 역시 help나 /?를 통해서 알아 볼 수 있다.(예, c:\net help 또는 c:\net /? ) 자주 쓰는 명령어들에 대해서는 따로 정리를 하도록 하겠다.

그림에서는 ipconfig/all을 통해서 얻은 결과를 보여준다. bluexp라는 이름의 호스트는 IP Address로써 192.168.5.11을 사용하며 Default Gateway, DNS, WINS 등도 각각 구성되어 있음을 볼 수 있다. <그림4-29>에서 하이라이트된 부분을 통해서 DHCP Server가 192.168.5.1임을 알 수 있다. Lease Expires 라는 항목을 통해서 이 IP의 임대기간을 확인할 수도 있다. Windows 98 이전버전에서는 ipconfig 커맨드를 지원하지 않는다. 하지만 Windows9x에서는 시작-실행창에서 ‘winipcfg’를 이용하면 된다. 아무래도 사용자들의 데스크탑용 OS인 만큼 GUI 환경의 사용자 인터페이스를 제공한다.

당연히 DHCP서버쪽에서도 변화가 있어났다. DHCP관리콘솔을 열고 '주소임대'를 클릭해 보면 <그림4-30>의 오른쪽 패널에서 bluexp라는 이름의 호스트에게 192.168.5.11을  발급하였다.  

테스트 환경에서는 다음과 같은 커맨드도 유용한다. ipconfig/release, ipconfig/renew를 통해서 수동으로 DHCP Server로부터 할당받은 IP Address를 반납하고, 다시 받아오는 것을 확인할 수 있다.

위의 그림을 보면 ipconfig/release를 이용해서 서버로부터 임대해온 IP Address를 반납했다. IP Address가 0.0.0.0임을 보여준다. 다시 ipconfig/renew를 입력했더니 192.168.5.11 IP Address가 설정되었음을 볼 수 있다.

생각해 봅시다.

호스트수보다 IP Address가 부족한 상황에서 DHCP를 통해서 해결하고자 하는 관리자가 있는데 좋지 않은 방법이라 생각된다. 문제의 소지가 있기 때문이다. 하지만 경우에 따라서는 사용할 수는 있는 방법이다.

예를 들어서 IP Address는 50개를 가지고 있는데 호스트의 수는 100대라고 가정을 해 보겠다. 이 100대의 호스트중 동시에 켜져 있는 호스트가 보통 50대 미만이라면 켜져 있는 호스트에게만 적절히 IP Address를 발급해서 IP Address의 부족을 해결할 수 있을것이기 때문이다.

하지만 마이크로소프트의 DHCP는 기본적으로 IP를 할당받은 호스트가 시스템이 꺼진다고 해서 IP를 반납하는 것은 아니다. Windows2000, XP 컴퓨터들은 추가설정을 통해서 그러한 기능을 구현하는 것은 가능하지만 그밖의 OS에서는 지원되지 않고 있다. 그렇기 때문에 호스트가 꺼져 있더라도 임대기간동안 DHCP서버는 해당 호스트의 IP가 발급된 것으로 판단하고 새롭게 요청하는 DHCP클라이언트에게 그 IP를 발급해 주지 않는다.

해결책은 IP임대기간을 아주 짧게 설정하는 방법이 있다. IP임대기간을 30분으로 설정했다고 가정했을 때, 호스트가 꺼지게 되면 얼마 되지 않아 DHCP는 임대기간이 만료된 IP를 다시 사용가능한 IP상태로 돌리게 되는 것이다. 그러면 이 IP는 다시 새로운 DHCP를 클라이언트를 위해서 사용되는 것이 가능해진다. 이러한 임대기간의 조정으로 IP부족이라는 측면을 DHCP를 통해서 어느 정도 조절하는 것은 가능하지만 완벽한 솔루션은 아니라는 생각이 들 것이다.

 IP가 부족하다면 DHCP를 이용해서 해결하려고 하기 보다는 개인 네트워크 (Private Network, 사설네트워크)를 구성할 것을 고려해 보아야 한다. NAT, Proxy Server 등을 통한 개인네트워크의 구축은 회사의 IP절약은 물론 보다 향상된 보안까지 제공한다.

DHCP서비스를 구현하기 전에 가장 먼저 할 일은 네트워크에서 IP Address관리방법에 대한 결정이 있어야 한다. 클래스 전체를 하나의 네트워크에서 쓸 것인지, 서브넷팅을 통해서 사용을 할 것인지에 대한 결정이 되었다면 이번에는 각 네트워크마다 사용할 호스트ID의 범위중에서 어떠한 IP를 라우터에게 할당을 하고, 어떠한 IP를 서버들에게 할당을 할 것이고, 어떠한 IP를 DHCP를 통해서 클라이언트에게 할당한 것인지 등을 결정하는 과정을 의미한다. 간단하게 A회사의 IP Address 관리테이블을 만들어 보았다.

<그림4-4. A회사 IP Address 관리 테이블>

이제 클라이언트를 위한 DHCP서비스를 구현해 보도록 하겠다. 네트워크에는 DHCP서버가 있어야 하고, 당연히 클라이언트도 구성이 되어야 한다. DHCP서버는 네트워킹 서비스이므로 서버제품군에서 구현될 수 있다. 먼저 DHCP서버를 설정해 보겠다.

Windows Server 2003이 설치될 때 DHCP, DNS 등의 네트워크 서비스는 기본적으로 설치되지 않는다. 구현을 하고자 할 때 추가로 설치를 해야 하는데 제어판의 프로그램 추가/제거를 통해서 설치할 수 있다.

4-2-1. DHCP서비스 설치

제어판의 프로그램추가/제거를 열고 "Windows구성요소 추가"를 선택하면 잠시후 "Windows구성요소"창이 열린다. 리스트를 찾아보면 "네트워킹 서비스"가 있는데 이것은 DHCP, DNS, WINS 등의 네트워킹 서비스들 전체의 묶음이다. -네트워킹 서비스 앞의 체크박스를 클릭하면 전체 네트워킹 서비스들이 설치가 되므로 체크박스 대신에 글자 부분을 클릭한다.- <자세히>버튼을 누르면 리스트에서 "DHCP(동적 호스트 구성 프로토콜)"를 찾을 수 있다. 체크하고 <확인>을 누르면 설치를 시작한다. Windows서버의 원본CD-Rom이 요구된다. 원본CD중에서도 i386 폴더가 셋업을 위한 폴더이다. 원본CD위치를 묻는 메시지가 뜬다면 원본CD를 넣고 i386폴더를 지정해 주면 셋업이 시작된다.

잠시후 설치가 끝났다는 메시지가 나오면 DHCP서비스가 추가된 것이다. 관리도구에 "DHCP" 라는 관리메뉴가 추가된 것을 볼 수 있는데, 클릭하면 <그림4-6>과 같은 그림을 만날 수 있다.

그림을 보면 친절하게도 오른쪽 패널에 설치방법에 대해서 설명을 해 주고 있다. 그리고 왼쪽패널의 서버이름 부분을 보면 아래쪽으로 향한 빨간색 화살표를 확인할 수 있다. DHCP서비스가 멈춰져 있다는 것을 말한다.

4-2-2. DHCP권한부여 작업 - (Active Directory 도메인 환경에서만 적용됨)

<그림4-6>에서 오른쪽 패널의 설명을 읽어보면 "DHCP서버가 IP 주소를 발급하기 전에 범위를 만들고 DHCP서버에 권한을 부여해야 합니다"라고 이야기한다. 범위라 하면 클라이언트들에게 발급할 IP Address를 구성하라는 뜻인 것 같은데, 권한을 부여하라구? 이렇듯 Windows Server 2003 DHCP서비스는 설치만 한다고 동작하는 것이 아니다. DHCP서버가 동작할 수 있도록 권한이 부여가 되어야만 DHCP서버는 동작을 하게 된다.

이것은 아무나 할 수 있는 작업은 아니다. 도메인에서 이러한 작업을 할 수 있는 사용자는 기본적으로 "관리자"로 제한된다. 정확히 말하면 도메인의 "Enterprise Admins"라는 그룹의 멤버가 이러한 작업을 할 수 있다.

이것은 어디까지나 회사의 네트워크 환경이 Active Directory도메인으로 구성되어 있을 때의 상황이다. 만일 회사가 도메인 모델을 채택하지 않고 워크그룹 환경으로 구성되어 독립된 서버에서 DHCP서비스를 구현하고 있다면 이 과정은 건너 뛰고 바로 다음 작업인 DHCP서버 구성으로 넘어간다.

DHCP서버에 권한을 부여하기 위해서는 DHCP관리콘솔을 이용한다. 관리콘솔에서 서버이름을 클릭하고 마우스 오른쪽 버튼을 누른후 "권한부여"를 선택하면 간단히 권한이 부여된다. 권한이 부여된 DHCP서버의 리스트를 확인하거나, 여러대의 DHCP서버를 관리하고자 한다면 다른 방법도 있다. 관리콘솔에서 DHCP항목을 클릭하고 마우스 오른쪽 버튼을 누르면 "권한이 부여된 서버관리"라는 메뉴를 볼 수가 있다<그림4-8>

<그림4-8>의 메뉴를 클릭하면 Active Directory에서 권한이 부여된 DHCP서버의 리스트를 볼 수가 있고 다른 DHCP서버에게 권한을 부여하거나 리스트에서 DHCP서버를 제거하는 것도 가능하다.

DHCP서버에게 권한을 부여하고 나면 관리콘솔의 왼쪽패널의 서버이름 옆에 위로 향한 녹색 화살표를 확인할 수 있다. DHCP서비스가 시작된 것이고, 오른쪽 패널의 설명도 처음 DHCP서비스를 추가했을 때와는 다른 설명을 보여주고 있다. <그림4-10>

4-2-3. DHCP서버 구성

DHCP서비스가 시작되면 DHCP서버는 브로드캐스트를 통해서 DHCP Discover 메시지를 날리는 클라이언트에게 IP Address를 발급해 주어야 하는데 이렇게 하기 위해서는 당연히 DHCP서버는 클라이언트를 위한 IP Address Pool을 가지고 있어야 한다. IP Address 발급을 위한 범위를 만들고 클라이언트를 위한 추가설정을 해 주어야 하는 것이다.

예제에서 DHCP서비스를 하는 blueapple이라는 서버는 192.168.5.0 네트워크를 위해 IP를 발급하고자 한다.

서버이름을 클릭하고 마우스 오른쪽 버튼을 눌러서 "새 범위"를 추가한다. 

범위이름을 입력해야 하는데, 이것은 실제 서비스와는 아무런 상관이 없다. 관리자가 알아보기 쉽게 이름과 설명을 주면 된다. 여러개의 네트워크를 DHCP서버가 지원해야 할 때 각각의 범위를 구별하기 쉽게 이름을 부여한다. 예제에서는 '2층 네트워크'라고 입력했다. 

DHCP클라이언트에게 발급할 IP Address의 범위와 적합한 서브넷마스크를 입력해야 한다. 하나의 DHCP서버는 하나의 네트워크당 하나의 IP범위 관리영역만 가질 수가 있다는 것을 염두에 둔다. 만일 192.168.5.11~100까지가 DHCP클라이언트용 IP Address라고 가정을 했을 때, 51~60까지가 서버들에게 고정IP로 발급한 부분이라서 제외해야 한다고 하더라도 192.168.5.11~50까지의 하나의 범위를 만들고 추가로 192.168.5.61~100까지의 영역을 만들 수는 없다. 그럴 경우에는 일단 전체범위를 잡은 다음에 고정IP로 사용할 IP가 범위에 포함되어 있다면 다음 과정에서 그 특정범위만큼을 제외하는 방법을 사용해야

필요하다면, IP범위중에서 제외할 특정 IP나 IP범위를 추가한다. DHCP서버는 단순한다. 클라이언트가 IP를 요청했을 때 자신의 IP범위중에서 사용가능한 IP를 골라서 망설이지 않고 IP 발급을 한다. 만일 Web서버에게 192.168.5.20 IP Address가 셋팅되어 있다고 가정을 했을 때, DHCP서버의 설정에192.168.5.20 IP가 사용가능한 상태로 되어 있다면 DHCP클라이언트는 192.168.5.20 IP를 발급받게 된다.

이 경우 네트워크에서 이미 사용되고 있는 IP를 발급받은 해당 클라이언트는 정상적으로 TCP/IP를 사용할 수가 없게 된다. 관리자가 해결해 주면 되겠지만 간혹의 경우에는 먼저 이 IP Address가 설정된 Web 서버가 제대로 동작하지 못하는 경우가 발생할 수도 있으므로 IP Address의 충돌이 생길 소지가 있는 부분에는 특별히 신경을 써야 한다.

Windows2000 이상의 서버에서 DHCP서비스를 구현한다면 서버의 고급옵션에서 ‘충돌감지시도횟수’를 할당하여 DHCP클라이언트에게 IP를 할당하기 전에 먼저 IP사용유무를 테스트하게 할 수도 있다. 이번장의 후반부에서 다시 한번 언급된다.

<그림4-14>에서 보듯이 제외할 주소를 추가하는 방법은 두가지이다. IP Address를 하나씩 추가할 수도 있고, 범위를 지정해서 추가하는 방법이 있다.

클라이언트에게 IP를 발급할 때 결정해 줄 임대기간을 지정한다. 기본값은 8일이다. 임대기간이 길어질수록 IP Address 갱신주기가 길어질 것이기 때문에 IP Address가 충분히 여유가 있다면 기간을 더 길게 설정하는 것이 좋다. 네트워크에서 DHCP트래픽의 비중은 극히 일부분이지만 DHCP 관련된 네트워크 트래픽을 최소화 할 수 있는 방법이 된다. 반대의 상황이라면? 당연히 기간을 줄여야 할 것이다.

지금까지 위에서는 클라이언트에게 발급할 IP Address와 Subnet Mask를 구성하였는데, 클라이언트들의 TCP/IP설정에는 Default Gateway, DNS, WINS등의 추가 설정이 필요하다. DHCP서버는 이러한 사항들을 'DHCP옵션'으로 처리해 주고 있다. DHCP옵션을 구성하는 그림이 나오는데 지금 구성할 수도 있고, 나중에 추가로 작업하는 것도 가능하다. "아니오"를 통해서 마법사를 마쳐도 기본적인 DHCP구성은 끝난 것이다. 계속 구성을 해 보도록 하겠다. 

클라이언트에게 할당할 Router, 즉 Default Gateway로 설정될 IP Address를 입력하고 <추가>버튼을 누릅니다.

DNS를 구성하는 과정인데 <그림4-18>의 예제처럼 IP주소만 입력해 주어도 동작하는 데는 문제가 없다. 그렇지만 도메인 환경에서의 작업을 고려한다면 부모도메인의 항목에도 도메인 이름을 입력할 필요가 있다. 예를 들어서 사용자가 속한 도메인이 secure.pe.kr 이라고 하면 '부모도메인'항목에 'secure.pe.kr'이라고 입력을 한다. 그렇게 해 주면 사용자가 hostA.secure.pe.kr 이라는 이름의 호스트를 찾고자 할 때 hostA 라고만 입력을 해도 실제 DNS에 쿼리가 날아갈 때는 hostA.secure.pe.kr 라는 이름으로 요청을 한다.

또한 DNS서버의 IP를 하나만 주는 것보다는 2개를 할당하여 하나의 DNS서버가 문제가 있을 경우를 대비하는 것이 좋다. DHCP클라이언트는 DNS서버의 IP를 2개를 가지게 되며 첫 번째 DNS서버가 문제가 있을시 두 번째 DNS서버를 통해서 호스트이름을 IP Address로 변환하는 작업을 처리할 수 있다. 회사에 DNS서버가 하나만 구현이 되어 있다면 추가로 ISP의 DNS등, 외부의 DNS서버를 두 번째 DNS서버로 셋팅하는 것도 하나의 방법이다. DNS는 아주 중요한 서비스중의 하나이다. DNS에 대해서는 5장에서 자세히 다루도록 하겠다.

WINS서버의 IP를 입력한다. 역시 하나보다는 두 개를 사용하는 것이 좋다. 물론 네트워크에 WINS서버가 적어도 2개 이상 있다는 전제가 따라야 한다. WINS서버는 "NetBIOS이름풀이"를 위해 필요한 서버이다. 6장에서 자세히 다룬다.

이제 옵션구성도 끝났다. 192.168.5.0 네트워크의 IP범위를 활성화 할 필요가 있다. 활성화 하기 전까지는 DHCP서버는 클라이언트의 요청에 응답하지 않다. 만일 추가로 구성을 더 해야 할 필요가 있다면 "아니오. 나중에 활성화하겠다."를 선택해서 DHCP서버가 IP를 발급하지 못하도록 한다. 나중에 DHCP관리콘솔을 통해서 얼마든지 활성화 작업은 가능하다.

 DHCP서버에 '새 범위 마법사'를 완료하는 그림이다.

<그림4-22>에서는 blueapple.secure.pe.kr 이라는 이름의 DHCP서버에 192.168.5.0 네트워크의 IP범위가 설정된 그림을 보여준다. 왼쪽패널의 '주소풀'을 클릭하면 오른쪽으로 IP주소 범위를 보여주는 그림을 볼 수 있다. 그림을 보면 192.168.5.11부터 192.168.5.100 까지가 범위로 되어 있고, 두 번째 리스트에는 192.168.5.20이 제외된 IP주소임을 보여준다. 결국 이 설정에서는 192.168.5.11~192.168.5.19, 192.168.5.21~192.168.5.100까지 총 89개의 IP가 사용가능하다는 것을 알 수 있다. 

DHCP관리콘솔의 192.168.5.0 범위의 '범위옵션'을 눌러보면 오른쪽 패널에 위에서 설정한 몇가지 DHCP옵션이 나오는 것을 확인할 수 있다. 이것은 마이크로소프트의 네트워크를 구축할 때 항상 따라다니는 기본 DHCP옵션들이다.

각 옵션값들의 설명은 각각의 장에서 따로 다루도록 한다.

이제 DHCP서버의 구성은 마쳤다. 다음엔 DHCP클라이언트의 설정을 구성해야 할 차례이다. 그래야 이 DHCP서버로부터 TCP/IP 구성을 받아갈 수 있다.

당신은 회사의 시스템 관리자이다. 사용자들이 네트워크 활동을 할 수 있도록 하기 위해서는 네트워크의 모든 호스트에게 IP Address를 할당하는 작업이 필요하다. 처음 한번만 잘 해주면 된다는 생각에 일일이 수작업으로 PC마다 IP Address를 잘 설정해 주었지만 심심치 않게 새로운 시스템도 늘어나고, 몇몇 사용자들의 호기심(?) 때문에 툭하면 IP Address로 인한 네트워크 장애가 발생하고 있다. 한 두 대도 아니고 수 많은 시스템을 관리해야 하는 관리자로서는 이러한 작업이 부담이 될 수 밖에 없다.

이러한 IP Address 관리작업을 자동화하면 해결된다. 바로 DHCP (Dynamic Host Configuration Protocol)가 그 해답이다.

마이크로소프트는 서버OS제품군에서 DHCP서버 서비스를 지원한다. 이때 DHCP서버로 셋팅된 컴퓨터는 클라이언트들에게 할당할 IP Address Pool을 유지하고 있으면서 DHCP프로토콜을 이용해서 IP Address발급을 요청하는 클라이언트에게 IP Address를 할당한다.

DHCP서비스를 DVD대여점의 프로세스와 유사하다. DVD 대여점이 DVD타이틀을 대여한다면 DHCP서버는 IP Address를 대여하는 역할을 한다. 완전히 소유권이 넘어간 것이 아니라 임대의 형식을 이용하는 만큼 당연히 기간이 만료되기 전에 반납을 해야 하며, 계속 임대를 원한다면 갱신요청을 보내서 임대기간을 연장해야 한다. 아래의 <그림4-1>과 같은 환경을 가정해 보자.

<그림4-1>에서 볼 수 있듯이 하나의 네트워크가 있고, 그 네트워크에는 DHCP서버, DHCP클라이언트, Non-DHCP클라이언트가 있을 수 있다. Non-DHCP클라이언트는 DHCP서버로부터 IP를 할당받지 않고 고정IP를 설정한 호스트를 의미한다. DHCP클라이언트는 IP Address가 변경될 수 있는(유동의) 소지가 있는 호스트이므로, IP가 변경됐을 때 네트워크의 원활한 소통에 문제가 있을 수 있는 서버역할을 하는 컴퓨터들의 경우는 고정 IP를 할당해야 한다. 예를 들면 웹서버, DNS서버, 메일서버, 도메인컨트롤러 등 서버들의 경우이다.

DHCP클라이언트는 시스템이 시작됨과 동시에 DHCP서버를 찾는 메시지를 네트워크에 발송하여 IP Address임대를 요청하게 되며, DHCP서버는 이러한 클라이언트의 요청에 응답하여 자신의 DHCP Database에서 IP Address를 임대한다. 그 과정을 <그림4-2>와 같이 정리하였다.