Problem with internal/external VIEWs
Dean Gibson (DNS Administrator)
isc at mailpen.com
Tue Jul 6 06:15:16 UTC 2021
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>
More information about the bind-users
mailing list