Best practice MultiView

[Nick Tait]

Hi Jiaming.

You'll also need "match-clients" in the first view (at least), so that 
the correct view handles the zone transfer request. As well as 
specifying 'the right key' in match-clients, you'll probably also want 
to specify 'not the wrong key', otherwise you won't be able to query the 
view from any clients (e.g. on your internal network) that don't present 
any key in their request...

I've taken your example, and changed the key names to 
"internal.example.com" and "external.example.com" (for clarity), and 
added the match-clients to it as follows:

    view "internal" {
       match-clients { key "internal.example.com"; !key
    "external.example.com"; internal-networks; };
       zone "example.com" IN {
         # some other config, master zone
         allow-transfer { key "internal.example.com"; };
         notify yes;
       };
       # some more zone
    };
    view "external" {
       match-clients { key "external.example.com"; !key
    "internal.example.com"; any; };
       zone "example.com" IN {
         # some other config, master zone
         allow-transfer { key "external.example.com"; };
         notify yes;
       };
    };

Note that I've included "internal-networks" in the internal view. This 
is simply to illustrate that you might also want the view to answer DNS 
requests from clients within your network.

There is one further improvement on the above, which is what Mark 
referred to below, which is where each view can include the respective 
key in NOTIFY messages. To do that, change "notify yes" to "notify 
explicit" and then use "also-notify" to specify the secondary servers 
along with the key to use. Applying this to the above you get something 
like:

    view "internal" {
       match-clients { key "internal.example.com"; !key
    "external.example.com"; internal-networks; };
       zone "example.com" IN {
         # some other config, master zone
         allow-transfer { key "internal.example.com"; };
         notify explicit;
         also-notify { 192.0.2.1 key "internal.example.com"; };
       };
       # some more zone
    };
    view "external" {
       match-clients { key "external.example.com"; !key
    "internal.example.com"; any; };
       zone "example.com" IN {
         # some other config, master zone
         allow-transfer { key "external.example.com"; };
         notify explicit;
         also-notify { 192.0.2.1 key "external.example.com"; };
       };
    };

The secondary server would need a similar match-clients set-up so that 
it associated the notify with the correct view (based on key). And as 
I'm sure you know it would also need a "primaries" (or "masters" in old 
terminology) statement that includes the correct key name.

Nick.


On 17/04/23 22:12, Mark Andrews wrote:
> You use keys as well when sending notify to select which view processes the notify
>
>> On 17 Apr 2023, at 18:44, Jiaming Zhang<J.Zhang at yiximeta.com>  wrote:
>>
>> Dear community,
>>
>> I was wondering if notifying and updating zones in different view (say "internal" and "external") between bind servers via different key is a good practice. I got a sample zone/config like below:
>> ```
>> view "internal" {   zone "example.com" IN {
>>      # some other config, master zone
>>      allow-transfer { key key1; };
>>      notify yes;
>>    };
>>    # some more zone
>> }
>> view "external" {
>>    zone "example.com" IN {
>>      # some other config, master zone
>>      allow-transfer { key key2; };
>>      notify yes;
>>    };
>> }
>> ```
>> where both zones have the same name server (e.g. `ns1.example.com` and `ns2.example.com`). What I'm trying to archive is that and update on zones in "internal" view does not contaminate zones in "external" view, or vice versa. I was wondering if using different key to limit update is a good practice, since I'm expecting "external" view on slave server will also receive notify upon update on "internal" zone at master, but just unable to query update due to incorrect key.
>>
>> Kind Regards,
>> Jiaming Zhang
>>
>> Yixi Meta
>> Tel: +31 (6) 12 98 08 07
>> Email:J.Zhang at yiximeta.com
>> Website: yiximeta.com
>>
>> De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail of informatie uit deze e-mail is alleen toegestaan met voorafgaande schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.
>>
>> The content of this message is intended solely for the addressee. No rights can be derived from this message or its attachments. If you are not the intended recipient, we kindly request you to delete the message and inform the sender. It is strictly prohibited to disclose, copy or distribute this email or the information inside it, without a written consent from the sender. Yixi Meta is registered with the Dutch Chamber of Commerce trade register with number 85744115.
>> -- 
>> Visithttps://lists.isc.org/mailman/listinfo/bind-users  to unsubscribe from this list
>>
>> ISC funds the development of this software with paid support subscriptions. Contact us athttps://www.isc.org/contact/  for more information.
>>
>>
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230417/2a16433f/attachment-0001.htm>