<444E53BCADB9F6BFEEBFB5C1F6C4A7BCAD D30382D E687770>

Transcription

1 한국인터넷진흥원

2 < 목차 > 1 장 DNS 일반 1.1 DNS 개요 DNS 구조 도메인(Domain) 과존(Zone) 개요 DNS 리소스레코드개요 DNS 네임서버및리졸버개요 DNS 도메인위임설정개요 도메인네임리졸루션(resolution) 관련표준목록 장 BIND 2.1 BIND 소개 BIND 설치하기 BIND 설정하기 BIND 운영 장 Windows 2003 DNS 서버 3.1 Windows 2003 DNS 서버설치 윈도우 2003 DNS 서버구성 윈도우 2003 DNS 서버설정 장 Q&A 4.1 BIND 관련 Q&A 네임서버관련 Q&A

3 1 장 DNS 일반 1.1 DNS 개요 도메인네임시스템 (Domain Name System) 은네트워크계층이이해하는 IP 주소와 사람이이해하고쉽게기억할수있는네임(name) 을상호변환해주는분산 데이터베이스시스템으로인터넷의모태가되었던 하였다. ARPANET 의발전과정에서탄생 ARPANET 의본래목적은비싼컴퓨팅자원을공유할수있게하는것이었는데, 초창기소수의호스트들만연결되었던환경에선각호스트에대해숫자형식의 네트워크주소를직접사용하였다. 그러나점차호스트의수가늘어나면서보다 이해하기쉽고기억하기쉬운호스트니모닉(mnemonic) 의사용이도입되었다. 이는보다광범위한범주에서사용될수있는도메인네임체계로발전하여 현재의인터넷네임체계인 DNS가등장하는계기가된다 년대초반, TCP/IP 프로토콜이개발되기시작하던시기의 ARPANET에는 23 개정도의호스트가연결되어있었다. IP 프로토콜이사용되기전에는 NCP(Network Control Protocol) 이라는호스트-호스트통신프로토콜이사용되고 있었는데이시기만하더라도도메인체계에대한필요성이그리크지않았다 년대중반이후, TCP/IP가 DoD(Department of Defense) 에적용시험되고 이어 ARPANET 에적용되었을때, ARPANET에연결된호스트수는약 111개 정도로늘어났다. 이당시많은수의호스트네트워크주소들을일일이외울 수가없으므로이를관리하는방법으로 HOSTS.TXT 라는호스트니모닉과네트워크 주소매핑을위한파일을사용하기시작했다. 이 HOSTS.TXT는 ARPAnet NIC (Network Information Center) 에서관리하며각호스트에서는 NIC이관리하는 호스트서버에 FTP로접속하여최신 HOSTS.TXT 파일을다운받아사용하는 방식이었다. 현재대다수의호스트에서사용하는 hosts 파일은이러한 [ 네트워크주소: 호스트네임 ] 테이블관리방식에상응하는것으로호스트의네임변환체계속에포함되어 사용되고있다

4 1980 년대초반, ARPANET에연결된호스트수는약 562개였고 HOSTS.TXT 파일에대한갱신작업은이제한계에이르렀다. 기존의 HOSTS.TXT 파일을통한 호스트네임관리체계를넘어보다체계적이고효율적인네임체계및관리방안이 필요하게되었다. 그리하여 1983년위스콘신대학에서 DNS 체계를만들었다. DNS는도메인네임체계와이를구현하는계층적인분산도메인 데이터베이스 체계로개발되었고도메인네임체계를구성하는도메인네임은하나의데이터 베이스에서관리하기보다는계층적이고분산구조를갖는데이터베이스체계로 고안되었다. 계층적인네임체계는추가확장이용이한구조를제공하고분산구조의 데이터베이스는네임데이터베이스에대한분산관리체계를가능케함으로써그 관리의효율성을증대시켰다. 그럼, 여기서 DNS 도입으로무엇이얼마나달라졌는지알아보도록하자. 그림 1-1은 DNS 도입적용전과적용후의모습을보여준다. [ 그림 1-1] DNS의도입 DNS 가적용되지않은환경에서는인터넷의네트워크주소를직접사용하여야 원하는호스트와통신할수있다. 그러나인터넷상에는수많은호스트가존재한다

5 특정호스트가어떤 IP 주소를가지고있는지, 어떤서비스를제공하는지를사전에 알지못한상태에서는해당호스트로접근하는방법을파악할수없다. DNS 가적용되면상황은달라질수있다. DNS는계층적인네임체계를제공하므로 미국의버클리대학의웹사이트에대한접근을원하는경우, 버클리대학의 영문표기인 Berkeley와교육기관용도메인인 edu를조합하여 Berkeley.edu를 도메인네임으로사용, 것이가능할수있다. 접속을시도함으로써버클리대학의호스트로접근하는 이때, 인터넷상에는그림처럼인터넷도메인네임데이터베이스를구성하는 DNS 서버가체계적으로구축, 존재해야만한다. 각클라이언트호스트는사용자가 지정한도메인네임의호스트에접속을개시하기이전에먼저도메인네임을 네트워크주소인 IP 주소로변환하는절차를 DNS 서버를사용하여수행한다. IP 주소를파악한이후에는해당 IP 주소를사용하여일반적인네트워크통신에 필요한절차를개시한다

6 1.2 DNS 구조 DNS 는크게도메인네임공간(Domain Name Space) 및리소스레코드 (Resource Record), 네임서버(Name Server), 리졸버(Resolver) 의 3가지기능 요소로구성된다. [ 그림 1-2] DNS의구조 도메인네임공간(Domain Name Space) 은흔히인터넷에서사용되고있는 도메인네임의계층적구조공간을의미한다. 네임공간에속한하나의노드즉, 호스트네임을지칭한다. 도메인네임공간의 분배와도메인네임의할당은전세계적으로도메인네임할당기관을통해 체계적으로할당, 관리되고있다. 이를통해인터넷상에서특정도메인네임은 언제나유일한네임(globally unique name) 으로써유지된다. 도메인네임공간은 네임주소영역을분배, 할당, 구성하는방식을제공한다. 그리고이러한도메인 네임공간은트리(tree) 형태의계층적인구조를이루어져있다. 리소스레코드 (resource record) 는도메인네임공간중에서지정된도메인 - 4 -

7 네임에대해필요한인터넷자원(resource) 정보를매핑하는수단을제공한다. 예를들어 의 IP 주소가 일경우, 이를인터넷상에 알려주기위해서는 이라는네임(name) 에대해 IP 주소속성을 연결시켜 DNS 데이터베이스를구성하여야한다. 이는 zone 파일을사용하여 IN A 이라는형태의표기를사용하여 설정한다. 이러한하나의도메인네임(domain name) 이가지는속성정보를 지정하는수단으로정의된것이리소스레코드이다. 리소스레코드는확장이가능하다. 즉, IPv4 네트워크주소정보를설정하기위해 A type의리소스레코드가사용되고있으나이제 IPv6가도입됨에따라 IPv6 네트워크주소정보를설정하기위해 AAAA type의리소스레코드가추가로 정의되었다. 리소스레코드의확장은기존에정의된리소스레코드에대한영향 없이이루어진다. 리소스레코드는도메인네임시스템체계에있어도메인데이터베이스를 구성하는역할을한다. 네임서버는도메인존(domain zone) 의정보를소유하고이에대한질의에대해 응답하는역할을수행한다. 흔히 DNS 서버라고도하며특히특정질의에대해 자신이소유한도메인존(domain zone) 의정보만그응답으로제공하는동작을 하는 DNS 서버라는의미로써 iterative DNS 서버라고불리기도한다. 또한 도메인네임공간상의특정영역(zone) 에대해관리권한이위임된서버이므로 authoritative DNS 서버, authoritative 네임서버라고한다. 네임서버는인터넷상의도메인네임에대해분산된도메인데이터베이스를 구성한다. 이때도메인데이터베이스는각네임서버에다양한형태의분산구조로 설정된리소스레코드들로이루어진다. 리졸버(Resolver) 는네임서버에의해구성된도메인데이터베이스를검색하는역할을한다. 리졸버는응용애플리케이션프로그램과도메인네임시스템간의인터페이스역할을담당한다. 또한요청된리소스레코드가존재하는위치를도메인네임시스템에서찾고이리소스레코드의정보를최종응답으로되돌려주는기능을담당한다. 리졸버는전체도메인네임시스템에대해전체도메인데이터베이스를검색할수있도록도메인네임시스템검색의시작점이되는루트네임서버 (root name server) 의 IP 주소정보를자신의환경구성파일로가지고있다. 또한리졸버는동일한 DNS 질의를짧은시간내에빈번하게반복하는것을 - 5 -

8 방지하기위해캐시(cache) 를내부에구현하여 DNS 질의결과데이터를일정 기간동안이캐시에저장하여관리한다. 각리소스레코드는레코드자체에 지정된 TTL(Time To Live) 시간동안만리졸버의캐시에존재한후삭제된다. 그러나이러한리졸버의전체기능을모든호스트에구현해야하는것은아니다. 현재대부분의호스트에는전체리졸버기능이아닌스터브리졸버형태로 구현하고있다. 스터브리졸버(Stub Resolver) 는호스트내의응용프로그램에프로그래밍 인터페이스를제공하고응용프로그램의네임질의요청이있는경우, 시스템에 지정된리졸버역할의네임서버로 DNS 질의를요청한다. 리졸버는스터브 리졸버를대신하여전체도메인네임시스템에대하여요청된레코드가존재하는 네임서버를파악하고해당리소스레코드정보를획득한후최종응답결과를 스터브리졸버에게전달한다. 여기에서스터브리졸버는전체도메인네임시스템 (DNS) 에대해원하는리소스레코드의위치를파악할수있는알고리즘을 구현하지않는다. 대신항상 DNS 요청을처리할수있는리졸버 DNS 서버 (resolver DNS server) 의 IP 주소를지정하는것으로충분하다. 흔히 PC에 설정하는 ISP 사업자가제공하는 DNS 서버또는네임서버는이리졸버기능이 설정된서버를지칭한다. UNIX 계열호스트의경우에는 /etc/resolv.conf 파일이 리졸버서버(resolver server) 의 IP 주소를설정하는환경구성파일에해당한다. Windows 계열호스트는 내네트워크환경 의등록정보에서인터넷프로토콜 등록정보에서 IP 주소를설정하면된다( 구체적인설정법은 Q&A 를참조한다). 일반적으로널리쓰이고있는 BIND는네임서버와리졸버를구현한 DNS 서버 소프트웨어이다. 도메인데이터베이스를구성하는리소스레코드는존 (zone) 파일로지정하며여기에작성된텍스트형태의리소스레코드데이터는 DNS 데몬(daemon) 의구동시그텍스트표기내용을해석하여데이터베이스형식으로 변환, 메모리에리소스레코드데이터베이스를구성한다. BIND 의경우, 네임서버와리졸버를모두네임데몬(name daemon) 에포함하고 있다. 따라서 BIND 는용도에따라네임서버로만동작하게하거나, 네임서버와 리졸버모두의기능을수행하도록설정, 운영할수있다. 이상과같이도메인네임시스템(DNS) 은도메인네임체계와각도메인네임에대한속성정보인리소스레코드들을네임서버소프트웨어로구현하여시스템화하였다. 또한분산구조의도메인네임데이터베이스에접근하여원하는도메인 - 6 -

9 네임의리소스레코드데이터를검색하기위한수단으로써소프트웨어로구현된리졸버를정의하였다. 그리고최종단말인호스트에서는도메인네임에대한주소변환을위해호스트내부에구현된스터브리졸버를사용하여원하는네임변환요청을함으로써전체인터넷상의도메인데이터베이스에서원하는정보를얻는다. DNS의구성요소간에는상호도메인데이터베이스의검색과응답을위한프로토콜이필요하다. DNS 프로토콜은애플리케이션계층에속하는애플리케이션프로토콜이다. [ 그림 1-3] DNS 프로토콜 DNS 프로토콜은네트워크를경유하여 DNS 구현요소간에 DNS 질의(DNS query) 와응답(DNS response) 을수행하기위한서버-클라이언트모델의 애플리케이션프로토콜이다. DNS 프로토콜은그림과같이 {TCP,UDP}/IP 프로토 콜스택위에존재한다. DNS 프로토콜은 TCP 및 UDP 포트번호 53 번을사용한다. 네임서버는 TCP와 - 7 -

10 UDP 53 번포트를디폴트포트(default port) 로하여네트워크상의요청에 대기한다. DNS 질의의대부분은 UDP 포트 53 을사용하여질의와응답이이루어진다. 그러나 UDP 헤더이후의 DNS 헤더를포함한 DNS 메시지영역의길이가 512 바이트를초과하는경우, TCP 53번포트를사용하는 TCP 연결을통한 DNS 질의응답이이루어지는메커니즘이존재한다. 이외에 TCP가사용되는경우는 동일한도메인존(domain zone) 을가지고있는네임서버간의도메인존 (domain zone) 데이터송수신을위한존트랜스퍼(zone transfer) 를수행하는 경우이다. 이경우에는많은데이터의전송이필요하므로 TCP를사용한연결을 통해데이터전송요청이이루어진다. DNS 프로토콜은네임서버와리졸버간, 그리고리졸버와스터브리졸버간에 사용된다. 스터브리졸버와응용프로그램은프로그래밍인터페이스를사용하며 DNS 프로토콜을사용치않는다

11 1.3 도메인 (Domain) 과존 (Zone) 개요 DNS 는도메인네임체계를기반으로한다. DNS 의구성요소중도메인네임공간(Domain Name Space) 은인터넷상에존재하는리소스(resource) 에대한네임체계를어떻게체계화할것인가에대한구성방안이라할수있다. DNS 의계층적(hierarchical) 인도메인네임구조는루트도메인(root domain) 으로부터시작하여각서브도메인으로위임(delegation) 하는구조로형성한다. 최상위의루트도메인은특수한도메인으로써모든도메인의부모도메인 (parent domain) 이다. 모든도메인은루트도메인으로부터위임받은서브도메인 (sub domain) 으로정의된다. [ 그림 1-4] DNS 도메인네임공간 도메인네임은. (dot) 로구분된레이블(label) 로구조화된이름으로표시한다

12 이이름에는루트도메인으로부터해당노드에이르는경로상의각계층(level) 을 모두표시함으로써도메인네임공간상에서의그위치를표시한다. 예를들어 도메인네임 kr 도메인에서 co 도메인으로위임된후 다시위임된 example 도메인에속하는 www 라는네임(name) 을지닌노드또는 호스트를의미한다. 이로써도메인네임은그자체로서도메인네임공간에서 유일한이름을지닌다. 이예에서 www, example, co, kr 은계층적구조의각수준(level) 에해당하는 레이블이다. 레이블들은점(dot) 으로구분되어있다. 최상위도메인인루트 도메인에해당하는레이블은널(null) 레이블로서그길이가 0인특수한레이블로 정의하고있다. 널(null) 레이블은루트도메인만이갖는예약된레이블로서타도메인은 이를레이블로사용할수없다. 레이블은 0~63 옥텟(octet) 의크기를가지는숫자/ 문자의조합으로부여하도록 정하고있다. 그러나이중에서 0 의크기를가지는널(null) 레이블은루트노드만이 사용하는레이블로다른노드에는이널(null) 레이블을사용할수없다. 따라서 루트노드가아닌다른노드들에는 1~63 옥텟(octet) 크기의레이블을부여할수있다. 또한레이블에사용할수있는문자숫자기호코드에도제한이정해져있다. 레이블에는 ASCII 코드중 a 에서 z 까지( 또는 A 에서 Z 까지) 의문자, 그리고 0 에서 9 까지의숫자, 그리고기호문자중 - (hyphen) 만을사용할수 있다. 이외의 ASCII 코드는레이블에사용할수없다. 따라서 kim&park.co.kr 이나 make$.com, save_money.co.kr 등과같은도메인네임은존재할수없다. 또한레이블의첫문자에는 - (hyphen) 이사용될수없다. --notice--.co.kr 과 같은도메인은생성할수없다. FQDN(Fully Qualified Domain Name) 은도메인네임을루트도메인으로부터 시작하는전체이름의표기를사용한것으로위의예는 같이도메인네임의끝에루트도메인의널(null) 과 레이블까지완전히표기하는 것을지칭한다. 즉마지막의루트도메인의레이블이널(null) 값이므로. 을 끝에표기함으로써루트도메인까지의경로레이블을모두포함하여도메인네임에 표기한것이다. FQDN 의총길이는구분자역할을하는점(dot) 을포함하여최대 255 옥텟 (octet) 의길이를가질수있다

13 원칙적으로 DNS에서는도메인네임은 FQDN 을사용한다. 단지사용자의편의를 고려하여루트도메인의표기를생략한도메인네임의표기를허용한다. 그러나 시스템내부에서도메인네임에대한 DNS 질의에있어 DNS 프로토콜에사용되는 실제도메인네임은항상 FQDN 형식의도메인네임을사용한다. 만일호스트 시스템의기본도메인이 company.com. 으로설정된경우, 사용자가입력한 도메인네임 은 으로 해석될수있다. 이호스트에존재하는시스템의리졸버루틴은사용자가입력한 을 로해석하여 DNS 질의절차를 수행하고만약이도메인네임이존재하지않는다는결과를얻는경우에는이를다시 으로해석하여 DNS 질의절차를수행하는 방법으로해당도메인네임을해석하려시도할수있다. 곧, FQDN이아닌도메인 네임은상위도메인네임이생략된도메인네임으로해석한다. 이를 PQDN(Partially Qualified Domain Name) 이라고하기도한다. 그러나 FQDN 의경우에는전체도메인이모두표기된도메인네임으로해석한다. 이러한차이는특히네임서버의존(zone) 파일을작성할때주의해야할사항으로서 의도하지않은문제를야기할수있는요인으로작용할수있다. 도메인트리(domain tree) 에서도메인네임은도메인네임공간에속한각 노드(node) 의경로정보를포함한이름이다. 노드는도메인트리에서분기점이나 트리의종단점을이루고있다. 각노드는하나의레이블을갖는다. 트리(tree) 구조로연결된노드들은단일한노드로부터연결된구조를갖는데, 이모든 노드의단일한뿌리가되는노드가루트노드(root node) 이다. 루트노드의 레이블은특수한레이블값인널(null) 레이블을갖는다. 곧, 루트노드는그 이름이없는노드라고할수있다. 루트노드의하위노드로서 com, org, net, kr, jp, int 등의노드가존재한다. 이러한노드들을지칭하여최상위도메인(TLD, Top Level Domain) 이라한다. 그리고이최상위도메인바로아래레벨(level) 의노드들을개념상으로 2단계 도메인(SLD, Second Level Domain) 이라한다. 여기에는 co.kr, or.kr, ne.kr 도메인들이있다. 최상위도메인(TLD) 은 일반도메인(generic domain), 국가도메인(country code domain), 인터넷인프라도메인(infrastructure domain) 으로구분할수 있다. 최상위도메인중일반도메인(generic domain) 은 gtld(generic TLD) 라 하고, 국가도메인은 cctld(country code TLD) 라한다. 이외에인터넷인프라

14 도메인은특수한도메인으로써 ARPA 도메인을지칭한다. 아래는각범주별로구분된최상위도메인(TLD) 현황을정리한것이다. 구분 gtld 최상위도메인 (TLD) 비고.aero,.biz,.com,.coop,.info,.museum, 3자리또는그이상자리수의레이블을갖는범용최상위.name,.net,.org,.pro,.gov,.edu,.mil,.int 도메인. 각도메인별로그사용목적을지니고있음. cctld.kr,.jp,.cn,.us 등과같이 2자리국가코드레이블을갖는국가별도메인 특수도메인.arpa 각국가별관리정책에의해관리하는국가별도메인. 전체 cctld 리스트: 인터넷기반구조에대한정보를제공하기위한목적의특수도메인. e164.arpa, in-addr.arpa, ip6.arpa, uri.arpa, urn.arpa의하위도메인존재 [ 표 1-1] 최상위도메인현황 DNS 는분산구조의네임체계이다. 이는분산된구조의도메인데이터베이스를 형성하며도메인데이터베이스도분산관리체계로운영하고있다. 이러한 분산된도메인데이터베이스의구성과분산관리체계를위해위임(delegation) 이 적용된다. 루트도메인은하위의최상위도메인(TLD) 으로해당도메인의관리를위임한다. 그리고최상위도메인은다시 2 단계도메인(SLD) 을생성하여그관리를위임한다..kr 도메인의경우에는루트도메인으로부터국가별도메인인 위임을받고그하위에 위임을하고 co.kr co.kr, or.kr, go.kr, ne.kr.kr 도메인의 등의도메인을생성하여도메인 도메인은다시국내기업기관을대상으로필요한도메인의 등록과그위임을하는구조를형성하고있다. 이러한위임에있어필요한개념이존(zone) 이다. 이는상위도메인으로부터 위임받은도메인을기준으로하위노드를생성, 관리하고다시서브도메인을 생성위임및관리할수있는도메인영역(zone) 을의미한다. 각도메인의 관리자는해당도메인의하위영역을독자적으로관리하는권한을지닌다. 위임은도메인네임의생성, 유지, 삭제등을할수있는일정한영역의도메인에 대한관리권한을위임하는것을의미한다. 즉 도메인네임시스템(DNS) 은이러한위임체계를통해전세계각사이트에서위임받은도메인영역에대한분산된관리체계를유지하고있다. 도메인등록시, 이도메인에대한일정기간동안의사용권과함께해당도메인하위의모든

15 도메인네임의생성, 유지, 삭제등에대한전적인관리권한을위임받게된다. 도메인존(domain zone) 은도메인트리구조에서특정노드와그하위노드를 포함하는일정한영역을지칭한다. example.co.kr 의경우, 한국인터넷진흥원(NIDA) 로부터 example.co.kr 이라 는도메인등록절차를마침으로써해당도메인에대한위임을받는다. example.co.kr 도메인의위임을받은사이트관리자는해당도메인에속한 새로운노드를필요에따라원하는레이블을부여하여도메인네임을생성할 수있다. 웹서버에대해서는 www, 메일서버에대해서는 mail, 도메인의 DNS 서버에대해서는 ns1 과 ns2" 의레이블을갖는노드를생성, 설정한다. 이설정작업을통해인터넷에는새로운도메인네임 " 과 "mail.example.co.kr", "ns1.example.co.kr", "ns2.example.co.kr" 이알려지게 되고이도메인네임을사용한접속이가능하게된다. 여기에서 "example.co.kr" 은 하나의도메인존(zone) 이된다. 이존(zone) 은단일관리자에의해관리되는 도메인네임영역이다. co.kr 은한국인터넷진흥원(NIDA) 가관리하는도메인존(zone) 이다. co.kr 도메 인은 example.co.kr 도메인을포함하는도메인이다. 그러나 co.kr 도메인존 (zone) 은 example.co.kr에대한위임설정관리만을수행하며 example.co.kr 도 메인이가지고있는도메인네임에대한관리는하지않는다

16 1.4 DNS 리소스레코드개요 도메인네임공간(Domain Name Space) 에서설정된도메인네임은그자체로서는 인터넷자원과관련된아무런정보를가지고있지않다. 즉, 하나의도메인네임은 전체네임체계속에서유일성을갖는네임으로서의특성만을가지고있다. 도메인네임은인터넷상에서사용하는각종자원(resource) 정보와연관시킬때, 인터넷네임체계로서의의미를지닐수있다. 리소스레코드(RR : Resource Record) 는도메인네임(domain name) 과인터넷 자원(resource) 수단이다. 정보를매핑하여하나의분산데이터베이스를구성하기위한 [ 그림 1-5] DNS 리소스레코드 리소스레코드(RR) 는도메인네임이갖는속성을표현한다. 하나의도메인네임은 호스트네트워크주소리소스레코드(Host Address RR) 인 A 타입 RR에의해 도메인네임이지칭하는 IP 주소를지정할수있다. 하나의도메인네임은다수의리소스레코드(RR) 를그속성정보로가질수있다. 예를들면, 은 및 의 2개의 IP 주소를 그속성정보로가지면서동시에 "example web site" 라는텍스트문자열을텍스트

17 리소스레코드(TXT type RR) 를사용하여그속성정보로지닐수있다. 이와같이 하나의도메인네임은인터넷네트워크주소를포함하는다양한인터넷자원 (resource) 으로서의속성정보를설정하여인터넷통신에서유용하게사용될수있다. 인터넷네트워크주소는인터넷자원(resource) 정보중의하나로써가장널리 쓰이는도메인네임의인터넷자원속성정보이다. IPv6가도입됨으로써이제는 하나의도메인네임에의해지정되는호스트가 IPv4 주소와 IPv6 주소를동시에 가지고있다면이도메인네임에는 A 타입의리소스레코드(A type RR) 와 AAAA 타입의리소스레코드(AAAA type RR) 를함께설정하게된다. 인터넷자원(resource) 정보는 IP 주소를제외하고도다양한정보가존재한다. 리소스레코드(RR) 는이러한다양한인터넷자원정보를표시하는 체계로서 추가확장정의될수있는유연한구조를지니고있다. 앞으로도다양한 정보가도메인네임에매핑될수있도록추가정의된리소스레코드(RR) 가 등장할것이다. 이와같이동일한도메인네임에대해정의된다수의리소스레코드(RR) 를 RRset 이라한다. 도메인네임중에서 IP 주소속성정보를갖는도메인네임을특별히호스트네임 (host name) 이라한다. IP 주소정보를가지지않는도메인네임이있을수있다. 예를들어 about.example.co.kr 이라는도메인네임을생성하고여기에사이트에 안내문을텍스트문자열리소스레코드(TXT type RR) 를사용하여사이트의 주소와안내사항을포함한문자열을정의하여서비스에이용할수있다. 이경우, about.example.co.kr 은호스트네임(host name) 이라하지않으며단지 example.co.kr 사이트에대한정보를제공하는역할을한다. 리소스레코드는도메인네임에대해관련속성정보를매핑할수있도록구조화 되어있다. 일반적인구조는그림과같이 <Name><TTL><Class><Type><RDATA> 로 구성되어있다. 이중에서 <RDATA> 는리소스레코드(RR) 데이터를표시하는 부분으로써각유형별타입마다그표시하는정보에적합하도록다르게정의된다. 단, 여기에서의필드순서는이해의편의를위해 DNS 서버의존파일(zone file) 작성시에표기하는순서를따랐다. DNS 프로토콜에서의리소스레코드는 <RDLength> 라는 <RRData> 의길이를표시하는필드를추가하여 <Name><Type><Class><TTL><RDLength><RRData> 의순서구조를갖는다

18 <Name> 은도메인네임을의미한다. 도메인네임은필요한리소스레코드데이터를 검색하기위한키인덱스(key index) 역할을한다. 리소스레코드는 <Name> 에 지정된네임을갖는노드에종속된속성정보임을의미한다. <TTL> 은 Time To Live 를의미하는필드이다. 이는해당리소스레코드가 인터넷상에존재하는리졸버의캐시테이블에얼마나오래존속할것인지를 결정하는초(second) 단위의값이다. 이필드는 DNS 체계의효율성을위해 리졸버가한번의질의결과로얻은리소스레코드값을캐시에저장하여일정기간 동안관리함으로써 DNS 질의로인한과다트래픽의유발을방지하는데에 사용한다. 주로인터넷상에존재하는리졸버에의해참조된다. <TTL> 은리소스레코드별로그값이정의된다. 따라서일반적으로는리소스 레코드데이터가자주변경될수있는리소스레코드(RR) 의경우는그값을적게, 그리고네임서버지정과같이오랫동안바뀌지않는데이터를지정하는리소스 레코드(RR) 의경우는길게설정할수있다. <TTL> 값은 0~ 의값을가질수있다. <TTL> 값이 0인경우에는 리졸버는해당리소스레코드를캐시에저장하지않는다. <Class> 는이제그구분의의미가없어진필드로써 IN(Internet) 만을사용하고 있다. BIND와같은경우에는 BIND DNS의버전정보등을조회할수있도록 CHAOS 클래스를사용하기도한다. <Type> 은각리소스레코드의유형을지정하는필드이다. 리소스레코드의각 유형별타입은코드화되어있으며이코드는각레코드타입별로정의되어있다. A 리소스레코드(RR) 는 1, NS 리소스레코드(RR) 는 2, SOA 리소스레코드 (RR) 는 6 등으로정의되어있다. 이외에다양한리소스레코드 <Type> 코드가 정의되어있다. <RDATA> 는각리소스레코드의 <Class> 와 <Type> 별로각기다른구조로 정의되었다. 호스트주소에대한리소스레코드(RR) 에서 A type 리소스레코드 (RR) 의경우, <RDATA> 는 32 bit 로고정된데이터공간을가진다. 여기에 IPv4 주소가이진(binary) 값으로설정된다. IPv6가도입되면서는 128 bit 크기로 고정된데이터공간을지닌 AAAA 타입리소스레코드(RR) 를추가로정의하였다. DNS 서버에설정하는존파일(zone file) 에서는 IP 주소를텍스트형식으로 작성하지만 DNS 질의에의해전달되는 IP 주소는이진(binary) 형태의데이터를 가진다

19 NS 리소스레코드의경우에 <RDATA> 는권한을지닌네임서버의도메인네임을지정한다. 리소스레코드종류 도메인네임에대한속성정보를부여하기위해다양한종류의리소스레코드가정의되어있다. 현재까지정의된리소스레코드종류는아래와같다. TYPE CODE 의미 A 1 A host address 32bit IPv4 주소 NS 2 An authoritative name server 네임서버도메인네임지정 MD 3 A mail destination (Obsolete-useMX) 사용하지않음 MF 4 A mail forwarder(obsolete-usemx) 사용하지않음 CNAME 5 The canonical name for an alias Alias 도메인네임설정, 원래도메인네임을매핑 SOA 6 Marks the start of a zone of authority Zone의속성정보지정 MB 7 A mailbox domain name(experimental) 시험적구현 MG 8 A mail group member(experimental) 시험적구현 MR 9 A mail rename domain 시험적구현 name(experimental) NULL 10 A null RR(EXPERIMENTAL) 시험적구현 WKS 11 A well known service description 호스트의특정 IP주소및해당 IP 주소를통해제공하는 TCP/UDP 서비스포트정보지정 PTR 12 A domain name pointer 도메인네임을매핑함주로 IP 주소의도메인네임지정에사용 HINFO 13 Host information 호스트의 CPU와 OS 정보 MINFO 14 Mailbox or mail list information (EXPERIMENTAL) 시험적구현 MX 15 Mail exchange 메일서버의도메인네임지정 TXT 16 Text strings 문자열정보를지정 RP 17 For Responsible Person 도메인네임별담당자정보 AFSDB 18 For AFS DataBase location AFS DB 위치정보 X25 19 For X.25 PSDN address 도메인네임의 X.25 주소정보 ISDN 20 For ISDN address 도메인네임의 ISDN 주소정보 RT 21 For Route Through NSAP 22 For NSAP address NSAP 주소정보 NSAP-PTR 23 SIG 24 For security signature 보안서명을저장 KEY 25 For security key 보안키를저장 PX 26 X.400 mail mapping information GPOS 27 Geographical Position 도메인네임의지리적위치정보위도, 경도, 고도 비고

20 AAAA 28 IP6 Address 128 bit IPv6 주소정보 LOC 29 Location Information NXT 30 Next Domain EID 31 Endpoint Identifier NIMLOC 32 Nimrod Locator SRV 33 Server Selection ATMA 34 ATM Address NAPTR 35 Naming Authority Pointer KX 36 Key Exchanger CERT 37 CERT A6 38 A6 (IPv6 Address) IPv6 Prefix 및주소정보사용하지않을예정 DNAME 39 DNAME A6과함께사용하는도메인매핑정보사용하지않을예정 SINK 40 SINK OPT 41 OPT APL 42 APL SSHFP 44 SSH Key Finger print UINFO 100 UID 101 GID 102 UNSPEC 103 TKEY 249 Transaction Key DNS 질의에만사용 TSIG 250 Transaction Signature DNS 질의에만사용 IXFR 251 Incremental transfer DNS 질의에만사용 AXFR 252 Transfer of an entire zone DNS 질의에만사용 MAILB 253 mailbox-related RRs (MB, MG or MR) DNS 질의에만사용 MAILA 254 Mailagent RRs (Obsolete - see MX) DNS 질의에만사용 * 255 A request for all records DNS 질의에만사용 [ 표 1-2] 리소스레코드(Resource Record) 종류 상당히많은종류의리소스레코드가정의되었지만이중에서주로사용하는 리소스레코드는한정되어있다. 그러나아래의다양한리소스레코드를용도에 적합하게사용함으로써 DNS 도메인데이터베이스체계를효율적으로사용할수있다. 위리소스레코드중에서그코드가상위에정의된리소스레코드들은실제 도메인데이터베이스를구성하는리소스레코드가아닌 DNS 질의에만사용하는 가상적인리소스레코드타입(type) 이다. 예를들면 AXFR 타입을사용한 DNS 질의에대해서는해당도메인네임을도메인존(zone) 으로하는존(zone) 의전체 리소스레코드(RR) 를모두응답한다. * 의경우에는해당도메인네임이가지는 모든종류의리소스레코드(RR) 들을응답한다. TSIG 및 TKEY는보안이적용된 DNS 질의응답을수행하기위해사용한다

21 도메인위임관련리소스레코드 리소스레코드중에서도메인네임체계의위임체계와관련된정보를표현하는 특별한리소스레코드(RR) 가있다. 이에는 SOA(Start of a zone Of Authority) 리소스레코드(RR) 와 NS(authoritative Name Server) 리소스레코드(RR) 가있다. SOA 리소스레코드(RR) 는도메인존(zone) 에대한정보를표시한다. SOA 리소스레코드는다른리소스레코드와동일하게다음과같은구조를갖는다. <Name><TTL><Class><Type=SOA><RDATA> 단, 여기에서의 <Name> 은존(zone) 의도메인네임이다. 즉, 상위계층의도메인에서 위임을받은노드의도메인네임이어야한다. SOA 리소스레코드는존(zone) 에 대한정보를지정하는리소스레코드이므로존(zone) 에속한다른일반도메인 네임은 SOA 레코드를소유할수없다. SOA 리소스레코드의 <RDATA> 는다음과같은내부필드구조를갖는다. <MNAME><RNAME><SERIAL><REFRESH><RETRY><EXPIRE><M INIM UM > <MNAME> 은해당존(zone) 의최상위마스터네임서버(primary master name server) 도메인네임을지정한다. 이때 <MNAME> 의도메인네임은 FQDN으로 표기한다. <MNAME> 에지정된네임서버는해당존(zone) 에대한전적인관리 권한을지닌마스터네임서버임을의미한다. 이후에도메인의위임과관련된장에서 관련된네임서버의마스터네임서버, 슬레이브네임서버, 최상위네임서버에관련한 상세한설명을한다. <MNAME> 에지정된최상위마스터네임서버는해당도메인의존(zone) 데이터의 생성, 변경, 삭제등을수행할수있는관리권한을지니는네임서버이다. 이 네임서버는후에 DNS UPDATE와같은도메인 네임및리소스레코드의동적 갱신을수행하는메커니즘에서참조되며, 또한마스터네임서버와슬레이브 네임서버간에도메인존(zone) 데이터전체를전송하는메커니즘에있어중요한 역할을한다. <RNAME> 은해당존(zone) 을관리하는담당자(Responsible Person) 의이메일 ( ) 주소를표기하는필드이다. 지정된도메인존(zone) 의담당자의정보를 제공하는역할을한다

22 <SERIAL> 필드는해당존(zone) 의변경에따른버전번호정보필드이다. 존 (zone) 내부의데이터가변경될때마다이 <SERIAL> 필드의버전번호는하나 이상으로증가되어야한다. <SERIAL> 필드의버전번호는해당존(zone) 의 변경여부를파악할수있는중요한정보를제공한다. 마스터네임서버와슬레이브 네임서버간에존(zone) 데이터의일치를유지하기위한메커니즘에서존 (zone) 의변경여부를확인하기위해참조된다. 수작업으로그변경작업을하는 경우에는일반적으로 YYYYMMDDnn 의형식으로버전번호를관리한다. 여기에서 YYYY= 년도, MM= 월, DD= 일, nn= 일련번호의의미를지닌다. 이경우 사용할수있는연도는 4294 까지이다. 그러나도메인네임과리소스레코드에 대한동적변경메커니즘으로 DNS UPDATE 를사용하는경우, 이 <SERIAL> 필드는마스터네임서버에의해자동으로관리된다. <REFRESH> 와 <RETRY>, <EXPIRE> 필드는이존(zone) 에대한정보를갱신 하는메커니즘에있어서의타이머시간정보를지정한다. 슬레이브네임서버는 <REFRESH> 에지정된타이머시간이경과한후에해당존(zone) 에대한갱신을 시도한다. 즉, <REFRESH> 에지정된시간은슬레이브네임서버가해당존 (zone) 에대한변경여부를확인하는주기로설정된다. 슬레이브네임서버는 <REFRESH> 에지정된주기로마스터네임서버에대하여대상존(zone) 의 SOA 리소스레코드를질의하여 <SERIAL> 버전이자신이알고있는 <SERIAL> 버전을기준으로갱신여부를확인한다. <RETRY> 필드값은 <REFRESH> 에의한갱신시도가실패한경우, 다시존 (zone) 에대한갱신을시도하는타이머시간의의미를지닌다. <RETRY> 필드 값은일반적으로 <REFRESH> 값보다작은값이어야한다. <REFRESH> 주기에 의한존(zone) 하도록하기위함이다. 버전정보의확인을하기이전에보다짧은시간내에재시도를 <EXPIRE> 필드는슬레이브네임서버가최상위마스터네임서버로대상존 (zone) 에대한갱신여부확인에실패한경우슬레이브에존재하는동일존 (zone) 의복사존(zone) 을유효한것으로유지할것인가에대한시간설정값이다. <EXPIRE> 필드에지정된기간동안슬레이브네임서버가최상위마스터네임서버로부터대상존(zone) 에대한갱신여부를확인할수없는경우, 슬레이브네임서버는이존(zone) 전체를유효하지않은것으로판단하고이존(zone) 에

23 속한모든도메인네임에대한 네임서비스(name service) 를중지한이후에도 DNS 응답을중지한다. 그러나존(zone) 에대한 <REFRESH> 에설정된주기로 해당존(zone) 의갱신여부를최상위마스터네임서버에대해확인하는시도를 지속한다. <EXPIRE> 값은일반적으로 <RETRY> 나 <MINIMUM> 값보다큰 값으로설정하며일반적으로권장하는설정값은 2 주~4 주정도이다. <MINIMUM> 필드는이존(zone) 에속한모든리소스레코드의디폴트 TTL (default TTL) 값을지정한다. 이값은최소 TTL 값을지정하는것으로만일 리소스레코드에 TTL 값이관리자에의해지정되지않은경우, 이 <MINIMUM> 필드의최소 TTL 값을지정하여사용한다. TTL 값은리졸버(resolver) 의캐시 (cache) 에리소스레코드를저장, 존속시키는기간으로사용된다. <MINIMUM> 필드의값으로는약 1~5 일의기간을설정하는것이권장되고있다. 단, 이 <MINIMUM> 필드의값은리소스레코드의 TTL 이명시적으로지정된경우, 리소스레코드별명시적인 TTL 지정값으로대체하여사용한다. 이와같이 SOA 레코드는존(zone) 의관리에필요한정보를갖고있는중요한 레코드이다. 그리고반드시하나의존(zone) 에반드시하나의 SOA 레코드만 지정되어있어야한다. NS 리소스레코드(RR) 는특정도메인존(zone) 이어느네임서버에위임되어 설정되어있는지를표시한다. NS 리소스레코드도다른리소스레코드와동일하게다음과같은구조를갖는다. <Name><TTL><Class><Type=NS><RDATA> 이중에서 <Name> 은위임되는또는위임된존(zone) 의도메인네임을지정한다. NS 리소스레코드의 <RDATA> 는 NS 리소스레코드의목적에따라아래와같이 NS 레코드의고유한구조를갖는다. <NSDNAME> NS 레코드의경우, <RDATA> 영역에단일한필드 <NSDNAME> 만을가지고있다. <NSDNAME> 은 NS 레코드를소유한 <Name> 의도메인존(zone) 을가지고있는 네임서버(name server) 의도메인네임을지정하는필드이다. 이필드는 FQDN의 도메인네임을설정한다

24 NS 레코드는 SOA 레코드와마찬가지로도메인존(zone) 에대한정보를지니고 있다. 단, NS 레코드는해당존(zone) 이실제로위치한네임서버를도메인네임으로 지정하는정보를지니고있다. NS 레코드는그사용되는방식에따라다음의 2 가지의미로사용한다. 첫째는상위도메인존(zone) 에서위임되는도메인존(zone) 의네임서버를 지정하는경우이다. 예를들어 example.co.kr. 존(zone) 은상위도메인 co.kr. 존(zone) 에서위임설정이 되어있다. 상위도메인 co.kr. 의존(zone) 내부에는위임설정을위해아래와 같은도메인네임에대한리소스레코드를정의한다. <Name=example.co.kr.><TTL><Class><Type=NS>< NSDNAME=ns1.example.co.kr.> <Name=example.co.kr.><TTL><Class><Type=NS>< NSDNAME=ns2.example.co.kr.> <Name=ns1.example.co.kr.><TTL><Class><Type=A><ADDRESS= > <Name=ns1.example.co.kr.><TTL><Class><Type=A><ADDRESS= > 이는 co.kr. 도메인에서 example.co.kr. 이라는서브도메인(sub domain) 이 ns1.example.co.kr. 과 ns2.example.co.kr. 의네임서버에위치하고있음을설정한 것이다. 이러한설정은리졸버서버가루트도메인으로부터 example.co.kr. 도메인에대한질의를하는과정에서 co.kr. example.co.kr. 이설정된네임서버정보를얻을수있게한다. 도메인에이르러원하는도메인 곧, 도메인을위임하는상위도메인에설정하는 NS 레코드는리졸빙(resolving) 과정에서도메인트리구조에서해당도메인을검색하기위한다음단계네임 서버의위치정보를알려주는역할을한다. 이경우에 NS 레코드에의해지정된네임서버의도메인네임에대해네트워크주소정보의지정이필요하다. 리졸버가 co.kr. 도메인에대해질의한결과그네임서버의도메인을파악했다하더라도네임서버의도메인이 example.co.kr. 도메인에속해있다면아직그네임서버의네트워크주소를알지못하는상황에서는도메인에대한질의절차는물론네임서버의네트워크주소를파악할수가없게된다. 이러한상황을피하기위해상위도메인이위임설정을하는경우, 해당네임서버의도메인네임을 NS 레코드로지정한후해당도메인네임이자신의도메인에속한도메인네임일

25 경우, 즉위예시와같이 example.co.kr. 도메인네임이 co.kr. 도메인에속해 있는경우에는해당도메인네임의네트워크주소정보를제공해야한다. NS 레코드아래에지정된 레코드라한다. A 리소스레코드는이를위한것이며이를글루 글루레코드(glue record) 는그단어가의미하는바와같이접착제역할을한다. 곧, 상위도메인에서하위도메인으로의위임관계를위해하위도메인의네임서버로네트워크주소를알려줌으로써네임리졸빙(name resolving) 절차를연결해주는역할을한다. 상위도메인의글루레코드설정을위해상위도메인과동일도메인에속한도메인네임을갖는네임서버를사용하는경우, 도메인신청시해당네임서버의도메인네임에대한네트워크주소정보를함께알려주어야한다. 글루레코드는리졸버에의한리졸빙절차에사용되므로만일글루레코드의네트워크주소가실제사용하는네임서버의네트워크주소와상이하다면리졸빙에문제가발생할수있다. 두번째는해당존(zone) 의 SOA 레코드와함께해당존(zone) 에대해지정된 NS 레코드의경우이다. 예로써 example.co.kr. 도메인은위의 co.kr. 도메인으로부터위임을받아 ns1.example.co.kr. 리소스레코드를설정한다. 네임서버와 ns2.example.co.kr. 네임서버에아래와같이 <Name=example.co.kr.><TTL><Class><Type=SOA><MNAME=ns1.example.co.kr.><RNAME><SERIAL><REFRESH> <RETRY><EXPIRE><MINIMUM> <Name=example.co.kr.><TTL><Class><Type=NS><NSDNAME=ns1.example.co.kr.> <Name=example.co.kr.><TTL><Class><Type=NS><NSDNAME=ns2.example.co.kr.> <Name=ns1.example.co.kr.><TTL><Class><Type=A><ADDRESS= > <Name=ns2.example.co.kr.><TTL><Class><Type=A><ADDRESS= > 이때설정된 NS 레코드는이도메인존(zone) 의네임서버를지정하는것으로리졸버의 질의절차보다는도메인존(zone) 에대한관리메커니즘에사용된다. 위의예에서 SOA 레코드에지정된 <MNAME=ns1.example.co.kr.> 은이도메인 존(zone) 의최상위마스터네임서버가 ns1.example.co.kr. 네임서버임을지정한다. 그리고그아래 2개의 NS 레코드는각각 ns1.example.co.kr. 과 ns2.example.co.kr. 서버가이도메인존(zone) 의네임서버임을지정한다

26 SOA 레코드의 <MNAME> 과해당존(zone) 의 NS 레코드를통해이도메인존 (zone) 에대한네임서버구성정보를파악한다. 즉, 위와같은경우에는이도메인 존(zone) 은 2개네임서버 ns1.example.co.kr. 과 ns2.example.co.kr. 이존재하며 이중에서 ns1.example.co.kr. 이마스터네임서버(master name server) 이고 ns2.example.co.kr. 이슬레이브네임서버로설정되어있는구조임을알려준다. 이러한정보는해당도메인존(zone) 이생성되거나수정이가해지는경우에네임 서버중에서어느네임서버가슬레이브네임서버로써존(zone) 데이터의전송을 마스터네임서버로요청해야하는지를알려준다. 곧, 도메인존(zone) 에설정된존(zone) 의도메인네임에대한 NS 레코드는 SOA 레코드와더불어도메인존(zone) 에대한관리메커니즘을정의하는역할을한다. 이정보들은마스터서버가특정도메인존(zone) 의갱신이이루어진경우, 슬레이브서버로이를알리는 NOTIFY 메시지를전송해야할때, 대상존 (zone) 의 NOTIFY 메시지를수신해야하는네임서버정보를파악하는데참조된다. 이경우, NS 레코드로지정된네임서버중최상위마스터네임서버에해당하는 네임서버를제외한모든 NS 레코드의지정된네임서버로 NOTIFY 를송출한다. AXFR 및 IXFR 등존(zone) 데이터의전송(transfer) 메커니즘에서는슬레이브 서버가 AXFR 또는 IXFR 메시지와같은전송요청메시지를송출해야할최상위 마스터네임서버를파악하는데에있어 SOA 레코드의 <MNAME> 필드값을 참조한다. 이외에도메인네임과리소스레코드에대한 DNS 동적변경(dynamic update) 메커니즘, 즉 DNS UPDATE 에서는수정을하고자하는도메인존(zone) 의 SOA 레코드를파악한후네임서버중에서해당리소스레코드수정이이루어져야 하는최상위마스터네임서버로직접접근하여해당레코드의동적변경을수행한다. 이상과같이 SOA 레코드와 NS 레코드는주로도메인의위임구조및도메인 관리를위한메커니즘을구현함에활용한다. 따라서도메인존(zone) 의이 SOA 레코드와 NS 레코드의설정에는각별한 주의를기울이는것이필요하다. 호스트주소리소스레코드 호스트주소(Host Address) 리소스레코드는가장일반적으로광범위하게사용 되는리소스레코드로써리소스레코드타입은 A(Address) 로표기된다. A 리소스 레코드는 IPv4 주소정보를위한레코드이다. IPv6의도입으로인해새로운

27 리소스레코드 AAAA 리소스레코드가새롭게추가정의되었다. 이로써현재 인터넷을위한호스트주소리소스레코드는 A 리소스레코드와 AAAA 리소스 레코드가존재한다. A 리소스레코드는아래와같은구조를지닌다. <Name><TTL><Class=IN><Type=A><RDATA> <Name> 필드는임의의도메인네임이될수있다. A 리소스레코드를가지는도메인네임을특히호스트네임(Host Name) 이라한다. <Class> 는인터넷(IN, Internet) 만이가능하다. 일반적인리소스레코드와는 달리 A 리소스레코드는인터넷클래스에대해서만정의된다. <RDATA> 는 A 리소스레코드의특성에맞게아래와같은구조를지닌다. <ADDRESS> A 리소스레코드는단일필드 <ADDRESS> 만을가진다. <ADDRESS> 필드는 32 bit의크기를갖는필드로써 IPv4 헤더의주소필드와 같은형식을사용한다. 즉, 네트워크상에서사용하는이진(binary) 32 bit IP 주소를여기에설정한다. 네임서버의존파일(zone file) 에는텍스트형태의 IP 주소표기를사용하여설정한다. AAAA 리소스레코드는아래와같은구조를가진다. <Name><TTL><Class=IN><Type=AAAA><RDATA> <Name> 은 A 레코드와동일하게임의의도메인네임이며호스트네임이다. 다만 IPv6 주소를갖는호스트도메인네임이설정될수있다. <Class> 는 A 레코드의경우와동일하게인터넷(IN, Internet) 만이가능하다. AAAA 리소스레코드는 <RDATA> 영역에단일주소필드로정의되어있다. 주소(address) 필드는 128bit 크기로 IPv6 헤더의주소필드와동일한형식의 네트워크바이트순서(network-byte order) 로설정된데이터를설정한다

28 특정도메인네임에대한 A 타입의질의는해당도메인이소유한 A 리소스 레코드정보만응답된다. 또한 AAAA 타입의질의에대해서는해당도메인네임이 소유한 AAAA 리소스레코드정보만응답된다. 따라서임의의도메인네임이 IPv4 또는 IPv6 주소를갖고있는지의여부는 A 타입의질의와 AAAA 타입의질의를모두수행함으로써만파악할수있다. 이메일서비스관련리소스레코드 인터넷네트워크주소정보이외에가장많이사용하고있는리소스레코드로는 MX 리소스레코드가있다. MX 는메일교환기(Mail Exchange) 를의미하며 인터넷상에서는메일서버를의미한다. 메일서비스를위해서는메일주소가필요한데이메일( ) 의주소체계는 <user account>@<domain name> 의형식을갖는다. 이러한이메일주소체계를 DNS 를사용하여효율적으로메일라우팅이가능하도록하기위해사용하는 리소스레코드가 MX 레코드이다. MX 리소스레코드는아래와같은구조를갖는다. <Name><TTL><Class><Type=MX><RDATA> <Name> 은도메인네임을지정한다. 흔히는회사의도메인네임, 즉도메인존 (zone) 네임에지정한다. 그러나존(zone) 에속하는임의의도메인네임을 <Name> 으로지정할수있다. 도메인 example.co.kr. 의경우, 도메인존(zone) 네임인 example.co.kr. 도메인 네임에대해 MX 레코드를설정할수있다. 또한 sales.example.co.kr. 이라는 영업부서용도메인네임을설정하여이에대해 MX 레코드를설정할수도있다. MX 레코드의 <RDATA> 는다음과같은구조를갖는다. <PREFERENCE><EXCHANGE> <PREFERENCE> 는우선순위를지정하는필드로써뒤에지정되는메일서버에대한선호도를지정한다. 이필드의값에따라외부에서이사이트로메일을전송하는메일서버는가장값이적은 <PREFERENCE> 필드값을갖는리소스

29 레코드의메일서버도메인네임을선택한다. 이에따라다수의메일서버가 존재할수있으며이들사이에 <PREFERENCE> 필드를사용하여우선순위를 설정하는것이가능하다. <EXCHANGE> 는메일서버의도메인네임을지정한다. MX 레코드에대한질의는 MX 레코드와 MX 레코드에지정된메일서버도메인 네임의 IP 주소를추가정보로응답한다. 아래는 example.co.kr. 도메인의 MX 레코드설정예이다. <Name=example.co.kr.><TTL><Class><Type=MX><PREFERENCE=10><EXCHANGE=mail.example.co.kr.> <Name=mail.example.co.kr.><TTL><Class=IN><Type=A><ADDRESS= >

30 1.5 DNS 네임서버및리졸버개요 DNS는크게다음의 3 가지요소로구성된다. 도메인네임공간 (Domain Name Space) 과리소스레코드 (Resource Record) 네임서버 (Name Server) 리졸버 (Resolver) 이중에서도메인네임공간(Domain Name Space) 과리소스레코드(Resource Record) 는앞장에서설명한바와같다. 도메인네임공간은도메인네임의구성과그구조를정의하는반면, 레코드는하나의도메인네임이가질수있는속성정보군을정의한다. 리소스 도메인네임은도메인네임공간으로부터도메인할당기관의관리를통해할당과 위임을거쳐이를필요로하는기관또는개인에게부여된다. 리소스레코드는도메인존(zone) 을기준으로관리권한을가진영역내의도메인 네임에대한속성정보를필요에따라생성, 유지, 관리할수있는도메인데이터 베이스를형성한다. 이도메인데이터베이스는인터넷통신에활용될수있는형태로구체화될필요성이있는데, 이러한기능을담당하는구성요소가네임서버와리졸버다. 네임서버는도메인데이터베이스의일정영역(zone) 을소유하고있는 DNS 서버이다. 도메인데이터베이스는 DNS 체계에따라분산구조를지니고있다. 네임서버는이전체도메인데이터베이스중에서관리권한을위임받은일정 영역(zone) 의데이터베이스를관리하고유지하며또한인터넷상의 임의의 리졸버로부터의데이터요청에대해응답한다. 즉, 네임서버는도메인데이터 베이스서버역할을담당한다고할수있다. 네임서버는다음의 2 가지의모드로동작할수있다. 리커시브가아닌모드 (non-recursive mode) 리커시브모드 (recursive mode) 리커시브가아닌모드(non-recursive mode) 는네임서버가기본적으로동작하는동작모드로써모든네임서버는이동작모드를구현해야한다. 리커시브가아닌모드에서네임서버는자신이갖고있는도메인데이터베이스영역(zone) 의

31 정보에대해서만권한을지니고응답한다. 그외의다른도메인중자신이소유하고있는도메인으로부터위임된도메인에대해서는가장근접한네임서버의정보를참조정보로응답한다. 리커시브모드(recursive mode) 는네임서버가옵션기능으로구현, 동작할수 있는동작모드이다. 이는주로클라이언트호스트의리커시브질의(recursive request) 요청에부응하기위한것이다. 리커시브모드로동작하는네임서버는 클라이언트에서리커시브질의요청이있는경우, 자신의포함하고있는리졸버 루틴을사용하여리졸버의질의절차를수행하고최종응답결과를클라이언트로 응답한다. 곧, 리커시브네임서버는본래의네임서버기능에리졸버의역할 기능까지포함하여동작하는네임서버라할수있다. 이러한리커시브모드로 동작하는네임서버를리커시브네임서버(recursive name server) 라한다. 리졸버는도메인데이터베이스로부터클라이언트프로그램이요청하는정보를 조회하여클라이언트프로그램에게제공하는기능을수행한다. 곧, 리졸버는도메인 네임서버와사용자프로그램 (user program) 간의인터페이스의기능을한다. 리졸버는 수많은네임서버에의해구성된전체도메인데이터베이스에서원하는정보가 있는위치를파악하고해당네임서버에접근하여요청된정보를조회하는기능을 수행할수있어야한다. 그러나이러한리졸버의전기능을클라이언트호스트에구현하는것은단말시스템의시스템자원의한계등으로비현실적인면이있다. 이에따라리졸버의대부분의기능을리커시브네임서버로이전하고단말호스트시스템에는단순한기능만을지닌리졸버루틴을구현하는옵션이제시되었다. 이러한단순화된기능의리졸버를스터브리졸버라한다. 스터브리졸버(stub resolver) 는현재대부분의호스트에구현된 OS 시스템의 리졸버루틴으로구현되어있다. 스터브리졸버는리졸버의기능대부분을리커시브 네임서버에의존하므로매우간단한동작만을수행한다. 스터브리졸버는전체 도메인데이터베이스의구조를파악할필요없이리커시브네임서버역할을해줄 네임서버의 IP 주소만파악하면된다. 이후의도메인데이터베이스에대한질의는 리커시브질의요청을포함한 DNS 질의를지정된리커시브네임서버로전송하고 최종결과를네임서버로부터응답받는절차만수행한다. 설정하는 대부분의단말에 DNS 서버는이리커시브네임서버를의미하는것으로주로 ISP 등에서 사용자들을위해운영하고있는리커시브모드의동작을하도록설정된네임서버 이다. 스터브리졸버는간단한기능의리졸버로각시스템의시스템루틴으로

32 존재하면서사용자프로그램의도메인네임의 인터페이스기능을수행한다. IP 주소로의변환요청을처리하는 스터브리졸버에반하여리커시브네임서버는전체도메인데이터베이스에대한 접근이가능하여야한다. 순차적으로검색해야하므로루트네임서버의 리졸버는루트노드를시작으로도메인루트구조를 IP 주소를그초기값으로가져야 할필요성이있다. 따라서리커시브네임서버를구성하는경우, 네임서버의환경 설정파일에루트네임서버의 IP 주소정보파일을수작업으로설정해주어야한다. 루트네임서버의 IP 주소정보파일은 INTERNIC에서관리를하고또한인터넷 상으로제공하고있는 다운받아설정한다. ftp://ftp.rs.internic.net/domain/named.cache 의파일을

33 1.6 DNS 도메인위임설정개요 DNS 는분산된도메인데이터베이스를기본구조로한다고이미말한바있다. 리졸버를통한도메인데이터베이스에대한조회가가능하기위해서는도메인 데이터베이스가인터넷상에안정적으로구성이되어있어야한다. 트리구조의도메인네임체계와이와관련된리소스레코드들이인터넷상에서분산데이터베이스를형성하는데있어위임(delegation) 체계는중요한요소가된다. 여기에서는주로도메인의위임과관련된구성이어떻게이루어지는가에그 초점을둔다. 도메인의위임은도메인존(zone) 에해당하는노드에대해설정한다. [ 그림 1-6] DNS 마스터/ 슬레이브네임서버위임구성사례 1 그림은 co.kr. 도메인에서도메인존(zone) example.co.kr. 이위임된상황을 보인것이다

34 도메인 co.kr. 에서는 example 노드를생성하고이노드의도메인네임에대해 NS 리소스레코드를설정한다. 이때, 만일 example.co.kr. 도메인이 3 개의네임서버를사용한다고가정할때, 각각을 NS 레코드를사용하여설정한다. 상위도메인인 co.kr. 도메인에서의 위임되는도메인네임에대해 접근하는경우위임되는도메인의 NS 레코드를지정하는것은해당네임서버로 SOA 레코드정보를제공받을수있다는것을 함축적으로의미한다. 곧 NS 레코드로설정되는도메인네임은하위도메인존 (zone) 의도메인네임이라는의미를가지고있다. 상위도메인 co.kr. 의 NS 레코드는리졸버에의해사용된다. 리졸버는도메인 위임트리구조를루트도메인으로부터하위도메인으로탐색하면서도메인 co.kr의네임서버에서 example.co.kr. 도메인의네임서버정보를얻는다. 위 경우에는 3 개의네임서버에대한정보를얻게된다. 리졸버의입장에서는 example.co.kr 도메인의네임서버들을정확히파악하여 원하는도메인네임의정보를얻을수있는것으로충분하다. 상위도메인의 특정도메인에대한 NS 레코드를사용한위임설정은도메인트리구조를 형성하는수단으로써리졸버의도메인네임리졸루션(resolution) 절차상에서 원하는도메인네임의정보가소재한네임서버의위치를제공하는결정적인 역할을한다. 상위도메인에서위임된하위도메인의네임서버에대한 NS 레코드정보만으로는 리졸버가참조된다음네임서버로네트워크접근을하는데에정보가불충분할 수있다. 이는 NS 리소스레코드는네임서버의도메인네임만을제공하기 때문이다. 이러한이유로상위도메인에서는위임하는하위도메인의네임서버에 대한 A 레코드정보를자신의도메인존(zone) 에서관리한다. 이로써리졸버의 DNS 질의에대해해당도메인의네임서버와그네임서버의 IP 주소를포함한 응답을함으로써리졸버가다음네임서버로접근하는데충분한정보를제공한다. 이때하위도메인의네임서버에대한 A 리소스레코드를글루레코드라한다. 이글루레코드(glue record) 는해당네임서버의도메인네임이위임을하는상위 도메인에속한도메인네임인경우에한한다. 곧, 앞의그림에서와같이 example.co.kr. 도메인의네임서버가 ns1.example.co.kr. 인경우에는 co.kr. 도메인에속한도메인네임이므로 co.kr. 도메인존(zone) 에그글루레코드를 설정한다. 그러나만일네임서버가 ns1.example.com. 과같이 com. 도메인에

35 속한도메인네임일경우에는글루레코드를 co.kr. 도메인존(zone) 에설정할 수없다. 이런경우에는 example.com. 도메인에 ns1.example.com. 도메인네임에 대한 A 리소스레코드를반드시설정해주어야한다. 만일이리소스레코드의 설정이누락되어있다면리졸버가 상황이발생하여도메인정보를얻을수없게된다. example.co.kr. 의네임서버로접근할수없는 한편 example.co.kr. 도메인의관리자의입장에서는도메인존(zone) 에대한 생성, 변경, 삭제등의관리를안정적으로할수있는방안이필요하다. example.co.kr. 도메인의경우, 그네임서버로서 3개의네임서버를구성하고 있다. 이는네임서버를안정적으로구성하기위한것이다. 그러나 2개이상의 네임서버를구성하는경우, 각네임서버의도메인존(zone) 에대한관리에있어 모든네임서버의도메인존(zone) 내용이동일하도록유지할필요성이발생한다. 즉, 도메인존(zone) 내용이어느네임서버를통해서 DNS 질의/ 응답을수행 하더라도동일하도록관리해야할필요성이있다. 마스터네임서버(master name server) 와슬레이브네임서버(slave name server) 의구성은이러한관리상의목적을충족시키기위한구성방법이다. 마스터 네임서버를주네임서버(primary name server), 네임서버(secondary name server) 라고하기도한다. 슬레이브네임서버를보조 마스터네임서버와슬레이브네임서버의구분은대상도메인존(zone) 단위로 기준하여구분한다. 하나의도메인존(zone) 에대해마스터네임서버인네임서버는 다른별개의도메인존(zone) 에대해서는슬레이브네임서버로동작할수있다. 도메인존(zone) 은마스터네임서버에그원본이존재하고복사본을슬레이브 네임서버의해당도메인존(zone) 데이터로복사하는방식의관리메커니즘을 가진다. 이에사용되는메커니즘을통칭하여존전송(zone transfer) 메커니즘이라한다. 특정도메인존(zone) 에속하는도메인네임과그리소스레코드에대한생성, 변경, 삭제는항상마스터네임서버에서만가능하다. 반면, 슬레이브네임서버는 해당도메인존(zone) 의변경여부를확인하여변경이발생한경우, 마스터 네임서버로해당존(zone) 데이터전송을요청한다. 슬레이브네임서버는전송 받은새로운버전의도메인존(zone) 도메인존(zone) 내용을갱신한다. 데이터로자신이관리하고있는해당 특정도메인존(zone) 의마스터네임서버와슬레이브네임서버구성은도메인

36 존(zone) 의리소스레코드에일정한데이터로반영된다. SOA 리소스레코드의 <MNAME> 필드는해당도메인존(zone) 의최상위마스터 네임서버의정보를지정한다. <MNAME> 필드는 FQDN 형식의도메인네임의 값을가진다. 이최상위마스터네임서버가해당도메인존(zone) 의원본도메인 존(zone) 을가지고있는마스터네임서버로써도메인존(zone) 에대한수정작업이 이루어질수있는서버이다. 나머지네임서버들은이최상위마스터네임서버 로부터존전송(zone transfer) 을받아도메인존(zone) 을관리하는슬레이브 네임서버에속하게된다. 도메인존(zone) 의네임서버들은 NS 리소스레코드에의해지정된다. 도메인존(zone) 에대해 NS 레코드로지정된 DNS 서버들중 SOA 레코드의 <MNAME> 최상위마스터네임서버(primary master name server) 로지정된 네임서버가이모든네임서버에대한마스터네임서버이다. 그림의예에서, example.co.kr. 도메인존(zone) 은최상위마스터네임서버로 ns1.example.co.kr. 네임서버를지정하고있다. 따라서 example.co.kr. 도메인 존(zone) 은마스터네임서버로 ns1.example.co.kr. 서버가그리고슬레이브 네임서버로는 ns2.example.co.kr. 과 ns3.example.co.kr. 서버를가지고있다. 관리자는 ns1.example.co.kr. 서버의도메인존(zone) 을사용하여도메인정보의 수정작업을하게된다. 도메인존(zone) 에지정된 NS 리소스레코드는리졸버에의해서는거의사용되지 않는다. 상위도메인에서해당도메인존(zone) 의글루레코드의도움으로 네임서버정보를이미파악하여접근하기때문이다. 이 NS 레코드정보는주로도메인존(zone) 에대한관리메커니즘에사용된다. DNS NOTIFY 메커니즘은도메인존(zone) 의변경이발생한경우, 슬레이브 네임서버로이사실을즉각적으로통보해주는기능을제공한다. DNS NOTIFY는 도메인존(zone) 에대해설정되어있는 NS 레코드정보를통하여 NOTIFY를 받아야하는슬레이브네임서버리스트를파악한다. 따라서 NS 레코드리스트에서 누락된슬레이브네임서버는 DNS NOTIFY 에의한도메인존(zone) 변경통보에서 제외될수있다. 이는해당누락된슬레이브네임서버의도메인정보갱신이 지연됨으로인한도메인존(zone) 정보의불일치문제를발생시킬수있다. DNS NOTIFY는 NS 레코드들중에서 SOA 필드의최상위마스터네임서버와

37 일치하는네임서버를제외한나머지슬레이브네임서버만을대상으로송출된다. SOA 레코드의 <MNAME> 필드, 즉최상위마스터네임서버정보는 DNS 다이나믹 업데이트(dynamic update) 메커니즘에의해사용된다. DNS 다이나믹업데이트는먼저생성, 삭제하고자하는대상도메인네임이어느 도메인존(zone) 에속해있는지와어느네임서버로접근하여 리소스레코드의 동적갱신(dynamic update) 을요청해야하는지를파악하는질의절차를수행한다. 이과정에서대상도메인네임이속한도메인존(zone) 의 SOA 얻은후 레코드정보를 <MNAME> 필드의최상위마스터네임서버를파악한다. 이는리소스 레코드의갱신은해당도메인존(zone) 의마스터네임서버에서이루어져야하기 때문이다. DNS 다이나믹업데이트메커니즘은최상위마스터네임서버의위치가 파악된후바로이마스터서버로직접접근하여 따라서 DNS 동적갱신요청을한다. SOA 레코드의최상위마스터네임서버의지정에오류가있는경우, DNS 다이나믹업데이트메커니즘이제대로동작하지않을수있다. 일반적이지는않으나네트워크환경에따라아래와같은구성이가능하다. [ 그림 1-7] DNS 마스터/ 슬레이브네임서버위임구성사례

38 이경우에서는도메인존(zone) example.co.kr. 의최상위마스터네임서버가 상위도메인 co.kr. 에서 NS 레코드로지정되어있지않은구성으로되어있다. 이구성에서리졸버(resolver) 에의한통상적인리졸루션(resolution) 절차에 있어서는 ns2.example.co.kr. 서버와 ns3.example.co.kr. 서버를참조하게된다. 반면, 도메인존(zone) 의관리측면에있어서는 ns1.example.co.kr. 서버에서그 관리가이루어지며나머지네임서버 ns2.example.co.kr. 과 ns3.example.co.kr. 서버가 ns1.example.co.kr. 의마스터존(master zone) 의내용을복사하여 DNS 서비스를제공한다. 흔히최상위마스터네임서버가방화벽내부에존재하고외부인터넷으로부터의접근에보안적측면의차단을설정하는경우에해당한다고할수있다. 최상위마스터네임서버를외부에서공격하여마스터존(master zone) 에대한변경, 삭제등을유발하는보안사고로부터보호하기위한목적으로구성할수있다. 이경우, DNS 다이나믹업데이트메커니즘은최상위마스터네임서버에직접 접근이불가능하므로슬레이브네임서버로 DNS 다이나믹업데이트요청을 하고해당슬레이브네임서버는최상위마스터네임서버로이동적갱신요청을 전달(forward) 하는방식으로동작하도록규정한다

39 1.7 도메인네임리졸루션 (Domain name Resolution) 도메인데이터베이스가구성된상태에서이데이터베이스에서필요한정보를 조회하여인터넷응용프로그램이사용하기위해서필요한절차가도메인네임에 대한리졸루션이다. 이는흔히도메인네임의 IP 주소로의변환절차로알려져 있다. 그러나보다일반적인시각에서볼때, 도메인네임이가질수있는 속성정보는단지 용도로만 IP 주소만이아니므로도메인네임을 IP 주소로변환하는 DNS 체계가존재하는것은아니다. 향후보다다양한형태의도메인 네임에대한속성정보가 새로운개념의서비스가가능할것으로예상된다. DNS의도메인데이터베이스에반영되고이를활용한 일반단말호스트의입장에서보면도메인네임의리졸루션은인터넷상의 IP 프로토콜을이용한실제통신을함에있어통신대상호스트주소또는통신대상에대한인터넷속성정보를조회하기위한절차에속한다. 따라서도메인네임에대한리졸루션절차는통신개시절차이전에수행될필요성이있다. 일반적인예로써웹브라우저프로그램은사용자가입력한 URL을근거로 접속대상서버를파악해야한다. 웹서비스의 URL은간략하게표현하면 name>/<directory path>/<file name> 과같은형식을갖는다. URL(Uniform Resource Locator) 은그용어가의미하는바와같이파일과같은 특정한인터넷자원(resource) 에대한인터넷상의고유한위치정보를담고있다. 웹브라우저는실제 IP 프로토콜을사용한통신을개시하기이전에먼저이 URL 중에서 <domain name> 의네트워크주소를파악하여야한다. 이는도메인 네임은네트워크주소가아니며네트워크주소인 IP 주소가있어야 IP 프로토콜을 통해접속대상호스트로 IP 패킷을전송할수있기때문이다. 프로그램은네트워크통신을위한소켓(socket) 도메인네임리졸루션을수행하는함수를호출한다. 인터페이스를호출하기이전에 애플리케이션프로그램 수준에서호출하는네임변환(name translation) 함수로는일반적으로 gethostbyname() 함수를사용해왔다. 이함수는네임문자열을입력값으로 받아 IPv4 주소를되돌려주는기능을제공한다. 이과정에서도메인네임 리졸버루틴을호출하고이를통해 IPv4 주소레코드에해당하는 A 리소스 레코드에대한 DNS 질의를수행함으로써도메인데이터베이스에서 IPv4 주소를 조회한후그결과를되돌려준다

40 웹브라우저프로그램은응답된 IPv4 주소를착신네트워크주소로설정하여소켓(socket) 인터페이스함수를호출하고통신절차를개시한다. 따라서일반적인인터넷통신응용프로그램들은사용자가입력하는도메인 네임에대한속성정보의조회절차를거친후본격적인통신절차를개시하는 구조를갖는다. 단말호스트의도메인네임리졸루션기능을제공하는리졸버는스터브리졸버이다. 스터브리졸버는리커시브네임서버의 IP 주소를환경설정데이터로가지고 있으면서이리커시브네임서버로 DNS 질의메시지를송출하고최종응답을 기다린다. 리커시브네임서버는단말클라이언트로부터요청되는리커시브질의요청에 대해네임서버에함께포함하여구현된리졸버루틴으로이요청을넘겨리졸버 루틴이이를처리하도록한다. 리졸버루틴은캐시나네임서버의공유데이터베이스 등의로컬정보를조회하여해당요청도메인네임에대한정보가있는경우, 바로이를응답으로리턴한다. 만일그해당정보가부재한경우, 리졸버는루트 네임서버로부터시작하는도메인트리구조를순차적으로조회하기시작한다. 이를위해리졸버는리커시브네임서버의환경설정데이터로존재하는루트 네임서버의 IP 주소정보를참조한다. 리졸버는도메인트리구조를순차적으로 탐색하면서원하는도메인데이터베이스영역(zone) 이존재하는위치, 즉네임 서버의 IP 주소를파악하고해당네임서버로 DNS 질의를수행한다. 해당네임 서버로부터의응답메시지를단말클라이언트호스트로 DNS 응답 메시지를 사용하여응답한다. 이와함께리졸버루틴은응답결과를로컬캐시에저장한다. 모든네임서버가리커시브네임서버로동작하지는않는다. 일반적으로호스트 단말에설정하는 DNS 네임서버는리커시브네임서버이다. 이는주로 ISP 등에의 해운영되고사용자에게그 IP 주소를공개한다. ( 예, KT의 ) 대부분의네임서버는리커시브가아닌모드(non-recursive mode) 로동작하는 기본적인네임서버이다. 이를이터레이티브네임서버(iterative name server) 라고도 한다. 리커시브모드로동작하지않는네임서버를편의상네임서버(name server) 라하고리커시브모드로동작하는네임서버를리커시브네임서버 (recursive name server) 라고구분하여사용하기로한다. 네임서버는자신이보유한도메인데이터베이스영역(zone) 에대해서만 DNS

41 응답을한다. 해당도메인데이터베이스영역을벗어난영역의도메인네임에 대한질의에대해서는현재보유한도메인영역으로부터가장근접한위임영역의 네임서버정보를참조정보로응답한다. 즉, 리졸버가다음단계의네임서버로 탐색을계속할수있도록다음네임서버정보를제공하는역할만한다. 리커시브네임서버가클라이언트를대신해리졸버의전기능을수행함에비해 네임서버 (name server) 는권한(authority) 을갖는도메인데이터베이스정보에대한 응답만제공하며리졸버기능을사용하지않는다. 따라서이와같이리커시브가 아닌모드 (non-recursive mode) 로동작하는네임서버(name server) 를단말 호스트에 DNS 서버또는네임서버로지정하는경우, 호스트는도메인네임에 대한리졸루션기능을제대로수행할수없게된다

42 1.8 관련표준목록 DNS 는오랫동안인터넷상의성공적인네임체계로자리해왔다. 전세계에헤아릴수없이많은네임서버가구축되어있고모든호스트는리졸버루틴을통해인터넷상에존재하는도메인데이터베이스에접근하여필요한정보를조회하고있다. 이장에서는이지침서에서미처다다룰수없는상세한 구조에대한심층적인파악과참조가가능하도록관련 IETF DNS 프로토콜및 표준목록을정리 하였다. DNS 관련전체 RFC 문서는상당한수에이른다. 여기에서는일반적으로 사용되지않는기능의확장을정의한문서들을제외한문서를중심으로추려서 정리하였다. 이에는향후사용이일반화될수있는기능에대한문서들과 DNS 운영상의참고문서와 DNS 개념명확화를위한문서들을포함하였다. 단, IPv6 관련확장표준문서는여기에서제외하였다. RFC 번호 제목, 비고 RFC1033 DOMAIN ADMINISTRATORS OPERATIONS GUIDE DNS 관리자의운영가이드 RFC1034 (STD13) RFC1035 (STD13) DOMAIN NAMES - CONCEPTS AND FACILITIES 개선보완된 DNS 체계기본표준문서 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION 개선보완된 DNS 구현기본표준문서 RFC1912 Common DNS Operational and Configuration Errors DNS 운영상의구성오류사례 RFC1982 Serial Number Arithmetic SOA 레코드 serial 번호의산술계산 RFC1995 Incremental Zone Transfer in DNS IXFR 신규정의 RFC1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) Zone의갱신에대한 NOTIFY RFC2136 Dynamic Updates in the Domain Name System (DNS UPDATE) 도메인네임에대한동적갱신 RFC2181 Clarifications to the DNS Specification DNS에대한개념명확화 RFC2308 Negative Caching of DNS Queries (DNS NCACHE) 실패한 DNS 질의에대한캐시처리 RFC3425 Obsoleting IQUERY DNS 질의코드 IQUERY 폐기 RFC2535 Domain Name System Security Extensions DNS 에대한보안확장, 관련 RR 정의 RFC2845 RFC2930 RFC2931 RFC3007 RFC3008 RFC3090 RFC3226 RFC3445 Secret Key Transaction Authentication for DNS (TSIG) Secret Key Establishment for DNS (TKEY RR) DNS Request and Transaction Signatures (SIG(0)s) Secure Domain Name System (DNS) Dynamic Update Domain Name System Security (DNSSEC) Signing Authority DNS Security Extension Clarification on Zone Status DNSSEC and IPv6 A6 aware server/resolver message size requirements Limiting the Scope of the KEY Resource Record (RR)

43 RFC 번호 제목, RFC1886 DNS Extensions to support IP version 6 DNS의 IPv6 확장 RR 및도메인정의 AAAA RFC2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering RR/IP6.ARPA 사용귀결진행 RFC3364 RFC3226 RFC3152 Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS) Delegation of IP6.ARPA [ 표 1-3] DNS 관련전체 RFC 문서 비고

44 2 장 BIND 2.1 BIND 소개 BIND(Berkeley Internet Name Domain) 는현재전세계에서가장많이사용되는 DNS 용응용프로그램이다. 이프로그램은유닉스, 리눅스, 윈도우등대부분의운영 체제에서사용이가능하며도메인네임서버와지원라이브러리그리고클라이언트 프로그램이함께배포된다. BIND에대한정보는 BIND 8.x 소개 BIND 8은기존의 BIND 4.x 를개선한것으로새로포함된주요기능은다음과같다. o DNS Dynamic Update o DNS Change Notification o Completely new configuration syntax o Flexible, categorized logging system o IP-address-based access control for queries, zone transfer and updates that may be specified on a zone-by-zone basis o More efficient zone transfers o Improved performance for servers with thousands of zones o The server no longer forks for outbound zone transfer o Many bug fixed BIND 9.x BIND 9는기존의 BIND 구조를전반적으로다시작성한버전으로 BIND 9에서 포함된주요기능은다음과같다. o DNS 보안 - DNSSEC(signed zones) - TSIG(signed DNS request) o IPv6-42 -

45 - IPv6 소켓을통한 DNS 질의에대한응답 - IPv6 관련리소스레코드(A6, DNAME, etc.) - 비트스트링레이블(Bitstring Labels) - 폐기됨 - 실험적인 IPv6 리졸버라이브러리 o DNS Protocol Enhancement - IXFR - DDNS - Notify - EDNSO o BIND 8.x 보다표준안에부합 o View - 하나의서버가여러뷰를지원할수있다. 다시말해서특정클라이언트에게는내부 뷰를보여주고, 다른클라이언트에게는외부뷰만을보이도록설정할수있다. o 다중프로세서지원 o BIND 8.x 보다이식이용이한구조

46 2.2 BIND 설치하기 BIND는 에서다운받을수있다. [ 그림 2-1] ISC BIND 화면 BIND 설치과정은압축된파일을해제한후, 환경을설정(./configure) 하고 make를 수행하면된다. 다음그림은 tar 명령을이용하여다운받은파일을압축해제하는 화면이다. 참고로, BIND8의설치는 src/port/ 아래 vendor OS별 Makefile.set 을 수정하여 make depend; make; make install 로설치하고있고, BIND9 설치시에만 GNU configure and build systems 아래와같은설치과정을거친다. 도입(configure; make; make install) 하여 [ 그림 2-2] 압축해제화면

47 압축을해제후./configure 명령을수행한다. 이과정은현재시스템의상태를 확인하고관련된파일들의존재유무, 사용할옵션등을확인하는과정이다. prefix 옵션을이용하여자신이원하는설치경로를정할수있다. [ 그림 2-3] configure 명령수행화면 이과정이끝나면 make를이용하여 BIND 를설치한다. make가끝나면 root 권한으로 make install 을수행하면설치과정이마무리된다. [ 그림 2-4] make 수행화면

48 2.3 BIND 설정하기 BIND 를설치한후해야할작업은영역데이터(zone) 파일들을설정하는것이다. 우선영역데이터파일중에는호스트이름을주소로매핑하는파일인 db.domain 과반대로주소를이름으로매핑하는 db.addr 파일이있다. 이들영역파일들을하나로묶어주는환경설정파일이필요한데, BIND 8이나 BIND 9에서는 name.conf 라는이름을가지고있다. 앞서소개한영역데이터파일의 형식은표준으로정해진것이므로어떠한 DNS 소프트웨어에서나동일하지만, 환경 설정파일의문법은소프트웨어마다다를수있다. 다음그림을예로들면서영역파일을설정하는과정을보이도록하겠다. example.co.kr도메인을사용하는회사의망주소는 /24이고이 망에는네임서버가 2 대운영되고있다. 웹서버와메일서비스는하나의서버에서 제공하는것으로가정하고 5대의 PC 가운영되고있다고가정한다. [ 그림 2-5] example.co.kr. 도메인구성 영역데이터파일 DNS 검색작업은대소문자를가리지않기때문에영역파일에이름을입력할 때대문자나소문자, 또는둘다섞어사용해도된다. 그러나검색과정에서는

49 대소문자를구별하지는않지만대소문자자체는보존된다. 예를들어영역데이터에 Abc.example.co.kr 이라는레코드를추가하면, abc.example.co.kr 이라는이름으로 검색을해도그레코드를찾을수있지만결과에대문자 A 가그대로나타난다. 리소스레코드는반드시첫번째열부터시작해야한다. DNS RFC 문서에 나타난예제의리소스레코들간에순서가있고대부분의사람들은이러한 순서를따르는데, 이순서를반드시따를필요는없다. 일반적인영역데이터 파일내의리소스레코드들의순서는다음과같다. SOA 레코드 본영역에대한권한(authority) 을나타낸다. NS 레코드 본영역에대한네임서버를나열한다. 가타레코드 본영역내의호스트에대한데이터이다. [ 표 2-1] 일반적인 RR 순서 기타레코드중에는이름을주소로매핑하는 A RR과반대로주소를이름으로 매핑하는 PTR RR, 전형적인이름을위한 CNAME RR 이있으며, IPv6 주소매핑을 위한 AAAA RR 도여기에해당한다. 또한축약어를이용할수도있다. 주석문이나공백라인이있으면영역데이터파일을읽기가수월한데, 영역데이터파일에있는주석문은세미콜론(;) 으로시작하며세미콜론부터그라인의끝까지모두주석문이다. o 영역의기본 TTL(Time To Live) 설정 TTL 값을설정하기앞서먼저 BIND 버전을확인할필요가있다. 그이유는 TTL 기본값이 BIND 8.2 를기준으로바뀌었기때문이다. BIND 8.2보다이전버전에서는 SOA 레코드의마지막필드가 TTL 기본값이된다. 그러나 BIND 8.2가발표되기 바로전에 RFC 2308 이발표되었고, 여기서는 SOA 레코드의마지막필드의 의미를부정적캐싱의 TTL 로정의하였다. 부정적캐싱의 TTL 값이란해당영역에 대한부정적응답( 특정도메인네임이존재하지않거나또는찾고자하는데이터 종류가해당도메인네임에없음을의미하는대답) 을얼마나오랫동안원격 네임서버가캐싱하고있어야하는가를정의하는값이다

50 BIND 8.2 및이후버전에서는영역의기본 TTL 값을 $TTL 제어구문을이용해서 한다. $TTL 구문이선언되면이후의레코드는그생존시간을따른다. 네임서버는질의에대한응답속에이 응답데이터를그 TTL 값을넣어서반환하며, 응답을받은서버는 TTL 시간동안캐싱한다. 데이터가자주바뀌는것이아니라면 TTL 을 며칠이상의큰값으로지정할수있다. 가장길면서도합당한값은일주일정도이며, 짧게는 1 시간정도로지정할수있다. 그보다작은 TTL을이용하는것은 DNS 트래픽이많이유발되기때문에바람하지않다. 일반적으로는 3시간정도를 TTL 값으로 이용한다. BIND 8.2보다이전버전의네임서버를운영한다면 $TTL 구문을추가하면 안된다. 이경우네임서버가이구문을이해하지못하고문법오류로취급한다. o SOA(Start Of Authority) 레코드 SOA RR 은네임서버가영역의데이터에대한가장최고의정보제공처임을 나타낸다. 네임서버는다음의 SOA 레코드때문에 example.co.kr 영역에대한 권한을갖는다. 모든 db.domain 및 db.addr 파일마다 SOA 레코드가필요하며, 하나의영역데이터파일에는반드시하나의 SOA 레코드만있어야한다. example.co.kr. IN SOA ns1.example.co.kr. root.example.co.kr. ( ; 시리얼번호 3h ;3 시간후리플래시 1h ;1 시간후재시도 1w ;1 주일후만료 1h) ;1시간의부정적캐싱 TTL [ 표 2-2] SOA RR 설정예 도메인이름 example.co.kr. 은반드시파일의첫열에서시작해야하며, 도메인 이름의끝은반드시점(.) 으로끝나야한다. 이점(.) 을생략하는경우도메인 이름이자동으로추가되어엉뚱한결과를초래한다. IN 은인터넷을의미한다. IN 클래스이외에도다른클래스들이있지만거의사용되지않는다. 클래스필드는선택적이어서이를생략하면환경설정파일의구문으로부터클래스를결정한다

51 SOA 다음에오는이름 ns1.example.co.kr. 은이데이터에대한주마스터 네임서버의이름이다. 그다음에오는 root.example.co.kr. 은제일처음의. 로바꾸면해당영역에대한책임자의이메일주소가된다. 종종메일주소로서 postmaster, hostmaster, admin 등을볼수있다. 네임서버는 SOA에적힌 이런메일주소를이용하지않는다. 다만영역에문제가생겼을때명시된 주소로이메일메시지를보낼수있도록사람이보기위한용도로이용된다. SOA 레코드는괄호가시작되는곳에서부터괄호가끝나는지점까지여러 라인을차지할수도있다. 괄호속에있는필드들의대부분은슬레이브네임 서버에의해이용되는데, [ 표 2-2] 를간략히설명하면시리얼번호를기준으로 데이터의갱신여부를판단하게되며, 정상적인경우 3시간마다확인을하도록 되어있고, 이때장애가있는경우 1 시간후다시재시도를하고, 이렇게 얻어진데이터파일은 1 주일간유효하며, 부정적정보( 특정도메인네임이존 재하지않거나또는찾고자하는데이터종류가해당도메인네임에없음을 의미) 를얻을경우그것이잘못되었다는사실을 1 시간동안유지함을뜻한다. o NS(Name Server) 레코드 이것은영역에대한각네임서버를나타내며, 각네임서버당하나의 NS를 추가한다. 따라서복수개의네임서버가운영되는경우여러줄의 NS 레코드가 나올수있다. db.domain 파일 o A(Address) 레코드와 CNAME(Canonical Name) 레코드 A 리소스레코드는호스트네임을주소로맵핑하는레코드로, A 는주소(Address) 를 나타낸다. 이름은하나지만주소가두개있는호스트의경우주소레코드를두개 가지고있을수있다. 호스트테이블검색하는것과는달리, DNS 탐색은하나의 이름에대하여하나이상의주소를반환할수있다. 따라서주소를둘이상 가지고있는호스트에대한질의에는둘이상이반환된다. 일반적으로망에서 가까운주소를앞에적고, 멀리있는주소를뒤에적은응답을할것이다. 이러한 기능은주소정렬(address sorting) 이라고한다. 주소정렬이적용되는경우가 아니라면질의마다대답이순환되어반환되므로순서가다르게나열된다. 이러한라운드로빈(round-robin) 기능은 BIND 4.9 에서처음소개되었다

52 CNAME(Canonical Name) 리소스레코드는별명을그에해당하는전형적인 네임으로맵핑한다. 네임서버가 CNAME 레코드를다루는방법은호스트 테이블에서별명이다루어지는방법과는다르다. 네임서버가어느이름을찾을때 CNAME 레코드를발견하면그이름을전형적인네임으로바꾸어서다시그 새로운이름을탐색한다. 일반적으로다중네크워크를갖는호스트가있다면 특정주소에고유한이름의 A 레코드를생성한다. 이때일반사용자에게는 CNAME 레코드에나타난이름만을드러내고시스템관리목적으로이용하는 A 레코드에나타난이름은숨기는것이일반적이다. 모든경우에서 CNAME 레코드대신에 A 레코드를이용해도좋은가? 하는 의문이있을수있는데, 대부분의애플리케이션들에서는문제가발생하지않는다. 왜냐하면애플리케이션들은 IP 주소를찾았는지에대해서만중요하게생각하기 때문이다. 그러나 sendmail 에서는다르다. 일반적으로 sendmail은메일헤더의 별명들을전형적인네임으로대치한다. 이런전형적인네임으로바꾸기 (Canonicalization) 는오직메일헤더내의이름이관련 CNAME 데이터를가지고 있을때만발생한다. 만일 CNAME 레코드를이용하지않으면메일서버호스트에대한 가능한별명을 sendmail 환경설정을잡아줄필요가있다. 이 sendmail 의문제이외에 사용자들이자신들의.rhosts 파일에입력한전형적인네임을확인하려고할때도혼동이 발생한다. 주소데이터를가지고있는이름은그렇지않지만, CNAME 데이터를가지고 있는 IP 주소를탐색하여전형적인네임을얻어야한다. o MX(Mail Exchange) 레코드 DNS를이용하면기존의 HOST.TXT(/etc/hosts) 를이용하는것보다보다 진보된메일라우팅이가능하다. HOST.TXT만을이용하는경우테이블에서 알아낸 IP 주소로메일을전송하여실패한경우다시전송하거나송신자에게 되돌려준다. 이에반해 DNS 를이용하면백업호스트를지정할수있다. 다시 말하면처음메일서버에서장애가발생한경우다른서버에게대신전송할 수있도록해준다. 이러한 MX 레코드에대한설명은 1 장을참조하면된다

53 [ 그림2-6] db.example.co.kr 파일 o db.addr 파일 db.addr 파일은주소를이름으로매핑하는기능을제공한다. 예를들면 example.co.kr. 도메인의경우주소를이름으로매핑하는파일을 db 파일이될수있다. 여기에는 PTR 레코드들이추가되어 전형적인이름을주소로매핑할수있게한다. 다음그림은 db 파일을보여준다

54 [ 그림2-7] db 파일 o db 파일 루프백네트워크를처리하기위한파일로서대부분의호스트가로프백을이용 하지만 망을담당하는서버가없으므로반드시설정하는것이좋다. [ 그림 2-8] db 파일

55 o db.cache 파일 루트도메인에대한네임서버들의위치를담고있는파일로서직접작성하는 것이아니라 ftp.rs.internic.net 에서가져올수있다. 다음그림들은 Internic의 ftp 서버에접속하여 named.root 파일을가져오는과정을보여준다. [ 그림 2-9] 는 ftp 명령으로 ftp.rs.internic.net 에처음접속했을때나타나는화면이다. [ 그림 2-9] ftp ftp.rs.internic.net 실행화면 이름에 anonymous( 익명) 라고입력하고암호로접속한사람의이메일주소를 입력하면다음화면이나타난다. [ 그림 2-10] 접속후초기화면

56 접속후존파일들이 domain 디렉토리에있다는안내를볼수있다. ls나 dir 명령을통해현재폴더의내용을확인할수있다. [ 그림 2-11] ls 명령으로현재폴더내용을확인 cd 명령으로 domain 디렉토리로이동하여 db.cache 나 named.root 를다운로드하면된다. [ 그림 2-12] cd 명령어로 domain 폴더로이동하여파일확인

57 get 명령으로 named.root 다운받을수있다. [ 그림 2-13] get 명령으로파일을다운로드 BIND 환경설정파일 BIND 에서는환경설정파일(configuration file) 을통하여서버가영역데이터 파일들을참조하게된다. 영역데이터파일들은 DNS 표준을따르지만 BIND의 환경설정파일은 BIND 만의고유한형태이다. BIND 환경설정파일의문법은 BIND 4와 BIND 8 사이에서매우큰변화가 있었다. BIND 8과 BIND 9 은동일하다. 이미 BIND 4의환경설정파일을 가지고있다면 named-bootconf라는프로그램을이용하여 BIND 8이나 9의 환경설정파일로변환할수있다. 이파일의위치는 BIND 8과 BIND 9 가다른데, BIND 8에서는 src/bin/named-bootconf 이고, BIND 9에서는 contrib /named-bootconf 이다. o BIND 8, 9 의환경설정파일 BIND 8과 9의환경설정파일의주석문은다음에나오는 C 스타일, C++ 스타일, 쉘(shell) 스타일을이용해야한다. BIND 8 부터는 ; 가설정구문의끝을나타낸다

58 /* C 스타일주석문 */ // C++ 스타일주석문 # 쉘스타일주석문 [ 표 2-3] BIND 8, 9의주석문 또한파일위치지정도옵션중하나로들어갔고, 있을수있다. 다음은 BIND 8과 9 의파일위치지정예이다. 이외에도다른옵션들이 options { directory "/dns1"; }; [ 표 2-4] BIND 8, 9의파일위치지정 BIND 8과 9에서읽어야하는파일을지정하기위해 zone이라는키워드로 시작하고도메인이름과클래스 (IN) 이뒤따라나온다. 중괄호안에서 type 값은 주도메인서버인경우 master 로, 보조도메인서버인경우 slave 로설정하고, 다음에파일이름이나온다. 다음은앞에나온 example.co.kr. 도메인의 /etc/named.conf 예이다. 여기서 db.cache의 type이 hint인점을주목할 필요가있다. [ 그림 2-14] BIND 8, 9의 named.conf 예

59 축약 BIND 의경우축약을이용할수있는데, db.domain 파일에서주로이용하는 기호, 그리고마지막이름반복 기능이있다. o 도메인네임자동확장 환경설정파일에서 zone 라인의둘째필드는도메인이름을나타낸다. 이 도메인이름은축약어를이용할수있다. 점(.) 으로끝나지않는영역데이터 파일내의모든이름들을바로이기원을뒷부분에추가한다. 영역데이터파일들은기원이서로다르다. 물론각각의 따라서다음과같이축약이가능 하다. 여기서 ns2 다음에 (.) 이없으면자동으로도메인이름이확장되어 ns2.example.co.kr 과같이된다. 완전한이름을입력하면서마지막 (.) 을 생략하는경우자동확장이일어나서엉뚱한결과를초래할수도있다. ns1.example.co.kr. IN A ; 완전한이름사용 ns2 IN A ; 도메인자동확장이용 [ 표 2-5] db.example.co.kr에서도메인자동확장예 in-addr.arpa. IN PTR ns1.example.co.kr. ; 완전한이름사용 12 IN PTR ns2.example.co.kr. ; 도메인자동확장이용 [ 표 2-6] db 에서도메인자동확장예 기호 로나타낼수가있다. 이방법은 영역데이터파일의 SOA 레코드에서많이볼수있으며, SOA 레코드는 IN SOA ns1.example.co.kr. root.example.co.kr. ( ; 시리얼번호 3h ;3 시간후리플래시 1h ;1 시간후재시도 1w ;1 주일후만료 1h) ;1시간의부정적캐싱 TTL [ 표 기호를이용한축약예

60 또한 NS 가이미내포되어있으므로도메인이름자체를 생략할수있다. o 마지막이름반복 줄의첫열이공백문자이거나탭문자라면, 가장최근의리소스레코드의 이름을이용한다. 이것은하나의이름에대하여여러개의리소스레코드들이있는 경우에유용하다. 이방법은리소스레코드의종류가다르더라도이용할수있다. 다음은앞서설명한축약을이용한영역데이터파일 db.example.co.kr 이다. [ 그림 2-15] 축약을이용한 db.example.co.kr 파일 다음은축약을이용한영역데이터파일 db 이다

61 [ 그림 2-16] 축약을이용한 db 파일 다음축약을이용한 db 파일이다. [ 그림 2-17] 축약을이용한 db 파일 호스트이름검사 RFC 952 에서호스트이름과그외의이름에대한규칙이정의되었는데, 다음과 같다. 우선호스트이름은영어알파벳문자와숫자의조합으로이루어진다. 또한이름중간에하이픈(-) 이쓰일수있으며, 밑줄문자(_) 는호스트이름으로 쓰일수없다. 호스트이름이아닌다른이름들은인쇄가능한 ASCII 문자들로 구성할수있다. BIND 이후버전에서는대부분이러한호스트이름검사 기능이제공되고있는데, 문제는밑줄문자를호스트이름의일부로쓰고있는

62 망에서문제가발생할수있다는점이다. 이러한강력한이름검사가문제가되는경우설정파일을수정하여이러한 이름을무시하거나경고메시지만나오도록할수있다. BIND 8, 9 의기본설정값을보여준다. 다음은이와관련된 options { }; check-names master fail; check-names slave warn; check-names response ignore; [ 표 2-8] BIND 8 이후의 check-names 기본값 또한 BIND 8 부터는영역파일별로이를설정할수도있다. 이경우전체적으로 설정하는 option 보다는영역에대한설정이우선한다. zone "example.co.kr" IN { type master; file "db.example.co.kr"; check-names fail; }; [ 표 2-9] BIND 8 이후의영역별설정

63 2.4 BIND 운영 BIND 실행 BIND를실행시키기위해서는 root 권한을가져야한다. BIND 서버의위치는 시스템에따라다를수는있지만일반적으로 /usr/sbin 에있다. 그외가능한 디렉토리로는 /etc, /usr/etc 등이있다. #/usr/sbin/named [ 표 2-10] BIND 실행 syslog 검사 BIND를실행시킨후제일먼저확인할것이 syslog 파일에오류메시지가 있는지확인하는것이다. 일반적으로 syslog 에서만든파일은 /var/adm 디렉 토리또는 /var/log 디렉토리아래 messages 라는이름으로존재한다. syslog는 BIND 외에도시스템내의중요사건들에대한기록들이있는데, grep을이용하여 BIND 에관련된부분만을확인하여볼수있다. syslog에서 BIND의 debugging 정보를보기위해서는 /etc/syslog.conf 파일에 아래와같이 *.info 를추가하고 syslog 데몬을 restart 시킨다. *.info;*.err;kern.debug;daemon.notice;mail.crit /var/adm/messages [ 표 2-11] syslog.conf 설정예 nslookup 또는 dig 를이용한검사 nslookup 과 dig는 DNS를이용하는대표적인클라이언트서비스로이를이용하면 기본적으로네임서버가정상적으로동작하는지를확인할수있다. 이때확인할 것은지역도메인이정상적으로찾아지는지, 지역도메인내의호스트의주소가 정상적으로찾아지는지, 그리고원격도메인네임이정상적으로찾아지는지의 여부이다. 현재는 nslookup보다는 dig 의사용이권장되고있다. 슬레이브네임서버운영

64 재해사항을대비하기위해또는네임서버를담당하는시스템의부하를줄이기 위해슬레이브네임서버를운영할수있다. 슬레이브서버는보통자신의영역 파일을가지지않고주네임서버와의통신을통해주네임서버가가지고있는 영역정보를받아질의의응답을보낸다. 주네임서버가아닌, 다른슬레이브 서버가가지고있는영역정보를얻어와서비스를제공하기도한다. 과거에는 이러한주네임서버와슬레이브서버간동기화가주기적인검사(polling) 에의해 이루어지는것이일반적이었다. 이때참조하는것이 SOA 레코드에있는값들이다. example.co.kr. IN SOA ns1.example.co.kr. root.example.co.kr. ( ; 시리얼번호 3h ;3 시간후리플래시 1h ;1 시간후재시도 1w ;1 주일후만료 1h) ;1시간의부정적캐싱 TTL [ 표 2-12] SOA RR 설정예 처음의시리얼번호는 4바이트정수값으로 0부터 (4,294,967,295) 까지의값을 가질수있다. 원칙적으로 1부터시작하여갱신이일어날때마다 1씩증가시키는 것이타당하겠지만, 일반적으로는 YYYYMMDDNN 형식으로수정한년도, 월, 일, 당일, 수정한번호로설정한다. 예를들면 은 2006년 5월 1일 두번째로수정했다는의미가되는것이다. 슬레이브서버는자신이보관중인 시리얼번호와주네임서버의시리얼번호를비교하여, 자신이보관하고있는 번호가작은경우갱신이일어났다고판단하고영역파일을다시전송한다. 따라서주네임서버인경우영역파일의갱신이일어날경우반드시시리얼 번호를증가시켜야한다. 다음의 4 개의필드는단위가생략된경우초로인식하는데, 첫필드값은 재생(refresh) 값으로서슬레이브가주네임서버의갱신여부를확인할시간 간격을의미한다. 일반적으로 8 시간정도가적당하며, 거리가멀거나자주 변경이일어나지않는경우 25 시간도고려해볼수있다. 두번째필드는재시도(retry) 값으로앞서설정된재생시간에주네임서버와연결을시도했는데실패한경우다시시도할시간간격을뜻한다. 일반적으로앞서설정된재생값보다는작은것이일반적이다

65 세번째필드는만료(expire) 값으로이시간동안주네임서버와연경이이루어지지않으면영역전체의데이터를폐기한다. 이필드값은앞서설명한두개의필드값보다는반드시클필요가있다. 네번째필드는부정적캐싱생존시간(negative caching TTL) 으로주네임서버로부터부정적인응답을어느정도캐싱하고있어야하는지를의미한다. 과거에는이러한 4 개의필드에설정하는단위가초만가능했으나, 현재는 h(hour), m(minute), d(day), w(week) 도가능하다. 주네임서버와슬레이브서버간동기화문제를해결하기위해 NOTIFY와같은 방식이새로제공되고있으며, 전체영역데이터를전송하는 AXFR과같은 방법이외에도갱신된영역데이터만을전송하기위한새로운방법(IXFR) 도 제공되고있다. 이에관련된설정은뒤에따로다룬다. 네임서버제어 기존에는스크립트파일을이용하여 이용하여네임서버를제어했었다. named 프로세스를직접제어하거나시그널을 그러나이러한방법으로제어할수있는 기능의제약이문제가되었고, 이를극복하고자 BIND 8.2부터특수제어채널로 메시지를보내네임서버를제어하는방법이등장했다. 이러한방식으로만들어진 것이 BIND 8.x의 ndc(name daemon controller) 이고, BIND 9.x에서는 rndc (remote name daemon controller) 로개선되었다. o BIND 8.X 의 ndc ndc를인자없이실행하면 ndc는 var/run/ndc라는유닉스도메인소켓을통해 로컬호스트에서동작중인네임서버와대화하려고하였다. 일부운영체제는 다른경로명에있는소켓을이용하기도하는데이소켓은일반적으로루트의 소유이며, 소유자만읽고쓰는것이가능하다. BIND 8.2 이후버전의네임서버는 시작시에이유닉스도메인소켓을생성한다. 소켓의경로명이나허가는 controls 구문을이용해바꿀수있다. 예를들어, 소켓의경로는 etc/ndc로 바꾸고, 그룹소유권을 named 로설정하며, 소유자와그룹소유자모두소켓을 읽고쓸수있게하려면다음을이용하면된다

66 control { }; unix /etc/ndc perm 0660 owner 0 group 53 ; 그룹 53 named [ 표 2-13] SOA RR 설정예 이때사용권한(perm) 은반드시 8 진수형태로표시해야한다( 맨앞의 0이 숫자가 8 진수임을나타낸다). 또한소유자(user id) 와그룹식별자(group id) 는 모두숫자이어야한다. 있는사용자만접근할수있도록해야한다. 이유닉스도메인소켓은네임서버를제어할권한이 ndc는 TCP 소켓을통해로컬이아닌원격호스트의네임서버에서메시지를 보낼수도있다. 이기능을이용하려면다음의예처럼 -c 옵션을주고원격 네임서버의이름이나주소와제어메시지를청취(listen) 할포트번호를 (/) 로 구별하여옵션의인자로주면된다. #ndc -c /953 [ 표 2-14] TCP 소켓을통한원격네임서버제어 이렇게 ndc 를통해원격네임서버를제어하려면, 제어될네임서버에서도 설정이필요한데, 제어될네임서버에서는다음과같이 control 구문을이용하여 특정 TCP 포트를통해제어메시지를기다리도록설정할수있다. controls { }; inet * port 953 allow { ndchost }; [ 표 2-15] 네임서버에서의 ndc를통한원격제어를위한설정 ndc 는대화식및비대화식두가지모드로동작한다. 비대화식모드는네임서버에게시킬일을명령행에지정하는방식으로다음은그예이다. #ndc reload [ 표 2-16] ndc를통한비대화식제어

67 명령행에명령을지정하지않으면다음그림과같이대화식모드로들어간다. [ 그림 2-18] 대화식 ndc 실행과 /h 실행화면 /h에서나온것은 ndc 자체에대한명령들의도움화면이고, ndc가이해하는 ( 네임서버가이해하는것이아님) 명령목록을나열한다. 이러한명령들은 ndc 의동작에만영향을미친다. 예를들어, /d 명령은 ndc 가디버깅출력( 예를 들어, 무엇을네임서버에게보내면어떤응답을받는지등) 을생성하게한다. 그러나네임서버의디버깅레벨에는영향을끼치지않는다. ndc를종료할 때에는 /e 명령을이용한다. 실제로네임서버를제어할수있는명령들을알기위해서는 help 명령을이용한다. 여기나열된것들이네임서버를제어할수있는명령들이다

68 [ 그림 2-19] ndc에서 help 실행화면 start와 restart는 builtin 명령으로포함되어있다. 다음은각명령들의기능이다. - getid : 네임서버의현재프로세스 ID 를출력한다. - status : 네임서버에관한유용한상태정보를출력한다. 예를들어, 네임 서버의버전, 디버그레벨, 수행중인영역전송개수, 질의기록이 활성화되어있는지여부등을알려준다. - start : 네임서버를실행한다. named에명령행인자를주고싶다면 start 뒤에 나열하면된다. 예를들어, start -c /usr/local/etc/named.conf 는 named -c /usr/local/etc/named.conf 와같다. - stop : 동적영역이있으면해당영역데이터파일에쓰고네임서버를종료한다. - restart : 네임서버를중지했다가다시시작한다. start처럼 named에넘길 명령행인자를뒤에나열할수있다. - exec : 네임서버를중지했다가다시시작시킨다. restart와달리 named에 넘길명령행인자를지정할수없다. 새로시작하는네임서버는 현재돌고있는네임서버의명령행인자를그대로받는다

69 - reload : 네임서버를리로드(reload) 한다. 주마스터네임서버에서환경설정 - reconfig : 파일을수정하거나영역데이터파일을하나이상고친수에이 명령어를실행하도록하자. BIND 4.9 이후버전의슬레이브 네임서버에이명령어를실행시키면최신이아닌슬레이브영역을 업데이트한다. 그리고 reload 뒤에도메인네임( 들) 을지정하면 네임서버는그영역( 들) 만다시읽어드린다. 네임서버가환경설정파일을검사해새로추가된영역이나 삭제된영역이있는지조사하도록지시한다. 기존의영역 데이터는고치지않고영역을새로추가하거나삭제만한 경우라면이명령어를네임서버로전달하도록하자. 뒤에 -noexpired 플래그를지정하면기한만료된영역에대해서도 네임서버가에러메시지를출력하지않는다. 수천개의영역을 갖는네임서버에이플래그를적용하면이미알고있는만료 에러메시지를보지않아도되기때문에유용하다. - dumpdb : 네임서버의내부데이터베이스를 named_dump.db 라는파일을 복사한다. 이파일의위치는네임서버의현재디렉토리이다. - stats : 네임서버의통계자료를 named.stats 라는파일로붙여넣는다. 이 파일의위치는네임서버의현재디렉토리이다. - trace[level] : 디버깅정보를 named.run 이라는파일로붙여넣는다. 이 파일의위치는네임서버의현재디렉토리이다. 레벨의값을 높게줄수록더자세한디버깅정보를기록한다. - notrace : 디버깅을하지않도록한다. - querylog( 또는 qrylog) : 모든질의를 syslog에기록할것인지아니면 - quit : 제어세션을종료한다. 토글(toggle) 한다. 즉, 이명령어를한번보내면 모든질의를 syslog 에기록하고, 한번더보내면 기록을중지한다. 그리고이러한내용은 LOG_INFO 우선순위로기록된다. named는 QRYLOG 를정의한상태로 ( 기본적으로정의되어 있음) 컴파일 o BIND 8.X 의 rndc rndc도 BIND 8.X의 ndc 와같이네임서버를제어하는기능을하는데, ndc와 비교하여가장중요한변화는 ndc 의경우유닉스도메인소켓을이용했는데, rndc 는유닉스도메인소켓이아닌, inet 도메인소켓을이용한다는것이다

70 이러한 inet 도메인소켓의사용은원격네임서버의제어도가능하게한다. 그리고보안강화를목적으로키값을요구한다. 이용할비밀키를설정하는것이필요하며이러한설정을위한 따라서서로간의통신에 rndc.conf 일을요구한다. 또한 ndc에서는명령행에서명령없이실행하면대화식으로 실행되었는데, rndc에서는명령들을소개하는간단한화면만나타나고바로종료 된다. 즉대화식실행이없다. 다음은명령행에명령없이 rndc 를실행한화면이다. 파 [ 그림 2-20] rndc에서명령없이실행한화면 BIND 9.X 초기에는 ndc에서제공하고있는기능의일부분만지원되었으나 지금은대부분의 rndc 에서도제공되고있다. 또한아래와같은새로운기능이 제공되고있다. - refresh : 슬레이브영역을즉시점검하도록한다. - halt : 대기중인업데이트내용을파일에기록하지않고네임서버를종료한다

71 BIND 9.X 네임서버에서는 rndc가이용할제어채널의디폴트포트번호가 953 으로설정되어있으므로, 포트번호를생략할수있다. 그럴경우포트 953 을기본으로청취하며, 다음과같이 keys 를설정해야한다. controls { }; inet * allow { any; } keys { "rndc-key"; }; [ 표 2-17] 네임서버에서의 rndc를통한원격제어를위한설정 key "rndc-key" { algorithm secret }; hmac-md5; "Zm9vCg=="; [ 표 2-18] key 구문예 위의 key 구문을 named.conf 파일에직접포함시킬수도있지만 named.conf 파일을아무나읽을수있도록허가한다면보안상의문제가될수도있기 때문에, 읽기권한을제한한별도의파일로만든후에 INCLUDE 문을이용하여 named.conf 에포함시키는방법이좋다. 이러한키알고리즘은현재 HMAC-MD5 알고리즘만지원된다. 이알고리즘은빠른 MD-5 보안해시 (hash) 알고리즘을이용해인증을수행한다. 비밀값은암호를 BASE 64 로 인코딩한것이며, named 및인가된 rndc 사용자들이그암호를공유한다. 비밀값을생성하려면 mmencode나 BIND 배포본에포함되어있는 dnssec-keygen 을이용하면된다. 다음은인자없이 dnssec-keygen 을실행하여 도움말로출력하도록한것이다

72 [ 그림 2-21] dnssec-keyggen 도움말출력화면 앞서설명한 named.conf 와 rndc.conf 파일생성을돕는명령어가제공되는데, 그것은 rndc-confgen 을실행시킨화면이다. [ 그림 2-22] rndc-confgen 실행화면

73 BIND의버전이 9.2 이후라면 rndc-confgen -a를이용하여 rndc와 named가 공통으로이용할키파일을생성하도록할수있다. 이때 named.conf 내에 controls 문장이없어야하고, rndc.conf 파일은존재하면안된다. 둘중 하나라도있으면자동설정이되지않는다. 다음은 rndc로현재네임서버 상태를확인한화면이다. [ 그림 2-23] rndc status 실행화면 네임서버를여러개제어할것이라면각각의네임서버에서로다른키를연계 시킬수있다. 이때에는각키를별도의 key 구문으로정의하고서로다른 server 구문으로연계하면된다. 그런후에 rndc에 -s 옵션으로제어할서버를 지정해실행한다. 또한아직특정한네임서버에연계시키지않은키가있다면 명령행에 -y 옵션을이용해특정키를지정할수있다. 마지막으로, 네임서버가 제어메시지를위해 (953 번이외의) 비표준포트를청취하는상황이라면 -p 옵션을이용해어떤포트로연결해야할지 rndc 에게알려주어야한다

74 3 장 Windows 2003 DNS 서버 3.1 Windows 2003 DNS 서버설치 Windows 2003 DNS server는 GUI 방식으로다음과같은과정에따른다. Windows 2003 DNS 서버설치과정 o Windows 구성요소마법사를연다. o - 시작, 제어판을차례로누른다음프로그램추가/ 제거를클릭한다. - Windows 구성요소추가/ 제거를클릭한다. 구성요소에서 네트워킹서비스확인란을선택한다음자세히를클릭한다. [ 그림 3-1] Windows 구성요소마법사 o 네트워킹서비스의하위구성요소에서 DNS( 도메인이름시스템 ) 확인란을선택하고확인을누른후다음을클릭한다

75 [ 그림 3-2] 네트워킹서비스 o 프롬프트가나타나면복사할파일위치에배포파일의전체경로를입력한다음확인을누른다

76 3.2. 윈도우 2003 DNS 서버구성 서버구성마법사사용 o 시작을누르고프로그램, 관리도구를차례로가리킨다음서버구성마법사를클릭한다. [ 그림 3-3] 서버구성마법사시작 - 구성옵션선택화면에서사용자지정구성을선택한다. [ 그림 3-4] 구성옵션 - 서버역할페이지에서 DNS 서버를누르고다음을누른다

77 [ 그림 3-5] 서버역할 o 선택사항요약페이지에서선택한옵션을보고확인한다. 페이지에있어야한다. - DNS 서버설치 - DNS 서버구성마법사를실행하여 DNS 구성 다음항목이이 [ 그림 3-6] 선택사항요약 o 선택사항요약페이지에이러한두항목이나타나면다음을누른다. 선택 사항요약페이지에이러한두항목이나타나지않으면뒤로를눌러서버 역할페이지로돌아가 DNS 를누르고다음을클릭한다

78 o 서버구성마법사가 DNS 서비스를설치하면먼저이서버의 IP 주소가정적 주소인지, 자동으로구성되었는지확인한다. 서버가현재 IP 주소를자동으로 얻도록구성된경우 Windows 구성요소마법사의구성요소구성중페이지에 이서버를정적 IP 주소로구성할것인지묻는메시지가나타난다. 이렇게 하려면다음과같이한다. - 로컬영역연결속성대화상자에서인터넷프로토콜(TCP/IP) 을누른다음 속성을누른다. - 인터넷프로토콜(TCP/IP) 등록정보대화상자에서다음 IP 주소사용을 누른다음이서버의정적 IP 주소, 서브넷마스크및기본게이트웨이를 입력한다. - 기본설정 DNS 서버에이서버의 IP 주소를입력한다. - 보조 DNS 서버에다른내부 DNS 서버의 IP 주소를입력하거나비워둔다. - 사용자는 DNS 의정적주소설정을마치면확인을누른다음닫기를누른다. o 닫기를누르면 DNS 서버구성마법사가시작마법사에서다음단계를수행한다. [ 그림 3-7] DNS 서버구성마법사 - 구성동작선택페이지에서 정방향및역방향조회영역만들기확인란을 선택하고다음을누릅니다

79 [ 그림 3-8] 구성동작선택 o 정방향조회영역생성 - 정방향조회영역생성을위해예를선택하고다음을클릭한다. [ 그림 3-9] 정방향조회영역 - 이 DNS가네트워크리소스에대한 DNS 리소스레코드가들어있는 DNS 영역을호스팅하도록지정하려면주영역을선택하고다음을클릭한다

80 [ 그림 3-10] 영역형식 - 영역이름페이지의영역이름에서네트워크에대한 DNS 영역이름을 지정하고다음을클릭한다. - 영역이름은소규모조직이나지사용 DNS 도메인의이름과같다. ( 예: nida.or.kr) [ 그림 3-11] 영역이름

81 - 영역파일을생성한다. 기본값으로도메인이름.dns 이름으로파일이생성한다. (DNS 데이터베이스는 %systemroot%\system32\dns 폴더에서확인이가능하다.) [ 그림 3-12] 영역파일 nida.or.kr.dns 영역파일 ; Database file nida.or.kr.dns for nida.or.kr zone. ; Zone version: 1 IN SOA nida-dns. hostmaster. ( ; serial number ; refresh ; retry ; expire 3600 ) ; default TTL ; ; Zone NS records NS nida-dns. ; ; Zone records ;

82 - 동적업데이트페이지에서보안되지않은및보안된동적업데이트허용을누르고다음을누른다. 이렇게하면네트워크에있는리소스에대한 DNS 리소스레코드가자동으로업데이트된다. [ 그림 3-13] 동적업데이트 o 역방향조회영역생성 - 역방향조회영역생성을위해예를선택하고다음을누른다. [ 그림 3-14] 영역형식

83 - 역방향조회영역이름을설정한다. [ 그림 3-15] 역방향조회영역이름 네트워크 ID에는인터넷에서사용할수있도록공인받은 IP 주소에대한 정보를사용하여, 클래스에따라입력해야합니다. 역방향조회영역의네트워크 ID 입력은아래와같은규칙을사용합니다. 입력값은 IP 주소가 w.x.y.z 일때 IP 주소중어떤부분을입력시켜야하는지를 나타냅니다. 클래스구분클래스의 IP 주소범위 입력값 A 클래스 ~ IP 주소의앞 8 자리 (w) B 클래스 ~ IP 주소의앞 16 자리 (w.x) C 클래스 ~ IP 주소의앞 24 자리 (w.x.y) [ 표 3-1] 역방향조회영역의네트워크 ID 입력규칙

84 - 영역파일을생성한다. [ 그림 3-16] 영역파일 in-addr.arpa.dns 영역파일 ; Database file in-addr.arpa.dns for in-addr.arpa zone. ; Zone version: 1 1 IN SOA nida-dns. ; serial number hostmaster. ( ; refresh ; retry ; expire ) ; default TTL ; ; Zone NS records NS nida-dns. ; ; Zone records ;

85 - 동적업데이트페이지에서보안되지않은및보안된동적업데이트허용을누르고다음을누른다. 이렇게하면네트워크에있는리소스에대한 DNS 리소스레코드가자동으로업데이트된다. [ 그림 3-17] 동적업데이트 - 전달자페이지에서예, 다음 IP 주소를가진 DNS 서버로쿼리를전달합니다. 를 누르고다음을클릭한다. 이구성을선택하면네트워크외부의 DNS 이름에대한모든 DNS 쿼리가 사용중인 ISP 또는본사에있는 DNS 로전달된다. ISP 또는본사 DNS 서버가사용하는 IP 주소를하나이상입력한다. [ 그림 3-18] 전달자

86 - DNS 서버구성마법사의 DNS 서버구성마법사완료페이지에서뒤로를 눌러설정을변경할수있습니다. 선택사항을적용하려면마침을누릅니다. [ 그림 3-19] DNS 서버구성마법사완료 DNS 서버구성마법사를마치고나면서버구성마법사는이서버는이제 DNS 서버로작동한다. 서버구성마법사에서서버에대한모든변경사항을검토하거나새역할이성공적으로설치되었는지확인하려면서버구성로그를누른다. 서버구성마법사로그는 %systemroot%\debug\configure Your Server.log 에있습니다. 서버구성마법사를닫으려면마침을누른다. [ 그림 3-20] 윈도우 2003 DNS 서버구성완료

87 3.3. 윈도우 2003 DNS 서버설정 윈도우 2003 DNS 서버구성이끝나면, 웹서버, 메일서버, FTP 서버등실제 외부에서접근해야할서버들을도메인에추가한다. 같은서버들의정보를레코드(record) 라고부른다. 도메인에등록되는위와 영역에호스트 (A) 리소스레코드추가 o DNS 콘솔트리에서해당정방향조회영역을마우스오른쪽단추로클릭한다음새호스트 (A) 를클릭한다. o 이름입력란에새호스트의 DNS 컴퓨터이름을입력한다. - IP 주소입력란에새호스트의 IP 주소를입력합니다. - 선택사항으로연결된포인터 (PTR) 레코드만들기확인란을선택하여이름및 IP 주소에입력한정보를기반으로이호스트의역방향영역에추가포인터 레코드를만듭니다. 영역에 A 리소스레코드를추가할때자동으로만들어진 PTR 리소스 레코드는해당 A 리소스레코드가삭제되면자동으로삭제됩니다. - 호스트추가를클릭하여영역에새호스트레코드를추가합니다. [ 그림 3-21] 새호스트

88 영역에 MX( 메일교환기 ) 리소스레코드추가 o DNS 콘솔트리에서해당정방향조회영역을마우스오른쪽단추로클릭한다음새메일교환기(MX) 를클릭한다. [ 그림 3-22] 새메일교환기(MX) o 이레코드를사용하여메일을배달할도메인이름을호스트또는자식도메인 입력란에입력한다. - 지정된도메인이름에메일을배달하는메일교환기또는메일서버호스트의 DNS 호스트컴퓨터이름을메일서버의정규화된도메인이름(FQDN) 입력란에 입력한다. - 옵션으로찾아보기를클릭하여이도메인에서이미호스트(A) 레코드가 정의된메일교환기호스트의 DNS 네임스페이스를볼수있다. [ 그림 3-23] 메일교환기설정

89 이영역에필요한대로메일서버우선순위를조정한다. 확인을클릭하여영역에새레코드를추가한다. 메일서버우선순위는 10 이기본값이며, 메일서버가여러대있다면우선순위를별도로할당해줄수있습니다. 숫자가낮을수록우선순위는높다. 영역에 CNAME( 별칭 ) 리소스레코드추가 o DNS 콘솔트리에서적용가능한정방향조회영역을마우스오른쪽단추로클릭한다음새별칭(CNAME) 을클릭한다. [ 그림 3-24] 새별칭(CNAME) o 별칭이름( 입력하지않으면부모도메인사용) 입력란에별칭이름을입력한다. - 대상호스트의정규화된도메인이름(FQDN) DNS 호스트컴퓨터의정규화된도메인이름을입력한다. 입력란에이별칭이사용될 - 옵션으로찾아보기를클릭하여 DNS 네임스페이스에서호스트(A) 레코드가 이미정의되어있는이도메인의호스트를검색할수있다. - 확인을클릭하여영역에새레코드를추가한다

90 [ 그림 3-25] 별칭설정

91 4 장 Q&A 4.1 BIND 관련 Q&A BIND 버전선택기준은? 현재주로이용되고있는 BIND 버전은 8.X와 9.X 가있다. BIND 9.X는기존의 BIND 8.X 의자료구조나전반적인시스템구조를새로작성한것이다. BIND 이전의 BIND 9.X는 BIND 8.X에비해제공하는기능이떨어졌으나그 이후는거의대동소이하다. 오히려 IPv6 지원, Dynamic Update, DNSSEC, DNS 보안, 그리고응용기능들은 BIND 9.X 가충실하다. 일반적으로 ( 초당 질의수가수천에이르는 ) 아주바쁜네임서버는 BIND 8.X 를이용하고, 그외의경우에는최신버전의 몇몇 BIND 9.X 를사용하고있다. ISP에서는고객편의를위해자사캐시네임서버의네임서버소프트웨어로 BIND 8 계열을사용하고있다. 앞서말한것처럼 BIND 8 계열은성능은 좋으나 DNS 보안상취약점이존재한다. 이에, ISP 업체에서도이를인식하여 상위버전으로의업그레이드를시도하고있으나고객들과의마찰이있어쉽게 업그레이드를하지못하는상황이다. 이것은안전한 DNS 서비스를위해서 향후, ISP 사업자뿐만아니라우리나라인터넷을이끌어가는 NIDA가함께 풀어나가야할과제이다. 여러버전의 BIND 가한서버에설치되었을경우주의사항? 테스트또는버전업그레이드를위해한서버에여러버전의 BIND 가설치할경우, BIND 버전별로디렉토리 (directory) 를생성하여설치하고 BIND 실행시전체경로를 명시하여수행하기를권고한다. 그렇지않고./named 형태로 BIND를실행시켰을 경우, 시스템의 process 상태정보파악시어떤 named 데몬이실행중인지 알아보기어렵다. 다음은 BIND 8.X 에서 Debugging 레벨 3 을주어실행한예이다. BIND 에서 IPv6 가지원되나? BIND 9에서는 named.conf상의옵션으로 BIND가 IPv6질의를인식하도록하고 있다. 옵션은다음과같다. 그러나 BIND 8 에서는네임서버벤더(Vendor) OS에 따라지원여부가다르다. 참고로 IBM의 AIX 5.2/5.3의경우 BIND 8에서 IPv6는 지원되지않지만, Sun Solaris 9의경우에는 BIND 8에서도 IPv6 를지원한다

92 options { } listen-on-v6 { any; }; // 기본포트 53번의 IPv6 NIC를청취하도록함 listen-on-v6 port 1053 { any; }; // 특정포트 1053번만청취하도록설정함 [...]; [ 표 4-1] BIND 9에서 IPv6 지원옵션 BIND 버전확인방법은? 일반적으로 BIND가시작되면버전에관련된정보가 syslog 에전달된다. 따라서 syslog 에저장된메시지를검토하여확인할수있다. syslog로전달된메시지는 일반적으로 /var/adm/messages 또는 /var/log/messages 에있다. 이파일내에 있는내용을검색하기위해 vi 와같은에디터를이용할수도있다. grep이나 sed, awk 와같은정규식을이용할수있는유틸리티를사용할수도있다. 다음 그림은 BIND 의시작메시지부분이다. 첫줄에서시작한시각과버전을 확인할수있다. [ 그림 4-1] named 시작과관련된 syslog 메시지(BIND 8.X) 다음그림은 BIND 9.X의시작과관련된 syslog 메시지이다. 화면에서버전정보를 확인할수있다. 이외에도설정파일이나인터페이스에대한정보도같이알수있다

93 [ 그림 4-2] named 시작과관련된 syslog 메시지(BIND 9.X) 또한 named를실행할때 -v 옵션을주어서화면에버전을출력하게할수도 있다. 다음은 BIND 8.4.7와 BIND 에서명령을수행한화면이다. [ 그림 4-3] named -v 로버전을확인(BIND 8.X) [ 그림 4-4] named -v 로버전을확인(BIND 9.X) 참고로, BIND 버전별취약점공격을대비하여버전정보는안보이게하는 것이좋다. 버전정보를보이지않도록하기위해서는 BIND 8.2이상버전에서는 아래와같이 named.conf 를설정함으로써 BIND 버전정보유출을막을수있다

94 options { version "None of your business.."; [...]; } [ 표 4-2] BIND 8.2 이상에서버전정보설정 BIND 에서 named.conf 파일의설정이정상인지확인하려면? 우선가능한방법은 named를실행한다음 syslog를살펴서부팅과정에서나온 메시지를확인한다. 이를직접로그파일을검색해서확인할수도있고, BIND 9.X인경우 named -g 로메시지를출력하도록할수도있다. 오류가있는 경우줄번호와에러메시지가나온다. named-checkconf 수있다. 프로그램을이용하면 named.conf 파일의설정을확인할 문법적인오류가있는경우줄번호와에러메시지를화면에출력 한다. 다음은 named-checkconf 를수행한예이다. [ 그림 4-5] named-checkconf 실행화면 이와마찬가지로 문법을확인할수있다. named-checkzone 프로그램을이용하면각영역파일들의 BIND 8.X 에서 ndc 로네임서버를제어하고자하면? ndc를인자없이실행하면 ndc 는 /var/run/ndc 라는유닉스도메인소켓을통해 로컬호스트에서동작중인네임서버와대화하려고한다. 일부운영체제는다른 경로명에있는소켓을이용하기도하는데이소켓은일반적으로루트소유이며, 소유자만읽고쓰는것이가능하다. BIND 8.2 및이후버전의네임서버는시작시에 이유닉스도메인소켓을생성한다. 소켓의경로명이나허가는 controls 구문을 이용해바꿀수있다. 이유닉스도메인소켓은네임서버를제어할권한이있는 사용자만접근할수있도록해야한다

95 ndc는 TCP 소켓을통해로컬이아닌원격호스트의네임서버로메시지를보낼 수도있다. 이기능을이용하려면다음의예처럼 -c 옵션을주고원격네임서버의 이름이나주소와제어메시지를청취(listen) 할포트번호를 (/) 로구별하여 옵션의인자로주면된다. #ndc -c /953 [ 표 4-3] TCP 소켓을통한원격네임서버제어 이렇게 ndc 를통해원격네임서버를제어하려면, 제어될네임서버에서도 설정이필요한데, 제어될네임서버에서는다음과같이 control 구문을이용하여 특정 TCP 포트를통해제어메시지를기다리도록설정할수있다. controls { }; inet * port 953 allow { ndchost; }; [ 표 4-4] 네임서버에서의 ndc를통한원격제어를위한설정 BIND 9 에서 rndc 로네임서버를제어하려면? rndc 도 BIND 8.X의 ndc 와같이네임서버를제어하는기능을하는데, ndc와 비교하여가장중요한변화는 ndc 의경우는유닉스도메인소켓을이용했는데, rndc 는유닉스도메인소켓이아닌, inet 도메인소켓을이용한다는것이다. 이러한 inet 도메인소켓의사용은원격네임서버의제어도가능하게한다. 그리고보안강화를목적으로반드시키값을요구한다. 따라서서로간의 통신에이용할비밀키를설정하는것이필요하며이러한설정을위한 rndc.conf 파일을요구한다. named.conf 와 rndc.conf 파일생성을돕는명령어가제공되는데, 그것을 rndc-confgen 이다. 또한 BIND의버전이 9.2 이후라면 rndc-confgen -a를 이용하여 rndc와 named 가공통으로이용할키파일을생성하도록할수있다. 이때 named.conf 내에 controls 문장이없어야하고, rndc.conf 파일은 존재하면안된다. 둘중하나라도있으면자동설정이되지않는다. BIND 9 에서 rndc 로네임서버를여러개제어하려면? 네임서버를여러개제어할것이라면각각의네임서버에서로다른키를 연계시킬수있다. 이땐각키를별도의 key 구문으로정의하고서로다른

96 server 구문에연계하면된다. 그런후 rndc에 -s 옵션으로제어할서버를 지정해실행한다. 또한아직특정한네임서버에연계시키지않은키가있다면 명령행에 -y 옵션을이용해특정키를지정할수있다. 네임서버가제어 메시지를위해 953번이아닌다른포트를청취하는상황이라면 -p 옵션을 이용해어떤포트로연결해야할지 rndc 에게알려주어야한다. 제어대상이되는네임서버에서는설명한바와같이 rndc-confgen을통해 만들어진 key 문장과 controls 문장을 named.conf 에추가하고, 특히제어할 rndc 의주소를등록한다. controls { }; inet * allow { ; ; } keys {"rndc-key"}; [ 표 4-5] 네임서버에서의 rndc를통한원격제어설정 네임서버의재시작없이영역데이터를갱신하고자하면? rndc reload 영역이름또는 ndc reload 영역이름으로네임서버의재시작없이영역데이터를변경할수있다. 네임서버의재시작이나리로드 (reload) 없이영역을추가하거나삭제하고자하면? named.conf 파일에새로운영역을추가하거나기존영역을삭제한후, rndc reconfig 또는 ndc reconfig 를하면추가되거나삭제된다. 영역데이터전송을바로시작하려면? 슬레이브네임서버에게영역데이터전송을바로시작하도록하려면 rndc refresh 영역이름또는 ndc reload 영역이름을하면된다. 전에실행한것과같은인수로네임서버를재시작하려면? rndc 에서는재시작하는기능이아직제공되지않고있다. 그러나 ndc에서는 ndc restart로재시작이가능할뿐만아니라 인수를그대로받아재시작할수있다. ndc exec로바로전에실행했던 네임서버의캐시를저장하고자하면? rndc dumpdb 또는 ndc dumpdb를이용하여캐시된내용을디스크로저장 할수있다

97 네임서버의캐시를지우고자하면? BIND 9.X인경우 rndc flush 로캐시를지울수있다. 그러나 BIND 8.X의경우 네임서버를다시시작하여한다. 네임서버를영역의주네임서버로설정하는방법은? 영역의주네임서버로설정하고자하는경우 named.conf 파일에다음과같이 type 속성값을 master 로설정하면된다. 다음은 named.conf의내용중에서 nida.or.kr 의주네임서버로설정하는부분이다. zone "example.co.kr" IN { type master; file "db.example.co.kr"; }; [ 표 4-6] named.conf 중주네임서버로설정부분 네임서버를영역의슬레이브 (slave) 네임서버로설정하는방법은? 영역의슬레이브네임서버로설정하고자하는경우 named.conf 파일에다음과 같이 type 속성값을 slave 로설정하고주네임서버들을지정하면된다. 다음은 named.conf의내용중에서 nida.or.kr. 의슬레이브네임서버로설정하는 부분이다. zone "example.co.kr" IN { type slave; master { }; file "bak.example.co.kr"; }; [ 표 4-7] named.conf 중슬레이브네임서버설정부분 네임서버가여러영역을담당하도록설정하는방법은? 하나의네임서버가여러영역을담당하도록하기위해서는 named.conf 파일에 추가된영역당존문장을삽입하면된다. 이때네임서버의 type은 master 일수도있고 slave 일수도있다

98 zone "example.co.kr" IN { type master; file "db.example.co.kr"; }; zone "example2.co.kr" IN { type master; file "db.example2.co.kr"; }; [ 표 4-8] named.conf 중복수영역을담당하도록설정하는부분 하나의영역을여러파일로나누어담당하려면? 영역을여러파일로나누어관리하고자하면영역파일이름에명시된파일 내에 $include 문장으로다른파일을포함시키면된다. Dynamic Update 를허용하려면? 일반적으로다음과같이 allow-update 문장을 named.conf 파일에포함하면된다. zone "example.co.kr" IN { }; type "db.example.co.kr"`; allow-update { ; }; [ 표 4-9] BIND 8.X 주네임서버에서의 Dynamic UPDATE 허용설정 allow-update 문장을통한 dynamic update 허용은보안상문제가있으므로 지원이가능하면반드시 update-policy 문장을이용하여 TSIG를이용한 갱신을이용하는것이좋다. BIND 9.X의경우 TSIG-signed UPDATE을지원 하는데, 이때에는 update-policy 라는문장을추가로필요로한다. update-policy { grant deny keyname nametype domain-name [type[...]]; [...]; }; [ 표 4-10] update-policy 문 여기서 keyname은 dynamic update에서이용할 TSIG 키이름이고, nametype 은

99 name, submain, wildcard, self 형태로나타날수있다. 부가적으로나타날수 있는 type은 A, MX, NS 와같은레코드타입을의미한다. 예를들면, update-key 라는이름의키를이용하면서, 도메인이름과같은 경우만 A 리소스레코드의갱신을허용하고자하는경우 다음과같이설정한다. zone "example.co.kr" IN { }; type "db.example.co.kr"; update-policy { grant update-key name A; }; [ 표 4-11] update-policy 설정예 슬레이브네임서버가주네임서버에게 BIND 9.X의경우슬레이브네임서버가주네임서버에게 Dynamic Update 를전달하도록하려면? dynamic update를 전달할수있다. 이를위해서슬레이브네임서버의 named.conf 파일의 zone 문장에 allow-update-forwarding 문장을추가한다. zone "example.co.kr" IN { type slave; master { ; }; file "bak.example.co.kr"; allow-update-forwarding { localhosts; }; }; [ 표 4-12] allow-update-forwarding 설정예 NOTIFY 메시지를제한하려면? NOTIFY 메시지를제한하는대표적인경우가슬레이브네임서버가동일한 메시지를또보내는것을막고싶을때이다. 원래는주네임서버가 NOTIFY를 보내면이를받은슬레이브네임서버가다른네임서버들에게또 NOTIFY 메시지를보내도록되어있다. 다음은슬레이브네임서버에서 NOTIFY를 보내지않도록설정한예이다

100 zone "example.co.kr" IN { type slave; master { ; }; file "bak.example.co.kr"; notify no; }; [ 표 4-13] 슬레이브네임서버에서 NOTIFY off 또한명시된네임서버들에게만 NOTIFY 를보내도록설정할수있다. 이때에는 notify를 explicit 로설정하고, also-notify 문장에서보낼네임서버들을나열한다. zone "example.co.kr" IN { }; type slave; master { ; }; file "bak.example.co.kr"; notify explicit; also-notify { ; }; [ 표 4-14] 명시된네임서버에게만 NOTIFY 전송예 IXFR 을설정하려면? BIND 9.X의경우 IXFR 이디폴트로설정되어있으므로별도의설정이필요없다. 그러나 BIND 8.X 의경우우선슬레이브네임서버를다음과같이설정하여야한다. server { }; support-ixfr yes; [ 표 4-15] BIND 8.X 슬레이브네임서버에서 IXFR 설정 또한주네임서버에서도 IXFR 요청을받을수있도록다음과같이설정한다. options { }; directory "/var/named"; maintain-ixfr-base yes; [ 표 4-16] BIND 8.X 주네임서버에서 IXFR 설정

101 네임서버가사용이허가된 IP 만질의하게하려면? BIND 는내부와외부에서구분하여사용을제한할수있도록설정할수있다. 주요네트워크로부터질의에대해서만응답할수있도록제한하기위해서 사용한다. named.conf에다음과같이질의를허용할 IP 블록을설정한다. options { }; directory "/dns1" allow-query { ; /24 }; [ 표 4-17] 허가된 IP로만질의하게끔하는 named.conf 설정 설정완료후네임데몬에설정을반영한다. #rndc reconfig [ 표 4-18] 설정을네임데몬에반영 질문자에따라응답을달리하려면? 네임서버가동일한질문을질문자에따라달리응답을하도록하고자하는 경우가있다. 대표적으로망내부호스트에서온질의와망외부에서온 질의를달리처리하고자하는경우가있을수있다. 이때 BIND 9.X의뷰를 이용한다. 이를위해먼저 acl 문장을이용하여질의자들을구분짓고, 두개의 view 문장으로각기다른파일을참조하여응답을하도록설정한다. acl internal { /24; }; view internal { match-client { internal; }; zone "example.co.kr" IN { type master; file "db.example.co.kr.internal"; }; }; view external { match-client { any; }; zone "example.co.kr" IN { type master; file "db.example.co.kr.external"; }; }; [ 표 4-19] 뷰(View) 설정예

102 시리얼넘버를조정하려면? 거대도메인을관리하는매니저들의실수중하나는잦은업데이트작업으로인한 잘못된 Serial 넘버링이다. DNS 시리얼넘버는 32비트의부호없는정수범위로 설정가능하다. 일반적으로 로날짜와그날업데이트한횟수로표기한다. 하지만 과같이실수로삽입된 '0' 은해당필드를오버플로우 시킨다. 따라서 Secondary의 Zone 은장기간업데이트되지않을수있다. 다음과같이문제를해결할수있다. o Secondary 를직접관리한다면, 먼저 Primary Zone의 Serial을정상적으로 조정한다. Secondary에저장되어있는 Zone 파일(Zone Transfer 된) 을 삭제한후 BIND 를재구동한다. o BIND 4.8.1보다최신이면서 BIND 9보다는오래된버전이라면시리얼 번호를 0 으로설정하면, 타기관의 Secondary 네임서버에존이전송된다. o BIND 4.9 이후의 DNS 시리얼번호는순차공간산술법(sequence space arithmetic) 을이용하는데이는임의의시리얼번호에대해번호공간내 번호의절반(2,147,483,647 번호들) 이그시리얼번호보다작으며나머지 절반은더크다는의미이다. 예를들어현재영역시리얼번호가 25,000인데번호 1부터다시시작하고 싶다면두단계를거쳐시리얼번호공간을바꿀수있다. 우선가능한 최대의증가치를시리얼번호에더한다.(25,000+2,147,483,647 = 2,147,508,647) 더한결과값이 4,294,976,295(32 비트최대치) 보다크면 그수에서 4,294,967,296 을빼번호공간의처음으로되돌린다. 시리얼 번호를바꾼후에는모든슬레이브가영역의새로운데이터를가져갈 때까지기다려야한다. 그런다음영역시리얼번호를원하는값인 1로 바꾸면현재시리얼번호(2,147,508,647) 보다크다. 슬레이브들이새로운 영역데이터를가져간후에는원하는일이끝난것이다

103 BIND 버전별기능호환조건들은어떻게되나요? 버전별기능호환은아래와같다. ( 자세한사항은 DNS&BIND 참고) 기능 BIND 버전 다중프로세서지원 동적업데이트 (Dynamic Update) 재귀(recursive) 기능비활성화 재귀(recursive) 액세스리스트 NOTIFY IXFR 영역전송 TSIG서명된동적업데이트 TSIG기반업데이트정책 뷰 (VIEW) 라운드로빈 (Round Robin) 포워딩 (Forwarding) 포워드영역 (Forward zone) 포워더에대해 RTT이용 설정가능한 RRset 순서 설정가능한 Sort list SIG,KEY,NXT RR들로딩 DNSSEC 지원 Trust chain 확인 안전영역의동적업데이트 AAAA 레코드 A6 레코드 IPv6 지원 DNAME 레코드 비트문자열레이블 DNAME과 A6 체인따름 질의 Access list [ 표 4-20] BIND 버전별기능호환조건표 TSIG 를통해동적업데이트또는존전송을사용할때 TSIG 설정을정확히 했음에도해당서버에서 TSIG 를 reject 할경우? 이경우 client와 server 간의시간차이가발생했을확률이높다. 두시스템간의 시간동기화(ex, ntp 프로토콜이용) 를시킨후, 재전송하기를권장한다. BIND 버전별취약점정보는어디서볼수있나? BIND 버전별 취약점정보는 를 방문하면자세히볼수있다. BIND 버전별취약점공격을예방하기위해서는 이미앞서말한바와같이 namd.conf 파일의 options 부분을이용하여 BIND 버전정보를숨기는방법이있고, 또한가지방법은최신의 BIND 버전으로 업그레이드하는것이다

104 4.2 네임서버관련 Q&A 자주가던홈페이지접속이안될경우? 자주가던홈페이지에접속이안될경우우선기본적인사항들부터점검을 해본다. 네트워크회선을체크하고, DHCP(Dynamic Host Configuration Protocol) 가아닐경우설정된로컬(local) 네임서버정보및설정상태를확인 한다. 로컬네임서버의상태확인결과이상이없으면해당도메인이현재운영 중인지를점검한다. 도메인의운영정보는 을참조한다. 도메인이운영중인데도접속이안될경우해당서버가장애일가능성이높다. 네임서버설정상태확인하는방법은? 해당도메인이사용하고있는네임서버가제대로동작하는지를점검하기 위해서 dig나 nslookup 같은툴(tool) 을사용할수있다. 그러나더편하게점검하고 싶다면진흥원에서제공하는네임서버점검웹페이지 ( ) 를 이용하기를권장한다. 도메인입력란에해당도메인만입력하여실행시키면, 간단히도메인의네임서버상태점검할수있다. Lame Delegation 은무엇인가? Lame delegation이란 Namespace 상에서깨어진링크(Link) 를말한다. example.co.kr. IN NS ns1.example.co.kr. IN NS ns2.example.co.kr. [ 표 4-21] Lame Delegation 예 예를들어 example.co.kr 이위와같이두개의네임서버를갖지만, 두서버중 하나혹은모두가해당도메인에대한 Authority 를갖지않는경우, 즉 Primary, Secondary 설정이안되어있을경우가 Lame delegation 에해당된다. 네임서버선택은어떻게이루어지는가? 네임서버간에질의, 응답에소요되는시간을 Round Trip Time 이라한다. (Recursive 모드에서총검색시간이아니다) BIND는내부적으로타네임서버에 대한 RTT 값을기록하고있다가, 요청도메인에대한다수의 Authority NS 중 RTT 값이가장낮은네임서버로먼저질의한다. Authority NS들에대한 RTT 정보를갖고있지않을경우엔, 해당네임서버전체에질의( 동시에) 를보내어

105 빠른응답을얻음과함께부가적으로 해당도메인에대한요청이 RTT 를측정한다. RTT가측정된다음부터는 RTT가가장적은서버로먼저보내어진다. 또한, 몇몇서버만이계속사용되는문제를막기위해질의를전송할때마다해당 네임서버에대한 RTT 값을조금씩증가시킨다. 이와관련하여, 해당도메인사용자가자신의네임서버를 1 차(Master), 2차 (Slave) 형태로운영할경우외부질의는 1차네임서버에질의를요청한후 응답이없으면 2차네임서버로질의요청을하는것이아니라미리기록된 RTT 값을참고하여응답이빠른서버쪽으로질의를요청하게된다. 네임서버는반드시복수개로운영해야하는가? 하나의네임서버로영역을담당하는것도가능하지만안정성을이유로둘이상의네임서버를운영하는것이권고되고있다. 그중하나는주네임서버로, 나머지는슬레이브서버로설정하는것이일반적이다. 네임서버에새로운호스트를추가하려면? 새로운호스트가들어오면영역파일에 A 리소스레코드와 PTR 리소스레코드가 추가되어야한다. A 리소스레코드는 db.nida.or.kr 파일에추가되어야하고, PTR 리소스레코드는 in-addr.arpa 파일에추가되어야한다. newhost.example.co.kr. IN A [ 표 4-22] db.example.co.kr에새로운 A 레코드추가부분 in-addr.arpa IN PTR newhost.example.co.kr. [ 표 4-23] in-addr.arpa에새로운 PTR 레코드추가부분 네임서버에기존호스트의이름 ( 별명 ) 을추가하려면? 이미등록되어있는호스트에게새로운이름( 별명) 을부여할경우가있을수 있다. 예를들면, 이미운영되고있는웹서버를새로 ftp 서버로도동작하게 하는경우 보다는 ftp.nida.or.kr 이라는이름이더적합할 것이다. 이런경우 CNAME 리소스레코드를이용한다. ftp.example.co.kr. IN CNAME ns1.example.co.kr. [ 표 4-24] db.example.co.kr에새로운 CNAME 레코드추가부분

106 네임서버에메일호스트를추가하려면? 일반호스트와는달리메일호스트는따로 MX 리소스레코드를이용하여 추가한다. 다음과같이 MX 리소스레코드를추가하는경우 로 보내는메일을 mail.nida.or.kr 서버가받아처리할수있다. MX 리소스레코드에는 preference 필드가있는데, 여기에는 0부터 65535까지의정수값을설정할 수있다. 이값자체가중요한것은아니고, 메일서버가여러개존재할때 어떤메일서버를우선적으로이용할것인지를나타낸다. 높은우선순위를갖는다. 값이낮은것이더 example.co.kr. IN MX 0 mail.example.co.kr. example.co.kr. IN MX 10 smtp.example.co.kr. [ 표 4-25] db.nida.or.kr에 MX 레코드추가부분 www 없이도메인이름으로바로웹서버에연결되도록하려면? 일반적으로 이라고입력하여웹서버에접속하지만, 단지 도메인이름 nida.or.kr 만입력해도웹서버에접속하도록할수도있다. 이렇게 하고자하면 A 리소스레코드의첫필드에호스트이름이아닌영역이름을 입력하고웹서버의 IP 주소를입력하면가능하다. 웹서버가여러개존재하면 그만큼의 A 리소스레코드를더설정하면된다. example.co.kr. IN A example.co.kr. IN A [ 표 4-26] 영역이름으로바로웹서버에접속하도록 A 추가 복수개의웹서버 (web server) 로부하를분산하려면? 복수개의웹서버를운영하면서전체부하를분산하고자하는경우가있을 수있다. 이때영역파일에같은이름을갖는 A 리소스레코드를복수개 설정하면라운드- 로빈(Round-Robin) 방식으로서비스를제공하게된다. 다음예는 3 개의웹서버가하나의영역을담당하는경우를보여준다

107 IN A IN A IN A [ 표 4-27] 라운드-로빈방식으로부하분산 멀티홈호스트를등록하려면? 두개의인터페이스를가져서두개의망에속한호스트를멀티홈 (Multihomed) 호스트라고한다. 대부분이런호스트는라우팅이나파이어월기능을하는 경우가많다. 이런호스트를등록하고자하면영역파일에두개의 A 리소스 레코드를추가하고, 각각의리버스영역파일에 PTR 리소스레코드를추가하면된다. abc.example.co.kr. IN A abc.example.co.kr. IN A [ 표 4-28] db.nida.or.kr 에멀티홈호스트추가부분 in-addr.arpa. IN PTR abc.example.co.kr. [ 표 4-29] in-addr.arpa에멀티홈호스트추가부분 in-addr.arpa. IN PTR abc.example.co.kr. [ 표 4-30] in-addr.arpa에멀티홈호스트추가부분 호스트의주소를변경하고자하면? 호스트의주소를바꾸고자할때바로영역파일을변경하는것은문제가 발생할수있다. 일반적으로네임서버에서는질의의응답으로받은정보를 캐시에보관하는데이때의유효시간이 TTL 값이다. 따라서먼저, 일반적으로 하루정도로설정되어있는해당 A 리소스레코드와 PTR 리소스레코드의 TTL 값을 60 초와같은낮은값으로먼저변경하고, 충분한시간이흐른후 변경작업을수행하고, 그다음 TTL 값을높여주는것이좋다. 네임서버 TTL, SOA 레코드값은어느정도가적당한가? 네임서버존의 TTL값과 SOA 레코드의 Refresh, Retry, Expire 시간값들은 초(second) 단위로설정되어있다. 그러나이런값들은특정값으로정의되어 있지않고, 네임서버관리자가자신의사이트에맞게적절히설정하는사용 하고있다. 이와관련하여, NIDA에서는네임서버담당자가초기에각필드값

108 설정시어느정도도움이되도록각필드값들에대해아래와같이정의하니설정시참고하기바란다. 아래의설정은권장사항으로각사이트의상황에따라적절히수정하여사용할수있다. $TTL ; 1 일 example.co.kr. IN SOA ns1.example.co.kr. root.example.co.kr. ( ; 시리얼번호 ; 3 시간후리플래시 3600 ; 1 시간후재시도 ; 1 주일후만료 3600 ) ; 1 시간의부정적캐싱 TTL [ 표 4-31] TTL 및 SOA 레코드필드값설정예 호스트의위치를 DNS 에저장하고자하면? 영역파일내에호스트의위치를저장하고자할때이용할수있는리소스 레코드는 TXT와 LOC 이다. 이중 TXT 리소스레코드는호스트의위치를 포함한어떠한설명도포함할수있는레코드이고, LOC 리소스레코드의경우 위도와경도로만위치를표현한다. DNS 운영초창기에는 DNS에호스트의 위치, 관리자, 기능등다양한정보를담는것이추세였지만, 보안등의이유로 제공하는정보를제한하는것이현재의추세이다. Linux Kernel 2.2.x 버전에서 --enable-threads 옵션으로 BIND 9 을 build 한후 "-u" 옵션이적용되지않는이유? Kernel 2.2.x 버전의 Linux threads는완전히 POSIX threads(pthreads) 표준을 지원하지않는다. 특히, setuid() 함수는전체 process가아닌오직현재의 thread 에한에서만동작한다. 이러한제한때문에, Linux 기반의 BIND 9은 setuid() 함수를다른지원되는 OS 플랫폼처럼사용할수없다. Linux Kernel or pre3 에서는이기능을제공하고있다. 참고로, POSIX(Portable Operating System Interface for Computer Environment) 는유닉스운영체계에기반을두고있는일련의표준운영체계 인터페이스이다. Linux 에서는 named 프로세서가 5 개이상보이는경우가있다. Linux 에서 named를실행시키고 ps 명령을수행할경우, named가여러개 보이는것을목격할수있다. named thread 개수는대략 n+4 개정도이고, 여기서 n은 CPU 개수이다. 유념할사항은전체메모리사용량은각

109 process 별로누적되는것이아니다. 각각의 process는 10MB 정도의 메모리를사용하고있다면, 전체 total 메모리소비량역시 10MB 이다. 상위버전의 Linux 에서는 ps 명령을수행하면개별적인 threads들을보여주지 않는다. 이경우전체 named process들을보기위해서는 -L 옵션을사용 해야한다. Linux 에서다음과같은 Error 메시지가나오는이유? Linux Kernel 버그로해당커널패치또는업그레이드를해야한다. errors message : general: errno2result.c:109: unexpected error: general: unable to convert errno to isc_result: 14: Bad address client: UDP client handler shutting down due to fatal receive error: unexpected error [ 표 4-32] 리눅스커널에러메시지 윈도우서버에서네임서버선택은어떻게이루어지는가? Wiindows NT4.0 또는 2000 이상에서리졸버알고리즘은다음과같다. 리졸버는 찾을 DNS 서버목록의첫네임서버에게첫질의를전송하고 1 초를기다린다. 응답이없으면질의를재전송하는데이때는자신이이미알고잇는모든네임 서버에게다시보낸다. 만일어떤네임서버도 2초이내에응답하지않으면 리졸버는네임서버모두에게다시질의를재전송한다. 재전송을다시할 때마다시간제한은계속 2 배로늘어나고, 총 4번의재전송을하게되며총 15 초가소요된다. 리졸버가참고하는 DNS 목록은제어판의네트워크설정상에 나와있다. [MS기술정보문서 Q 참고]

110 [ 그림 4-6] 사용자네트워크설정예 DNS 에서는별도의보안솔루션을제공하는가? DNS의확장으로서제공되는 DNSSEC(DNS Security Extensions) 기능은 DNS 메시지에공개키기반의전자서명기능을제공하여 DNS 데이터에대한 응답이신뢰할수있는가에관한인증메커니즘을제공한다. DNSSEC은보안 기능제공을원하는최상단의네임서버부터사용자의리졸버까지완벽하게 구현되어야하며, 및시범적용을통하여단계적으로 이에따른고려사항및안전한적용을위하여충분한시험 kr 도메인에적용할예정이다. DNS 서비스만을위한방화벽정책은? 네임서버는다른용도로사용하지않고방화벽에서네임서비스에필요한포트 (Port) 만개방함에따라캐시오염(Cache Poisoning) 등의침해의가능성을 줄일 수있다. 이에따라 DNS 만을위한별도의네트워크를구축하고 DNS 서비스에 필요한포트만개방함으로써보다안전하게 DNS 서버를관리할수있다. DNS 서비스에필요한포트는일반적인질의의경우 UDP 53과 1024 ~ 의포트를사용하며, UDP의메시지가 512Byte 초과시또는 Transfer 시에는 TCP 로질의할수있다. Zone