named failed to resolve forwarding queries(with global forwarders specified with "forward only") when "server section statement" has forwarder IP

[Nagesh Thati]

Thanks a lot for your quick response. Your answer is helpful.

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

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
> queries.
>
> (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.
>
> Tony.
> --
> f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
> harness technological change to human advantage
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20211125/5d240590/attachment.htm>