12. Bind Refresh
Hanterm |
[root@bbuwoo named]$ ps ax | grep named
224 ? S 0:12 named
4444 p0 S 0:00 grep named
[root@bbuwoo named]# cat /var/run/named.pid
224
[root@bbuwoo named]# kill -HUP 224 <- HUP는 꼭 대문자여야 한다.
[root@bbuwoo named]#
|
위의 과정은 전통적으로 process 를 refresh 시키는 방법을 보여준다. 하지만 bind 9 에서 부터
는 ISC 권장 사항으로 위의 방법을 사용하지 말 것을 요구하고 있다. (물론 9.1 대의 몇몇 버젼
을 제외하고는 현재 최신 버젼에서는 위의 방법으로도 되기는 한다.)
ISC 의 권장 사항으로는 rndc 를 이용한 refresh 를 권장하고 있으며 사용법은 다음과 같다.
/usr/sbin/rndc -p 953 reload
-p 옵션 값은 /etc/named.conf 의 controls 블럭에서 port 를 기본값 953 에서 변경했다면, 변경
된 값을 사용해야 한다.
원격에서 rndc 를 이용하여 네임서버를 refresh 할 때는 다음의 과정을 거쳐야 한다. 일단 네임
서버의 rndc.conf 에 설정이 되어있는 key block을 원격지의 /etc/rndc.conf 에 설정을 한다. 다
음 아래의 명령을 실행한다.
/usr/sbin/rndc -s 210.24.154.2 -p 953 -y oops-key reload
물론 원격지에서 refresh 를 하기 위해서는 /etc/named.conf 의 contols block 에서 접근 및 권한
설정이 되어 있어야 한다.
주의할 것은, nsupdate 를 이용한 dynamic update 를 이용하려면 bind 의 시작과 refresh 는 무조
건 rndc 를 통해서 해야 한다. 그래야만 변경된 값을 bind 종료 시에 zone 파일에 기록을 할 수가
있다. 아주 중요한 요소이다. rndc 를 통한 종료는 reload 대신에 stop 을 사용하면 된다.
named 의 구동은 아래와 같다.
Hanterm |
[root@bbuwoo named]$ /sbin/named -u named
[root@bbuwoo named]#
|
위의 -u option 은 8.2 부터 추가되어진 옵션으로, named 를 named 라는 유저의 권한으로 실행을
하라는 의미이다. bind 의 process 가 root 의 권한으로 작동을 하고 있다보니 BOF 와 같은 공격
에 너무나 취약하게 root 의 권한을 빼앗기는 것을 방지하기 위해서 위의 옵션이 추가 되었다.
여기서 강조하고픈 바는 BIND 9에서의 변화이다. 즉 BIND 8 까지는 위와 같이 named 를 시작하면
되지만 BIND 9 부터는 kernel 버젼이 2.33.99pre2 이상일 경우에만 -u 옵션을 사용을 할 수 있다
는 것을 명심을 하도록 한다. 즉 kernel 2.4 이하 버젼인 사람들은 BIND 8 을 사용하라는 의미이
다. (그렇다고 해서 BIND 8 이 BIND 9 보다 기능이 떨어진다는 의미는 아니다. 오히려 BIND 9 가
BIND 8 의 기능을 모두 다 지원을 못해주고 있다. 현재 필자 역시 아직까지 BIND 8 을 사용하고
있다.)
13. nslookup
사용법
설정이 제대로 되었나 확인하는 방법으로는 nslookup을 이용할 수가 있다. name server 의 설정
을 가장 확실하게 알 수 있는 방법일 것이다. 설정의 확인은 간단하게
nslookup '설정한 domain name'
의 형식으로 몇개를 찾아 보면 쉽게 알 수 있을 것이고 여기서는 간단하게 nslookup 의 기본적인
사용법을 알아 보도록 하겠다.
nslookup oops.org
가장 기본적인 사용법이다. 저 도메인명의 IP 주소를 찾는 것이다. 또는 저기에 IP 주소를 넣는
다면 해당하는 도메인명을 불러 줄 것이다.
BIND 9 에 포함되어 있는 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.
이 메세지는 에러 메세지가 아니라, nslookup 은 향후에 없어질 것이다. 그러므로 nslookup 대신
에 dig 나 host 명령을 사용하는 것을 고려 하라는 뜻이다. 그리고 이 메세지를 보지 않으려면
nslookup -sil 로 실행을 하라는 내용이다.
dig 나 host 명령은 man dig 또는 man host 로 알아보기를 바란다. 여기서는 nslookup 만 논한다.
이제는 그냥 nslookup -sil 만으로 실행 해보자.
Hanterm |
[root@bbuwoo named]$ nslookup -sil
>
|
그냥 nslookup -sil 만 실행을 하면 위처럼 프롬프트 하나만 뜰 것이다. 애석하게도 BIND 8 보다
기능이 상당히 떨어진다. 또한 help 명령도 없다. 각설하고 프롬프트 모드로 들어오면 다양한 방
법 으로 질문을 할 수가 있다. query type 을 정해 줄 수 있는데 그 도메인의 네임 서버를 알고
싶 다면 이런식으로 할 수 있을 것이다.
Hanterm |
[root@bbuwoo named]$ nslookup -sil
> set query=ns
> oops.org
Server: 10.0.0.1
Address: 10.0.0.1#53
Non-authoritative answer:
oops.org nameserver = ns.oops.org.
Authoritative answers can be found from:
ns.oops.org internet address = 210.24.154.2
|
아주 간단하다. qwery type 은 IN class 에서 사용하는 RECORD 는 모두 지정할 수 있다. 그리고
set query=any 는 모든 사항에 대한 정보를 보는것이다. 그리고 애석하게도 BIND 9 의 nslookup
에서는 ls 명령도 안된다. 역시 삐리하다. :-)
14. Name Server Error Debugging
많은 사람들이 name server 설정에 대한 자세한 이해없이 설정만 하고선 안된다는 질문이 많아서
이런 글을 추가한다. Name Server 의 설정이 제대로 되었는지, 또는 적용이 안되는 경우는 2가지
의 이유가 있다. 보통 설정 자체의 에러가 있거나 또는 DNS 이전 또는 primary name server의 변
경 등의 이유가 있으며 가끔 외부의 network 상의 문제로 인하여 일시적으로 마비가 되는 경우가
있다. 보통 첫번째 문제 즉, 설정 자체의 문제가 아니라면 시간이 해결해 주기를 바라는 수 밖에
없다.
일단 debugging 을 하는 첫번째 방법으로는 내 설정에 문제가 있는지 부터 확인을 한다. 즉 디버
깅의 순서는 보통 내부에서 문제를 찾아보고 없으면 외부의 방향으로 나가는 것이 관례이다.
일단 창을 2 개를 이용을 하도록 한다. 창을 2 개를 띄어 놓고선 하나의 창에는
tail -f /var/log/messages
를 실행하도록 한다. tail 은 file 의 제일 마지막 몇줄을 보여 주는 것으로 -f 옵션을 사용하면
추가되는 기록을 계속 볼 수가 있다. 그리고, 다른 한창에서는 named 를 재시작 하도록 한다. 그
러면 named 가 시작 되면서 named.conf 와 zone file 들을 읽어 올 것이며 여기서 에러가 발생할
경우 tail -f /var/log/messages에서 에러에 대한 문구를 볼수 있을 것이다. 보통 messages file
에는 어느 파일 몇 번째 줄에서 에러가 있다고 명확하게 보여 주므로 해당 라인에 문법적 에러가
있는지 강좌 같은 것을 자세히 보면서 수정을 해 보면 된다.
일단 다른 한 창에서 named 를 재시작하면 tail -f 를 실행한 창에서는 아래와 같은 로그들이 나
타날 것이다.
Hanterm - tail -f /var/log/messages |
[root@bbuwoo named]$ tail -f /var/log/messages
Feb 25 18:57:11 oops named[431]: named shutting down
named 를 내릴 준비를 시작한다.
Feb 25 18:57:11 oops named[431]: USAGE 983095031 982820410 CPU=10.05u/5.43s
CHILDCPU=0u/0s
Feb 25 18:57:11 oops named[431]: NSTATS 983095031 982820410 A=5087 NS=2 CNAME=3
PTR=56903 MX=144 AAAA=1 AXFR=2 ANY=752
Feb 25 18:57:11 oops named[431]: XSTATS 983095031 982820410 RR=7894 RNXD=2196
RFwdR=4122 RDupR=4 RFail=499 RFErr=0 RErr=0
RAXFR=2 RLame=1740 ROpts=0 SSysQ=945 SAns=60899
SFwdQ=5026 SDupQ=3610 SErr=0 RQ=62914 RIQ=0
RFwdQ=5026 RDupQ=56 RTCP=2 SFwdR=4122 SFail=75
SFErr=0 SNaAns=10427 SNXD=44277 RUQ=0
RURQ=0 RUXFR=2 RUUpd=0
Feb 25 18:57:11 oops named: named shutdown succeeded
named shutdown 을 성공한다.
Feb 25 18:57:11 oops named[351]: starting (/etc/named.conf). named 8.2.3-REL
Wed Jan 31 01:04:28 KST 2001
^Iroot@oops.org:/../bind-8.2.3/src/bin/named
named 를 시작한다
Feb 25 18:57:11 oops named[351]: limit files set to fdlimit (1024)
Feb 25 18:57:11 oops named[351]: hint zone "" (IN) loaded (serial 0)
cache file 을 읽어 온다.
Feb 25 18:57:11 oops named[351]: oops.zone: WARNING SOA expire value is less
than 7 days (432000)
oops.zone 이라는 zone 을 읽어 들인다. SOA filed 에 대한 경고가 있
지만 2차 ns를 운영하지 않는한은 별로 신경을 쓸 필요가 없다.
Feb 25 18:57:11 oops named[351]: master zone "oops.org" (IN) loaded
(serial 20000302)
oops.org 가 master zone 으로 로딩이 되었음을 알린다.
Feb 25 18:57:11 oops named[351]: oops.rev: WARNING SOA expire value is less
than 7 days (432000)
Feb 25 18:57:11 oops named[351]: master zone "1.1.1.in-addr.arpa" (IN)
loaded (serial 20000302)
oops.rev 를 읽어들여 1.1.1.x 에 대한 network 의 inverse domain
의 설정을 로드 했음을 알린다.
Feb 25 18:57:11 oops named[351]: listening on [1.1.1.1].53 (eth0)
Feb 25 18:57:11 oops named[351]: Forwarding source address is [0.0.0.0].37760
Feb 25 18:57:11 oops named: named startup succeeded
Feb 25 18:57:11 oops named[352]: group = 25
Feb 25 18:57:11 oops named[352]: user = named
Feb 25 18:57:11 oops named[352]: Ready to answer queries.
|
그리고 또 한 방법은 nslookup 을 이용하는 방법이다. 일단, name server 로 접속하여 login 을
한 후에, name server 의 /etc/resolv.conf 에서 primary name server 를 자기 자신으로 잡는다.
즉 name server의 ip address 가 1.1.1.1 이라면 /etc/resolv.conf 에서 가장 상단의 nameserver
1.1.1.1 로 잡아 주라는 것이다.
resolv.conf 의 역할은 시스템이 domain 을 ip address 로 변환할 default name server 를 지정
하는 것으로 보통 3차 name server 까지 설정할수 있다. 여기서는 name server 를 설정하는 것이
아니라 사용할 name server 를 지정하는 것이고 또한 default name server 를 자신으로 지정하라
는 것은 resolv.conf 에서 가장 상단의 nameserver 지시자에 name server 의 ip address 를 잡아
주라는 것이다.
그리고 nslookup 을 실행했을때
*** ns.oops.org can't find 1.1.1.in-addr.arpa.: Non-existent host/domain
와 같은 에러 메세지를 만날 경우가 있다. 이 경우는 named.conf 에서 지정된 in-addr.arpa 설정
파일 즉 inverse domain 을 설정하는 파일의 설정에 문제가 있어서 그런 것이니 잘 살펴 보기 바
란다.
그리고 nslookup 을 실행한 뒤에 자신이 설정한 것을 잘 찾아 보기 바란다. 만약 default server
가 자기 자신이고, 자신의 domain name 이나 sub domain name 을 nslookup 상에서 찾았는데도 불
구하고 Non-authoritative answer: 와 같은 cache 의 내용을 꺼내 온다면 그것 또한 에러가 있는
것이니 잘 살펴 보도록 한다. 보통 자신의 domain 이나 sub domain 을 찾을 때는 cache 에서 꺼
내올 필요가 없기 때문에 위의 메세지가 뜨면 안된다.
위의 2가지 검사에서 아무 문제도 없다면 설정상의 문제는 아니고 외부의 문제로 돌리는 수 밖에
없다. 만약 외부의 문제라면 이때에는 어떻게 할 도리가 없다. Name Server 강좌를 잘 읽어본 사
람은 TTL 값 조정에 대한 글을 보았을 것이다. 즉, 외부에서의 문제를 해결하기 위해서는 수정하
거나 옮기기전 TTL값을 충분히 고려를 해서 해야 하는데 이에대한 이해가 없이 일단 무언가를 해
버렸 다면 TTL 값만큼 지정된 시간까지는 어떻게 할 수가 없다. 빠르면 TTL 에 지정된 시간이 지
나면 해결이 될 것이고 재수 없으면 일주일 이상 걸릴 수도 있다.
>> 이전 : Cache file 생성
>> 다음 : Method of Dynamic Update
|