DNS와 GSLB
경희대학교 KHLUG
7기 이준형
네트워크상의 모든 컴퓨터들은 IP주소를 갖고 있는데 이것은 모든 컴퓨터들을 각각 고유한 식별 값으로 분리해내기 위한 것으로 주소로, 네이버는 222.122.84.200 , 구글은 209.85.171.99 등과 같이 서로가 중복되지 않게 서버 또는 컴퓨터마다 고유하게 1개 또는 다수의 IP주소를 갖고 있다.
(현재 가장 많이 활용되고 있는 IP주소는 IPv4 방식으로 32비트를 8비트 단위로 구분하여 “.” 과 함께 이루어진 주소체계이다)
우리는 가령 네이버나 구글 같은 홈페이지에 접속하기 위하여 브라우저 창에 네이버의 도메인 주소인 www.naver.com 대신에 222.122.84.200 를 입력하거나 구글의 도메인 주소인 www.google.com 대신에 209.85.171.99 를 입력하여 접속하진 않는다. 이는 사람이 인식하고 외우기 어려운 IP주소대신에 사람이 외우고 사용하기 쉬운 도메인을 이용하여 문자(영어, 근래엔 각국의 언어도 포함)를 통하여 입력하면 특정 서버가 호스트의 IP값을 자동적으로 찾아내어 IP를 직접 알지못해도 접속이 가능하다.
이러한 역할을 담당하는 것이 DNS(Domain Name Server)로 지금부터 DNS의 동작 원리 및 동작방법을 알아보고, BIND(Berkeley Internet Name Domain)를 통해 이를 직접구성할 것이다. 또한 최근 대두되고 있는 CDN(Content Delivery Network)의 가장 핵심이 된다고 볼수있는 GSLB(Global Server Load Balance)를 BIND의 View를 통하여 간략하게 직접 구성해 보고자 한다.
도메인 주소 체계는 우리가 자주 사용하는 Linux 나 Unix 의 파일 시스템의 트리구조와 비슷하다고 볼 수 있다.
가장 최상위의 "." 인 루트도메인을 중심으로 .com .net .org .co.kr .kr 등의 1단계, .co .or .pe 등의 2단계, naver , google 같은 3단계, www , ftp 같은 4단계로 구성이 된다.
1단계는 gTLD(Greneric Top Level Domain) 또는 nTLD(National Top Level Domain) 으로 국가코드나 전세계 범용적으로 등록하는 도메인등이 해당되며, 2단계는 조직의 성격에 따라 구분짓는 도메인이며, 3단계는 사용하고자 하는 이름을 나타내며, 4단계는 서비스 성격에 따라 구분짓는 호스트명이다.
(gTLD는 위에 설명된 2단계 대신에 3단계가 바로 나온며, 4단계의 성격이 없다.)
도메인을 읽는 과정은 위와 같이 4단계부터 1단계로 거꾸로 표기해나가며, 예를들어 한국의 대학중 경희대학교의 리눅스동아리의 도메인은 khlug.khu.ac.kr 와 같이 표기한다.
그렇다면 이제 khlug.khu.ac.kr 이라는 도메인의 IP주소를 찾기 위하여 어떠한 과정을 거치는지 알아보자.
우선 khlug.khu.ac.kr를 찾기 위하여 “.” 도메인의 네임서버를 찾아가게 된다. “.” 네임서버는 Root Name Server 라고 불리는 서버로, 전 세계 대륙에 Mirror 서버형태로 퍼져있는 서버로 gTLD, nTLD 도메인의 값을 가지고 있다.
이후 .kr 도메인의 네임서버, .ac 도메인의 네임서버를 거쳐 .khu.ac.kr 도메인의 네임서버를 찾아간다. 이때, .khu.ac.kr 의 네임서버는 도메인을 등록할 때 네임서버를 지정하게 되는데, 이곳의 주소로 찾아가게 되며, 이곳에서 마지막 khlug.khu.ac.kr 이라는 호스트의 IP주소를 받아오게 되어 요청 자에게 그 주소 값을 알려주게 된다. 이것이 도메인의 네임서버로의 DNS의 역할이다.
그렇다면 흔히 우리가 PC에 DNS주소를 IP주소 형태로 입력하는데 이는 무었일까? 초기에 도메인의 값들이 많지 않았을 때에는 PC상의 “hosts” 파일을 직접 호스트주소와 IP주소를 입력하여 사용하였다. (ex. 리눅스 : /etc/hosts , 윈도우 : C:\Windows\System32\drivers\
etc\hosts ) 하지만 이러한 도메인들이 양이 점차 늘어나게 되면서 수만 개 수억 개의 도메인의 값을 매번 일일이 변경, 추가, 삭제 할수없게 되어 이를 도메인 네임서버에게 질의를 하고 그 값을 받아오는 서버를 두게 되었는데 이것이 DNS 캐싱서버이다.
캐싱서버는 클라이언트가 도메인의 값을 질의를 하면 이를 자신의 캐시에서 먼저 찾아보고 없으면 그림3 의 방법으로 각 도메인의 네임서버로 찾아가 그 값을 자신의 캐시에 저장 및 클라이언트에게 그 값을 전달해 주는 역할을 한다. 이러한 DNS 캐시서버는 보통 자신이 사용하는 ISP(Internet Service Provider)의 캐싱서버를 주로 사용하는데 이는 각 PC가 직접 도메인의 네임서버에 질의를 한다면, 수많은 컴퓨터들이 도메인의 값을 찾기 위해 도메인의 네임서버에 질의를 한다면 각 도메인의 네임서버에는 엄청한 부하가 걸려 하루에도 몇 차례나 계속해서 다운이 될 것이다. 따라서 이를 방지하기 위한 중간 저장 서버라 볼 수 있다. (DNS의 경우 53번 UDP 프로토컬을 사용, 질의에 대한 거부가 없기 때문에 다수의 PC가 질의를 할 경우 엄청난 DDOS(Distribute Denial of Service attack) 공격으로 변할 것이다.)
그럼 이제 BIND를 통해 실제 서버를 구성하여 보자.
사용할 OS는 Centos 5.2 버전으로, BIND 9.3.4-6 버전이 패키지화 되어있다. (현재 ISC에서 배포하는 BIND 최신버젼은 9.5.0 이다.) 물론 http://www.isc.org 에서 직접 소스를 다운받아 설치도 가능하다.
#yum install bind
#yum install caching-nameserver
Centos(또는 레드햇 계열의 배포판) 에서는 이렇게 간단히 두줄이면, YUM(Yellow dog Updater, Modified)을 통하여 손쉽게 설치가 가능하다.
(*참고 : 현재 BIND는 9버젼 부터 원격 루트 익스플로잇 으로부터 초래되는 문제를 최소화하기 위하여 chroot 환경에서 운영되고 있으며, 본 문서또한 BIND 9 버전에 맞춘 세팅내용을 기술 하도록 하겠다.)
이제 각 세팅파일을 살펴 보도록 하자.
/etc/named.caching-nameserver.conf
/etc/named.rfc1912.zones
named.caching-nameserver.conf 에는 BIND 에 관한 전반적인 설정을 담고 있으며, named.rfc1912.zones 에는 각 도메인들의 대한 ZONE 파일등을 설정을 할 수 있는 내용을 담고 있음을 알 수 있다.
named.caching-nameserver.conf
#####################################################################
//
// named.caching-nameserver.conf
//
// Provided by Red Hat caching-nameserver package to configure the
// ISC BIND named(8) DNS server as a caching only nameserver
// (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
// DO NOT EDIT THIS FILE - use system-config-bind or an editor
// to create named.conf - edits to this file will be lost on
// caching-nameserver package upgrade.
//
acl "autharea" {
163.180.0.0/16;
163.180.114.72/32;
};
options {
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
allow-transfer { autharea; };
allow-recursion { autharea; };
version "KHLUG Name Server";
};
view localhost_resolver {
include "/etc/named.rfc1912.zones";
};
#####################################################################
위 설정은 가장 중요한 부분만 설정을 한 것으로 autharea 를 지정하여, 지정한 Network 대역 에서만 zone 파일과 recursive 응답이 가능하도록 한 것이며, BIND Version 정보를 숨기기 위하여 텍스트를 입력해 둔 것이다.
named.rfc1912.zones
#####################################################################
//
// named.rfc1912.zones:
//
// Provided by Red Hat caching-nameserver package
//
// ISC BIND named zone configuration for zones recommended by
// RFC 1912 section 4.1 : localhost TLDs and address zones
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
zone "." IN {
type hint;
file "named.ca";
};
zone "localdomain" IN {
type master;
file "localdomain.zone";
allow-update { none; };
};
************중간 생략************
zone "0.in-addr.arpa" IN {
type master;
file "named.zero";
allow-update { none; };
};
zone "khlug.org" IN {
type master;
file "khlug.org-zone";
allow-update { 163.180.114.72; };
};
#####################################################################
위 설정은 khlug.org 를 master 1차 네임서버로 각종 레코드 값들을 khlug.org-zone 파일에 저장하여 2차 네임서버 163.180.114.72 로 zone 설정들을 전송이 가능하도록 세팅을 한 것이다. 추가적으로 3차, 4차 다수의 네임서버를 구성시에 allow-update 에 계속해서 써주면 된다. 또한 추가적인 부분은 1차 외에 모든 네임서버에서는 type 을 master 가 아닌 slave 로 지정하고 allow-update 대신에 masters { 163.180.114.71; }; 이렇게 지정하여 사용하면 된다.
이렇게 간단하게 네임서버를 구성함으로 모든 준비는 끝났고, 이제 zone 파일을 작성하면 된다. 폴더는 /var/named/chroot/var/named 폴더에서 작성하면 된다.
khlug.org-zone
#####################################################################
$TTL 86400
@ IN SOA ns1.khlug.org. webmaster.khlug.org. (
2008101101
10800
900
604800
86400 )
;
IN NS ns1.khlug.org.
IN NS ns2.khlug.org.
IN MX 10 mail.khlug.org.
khlug.org. IN TXT "v=spf1 ip4:163.180.114.71 -all"
ns1 IN A 163.180.114.71
ns2 IN A 163.180.114.72
mail IN A 163.180.114.71
www IN A 163.180.114.71
ftp IN A 163.180.114.71
#####################################################################
맨 위부터 설정을 간략하게 살펴보도록 하자.
$TTL 86400 ☞ 캐싱 서버가 도메인의 값을 갖고 있을 동안의 시간
@ IN SOA ns1.khlug.org. webmaster.khlug.org. ( ☞ 네임서버명, 관리자 메일주소
2008101101 ☞ Serial
10800 ☞ refresh
900 ☞ retry
604800 ☞ expire
86400 ) ☞ minimum
IN NS ns1.khlug.org. ☞ 네임서버 정보
khlug.org. IN TXT "v=spf1 ip4:1.1.1.1 -all" ☞ SPF레코드 (http://www.kisarbl.or.kr참고)
www IN A 163.180.114.71 ☞ www 에대한 IP주소
DNS의 레코드 유형에는 위에 간략하게 나온 설정과 그 외에 SOA, NS, A, PTR, CNAME, MX, TXT, RP등의 있다.
SOA(Start of Authority) 는 위에 나온 네임서버명(FQDN), 관리자 메일 주소 와 시리얼 등이 적혀있다. Serial 은 도메인의 정보가 갱신되었을 때 마지막 값에 +1을 하여 변경된 내용이 다른 네임서버에 전송이 되도록 고유한 값을 저장하는 것이며, 보통 YYYYMMDDxx 같은 날짜형식으로 작성하여, 하루에 많게 99번까지(?) 변경하여도 그 내용이 저장되게 만드는 것이 좋다. 또한 refresh 는 2차 네임서버가 1차 네임서버에게 레코드의 변경여부를 얼마나 자주 확인할 지에 대한 내용을 저장하는 것이며, retry 는 2차 네임서버가 변경 여부를 검사하기 위하여 1차 네임서버에게 접속할 때에 연결 장애 발생 시에 일정 시간만큼 이후 다시 시도할 시간을 작성하는 것이다. expire 는 2차 네임서버에서 가용하는데, 1차 네임서버와 연결을 할 수 없을 때 일정 시간만큼 지난이후 캐싱 데이터의 파기 시간을 지정한다. 또한 마지막 minimum은 1차 네임서버와 연결이 불가능할 때 얼마 이후 데이터를 파기할 지에 대하여 작성한다. 이 정보는 각 도메인 운영 정책에 맞게 작성하면 될 것이다.
NS(Name Server)는 어떤 네임서버들이 이 도메인에 대하여 관리하고 있는지를 지정하는 것이다.
A(Address Record)는 호스트의 이름을 IP주소로 대응시키기 위하여 사용한다.
PTR(Pointer Record)는 역방향 풀이를 위한 것으로, IP주소를 호스트에 매핑하기 위한 것인데 본 문서에서는 Resolve 도메인에 관하여서는 생략한다.
MX(Mail Exchanger)는 본 도메인에 대한 메일서버를 지정하는데, 메일서버에대하여 가중치로 숫자를 지정하는데, 예를 들어 khlug.org. IN MX 10 163.180.114.71 이렇게 지정을 한다. 이는 메일서버가 장애 시에 가중치가 가장 작은 메일서버부터 하나씩 가중치가 높은 서버로 변경해 가면서 전송을 하기 위한 것으로, 이 부분은 또다시 메일서버에서 가중치 별로 전송처리 방식을 세팅을 해주어야 한다.
TXT는 관련된 정보나 SPF레코드 등을 작성하기 위한 것이다.
이제 모든 작성이 끝났으면, BIND 서버를 시작해 보도록 하자
#service named start (또는 /etc/rc.d/init.d/named start)
도메인의 세팅이 잘 되었는지 알아보기 위해서 dig 나 nslookup 등으로 설정을 확인해 보면 된다. (이때 주의할 점은 named.caching-nameserver.conf 에서 지정한 allow-recursion 에 지정한 Network 대역에서만 정상적으로 설정된 데이터를 체크할 수 있다는 점을 꼭 기억하여 체크하는 것이 좋다.)
DNS에 관련된 기초적인 내용은 마무리 되었고 이제는 GSLB 에 대하여 알아보자.
위 그림은 GSLB 솔루션으로 구성된 환경에서 Client가 Europe에서 www.work.com 이라는 홈페이지에 접속하는 과정을 나타는 그림이다. Client 는 Local DNS 캐싱 서버에 DNS를 질의하면 도메인의 네임서버는 그 사용자의 Client 위치를 체크하여 United States 에 있는 www.work.com 이 아닌, Client로부터 가장 가까운 Europe 의 www.work.com 에 접속을 유도하게 된다. 이렇게 GSLB는 대륙이나 ISP에 따라 가장 빠른 방법으로 최소한의 라우터만을 거쳐 원하는 정보에 접속이 가능하도록 하는 방법이다.
일반적으로 GSLB 는 L4 같은 고가의 장비로 구성하여 사용하는데 Cisco의 4492R 나 F5의 3DNS 장비 등이 있다. 하지만 상상이상의 엄청난 고가의 장비이고 실제로도 몇 안 되는 포털 사이트에서 사용할 정도의 장비이기 때문에 본 문서에서 저런 장비를 직접 구성하여 GSLB를 구연하는것은 다소 무리가 있다. 따라서 본 문서에서는 서두에서 밝혔듯 BIND의 View를 이용하여 GSLB를 구성할 것이다.
실제로 지금부터 구성해볼 GSLB는 MaxMind의 GeoIP Country Database 를 이용하여 C Api를 이용하여 BIND를 패치하고 각 나라별 BIND View를 만들어 접속하게 하는 방법이다.
우선 ISC 홈페이지에서 BIND 소스코드를 다운받은 후 http://www.maxmind.com/app/c 에 공개되어있는 C Api를 다운 및 컴파일 이후 BIND 소스에 아래 패치를 적용시킨다.
patch.diff
#####################################################################
diff -ruN bind-9.4.1-P1.orig/lib/dns/acl.c bind-9.4.1-P1/lib/dns/acl.c
--- bind-9.4.1-P1.orig/lib/dns/acl.c Thu Mar 2 01:37:21 2006
+++ bind-9.4.1-P1/lib/dns/acl.c Tue Aug 14 16:56:34 2007
@@ -21,12 +21,15 @@
#include <config.h>
+#include <GeoIP.h>
#include <isc/mem.h>
#include <isc/string.h>
#include <isc/util.h>
#include <dns/acl.h>
+static GeoIP *geoip = NULL;
+
isc_result_t
dns_acl_create(isc_mem_t *mctx, int n, dns_acl_t **target) {
isc_result_t result;
@@ -207,6 +210,27 @@
&e->u.ip_prefix.address,
e->u.ip_prefix.prefixlen))
goto matched;
+ break;
+
+ case dns_aclelementtype_ipcountry:
+ /* We only match V4 addresses */
+ if (reqaddr->family == AF_INET) {
+ /* Country match */
+
+ if (NULL == geoip) {
+ geoip = GeoIP_new(GEOIP_MEMORY_CACHE);
+ }
+ if (NULL != geoip) {
+ const char *value;
+
+ value = GeoIP_country_code_by_addr(geoip,inet_ntoa(reqaddr->type.in));
+ if ((NULL != value) && (2 == strlen(value))) {
+ if ((e->u.country[0] == value[0]) && (e->u.country[1] == value[1])) {
+ goto matched;
+ }
+ }
+ }
+ }
break;
case dns_aclelementtype_keyname:
diff -ruN bind-9.4.1-P1.orig/lib/dns/include/dns/acl.h bind-9.4.1-P1/lib/dns/include/dns/acl.h
--- bind-9.4.1-P1.orig/lib/dns/include/dns/acl.h Thu Mar 2 01:37:21 2006
+++ bind-9.4.1-P1/lib/dns/include/dns/acl.h Tue Aug 14 16:58:28 2007
@@ -47,6 +47,7 @@
typedef enum {
dns_aclelementtype_ipprefix,
+ dns_aclelementtype_ipcountry,
dns_aclelementtype_keyname,
dns_aclelementtype_nestedacl,
dns_aclelementtype_localhost,
@@ -55,6 +56,7 @@
} dns_aclelemettype_t;
typedef struct dns_aclipprefix dns_aclipprefix_t;
+typedef char dns_aclipcountry[3];
struct dns_aclipprefix {
isc_netaddr_t address; /* IP4/IP6 */
@@ -66,6 +68,7 @@
isc_boolean_t negative;
union {
dns_aclipprefix_t ip_prefix;
+ dns_aclipcountry country;
dns_name_t keyname;
dns_acl_t *nestedacl;
} u;
diff -ruN bind-9.4.1-P1.orig/lib/isccfg/aclconf.c bind-9.4.1-P1/lib/isccfg/aclconf.c
--- bind-9.4.1-P1.orig/lib/isccfg/aclconf.c Thu Mar 2 01:37:22 2006
+++ bind-9.4.1-P1/lib/isccfg/aclconf.c Tue Aug 14 16:51:48 2007
@@ -228,6 +228,12 @@
} else if (strcasecmp(name, "none") == 0) {
de->type = dns_aclelementtype_any;
de->negative = ISC_TF(! de->negative);
+ } else if ((0 == (strncmp("country_", name, 8))) && (10 == strlen(name))) {
+ /* It is a country code */
+ de->type = dns_aclelementtype_ipcountry;
+ de->u.country[0] = name[8];
+ de->u.country[1] = name[9];
+ de->u.country[2] = '\0';
} else {
de->type = dns_aclelementtype_nestedacl;
result = convert_named_acl(ce, cctx, lctx,
#####################################################################
#patch -p0 < bind-9.*.*-geodns-patch/patch.diff
#cd bind-9.*.*
#CFLAGS="-I/usr/local/geoip/include" LDFLAGS="-L/usr/local/geoip/lib -lGeoIP" ./configure --prefix=/usr/local/bind
#make
#make install
이제 /etc/named.rfc1912.zones 에 각 국가코드별로 Zone 파일을 지정한다.
#####################################################################
view "Korea" {
match-clients { country_KR; };
recursion no;
zone "khlug.org" {
type master;
file "khlug.org-korea-zone";
};
};
view "USA" {
match-clients { country_US; country_CA; };
recursion no;
zone "khlug.org" {
type master;
file "khlug.org-usa-zone";
};
};
view "other" {
match-clients { any; };
recursion no;
zone "khlug.org" {
type master;
file "khlug.org-other-zone";
};
};
#####################################################################
이후 각 zone 파일을 각 대륙에 있는 서버의 IP로 지정을 하면 한국에서는 한국 쪽 서버로의 접근을 할 것이고, 미국과 캐나다에서는 미국 쪽에 있는 서버로 접근을 하여 불필요 하게 패킷이 태평양 바다를 건너는 일은 없을 것이다.
만약 국내 ISP 별로 BIND View 를 만들고자 한다면 http://ipstat.nida.or.kr 에서 제공하는 데이터를 기반으로 일일이 BIND View 를 만들면 될 것이다. 하지만 엄청난 양의 IP주소를 입력한다는 건 쉽지 않은 일이 될 듯하다. :)
*참고자료
Cricket Liu & Paul Albitz, ≪DNS and BIND≫, O'reilly, 1998, p.84~106.
ISC, ≪BIND 9 Administrator Reference Manual≫, ISC, 2008, p.35
롭 프리켄저, ≪리눅스 서버관리 Hacks 100≫, O'reilly 한빛미디어, 2005, p.303~316.
Steven Graham & Steve Shah, ≪LINUX 관리자 가이드≫, Mc Graw-Hill 사이텍미디어, 2003, p.230~235.
이소문, ≪이소문의 엔터프라이즈 리눅스≫, 대림, 2007, p.782~787.
Nico, 〈GeoDNS BIND patch〉, http://www.caraytech.com/geodns, 2008년 11월 3일
Cisco,〈Configuring the CSS as a Domain Name System Server〉,
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/css11500series/v7.30/configuration/gslb/guide/DNS.html, 2008년 11월 3일
출처 : http://blog.naver.com/kubby72
댓글