Windows NT DNS 설치 및 관리 설명서

윈도우 사용자그룹 저

“윈도우 NT DNS에서는 분명 파일을 변화시키거나, 영역을 삭제했는데도 다음 DNS 서비스 조

작에서 마치 귀신같이 이 삭제 부분이 되살아나게 된다. 윈도우 NT DNS 체계를 이해하는 사람

이라면 쉽게 이 현상을 이해할 수 있겠지만, 대부분의 사용자에게는 이는 어딘가 귀신이 붙어

있는 것처럼 느끼게 된다. 이 설명서는 이러한 윈도우 NT의 DNS 체계를 올바로 이해하는 것을

그 목적으로 한다.”

이 문헌은 Adobe Korea의 협조로 Acrobat으로 출력되었습니다.

이 문헌은 윈도우 사용자그룹에 그 저작권이 있으며, 비

영리적 목적으로는 자유롭게 사용할 수 있습니다. 만일,

이 문헌의 전부 혹은 일부를 영리적 목적에 의해 사용하

거나, 학원 및 학교의 강의용으로 채택하는 경우 사용자

그룹이 정하는 바에 따라 복사본 1부당 소정의 저작권료

를 지불하여야 합니다. 저작권료의 지불 및 문의는 아래

연락처를 이용하시기 바랍니다.

문헌은 사용자그룹의 공식 웹 사이트 외의 다른 곳에서

배포할 수 없습니다.

http://windows.designweb.org

Tel: (02) 882-8522

1999 Netien All right reserved

DNS 서비스

DNS서비스는 인터넷에서 가장 필수적인 서비스 중의 하나이다. 인터넷에 연결된 모든 컴퓨터

는 스스로 자신의 식별 코드인 IP 주소를 갖게 된다. 이 IP 주소는 네트워크 인터페이스 카드

에 부여되며, 하나의 컴퓨터에 몇 개의 IP 주소를 사용할 수도 있다. DNS서비스의 원리는 의외

로 간단하며, 또한 사용하는 용어도 그렇게 어려운 것은 없다. .

DNS 의 원리 DNS는 IP 주소를 찾아주는 서비스이다. 가령, http://windows.designweb.org 와 같은 주소를 웹 브

라우저에 입력했을 때 이에 해당하는 서비스가 나타나게 되며, 이것은 미리 컴퓨터에 설정된

DNS 서버에게 이 주소를 물어본 후 반환된 IP 주소를 사용하여 직접 이 서비스에 접속한 것이

다. 즉, 다음 그림과 같이 내 컴퓨터에서 windows.designweb.org라는 컴퓨터를 찾기 위해서는 내

컴퓨터가 지정한 DNS 서버에게 이 이름에 해당하는 IP를 찾아달라고 문의한다. DNS서버는 먼

저 designweb.org 서버가 어디에 존재하는지 알지 못하므로, .org를 맡고 있는 가장 상위 서버인

인터닉 루트 서버에 designweb.org 도메인의 네임 서버를 가르쳐 달라고 문의하게 된다. 그러면

루트 서버는 이 도메인 네임 서버의 IP와 DNS 이름을 반환한다. 이 정보를 가지고 다시 DNS

서버는 designweb.org 네임 서버로부터 windows.designweb.org의 주소를 가져오게 된다.

����

����������

������������ �������������

���������

����������������

�� ����������

�������

������ ��� �����������

�����

����������

� �!"

인터넷에서는 수많은 DNS 서버가 존재한다. 그런데, 이 DNS서버는 웹 서버와 같은 일반적인

인터넷 서버와는 달리 상위 DNS 및 하위 DNS 등의 위계적 체계를 지니게 된다. 즉, 인터넷상

에서 임의로 사용자가 DNS를 등록하였다고 해서 DNS가 작동하는 것은 아니다. 반드시 자신이

속한 상위 DNS에 현재 운영되고 있는 DNS를 등록해 주어야 한다. .com이나 .net, .org 도메인을

사용하기 위해서는 최상위 도메인인 인터닉에 등록해 주어야 하며, co.kr, pe.kr과 같은 2 차 도

메인을 사용할 경우에는 한국전산원에 등록해 주면 된다.

인터넷에서 도메인 네임의 체계는 IP 주소의 체계와 아무런 상관이 없다. 다만 어떤 DNS 서버

가 포인팅하고 있느냐가 중요하다. 가령, www.mycorp.com 은 미국 NIC가 관리하는

192.156.136.10에 존재하고 ftp.mycorp.com은 한국전산원 소속의 210.120.128.90에 두어도 상관없

다. 다만, 이름을 서비스하고 있는 상위 도메인에만 등록되어 있으면 된다. 이런 이유 때문에

인터넷에서는 도메인 네임 판매 등의 사업이 가능해진다.

도메인 네임의 등록 및 관리 도메인 네임은 상위 도메인 네임 서버를 어떤 것을 쓸 것인지 여부에 따라 그 체계가 달라지

게 된다. 가령, 상위 도메인이 미국의 인터닉이면 .com, .net, org와 같은 도메인 네임의 발급이

이루어질 수 있다. 또한 일본이면 .co.jp, .ac.jp 등의 도메인이 발급되고, 한국이

면 .co.kr, .or.kr, .pe.kr 등의 도메인을 발급받을 수 있다.

도메인 네임을 발급받기 위해서는 보통 자신의 신상 정보와 유료 도메인 서비스의 경우에는

지불 방법(보통 VISA 혹은 Master CARD) 그리고, 도메인 네임 서버로 활동해 줄 서버 한 대만

가지고 있으면 된다. 이 도메인 네임 서버는 윈도우 NT, 유닉스, 리눅스 등 서버급의 운영체제

를 가지고 있는 어떤 소프트웨어든지 사용이 가능하다. 또한 정적 IP를 사용하고 있는 상태라

야 한다. 현재 이러한 도메인 네임 서버를 운영할 여력이 되지 않는 경우에는 운영되고 있는

도메인 네임 서버 관리자에게 부탁하여 새로 레코드를 하나 더 만들어 사용하는 방법이 있다.

이것을 도메인 네임 호스팅이라고 하기도 한다.

윗 그림은 인터닉의 도메인 등록 서비스를 대행하고 있는 네트워크 솔루션즈의 홈페이지이다.

WINDOWS NT DNS

Windows NT DNS 의 구현

윈도우 NT DNS 는 NT 의 빠른 보급 속도와 맞물려, 현재 인터넷상에서 많이 사용되고 있는 DNS 이다. 그러나, 윈도우 NT DNS 는 그 사용 방법과 작동 원리는 많이 알려지지 않아 잘못 사용되는 일이 허다하다.

윈도우 NT 에서는 크게 두 가지 방식의 DNS 를 지원하고 있다.유닉스와 동일한 BIND(Berkeley Internet Name Domain) 데이터를 사용하는 방식과 윈도우 NT 레지스트리에

서 DNS 설정을 관리하는 방식이다. 보통 윈도우 NT 레지스트리를 직접 사용하는 방식을 많이 사용하지만 BIND 데이터를 직접 사용하는 것도 나름대로의 장점이 있다.

Windows NT 에서 DNS 의 설치

Windows NT 에서 DNS 를 설치하는 것은 매우 간략하게 끝난다. 제어판의 네트워크 설정을 선택하여 서비스 중 DNS 서비스를 선택하여 설치해 주면 된다.

DNS 서비스를 설치하게 되면 서비스에 DNS 서비스 항목이 추가되며 관리 도구에 DNS 관리자가 설정된다.

DNS 관리자는 관리 도구에서 실행할 수도 있고 명령 프롬프트에서 DNSadmin 을 입력해도 된다. DNSadmin.exe 를 실행시키면 DNS 를 GUI 환경에서 설정할 수 있도록 해 준다.

DNS 텍스트 모드 사용(GUI 사용만을 원하는 사용자는 읽을 필요 없음)

BIND(Berkeley Internet Name Domain)는 이름 그대로 버클리에서 제작된 도메인 네임 시스

템을 위한 소프트웨어이다. 전통적으로 유닉스 서버에서는 인터넷 네임 서비스를 이 BIND 소프트웨어에 의해 작동되며, 이 소프트웨어는 http://www.isc.org 에서 무료로 얻을 수 있다.

유닉스 사용자들은 DNS 를 텍스트 파일 편집으로 설정한다. 그런데 Windows NT 역시 DNS 를 텍스트 파일의 편집만으로 설정할 수 있다. 유닉스에서 DNS 를 설정해 본 경험이 있는 사람이라면 텍스트 파일 편집으로 DNS 를 설정하는 것이 훨씬 쉽게 느껴질 것이다. 그러나 이 텍스트 파일 편집으로 DNS 를 운영하는 것은 윈도우 NT 의 GUI 프로그램과 호환되지 않는다. 따라서, 관리자는 처음부터 어떤 방식에 의해 DNS 를 운영할 것인지 결정

하여야 한다. GUI 방식을 사용한다면 상대적으로 편리한 설정 방식을 갖게 된다. 또한 원격 서버를 동일한 GUI 화면에서 관리할 수 있다. 그러나, 데이터가 많은 경우 원격 서버에서 다른 서버를 관리하는 것은 네트워크 대역상 많은 무리가 따른다.

만일, 유닉스상에서 작성된 막대한 양의 BIND 데이터를 받았을 때, 기본적으로 Windows 에

서 다시 모든 DNS 를 설정해 주는 것은 매우 큰 낭비이다. 이런 경우 DNS 의 Boot 파일을 적용하면 매우 쉽게 DNS 서버를 전환할 수 있다.

윈도우 NT 는 기본적으로 이 텍스트로 주어진 named 파일들을 사용할 수 없도록 설정되어 있다. 그러나 레지스트리의 다음 키 값을 수정하게 되면 레지스트리를 무시하고 BIND 데이

터를 읽어들여 사용할 수 있도록 설정된다.

HKEY_LOCAL_MACHINE\

SYSTEM\CurrentControlSet\Services\DNS\Parameters

에서 parameter 의 EnableRegistryBoot 의 값을 지운다.

이렇게 값을 지우면 이제 Windows 는 부트 파일에서 정보를 읽게 되며, Boot 파일을 수정

하면 DNS 정보를 고칠 수 있다.

유닉스의 경우 /etc/named.boot 등의 부트 파일 명을 가진다. Windows NT 는 winnt/system32/dns/boot 파일이 부트 파일로 사용된다. GUI 환경에서는 이 boot 파일을 다룰 필요가 없다.

Boot 파일을 작성하는 것은 그다지 어렵지 않다. 다음과 같은 문법으로 이 파일을 작성해 주면 된다.

cache . cache.dns

primary oridesign.com oridesign.com.dns

primary 143.46.147.in-adr.arpa 143.46.147.in-addr.arpa

secondary netien.com 147.46.46.28 netien.com.dns

cache 는 도메인 네임 캐시를 위해 사용되며, 이것은 DNS 가 DNS 외부의 서버와 접촉하기 위해 사용된다. primary 는 주 도메인 서버를 말하며, 이 예제에서는 oridesign.com 의 주 도메인 콘트롤러가 이 서버라는 것을 의미한다. BIND 와 다른 점은 주 도메인 영역을 일일이

주소로 입력하지 않고 파일명을 적어 하나의 DNS 영역은 하나의 파일 내에 넣어 두는 차이

가 있다. 캐시 파일은 samples 에 제공된 기본 파일을 그냥 사용하면 된다.

각 파일 영역은 BIND 에서 설정된 방식과 거의 유사하게 설정된다. 다음은 DNS 데이터 파일의 예제이다. ;

; Database file oridesign.com.dns for oridesign.com zone.

; Zone version: 7l

;

@ IN SOA ecel.snu.ac.kr. (

7 ; serial number

3600 ; refresh

600 ; retry

86400 ; expire

3600 ) ; minimum TTL

;

; Zone NS records

;

@ IN NS ecel.snu.ac.kr.

;

; Zone records

;

@ IN MX 0 mail

gc IN A 147.46.143.185

mail IN A 147.46.143.204

ns IN A 147.46.143.185

test IN A 147.46.143.204

www IN A 147.46.143.204

NS, MX, A, SOA 레코드들이 여기서 어떤 방식으로 설정되는지 간략하게 보여 준다. 또한 시리얼 넘버 Refresh, TTL 등의 전송 설정 역시 간략히 텍스트로 작성할 수 있다.

DNS 의 GUI 설정

관리 대상 DNS 서버가 모두 로컬 네트워크에 존재하거나, 유닉스 BIND 데이터베이스와 별다른 교류가 없다면 GUI 모드의 DNS 설정으로 DNS 를 관리한다.

GUI 모드에서는 DNS 설정을 레지스트리에서 읽어 오게 된다.

GUI 에서 설정한 데이터베이스는 이렇게 레지스트리에 등록된다. 또한, 레지스트리에 등록

된 파일 경로는 시스템이 시작하면서 읽어들여 계속 메모리상에 존재하게 된다. 따라서 관리하는 도메인이 많을수록 DNS.exe 서비스는 많은 양의 메모리를 요구하게 된다.

Windows NT 작업 관리자에서 DNS.exe 의 메모리 사용량을 조사해 보면 하나의 DNS 목록

또는 영역이 추가될 때마다 약간씩 DNS 의 메모리 사용량이 증가하는 것을 확인할 수 있다. 따라서, DNS 서비스 목록이 매우 많다면 DNS.exe 가 시스템 자원을 엄청나게 소모해 버린

다. 따라서 다량의 DNS 서비스를 할 경우 독립 DNS 를 구축하는 것이 요구된다.

GUI 방식의 DNS 설정에서 새로운 기록의 등록은 이렇게 DNS 관리자가 레지스트리의 설정

에 따라 메모리에 설정 사항을 등록하고 파일에 기록한다. 메모리 내에 저장된 내용이 파일

에 기록된 내용보다 언제나 우선 순위를 가지게 되며, 파일 내의 내용을 임의로 변경시켜도 DNS 내용은 바뀌지 않는다.

새 영역의 등록-GUI

DNS 등록의 GUI 툴인 DNS 관리자는 다른 관리 도구와 마찬가지로 RPC 를 지원한다. 따라서, 하나의 DNS 관리자로 많은 DNS 서버들을 관리할 수 있다. 그러나, DNS 관리자가 여러 서버를 관리하기 위해서는 생각보다 많은 데이터 전송이 이루어져야 하며, 아주 많은 DNS 서비스를 운영하는 서버를 원격에서 접속하기는 생각보다 쉽지 않다.

DNS 관리자는 따라서 RPC, LPC 를 관리할 컴퓨터를 설정해 주어야 한다. 로컬 컴퓨터라도 컴퓨터 이름을 따로 등록해 주어야 한다. 또한 DNS 관리자의 설정은 로그온한 관리자 계정

의 사용자마다 설정이 다르다. 이것은 백오피스 프로그램도 마찬가지이다.

따라서, 일단 관리할 컴퓨터를 등록한다. DNS 메뉴를 선택하여 새 서버를 선택하고 관리할 DNS 서버의 NetBIOS Name 혹은 NetBIOS 와 매핑된 IP 를 입력하도록 한다. 원격 서버인 경우에는 네트워크 로그온 과정을 거친 후 접속해 주어야 한다.

DNS 는 영역 등록과 레코드의 등록 두 가지 절차를 갖게 된다. 유닉스의 BIND 는 영역에 따른 구분을 같은 파일에서 설정하였지만 Windows NT 의 DNS 는 영역별로 하나의 파일에 넣어 관리하는 방식을 취한다. 레코드는 각 영역별 도메인 주소와 IP 사이의 매핑을 말한다.

서버가 등록되었으면 마우스로 해당 서버를 두 번 클릭한다. 그러면 서버에 등록된 영역 DB 가 나열되게 된다. 어떠한 영역도 받지 않았다면 이 영역 DB 는 캐시 설정 하나만이 존재한다.

새 영역을 만드는 과정은 서버를 선택하여 새 영역을 클릭하는 것으로 시작한다. 일단 이 영역이 주 영역인지 보조 영역인지 선택해 준다. 주 영역을 선택하였으면 영역 정보에 대한 입력 사항이 나타난다. 여기에 사용할 도메인명(인터닉이나 KRNIC 등에 등록된 이름)을 입력한다.

입력된 이름은 영역의 이름, 그리고 데이터베이스 파일 명으로 사용된다. 그림과 같이 일단 영역 설정이 이루어지면 winnt/system32/dns 디렉터리에는 test.com.dns 라는 파일이 만들어

지게 된다.

주 영역은 이 영역에 레코드를 입력하는 것으로 DNS 설정이 마무리된다. 보조 영역은 그러

나 주 영역에 비해 설정 방식이 약간 다르다.

보조 영역은 영역명과 서버명을 입력하여 이루어진다. 만일 DNS 관리 도구로 관리 가능한 DNS 라면 서버 이름과 영역 이름을 손 모양의 아이콘을 마우스로 잡고 다른 서버의 영역에

서 끌어붙이기를 할 수 있다.

보조 영역이 주 영역 설정과 크게 다른 점은 바로 IP 매스터를 설정해 주어야 한다는 것이

다. 주 영역 서버가 Windows NT 서버라면 IP 매스터의 기본 설정 권장값으로 이 서버의 DNS 주소가 나타난다. 주 영역 서버가 Windows NT 서버가 아니라면 IP 매스터는 자동으

로 찾아지지 않고, 수동으로 입력해 주어야 한다.

IP 매스터는 주 영역 서버에서 통째로 리스트를 외부로 가지고 가는 옵션을 막지 않았다면 전 세계의 어떤 서버에서 매스터를 받아 올 수 있다. 보조 서버는 이 매스터 데이터베이스

와 주기적으로 통신하여 자신의 데이터를 업데이트하게 된다.

레코드의 등록과 하위 도메인의 등록

레코드는 IP 주소와 DNS 이름을 직접 매개하는 것이며 몇 가지 종류가 있다. 레코드 등록

을 위해 알아야 할 레코드 종류를 몇 가지 들면 다음과 같다.

레코드 종류 설명

SOA 이름 권한, 그 이름을 사용할 권리가 있음을

나타내며 자동으로 부여된다.

NS 주 도메인 네임 서버

A 도메인 네임

CNAME A 네임의 별명

MX 전자 메일 송수신 서버를 지정하는 레코드

물론 여기에 제시된 것보다 훨씬 많은 레코드들이 RFCs 에 존재한다. 그러나 Windows 네트워크나 TCP/IP 에서 사용하는 레코드는 대부분 위에 제시된 다섯 가지이다. 이 중 SOA 레코드나 NS 레코드는 영역이 설정되면서 자동으로 부여되는 것으로 도메인 서버 관리자는 A, CNAME, MX 레코드만을 새로 설정해 주면 된다.

영역에 적용되는 레코드를 등록하기 위해서는 다음 절차를 거치면 된다.

A 레코드: 영역에서 새 호스트 등록을 선택하거나 새 레코드 등록을 선택하여 사용할 컴퓨

터 네임과 IP 주소를 입력한다. 가령, ori.netien.com 이라는 호스트를 등록하기 위해서 컴퓨

터 네임을 ori 로 등록해 주면 된다.

CNAME 레코드: CNAME 레코드는 일단 A 레코드로 등록된 하나의 서버에 대해서 설정이 가능하다. CNAME 레코드는 A 레코드의 별명이며 별명 이름에 새로 등록될 이름을 입력하

고 호스트 DNS 이름에 현재 사용되고 있는 A 레코드 이름을 부여해 준다. CNAME 으로 설정하지 않고 A 레코드로 설정하여 중복된 IP 를 갖게 하더라도 큰 문제는 발생하지 않는다.

MX 레코드: MX 레코드는 좀 특이한 레코드이다. 이것은 메일 송수신을 위해 설정된 규약이

다. 가령 ori@plaza.snu.ac.kr 을 메일 주소로 사용하고 있는 사용자는 MX 레코드로 plaza가 도메인 관리자에 의해 지정되어 있다면 ori@snu.ac.kr 과 같은 도메인 이름의 주소를 가질 수 있다.

MX 레코드는 또한, 메일 호스팅에 사용될 수 있다. 가령 ori@pop.netien.com 이라는 메일 주소를 갖는 사용자가 dark.co.kr 이라는 회사를 차렸다고 하자, 이 때 dark.co.kr 의 도메인

관리자는 MX 레코드로 pop.netien.com 을 입력하면 사용자는 ori@dark.co.kr 의 메일 주소를 사용하여 자신의 메일을 받을 수 있다.

그림과 같이 MX 레코드를 설정하면 ID@oridesign.com 으로 송신되는 메일은 모두 pop.oridesign.com 으로 전송된다. MX 레코드는 기본 설정 번호를 부여하고 있기 때문에 이 기본 설정 번호가 낮을수록 가장 먼저 메일을 송신하는 메일 서버가 된다. 기본 설정 번호

를 지정하는 이유는 메일 서버에 문제가 생겼을 경우 메시지의 전달에 문제가 없도록 하기 위해서이다. 0 이 가장 낮은 수이므로 0 을 설정한 메일 서버가 보통 디폴트 메일 서버가 된다.

Windows 2000 에서는 SRV 레코드가 하나 더 추가되어 DNS 서비스가 운영된다. Windows 2000 은 Windows NT 4.0 과는 달리 모든 네트워크가 DNS 기반에 의해 운영되기 때문이다.

하위 도메인의 등록은 비교적 간단하다. 영역에 레코드 대신 하위 도메인을 등록하고 그 하위 도메인 내에 다시 레코드를 등록해 주면 되기 때문이다. 가령 windows.designweb.org 라

는 도메인을 만든 다음 www.windows.designweb.org 라는 도메인으로 확장할 수도 있다.

도메인 이름 자체를 A 레코드로 등록할 수도 있다. 그러나, 이것은 그다지 많이 쓰이는 방식은 아니다. 또한 BOOT 파일을 사용하지 않고서는 정상적인 방법으로 도메인 이름 자체

에 A 레코드를 줄 수는 없다.

교재에 편법을 다루는 것은 정도에 어긋나지만, A 레코드를 등록하는 방법이 없는 것은 아니다. Oridesign.com 이라는 도메인을 A 레코드로 부여하려면 먼저 가장 상위 영역에서 새 영역 중 com 영역을 하나 만들어준다. 물론, 이 영역은 등록되지 않은 영역이기 때문에 별다른 의미를 지니지 못한다. 그리고, 이 하위 레코드로 oridesign 을 입력하면 된다. 이후 DNS 새로 보기를 해 보면 oridesign.com 의 항목에 A 레코드가 첨가된다.

A 레코드를 확인하였으면 이제 만들었던 com 영역을 삭제한다. 만일 com 영역을 삭제하지 않는다면 해당 도메인 네임 서버를 사용하는 모든 사용자들은 com 으로 끝나는 서버에 접속할 수 없다.

레코드셋 유출 보안 및 전달

도메인 네임 서버의 레코드셋은 일반인들에게 서비스하기 위한 정보로 채워져 있으므로 일반적으로 도메인 네임 서버를 처음 세팅하였을 경우, 도메인 네임 서버의 레코드셋은 누구나 접근할 수 있게 설정되어 있다. Nslookup 명령을 사용하면 도메인 레코드셋 전체의 정보룰 볼 수 있다. 특히 교육전산망에 연결된 도메인 네임 서버들은 대부분 레코드셋 정보를 볼 수 있게 해 놓았다.

그림은 nslookup 명령을 사용하여 서울대학교 전체의 서버 중 NS 로 설정된 서버 리스트를 뽑아 본 것이다. 이처럼 nslookup 명령으로 레코드셋을 일일이 확인할 수 있다. ls –d 명령

을 사용하면 도메인 전체의 레코드셋을 볼 수 있다.

더구나 공인되지 않은 보조 네임 서버를 사용하여 주 도메인 콘트롤러의 레코드셋을 모두 복사할 수 있다. 이렇게 레코드셋 복사는 자칫 보안 정보를 유출할 가능성도 있다.

따라서, 상용 도메인 관리 서버들은 이런 레코드셋 전체 쿼리 설정이 아예 막혀 있다. 다음 그림과 같이 보라넷을 nslookup 명령을 사용하여 액세스하려고 할 때 접근 거부 메시지가 나타나는 것은 그러한 이유 때문이다.

레코드셋 전체를 요구하는 설정값을 변화시키려면 다음과 같이 영역 알림 설정을 해 주어

야 한다. 영역 알림 설정은 특정 IP 를 가진 네임 서버를 지정하여 해당 네임 서버에만 레코드셋 전체를 전달하도록 한다. 영역 알림 설정은 보조 도메인 서버가 도입되었을 경우 설정해 주어야 하며, 이 보조 도메인 서버를 알림 목록에 입력해 둔다. 그리고 알림 목록에 있는 보조 영역에서만 액세스를 허용하도록 옵션을 바꾸어 놓는다.

이렇게 설정해 놓으면 nslookup 명령이든 혹은 외부 도메인 서버를 사용하던 간에 도메인 전체의 레코드셋을 한번에 읽지 못하게 된다. 레코드셋은 주 도메인 서버와 보조 도메인 서버 상호간에만 읽을 수 있다.

PTR 영역의 설정

PTR 영역은 거꾸로 찾기를 위한 포인터를 제공한다. 즉, ori.designweb.org 의 주소가

220.221.32.9 이라면 220.221.32.9 라는 주소로 DNS 에 질의를 하였을 때 ori.designweb.org가 반환되도록 설정하는 것이다.

PTR 레코드는 특히 스팸 방지에 사용된다. 특정 서버로부터 메일이 전송되었을 떄 PTR 레코드를 확인하여 정말 그 서버에서 메일이 전송되었는지를 확인하기 위한 방안으로 DNS 의 PTR 을 쿼리하게 된다.

PTR 은 다른 DNS 와는 달리 ISP 에서 일차적으로 부여해 주어야 한다. 도메인 네임은 자유

롭게 부여되지만 PTR 의 경우에는 전 세계 공통인 IP address 를 사용하고 있기 때문에 비교적 엄격하고 체계적인 관리가 이루어진다. 따라서, 도메인 네임을 부여받은 후 PTR 레코

드에 관해서 담당 ISP 와 상의를 해 보아야 한다.

PTR 영역은 IP 의 역순서.in-addr-arpa 로 입력된다. 영역 이름을 이렇게 설정해 놓아야 하고, 상위 DNS 에서 PTR 포인터로 해당 서버를 설정해 주어야 한다. 가령 210.221.32.X 의 PTR 영역을 제작하려면, 32.221.210.in-addr.arpa 라는 영역 이름으로 PTR 영역을 작성하면 된다.

IP 뒤에 in-addr.arpa 가 적혀 있으면 DNS 는 자동으로 이 영역을 PTR 로 인식한다. 따라서, 이 영역에서 새로 등록할 수 있는 래코드는 NS, PTR, TXT 로 한정된다. PTR 설정을 이렇게 해 놓으면 상위 도메인에서 PTR 을 제대로 찾아올 수 있다.

WINDOWS NT DNS 의 내부

캐시 파일 캐시 파일은 상위 DNS를 찾기 위한 파일이다. 따라서, 이 캐시 파일이 있어야만 DNS는 다른

호스트의 이름으로 IP를 찾을 수 있다. 캐시 파일은 DNS가 설정되면서 같이 저장되고, 임의로

수정해서는 안 된다. 캐시 파일에서 나타내는 주소들은 모두 상위 인터닉에 소속된 서버들이다.

이 캐시 파일은 \winnt\system32\dns 디렉터리에 존재하게 된다. 따라서, 이 캐시 파일이 손상된

경우 다른 도메인 이름을 찾을 수 없다. 따라서 캐시 파일은 결코 지워서는 안 된다.

;

; Cache file:

;

. 2163095040 IN NS A.ROOT-SERVERS.NET.

A.ROOT-SERVERS.NET. 2163095040 IN A 198.41.0.4

. 2163095040 IN NS B.ROOT-SERVERS.NET.

B.ROOT-SERVERS.NET. 2163095040 IN A 128.9.0.107

. 2163095040 IN NS C.ROOT-SERVERS.NET.

C.ROOT-SERVERS.NET. 2163095040 IN A 192.33.4.12

. 2163095040 IN NS D.ROOT-SERVERS.NET.

D.ROOT-SERVERS.NET. 2163095040 IN A 128.8.10.90

. 2163095040 IN NS E.ROOT-SERVERS.NET.

E.ROOT-SERVERS.NET. 2163095040 IN A 192.203.230.10

. 2163095040 IN NS F.ROOT-SERVERS.NET.

F.ROOT-SERVERS.NET. 2163095040 IN A 39.13.229.241

. 2163095040 IN NS G.ROOT-SERVERS.NET.

G.ROOT-SERVERS.NET. 2163095040 IN A 192.112.36.4

. 2163095040 IN NS H.ROOT-SERVERS.NET.

H.ROOT-SERVERS.NET. 2163095040 IN A 128.63.2.53

. 2163095040 IN NS I.ROOT-SERVERS.NET.

I.ROOT-SERVERS.NET. 2163095040 IN A 192.36.148.17

DNS 의 동작과 오류 윈도우 NT DNS가 GUI 방식으로 이루어지는 경우 동작 방식을 이해하는 사용자는 많지 않다.

윈도우 NT DNS는 부팅과 동시에 동작한다. 즉 위에 예를 든 캐시 파일이나, 각각의 도메인 정

보를 저장하고 있는 파일은 부팅과 동시에 읽혀 메모리에 보관된다. 또한 DNS 서비스가 종료

될 때 메모리에 있는 모든 내용은 파일로 기록된다. 따라서, 사용자들이 DNS 서비스가 동작되

는 도중 이 파일의 내용을 변형시켜도 결국 DNS 서비스는 큰 영향을 받지 않는다 시스템이

종료되면서, 혹은 DNS 서비스가 중단되면서 변경 내용을 기록해 놓기 때문이다.

레지스트리에는 각각의 도메인별로 이렇게 DNS 서비스가 시작하거나 종료될 때 참조하는 파

일명을 기록해 놓는다. 이 각각의 파일은 DNS가 동작하는 도중에는 기록되지 않는다. 따라서,

DNS 서비스를 모두 등록해 놓았는데 정전 혹은 시스템 오류로 정상적인 시스템 종료와 재시

작이 일어나지 않은 경우는 기존 데이터들이 모두 유실되어 버린다.

새로 도메인 레코드를 생성하는 경우, 만일 \system32\DNS 디렉터리에 기존 파일이 있다면 윈

도우 NT의 DNS는 이 기존 파일을 덮어 사용하지 않고 기존 파일의 데이터를 그대로 사용하게

된다. 이것이 삭제된 영역의 데이터가 계속 등록할 때마다 나타나게 하는 원인이 된다.

이런 원리를 이해하였다면 BIND 데이터를 사용하는 텍스트 기반이 아니더라도 GUI 바탕의 텍

스트 파일을 조작하여 DNS를 동작하도록 만들 수 있다. 제어판의 서비스, 혹은 서버 관리자를

사용한 원격 DNS 서비스를 중단시키면 DNS 서비스는 현재 메모리에 존재하는 모든 내용을

DNS 디렉터리 아래의 각 영역에 저장하게 된다. DNS 서비스가 확실히 중단된 이후 이 파일을

편집하고 나서 DNS를 시작하면 이제 편집된 내용이 DNS 서비스로 이루어지게 된다.

간혹 DNS 관련 파일들의 손상, 혹은 데이터들의 오류로 인해 DNS 서비스가 중단되는 경우가

있다. 특히 매핑 오류를 발생시키며 자주 중단되는 경우가 생긴다. 보통 이러한 오류는 시스템

파일의 손상에 의해 발생된다. 이 경우 DNS 서비스를 재설치할 때 가급적 레지스트리 정보를

삭제하고 DNS를 재설치하는 방법을 권장한다. 레지스트리 내용을 삭제하지 않고 DNS를 재설

치하면 모든 데이터들이 다시 나타나는 요술(?)을 볼 수 있다. 이는 DNS는 서비스 시작과 동시

에 레지스트리 정보를 파악하여 필요한 파일을 읽어들이기 때문이다.

그림에서 보듯 DNS 디렉터리는 현재 이 서버가 관리하는 모든 DNS 파일들이 나타나 있다. 하

지만, DNS 서비스를 중단하기 전까지 이 파일들은 현재 변형된 설정을 결코 나타내지 않는다.

DNS 서비스가 중단되고 나서 변경된 내용은 이 파일에 기록되며, DNS 서비스가 재시작될 경

우 이 파일의 내용을 읽어들여 새로 서비스가 이루어지며, 이후 서비스가 중단될 때까지 파일

의 변경 사항은 결코 서비스 자체에 영향을 주지 않는다. 만일 파일 내용을 바꾸었다고 하더라

도 DNS 서비스가 종료되면서 현재 설정을 그대로 재저장해 버리므로, DNS 서비스가 동작하는

동안 이 파일의 변경은 아무런 의미를 지니지 못한다.

© 1999 윈도우 사용자그룹 All right reserved.