On 21/08/14 10:02, reiner otto wrote: > Next is an excerpt from squids cache.log, printing some debug output: > > 2014/08/21 08:24:47| idnsALookup: buf is 40 bytes for dc80.s290.meetrics.net, > id = 0x81de > 2014/08/21 08:25:09| idnsRead: FD 6: received 56 bytes from 127.0.0.1. > 2014/08/21 08:25:09| idnsGrokReply: ID 0x81de, 1 answers > > Here, the response from dnsmasq to resolve dc80.meetrics.net took 32s, which > seems to be like a timeout somewhere. > > Such behaviour I see with several other domains, all of them advertising > domains. > Sometimes the servers of which change very often, like dc64.s290.meetrics.net > next time, or dc61.s290.meetrics.net etc. > > So somehow it seems to be related to some type of load sharing, popular for > ads :-). > Actually, I simply block these servers, but that needs regular update of the > blocklist. > Any suggestion, which type of debugging to do for dnsmasq, to trace down the > problem ? >
--log-queries is the obvious path to take. It will tell you which upstream servers are taking a long time to respond. Cheers, Simon. > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
