Basically I'm looking for a third option to "dns_v4_fallback", like this: "If this is Squid will lookup A and only try AAAA if none found." John --- On Thu, 5/1/12, John <just_bytesize@xxxxxxxxxxx> wrote: > From: John <just_bytesize@xxxxxxxxxxx> > Subject: Force A lookup first, then AAAA > To: squid-users@xxxxxxxxxxxxxxx > Date: Thursday, 5 January, 2012, 12:48 > Hello all, > > I'm regularly encountering a problem where remote websites > have incorrectly configured their DNS servers to respond > with SERVFAIL instead of NXDOMAIN to IPv6 queries. > > This can result in delays of up to 90 seconds as Squid > cycles through the DNS servers making IPv6 AAAA, then > finally falling back to A. The delay depends on how many DNS > servers are listed as authorititive NS. > > This is frustrating my users, and although I'm being > proactive and emailing the administrators of every broken > nameserver this isn't scalable. > > I cannot disable IPv6 in Squid because I'm running an IPv6 > enabled network. > > Is there a way to force Squid to perform an A lookup first, > then only do an AAAA lookup if the A lookup fails? This > would have the side effect of preferring IPv4 over IPv6, but > seems to be the only workaround where so many sites have > broken DNS. > > I tried options "dns_v4_fallback" and "dns_v4_first" but in > both cases Squid still tries to do AAAA lookups first, so > the delay is still present. > > Here is an example: > > time wget www.flybe.com > 1m 30.177s > > 2012/01/04 16:44:43.147| idnsALookup: buf is 31 bytes for > www.flybe.com, id = 0xb0ca > 2012/01/04 16:44:48.147| idnsCheckQueue: ID 0xb0catimeout > 2012/01/04 16:44:58.148| idnsCheckQueue: ID 0xb0catimeout > 2012/01/04 16:45:13.150| idnsRead: starting with FD 8 > 2012/01/04 16:45:13.150| idnsRead: FD 8: received 31 bytes > from 127.0.0.1:53 > 2012/01/04 16:45:13.150| idnsGrokReply: ID 0xb0ca, -2 > answers > 2012/01/04 16:45:13.150| idnsGrokReply: error Server > Failure: The name server was unable to process this query. > (2) > 2012/01/04 16:45:13.150| idnsGrokReply: Query result: > SERV_FAIL > 2012/01/04 16:45:13.150| idnsRead: FD 8: received 31 bytes > from 127.0.0.1:53 > 2012/01/04 16:45:13.150| idnsGrokReply: ID 0xb0ca, -2 > answers > 2012/01/04 16:45:13.150| idnsGrokReply: Late response > 2012/01/04 16:45:13.150| idnsRead: FD 8: received 31 bytes > from 127.0.0.1:53 > 2012/01/04 16:45:13.150| idnsGrokReply: ID 0xb0ca, -2 > answers > 2012/01/04 16:45:13.150| idnsGrokReply: Late response > 2012/01/04 16:45:43.151| idnsRead: starting with FD 8 > 2012/01/04 16:45:43.151| idnsRead: FD 8: received 31 bytes > from 127.0.0.1:53 > 2012/01/04 16:45:43.151| idnsGrokReply: ID 0xb53e, -2 > answers > 2012/01/04 16:45:43.151| idnsGrokReply: error Server > Failure: The name server was unable to process this query. > (2) > 2012/01/04 16:45:43.151| idnsGrokReply: Query result: > SERV_FAIL > 2012/01/04 16:46:13.155| idnsRead: starting with FD 8 > 2012/01/04 16:46:13.155| idnsRead: FD 8: received 31 bytes > from 127.0.0.1:53 > 2012/01/04 16:46:13.155| idnsGrokReply: ID 0xd7dd, -2 > answers > 2012/01/04 16:46:13.155| idnsGrokReply: error Server > Failure: The name server was unable to process this query. > (2) > 2012/01/04 16:46:13.155| idnsGrokReply: www.flybe.com AAAA > query failed. Trying A now instead. > 2012/01/04 16:46:13.163| idnsRead: starting with FD 8 > 2012/01/04 16:46:13.163| idnsRead: FD 8: received 83 bytes > from 127.0.0.1:53 > 2012/01/04 16:46:13.163| idnsGrokReply: ID 0xa3cd, 1 > answers > > Thanks, > > Dean > >
