forward first and fallback not working

[ma...@nucleus.it]

Hi,
bind 9.10.3_p4 with this global option:

forward first;

forwarders {
8.8.8.8;
};

If i dig from localhost or any client and 8.8.8.8 answers all is ok but
if 8.8.8.8 is unreachable or it doesn't respond, bind doesn't fallback
on himslef asking to root server etc .

This is not expected.
Anyone with this behavior ?

best regards
Marco

[Darcy Kevin (FCA)]

Look in your logs at the time of named startup to see if your root-server priming failed at that time.

- kevin

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[ma...@nucleus.it]

No errors on logs and if i remove
forward first;

forwarders {
8.8.8.8;
};

all is workin properly .

i don't know if i am missing something but i think it is a bug .

[Marco Felettigh]

The dns resolution with 8.8.8.8 works fine with "forward first" if
8.8.8.8 is working but for testing i blocked with an
intermediate firewall the dns requests to the forwarder and two things
happened (the second one is bad).

1) If the firewall reset the connection to 8.8.8.8 bind fallbacks on its
root servers and this is good

2) If the firewall drop the connection to 8.8.8.8 bind does NOT
fallback on its root servers and this is a bad thing cause in this
way i was testing a network outage for my forwarder.

below my config

Hi attach also che config

/etc/resolv.conf
search domain.dom
nameserver 127.0.0.1

named.conf
acl "trusted" {
127.0.0.0/8;
192.168.1.0/24;
};

options {
directory "/var/bind";
pid-file "/run/named/named.pid";

/* https://www.isc.org/solutions/dlv >=bind-9.7.x only */
//bindkeys-file "/etc/bind/bind.keys";

session-keyfile "/var/bind/session.key";

//listen-on-v6 { ::1; };
//listen-on { 127.0.0.1; };

masterfile-format text;

allow-query {
/*
* Accept queries from our "trusted" ACL. We will
* allow anyone to query our master zones below.
* This prevents us from becoming a free DNS server
* to the masses.
*/
trusted;
};

allow-query-cache {
/* Use the cache for the "trusted" ACL. */
trusted;
};

allow-recursion {
/* Only trusted addresses are allowed to use recursion.
*/ trusted;
};

allow-transfer {
/* Zone tranfers are denied by default. */
none;
};

allow-update {
/* Don't allow updates, e.g. via nsupdate. */
none;
};

forward first;
forwarders {
8.8.8.8;
};
};

zone "." in {
type hint;
file "/var/bind/named.cache";
};

zone "localhost" IN {
type master;
file "pri/localhost.zone";
notify no;
};

zone "127.in-addr.arpa" IN {
type master;
file "pri/127.zone";
notify no;
};

End of named.conf

[/dev/rob0]

On Wed, Aug 24, 2016 at 05:28:55PM +0200, Marco Felettigh wrote:
> The dns resolution with 8.8.8.8 works fine with "forward first" if
> 8.8.8.8 is working but for testing i blocked with an intermediate
> firewall the dns requests to the forwarder and two things happened
> (the second one is bad).
>
> 1) If the firewall reset the connection to 8.8.8.8 bind fallbacks
> on its root servers and this is good
>
> 2) If the firewall drop the connection to 8.8.8.8 bind does NOT

> this fallback on its root servers and this is a bad thing cause

> in this way i was testing a network outage for my forwarder.
>
> below my config

I am not sure this is a BIND issue. Try this with a longer timeout
set in your resolver ...

> Hi attach also che config
>
> /etc/resolv.conf
> search domain.dom
> nameserver 127.0.0.1

options timeout=20

Try similar settings on other clients.

My glibc (GNU/Linux) resolver says the default timeout is 5 seconds.
I'm not sure about named, but I think its timeout is greater than
that. So named is waiting for its own timeout before attempting
recursion. By the time recursion is complete, the client has long
since given up.

> named.conf
snip

If anything needs to change on the BIND side of this, perhaps it
would be the documentation of "forward first", to note that this
feature won't work with most standard resolver clients.

I would further suggest that this fallback isn't a very good idea
anyway; you'll probably be better off just doing the recursion
without forwarders in the picture.
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: