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

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

2021-11-24 Thread Nagesh Thati

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


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, Nov 24, 2021 at 4:22 PM Tony Finch  wrote:

> Nagesh Thati  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.finchhttps://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

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

2021-11-24 Thread Tony Finch

Nagesh Thati  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.finchhttps://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

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

2021-11-23 Thread Nagesh Thati

Hi,

I have a BIND master server(10.1.10.110) and slave server(Recursive,
10.1.10.120) and also a global forwarding to another server for non managed
domains.
Forwarding server(10.1.10.25) also a slave for example1.com and example2.com,
which will get zone transfers from BIND slave server.

Below is my named.conf configuration, in the config, for secure zone
transfers I am using "server statement" with a TSIG communication key. With
this configuration when named is loaded in the BIND slave server,
I can only resolve exmple1.com and example2.com on BIND slave server
(10.1.10.120), for other non managed domains I see *SERVFAIL errors*.

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?




*BIND AUTH Master IP: 10.1.10.110BIND AUTH Slave IP: 10.1.10.120Forwarder
IP: 10.1.10.25*

*named.conf:*

#-
# ACLs
#-


*acl "transfer-core-dns" { 10.1.10.25};*

#-
# Key Definition
#-
key "RNDC-KEY" {
algorithm HMAC-SHA512;
secret
"ykLMNmAECOp4fcBMqIddG17Ubo4sTvm1zb5YSh7HvEjP8F2f+XU9uavOx4hoVBKANDY0tJIRlNOI8U8LaJunDg==";
};
#-
# Controls Definition
#-
acl "RNDC-USERS" {
127.0.0.1;
localhost;
};
controls {
inet 127.0.0.1 port 953 allow { RNDC-USERS; } keys { "RNDC-KEY";};
};

#-
# Logging Definition
#-
logging {
channel named {
file "/var/named/log/named.log" versions 10 size 100M;
severity  dynamic;
print-category yes;
print-severity yes;
print-time yes;
};
category default {
named;
};
};

#-
# Global Options
#-
options {
directory "/";
allow-query {any;};
allow-transfer {none;};
blackhole {none;};
dnssec-enable yes;
dnssec-validation no;
listen-on-v6 {none;};
check-srv-cname ignore;
check-mx-cname ignore;
check-mx ignore;
check-names master ignore;
check-names response ignore;
dump-file "/var/named/log/named_dump.db";
lame-ttl 600;
max-ncache-ttl 10800;
minimal-responses yes;
pid-file "/var/run/named/named.pid";
recursion yes;
session-keyfile "/var/run/named/session.key";
statistics-file "/var/named/log/named.stats";
tcp-clients 1000;
zone-statistics yes;
empty-zones-enable no;
rrset-order {
order cyclic;
};
transfers-in 50;
transfers-out 30;
transfers-per-ns 30;
no-case-compress {any; };
allow-recursion {any;};
recursive-clients 1;

* forward only; forwarders {10.1.10.25;};*
flush-zones-on-shutdown yes;
};

#-
# Statistics Section
#-
statistics-channels {
inet 127.0.0.1 port 8080 allow { 127.0.0.1; };
};



#-
# Server Definition
#-
key "COMMUNICATION-KEY" {
algorithm HMAC-SHA512;
secret
"1HVF90bx+6ywx5Ovr1SOCcL2inTDc0gYRoG6BK/TU+g8tAr3j0ptJsZ6OjfNxEYcMGDRt5m5z/it1gPe7+jJqA==";
};




*server 10.1.10.25 { keys  "COMMUNICATION-KEY"; provide-ixfr yes;
request-ixfr yes;};*

#-
# Zone Section
#-
zone "." IN { type hint; file "/var/named/zones/masters/db.cache"; };
zone "example1.com" IN {
type slave;
file "/var/named/zones/slaves/db.example1.com";
* allow-transfer {transfer-core-dns;};*
allow-notify {10.1.10.110;};
notify yes;
masters {
10.1.10.110;
};
check-names ignore;
zone-statistics yes;
forwarders {};
};
zone "example2.com" IN {
type slave;
file "/var/named/zones/slaves/db.example2.com";
allow-transfer {transfer-core-dns;};
allow-notify {10.1.10.110;};
notify yes;
masters {
10.1.10.110;
};
check-names ignore;
zone-statistics yes;
forwarders {};
};

*named.log:*
client: error: query (google.com/NS): query_find: *unexpected error after
resuming: tsig indicates error*
query-errors: info: (google.com): *query failed (SERVFAIL) *for
google.com/IN/NS at query.c:8678
client: error: query (google.com/MX): query_find: unexpected error after
resuming: tsig indicates error
query-errors: info: (google.com): query failed (SERVFAIL) for
google.com/IN/MX at query.c:8678
query-errors: info: (google.com): query failed (SERVFAIL) for
google.com/IN/A at query.c:7118
query-errors: info: (google.com): query failed (SERVFAIL) for
google.com/IN/A at query.c:7118
query-errors: info: (google.com): query failed (SERVFAIL) for
google.com/IN/NS at query.c:7118
query-errors: info: (google.com): query failed (SERVFAIL) for
google.com/IN/MX at query.c:7118
___
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

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

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

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

3 matches

Site Navigation

Mail list logo

Footer information