ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • BIND(Berkeley Internet Name Daemon)
    └ Domain 2007. 5. 12. 13:26
    뭔가에 대해서 설명할려고 하면 그 범위때문에 막연해진다.
    물론 내자신을 위해 기록하는것이지만, 혹여 답을 찾아 온 다른이에게 도움이 될 수 있을지도 모른다는 생각때문에 기록에 범위가 커져가는걸 느낀다.

    나 역시 답을 찾아 다닐때 다른이의 블로그에서 도움을 많이 받기때문에 되갚아 한다는 의무감이 있기도 하다.

    하지만...
    이놈의 귀차니즘~

    이번에 회사 서버 이전하면서 기존 사용하던 master-master 설정에서 master-slave 로 바꾸었다.
    네임서버를 새로 이전하는 것도 흔치 않는일이고, 설정을 바꾸어서 적용하는것도 흔치 않는 일인지라 나름 재미있었다.
    하지만 본의 아니게 UDT 공격을 받아 master 서버가 장애가 났고..
    장애 처리하면서 master-slave  설정에 대해 잘몰라서 허둥댔다는..
    뭐 처리는 내가 안했지만 과정을 지켜보는 내가 잘몰라 당황스러웠다.

    BIND(Berkeley Internet Name Daemon)

    설치 : 생략
    rpm 설치 
    shell>  rpm -qa bind
    bind-9.2.4-24.EL4

    시작과 종료
    시작 : /usr/sbin/named -u named &
    리로드 : /usr/sbin/rndc -s XXX.XXX.XX.XXX reload
    종료 : /usr/bin/killall -9 named
    참고사항 : rndc - name server control utility (remote name daemon control)

    bind를 운영할때 서버를 한대만 사용한다면 master-slave 에 대한 고민이 필요없다.

    서버가 두대이상일경우 :
    master - master 로 운영할때
    장점 : 한쪽 서버가 장애났을때 대처속도가 빨라진다.
    장애서버를 내리고 운영가능 서버의 설정을 바꾸면 바로 적용되기 때문이다.
    단점 : 한쪽 서버에 설정이 바뀌거나 zone이 추가되었을때 다른 서버도 똑같이 적용해줘야 한다. 운영이 귀찮다.

    master - slave 로 운영할때
    장점 : master 서버만 관리하면 slave 에 대한 관리가 필요없다. 유지관리가 용이하다.
    단점:  장애서버가 master 인경우 설정을 바꿔야 하는겨우 slave 서버를 master로 변경해야한다. 변경작업에서 대처속도가 느려진다.
    master-slave 의 설정에 따라 다르지만 slave 에 master 의 zone 파일을 백업하지 않는 경우,
    장애시 master의 백업본이 반드시 있어야 한다.
    설정방법
    - master 만 바라보고 있어서 자신을 갱신하는 경우 :
    slave 에 파일이 필요하지 않기에 백업하지 않는 가능성이 높다.
    - master 의 변경부분만 slave 로 가져와 갱신하는 경우는 slave에도 반드시 파일이 존재한다.

    설정 --
    shell> vi /etc/named.conf
    // aaa.com 도메인
    zone "aaa.com" {
           type master; <- master
           file "aaa.com.zone"; <- zone 파일
           notify yes; <- serial 넘버가 변경될때마다 slave 에게 알림 (no: 알림기능 해제)
    };

    shell> vi /etc/named.conf
    // aaa.com 도메인
    zone "aaa.com" {
           type slave; <- slave
           masters { XXX.XXX.XXX.XXX ; }; <- master server 의 ip address
    };

    zone 파일을 변경할일이 생겼다.
    변경해보자
    shell> vi /var/named/aaa.com.zone
    TTL 1M
    @                       IN SOA          slave.aaa.com.  webmaster.aaa.com.  (
                                                2007050702      ; Serial , -> 변경사항이 있을때마다 수정해준다.
                                                2H         ; Refresh
                                                1H             ; Retry
                                                1W         ; Expire
                                                1H )            ; Minimum
                                           IN NS      master.aaa.com.
                                           IN NS      slave.aaa.com.
                                           IN MX 10   mail.aaa.com.

                  IN txt  "v=spf1  ip4:XXX.XXX.XX.XXX ip4:XXX.XXX.XX.XXX ip4:XXX.XXX.XX.XXX -all"

    aaa.com.                        IN A    XXX.XXX.XX.XXX  -> 변경했다고 치자.
    www.aaa.com.            IN A    XXX.XXX.XX.XXX

    내용을 변경했다면 리로드 해준다.
    /usr/sbin/rndc -s XXX.XXX.XX.XXX reload
    리로드할때 master 서버는 notify yes 인경우 slave 서버에게 자신의 serial 이 변경되었음을 알려준다. 그러면 slave 서버는 설정을 다시 가져온다.
    네임서버 설정 update 가 잦고, 데이터가 많은경우 slave가 미쳐 데이터를 다 가져오기 전에 master 가 update 되어 버린다면??
    그런 단점을 보완하기 위해 변경된 내용만 알려주는 옵션도 있다.
    서적을 참고하시길..

    로그 --
    가끔 slave 네임서버가 master 의 정보를 잘 가져왔는지 궁금할때가 있다.
    그때 확인하는 방법은
    shell> vi /var/log/messages
    May 12 05:39:49 ns4 named[17127]: zone aaa.com/IN: transferred serial 2007050702
    May 12 05:39:49 ns4 named[17127]: transfer of 'aaa.com/IN' from XXX.XXX.XXX.XXX#53: end of transfer


    참고 URL : http://kldp.org/KoreanDoc/html/PoweredByDNS-KLDP/index.html
    참고 서적 : DNS와 BIND (o'reilly 폴앨비츠, 크리켓류 저)

    '└ Domain' 카테고리의 다른 글

    멋쟁이 해커씨. ICANN 을 놀리다.  (0) 2008.06.30
    gTLD, ccTLD  (0) 2008.02.12
    about Domain Name Service  (0) 2007.11.14

    댓글

Designed by Tistory.