제목 : SULINUX를 네임서버로 사용하기 1편
ㅇ 제작 : 리눅스포털(www.superuser.co.kr) 수퍼유저코리아 서버관리팀
ㅇ SULINUX 홈페이지 : www.sulinux.net
ㅇ 리눅스포털 홈페이지 : www.superuser.co.kr
SULINUX를 Name Server로 사용하기
네임서버는 우리가 웹주소(URL)을 웹브라우즈에 입력하고 그 사이트를 찾아갈수 있도록 도와주는 서버를 말한다. 다시 말해 서버의 IP주소와 도메인을 연결시켜주는 색인역할을 한다는 것이다.
네임서버 설정은 아주 복잡하고 이렇게 복잡한 설정을 SULinux의 SSU 유틸리티를 이용하면 간단히 설정할 수 있다. 자세한 사항은 SSU의 “6-3-5. DNS 환경설정”편을 살펴보기 바란다. 이것은 간단한 설정방법이지만 네임서버의 역할을 이해하기 위해 아래 글을 작성하였다. 네임서버의 구성 및 설정을 자세히 알아보도록 하자.
네임서버는 Primary, Secondary, Cache only server로 구분된다.
Primary server는 해당 도메인을 관리하는 주 네임서버이다.
Secondary server는 특정 도메인에 대한 back-up copy를 유지하는 서버이다. Secondary는 Primary가 비정상 운행될 때와 부하를 분산시키기 위해 운용하며, 여러개가 존재할 수 있다.
보통 도메인을 관리하기 위해서는 Primary, Secondary 서버가 필요하게 되며, Secondary는 원칙적으론 외부 네트웍에 위치시켜 정전 등의 사태로 Primary가 다운되었을 때를 대비한다. 따라서, 도메인을 운영하기 위해서는 최소 2대(Primary * 1, Secondary * n) 이상의 네임서버가 요구된다.
(기술적으로 Resolver의 입장에서는 Primary와 Secondary가 구분되지 않기에 Primary 만으로도 운영은 가능하나 권고되진 않는다)
Cache only server는 도메인에 대한 데이터를 관리하지는 않고, resolving만을 처리해 준다. 만약, 본사와 지사가 있고 이 회사의 Primary, Secondary Name server가 모두 본사에 위치한다고 할 때, 지사에 위치한 네트워크 유저들은 Local DNS server가 없게 된다. 이럴 경우 도메인 resolving이 요구될 때마다 다른 네트워크(본사)로 접속을 시도하게 되므로 약간의 딜레이가 생기게 되며, 본사 네트워크가 단절 되었을시 지사도 실질적으로 인터넷 사용이 불가능한 단점이 있다. 이럴 때 지사에 Cache only server를 운용하면 효과적으로 문제를 해결할 수 있다.
1. BIND(Berkeley Internet Name Daemon) 설치
Name server를 운용하기 위해서는 서버측 데몬 프로그램이 필요하게 되는데, 이중 BIND는 db 파일의 구성이 손쉽고 표준을 충실히 따른 검증된 도구로서 인터넷에서 가장 널리 사용된다. 대부분의 Unix 시스템에서는 BIND가 이미 설치되어 있다. /usr/sbin 디렉토리에 in.named 혹은 named가 존재함을 확인하고, BIND가 이미 설치되어 있을 경우에는 다음과 같이 설치된 BIND의 버전을 확인한다. (BIND가 동작중이여야 함)
|
$ dig @ns.nemo.co.kr txt chaos version.bind. | grep version ; <<>> DiG 9.2.4 <<>> @ns.nemo.co.kr txt chaos version.bind. ;version.bind. CH TXT version.bind. 0 CH TXT "9.2.4" |
배포처인 ISC(Internet Software Consortium) 에서 BIND의 최신버젼을 확인하고, 버전 차이가 많거나 현재 버전에 심각한 문내가 보고 되었다면, 업그레이드를 고려해보아야 한다. 하지만 SULinux의 패치팀에서 신속한 패치가 이루어 질것이다. 따라서 yum update 명령을 이용하여 업데이트를 수시로 점검 관리가 필요하다.
BIND의 설치는 매우 간단하다. ISC FTP사이트에서 최신 버전의 소스를 내려받거나 SULinux에서 다운받은 다음, 압축을 푼후 아래과 명령을 입력하는 것이 설치에 필요한 전부이다.
|
[ISC에서 소스다운 받았을 경우] # make clean depend all install
[SULinux을 통한 설치를 원할 경우] # yum install bind* 또는 # yum update |
그리고 시스템 rc.local 스크립트를 적절히 수정하여 시스템 부팅시 BIND가 자동으로 구동될 수 있도록 한다. (/etc/rc.d/init.d/named)
2. 퍼블릭 도메인(Public Domain) 신청
Primary, Secondary 네임서버가 준비되었고 신청할 도메인이 결정되었다면, 상위 도메인 관리 기관(kr 도메인의 경우 KRNIC, com/net/org 등의 도메인은 Network Solutions을 대표로 ICANN의 심사를 획득한 등록 대행 업체들)에 도메인을 신청하여 발급(네임스페이스상에 링크) 받게 된다. 도메인 신청양식은 기관마다 조금씩 상이하지만 일반적으로 사용기관, 책임자, 관리자, 결제자 , 네임서버 정보가 요구된다. 이중 신청 도메인을 네임스페이스에 링크하기 위한 네임서버 정보는 다음과 같이 작성한다.
2. Complete Domain Name...: nemo.co.kr
7a. Primary Server Hostname..: ns.nemo.co.kr
7b. Primary Server Netaddress..: 192.168.1.2
8a. Secondary Server Hostname..: ns2.nemo.co.kr
8b. Secondary Server Netaddress: 192.168.1.3
"nemo.co.kr"이 등록되었다는 메시지를 받았다면, 다음과 같이 해당 도메인의 등록 여부를 확인한다.
$ nslookup -type=ns nemo.co.kr
Server: ns.nemo.co.kr
Address: 0.0.0.0
nemo.co.kr nameserver = ns.nemo.co.kr
nemo.co.kr nameserver = ns2.nemo.co.kr
ns.nemo.co.kr internet address = 192.168.1.2
ns2.nemo.co.kr internet address = 192.168.1.3
해당 도메인에 대한 네임서버가 신청한 것과 같이 표시된다면, 등록이 바르게 진행된 것이다. 아직 등록이 안되었다면, 다음과 같은 메시지를 볼 수 있다.
*** local.name.server can't find nemo.co.kr.: Non-existent host/domain
"도메인 nemo.co.kr을 신청하는데 어떻게 그 하부에 있는 ns.nemo.co.kr, ns2.nemo.co.kr을 사용할수 있습니까?" "ns.nemo.co.kr은 nemo.co.kr 도메인 신청이 완료된 후 네임서버에서 설정 해주어야 사용할 수 있지 않습니까?"라는 의문이 들 수 있는데, 어떤 도메인을 하위 도메인으로 위임하기 위한 네임서버 정보는 상위 도메인에서 관리되기 때문에 가능하다.
3. 인버스 도메인(Inverse Domain) 신청
인버스 도메인은 IP에 대해 해당 도메인을 역으로 찾을 수 있도록 하는 서비스이다. 보통 ISP(Internet Service Provider)에서 IP를 할당받을 때 같이 신청한다. 다음과 같이 인버스 도메인에 대한 네임서버가 in-addr.arpa 네임스페이스에 등록되어 있는지 확인한다.
$ nslookup -type=ns 1.168.192.in-addr.arpa (C Class 192.168.1.x를 할당 받았을 경우)
Server: ns.nemo.co.kr
Address: 0.0.0.0
79.105.210.in-addr.arpa nameserver = ns.nemo.co.kr
79.105.210.in-addr.arpa nameserver = ns2.nemo.co.kr
ns.nemo.co.kr internet address = 192.168.1.2
ns2.nemo.co.kr internet address = 192.168.1.3
만약 다음과 같은 메시지가 나온다면, 인버스 도메인 등록이 안되어 있는 것이므로, 해당 ISP에 신청하여야 한다.
*** ns.nemo.co.kr can't find 79.105.210.in-addr.arpa.: Non-existent host/domain
4. Name Server 설정
네트워크엔 서버가 3대 연결되어 있다. DNS를 구축하기 전에, 그림과 같이 미리 각 서버에 호스트명과 IP를 부여하자. 보통 네임서버는 ns(primary), ns2(secondary)를 호스트명으로 사용하고, IP 1(할프로 받았을 경우엔 129)을 라우터 혹은 스위치, 2를 ns, 3을 ns2에 할당한다. 도메인 nemo.co.kr은 앞서 등록기관에 신청하였으니, ns.nemo.co.kr, ns2.nemo.co.kr에 네임서버 설정을 하면 된다.
4-1. BIND부트 파일 named.conf
BIND 부트 파일은 추가사항을 손쉽게 적용할 수 있도록 파일 포맷이 변경되었다. 그리고 구버젼 부트 파일과의 혼동을 막기위해 named.conf로 리네임 되었다. 어떻게 보면 C 언어의 문법과 매우 흡사한 것을 알 수 있다. 설정을 좀더 세밀하게 할 수 있도록 작성법이 바뀌었을 뿐, BIND의 부트 파일과 크게 다를 것은 없다. 다음은 앞서 작성한 BIND 기반 부트 파일을 BIND-8에 맞게 변환한 예이다. 일반적으로 BIND-8 기반의 부트 파일은 다음에 나열된 레코드정도만이 활용되지만, 재미난 부분이 많으므로 좀더 깊숙히 알고 싶다면 http://www.isc.org/products/BIND/docs/ 를 참고하기 바란다.
다음은 Primary 네임서버를 위한 부트 파일이다.
ns.nemo.co.kr(Primary NS)의 /etc/named.conf 파일
options {
directory "/var/named";
설명 : ';'은 주석이 아니라 줄의 끝을 의미한다. Zone 파일의 베이스 디렉토리
dump-file "/var/tmp/named_dump.db";
설명 : Dump 파일이 생성되는 경로
statistics-file "/var/tmp/named.stats";
설명 : 통계 파일이 생성되는 경로
pid-file "/var/run/named.pid";
설명 : 프로세스 ID가 담긴 파일 생성 경로
};
logging {
설명 : 불필요한 정보를 로그파일에 남기지 않는다.
category lame-servers { null; };
category cname { null; };
category response-checks { null; };
category notify { null; };
};
zone "." IN {
설명 : 캐쉬 파일
type hint;
file "named.root";
};
zone "0.0.127.in-addr.arpa" IN {
설명 : localhost를 위한 Primary 도메인 설정
type master;
file "zone-0.0.127.in-addr.arpa";
};
zone "79.105.210.in-addr.arpa" IN {
설명 : 할당 IP 블락에 대한 Reverse Zone
type master;
file "zone-79.105.210.in-addr.arpa";
};
zone "nemo.co.kr" IN {
설명 : 도메인 nemo.co.kr 에 대한 Forward Zone
type master;
file "zone-nemo.co.kr";
};
Secondary 네임서버를 위한 부트 파일은 다음과 같이 작성된다.
ns2.nemo.co.kr(Secondary NS)의 /etc/named.conf 파일
options {
directory "/var/named";
};
logging {
category lame-servers { null; };
category cname { null; };
};
zone "." IN {
type hint;
file "named.root";
};
zone "0.0.127.in-addr.arpa" IN {
설명 : localhost를 위한 Primary 도메인 설정
type master;
file "zone-0.0.127.in-addr.arpa";
};
zone "79.105.210.in-addr.arpa" IN {
설명 : Reverse Zone에대한 Secondary 설정
type slave;
file "sec-79.105.210.in-addr.arpa";
masters { 192.168.1.2; };
설명 : Primary NS의 IP 주소
};
zone "nemo.co.kr" IN {
설명 : nemo.co.kr 의 Secondary 설정
type slave;
file "sec-nemo.co.kr";
masters { 192.168.1.2; };
};
4-2. 리소스 레코드(Resource Record)
Zone 파일은 Forward, Reverse 두 가지로 구분된다. Forward Zone은 도메인에 대한 IP 정보를 갖고 있는 데이터베이스이고, Reverse Zone은 IP에 대한 도메인정보를 갖는 데이터베이스이다. 앞서 named.boot 파일에 네임서버가 loopback, 79.105.210.in-addr.arpa, nemo.co.kr 도메인에 대해 Primary로 동작하도록 설정하였다. 이중 zone-0.0.127.in-addr.arpa와 zone-79.105.210.in-addr.arpa가 Reverse Zone 파일이고, zone-nemo.co.kr이 Forward Zone 파일이다.
4-3. SOA 레코드 (Start Of Authority)
Zone 파일은 항상 SOA 레코드로 시작한다. SOA 레코드는 해당 도메인, nemo.co.kr에 대해 네임서버가 인증(authoritative)된 자료를 갖고 있음을 의미하며, 자료가 최적의 상태로 유지, 관리될 수 있도록 한다.
nemo.co.kr. IN SOA ns.nemo.co.kr. root.nemo.co.kr. (
1998122800 ;Serial
21600 ;Refresh ( 6 hours)
1800 ;Retry (30 minutes)
1209600 ;Expire (14 days)
86400) ;Minimum ( 1 day)
1열에는 해당 Zone 파일에 대한 도메인명이 들어간다. 도메인명 끝의 도트를 잊지 말자. 다음과 같이 도메인명 대신 '@' 표시를 사용하여도 된다.
@ IN SOA ns.nemo.co.kr. hostmaster.nemo.co.kr. (
IN(Internet)은 클래스명이다. HS, HESIOD, CHAOS와 같은 클래스도 존재하지만, 일반적으로 사용되지 않으므로 항상 IN이 사용된다고 생각하자.
SOA 다음엔 Primary 네임서버와 관리자 Email 주소가 들어간다. hostmaster.nemo.co.kr. 이 Email 주소인데, 일반적 Email 표기법에서 '@'를 도트로 바꾸어 쓰면 된다. 본 Email은 해당 도메인의 콘택 포인트(Responsible Person)로서 도메인에 문내가 발생할 경우 이를 리포팅하는 용도로 사용된다. Namespace를 쫓으며 도메인 오류를 점검하는 lamers 와 같은 도구들은 문내가 검출되었을 때 본 Email로 통지하여 준다.
다음 괄호로 둘러싸인 부분엔 Serial, Refresh, Retry, Expire, Minimum 5개의 시간(초) 필드가 놓인다. Minimum을 제외한 4개 필드는 Secondary 네임서버를 제어하기 위한 값이다. 기본 단위는 '초'이고, 단위기호 M(Minute), H(Hour), D(Day), W(Week)를 붙여 30M, 8H, 2D, 1W와 같이 사용할 수도 있다.
|
필드 |
설 명 |
|
Serial |
Serial은 Secondary가 Zone 파일의 수정여부를 알 수 있도록 하기 위함이다. Secondary는 백업본의 Serial이 Primary의 Serial보다 작을 경우 Zone 파일을 재전송 받는다. 따라서 Zone 파일이 수정된 후 Serial이 변경되지 않는다면, Secondary는 백업카피를 업데이트하지 않음을 유의하자. Secondary가 없다면 Serial은 의미가 없지만 그렇다 할지라도 Zone 파일이 수정되었을 때 Serial을 증가하는 것은 좋은 습관이다. Seria의l 표기는 증가하는 임의 숫자보단 일반적으로 최종 수정일을 YYYYMMDDNN의 형식으로 표기한다. YYYYMMDDNN 연도 표기법은 4294년까지 표기 가능하다. |
|
Refresh |
Primary측의 Zone 데이터베이스 수정여부를 Secondary가 검사하는 주기이다. 네트워크의 변경이 잦아 Zone파일이 자주 수정된다면, 3H(10800) 정도로 설정한다. Zone이 안정되는 시점에서는 일반적으로 6H(21600) - 12H로 설정한다. |
|
Retry |
Secondary측에서, Primary와 연결이 안될 경우, 재 시도 시간 주기이다. Refresh 기간 보다 적을때 의미가 있으며, 대부분의 경우 30M(1800) - 1H로 설정한다. |
|
Expire |
Secondary가 Expire로 지정된 시간동안 Primary에 연결하지 못할 경우, 오래된 백업카피의 자료가 더 이상 유효하지 않다고 보고, 해당 도메인에 대한 답변을 하지 않는다. 이 값을 너무 낮게 책정하는 것은 좋지 않다. 보통 1W - 2W(1209600)로 설정한다. |
|
Minimum |
타 네임서버가 본 Zone에 기술된 자료를 갖고 갔을 경우, 그 자료에 대한 유효기간(캐쉬에 살아있는 시간)을 설정한다. TTL(Time To Live)값이 명시되지 않은 레코드는 본 값을 기본으로 갖게 된다. 특정 레코드가 변경되었을 때, 이것이 인터넷에 전파되어 업데이트되는 주기는 전적으로 이 Minimum 값에 의존한다. 일반적으로 SOA에서는 1D(86400)를 설정하여 전체 레코드에 적용하고, 잦은 변경이 예상되는 레코드만 명시적으로 1H - 3H 정도로 낮추는 방법을 사용한다. 0은 캐싱을 하지 말라는 의미이다. |
4-4. NS(Name Server) 레코드
NS 레코드로 해당 도메인에 대한 네임서버를 다음과 같이 나타낸다.
nemo.co.kr. IN NS ns.nemo.co.kr.
IN NS ns2.nemo.co.kr.
또 다른 NS의 활용으로는, 거대 도메인에서 서브 도메인을 다른 네임서버로 위임할 때이다. Namespace상의 가지연결은 이 NS 레코드로 이루어 지는데, 거대 도메인일 경우 해당하는 부분이므로, 여기서는 해당 도메인에 대한 위임 정보만을 나타낸다고 알아두자. 도메인 위임에서 자세히 다룬다.
4-5. A(Address) & CNAME(Canonical Name) 레코드
A 레코드는 도메인에 IP를 부여한다. 다음 설정을 보자. mail과 power에 A 레코드로 IP를 매핑 하였다. (mail과 mail.nemo.co.kr. 은 동일하게 해석된다.)
; Host addresses
mail.nemo.co.kr. IN A 192.168.1.2
power IN A 192.168.1.103
; Aliases
www IN CNAME power.nemo.co.kr.
ftp IN CNAME www
CNAME 레코드는 도메인에 대한 또 다른 이름이 가능하도록 한다. 예에서는 power.nemo.co.kr, www.nemo.co.kr, ftp.nemo.co.kr은 모두 같은 IP 192.168.1.103을 갖게 된다. ftp와 같이 CNAME이 CNAME을 포인팅 하는 경우는, 여러 DNS 관련 자료에서 다르게 얘기되고 있지만, 이것은 가능하다. CNAME은 포인팅하는 오리지널 도메인의 레코드를 모두 상속받기 때문에, CNAME으로 설정된 도메인은 추가 레코드를 갖을 수 없음을 유의한다. 또한, MX, NS 등의 레코드에도 CNAME으로 설정된 도메인을 넣어서는 안된다. 반드시 주의하여야 한다. CNAME의 잘못된 사용은 BIND 로그를 유심히 관찰하지 않으면 찾기 어려우므로, 확실히 할 수 없다면 CNAME으로 설정된 레코드를 아예 다른 레코드의 인자로 놓지 않는 것이 좋다. 숙련된 도메인 메니저 중에서도 트래픽과, 퍼포먼스라는 측면에서 CNAME을 전혀 사용하지 않는 경우도 있다. (참고: CNAME의 사용에 관해)
ftp IN CNAME www ; (X) CNAME엔 추가레코드를 갖을 수
IN MX mail ; 없다.
power IN MX 10 mail ; (X) MX에 CNAME으로 설정된
mail IN CNAME ns ; 레코드가 올 수 없다.
invalid-file