DNS서버보안 2편 : DNS 보안 정책 실무편1

일반적으로 master, slave라는 용어뿐만이 아니라 primary, secondary 또는 1차, 2차라는 용어가 혼재되어 사용되고 있다.

물론 비슷한 의미의 용어이지만 primary, secondary 또는 1차, 2차라는 용어가 DNS의 작동 방식에 대해 다소의 오해를 유발할 수 있기 때문에 필자는 가급적 master, slave라는 용어를 사용할 것이다.

우리가 도메인을 등록할 때 보면 1차와 2차 네임서버를 각각 지정하도록 되어 있는데, 1차, 2차라는 용어 때문인지 흔히들 1차가 DNS 서비스를 제공하다가 만약 1차가 다운되면 2차가 대신 응답하는 것으로 알고 있다.

그러나 이는 잘못 알고 있는 것으로, 실제로 1차와 2차는 동시에 질의를 받아 처리하고 있다.

즉, 동일한 권한으로 질의를 받고 응답한다는 것이다.

단지 1차에는 위임 도메인에 대한 설정이 직접 정의되어 있고, 2차에는 1차의 정보를 zone transfer로 전송받아 저장하는 것 뿐 인데, 이 때문에 오해의 소지가 있는 1차, 2차 보다는 master, slave라는 용어가 더 정확하다는 것이다.

즉, master와 slave는 단지 서버가 어디에서 데이터를 얻어오는가에 따른 분류일 뿐인데, 단지 slave 는 자기 자신이 독자적으로 DNS를 설정할 수 있는 권한은 없고 단지 master에서 지정한 설정대로만 따라간다는 것이다.

실제로 slave DNS로도 동등하게 질의가 들어오는지 확인해 보려면, 2차 DNS 서버에서 tcpdump port 53을 실행해 보거나

# dig @ns.dacom.co.kr server.com +trace 와 같이 반복적으로 질의해 보기 바란다.

같은 도메인이라도 질의할 때마다 경로가 달라지는 것을 알 수 있을 것이다.

첫 번째 질의)

두 번째 질의)

위는 첫 번째와 두 번째 질의했을 때의 결과인데, 첫 번째는

c.root-servers.net -> E.DNS.kr. -> ns2.ttpia.com.를 통해 질의하지만 아래의 경우

g.root-servers.net -> F.DNS.kr. -> ns1.tt.co.kr.로 질의하는 것을 알 수 있다.

이와 관련하여 추가적으로 최상위 root 네임서버를 생각해 보자. A.root-servers.net는 master이고, B부터 M.root-servers.net는 slave인데, 기존 상식대로라면 B부터 M.root-servers.net는 평소에는 질의가 없다가 A.root-servers.net이 다운되었을 때만 작동하게 될 것이다.

그러나 질의해 보면 그렇지 않다는 것을 알 수 있으며 이를테면 아래 사이트에 접속해 보면 k.root-servers.net의 경우 질의와 응답이 계속적으로 발생하고 있다는 것을 알 수 있다.

http://k.root-servers.org/

[그림] k.root-servers.net이 받는 질의 수

그리고, .kr 도메인의 경우 한국인터넷진흥원(구 KRNIC)에서 master(G) 1대, KT,dacom, 하나로,KISTI등 4개 기관에서 slave 5대로 총 6대([b-g].dns.kr)가 운영되고 있는데, 각각의 서버는 초당 평균 800-1000번의 질의를 처리하는 것으로 알려져 있다.

.kr이 언급된 김에 재미있는(?) 문제를 하나 풀어보자. dig이나 nslookup등 여러 질의를 이용해 실제 .kr을 관리하는 한국인터넷진흥원의 DNS에는 도메인설정이 어떻게 설정이 되어 있는지 알 수 있을까? 물론 가능하다.

필자는 물론 직접 본 적은 없지만 아마도 2단계 도메인은 아래와 같이 설정되어 있을 것으로 추측한다.

co.zone 예)

같은 방법으로 .kr 에 대한 kr.zone 파일을 각자 만들어 보기 바란다.

dig을 이용해 질의를 해 보면 그다지 어렵지 않을 것이다.

[root@dns /root]# nslookup yahoo.co.kr ns.dacom.co.kr

Server: ns.dacom.co.kr

Address: 164.124.101.2

Name: yahoo.co.kr

Address: 211.32.119.151

[root@dns /root]# nslookup yahoo.co.kr. nis.dacom.co.kr

Server: nis.dacom.co.kr

Address: 164.124.101.31

Name: yahoo.co.kr

Served by:

- F.ROOT-SERVERS.NET

192.5.5.241

- G.ROOT-SERVERS.NET

192.112.36.4

- H.ROOT-SERVERS.NET

128.63.2.53

- I.ROOT-SERVERS.NET

192.36.148.17

- J.ROOT-SERVERS.NET

192.58.128.30

- K.ROOT-SERVERS.NET

193.0.14.129

- L.ROOT-SERVERS.NET

198.32.64.12

- M.ROOT-SERVERS.NET

202.12.27.33

여기서 잠깐 "DNS Caching"에 대해 알아보도록 하자.

① Caching에 있는 정보란?

예를 들어 www.yahoo.com에 대한 DNS 질의를 받을 경우 질의를 받은 Local DNS는 질의한 도메인에 대하여 위임 권한이 없으면 자신의 Caching 메모리에 해당 도메인과 관련된 정보가 있는지 여부를 살펴본다고 하였다.

여기에서 Caching은 www.yahoo.com의 IP 주소에 대한 질의를 받았으므로 일차적으로 www.yahoo.com에 대한 A 레코드가 있는지 살펴보고, 없을 경우에는 yahoo.com에 대한 NS 레코드가 Caching에 있는지 살펴보고 만약 있으면 해당 DNS에 직접 www.yahoo.com의 A 레코드를 질의한다.

만약 Caching에 yahoo.com에 대한 NS 레코드가 없을 경우에는 다음으로 .com에 대한 NS 레코드가 있는지 살펴보고, 만약 이도 없으면 최종적으로 root DNS에 질의하게 되는 것이다.

물론 이전에 누군가가 dns.com을 질의하였다면, zone 파일에 지정된 TTL 시간동안 dns.com에 대한 정보뿐만 아니라 .com에 대한 NS 레코드를 Caching에서 기억하고 있으므로 최상위 root DNS까지 올라갈 필요는 없을 것이다.

따라서 거의 대부분은 Caching에서 응답할 수 있으므로 우리가 일반적으로 우려(?)하는 만큼 도메인 질의시마다 매번 root DNS에 질의하는 것은 아니다.

② caching은 어떻게 되는지 실제 확인이 가능할까?

만약 현재 자신이 운영하는 DNS 서버에 어떤 캐시정보가 있는지 확인하려면 다음과 같이

실행하면 된다.

dump된 cache는 /var/named/named_dump.db 파일에 저장되므로 각자 어떤 정보가 캐시되어 있는지 확인해 보기 바란다.

cache된 데이터는 예상할 수 있듯이 root DNS서버에 대한 정보가 가장 먼저 보일 것이다.

또는 다음과 같이 dumpdb대신 querylog를 실행하면 실시간으로 질의되는 도메인에 대한 확인도 가능하다.

# rndc querylog

# tail -f /var/log/messages

Oct 11 20:45:50 mail-14 named[6294]: query logging is now on

Oct 11 20:47:19 mail-14 named[6294]: client 127.0.0.1#49907: query: yahoo.co.kr IN A

Oct 11 20:47:19 mail-14 named[6294]: client 127.0.0.1#49907: query: cinigroup.biz IN A

Oct 11 20:47:19 mail-14 named[6294]: client 127.0.0.1#49907: query: cinigroup.biz IN MX

Oct 11 20:47:19 mail-14 named[6294]: client 127.0.0.1#49907: query: yahoo.co.kr IN MX

Oct 11 20:47:19 mail-14 named[6294]: client 127.0.0.1#49907: query: mail.cinigroup.biz IN A

Oct 11 20:47:31 mail-14 named[6294]: client 127.0.0.1#49907: query: 99.68.47.211.in-addr.arpa IN PTR

Oct 11 20:47:31 mail-14 named[6294]: client 127.0.0.1#49907: query: w-ins.net IN A

Oct 11 20:47:31 mail-14 named[6294]: client 127.0.0.1#49907: query: w-ins.net IN MX

Oct 11 20:49:28 mail-14 named[6294]: query logging is now off  재실행시 Off

③ PC도 DNS를 caching한다?

PC로 Windows 2000이나 XP를 사용한다면 기본적으로 DNS Client Service가 작동하는데, 이러한 경우 Caching 정보가 남게 된다.

이를 위해서 command 창에서 다음과 같이 확인해 보기 바란다.

C:\Documents and Settings\Administrator>ipconfig /displaydns

많은 DNS cache 정보가 저장되어 있는 것을 알 수 있다.

이 cache 정보는 네트워크 환경에서 DNS 정보를 변경하면 초기화되는데, 만약 cache를 초기화하려면 다음과 같이 "ipconfig /flushdns"를 실행하면 된다.

[root@dns /root]# dig @a.root-servers.net. yahoo.co.kr.

;; AUTHORITY SECTION:

kr. 172800 IN NS D.DNS.kr.

kr. 172800 IN NS E.DNS.kr.

kr. 172800 IN NS F.DNS.kr.

kr. 172800 IN NS G.DNS.kr.

kr. 172800 IN NS B.DNS.kr.

kr. 172800 IN NS C.DNS.kr.

;; ADDITIONAL SECTION:

B.DNS.kr. 172800 IN A 61.74.75.1

C.DNS.kr. 172800 IN A 203.248.246.220

D.DNS.kr. 172800 IN A 203.83.159.1

E.DNS.kr. 172800 IN A 202.30.124.100

E.DNS.kr. 172800 IN AAAA 2001:dcc:5::100

F.DNS.kr. 172800 IN A 218.38.181.90

G.DNS.kr. 172800 IN A 202.31.190.1

G.DNS.kr. 172800 IN AAAA 2001:dc5:a::1

[root@dns /root]# dig @g.dns.kr co.kr. ns

;; ANSWER SECTION:

co.kr. 86400 IN NS f.dns.kr.

co.kr. 86400 IN NS g.dns.kr.

co.kr. 86400 IN NS b.dns.kr.

co.kr. 86400 IN NS c.dns.kr.

co.kr. 86400 IN NS d.dns.kr.

co.kr. 86400 IN NS e.dns.kr.

;; ADDITIONAL SECTION:

b.dns.kr. 86400 IN A 61.74.75.1

c.dns.kr. 86400 IN A 203.248.246.220

d.dns.kr. 86400 IN A 203.83.159.1

e.dns.kr. 86400 IN A 202.30.124.100

e.dns.kr. 86400 IN AAAA 2001:dcc:5::100

f.dns.kr. 86400 IN A 218.38.181.90

g.dns.kr. 86400 IN A 202.31.190.1

g.dns.kr. 86400 IN AAAA 2001:dc5:a::1

[root@dns /root]#dig @b.dns.kr. yahoo.co.kr. ns

;; AUTHORITY SECTION:

yahoo.co.kr. 86400 IN NS ns1.yahoo.com.

yahoo.co.kr. 86400 IN NS ns3.yahoo.com.

yahoo.co.kr. 86400 IN NS ns4.yahoo.com.

yahoo.co.kr. 86400 IN NS ns5.yahoo.com.

yahoo.co.kr. 86400 IN NS ns6.yahoo.com.

[root@dns /root]# dig @ns1.yahoo.com. yahoo.co.kr A

;; ANSWER SECTION:

yahoo.co.kr. 300 IN A 211.115.99.172

yahoo.co.kr. 300 IN A 203.212.171.217

[root@dns /root]# dig @ns.dacom.co.kr yahoo.co.kr +trace

; <<>> DiG 9.3.3rc2 <<>> @ns.dacom.co.kr yahoo.co.kr +trace

; (1 server found)

;; global options: printcmd

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

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

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

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

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

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

. 428423 IN NS J.ROOT-SERVERS.NET.

. 428423 IN NS K.ROOT-SERVERS.NET.

. 428423 IN NS L.ROOT-SERVERS.NET.

. 428423 IN NS M.ROOT-SERVERS.NET.

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

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

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

;; Received 500 bytes from 164.124.101.2#53(164.124.101.2) in 5 ms

kr. 172800 IN NS E.DNS.kr.

kr. 172800 IN NS G.DNS.kr.

kr. 172800 IN NS B.DNS.kr.

kr. 172800 IN NS D.DNS.kr.

kr. 172800 IN NS F.DNS.kr.

kr. 172800 IN NS C.DNS.kr.

;; Received 281 bytes from 128.8.10.90#53(D.ROOT-SERVERS.NET) in 312 ms

yahoo.co.kr. 86400 IN NS ns3.yahoo.com.

yahoo.co.kr. 86400 IN NS ns4.yahoo.com.

yahoo.co.kr. 86400 IN NS ns5.yahoo.com.

yahoo.co.kr. 86400 IN NS ns6.yahoo.com.

yahoo.co.kr. 86400 IN NS ns1.yahoo.com.

;; Received 128 bytes from 202.30.124.100#53(E.DNS.kr) in 52 ms

yahoo.co.kr. 300 IN A 203.212.171.217

yahoo.co.kr. 300 IN A 211.115.99.172

yahoo.co.kr. 7200 IN NS ns1.yahoo.com.

yahoo.co.kr. 7200 IN NS ns2.yahoo.com.

yahoo.co.kr. 7200 IN NS ns3.yahoo.com.

yahoo.co.kr. 7200 IN NS ns4.yahoo.com.

yahoo.co.kr. 7200 IN NS ns5.yahoo.com.

yahoo.co.kr. 7200 IN NS ns6.yahoo.com.

;; Received 274 bytes from 217.12.4.104#53(ns3.yahoo.com) in 300 ms

http://www.zonecut.net/dns/ 에 접속해 보면 +trace로 보이는 결과를 아주 흥미로운 그림으로 보여주고 있다.

꼭 접속해서 여러분의 도메인을 검색해 보기 바란다.

# dig @a.root-servers.net . ns

. 518400 IN NS J.ROOT-SERVERS.NET.

. 518400 IN NS K.ROOT-SERVERS.NET.

. 518400 IN NS L.ROOT-SERVERS.NET.

. 518400 IN NS M.ROOT-SERVERS.NET.

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

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

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

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

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

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

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

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

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

# dig @a.root-servers.net com. ns

com. 172800 IN NS H.GTLD-SERVERS.NET.

com. 172800 IN NS I.GTLD-SERVERS.NET.

com. 172800 IN NS J.GTLD-SERVERS.NET.

com. 172800 IN NS K.GTLD-SERVERS.NET.

com. 172800 IN NS L.GTLD-SERVERS.NET.

com. 172800 IN NS M.GTLD-SERVERS.NET.

com. 172800 IN NS A.GTLD-SERVERS.NET.

com. 172800 IN NS B.GTLD-SERVERS.NET.

com. 172800 IN NS C.GTLD-SERVERS.NET.

com. 172800 IN NS D.GTLD-SERVERS.NET.

com. 172800 IN NS E.GTLD-SERVERS.NET.

com. 172800 IN NS F.GTLD-SERVERS.NET.

com. 172800 IN NS G.GTLD-SERVERS.NET.

# dig @a.root-servers.net org. ns

org. 172800 IN NS C0.ORG.AFILIAS-NST.INFO.

org. 172800 IN NS D0.ORG.AFILIAS-NST.org.

org. 172800 IN NS TLD1.ULTRADNS.NET.

org. 172800 IN NS TLD2.ULTRADNS.NET.

org. 172800 IN NS A0.ORG.AFILIAS-NST.INFO.

org. 172800 IN NS B0.ORG.AFILIAS-NST.org.

# dig @a.root-servers.net jp. ns

jp. 172800 IN NS D.DNS.jp.

jp. 172800 IN NS E.DNS.jp.

jp. 172800 IN NS F.DNS.jp.

jp. 172800 IN NS A.DNS.jp.

jp. 172800 IN NS B.DNS.jp.

앞에서, RTT(Round Trip Time)라는 용어가 사용되었는데, 아마 처음 들어보는 관리자도 있을 것이다.

RTT란, DNS 서버 간에 질의, 응답에 소요되는 시간을 뜻한다.

네임서버는 질의하려는 네임서버가 복수 개 있을 때 먼저 해당 DNS 서버에 대한 RTT 값을 알고 있는지 확인하게 된다.

만약 RTT에 대한 데이터가 없을 경우 모든 서버에 질의를 하여 RTT 값을 기록한 후 차후에는 이 값이 가장 낮은 네임서버에게 질의하게 되는데, 한 번 질의를 한 후에는 해당 DNS에 대한 RTT 값을 조금씩 늘림으로써 한 DNS 서버에 질의가 몰리는 것을 방지하게 된다.

결국 primary 등 특정 DNS 서버에 질의가 몰리지 않고 여러 DNS 서버에 골고루 분산되는 것이다.

또한 응답이 없는 DNS는 RTT값을 매우 높여 응답이 없는 DNS로 질의가 가지 않도록 하기도 한다.

options {

directory "/var/named";

allow-recursion {127.0.0.1; 192.168.1.0/24; };

};

acl internal { 127.0.0.1; 192.168.1.0/24; };

options {

directory "/var/named";

allow-recursion {internal; };

};

acl acl-name {

address_match_list

};

options {

allow-recursion {none;};

};

options {

recursion no;

};

[root@dns /root]# dig @ns.test.ac.kr test.ac.kr axfr

; <<>> DiG 9.3.3rc2 <<>> @ns.test.ac.kr test.ac.kr axfr

; (1 server found)

$ORIGIN test.ac.kr.

@ 1H IN SOA ns root.ns (

2007101773 ; serial

6H ; refresh

10M ; retry

1W ; expiry

1H ) ; minimum

1H IN NS ns

1H IN NS ns2

1H IN MX 0 smtp

1H IN MX 10 smtp2

1H IN A xxx.xxx.6.20

ling 1H IN A xxx.xxx.100.22

script 1H IN A xxx.xxx.44.18

mobicomm 1H IN A xxx.xxx.19.212

knuth 1H IN A xxx.xxx.44.14

maynard 1H IN A xxx.xxx.47.79

infosys1 1H IN A xxx.xxx.33.108

lim2 1H IN A xxx.xxx.82.165

...... 이하 중략

options {

allow-transfer { none; };

};

options {

allow-transfer { 192.168.1.10; };

};

zone "server.com" {

type master;

file "server.zone";

allow-transfer { 192.168.1.10; };

};

Dec 9 08:17:22 dns named[241]: unapproved update from [192.168.0.76].4852 for server.com

[root@dns /root]# nslookup www.server.com.

Name: www.server.com

Address: 192.168.3.5

[root@dns /root]# nsupdate

> prereq yxdomain server.com.

> update delete www.server.com.

> update add www.server.com. 86400 IN A 192.168.4.6

> Ctrl+D

[root@dns /root]# nslookup www.server.com.

Name: www.server.com

Address: 192.168.4.6

options {

allow-update { none; }.

};

options {

allow-update { 192.168.10.0/24; }.

};

zone "www.server.com" {

type master;

file "www.server.zone";

allow-update { 192.168.4.0/24; };

};

zone "server.com" {

type master;

file "www.server.zone";

update-policy {

grant allowed-www-updater self www.server.com A;

};

};