named failed to resolve forwarding queries(with global forwarders specified with "forward only") when "server section statement" has forwarder IP
tcpnagesh at gmail.com
Thu Nov 25 05:19:15 UTC 2021
Thanks a lot for your quick response. Your answer is helpful.
On Wed, Nov 24, 2021 at 4:22 PM Tony Finch <dot at dotat.at> wrote:
> Nagesh Thati <tcpnagesh at gmail.com> wrote:
> > Can anyone tell me why I am getting tsig errors and SERVFAIL errors for
> > non managed zones? Why named using the "server statement" TSIG key in
> > forwarding queries instead of using this TSIG only for ixfr/axfr?
> TSIG is a bit confusing to set up because there are a bunch of options
> and the use-cases and pros and cons can be unclear.
> The `server` clause has a grab-bag of options that you can specify about
> other nameservers that your server might communicate with for whatever
> reason. If you configure a TSIG key in a `server` clause, it is used for
> all traffic with that server. (There will normally be a corresponding
> config on the other server for traffic in the opposite direction.) It's
> convenient to use for traffic between authoritative servers, because it
> gives you one place to secure refresh queries, notifies, and zone
> transfers. But in a more complicated configuration like yours it can have
> an unwanted effect on other traffic.
> Another approach is to configure TSIG for each kind of traffic separately.
> More explicit, but more verbose. The way I like to do this is to have
> `acl` clauses with helpful names, which can then be used in allow-notify
> and allow-transfer options to require TSIG for incoming requests; and
> corresponding top-level `primaries` clauses for use in per-zone
> `primaries` and/or `also-notify` clauses for outgoing requests. I can put
> all this access control stuff into a shared config file used on all my
> servers, and the authoritative TSIG stuff will not affect recursive
> (For example, at Cambridge we have a mutual secondarying arrangement with
> Imperial College with TSIG and IPv6 and DNSSEC and all that good stuff;
> our recursive servers don't know anything special about the Imperial
> zones, and we don't need or want recursive queries between us to use TSIG.
> Our recursive servers still have the same shared access control config,
> but the Imperial parts are not used there, because none of the zone
> clauses refer to the Imperial acl/primaries names.)
> This kind of explicit TSIG configuration doesn't work in all cases: for
> instance, you can't specify TSIG keys in the `forwarders` clause, so you
> have to use a `server` clause to configure TSIG for forwarding.
> I haven't answered your specific questions because I'm not sure I
> understand the details of your setup properly, but I hope this more
> general answer is helpful.
> f.anthony.n.finch <dot at dotat.at> https://dotat.at/
> harness technological change to human advantage
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bind-users