여기서는 DNS의 몇 가지 중요한 측면들에 대해 살펴보고자 한다. 만일 네트웍상에 Windows 2000을 설치할 계획이라면, 또는 Windows 2000 시험을 통과하고자 한다면 반드시 여러분은 DNS에 대한 전문가가 되어야 한다. 이 첫번째 문서에서는 네트웍상에서의 DNS의 다양한 역할에 대해 살펴볼 것이다.
1. 주(Primary) DNS 서버
주 DNS 서버는 네트웍 영역 데이터베이스의 기록 가능한 복사본만을 가진다. 또한 그 영역 데이터베이스 파일들에 포함되어 있는 도메인들에 대한 권한을 가지므로 DNS 질의에 대해 직접적으로 응답을 할 수 있다. 보조 DNS 서버 역시 영역 데이터베이스 파일들에 포함된 도메인들에 대한 권한을 가진다. 이것이 주 DNS 서버가 Start of Authority 레코드를 가지는 이유이다. 즉 주 DNS 서버가 권한 사슬의 시작이지만 끝이 아님을 나타내고 있다.
주 DNS 서버 뿐만 아니라 다른 모든 DNS 서버들은 다음과 같은 특성들을 가진다.
- %systemroot%\system32\dns 디렉토리에 저장된 영역 데이터베이스 정보
- DNS 질의에 대한 결과를 캐쉬하는 능력
- cache.dns( “root hints” 파일) ? 인터넷 DNS 루트 서버들에 대한 IP 주소 매핑을 위한 호스트 이름을 포함하고 있다.
표준 영역의 경우 영역 파일들은 %systemroot%\system32\dns 디렉토리에 저장되고 영역 파일들의 이름은 영역 이름에 “.dns”라는 확장자가 붙어서 만들어진다. 다음 주쯤에는 DNS 영역을 활성화하는 액티브 디렉토리를 구현하는 것을 살펴볼 텐데, 이 경우 영역 데이터베이스 정보는 텍스트 기반의 영역 데이터베이스 파일이 아닌 액티브 디렉토리에 저장된다.
DNS의 질의 캐싱
모든 DNS 서버는 그들이 처리하는 질의의 결과를 캐쉬한다. 하나의 DNS 서버가 다른 DNS 서버에 반복적으로 질의를 던질 때 그 서버는 자신의 캐쉬에 질의 결과를 저장한다. 캐쉬되는 정보는 디스크가 아니라 시스템 메모리에 저장되는데 메모리가 부족할 경우에는 페이지 파일에 저장된다. 캐쉬되는 정보는 거의 RAM에만 저장되기 때문에 서버가 재부트되면 잃어버리게 되므로 DNS 서버는 재부트가 안되는 동안에 가장 효과적으로 동작하는 것이다.
DNS 서버의 Negative Caching
Windows 2000 DNS 서버는 negative caching을 지원한다. 만약 도메인 이름 검사가 결과를 만들어내는데 실패할 경우 DNS Client Service는 부정적인 결과를 만들어 낸 호스트 명을 기억하게 된다. 그리고 디폴트로 다음 5분 동안 그 서버는 도메인 이름 검사를 하지않고 자신의 캐쉬로부터 부정적인 응답을 계속 내보내게 된다. 만약 DNS 클라이언트가 자신이 질의한 모든 서버들로부터 부정적인 결과를 받게되는 경우에는 즉각적으로 부정적인 응답을 응용프로그램으로 리턴하고 DNS 서버에게 질의를 하지 않게 된다.
첫번째 경우에서의 중요한 점은 DNS 클라이언트가 여전히 DNS 서버에게 질의를 하고 있으며 DNS 서버는 자신의 캐쉬에 있는 부정적인 결과로 응답을 한다는 것이다. 두번째 경우에서는 DNS 클라이언트가 30초 동안에는 절대 DNS 서버에게 질의를 하지않으며 응용프로그램에게 부정적인 결과를 리턴한다. 이 negative caching은 오류가 난 사이트에 질의를 하지 않음으로써 DNS 관련 네트웍 트래픽을 감소시키는데 도움을 준다.
루트 힌트 파일
cache.dns 파일( Root Hints 파일이라고도 한다)은 루트 인터넷 DNS 서버들의 호스트 명과 IP 주소 매핑을 가지고 있다. 만약 DNS 서버가 자신의 권한외의 도메인에 대해 재귀적 질의를 받게 되면 반드시 여러 DNS 서버들을 거쳐가는 반복적 질의를 발생시켜서 재귀적 질의를 끝내야 한다. 반복적 질의 처리는 DNS 질의의 목적 도메인이 DNS 서버의 캐쉬에 존재하지 않을 경우 루트 DNS 서버에서 시작한다.
DNS 서버의 다중 도메인에 대한 권한
많은 Windows NT 4.0 MCSE들은 DNS 서버가 다중 도메인에 대한 권한을 가질 수 있다는 사실을 모르고 있다. 예를들어, swink.com DNS 영역 파일은 swink.com과 sql.swink.com에 대한 권한을 가지고 있다. 이들 도메인에 대한 권한을 가지고 있기 때문에 어떤 요청을 해결하기위해 다른 DNS 서버에게 반복적으로 질의를 던질 필요가 없어진 것이다.
2. 주 DNS 서버와 보조 DNS 서버의 차이
주 DNS 서버는 보조 DNS 서버가 될 수 있다. 즉, 다른 주 서버로부터 영역 전송자를 받는 주 DNS 서버는 보조 서버로서의 역할을 하는 것이다. 어떠한 DNS 서버도 주 서버나 보조 서버 혹은 둘 다의 역할을 할 수 있다. 주 서버와 보조 서버 사이의 차이점은 주 영역 파일은 기록이 가능한데 반하여 보조 영역 파일은 읽기만 할 수 있다는 데에 있다.
보조 DNS 서버
공용 도메인 네이밍 시스템은 각 영역에 대한 권한을 가지는 최소 두개의 DNS 서버를 포함하도록 설계되었다. 일반적인 DNS 서버 셋업에서는 이들 중의 하나가 주 서버가 되고 다른 하나가 보조 서버가 된다. 보조 DNS 서버는 다음 기능을 제공하고 있다.
- Fault Tolerance(오류에 대한 내성)
주 DNS 서버가 갑자기 동작을 하지않는다 해도 보조 서버가 그 영역에 대해 질의에 응답할 수 있는 권한을 가진다. - Load Balancing(부하의 균등 분배)
여러 서버에 질의의 부하를 균등 분배함으로써 주 서버에 과다한 DNS 질의 트래픽이 발생하지 않는다. - Reduction is Bandwidth Requirements
보조 서버를 원거리 지역에 두되, 이름을 풀기위해 WAN을 따라 검색해 나갈 필요성을 감소시킬수 있는 지역에 둘 수 있다.
오류 내성
주 서버와 마찬가지로 보조 DNS 서버는 영역 데이터베이스 파일을 포함한다. 보조 서버는 영역 전송자를 통해 영역 파일의 복사본을 받는다. 그 영역에 대한 주 DNS 서버는 Master Server로서 동작하고 영역 전송자를 통해 보조 서버에 그 영역 파일을 복사한다. 보조 서버들은 DNS 클라이언트의 질의에 응답을 할 수 있게 되고 따라서 그들이 포함하는 영역에 대해 권한을 가진다. DNS 클라이언트의 환경 설정시 오류 내성을 지니기 위해 주 DNS 서버와 보조 DNS 서버의 IP 주소를 기록한다. 그러므로 주 서버가 동작을 하지 않는다 하더라도 보조 서버에게 질의를 보냄으로써 name resolution service는 계속적으로 지원된다.
Load Balancing과 네트웍 대역폭 유지
여러 DNS 서버들 사이에 질의 부하를 분배할 수 있다. 모든 클라이언트 컴퓨터들이 하나의 주 서버에게 동시에 질의를 하는 경우 그 DNS 서버는 과도한 질의 부하에 걸리게 된다. 이를 해결하기 위해 서로 다른 세그먼트에 있는 클라이언트들은 자신의 지역에 있는 보조 서버에게 질의를 보내도록 설정될 수 있다. 이렇게 함으로써 질의 부하를 주 서버와 보조 서버들 사이에 분배시킬 수 있다.
오류 내성, 부하 균등분배, 네트웍 대역폭 유지 기능은 보조 DNS 서버가 왜 필요한지에 대한 적절한 사유를 보여주고 있다. 만약 여러분이 인터넷 상에 자신의 DNS 서버를 유지하고자 할 경우 Domain Register는 여러분에게 최소 하나의 주 서버와 2차 수준 도메인을 위한 하나의 보조 DNS 서버를 가지도록 요구할 것이다.
다음 글에서는...
다음 글에서는 DNS 서버의 역할에 대해 자세히 살펴보고 다른 중요한 역할들은 어떤 것들이 있는지 체크해 보고자 한다. 특별히, Caching Only Sever, Forwarders, Slaves 를 다룰 예정이다. DNS Forwarders와 DNS Slave Servers는 보안 인프라 측면에서 특히 중요한 부분이다. 다음 글을 절대 놓치지 말기를 바란다.
DNS에 관한 추가 정보
DNS에 관한 추가적인 정보는 여기에 있는 Implementing and Administering a Windows 2000 Network Infrastructure(70-216) 시험을 위한 Syngress/Osborne 스터디 가이드를 참조하기 바란다.
Windows 2000 DNS 서버에 대한 기술적인 상세 정보를 얻을려면 여기에 있는 마이크로소프트 기술백서를 참조하기 바란다.
3. Caching Only Servers
모든 DNS 서버는 질의 결과를 캐쉬한다. 그러나 어떤 DNS 서버들은 이 캐쉬 기능만을 가지고 있는데 이를 Caching-Only DNS 서버라고 한다. Caching-Only DNS 서버는 영역 정보나 영역 데이터베이스 파일은 가지지 않으며 이전에 처리했던 질의의 결과만을 가진다. 이러한 경우 캐쉬가 영역 데이터베이스 파일 역할을 하게된다. 이들 Caching-Only DNS 서버는 빠른 시간내에 셋업될 수 있으므로 네트웍과 인터넷 보안 설계에 있어서 매우 중요한 서버라 할수있다.
모든 DNS 서버는 모든 인터넷 루트 서버의 IP 주소를 포함하고 있는 cache.dns 파일을 가진다. 이 Windows 2000 cache.dns 파일은 root hints 파일로도 불려진다. Caching-Only DNS 서버는 자신의 캐쉬를 구축하기위해 이 파일의 내용을 사용하는데, 질의를 반복해서 던짐에 따라 Fully Qualified Domain Names을 IP 주소로 변환 요청하는 클라이언트에게 제대로 응답할 때 캐쉬에 그 서버를 추가한다. FQDN을 IP주소로 변환한 후에 이 정보는 DNS 서버 캐쉬에 저장된다.
Caching-Only DNS 서버는 다음 몇가지 이유로 중요한 가치를 가진다.:
- Caching-Only DNS 서버는 영역 전송자에 포함되지 않기 때문에 영역 전송 트래픽이 없다.
- 느린 WAN 링크의 한쪽 끝에 위치하면서 고수준의 호스트 이름 변환 지원이 필요치 않은 원거리 지점의 호스트 이름 변환을 제공한다.
- Forwarders로서 설정된 경우 안전한 호스트 이름 변환을 제공하도록 구현될 수 있다.
원거리 지점은 종종 느린 WAN 링크를 통하여 본점에 연결된다. 이런 경우 Caching-Only DNS 서버를 사용하면 다음과 같은 잇점을 가진다.
- 영역 전송에 따른 트래픽이 없다. 작은 원거리 지점들을 가지고 있는 큰 기업의 인트라넷의 경우에 영역 전송 트래픽을 제거함으로써 속도가 느린 링크를 사용하는데 있어서 커다란 장점을 가지게 된다.
- WAN 상에서 기업의 DNS 서버들을 찾아 다니는 DNS 질의 트래픽을 상당량 감소시킬 수 있다.
이들 Caching-Only DNS 서버는 전문가적인 관리를 필요로 하지 않는다. 그러므로 각 지점마다 자신의 사이트에 전문적인 DNS 관리자를 둘 필요가 없는 것이다. 이것은 비용 감소 효과를 가져온다. 그러나 Caching-Only DNS 서버로부터 최대한 잇점을 얻기위해서는 컴퓨터를 재부팅해서는 안된다. 왜냐하면 DNS 캐쉬는 때때로 페이지 형태로 디스크에 존재하기도 하지만 대부분 RAM에 존재하기 때문에 서버가 재부팅되면 캐쉬의 내용이 모두 없어지기 때문이다. UPS, 디스크 미러링, 여러 개의 전원 공급 장치 등과 같은 오류에 대비한 여러 기법들을 적용해야 한다.
다음 글에서는 DNS Forwarders에 대해 살펴볼 것이다.
4. DNS Forwarders와 Slave Servers
Forwarder는 질의 사슬에서 DNS 서버 다운스트림으로부터 재귀적 질의를 받아들이는 DNS 서버이다. Caching-Only 서버는 좋은 forwarder이다. Caching-Only forwarder는 인터넷 상에서의 침입자로부터 내부 영역 파일들을 보호하기 위해 사용될 수 있다.
예를들어, DNS 클라이언트는 인터넷상에 존재하는 호스트에 대해 자신의 주 DNS 서버에게 재귀적 질의를 보낸다. DNS 클라이언트의 주 DNS 서버는 기업 내부 네트웍에 존재하기 때문에 질의에 포함된 도메인에 대한 권한을 가지지 않을 것이다.
주 DNS 서버는 클라이언트가 질의한 호스트 이름을 IP 주소로 변환하거나 그렇지 못하고 실패할 경우에는 오류를 내보낸다. 여러분은 DNS 클라이언트의 주 DNS 서버가 자신이 권한을 가지지 않는 영역에 대한 모든 질의를 forward하도록 환경 설정을 할수 있다. 그런 다음 이 DNS 서버는 자신의 Forwarder로 설정된 DNS 서버에게 재귀적 질의를 보내게 된다.
Forwarding과 Forwarder Servers
먼저 용어에 대해 분명하게 이해를 해야할 필요가 있다. 이 예에서 클라이언트의 주 서버는 “forwarder”로의 요청을 “forwarding”한다. 클라이언트의 주 서버는 forwarding DNS 서버이고 forwarding 서버로부터 질의를 받는 DNS 서버는 Forwarder이다. 그러므로 DNS 질의를 포워딩하는 하는 프로세스는 forwarding DNS 서버와 forwarder DNS 서버 둘 다를 포함한다.
Forwarders를 이용한 호스트 이름 검색
Forwarder DNS 서버는 자신의 캐쉬나 영역 파일로부터의 정보를 검색하거나, 또는 일련의 질의를 반복적으로 던짐으로써 질의에 포함된 호스트 이름을 변환한다. 만약 변환이 성공적이면 재귀적 질의에 응답을 하고 IP 주소를 forwarding DNS 서버에게 반환한다. forwarding 서버는 이 IP 주소를 질의를 처음 만들었던 DNS 클라이언트에게 반환함으로써 자신의 재귀적 질의를 끝마친다.
만약 forwarder DNS 서버가 호스트 이름을 IP 주소로 변환하지 못할 경우에는 forwarding DNS 서버에게 “host not found”라는 오류를 반환한다. 이럴 경우 주 DNS 서버(forwarding DNS 서버) 스스로 호스트 이름을 변환하려고 시도한다. forwarding 서버는 호스트 이름을 변환하기위해 자신의 캐쉬, 영역 파일을 체크하거나 질의를 반복적으로 수행할 것이다. 만약 forwarding 서버도 성공하지 못하면 최종적으로 “host not found” 혹은 이와 유사한 오류가 클라이언트에게 반환된다.
여러분은 forwarding DNS 서버가 인터넷상에 존재하는 서버들에게 질의를 반복적으로 전달하기를 원하지 않을수도 있다. 이런 경우는 forwarding 서버가 내부 DNS 서버인 경우이다. 인터넷 호스트 이름 변환을 위해 질의를 반복적으로 전달하는 내부 DNS 서버는 여러분의 내부 호스트 이름 구조에 관한 정보를 탐색하려는 해커들에게는 좋은 타겟이 될수 있다.
여러분은 forwarder 서버가 올바른 IP 주소를 반환하지 못할 경우에 forwarding 서버가 대신 호스트 이름을 변환하는 것을 하지 못하도록 환경 설정 할수 있다. forwarding 서버가 이런 식으로 환경 설정되면 그 서버는 slave 서버가 된다. slave 서버는 forwarder로부터 응답을 받을 때 forwarder 서버가 질의에 응답할 수 없는 경우일지라도 그 스스로 호스트 이름을 변환하려고 하지 않고 곧바로 forwarder의 응답을 클라이언트에게 전달한다.
다음 글에서는 Slave Servers에 대해 살펴볼 것이다.
5. Forwarders 와 방화벽
Slave 서버와 Caching-Only forwarder를 같이 둠으로써 여러분의 인터넷 영역 데이터를 보호할 수 있다. 이 두 서버의 조합은 내부 DNS 서버에 있는 정보에 접근하기위해 방화벽의 반대 측면으로 접근하는 사용자들을 막기위해 사용될 수 있다.
예를들어, tacteam.net에 기업내의 시스템들에 대한 DNS 요청을 처리하기 위해 사용되는 하나의 내부 DNS 서버가 있다. DNS에게 보내지는 요청이 내부 네트웍상에 존재하는 호스트들에 대한 것일 경우, 이 DNS 요청은 어떤 위험 요소도 가지지 않는다. 그러나 내부 내트웍상의 사용자가 인터넷상의 어떤 자원들을 접근하고자 하는 경우에는 어떤 일이 발생할 것인가?
내부 사용자들 중의 한명이 www.funtimes.com에 접근하려고 한다면 어떻게 될까? 재귀적 요청이 내부 DNS 서버에 도달했을 경우(내부 DNS 서버는 tacteam.net에 대해서만 권한을 가진다) 서버는 어떻게 동작할까? 그럴경우 DNS 서버는 요청된 인터넷 호스트 이름을 변환하기 위해 인터넷 상에 있는 다른 DNS 서버들에게 반복적으로 질의를 보낸다. 처리 과정에서 인터넷 DNS 서버는 자신의 응답을 방화벽을 통하여 내부 DNS 서버에게 직접 보내야 한다. 이럴 경우 방화벽은 반드시 인터넷 DNS의 응답이 내부 DNS 서버에게 전달될 수 있도록 인터넷 상의 사용자를 위해 개방 포트를 가져야 한다. 이것은 인터넷상의 사용자에게 내부 DNS 서버와 그 서버의 영역 데이터, 그리고 내부적인 질의 형태를 공개하게 되는 것이다. 이런 잠재적인 위험 상황을 어떻게 극복할 것인가?
해결책
방화벽 바깥에 Caching-Only forwarder를 두고 내부 DNS 서버를 slave 서버로 설정한다. 그런 다음 클라이언트들 중의 하나가 내부 DNS 서버로 내부 호스트에 대한 이름 변환을 요청했을 때 내부 서버는 그 요청을 방화벽 바깥에 있는 forwarder에게로 포워딩시키면 Forwarder가 요청된 호스트 이름을 IP 주소로 변환하려고 한다. 만약 변환이 성공되면 forwarder는 변환된 IP 주소를 내부 DNS 서버에게 반환하게 되고 내부 DNS 서버는 다시 클라이언트에게 그 IP 주소를 전달하게 된다. 만약 forwarder가 주소 변환에 실패하게 되면 내부 DNS 서버에게 실패했음을 알리게 되고 다시 내부 DNS 서버는 클라이언트에게 호스트를 발견할 수 없다는 오류를 반환하게 된다. 이처럼 내부 DNS 서버는 자신이 호스트 이름을 주소로 변환하지 않으며 단지 forwarder가 보내주는 결과를 클라이언트에게 전달해 주는 역할만을 담당한다.
Slave서버와 Caching-Only forwarder를 같이 둠으로써 내부 DNS 서버가 다른 내부 서버에게 응답을 직접 보낼수가 없다. 방화벽은 단지 forwader 하고만 메시지를 주고 받을 수 있도록 설정된다. 이렇게 함으로써 내부 영역 데이터는 안전하게 보호될 수 있다.
다음 글에서는 동적 DNS Servers에 대하여 살펴볼 것이다.
6. Dynamic DNS Servers (DDNS)
Windows 2000 DNS 서버와 이전 버전의 마이크로소프트 DNS 서버의 차이점을 분명히 보여주는 하나의 특성이 있다면 그것은 Windows 2000 DNS 서버의 영역 데이터베이스의 정보를 동적으로 수정할 수 있는 능력에 있다.
이러한 기능은 WINS 서버에서 보았던 것과 상당히 유사하다. WINS 서버는 네트웍상의 NetBIOS 노드들이 자신의 NetBIOS 이름과 IP 주소 사이의 매핑정보를 동적으로 변경할 수 있도록 지원한다. 이전 버전의 마이크로소프트 네트웍은 전부 NetBIOS 기반이었기 때문에 이러한 동적 변경 기능은 실제적인 잇점을 제공하였다.
Windows 2000의 이 NetBIOS의 구속에서 벗어나 컴퓨터와 도메인 네이밍을 위해 DNS 기법을 사용하고 있다. 그러나 DNS가 NetBIOS에 비해 많은 장점들을 가지고 있지만 한가지 중요한 문제점도 가지고 있다. 그것은 영역 데이터베이스 파일들이 원래 정적 데이터베이스로 설계되었다는 것이다. 즉, 만일 영역 데이터베이스의 내용을 변경할 필요가 있을 경우에는 DNS 관리자가 수작업으로 그 내용을 변경해야하는 것이다.
Enterprise Windows 2000 Network과 같은 DNS 기반의 대형 네트웍에 있는 영역 데이터베이스를 수작업으로 관리한다는 것은 매우 힘들고 어려운 작업이다. 이 작업은 전적으로 DHCP를 사용하여 이 DHCP가 공유 네트웍 자원들에게 IP 주소를 부여할 때 보다 훨씬 성가신 작업이다. 그러므로 Dynamic DNS Update Protocol은 Windows 네트웍을 구축하는데 있어서 이 큰 장애물을 해결하는 좋은 해결책이다.
동적 DNS는 네트웍상의 모든 클라이언트들이 Windows 2000을 사용할 때 더 효과적으로 동작한다. 이 경우 Windows 2000 클라이언트는 자신의 호스트 레코드와 포인터 레코드 정보를 DDNS 영역 데이터베이스 파일에 등록할 수 있다. 그러나 대부분의 네트웍은 이처럼 동작하지 않으며 네트웍 클라이언트들이 혼합하여 존재한다. 이 경우 낮은 버전의 Windows 기반의 클라이언트들은 Windows 2000 DHCP 서버를 이용하여 호스트와 포인터 레코드 정보를 DDNS 서버에 동적으로 등록하는 장점을 가지게 된다.
끝마치면서
Windows 2000 서버는 서로 다른 많은 역할을 담당할 수 있다. 서버가 어떤 역할을 담당할 것인가는 여러분의 네트웍상에서 어떤 요구사항들이 있는가에 따라 달라진다. DNS 서버의 역할은 여러분이 DNS를 Active Directory와 통합을 하느냐 아니냐에 따라 달라진다. 여기서는 DNS 서버와 통합된 Active Directory에 대해서는 언급을 하지 않았지만 네트웍상에 DNS를 구현하기 전에 또는 Windows 2000 시험에 응시하기전에 반드시 살펴보고 내용을 파악해야 한다.
댓글 없음:
댓글 쓰기