5-4. DNS Server관리 Windows Networking2008. 11. 17. 12:50
앞에서 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주소이다.
< 그림5-56. DNS Zone 등록정보의 "영역전송"탭 >
준비가 되었으면 이제 Secondary DNS Server를 설치해 보자. 과정은 지난 장에서 소개한 것과 큰 차이가 없으므로 어렵지 않을 것이다.
|
|
‘정방향 조회 영역’에서 마우스 오른쪽 클릭하고 ‘새 영역’을 선택한다. |
|
|
다음 그림에서 "보조영역"을 선택해야 한다. 보조DNS서버를 추가하기 위한 과정이다. |
|
|
|
|
|
|
|
|
|
다음의 <그림5-62>를 보면, 콘솔 오른쪽에 많은 정보가 전송되어 왔음을 확인할 수 있다. 이제부터 REDAPPLE라는 이름의 DNS서버는 secure.pe.kr 도메인의 Secondary Zone(보조영역)을 가지고 서비스를 할 수 있게 되었다.
< 그림5-62. Secondary DNS서버에 보조영역이 완성된 화면 >
5-4-1-2. Zone Transfer (영역전송)
두번째 DNS서버가 추가되는 과정에서 영역전송이 진행된다. Zone transfer는 엄밀히 따지면 서버대 서버의 작업이 아니다. 서버의 Zone과 Zone간의 작업이라고 하는 편이 정확하겠다. 영역전송과정은 자동으로 일어난다. 이 과정에 대한 설정 역시 DNS서버에서는 하나의 레코드로 처리되고 있다. "SOA(Start of Authority)"레코드가 바로 그것이다.
Secondary DNS가 마스터DNS를 통해서 영역전송을 하고자 할 때 처음 요청하는 레코드가 바로 이 SOA레코드이다. <그림5-63>은 마이크로소프트의 네트워크모니터 툴을 사용해서 Zone transfer과정을 캡춰한 내용을 보여준다.
< 그림5-63. DNS서버간 영역전송capture그림 >
그림에서 하이라이트된 부분이 Secondary DNS Server가 마스터DNS Server에게 SOA레코드를 요청하는 패킷이다. 바로 아래에는 마스터로부터의 응답이 오고 있는 것이 보여진다. Secondary DNS에서 마스터DNS Server로부터 영역전송을 받기 전에 가장 먼저 SOA레코드에 대한 요청이 이루어졌다. SOA레코드에 어떤 정보가 담겨 있는지 확인해본다.<그림5-64>
< 그림5-64. DNS Zone등록정보 SOA Record정보 >
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서버로 요청을 보낼 일이 없다. 어디까지나 백업 차원에서 제공되는 것이다.
< 그림5-66. DNS클라이언트 DNS서버 할당 >
위와 같이 구성하면 4장.DHCP 를 설명하면서 언급을 했던 ‘기업 네트워크에서 네트워크 서버 배치시 고려할 사항’중에서 성능,가용성,기능성 측면을 모두 만족하는 서버배치를 하고 이를 구현하는 것이 가능해 진다. 잘 고려해 보자.
처음에 전반적인 개요를 설명할 때 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. SRV Record >
<그림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-68. DHCP서버와 DNS서버의 연동 >
< 그림 5-69. DHCP서버와 DNS서버의 연동 >
5-4-5. Active Directory 통합영역 사용
DNS를 설치하고, 관리할 도메인에 대한 관리영역(zone)을 추가하다 보면 영역의 종류를 결정하는 항목이 나온다. 아래의<그림5-70>을 참고한다.
< 그림5-70. Zone type 변경 >
'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통합영역'을 사용하면 동적업데이트 옵션에서 "보안된 항목만"을 사용할 수 있게 된다.
< 그림5-71. Secure Update >
지금까지 Windows Server 2003의 DNS 를 기준으로 몇가지 기능과 관리방법에 대해서 설명하였다. 다음 장에서는 마지막으로 DNS Server의 문제점을 해결할 수 있는 진단도구와 해결방법에 대해서 알아보겠다.
