Switching from forwarding to recursion

Tue Nov 1 18:01:39 UTC 2011

If you get the EDNS errors for many or most remote name servers, look to your firewall as a suspected culprit. Otherwise, a few of these messages are normal.

You might be able to set query-source (and other *-source) options to just IPv4 addresses to disable use of IPv6. However, this shouldn't be a source of your slowness -- on most OS's, named figures out in very short order (for any given query) that the remote network is not available over IPv6.

The most obvious suspects are the EDNS problems and the number of unavailable forwarders -- as discussed previously in this thread, they all have to be tried once before the server will fail back to doing its own recursion.

Regards,
Chris Buxton
BlueCat Networks

On Nov 1, 2011, at 8:00 AM, Will Lists wrote:

> I did get a chance to dig through the syslogs finally on one of the internal name servers and I'm seeing a lot of these three entries for various domains.  I would have to assume that one or all of these items would also contribute to the lengthy times to resolve queries?
> 
> 
> named[16593]: error (network unreachable) resolving 'a1294.w20.akamai.net/A/IN': 2001:428:1802:3f0:8719:deda:1eed:ea4#53
> 
> -- This would be due to our network (internal or external) not supporting IPv6 I would assume.  I see that you can use the -4 flag when starting named to force IPv4 only, but I'm not sure if/how you could actually force this configuration via the named.conf file itself.
> 
> 
> named[16593]: success resolving 'ns2.gslb.com/AAAA' (in 'gslb.com'?) after reducing the advertised EDNS UDP packet size to 512 octets
> 
> -- Firewall configuration in regards to packet sizes?
> 
> 
> named[16593]: success resolving 'ns2.gslb.com/A' (in 'gslb.com'?) after disabling EDNS
> 
> -- ?
> 
> 
> Thanks
> 
> -Will
> 
> 
> 
> On Tue, Nov 1, 2011 at 9:13 AM, Ben Croswell <ben.croswell at gmail.com> wrote:
> If a given forwarder is "bad " it get its round trip time, rtt, set high and will not be used until that comes back down via the normal rtt decay mechanism in BIND. I have not tested the behaviour when all are down. My assumption would be that if all are down they will all have to be tried before going to NS or there is no way of knowing when the forwarders are back.
> 
> In your case if you have a limited number of servers a quick removal of the forwarders may be the quickest way to restore service.
> 
> -Ben Croswell
> 
> On Nov 1, 2011 10:03 AM, "Will Lists" <listswill at gmail.com> wrote:
> Ben,
> 
> I seem to recall reading at some point in the past that after X amount of time, BIND would stop trying to contact servers it figured to be dead (at least it would stop trying for some amount of time).  Is that in fact the case and would it eventually come into play here?  Any configurable options here, if this behavior does exist?
> 
> It almost seems like the best way to handle this scenario, in the event of a real failure of one or more external servers that typically act as forwarders, would be to quickly modify the configuration internally to just stop forwarding.  Thoughts?
> 
> Thanks.
> 
> 
> -Will
> 
> 
> On Tue, Nov 1, 2011 at 8:54 AM, Ben Croswell <ben.croswell at gmail.com> wrote:
> If you have a global forwarder in place there are two options that affect its use. Forward first, the default, and forward only.
> Forward first will exhaust the forwarders you have and then attempt to follow NS records. Forward only will only use forwarders.
> 
> The delay you are seeing is likely the delay in exhausting the forwarders before attempting the roots.
> 
> -Ben Croswell
> 
> On Nov 1, 2011 9:23 AM, "Will Lists" <listswill at gmail.com> wrote:
> We recently tried a test to see how our internal servers would react to a loss of their external peers, with the goal being that the internal servers would switch from forwarding to doing recursive queries for clients.  Normally, the internal servers forward to the external servers.  To simulate the loss of the external servers, we pushed a new firewall rule that blocked port 53 to the external servers from the internal servers.  That did seem to cause the internal servers to start using the root servers in a recursive manner.
> 
> We did see that some recursive queries were answered, eventually, though usually much, much slower than if the request had been forwarded as normal to the external servers.  We saw traffic (lots of traffic) going across the firewall to the roots as well as multiple domain specific name servers, so that flow path is working as best as I can tell.  All servers are running BIND 9.7.4.
> 
> The issue we saw was that the queries would time out more often than not and on the off chance they did get an answer back to the requesting client, it was very slow after several retries.  
> 
> Am I missing something in the named.conf file?  Is there something specific I should be looking for in the syslog or daemon.log?
> 
> 
> The relevant portion of the named.conf file for the INTERNAL view is below:
> 
> 
>     forwarders { NS2; NS1; };
>     forward first;
>     allow-recursion { 10.0.0.0/8; 192.168.0.0/16; 172.16.0.0/12; };    
>     recursion yes;
> 
>     // zone: . [hint]
>     include "...";
> 
> 
> The hints DB file is current as of the version of BIND in use (2011060800).
> 
> 
> Thanks.
> 
> -Will
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20111101/bacd1f54/attachment.html>