She쥐포s' 이야기

오늘 모 회사의 Secondary DNS 작업을 지원을 해주면서 알게된 내용에 대해 적으려 함.

문제는
1. Apr 16 00:34:38 ns2 named[4586]: client SERVER_IP#XXXX: received notify
   for zone 'DOMAINNAME'
   Apr 16 00:34:38 ns2 named[4586]: zone ZONEFILENAME/IN: refused notify from non-master: SERVER_IP#XXXX

; bind가 시작될 때 자기가 갖고 있는 zone이 최신 버전인지 확인하기 위해, 데몬에게 "notify" 메시지를 보낸다.
  그러나 권한이 없기 때문에(there is no authorization) 데몬은 자신의 요청을 거부하게 된다.

  이 경우 options부분에 allow-notify를 세팅하여 해결하였다.

options {
        ......
//   allow-transfer { SERVER_IP; };
      allow-notify { SERVER_IP; };
        ......
}

  이제 named 를 재시작하고 나면 다음과 같이 나올 것이다.

Apr 16 00:43:13 ns2 named[4973]: zone ZONEFILENAME/IN: sending notifies (serial 2004110621)
Apr 16 00:43:13 ns2 named[4973]: client SERVER_IP#XXXX: received notify for zone 'DOMAINNAME'
Apr 16 00:43:13 ns2 named[4973]: zone ZONEFILENAME/IN: notify from SERVER_IP#XXXX: zone is up to date

  위의 내용은 다음의 사이트에서 힌트를 얻었다.
 
  http://benjamin.sonntag.fr/a37-named_zone_sonntag_eu_org_refused_notify_from_non-master.html

  모 회사의 Secondary Server의 named.conf에는 allow-transfer가 자신에게 지정되어 있었다.
  그래서 자신에게 걸려있는 allow-transfer 부분은 주석처리를 하였다.

2. zone domain.com/IN: refresh: could not set file modification time of
   '/var/named/slaves/domain.com.hosts': permission denied

; 모 회사의 경우 Cache Poisoning에 대비해 최신 버전의 Bind로 업그레이드한 상태이며
  리눅스를 사용중이었으며, chroot를 적용한 패키지를 설치하였다. Secondary로 설정하여
  named 데몬을 재시작하였을 때 위와 같은 메시지가 발생했다.
  /var/named/chroot/var/named/ 아래에 존재하는 파일들의 퍼미션을 살펴보니
  소유자는 root, 그룹은 named로 되어 있었다. 즉 다음 그림과 같이 되어 있었다.

   zone 파일이 전송되어서 생성된 파일인지 여부는 알 수 없었으나
   기존의 파일들을 임의의 디렉토리로 옮기고 named를 재시작 후에 정상화 되었다.