>> >> > imasd.ipv6.elmundo.es will fire an error, even with n=4 ... >> >> which error ? >> > > (debug_options 78,9 ) > > > 2007/11/26 15:48:37.010| idnsALookup: buf is 39 bytes for > imasd.ipv6.elmundo.es, id = 0xa80c > 2007/11/26 15:48:37.010| idnsRead: starting with FD 7 > 2007/11/26 15:48:37.021| idnsRead: FD 7: received 325 bytes from > 62.42.230.24:53 > 2007/11/26 15:48:37.021| idnsGrokReply: ID 0xa80c, 4 answers > ========================================================================== > 2007/11/26 15:48:37.021| idnsGrokReply: imasd.ipv6.elmundo.es AAAA query > failed. Trying A now instead. >
Ahh. You are sort of right. Its performing the right behaviour, just the wrong debug being shown. Should have said 'configured to also try A'. Fixed that. <snip> >> > Right. But the above log error is invoked with state: > > q->need_A = 1 , Config.onoff.dns_require_A == 1 , n = 4 > > evaluating the "if" guard to true. And the message is > > "idnsGrokReply: imasd.ipv6.elmundo.es AAAA query failed" > > > >> > >> > Even with that, ipcache.cc seems to have problems with canonical >> > names... >> >> Any more detail on what those problems are? >> I have seen some weird behaviour listing ipcache, but nothing I have >> been able to track down yet. If you can provide any light all the >> better. My bug has something to do with walking the hash list under some >> still unknown conditions. >> > > Yes, it's about that, (a flag?) When I get a deeper knowledge I'll > write.. > Meanwhile, if you locally modify the || by && (just to test, perhaps > this is not the rigth solution, up to you) , you can reproduce the > failure by entering a non-canonical name, i.e. www.google.com , > www.ipv6.elmundo.es , (no matter if IPv4 or IPv6) . By contrast, > www.l.goggle.com and imasd.ipv6.elmundo.es, canonical names, seem to be > answered... > The lookup behaviour can be overridden with the squid.conf option "dns_v4_fallback off". I'll get onto it when I have these pinger malformed packets dead. Amos
