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)?
_______________________________________________
Please visit https://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 at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
