|
이제 인버스 도메인을 설정해 보자. 인버스 도메인이란 IP를 도메인으로 변경해 주는 서비스이다. 쉽게 예를 들면 yahoo.co.kr의 IP주소는 211.32.119.151이다. 지금 브라우저에다 211.32.119.151를 입력하고 엔터키를 쳐보기 바란다. 아마도 yahoo.co.kr로 변경이 되면서 야후 홈페이지가 나올 것이다. 인버스 도메인을 운영하려면 상위 ISP에서 권한을 위임 받아야 된다. 실제로 IP몇개 가지고는 운영하기 힘들 것이다. 적어도 클래스 대역을 받아야 권한 위임이 가능할 것이다. 그래도 간단히 알아보고 넘어가자.
| [root@localhost]# |
[root@localhost]# vi /etc/named.conf
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};
|
우리는 caching nameserver패키지를 설치했기 때문에 위의 설정이 기본으로 잡혀 있을 것이다. 위의 설정은 로컬 네트워크 설정이다. 위에서 요구하는 named.local화일을 열어보자.
| [root@localhost]# |
[root@localhost]# vi /var/named/named.local
$TTL 86400
@ IN SOA localhost. root.localhost. (
2003081401 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS localhost.
1 IN PTR localhost.
|
named.local화일에 보면 SOA영역은 도메인 설정할 때의 zone화일과 같다. 데이터 영역에 보면 새로운 레코드가 한 개 보일 것이다. PTR 레코드는 인버스 도메인을 정의 해주는 레코드 이다. 기본적으로 로컬 루프백 주소인 127.0.0.1번 IP가 localhost로 설정이 되어있다.
이제 실제로 네트워크 대역에 대해서 설정을 해보자. 필자는 192.168.0.0의 C클래스 대역을 가지고 있다. 이제 필자의 네트워크 대역에 대해서 인버스 도메인을 설정해 보자.
| [root@localhost]# |
[root@localhost]# vi /var/named/0.168.192.rev
$TTL 86400
@ IN SOA ns.nasord.com. admin.nasord.com. (
2003081401 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS ns.nasord.com.
10 IN PTR ns.nasord.com.
13 IN PTR nasord.com
14 IN PTR ftp.nasord.com
15 IN PTR mail.nasord.com
|
위의 설정을 보면 필자는 각각의 호스트 마다 PTR레코드를 설정해 주었다. PTR레코드는 한 개의 IP에 여러개의 호스트를 설정할 수 없다. 주의 하기 바란다.
웬만한 기업에서는 네임서버를 2대를 사용하는 것이 낭비일 수도 있으나, 네임서버가 장애시 정상적인 서비스를 위해서 보조 네임서버를 운영하는 것은 좋은 방법이다. 이제 어떻게 주네임서버와 보조 네임서버를 운영하는지 알아보자.
어느날 갑자기 주네임서버가 장애로 인해서 다운이 되었다. 물론 캐시된 내용들이 다른 네임서버들에 남아있기 때문에 바로 영향을 받지는 않는다. 하지만 캐시된 내용이 없는 서버들도 있기 때문에 빨리 복구를 해야 된다. 이럴 때 보조 네임서버가 있다면, 좀더 안정적인 서비스를 할 수 있을 것이다.
필자는 주 네임서버의 IP를 192.168.0.10번으로 설정하고 보조 네임서버는 192.168.0.11번으로 설정할 것이다. 호스트 네임은 ns.nasod.com과 ns2.nasord.com으로 설정해서 운영할 것이다. 설치 방법은 주네임서버나 보조 네임서버나 같다. 다만 설정에서 약간의 변화가 필요하다. 우리는 여기서 배운 SOA영역에 관한 내용들을 사용할 것이다. 주로 SOA영역은 주네임서버와 보조 네임서버간에 데이터의 신뢰성에 관한 내용들을 가지고 있다. 이렇게 말로 애기하는 것보다 실제로 설정해보는 것이 훨씬 이해가 잘될 것이다.
 주 네임서버 설정
| [root@localhost]# |
[root@localhost]# vi /etc/named.conf
zone "nasord.com" IN {
type master;
file "nasord.com.zone";
};
|
보조 네임서버 설정
| [root@localhost]# |
[root@localhost]# vi /etc/named.conf
zone "nasord.com" IN {
type slave;
file "nasord.com.zone";
masters { 192.168.0.10; };
};
|
달라진 것이 있다면 도메인의 type가 변경이 되었고 보조 네임서버에서는 주 네임서버를 설정해 주었다. 보조 네임서버는 zone화일을 만들어줄 필요가 없다. reload시키면 자동으로 불러온다. 보조 네임서버 설정시 주의할점은 주 네임서버에 allow-transfer옵션이 설정되어 있어야 된다. 기본적으로 모든 호스트에 대해서 transfer할 수 있도록 설정이 되어있다. allow-transfer에 대한 내용은 뒷부분에서 다루기로 하겠다.
Bind 9의 시작과 종료에 대해서 알아보자. Bind 9의 시작 데몬의 위치는 설치 방식에 따라서 틀리다. Source설치시 /usr/local/bind/sbin/named이고, RPM설치시는 /usr/sbin/named이다. 데몬 파일에서 바로 실행하는 것보다, 스크립트를 등록해 놓고 사용하면 편리하다.
| [root@localhost]# |
[root@localhost]# /etc/rc.d/init.d/named start
Starting named: [ OK ]
|
실행을 시키면 named계정으로 Bind데몬이 구동이 될 것이다. 데몬의 종료는 아래와 같이 하면 된다.
| [root@localhost]# |
[root@localhost]# /etc/rc.d/init.d/named stop
Stopping named: [ OK ]
|
Bind 9의 재시작은 rndc를 이용해서 하기 바란다. 도메인이 많을 경우 데몬 구동 스크립트로 재시작할 경우 캐시가 지워지면서 다시 로드하는데 오랜 시간이 걸린다.
| [root@localhost]# |
[root@localhost]# rndc reload
|
rndc를 이용해서 reload하면 변경된 부분만 바로 적용을 시킨다. rndc명령어는 현재 Bind데몬의 상태를 자세하게 알려준다.
| [root@localhost]# |
[root@localhost]# rndc status
number of zones: 388
debug level: 0
xfers running: 2
xfers deferred: 22
soa queries in progress: 351
query logging is OFF
server is up and running
|
위와 같이 zone의 갯수와 진행되고 있는 transfer상태와 데몬의 현재 상태등 다양한 것들을 보여준다.
지금 까지의 설명은 초급 사용자들이 쉽게 사용할 수 있도록 기본적인 설명위주로 진행을 했다. 지금부터는 네임서버를 운영하는데 있어서 좀더 고급옵션과 보안에 중점을 두어서 설명하고자 한다. 먼저 named.conf의 옵션들을 살펴보자.
| [root@localhost]# |
[root@localhost]# vi /etc/named.conf
// generated by named-bootconf.pl
options {
directory "/var/named";
version "unknown";
pid-file "/var/run/named/";
allow-transfer { 192.168.0.10; };
};
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
};
//
// a caching only nameserver config
//
controls {
inet 127.0.0.1 allow { localhost; } keys { key; };
};
logging {
category lame-servers { null; };
category unmatched { null; };
category network { null; };
category notify { null; };
};
zone "." IN {
type hint;
file "named.ca";
};
zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};
include "/etc/rndc.key";
|
options{} : Bind 9의 기본적인 옵션을 설정한다. 세부 옵션을 살펴 보자.
directory : zone화일이 위치하는 경로를 지정해 준다. 기본값은 /var/named이다.
version : Bind의 버전을 임의로 지정해 준다. 버전별로 취약점을 악용한 exploit이 존재하기 때문에 버전을 숨길 수 있음으로 공격자가 정보의 획득을 힘들 게 한다.
| [root@localhost]# |
[root@localhost]# dig @192.168.0.2 version.bind chaos txt
; <<>> DiG 9.2.0 <<>> @192.168.0.2 version.bind chaos txt
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2655
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;version.bind. CH TXT
;; ANSWER SECTION:
version.bind. 0 CH TXT "9.2.2"
;; Query time: 2 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: Sat Aug 16 11:25:06 2003
;; MSG SIZE rcvd: 48
|
위의 예제를 보면 Bind 9의 버전이 9.2.2라는 것이 나왔다. 그러면 공격자는 9.2.2버전의 exploit을 준비해서 공격을 하면 된다. 만약 버전이 unknown으로 나오면 공격자는 다른 방법을 찾아야 할것이다.
pid-file : Bind 9의 PID가 생성될 경로를 지정해 준다. 기본값은 /var/run/named이나, 권한부족으로 생성이 안될 경우 변경해 주면 된다.
allow-transfer : zone-transfer을 허용할 IP를 지정해 준다. 보통 보조 네임서버를 지정해 두면 된다. 만약 지정하지 않을 경우 보안상 취약하게 된다. 만약 허가 되지 않은 사람에게 zone-transfer을 허용할 경우 DNS 서버의 중요한 정보가 유출되게 된다. 즉, 공격자는 전송 받은 Zone 정보를 이용하여 호스트 정보, 네트워크 구성 형태 등의 많은 정보를 파악할 수 있게 된다. 대부분의 사이트에서 DNS 서버를 디폴트로 설치할 경우 임의의 사용자가 Zone Transfer 를 할 수 있도록 설정된다. 다음은 nslookup 명령을 이용하여 DNS 서버의 Zone 데이터를 수집하는 것을 보여준다.
| [root@localhost]# |
[root@localhost]# nslookup
>server 192.168.0.10
Default Server: [192.168.0.10]
Address: 192.168.0.10
>
> set type=any
> nasord.com >> nasord.com.zone
Server: [192.168.0.10]
Address: 192.168.0.10
|
위와 같이 실행후 전송된 naosrd.com.zone화일을 보면, 호스트별 IP와 네트워크의 구성형태등의 중요한 내부 정보가 유출될 수 있다. 그러므로 보조 네임서버를 제외하고는 모두 막아 두는 것이 좋다.
controls {} : 콘트롤 옵션은 주로 관리 목적으로 설정이 된다. 세부 설정을 살펴보자.
inet : Listening IP를 지정한다.
allow : allow에 지정된 호스트만이 Bind를 컨트롤 할 수 있다.
key : allow에 지정이 안되있더라고 key값이 동일한 경우 콘트롤할 수 있다. key생성에 대해서 간단히 알아보자. key는 rndc-confgen명령어로 생성하며, 생성시에 램덤하게 생성이 된다.
| [root@localhost]# |
[root@localhost]# /usr/local/bind/sbin/rndc-confgen > /etc/rndc.conf
[root@localhost]# cat /etc/rndc.conf
key "rndc-key" {
algorithm hmac-md5;
secret "PSYc3s2THUqOK8qV65Jm9w==";
};
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
|
logging {} : 주로 로그 관련 항목들을 설정한다. 거의 불필요한 로그들이므로 null로 설정해서 하용하면 된다. 세부 항목의 설명은 생략하겠다.
include "/etc/rndc.key" : /etc/rndc.key에 정의된 경로를 넣어주면 된다. 최소 named사용자에게 읽기 권한이 있어야 된다. 보안상 외부사용자에게 유출되면 안되니, 최소의 권한만으로 운영하기 바란다.
거의 손댈일이 없는 부분이다. 하지만 가끔식 변경하기도 하니까, 최소 한달에 한번식만 업데이트 해주기 바란다. 업데이트는 cron으로 한달에 한번 실행되도록 설정해 주면 된다.
| [root@localhost]# |
[root@localhost]# dig @ns.krnic.net . ns > /var/named/named.ca
[root@localhost]# crontab -e
0 0 1 * * root dig @ns.krnic.net . ns > /var/named/named.ca
|
필자는 주로 krnic에서 받아온다.
Dynamic Update는 동적 업데이트로 Bind 8에 비해서 dnssec-key를 이용한 인증부분이 강화되었다. Dynamic Update를 사용하기 위해서는 named.conf의 zone설정에서 allow-update지시자에 rndc.key에서 정의된 key를 사용해야 된다.
| [root@localhost]# |
[root@localhost]# tar xvfz bind-9.2.2.tar.gz
[root@localhost]# cd bind-9.2.2[root@localhost]# vi /etc/naemd.conf
zone "nasord.com" IN {
type master;
file "nasord.com.zone";
allow-update { key "rndc-key"; };
};
|
위와 같이 정의된 키를 입력하고 명령을 수행해야 된다. 인증방식은 두가지로 key를 사용한 인증과 IP인증이 있다. 될 수 있으면 key를 사용한 인증을 사용하는 것을 권장한다. 이제 실제로 업데이트를 사용해 보자.
업데이트 전에 명령문에 대해서 간단히 알아보자. 자세한 명령어는 msn을 참고하기 바란다.
prereq yxdomain DOMAIN-NAME : DOMAIN-NAME이 존재(하나이상의 레코드가 설정되어 있음)함을 연속된 명령의 선행 조건으로 삼는다.
prereq nxdomain DOMAIN-NAME : DOMAIN-NAME에 어떠한 레코드도 설정되어 있지 않음을 연속된 명령의 선행 조건으로 삼는다.
prereq yxrrset DOMAIN-NAME [CLASS] TYPE [DATA] : DOMAIN-NAME에 해당 레코드가 존재함을 연속된 명령의 선행 조건으로 삼는다. DATA가 명시되어 있을 경우에는 정확하게 매칭이 되는 경우에만 조건이 성립된다.
prereq nxrrset DOMAIN-NAME [CLASS] TYPE : DOMAIN-NAME에 해당 레코드가 존재하지 않음을 연속된 명령의 선행 조건으로 삼는다.
update delete DOMAIN-NAME [CLASS] [TYPE [DATA...]]: TYPE이 명시되지 않았을 경우엔 해당 DOMAIN-NAME에 소속된 레코드를 모두 삭제한다. TYPE이 명시될 경우엔 매칭되는 레코드만이 제거된다.
update add DOMAIN-NAME TTL [CLASS] TYPE DATA... : 지정된 레코드를 해당 도메인에 추가한다.
show: 마지막 send 전 까지의 모든 선행 조건과 업데이트 스펙을 포함한 모든 메세지를 출력한다.
send: 현재 메세지를 서버로 전송하여 업데이트를 시도한다.
dnssec-key를 사용한 인증 : ex)nsupdate -d -y key-name:dnssec-key
| [root@localhost]# |
[root@localhost]# vi /etc/naemd.conf
zone "nasord.com" IN {
type master;
file "nasord.com.zone";
allow-update { key "rndc-key"; };
};
[root@localhost]# vi /etc/rndc.key
key "rndc-key" {
algorithm hmac-md5;
secret "PSYc3s2THUqOK8qV65Jm9w==";
};
[root@localhost]# nsupdate -d -y
rndc-key:PSYc3s2THUqOK8qV65Jm9w==
Creating key...
namefromtext
keycreate
> server 192.168.0.10
> prereq nxdomain kr.nasord.com
> update add kr.naosrd.com 86400 A 192.168.0.13
> send
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5040
;; flags: qr aa rd ra ; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;kr.naosrd.comr. IN SOA
;; AUTHORITY SECTION:
kr.naosrd.com. 0 IN SOA kr.naosrd.com. admin.kr.naosrd.com.
2003080410 28800 7200 604800 300
Found zone name: nasord.com
The master is: ns.nasord.com
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 35288
;; flags: qr ra ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; TSIG PSEUDOSECTION:
rndc-key. 0 ANY TSIG hmac-md5.sig-alg.reg.int.
1061006788 300 16 IKIz+21KtkwHOUYyKb+8LQ== 35288 NOERROR 0
|
필자는 kr.nasord.com이라는 호스트를 추가해 보았다. 이제 제대로 추가가 되었는지 확인해 보자.
| [root@localhost]# |
[root@localhost]# nslookup kr.nasord.com
Server: ns.nasord.com
Address: 192.168.0.10
Non-authoritative answer:
Name: kr.nasord.com
Address: 192.168.0.13
|
위에 보이는 것처럼 kr호스트가 추가가 되었다. 하지만 zone화일에는 아직 추가가 되지 않았다. 아직까지는 캐시에만 저장이 되어있다가 Bind종료시 zone화일에 쓰여진다.
-주 의-
Dynamic Update를 이용할 경우 Bind의 종료는 rndc를 이용해서 종료 해야 된다. 프로세스를 그냥 죽여 버릴 경우 캐시에 남아있는 것들이 zone화일에 쓰여지지 않고 날아가게 된다.
| [root@localhost]# |
[root@localhost]# rndc stop
[root@localhost]# /etc/rc.d/init.d/named.start
[root@localhost]# cat /var/named/nasord.com.zone
$TTL 86400
@ IN SOA ns.nasord.com. admin.nasord.com. (
2003081301 ; serial
28800 ; refresh
7200 ; retry
604800 ; expire
86400 ; ttl
)
IN NS ns.nasord.com.
IN MX 10 mail.
@ IN A 192.168.0.13
ns IN A 192.168.0.10
ftp IN A 192.168.0.14
mail IN A 192.168.0.15
kr IN A 192.168.0.13 <-- 추가된 부분
www IN CNAME @
|
기존의 호스트를 수정할 경우 명령어가 달라진다. 예제를 보기 바란다.
| [root@localhost]# |
[root@localhost]# nsupdate -d -y rndc-key:PSYc3s2THUqOK8qV65Jm9w==
Creating key...
namefromtext
keycreate
> server 192.168.0.10
> prereq yxdomain kr.nasord.com
> update delete kr.nasord.com A
> update add kr.naosrd.com 86400 A 192.168.0.14
> send
|
호스트 수정시에는 기존의 호스트를 삭제해주고 추가를 시켜 줘야 된다.
IP를 이용한 인증 : ex)nsupdate ip를 이용한 인증은 별다를 것이 없다. IP만으로 인증을 해야 되므로 보안상 취약할 수 있다. 될 수 있으면 key을 이용한 인증을 하기 바란다.
| [root@localhost]# |
[root@localhost]# vi /etc/naemd.conf
zone "nasord.com" IN {
type master;
file "nasord.com.zone";
allow-update { 192.168.0.10; };
};
[root@localhost]# nsupdate
Creating key...
namefromtext
keycreate
> server 192.168.0.10
> prereq nxdomain kr.nasord.com
> update add kr.naosrd.com 86400 A 192.168.0.13
> send
|
Dynamic Update기능은 유용하게 사용할 수 있으나, 명령어가 손에 익어야 잘 사용할 수 있을 것 같다. 필자는 아직 익숙하지가 않아서 바로 수정해서 사용한다. 스크립트로 만들어서 사용하면 아주 편리할 것 같다.
nslookup이란 네임서버에 질의를 던져서 결과를 얻어 내는 도구이다. 거의 모든 운영체계에 기본적으로 설치가 되어있다. 네임서버 운영시에 가장 많이 사용되는 도구이다. 이제 nslookup의 사용법에 대해서 알아보자. 실행방법은 아주 간단하다. 그냥 명령어만 입력하면 된다.
| [root@localhost]# |
[root@localhost]# nslookup
Note: nslookup is deprecated and may be removed from future releases.
Consider using the `dig' or `host' programs instead. Run nslookup with
the `-sil[ent]' option to prevent this message from appearing.
>
|
위의 실행 예제는 리눅스 플랫폼에서 실행시킨 예제이다. note부분은 무시해도 된다. nslookup도구가 없어질 것이니 dig나 host를 사용하라는 말이다. 위의 note를 보기 싫으면 -sil옵션으로 실행하면 된다. 이제 nslookup를 이용해서 실제로 질의를 해보자.
| [root@localhost]# |
[root@localhost]# nslookup -sil
> nasord.com
Server: 168.126.63.1
Address: 168.126.63.1#53
Name: nasord.com
Address: 192.168.0.13
>
|
nslookup으로 질의를 던졌더니 nasord.com --> 192.168.0.13번이라고 가르쳐 주었다. 위의 예제는 간단한 예제를 실행해본 것이고, 좀더 고난이도의 질의를 해보자. 만약 호스트의 IP가 변경이 되어서 네임서버에서 IP를 변경을 해주었다. 그런데 일부는 정상적으로 접속이 되는데, 접속이 안되는곳도 있다. 왜 그런지 네임서버에 질의를 해서 알아보자.
| [root@localhost]# |
[root@localhost]# nslookup -sil
> server 168.126.63.1
Default server: 168.126.63.1
Address: 168.126.63.1#53
> set type=soa
> nasord.com
Server: 168.126.63.1
Address: 168.126.63.1#53
nasord.com
origin = ns.nasord.com
mail addr = admin.nasord.com
serial = 2003080501
refresh = 300
retry = 7200
expire = 604800
minimum = 86400
>
|
한국통신 회선을 사용하는 가입자들이 서비스에 접속이 안된다고 난리가 났다. 그래서 필자는 네임서버를 168.126.63.1로 변경을 하고 서버에 질의를 해보았다. 이런, 한국통신 회선의 네임서버에는 ttl값이 86400초로 등록이 되어있다. 저 값이 다 되기 전까지는 한국통신의 네임서버는 ns.nasord.com에 질의를 하지 않는다. 어쩔 수 없이 24시간을 기다려야 된다.
만약 자신이 서버 관리자라면, 서버의 IP를 변경하기 전에 ttl값을 300초내지 짧은 시간으로 변경을 해주고 타 네임서버에 전파되기까지 24시간 정도를 지켜본다음에 호스트의 IP를 변경을 해야 될 것이다. 그렇게 한다면 최고 5분이면 IP변경이 완료 되는 것이다.
set type 옵션은 여러 가지가 있다. 필자가 아는 것만 설명해보겠다.
| [root@localhost]# |
[root@localhost]# nslookup -sil
> server 168.126.63.1
> set type=a
> nasord.com
Server: 168.126.63.1
Address: 168.126.63.1#53
Name: nasord.com
Address: 192.168.0.13
|
set type 옵션의 종류는 A레코드를 보여주는 a옵션, MX레코드를 보여주는 mx옵션, 그리고 네임서버를 보여주는 ns옵션등 여러 가지가 있다. 도메인의 모든 정보를 다 보고 싶다면 any를 입력하면 된다.
|
+Authoritative answer & Non-authoritative answer
|
|
네임서버는 질의에 대한 결과를 캐시에 저장하고 같은 질의가 요구되었을시 빠르게 응답을 한다. 캐시의 자료는 Resolving시 얻은 TTL값이 만료 되기전까지 유효 하고 TTL값 만료후에는 파기된다. 도메인 Resolving 요청시 네임서버가 캐쉬의 자료로 응답 할 경우는 Non-authoritative answer이고, 캐쉬에 자료가 없거나, 자료의 TTL이 만기되어 해당 도메인의 Primary 네임서버에서 직접 자료를 얻어 답변을 주었을 경우가 Authoritative answer이다.
| [root@localhost]# |
[root@localhost]# nslookup -sil
> server 168.126.63.1
> set type=a
> nasord.com
Server: 168.126.63.1
Address: 168.126.63.1#53
Non-authoritative answer:
Name: nasord.com
Address: 192.168.0.13
|
위의 예제에서는 캐시에 저장된 값을 불러왔다. 만약 캐시에 없다면 해당 네임서버로 질의를 한뒤 결과를 얻어 올 것이다. 그럼 Authoritative answer로 나오게 된다.
Bind 9를 운영하면서 접할 수 있는 에러에 대해 알아보자. 먼저 named.conf화일의 구문 오류를 체크해 볼 수 있는 named-checkconf명령어에 대해서 알아보자. 만약 named.conf화일에 구문 오류가 발생한다면 Bind 9의 데몬이 실행이 안된다. 이럴 경우를 대비해서named-checkconf를 이용해서 named.conf화일을 체크하는 습관을 기르도록 하자.
| [root@localhost]# |
[root@localhost]# vi /etc/naemd.conf
zone "nasord.com" IN {
type master;a <-- 오타 입력
file "nasord.com.zone";
allow-update { key "rndc-key"; };
};
[root@localhost]# named-checkconf
/etc/named.conf:47: unknown option 'a'
|
위와 같이 구문 오류가 나는 부분의 위치와 원인이 자세히 나온다. 보통의 경우 Bind 9의 에러는 소유권과 퍼미션 에러가 거의 대부분이다. Bind 9는 named계정으로 실행이 된다는 것을 명심해라. Bind 9관련 파일은 최하 named계정에 대해서 읽기 권한이 있어야 된다. 아래의 예제를 보기 바란다.
| [root@localhost]# |
[root@localhost]# vi /var/log/message
named[184]: couldn't open pid file '/var/run/named.pid': Permission denied
|
PID생성 실패로 나오는 에러 메시지 이다. 에러 메시지의 내용을 보면 /var/run/named.pid화일을 생성하지 못해서 에러가 나오고 있다. named계정이 생성할 수 있도록 권한을 부여 한다. 아니면 PID폴더를 변경해줘도 된다.
아래의 예제는 해당 도메인의 zone화일을 찾지 못해서 나오는 에러이다. 해당 도메인의 zone화일을 생성해 주면 된다.
| [root@localhost]# |
[root@localhost]# vi /var/log/message
named[227]: zone nasord.com/IN: loading master file nasord.com.zone: file not found
|
만약 권한이 없다면 아래와 같은 에러 메시지가 나온다. 권한 에러의 경우 named계정에 관해 읽기 권한을 주면 된다.
| [root@localhost]# |
[root@localhost]# vi /var/log/message
named[227]: zone nasord.com/IN: loading master file nasord.com.zone: permission denied
|
기타 에러메시지도 로그를 보면 해결할 수 있다. 데몬이 구동이 안된다던지 도메인이 셋팅이 안된다는지 할 때는 에러메시지를 참고하면 된다.
Bind 9를 필자는 처음 사용해 봤다. 물론 Source설치도 처음 해봤다. 부족한 부분이 많이 있고, 강좌의 진행도 어수선 하지만 나름대로 열심히 정리를 해봤다. 강좌를 작성하는데 자그마치 일주일이 걸렸다. 작성하면서 많은 부분들이 빠졌지만, 빠진 부분은 나름대로 시간을 내서 다시 정리하겠다. 강좌의 내용중 오타와 틀린부분이 있다면 메일이나 게시판을 이용하기 바란다.
|
