Problem with internal/external VIEWs

[Dean Gibson (DNS Administrator)]

Well!  That was the quickest & simplest WORKING solution I have ever 
received from a mailing list!  Thank you!


On 2021-07-05 17:55, Mark Andrews wrote:
> If you want the content to be the same in both views and to be dynamically updatable then use
>
> view view1 {
> 	zone example.com {
> 		type primary;
> 		[ allow-update / update-policy ] { … };
> 		…
> 	};
> };
>
> view view2 {
> 	zone example.com { in-view “view1”; };
> };
>
> ...
>
>> On 2021-07-05 12:36, Dean Gibson (DNS Administrator) wrote:
>>> Currently running Bind v9.11.4:
>>>
>>> Several years ago, I implemented multiple VIEWs using (almost) the 
>>> exact example in the Reference Manual.  However, I wanted the 
>>> "example-internal.db" and "example-external.db" to be the same file.
>>>
>>> This worked until I wanted to have "example.com" updateable via 
>>> ddns.  I don't remember the exact error, but I have a note in my 
>>> configuration file of /"don't do that!"/ (use the same file).  So, I 
>>> removed the first zone declaration for "example.com".  That was 
>>> still with Bind v9, but a lesser minor version.
>>>
>>> So, the result is that I can't do a "dig -k tsig.file @localhost -t 
>>> axfr example.com" from the server command line.  The transfer is 
>>> denied, because "match-clients" forces me into the first (internal) 
>>> VIEW.
>>>
>>> The server is behind a firewall (which has a forward to the server), 
>>> so "dig" works if I specify "dig -k tsig.file @ns1.example.com".  
>>> Because of this, I can still use "dig" like I want on the server.
>>>
>>> However, I'd think this must be a common issue.  Any resolution 
>>> (like recognizing & dealing with two references to a dynamically 
>>> updated file)?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210705/e57b1933/attachment.htm>