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 <d...@dotat.at> wrote: > Nagesh Thati <tcpnag...@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 <d...@dotat.at> https://dotat.at/ > harness technological change to human advantage > >
_______________________________________________ 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
