web-dev-qa-db-ja.com

ビュー間で共有されるBIND動的ゾーンの更新が遅れる

すばやく簡単に説明します。BIND9で動的ゾーンが views で共有されている場合、nsupdateを実行し、レコードの更新/作成/削除を行うと、該当するクライアントからそのレコードをクエリすると正常に機能します。 nsupdateを実行したときと同じビュー。

Nsupdateに使用したものとが同じではないビューからクエリを実行すると、NXDOMAIN（新しいレコードを追加する場合）がスローされるか、イベントの発生時に古いレコード情報が表示されます任意の時間（たとえば15分）が経過するまで変更または更新するか、または強制的に$ rndc freeze && rndc thaw。 $ rndc syncは、問題を解決するために何もしないようです-ジャーナルのフラッシュは約15分でフラッシュすることが文書化されているので、それが単なるジャーナルファイルであることを望んでいました。

それが明確でない場合は、開始するための擬似コードを次に示します。

BINDビュー

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と同じビューに分類されます

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

その他、ホストはnsupdateとしてdifferentビューに分類されます

[email protected]:~$ 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"に一致するクライアントからの後続のクエリは、nsupdateの直後に "rndc freeze/thaw"、butをいじることなく正しいレコードを取得します。 「cdn-redir」のビューから外れるようになりましたが、遅延/ rndcのばかげています。

私の究極の質問

42と簡単だったら、両手を広げて...

DHCPサーバーからの動的更新を見逃す恐れがあるため、「rndcフリーズ&& rndc解凍」する必要がないようにしたいと思います。更新されたレコードをビュー間でより効果的/効率的に同期させる方法を知っている人はいますか、または私が間違っている可能性のある場所に光を当てることができますか？

編集：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"
binddynamic-dnssplit-dns
8
enragedSquirrel

異なるビューは個別に動作します。これは本質的に、namedの個別のインスタンスを実行するよりも便利です。異なるビューに同じ名前のゾーンがある場合、これは単なる偶然であり、それらは完全に別個のゾーンであり、他のどのゾーンよりも関連がありません。

複数の別々のゾーンが同じゾーンファイルを使用するようにしても、バインドがゾーンのコンテンツを独自に更新している状況（スレーブゾーン、動的更新のあるゾーンなど）では機能しません。ゾーンファイル自体を破損するリスクさえあるかどうかはわかりません。

一方のビューのゾーンをもう一方のビューの同じ名前のゾーンのスレーブにすることで、やりたいことのようなものを設定できる場合があります。これは明らかにやや複雑な設定になりますが、マッチクライアントに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 { ... };
    };
};
7
Håkan Lindqvist

ビューに同様の問題があるため、ビューを削除して、代わりに承認をゾーンに移動することにしました。

質問のビューを両方のゾーンファイルの単純なインクルードで置き換え、現在共有されているゾーンをそのままにして、次のように「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にアクセスできるようにし、他のゾーンを公開するという推定目標を達成します。

1
tomas