BIND 9 installation

Bind 9를 이용한 주네임서버와 보조 네임서버 구축

(글쓴이: 굿스피드 (2003년 09월 20일 오후 03:10) 읽은수: 6,042)
이번 강좌는 Bind 9를 이용해서 네임서버를 구축하는 과정을 다루고 있다. 인터넷의 시작은 우리가 브라우저에 도메인을 입력하면서부터 시작된다. 그만큼 네임서버는 인터넷 서비스에서 중요한 역할을 하고 있다. 본 강좌는 깅승영님의 Powered by DNS와 김정균님의 Name Server(BIND9)에서 많은 도움을 받았다. 부족한 부분은 위의 문서를 참고하면 많은 도움이 될것이다.

+목차
1. 설치전 주의사항
2. 설치환경
3. 설치전 준비사항
4. Bind 9설치(Source 설치)
5. Bind 9설치(RPM 설치)
6. Caching Name Server 테스트
7. 설정 화일
8. 도메인 셋팅 #1
9. 도메인 셋팅 #2
10. inverse domain 설정
11. 주네임서버와 보조 네임서버 연동
12. Bind 9의 시작과 종료
13. Bind 9의 고급옵션과 기능 #1
14. Bind 9의 고급옵션과 기능 #2
15. Cache화일 생성하기
16. Dynamic Update
17. nslookup를 이용한 네임서버 점검
18. Authoritative answer & Non-authoritative answer
19. Bind 9 에러 메시지
20. 설치를 끝내며

+설치환경
주 네임서버(192.168.0.10)
Model: LG IBM eServer X330
CPU : Intel Pentium III 1.13Mhz
RAM: 256M
HDD: SCSI IBM 18.2G
OS: Redhat Linux 7.3(서버모드 설치)
Kernel: 2.4.18
보조 네임서버(192.168.0.11)
Model: LG IBM eServer X330
CPU : Intel Pentium III 1.13Mhz
RAM: 256M
HDD: SCSI IBM 9G
OS: Redhat Linux 7.3(서버모드 설치)
Kernel: 2.4.18

+설치전 준비사항
설치에 앞서 간단히 현재 인터넷 상의 도메인 체계와 IP에 관해서 알아보고 넘어가자. 인터넷상에서 사용되는 도메인은 전세계적으로 고유하게 존재하여야 하므로 공통적으로 정해진 체계에 따라야하며, 임의로 변경하거나 생성할 수 없다.
인터넷상의 모든 도메인은 "." 또는 루트(root)라 불리는 도메인 이하에 아래 그림과 같이 나무를 거꾸로 위치시킨 역트리(inverted tree) 구조로 계층적으로 구성되어 있다. 루트도메인 바로 아래의 단계를 1단계 도메인 또는 최상위 도메인(TLD, Top Level Domain)라고 부르며, 그 다음 단계를 2단계 도메인(SLD, Second Level Domain)이라 부른다.

위의 그림에서 보면 알 수 있듯이 도메인이름이란 특정 도메인의 위치를 나타내기 위한 경로를 말한다. 이제는 도메인 체계에 대해서 대충 감이 잡힐 것이다.
그럼 이제 네임서버의 역할이 무엇인지 알아보자. 현재 우리가 사용하는 인터넷 서비스는 숫자로된 IP주소와 영문자로 된 도메인이름이 있다. 하지만 컴퓨터가 이해하는 IP주소는 사람이 기억하기 어렵기 때문에 사람이 이해하기 쉬운 도메인이름을 사용하게 되었다. 따라서 이러한 도메인이름을 사용하기위해 도메인이름을 컴퓨터가 이해할 수 있는 IP주소로 변환해주는 과정이 필요하게 되는 것이다. 이렇게 도메인이름을 IP주소로 바꾸어주는 것을 도메인 네임서비스라고 하며, 이러한 역할을 해주는 것을 네임서버라고 한다.

+Bind 9설치(Source 설치)
네임서버에 관해서 어느정도 감이 잡힐 것이다. 이제 네임서버 운영을 위한 Bind를 설치해 보자. 설치는 리눅스에서 RPM방식과 Source설치 두가지 방식으로 진행을 할 것이다. 물론 Bind 9버전은 윈도 플렛폼용도 있다. 하지만 윈도에서 Bind설치하는 사람이 별로 없을 것 같아서 여기서 설명하지는 않겠다.
이제 Bind 9의 소스를 구해보자 Bind 9의 소스는 http://isc.org/products/BIND에서 구할 수 있다. 최신 버전인 Bind 9.2.2버전을 다운 받아 보자. 다운받은 소스화일을 적당한 디렉토리에서 압축을 해제 한다.
[root@localhost]#

[root@localhost]# tar xvfz bind-9.2.2.tar.gz
[root@localhost]# cd bind-9.2.2
소스 설치라고 어려워 할 것없다. 무지 간단하다. 만약 자신이 없다면, RPM설치를 권장한다. 압축을 해제 했으면 이제 설치를 해보자.
- 주의사항 -
1. 설치전에 OpenSSL을 업그래이드 시켜 준다. 필자는 레드헷 7.3에서 설치하다 OpenSSL에러가 나서 up2date로 업그래이드 시켜 줬다. 아래와 같은 에러나 나면서 0.9.6e이상 버전을 요구하는데 그냥 up2date로 업그래이드 시켜 줬더니 openssl-0.9.6b-32.7버전으로 교체 되면서 이상없이 설치가 되었다.
configure: error: you need OpenSSL 0.9.6e/0.9.7-beta2 (or newer): CERT CA-2002-23
[root@localhost]#
[root@localhost]# up2date openssl
설치전에 rhn에 등록이 되어있어야 된다.

2. configure전에 소스화일에서 pid폴더를 변경해줘야 된다. 디폴트로 /var/run/named.pid이나 퍼미션 에러로 생성이 안된다. /var/run/named/named.pid로 변경해주자.
[root@localhost]#
[root@localhost]# vi bin/named/include/named/globals.h
run/named.pid/ -> /run/named/named.pid
run/lwresd.pid -> /run/named/lwresd.pid
위의 설정을 다 끝마쳤으면 이제 Bind를 설치해 보자. 아래는 configure옵션이다. 필자는 아래와 같은 옵션으로 설치했지만, 거의 디폴트로 설정이 되어있기 때문에 그냥 옵션없이 configure만 해도 상관이 없다. 특별한 이유가 없다면 아래의 설정으로 설치하기를 권장한다.
[root@localhost]#
[root@localhost]# ./configure --prefix=/usr/local/bind --sysconfdir=/etc --localstatedir=/var --mandir=/usr/share/man --with-openssl --with-libtool --disable-ipv6
[root@localhost]# make; make install
설치는 위의 과정만으로 Bind 9의 설치는 끝이 났다. 이제 네임서버 운영을 위한 설정을 해보자. 처음부터 도메인 셋팅하고 할려면 에러나면 힘이 든다. 우리는 단순히 caching역활을 하는 설정을 먼저 해보고 도메인 셋팅을 해보도록 하자.

caching nameserver란 단순히 사용자들의 쿼리에 대한 답변만 보내 주는 서버이다. 다행이도 caching역활에 필요한 설정화일들이 rpm으로 패키징 되어있다. 필자는 그냥 rpm패키징화일을 사용하기로 했다. 물론 직접 작성해서 사용해도 상관은 없다.

RPM으로 설치 하려면 아래와 같이 입력하면 된다. 설치시 의존성에 걸리기 때문에 --nodeps옵션으로 설치한다. caching-nameserver-7.2-1.noarch.rpm설치시 caching역활에 필요한 기본 파일들이 설치가 된다. /var/named의 내용들과 /etc/named.conf화일들이다. 위의 파일들은 직접 작성해도 작동하는데 크게 무리 없다.
[root@localhost]#
[root@localhost]# rpm -Uvh --nodeps ftp://rpmfind.net/linux/redhat/7.3/en/os/i386/RedHat/RPMS/caching-nameserver-7.2-1.noarch.rpm
이제 dnssec-key를 생성해 보자. bind 9의 가장 큰 변화는 dnssec-key를 이용한 인증과 업데이트이다. dnssec-key에 관한 내용은 뒤에서 애기하겠다. 일단 cashing역활을 위해 기본 설정만 해보자.
[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;
};

위의 내용중에 key부분을 복사해서 입력한다.
[root@localhost]# vi /etc/rndc.key
key "rndc-key" {
       algorithm hmac-md5;
       secret "PSYc3s2THUqOK8qV65Jm9w==";
};

굵은 글씨로 표시된 rndc-key부분은 사용자 설정으로 변경을 해도 상관은 없으나 아래 파일에서
도 변경을 해줘야 된다. key부분의 secret는 생성할 때마나 랜덤하게 암호화 되어 변경이 된다.
[root@localhost]# vi /etc/named.conf
controls {
       inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};
이제 Bind 9의 운영을 위한 유저와 소유권 설정을 해주자. Bind 9는 named계정으로 동작이 되기 때문에 설정화일들에 대한 소유권 조정이 필요하다. 먼저 유저를 생성해주자.
[root@localhost]#
[root@localhost]# useradd -s /bin/false -d /var/named named
유저 생성이 완료 되었다면 설정화일들의 소유권과 퍼미션을 조정해보자. Bind 9를 named계정으로 운영을 함으로 named계정에 최하 읽기 권한이 있어야 운영을 할 수 있다. 아래와 같이 설정화일들의 소유권과 퍼미션을 변경해 주자.
[root@localhost]#
[root@localhost]# chmod 640 rndc.key
[root@localhost]# chmod 640 rndc.conf
[root@localhost]# chmod 640 named.conf
[root@localhost]# chown root.named rndc.key
[root@localhost]# chown root.named rndc.conf
[root@localhost]# chown root.named named.conf
[root@localhost]# chmod 700 /var/named
[root@localhost]# chmod 600 /var/named/*
[root@localhost]# chown named.named /var/named
[root@localhost]# mkdir /var/run/named
[root@localhost]# chown named.named /var/run/named
이제 cashing역활을 할 수 있는 서버 설정이 끝이 났다. 이제 named데몬을 시작시킬 수 있는 스크립트를 만들어 보자. 필자는 named데몬을 시작시키는 스크립트를 Bind 9 RPM버전에 있는 스크립트를 수정해서 사용하였다. 아래 링크에서 받아서 사용하면 된다.
Bind 9 구동 스크립트 : named
다운 받은 스크립트를 /etc/rc.d/init.d에 복사해놓고 실행 권한을 준다음에 경로 설정만 해주면 된다.
[root@localhost]#
[root@localhost]# cp named /etc/rc.d/init.d
[root@localhost]# chmod +x /etc/rc.d/init.d/named
[root@localhost]# touch /etc/sysconfig/named
[root@localhost]# ln -s /usr/local/bind/sbin/named
/usr/sbin/named
시작 스크립트의 수정이 끝나면 이제 서버 시작시 자동으로 시작이 되도록 설정을 해준다. 아래와 같이 설정시 Level 3과 Level5일 경우 자동적으로 시작이 된다.
[root@localhost]#
[root@localhost]# chkconfig --add named
[root@localhost]# chkconfig --level 3 named on
[root@localhost]# ntsysv
[*]named 체크 확인
[root@localhost]# ln -s /etc/rc.d/init.d/named /etc/rc.d/rc3.d/S55named
[root@localhost]# ln -s /etc/rc.d/init.d/named /etc/rc.d/rc3.d/K44named
자 이제 네임서버의 설정이 모두 끝이 났다 이제 Bind 9를 시작시켜 보자.
[root@localhost]#
[root@localhost]# /etc/rc.d/init.d/named start (MySQL시작)
[root@localhost]# ps -ef | grep named (MySQL데몬 확인)
[root@localhost]# /etc/rc.d/init.d/mysqld named (MySQL 종료)
Bind 9가 이상없이 실행이 되는가? 실행이 된다면 아래 2개의 포트가 열려 있어야 된다.
[root@localhost]#
[root@localhost]# nmap localhost
53/tcp          open          domain
953/tcp          open          rndc
여기까지 이상없이 진행이 되었다면 우리가 설치한 Bind 9는 caching역활을 할 수 있다. 이제 도메인은 설정하고 운영하는 방법에 대해서 알아보자.

+Bind 9설치(RPM 설치)
Bind 9를 RPM패키지로 설치해 보자. Source설치에 비해서 간단방식의 RPM설치지만 지원 플랫폼이 제한되어 있어서 필자는 많이 사용하지는 않는다. 하지만 리눅스 플랫폼이라면 RPM설치를 적극 추천이다.
RPM 설치 방법 #1(up2date를 이용)
[root@localhost]#
[root@localhost]# up2date -u bind-utils
[root@localhost]# up2date -u bind
[root@localhost]# up2date -u caching-nameserver
RPM 설치 방법 #2(RPM패키지 이용)
[root@localhost]#
[root@localhost]# rpm -Uvh ftp://rpmfind.net/linux/redhat/updates/7.3/en/os/i386
/bind-utils-9.2.1-1.7x.2.i386.rpm
[root@localhost]# rpm -Uvh ftp://rpmfind.net/linux/redhat/updates/7.3/en/os/i386
/bind-9.2.1-1.7x.2.i386.rpm
[root@localhost]# rpm -Uvh ftp://rpmfind.net/linux/redhat/7.3/en/os/i386/RedHat
/RPMS/caching-nameserver-7.2-1.noarch.rpm
rpm패키지는 레드햇 원본 시디나, http://rpmfind.net에서 구할 수 있다. 설치 순서를 지켜줘야 된다. rpm설치시 의존성에 걸리기 때문에 위의 과정대로 설치해 준다. rpm설치는 Source설치에 비해서 설치가 쉽고 관리하기에 편리하다.
rpm패키지로 설치하면 설치가 끝나고 바로 caching역활의 서비스를 할 수 있다. Bind 9를 실행시켜 보자.
[root@localhost]#
[root@localhost]# /etc/rc.d/init.d/named start
[root@localhost]# nmap localhost
53/tcp          open          domain
953/tcp          open          rndc
이제 설치에 관련된 부분은 모두 끝이 났다 사용자가 생각하기에 편한쪽으로 선택해서 사용하면 된다. 지금부터는 설정과 테스트에 관해서 다룰 것이다.

+Caching Name Server 테스트
Bind 9를 설치했으니 이제 테스트를 해보자. 단순히 caching역활을 제대로 해내는지 테스트를 해보자.
C:\windows\system32\cmd.exe
C:\>nslookup
Default Server:  kns.kornet.net
Address:  168.126.63.1
> server 192.168.0.10 <-- Bind 9가 설치된 네임서버 IP
Default Server:  [192.168.0.10]
Address:  192.168.0.10
> yahoo.co.kr
Server:  [192.168.0.10]
Address:  192.168.0.10
Non-authoritative answer:
Name:    yahoo.co.kr
Address:  211.32.119.151
> korea.com
Server:  [192.168.0.10]
Address:  192.168.0.10
Non-authoritative answer:
Name:    korea.com
Address:  211.109.6.235
위의 내용에서 우리는 nslookup도구를 가지고 네임서버에 질의를 해보았다. 네임서버를 Bind 9가 설치된 IP로 변경을 하고 yahoo.co.kr을 보냈더니 네임서버는 211.32.119.151의 결과를 보내 주었다. 이것은 우리가 브라우저에 yahoo.co.kr을 치면 211.32.119.151번의 IP를 찾아 가라는 말이다. 어떻게 해서 찾아 가는지는 설정화일에 나온다. 만약 네임서버가 설정이 잘못되었다면 아래와 같은 결과를 얻게 될 것이다.
C:\windows\system32\cmd.exe
C:\>nslookup
Default Server:  kns.kornet.net
Address:  168.126.63.1
> server 192.168.0.10 <-- Bind 9가 설치된 네임서버 IP
Default Server:  [192.168.0.10]
Address:  192.168.0.10
>
> yahoo.co.kr
Server:  [192.168.0.10]
Address:  192.168.0.10
*** [192.168.0.10] can't find yahoo.co.kr: No response from server  
위와 같이 나올 경우 앞장의 설치문서를 참고하여 다시 설정해 보기 바란다.

+설정 화일
앞서 Source설치와 RPM설치에 관해 다뤄봤다. 이제 Bind 9를 운영하는데 필요한 설정화일들에 대해서 알아보자. caching-nameserver패키지를 설치했다면 운영에 필요한 기본 파일들은 모두 설치가 되어있다. 필자는 간단하게 caching-nameserver패키지에 설정 되어있는 상태를 기본으로 설명하겠다. 아래는 Bind 9를 운영시 꼭 필요한 파일들이다.
/etc/named.conf
/etc/rndc.conf
/etc/rndc.key
/var/named/*.zone
/var/named/named.local
/var/named/named.ca
위의 파일들은 최하 named계정이 읽을 수 있는 권한이 있어야 된다. 이제 하나하나 알아보자.
/etc/named.conf: Bind 9를 실행시에 가장 먼저 참조 되는 파일이다. 네임서버의 기본적인 정보들이 설정되어 있으며, 세부적인 설정들도 지정할 수 있다.
/etc/rndc.conf: rndc를 사용하기 위한 설정 파일이다. 보안상 최소 권한만 부여한다.
/etc/rndc.key : rndc를 사용하는데 필요한 key가 들어있다. 보안상 최소의 권한만 부여한다.
/var/named/*.zone: 네임서버 운영에 필요한 zone화일들이다. 디폴트로 /var/named로 설정이 되어있으나 변경 가능하다. 변경시 /etc/named.conf의 directory지시자에서 변경한 폴더를 지정해 주면 된다.
/var/named/named.local : Local Roopback IP의 reverse mapping을 정의하는 파일이다. 쉽게 IP --> 도메인으로 변경해주는 화일이다.
/var/named/named.ca : 최상위 루트 도메인 서버들이 정의 되어있는 파일이다. 루트 도메인 서버는 세계 각지에 흩어져 있으며 총 14대가 존재한다. 현재 대한민국에 미러서버를 추진중이다. 거의 수정할 필요는 없지만 적어도 1달에 한번은 업데이트 해주는 것이 좋다. 아주 가끔 변경되기도 한다. 2002년경에는 베리사인에서 관리하는 J루트 서버 IP가 변경된적이 있다.

+도메인 셋팅 #1
이제 실제적으로 Bind 9를 이용한 도메인 서비스를 해보자. 셋팅전에 우리는 네임서버가 어떻게 도메인을 IP로 바꿔주는지 알아야 된다. 간단히 알아보고 넘어가자.
필자는 nasord.com이란 도메인을 가지고 있다. 도메인 등록시 네임서버를 ns.rootline.com으로 등록을 해두었다. 그럼 이제 필자의 컴퓨터에서 nasord.com을 입력하면 필자의 컴퓨터에 설정되어있는 네임서버에 먼저 질의를 한다. 그럼 네임서버에서 닷컴 도메인을 관리하는 최상위 루트서버에 질의를 하고 최상위 루트서버에서는 ns.rootline.com으로 가라고 알려준다. 그럼 ns.rootline.com에서는 설정되어있는 nasord.com의 IP를 필자의 컴퓨터에 가르쳐 준다.
위의 결과로 필자는 nasord.com의 IP를 받아왔다. 하지만 위의 설정전에 먼저 읽어 들이는 파일이 있다. 윈도계열의 컴퓨터의 경우 WINNT\System21\Drivers\etc폴더의 hosts(리눅스 : /etc/hosts)화일을 먼저 참조한다. 만약 hosts화일에 nasord.com의 IP가 미리 설정이 되어있다면 필자의 서버는 네임서버에 질의를 하지 않을 것이다. hosts화일 다음에 참조하는 것이 컴퓨터의 메모리에 남아있는 캐시이다. 도스창에서 아래와 같이 입력해 보기 바란다.
C:\windows\system32\cmd.exe
C:\>ipconfig /displaydns
C:\>ipconfig /flushdns <-- 캐시 삭제
위와 같이 입력하면 현재 컴퓨터에 남아있는 캐시들이 보일 것이다. 종합해보면 컴퓨터에서 질의를 보낼 경우 가장먼저 hosts화일을 참조하고 다음으로 캐시를 참조한다. 만약 둘다 없다면 컴퓨터에 셋팅되어있는 네임서버에 질의를 하게 된다. 위의 내용들은 실무에서 아주 중요하게 사용이 된다. 네임서버에서 변경을 해도 가끔식 적용이 안될 때가 있는데 위의 경우처럼 찾아보면 쉽게 해결할 수 있다.

+도메인 셋팅 #2
이제 Bind 9를 이용하여 실제로 도메인서버를 운영해보자. 도메인을 설정하기 위해서는 named.conf화일과 zone화일이 필요하다. 연습용으로 nasord.com이란 도메인을 설정해 보겠다. 필자가 Bind 9가 구동될 때 가장 먼조 참조하는 파일이 named.conf화일이라고 했다. named.conf화일에는 규칙이 있으며, 규칙에 따라서 편집을 해줘야 된다.
[root@localhost]#
[root@localhost]# vi /etc/named.conf
zone "nasord.com" IN {
       type master;
       file "nasord.com.zone";
       allow-update { key "rndc-key"; };
};
위와 같이 named.conf화일에 추가를 해주자. 들여쓰기를 할 때는 꼭 탭키를 사용하기 바란다. 위의 내용은 nasord.com이라는 도메인을 master로 설정하고 nasord.com.zone이란 zone화일을 사용하겠다는 의미이다. allow-update는 뒤에 다룰 동적 업데이트를 위한 설정이다. allow-update내용에서 key부분은 rndc.conf에서 정의되어있는 key가 입력되야 된다.
이제 nasord.com.zone화일을 편집해 보자.
[root@localhost]#
[root@localhost]# vi /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  
 
www        IN        CNAME        @

위와 같이 zone화일을 생성해 보자. zone화일은 크게 두 개의 영역으로 구분이 된다. SOA(Start Of Authority)영역과 데이터 영역으로 구분한다. 이제 세부적으로 살펴보자 먼저 SOA영역 먼저 살펴보자.
[root@localhost]#
$TTL 86400
@        IN      SOA     ns.nasord.com. admin.nasord.com. (  
                                     2003081301 ; serial
                                     28800      ; refresh
                                     7200       ; retry
                                     604800     ; expire
                                     86400      ; ttl
                                     )
$TTL 86400 : zone정보의 ttl값으로 지정된 시간이 지나면 캐시에서 삭제 된다. 기본적으로 86400초 1일이다.
골뱅이 : ORIGIN을 뜻하며, 도메인 자기 자신을 나타낸다.
ns.nasord.com. : 도메인의 네임서버를 지정한다.
admin.nasord.com. : 도메인의 관리자 메일을 지정한다. 입력시 오리곤을 쓰는 일이 없도록 한다. 점으로 구분해야 된다.
2003081301 ; serial : 도메인의 업데이트 유무를 나타내는 시리얼 값이다. 보통 YYYYMMDDHH의 형식으로 입력한다. 만약 zone화일의 정보가 변경이 되었다면 꼭 증가 시켜 줘야 된다. 그래야 보조 네임서버에서 변경 유무를 확인할 수 있다.
28800 ; refresh : 마스터 네임서버로부터 데이타를 가져온 후 다시 업데이트 하기 위해 접속 시도를 할 때까지 기다리는 시간을 지정한다.기본값은 8시간이다.
7200 ; retry : 마스터 네임서버에 접속이 실패했을 경우 지정된 시간이 지나면 재접속을 한다.
604800 ; expire : 마스터 네임서버에서 받아온 도메인의 정보들은 보관하는 주기이다. 지정된 시간이 지나면 받아온 데이터가 신뢰성이 없다고 판단하고 삭제한다. 기본값은 7일이다.
86400 ; ttl : 캐시된 도메인의 정보들을 보관하는 시간이다. 네임서버는 질의를 던질 때 마다 일일이 물어보는 것이 아니고 한번 질의된 정보는 ttl에 지정 되어있는 시간동안 보관하게 된다. 좀더 빠른 서비스를 위해서 보관하고 있는데, 기본값을 사용하면 된다. 만약 서비스 이전계획이라면, 미리 ttl값은 짧게 잡아서 캐시를 빨리 삭제 해주는 것이 좋다.
이제 실제 도메인의 데이터가 들어가는 부분을 살펴 보자.
[root@localhost]#
       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  
 
www        IN        CNAME        @
위의 예제는 간단해 보이지만 처음 설정하는 것이라면 가장 실수가 많은 곳이다. 데이터 부분을 설정하기 전에 먼저 레코드 타입에 대해서 설명하겠다. 위에 보면 NS, MX, A, CNAME 이런 것들이 보일 것이다. 복잡하게 생각하면 복잡하기만 하니까 간단히 설명하겠다.
NS 레코드 : NS 레코드는 도메인의 네임서버를 지정한다. 예제로 보면 위에 ns.nasord.com.이렇게 뒤에 점을 붙였다. 꼭 붙여야 된다. 왜 그런지는 안붙이고 질의를 해보면 알 수 있을 것이다. NS 레코드는 위임도 가능하다.
[root@localhost]#
ns.kr.nasord.com        IN        A        192.168.0.11
kr.nasord.com                IN        NS        ns.kr.nasord.com.
위의 예제에서 보면 ns.kr.nasord.com이란 호스트에 192.168.0.11의 IP를 할당하고, kr.nasord.com의 네임서버를 ns.kr.nasord.com으로 설정했다. 그러면 앞으로는 우리가 kr.nasord.com을 찾을 때는 192.168.0.11에서 질의를 수행하게 된다. 이런식으로 하면, 한 개의 도메인을 가지고 2차, 3차 호스트를 만들어서 사용할 수 있다.
MX 레코드 : MX 레코드는 Mail Exchange의 약자로 메일서버를 지정하면 된다. 필자는 단독 메일서버로 설정해서 nasord.com으로 오는 메일을 192.168.0.15로 보내도록 설정했다. MX 레코드는 여러개를 지정해서 보조 메일서버도 설정할 수 있다.
[root@localhost]#
       IN        MX        10        mail.
       IN        MX        20        mail2.

mail        IN        A        192.168.0.15  
mail2        IN        A        192.168.0.16
위의 설정에서 필자는 2개의 MX 레코드를 생성했다. mail과 mail2이다 각각의 호스트는 15번과 16번 IP로 설정이 되어있다. 위의 경우 MX 레코드 뒤에 있는 숫자 10과 20의 설정에 따라서 메일을 받는 우선순위가 부여된다. 낮은 숫자의 호스트가 먼저 메일을 받는다. 만약 mail호스트가 다운이 되서 메일을 받지 못한다면 메일은 mail2호스트로 건너가서 queuing상태에 있다가 mail호스트가 살아나면 다시 메일을 보내준다. 이런 설정일 경우 메일서버 한 개가 다운이 되어도 메일을 잃어 버릴 염려가 없다.
A 레코드 : A 레코드는 실제로 호스트에 IP를 부여하는 역할을 한다. 필자는 기본적으로 4개의 호스트를 설정했다. @, NS호스트. mail호스트, ftp호스트이다. A 레코드를 추가해줄 때마다 도메인에 서브 호스트가 생성이 된다. A 레코드를 잘 사용하면 호스트 분산역활도 할 수 있다. 예제로 필자는 웹서버가 4대가 있다. 하지만 L4스위치는 가격이 비싸다. 이럴 경우 Bind를 이용해서 저렴하게 분산 호스트를 구성할 수 있다.
[root@localhost]#
www        IN        A        192.168.0.20  
       IN        A        192.168.0.21  
       IN        A        192.168.0.22
       IN        A        192.168.0.23
위의 예제에서 필자는 한 개의 A레코드에 4개의 IP를 할당하였다. 그럼 클라이언트에서 질의를 던지면 네임서버는 www호스트에 대해서 20~23번까의 IP중에서 한 개식 한 개식 분산시켜서 IP를 가르쳐 준다. 위의 방식을 Round Robbin이라고 하며, 종종 사용할 때가 있을 것이다. microsoft.com의 웹서버와 cnn.com의 웹서버가 위의 방식으로 운영이 되고 있다. L4에 비해서 설정이 쉽고 소요 비용이 적기 때문에 종종 사용한다.
CNAME : CNAME는 별칭이다. 각각의 호스트에 모두 A 레코드로 설정을 해줄 경우, 쉽게 예를 들어서 서브 호스트가 1000개가 있다고 설정해보자 각각의 호스트는 모두 같은 IP인데 네트워크의 변화로 IP가 변경이 되었다고 생각해보자. 이럴 경우 모든 호스트를 A 레코드로 설정를 했다면 모든 호스트에 IP의 변화가 필요할 것이다. 하지만 CNAME를 이용하면 CNAME에 해당되는 한 개의 호스트만 IP를 변경해주면 된다. CNAME를 사용하나 A 레코드를 사용하나 결과는 같지만, 관리적인 측면에서 적절한 CNAME의 사용을 권장한다.

Bind 9를 이용한 주네임서버와 보조 네임서버 구축 #2
inverse domain 설정
이제 인버스 도메인을 설정해 보자. 인버스 도메인이란 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의 시작과 종료에 대해서 알아보자. 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상태와 데몬의 현재 상태등 다양한 것들을 보여준다.

Bind 9의 고급옵션과 기능 #1
지금 까지의 설명은 초급 사용자들이 쉽게 사용할 수 있도록 기본적인 설명위주로 진행을 했다. 지금부터는 네임서버를 운영하는데 있어서 좀더 고급옵션과 보안에 중점을 두어서 설명하고자 한다. 먼저 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와 네트워크의 구성형태등의 중요한 내부 정보가 유출될 수 있다. 그러므로 보조 네임서버를 제외하고는 모두 막아 두는 것이 좋다.

+Bind 9의 고급옵션과 기능 #2
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사용자에게 읽기 권한이 있어야 된다. 보안상 외부사용자에게 유출되면 안되니, 최소의 권한만으로 운영하기 바란다.

+Cache화일 생성하기
거의 손댈일이 없는 부분이다. 하지만 가끔식 변경하기도 하니까, 최소 한달에 한번식만 업데이트 해주기 바란다. 업데이트는 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
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이란 네임서버에 질의를 던져서 결과를 얻어 내는 도구이다. 거의 모든 운영체계에 기본적으로 설치가 되어있다. 네임서버 운영시에 가장 많이 사용되는 도구이다. 이제 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 에러 메시지
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설치도 처음 해봤다. 부족한 부분이 많이 있고, 강좌의 진행도 어수선 하지만 나름대로 열심히 정리를 해봤다. 강좌를 작성하는데 자그마치 일주일이 걸렸다. 작성하면서 많은 부분들이 빠졌지만, 빠진 부분은 나름대로 시간을 내서 다시 정리하겠다. 강좌의 내용중 오타와 틀린부분이 있다면 메일이나 게시판을 이용하기 바란다.

위와 같이 설정을 했습니다...
헌데... 도메인 접속이 안됩니다...
대신 네임서버로 접속을 하면...접속이 되구요...
이건 리눅스 서버에서 resolving이 안되는건가요... 간단하세 제가 세팅한거 올려 봅니다...

이건 /etc/host 입니다
127.0.0.1 localhost.localdomain localhost
xxx 아이피 동일입니다.
218.150.166.xxx ns1.lliill.net ns1
218.150.166.xxx lliill.net www


이건 name.conf 수정부분 입니다..
zone "lliill.net" IN {
type master;
file "lliill.net.zone";
allow-update { key "rndc-key"; };
};

zone "166.150.218.in-addr.arpa" IN {
type master;
file "lliill.net.rev";
allow-update { none;};
};

이건 zone file 입니다
뒤의 아이피는 모두 동일 합니다...

$TTL 86400
@ IN SOA ns1.lliill.net. root.lliill.net. (
2004062801 ;Serial
28800 ;Refresh
7200 ;Retry
604800 ;Expire
86400 ) ;Minium
;
;Name Server
IN NS ns1.lliill.net.
IN MX 10 mail.

@ IN A 218.150.166.xxx
ns1 IN A 218.150.166.xxx
mail IN A 218.150.166.xxx

www IN CNAME @

이건 rev 파일 입니다.
$TTL 86400
@ IN SOA ns1.lliill.net. root.lliill.net. (
2006062801 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS ns1.lliill.net.
; IN MX 10 mail.lliill.net.
;
xxx IN PTR ns1.lliill.net.
xxx IN PTR lliill.net.
[수정] [ 이글에 답장 | 본문에 답장 | 책갈피 ]
설정은 이상이 없는것 같네요.. nslookup으로 테스트를 한번 해보세요

nslookup
> server 218.150.166.xxx
> lliill.net.

설정안 DNS서버에서 nslookup으로 쿼리를 시도했을때 정상적으로 결과가 나오면 설정에는 이상이 없습니다.

> server 168.126.63.1
> lliill.net.

이상이 없으면 일단 코넷쪽 네임서버로 외부에서 인식이 되는지 테스트를 해봅니다. 여기서 이상이 있다면 도메인 등록기관에서 네임서버 등록이 제대로 되어있나 확인해 보시기 바랍니다.
조회 결과가 이상이 없다면 네임서버 캐시 전파기간동안 대기하시면 됩니다. 보통 .kr도메인은 하루 3회 .net .com같은 경우 길면 3일정도 소요 되는것 같습니다.
도메인 등록정보에서 아래와 같이 자신이 설정한 네임서버가 등록되어 있으면 됩니다.

1차 네임서버 정보
호스트이름 : ns.lliill.net
IP 주소 : 192.168.0.1

2차 네임서버 정보
호스트이름 : ns2.lliill.net
IP 주소 : 192.168.0.2