Windows2000 동적 DNS - mapoo's blog

Windows2000 동적 DNS

DNS는 인터넷 표준으로 인터넷에 접속된 호스트의 이름을 결정하고 호스트 이름을 IP 주소로 변환하는 방법을 규정하고 있다. DNS는 계층적 구조를 갖기 때문에 권한을 위임할 수 있으며 이로 인해 네트워크의 확장성을 보장한다. 다만, DNS는 정적인 구조를 갖기 때문에 새로운 호스트가 추가되었을 때나 삭제되었을 때 해당 데이터베이스를 수작업으로 수정해야만 하는데, 이런 번거러움을 해결한 것이 DDNS이다. DDNS를 이용하면 호스트가 추가되었을 때 자동으로 서버에 통지되고 서버는 데이터베이스를 수정하여 다른 호스트에서 추가된 호스트의 주소를 찾을 수 있도록 한다. 보통 DDNS는 DHCP와 함께 사용되는데, Windows 2000에는 DDNS와 DHCP가 모두 포함되어 있다.

DNS의 이해

- 주소 체계
☞ 네트워크에 연결된 호스트는 해당 네트워크 내에서 고유한 주소를 갖고 있다. TCP/IP네트워크인 경우 주소는 4개의 8비트 숫자로 구성되는데. 이러한 주소를 일일이 외우기란 쉽지 않은 일이다. 그래서 207.46.230.219 등과 같이 숫자로 구성된 주소대신 www.microsoft.com과 같이 알기 쉽고 외우기 쉬운 단어를 이름으로 사용한다.

물론 이는 전적으로 사람을 위한 것이고 실제로 네트워크 내에서 이런 주소를 사용하지 않는다. 그렇기 때문에 단어로 구성된 주소를 숫자로 구성된 IP 네트워크 주소로 변환하는 과정이 필요한데 이 과정을 이름 해결(Name Resolution)이라고 하며 DNS 서버가 이 역활을 담당한다.

DNS의 역사
☞ DNS가 초기 인터넷인 ARPAnet 시절부터 존재했던 것은 아니다. 물론 호스트 이름을 IP 주소로 바꾸는 것은 지금이나 그때나 마찬가지였지만 네트워크에 연결된 호스트의 수가 그리 많지 않았기 때문에 일반 텍스트 파일인 HOSTS.TXT에 호스트 이름과 이에 대응되는 IP주소를 입력하는 것으로도 충분하였다.
HOSTS.TXT는 NIC(Network Information Center)에서 관리하였는데, 새로운 호스트가 추가되면 NIC에서 HOSTS.TXT 파일을 갱신하고 이를 네트워크 내의 호스트에 전파하는 방법을 이용했다.

이 방법은 단순하면서 사용하기 쉬워 호스트의 수가 적은 초기에는 별 문제가 없었지만 네크워크가 급격히 확장되면서 모든 호스트가 NIC에 접속하여 회신의 HOSTS.TXT 파일을 받는다는 것이 심각한 문제가 되었고 NIC에서 HOSTS.TXT 파일을 관리한다는 것이 불가능한 상황에까지 이르게 되었다.더구나 이 때만해도 지금의 DNS 호스트 이름처럼 계층적인 형태가 아니었기 때문에 관리가 더욱 힘들었고 HOSTS.TXT를 대체할 다른 방법이 절실한 상황이었다. 초기의 이름 해결 방법을 대체할 새로운 방법에 대한 조건은 다음과 같이 정하였다.

① 새로운 이름 해결 방법은 네트워크의 확장을 충분히 고려하여 수용할 수 있어야 한다.
② 새로운 이름 해결 방법은 호스트를 분산하여 관리할 수 있어야 한다.
③ 이를 위해 호스트의 이름을 계층적, 직관적으로 구성되어야 한다.

이러한 조건을 모두 만족시키도록 개발된 새로운 이름 해결 방법이 바로 DNS이다. DNS는 Paul Mockapetris에 의해 RFC882, 883으로 제안되었는데 인터넷에서는 거의 15년 가까이 이 방법이 사용되어 왔다 . DNS는 계층적인 네임스페이스를 이용하여 네트워크 확장에 대비한 확장성(Scalability)을 제공하며 분산 관리를 지원할 수 있기 때문에 상당히 효율적인 방법이다. 즉, 왼쪽의 그림에서 보면 ROOT가 A, B, C, D를 포함해 네트워크 내의 모든 호스트를 관리하는 것이 아니라 A, B만 관리하고 C, D에 대한 관리 권한은 B에 위임하며 C는 다시 하위 계층의 호스트를 관리하는 형태이다.

DNS의 기초

◇ DNS 네임스페이스
☞ DNS 호스트 이름은 도메인 이름, 서브 도메인 이름, 호스트 이름으로 구성되며 계층적인 트리 구조를 갖는다. 가장 상위의 도메인을 루트 도메인(ROOT Domain)이라고 하며 단계별로 1단계(Top Level) 도메인, 2단계(Second Level) 도메인 등으로 부르는데, 1단계 아래는 모두 서브 도메인이 된다. .com, .edu, .org, .kr등은 1단계 도메인에 속한다.
이렇게 계층적으로 구성된 도메인에서 각각의 호스트는 상위 도메인의 이름을 반드시 뒤에 포함하고 있으며 호스트 이름을 통해 계층 내의 위치를 파악할 수 있는데, 이런 이름을 FQDN(Fully Qualified Domain Name)이라고 한다. 예를 들어, 오른쪽 그림의 아래 부분에 있는 win2000이라는 호스트의 FQDN은 win2000.research.ez2com.co.kr이 된다.

◇ 존(Zone)
☞ 오른쪽의 그림에서 ez2com회사의 규모가 작다면 ez2com 내의 모든 호스트를 ez2com.co.kr 도메인 서버가 관리할 수 있겠지만, 규모가 커지면 ez2com 내에서 다시 도메인을 나눠 관리하는 것이 효율적이다.
마찬가지로 DNS 네임서버도 두 개 이상의 DNS 네임서버를 운영하는 것이 좋은데, 이 때 각각의 네임서버가 담당할 영역을 존(Zone)이라고 한다. 존은 아래의 특징을 갖는다.

① 도메인 네임이 논리적인 개념인 반면 존은 물리적인 영역을 나타낸다.
② 존이 포함하는 도메인은 연속적이어야 한다.(즉. research와 ez2com 도메인 만을 존으로 구성하여 네임서버를 운영할 수는 있어도 ez2com을 제외한 research와 tech를 존으로 구성하는 것은 불가능하다.)

◇ DNS 네임서버의 종류
☞ 각각의 존에는 하나 이상의 DNS 네임서버가 있어야 한다. DNS 레코드를 직접 관리하는 네임서버를 주 DNS 네임서버라고 하며 주 DNS 네임서버를 보조하여 네트워크 트레픽을 분산시키는 역할을 하는 것을 보조 DNS 네임서버라고 한다. 보조 DNS 네임서버는 주 DNS 네임서버로부터 존 데이터베이스를 주기적으로 복제받아 이용하여 보조 DNS 네임서버가 관리하는 존 데이터베이스는 읽기 전용이기 때문에 보조 DNS 네임서버는 직접 레코드를 변경할 수는없다.
이외에도 요청받은 이름 해결을 존 데이터베이스에 보관된 DNS 레코드로는 해결할 수 없을 때 다른 DNS 네임서버를 이용해야 하는데, 이렇게 다른 DNS 네임서버를 이용했던 결과를 캐시에 보관하는 역할만 하는 캐싱서버가 있다.

◇ DNS 리소스 레코드의 종류
☞ DNS의 존 데이터베이스(실제는 텍스트 파일)에는 이름 해결에 필요한 정보가 레코드 단위로 저장되는데, 이것을 리소스 레코드(Resourc Record)라고 한다. 리소스 레코드의 대표적인 예가 호스트 이름과 IP주소를 대응한 A형식의 레코드인데, 주요 레코드 형식은 다음 표와 같다.

종류	설명
SOA(Start Of Authority)	반드시 존 데이터베이스의 첫 번째 레코드로 나와야 하는 리소스 형식으로 해당 존에 대한 권한을 갖는 네임서버 주소를 나타낸다.
NS(Name Server)	해당 도메인에 할당된 네임서버 목록을 나타낸다.
A(Host)	정방향 조회를 위한 호스트 이름 : IP 주소를 나타낸다.
PTR(Pointer)	역방향 조회에 사용되는 레코드 형식으로 IP 주소 : 호스트 이름을 나타낸다.
SRV(Service)	특정 서비스를 제공하는 호스트를 나타낸다.
CNAME(Alias)	별칭 호스트 이름을 나타낸다. 예를들면, 하나의 IP주소에 두개의 호스트 이름을 지정할 수 있는데, 하나는 A레코드로 저장되고 나머지 하나는 CNAME 레코드로 저장하게 된다.
MX(Mail eXchanger)	특정 도메인 내에서 서비스하는 메일 서비를 나타낸다.
HINFO(Host Information)	CPU나 운영체제 등 호스트에 관한 간략한 정보를 나타낸다.

이름 등록 및 변환 과정
이름 해결은 호스트 이름을 IP 주소로 변환하는 것을 말한다. 이것은 전화번호부에서 이름을 이용하여 전화번호를 찾는 것에 비교할 수 있다. DNS 서버는 호스트 이름을 IP 주소로 변환할 수도 있고, 역으로 IP 주소를 호스트 이름으로 변환할 수도 있는데 전자를 정방향 조회(Forward Lookup), 후자를 역방향 조회(Reverse Lookup)라고 한다.

◇ 재귀와 반복
☞ DNS 클라이언트가 서버에 이름 해결을 요청한 경우 서버 자체에서 처리할 수 없을 때에는 다른 서버를 이용해야 하는데 이 때 두가지 방법이 있다. 하나는 클라이언트의 요청을 받은 서버가 모든 책임을 지고 다른 서버로부터 이름 해결 결과를 받아 클라이언트에 응답하는 것이고 다른 하나는 클라이언트를 다른 서버로 연결해 주는 것이다.
전자의 경우는 재귀(Recursion)에 해당하고 후자의 경우는 반복(Iteration)에 해당한다. 재귀 요청을 받은 DNS 서버는 이름 해결이 성공적이거나 불가능하다는 것이 확인 되어야만 클라이언트에 응답을 할 수 있다.

이에 비해 반복적 이름 해결은 비재귀적 이름 해결이라고도 하는데, 이름 해결을 요청받은 DNS 서버는 그 상태에서 응답할 수 있는 최대한의 결과를 클라이언트에 즉시 넘겨주는 방식이다. 따라서 이름 해결을 요청받은 서버가 해결할 수 없을 경우에는 해결할 수 있을 것으로 생각되는 서버로의 레퍼런스(Reference)를 클라이언트에 넘겨주는 것으로 자신의 역할을 다하게 되며 클라이언트가 직접 레퍼런스를 이용하여 다른 DNS 서버를 이용해야 한다.

◇ 정방향 조회(Forward Lookup) 처리 과정
☞ DNS 서버는 클라이언트-서버 모델을 이요하여 이름 해결 작업을 수행한다. 자신이 요청받은 이름 해결을 처리하지 못할 경우 이를 처리할 수 있는 다른 서버를 통하게 되는데 이 과정을 그림으로 표현하면 다음과 같다.

① 클라이언트가 www.ez2com.co.kr의 IP 주소 요청
② 로컬 네임서버는 먼저 자신의 데이터베이스에 해당 호스트의 이름이 있는지 검색
③ 없을 경우, 루트 네임서버에 요청
④ 루트 네임서버는 호스트 이름을 분석하여 .kr 도메인의 네임서버에 대한 Referral 제공
⑤ 로컬 네임서버가 이를 이용하여 .kr 네임서버에 요청
⑥ kr 네임서버는 다시 호스트 이름을 분석하여 .co.kr 네임서버에 대한 Referral 제공
⑦ 로컬 네임서버가 이를 또 이용하여 .co.kr 네임서버에 요청
⑧ 5번과 마찬가지 방법으로 .co.kr 네임서버는 ez2com.co.kr 네임서버에 대한 Referral 제공
⑨ ez2com.co.kr 네임서버에 요청
⑩ ez2com.co.kr 네임서버는 www.ez2com.co.kr에 대한 IP 주소를 보유하고 있기 때문에 IP 주소를 로컬 네임서버에 제공
⑪ 로컬 네임서버는 결과를 클라이언트에 전달

DNS의 계층적 구조는 로커 네임서버가 네트워크 전체의 호스트 주소를 보관하지 않아도 된다는 전에서 상당히 효율적이다. 이 말은 보관하고 있지 않은 호스트 주소에 대한 요청에 대해서는 항상 상위 네임서버를 이용해야 하기 때문에 네트워크 자원을 낭비할 수 있다는 말도 되는데, 이를 막기위해 보통 캐싱(Caching) 방법을 사용한다.

위 그림에서 로컬 네임서버는 www.IBM.co.kr 의 IP 주소를 일정 시간(TTL : Time To Live) 동안 자신의 데이터베이스에 보관하고 있다가 다른 클라이언트로부터 같은 요청이 들어왔을 때 즉시 결과를 전달하도록 하는 것이다.
TTL을 길게 할 경우와 짧게 할 경우 모두 장단점이 있는데, TTL이 길 경우 네트워크 자원의 낭비를 막을 수 있지만, 호스트 이름이나 IP 주소의 변경을 즉각 반영하지 못한다는 단점이 있다. 반면 TTL이 짧으면 네트워크의 자원을 많이 사용하지만 호스트 이름이나 IP 주소의 변경을 보다 빨리 반영할 수 있다. 대개 TTL은 60분으로 지정되며 관리자가 이를 바꿀 수 있다.

◇ 역방향 조회(Reverse Lookup) 처리 과정

☞ DNS 호스트 이름으로부터 IP 주소를 찾는 것을 정방향 조회라고 하는데, 그 반대 과정 즉, IP 주소로부터 DNS 호스트 이름을 찾는 것을 역방향 조회라고 한다. 사실 정방향 조회를 위한 존 데이터베이스 파일을 이용해도 역방향 조회를 할 수는 있지만, 정방향 조회를 위한 존 데이터베이스 파일은 호스트 이름을 기준으로 인덱싱이 되어 있기 때문에 IP 주소를 이용한 검색에는 적절하지 못한 것이 사실이다.

효율적인 역방향 조회를 위해 특별한 두 번째 도메인을 만들게 되었는데, in-addr.arpa가 그것이다. in-addr.arpa 도메인 역시 보통의 도메인과 마찬가지로 계층적인 구조를 갖고 있지만, 다른 점은 IP 주소를 이용한다는 것이다. 아래의 그림은 넷마스크가 255.255.255.0이고 147.6.9.0부터 147.6.9.255까지의 IP 주소를 할당 받은 도메인에 대한 in-addr.arpa 도메인을 나타낸다.

◇ 캐싱을 이용한 이름 해결
☞ 로컬 DNS 서버가 클라이언트의 이름 해결 요청을 해결할 수 없을 경우 다른 서버를 이용한다는 것은 이미 설명 되었다. 이 경우 로컬 DNS 서버는 단순히 다른 DNS 서버가 해결한 내용을 클라이언트에 전달하는 것만은 아닌다. 대신 일정 기간 동안 같은 이름 해결 내용을 캐시에 보관하고 있다가 같은 내용을 다시 요청할 때 이용하게 된다.
이렇게 캐시만을 전문적으로 담당하는 DNS 서버를 운영할 수도 있는데, 이를 캐싱 서버(Caching-Only Server)라고 한다. 캐싱 서버는 단지 클라이언트의 요청에 대한 응답만을 캐시에 보관하는 역할을 한다. 캐시에 저장된 내용은 최신의 정보를 유지하기 위해 일정 기간이 지나면 삭제되지만 캐시 내에서 삭제되지 않고 유지되는 항목도 있는데, 인터넷의 루트 DNS 서버로의 레퍼런스가 그것이다. 인터넷 루트 DNS 레퍼런스는 전체 인터넷 이름을 관리하는 INTERNIC에서 배포하는데, ftp://ftp.rs.internic.net/domain/의 named.root 파일에 포함되어 있으며 내용은 아래와 같다. 파일을 제대로 보려면 워드패드를 사용해야 아래와 같이 보인다. Down

; This file holds the information on root name servers needed to
; initialize cache of Internet domain name servers
; (e.g. reference this file in the "cache . <file>"
; configuration file of BIND domain name servers).
;
; This file is made available by InterNIC registration services
; under anonymous FTP as
; file /domain/named.root
; on server FTP.RS.INTERNIC.NET
; -OR- under Gopher at RS.INTERNIC.NET
; under menu InterNIC Registration Services (NSI)
; submenu InterNIC Registration Archives
; file named.root
;
; last update: Aug 22, 1997
; related version of root zone: 1997082200
;
; formerly NS.INTERNIC.NET
;
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;
; formerly NS1.ISI.EDU

;
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
;
; formerly C.PSI.NET
;
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
;
; formerly TERP.UMD.EDU
;
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
;
; formerly NS.NASA.GOV
;
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
;
; formerly NS.ISC.ORG

;
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
;
; formerly NS.NIC.DDN.MIL
;
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
;
; formerly NIC.NORDU.NET
;
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
;
; temporarily housed at NSI (InterNIC)
;
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10

;
; housed in LINX, operated by RIPE NCC
;
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129 ;
; temporarily housed at ISI (IANA)
;
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
;
; housed in Japan, operated by WIDE
;
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
; End of File

Windows2000 동적 DNS

답글 남기기 응답 취소