리눅스포털

참고: RFC1996

BIND-8 부터 지원하는 DNS Notify기능은 Primary의 Zone 데이터베이스가 수정되었음을 해당 Zone의 Authority를 갖는 Secondary 서버로 알려주어 Primary와 Secondary 네임서버의 동적 동기화를 가능케 한다.

BIND-4나 BIND-8에서 본 옵션을 사용하지 않으면 Zone의 SOA 영역에 명시된 Refresh를 주기로 Secondary가 Primary의 Serial 증가를 체크하여 Zone Transfer 하는 형태이나. BIND-8의 DNS Notify를 사용하면 하여 도메인 수정 변경에 따른 전파시간 (Maximum Propagation Delay)을 최소화 해준다.

Primary의 Zone이 업데이트 되면 BIND는 해당 Zone의 NS 레코드를 분석하여 자신을 제외한 나머지 네임서버에 Zone이 업데이트 되었음을 알리는 Notify 신호를 보내고, Secondary는 Primary Zone의 Serial이 증가하였음을 확인한후 Zone transfer를 통해 해당 Zone을 업데이트한다. 만약 Secondary가 DNS Notify를 지원하지 못한다면 "Not Implemented" 응답과 함께 해당 요청을 무시한다.

Figure 5-1. Maximum Propagation Delay

Maximum Propagation Delay

[큰 그림 보기]

BIND-8는 기본적으로 DNS Notify가 켜져있다. 따라서 다음과 같은 설정을을 통해 전체 혹은 특정 Zone에 대해서 DNS-Notify를 적용치 않을 수 있다.

    options {
        notify no;  // 전체에 대해서 기능을 끈다. (디폴트 yes)
    }
    
    zone "freebsd.org" {
        type master;
        file "zone-freebsd.org"
        notify no;          // 해당 도메인에 대해서만 기능을 끈다.
    };
    
    zone "freebsd.org" {
        type master;
        file "zone-freebsd.org"
        notify yes;         // 해당 도메인에 대해서만 기능을 켠다.
    };

Authority를 갖지 않는 네임서버에 Notify 리스트에 포함하고자 할 경우엔 also-notify 옵션을 사용한다.

    zone "freebsd.org" {
        type master;
        file "zone-freebsd.org"
        notify yes;
        also-notify {210.124.149.130;};
    };

RFC1996에 따르면 DNS Notify 요청을 받은 Secondary 네임서버는 해당 도메인의 Authority를 갖는 다른 네임서버에게 다시 DNS Notify 신호를 보내야 하는데 실제 BIND-8 구현에서는 포함되지 않았음을 참고하기 바란다. 이 기능은 네트워크 토폴로지상 Secondary가 Primary에 바로 접속치 못하고 다른 Secondary를 마스터로 설정하는 경우를 대비해 규정되었으나, 실용적으로 이러한 경우가 매우 드물고 바람직하지 않은 구성(Maximum Propagation Delay 증가)이기에 BIND-8에 같이 구현되지 않은듯 싶다.

5.2. Dynamic Update

참고: RFC2136

BIND-8 부터 지원되는 Dynamic Update는 해당 도메인의 Authority를 갖는 네임서버를 통해 Zone 파일을 수정치 않고도 레코드를 동적으로 원격 갱신할 수 있도록 한다. 도메인 관리를 자동화 하거나, 사용자별로 접속 도메인을 실시간 변경하여 제공하거나, DHCP에서의 주소-IP 매칭등과 같이 실시간 적으로 레코드가 변경, 갱신 될 필요가 있는 서비스에 특히 유용할 수 있겠다.

Dynamic Update는 보안을 이유로 기본적으로 기능이 꺼져있기 때문에 허용할 도메인에 대해 allow-update 옵션을 추가해야 한다.

    zone "freebsd.org" {
        type master;
        file "zone-freebsd.org";
        allow-update { 210.124.149.130; };
    }

Dynamic Update는 BIND 배포판에 포함되어 있는 nsupdate 도구를 사용하여 명령행(non-interactive) 혹은 대화형(interactive)으로 조작이 가능하다. 대화형 모드에서 주어진 명령문은 묶음(조건문과 명령문)으로 실행이 가능하기 때문에 입력한 명령문(들)은 공백 라인에서 엔터를 한번 더 입력하여야 한다. 명령행 모드는 명령문을 주어진 파일이나 stdin 에서 입력받는다. 다음은 nsupdate에서 사용가능한 명령문이다.

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...: 지정된 레코드를 해당 도메인에 추가한다.

    $ nsupdate
    > update add freefall.freebsd.org. 3600 IN A 210.124.149.150
    > [Enter]
    ...(messages)...
    > ^D
    
    $ nsupdate
    > prereq nxrrset freebsd.org. IN MX
    > update add freebsd.org. 3600 IN MX 10 mail.freebsd.org.
    > [Enter]
    ...(messages)...
    > ^D

기존에 A, CNAME 등의 레코드가 설정된 도메인명에 대해서 delete를 수행치 않고 add 명령을 입력했을때 기존 레코드의 데이터가 입력된 레코드의 데이터로 교체될거라는 생각은 하지 말아야 한다. 중복된 A 레코드의 입력은 도메인에 여러개의 IP를 매핑할 것이고, CNAME이 설정된 도메인명은 다른 레코드가 존재할 수 없음에도 CNAME을 add하는 명령이 해당 도메인의 A, MX와 같은 레코드를 자동으로 제거해주지는 않기 때문이다.

Dynamic Update를 통해 수정된 내역은 즉시 적용되며 named가 종료될 때 해당 Zone 데이터베이스에 직접 기록되어 다음번 구동시에도 그 내역이 변함없이 적용될 수 있도록 한다.

Dynamic Update에 대한 요청이 해당 도메인의 Authority를 갖는 Secondary로 보내어 졌다면 Secondary 네임서버는 Primary 네임서버로 요청을 전달하도록 되어있다. 물론 이러할 경우엔 Primary의 allow-update 억세스 리스트에는 Secondary가 포함되어 있어야 한다.

5.3. 미러링 서버간의 부하 공유

서버가 히트수를 감당하지 못할 경우, 그 해결책으로써 다수의 미러링 서버를 운영하여, 부하를 분담시키는 방법을 생각할 수 있다. 하지만, 이러한 방법은 미러링 서버를 사용자에게 홍보하여 서버의 부하가 이동하는데 실질적으로 많은 시간이 소요되고, 적절한 부하 분배를 기대하기가 힘이든 문제가 있다. 그래서 전화국의 대표 번호 서비스와 같이, 사용자의 요청을 각각의 미러링 서버로 연결해주는 대표 도메인을 생각할 수 있는데, 여기에서 그 방법을 소개한다. Shuffle Addresses이라 불리는 이 특별한 기법은 BIND 4.9 부터 지원된다.

    www             180     IN      A       210.105.79.101
                    180     IN      A       210.105.79.102
                    180     IN      A       210.105.79.103

하나의 호스트명에 여러개의 IP주소를 주었을 경우, 네임서버는 해당 도메인에 대해 다음과 같이 라운드 로빈 방식으로 응답 한다.

    $ nslookup www.nobreak.com
    Name:    www.nobreak.com
    Addresses:  210.105.79.101, 210.105.79.102, 210.105.79.103
    
    $ nslookup www.nobreak.com
    Name:    www.nobreak.com
    Addresses:  210.105.79.102, 210.105.79.103, 210.105.79.101
    
    $ nslookup www.nobreak.com
    Name:    www.nobreak.com
    Addresses:  210.105.79.103, 210.105.79.101, 210.105.79.102

이것이 로드 발랜싱(Load Balancing)은 아니지만, 클라이언트는 3대의 서버에 어느정도 공평하게 접속되므로, 부하를 공유하는 효과를 얻을 수 있고, 또한 외부로는 대표 도메인만을 알리면 되므로, 서버의 확장 및 축소에 유연하다. 본 기법을 적용할 때에는 라운드 로빈이 지원되지 않는 네임서버를 고려하여 TTL을 낮게 책정(TTL이 만기하여 다시 요청이 들어오도록)하는 것도 좋다.

또하나의 방법으로는 다수의 CNAME을 연결하는 방법이다. 원칙적으로 다수의 CNAME은 거부되기 때문에, 반드시 다음과 같이 부트 파일에 별도의 옵션을 주어야 한다.

    options {
            multiple-cnames yes;
    };

이것은 BIND-8 에서만 가능하며, 대표적으로 YAHOO!(www.yahoo.com)가 이러한 방법으로 운영된다.

    www             180     IN      CNAME   www1.nobreak.com.
                    180     IN      CNAME   www2.nobreak.com.
                    180     IN      CNAME   www3.nobreak.com.
    www1            180     IN      A       210.105.79.101
    www2            180     IN      A       210.105.79.102
    www3            180     IN      A       210.105.79.103
            180 IN  A   210.105.79.104
            180 IN  A   210.105.79.105

다수의 A 레코드 방식은 Resolver의 로컬 NS가 Authority NS에서 다수의 IP(라운드 로빈된)를 넘겨받아 캐쉬에 저장해 둔 후 자체적으로도 라운드 로빈처리를 해주지만, 다수의 CNAME 방식은 로컬 NS가 한 개의 주소만을 넘겨받기 때문에 자체 라운드 로빈이 불가능하며, TTL이 만기될 때까지 해당 Resolver들은 하나의 주소를 사용하게 된다.

    * Authority NS에 직접 질의하였을 경우
    $ nslookup  www.nobreak.com  ns.nobreak.com
    Name:    www1.nobreak.com
    Address:  210.105.79.101
    Aliases:  www.nobreak.com
    
    $ nslookup  www.nobreak.com  ns.nobreak.com
    Name:    www2.nobreak.com
    Address:  210.105.79.102
    Aliases:  www.nobreak.com
    
    $ nslookup  www.nobreak.com  ns.nobreak.com
    Name:    www3.nobreak.com
    Address:  210.105.79.103, 210.105.79.104, 210.105.79.105
    Aliases:  www.nobreak.com

    * 네임서버의 캐쉬(Third Party Name Server)에서 받아올 경우
    $ nslookup  www.nobreak.com  ns.kornet.ne.kr
    Name:    www2.nobreak.com
    Address:  210.105.79.102
    Aliases:  www.nobreak.com
    
    $ nslookup  www.nobreak.com  ns.kornet.ne.kr
    Non-authoritative answer:
    Name:    www2.nobreak.com
    Address:  210.105.79.102
    Aliases:  www.nobreak.com
    
    $ sleep 180  (TTL이 만기될 때 까지 기다린 후)
    
    $ nslookup  www.nobreak.com  ns.kornet.ne.kr
    Non-authoritative answer:
    Name:    www3.nobreak.com
    Address:  210.105.79.103, 210.105.79.104, 210.105.79.105
    Aliases:  www.nobreak.com
    
    $ nslookup  www.nobreak.com  ns.kornet.ne.kr
    Non-authoritative answer:
    Name:    www3.nobreak.com
    Address:  210.105.79.104, 210.105.79.105, 210.105.79.103
    Aliases:  www.nobreak.com
    
    $ nslookup  www.nobreak.com  ns.kornet.ne.kr
    Non-authoritative answer:
    Name:    www3.nobreak.com
    Address:  210.105.79.105, 210.105.79.103, 210.105.79.104
    Aliases:  www.nobreak.com

참고로, 로드 밸런싱을 구현하기 위해서는 시스템의 부하에 따라 라우팅을 조정하는 스위치나 클러스터링(Clustering) 솔루션을 통하여야 한다.

강좌