Switching from forwarding to recursion

Tue Nov 1 15:00:53 UTC 2011

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20111101/e59aada5/attachment.html>