Updates to a BIND dynamic zone that is shared between views delayed

Solution 1:

Different views act separately, it's essentially a convenience over running separate instances of named. If there are zones with the same name in different views this is just a coincidence, they are still entirely separate zones, no more related than any other zones.

Having multiple separate zones use the same zone file does not work in situations where bind is updating the zone contents on its own (slave zones, zones with dynamic updates, etc). I'm not sure if there's even risk of corrupting the zone file itself.

You may be able to set something like what you want to do up by having the zone in one view be a slave for the zone with the same name in the other view. This will clearly be a somewhat complicated configuration but using TSIG keys for match-clients as well as the notify/transfer I believe it should be doable.

Edit: ISC has published a KB article for this scenario, How do I share a dynamic zone between multiple views?, suggesting the same kind of config mentioned above.

This is their config example with somewhat improved formatting:

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 { ... };
    };
};

Solution 2:

Having the similar problems with views I decided to get rid of them and move the authorization into the zones instead.

You could replace the views in questions by simple includes of both zone files, let the currently shared zone(s) untouched and add allow-query{} to "dynamic-zone.db" definition like:

    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 { .... };
    };

by this you achieve your presumed goal to make dynamic.zone accessible from specified networks only and to have other zones public.