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.crosw...@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" <listsw...@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.crosw...@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" <listsw...@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@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@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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users