Re: [squid-users] Force A lookup first, then AAAA

From: John <just_bytesize_at_yahoo.co.uk>
Date: Thu, 5 Jan 2012 12:53:54 +0000 (GMT)

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_at_yahoo.co.uk> wrote:

> From: John <just_bytesize_at_yahoo.co.uk>
> Subject: [squid-users] Force A lookup first, then AAAA
> To: squid-users_at_squid-cache.org
> 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
>
>
Received on Thu Jan 05 2012 - 12:54:01 MST

This archive was generated by hypermail 2.2.0 : Fri Jan 06 2012 - 12:00:02 MST