지연된 뷰간에 공유되는 BIND 동적 영역에 대한 업데이트

뷰 가 공유되는 동적 영역이있는 BIND9 에서 nsupdate를 수행하고 동일한 뷰에 속하는 클라이언트에서 해당 레코드를 쿼리하면 nsupdate를 수행하면 레코드 업데이트 / 생성 / 삭제가 제대로 작동합니다. 에서.

nsupdate에 사용한 것과 동일 하지 않은 뷰에서 쿼리 하면 NXDOMAIN이 발생하거나 (새 레코드를 추가하는 경우) 임의의 시간 길이 (예 : 15)까지 변경 / 업데이트시 이전 레코드 정보가 표시됩니다. 분) 패스, 또는 나는 강제로 $ rndc freeze && rndc thaw. $ rndc sync이 문제를 해결하기 위해 전혀 아무것도하지 않는 것 같습니다. 저널 플러시가 15 분 정도 플러시되는 것으로 문서화 되었기 때문에 저널 파일 일뿐이었습니다.

확실하지 않은 경우 다음과 같이 시작하는 의사 코드가 있습니다.

바인드 뷰

view "cdn-redir" {
   match-clients { 10.1.1.0/24; 10.1.2.0/24; };
   include "cdn-zone.db";
   include "dynamic-zone.db";
};

view "default" {
   match-clients { any; };
   include "dynamic-zone.db";
};

명령 행 예

user@ns:~$ nsupdate -k rndc.key
> server localhost
> zone example.com.
> update add foohost.example.com. 600 A 10.5.6.7
> send
> quit

user@ns:~$ dig foohost.example.com (resolv.conf points to 127.0.0.1)
  [ responds with correct answer 10.5.6.7 ]

nsupdate와 동일한보기에 속하는 호스트

user@10.11.12.50:~$ foohost.example.com (resolv.conf points to above nameserver)
  [ responds with correct answer 10.5.6.7 ]

다른 곳에서 호스트 는 nsupdate와 다른 관점으로 떨어집니다.

user@10.1.1.50:~$ dig foohost.example.com (resolv.conf points to above nameserver)
  [ responds with NXDOMAIN even though I'm asking the same server ]

이 시점에서 인내심을 가지면 문제가 결국 해결되지만 (15 분 정도) 자주 인내심이 없기 때문에 $ rndc freeze && rndc thaw네임 서버에서 강제로 문제를 해결해야합니다.

플립 사이드

완전히 역전 된 측면에서 "cdn-redir"보기에 해당하는 주소에서 서버에 대해 nsupdate를 수행하면 문제 자체가 반대로 바뀝니다. "cdn-redir"와 일치하는 클라이언트의 후속 쿼리는 "rndc freeze / thaw"를 사용하지 않고 nsupdate 직후에 올바른 레코드를 가져 오지만 "cdn-redir"보기를 벗어나는 주소에서 쿼리하면 지연 / rndc 어음이 있습니다.

내 궁극적 인 질문

42만큼 단순하다면 팔을 벌려서 가져갈 것입니다 ...

DHCP 서버에서 동적 업데이트가 누락 될 우려가 있으므로 "rndc freeze && rndc thaw"를 피하고 싶습니다. 누구든지 업데이트 된 레코드를보기 사이에서보다 효과적이고 효율적으로 동기화하는 방법을 알고 있습니까, 아니면 내가 잘못 가고있는 곳을 밝힐 수 있습니까?

편집 : BIND 9.9.5 / Ubuntu 14.04 그러나 이전 버전의 Ubuntu 및 BIND에서 발생했습니다.

모두 감사합니다!

Andrew B가 요청한대로 다음 은 개정 된 (및 부분적인) 영역입니다.

$ORIGIN .
$TTL 3600
example.com     IN SOA ns1.example.com. HOSTMASTER.example.com. (
                       2009025039 ; serial
                       900 ; refresh 15
                       600 ; retry 10
                       86400 ; expire 1 day
                       900 ; minimum 15 min
                )
                NS     ns1.example.com.
$ORIGIN example.com.
$TTL 30
AEGIS           A   10.2.1.60
                TXT "31bdb9b3dec929e051f778dda5abd0dfc7"
$TTL 86400
ts-router       A 10.1.1.1 
                A 10.1.2.1
                A 10.1.3.1
                A 10.1.4.1
                A 10.1.5.1
                A 10.1.6.1
                A 10.1.7.1
                A 10.1.8.1
                A 10.2.1.1
                A 10.2.2.1
                A 10.2.3.1
ts-server       A 10.2.1.20
ts-squid0       A 10.2.2.20
ts-squid1       A 10.2.2.21
$TTL 600
tssw4           A 10.2.3.4
tssw5           A 10.2.3.5
tssw6           A 10.2.3.6
tssw7           A 10.2.3.7
; wash rinse repeat for more hosts
$TTL 30
wintermute      A     10.2.1.61
                TXT   "003f141e5bcd3fc86954ac559e8a55700"

다른 뷰는 개별적으로 작동하며, 별도의 명명 된 인스턴스를 실행하는 것보다 기본적으로 편리합니다. 다른보기에서 동일한 이름을 가진 영역이있는 경우 이는 우연의 일치 일 뿐이며 여전히 다른 영역과 더 이상 관련이없는 완전히 분리 된 영역입니다.

바인드가 영역 내용을 자체적으로 업데이트하는 상황 (슬레이브 영역, 동적 업데이트가있는 영역 등)에서 여러 개의 개별 영역이 동일한 영역 파일을 사용하면 작동하지 않습니다. 영역 파일 자체가 손상 될 위험이 있는지 확실하지 않습니다.

한보기의 영역이 다른보기의 이름이 같은 영역의 슬레이브가되도록하여 원하는 작업을 설정할 수 있습니다. 이것은 다소 복잡한 구성이지만 일치 클라이언트에 TSIG 키를 사용하고 수행 할 수 있다고 생각하는 알림 / 전송을 사용합니다.

편집 : ISC는이 시나리오에 대한 KB 기사를 게시했습니다. 여러보기간에 동적 영역을 공유하려면 어떻게합니까? 위에서 언급 한 것과 동일한 종류의 구성을 제안합니다.

다음은 형식이 다소 개선 된 구성 예입니다.

key "external" {
    algorithm hmac-md5;
    secret "xxxxxxxx";
};

key "mykey" {
    algorithm hmac-md5;
    secret "yyyyyyyy";
};

view "internal" {
    match-clients { !key external; 10.0.1/24; };

    server 10.0.1.1 {
        /* Deliver notify messages to external view. */
        keys { external; };
    };

    zone "example.com" {
        type master;
        file "internal/example.db";
        allow-update { key mykey; };
        also-notify { 10.0.1.1; };
    };
};

view "external" {
    match-clients { key external; any; };

    zone "example.com" {
        type slave;
        file "external/example.db";
        masters { 10.0.1.1; };
        transfer-source { 10.0.1.1; };
        // allow-update-forwarding { any; };
        // allow-notify { ... };
    };
};

뷰와 비슷한 문제가 발생하여 제거하고 대신 권한을 영역으로 이동하기로 결정했습니다.

두 영역 파일을 모두 포함하여 문제의보기를 대체하고, 현재 공유 영역을 변경하지 않고 "dynamic-zone.db"정의에 allow-query {}를 추가 할 수 있습니다.

    zone "dynamic.zone" {
            allow-query { 10.1.1.0/24; 10.1.2.0/24; };
            type master;
            file "/etc/bind/zones/master/dynamic.zone";
            update-policy { .... };
    };

이를 통해 지정된 네트워크에서만 dynamic.zone에 액세스 할 수있게하고 다른 영역을 공개하는 것으로 가정합니다.