Hi ! If it comes to webbrowsing, it comes to complexity. But if I wish to analyze dns, I go to the commandline. If one has 30 instances of Firefox, you cannot control something - it is always slower, while for Chrome, due to its multiprocess design, it keeps fast.
So I usually do not look at apps, I look to the network. I make direct test to dns and there is really the problem. So I present a little dnsmasq log here: Q Jun 21 13:14:46 dnsmasq[28673]: query[A] startpage.com from 192.168.26.9 Jun 21 13:14:46 dnsmasq[28673]: forwarded startpage.com to 213.73.91.35 Jun 21 13:14:46 dnsmasq[28673]: query[A] startpage.com.mbg.local from 192.168.26.9 Jun 21 13:14:46 dnsmasq[28673]: config startpage.com.mbg.local is NXDOMAIN-IPv4 Jun 21 13:14:46 dnsmasq[28673]: query[A] startpage.com from 192.168.26.9 Jun 21 13:14:46 dnsmasq[28673]: forwarded startpage.com to 213.73.91.35 Jun 21 13:14:46 dnsmasq[28673]: query[A] www.manne.eu.mbg.local from 192.168.26.254 Jun 21 13:14:46 dnsmasq[28673]: config www.manne.eu.mbg.local is NXDOMAIN-IPv4 Jun 21 13:14:51 dnsmasq[28673]: query[A] startpage.com from 192.168.26.9 Jun 21 13:14:51 dnsmasq[28673]: forwarded startpage.com to 85.214.73.63 Jun 21 13:14:51 dnsmasq[28673]: query[A] startpage.com from 192.168.26.9 Jun 21 13:14:51 dnsmasq[28673]: forwarded startpage.com to 85.214.73.63 Jun 21 13:14:56 dnsmasq[28673]: query[A] startpage.com.mbg.local from 192.168.26.9 Jun 21 13:14:56 dnsmasq[28673]: config startpage.com.mbg.local is NXDOMAIN-IPv4 Jun 21 13:14:56 dnsmasq[28673]: query[A] startpage.com.mbg.local from 192.168.26.9 Jun 21 13:14:56 dnsmasq[28673]: config startpage.com.mbg.local is NXDOMAIN-IPv4 Jun 21 13:14:56 dnsmasq[28673]: query[A] startpage.com from 192.168.26.9 Jun 21 13:14:56 dnsmasq[28673]: forwarded startpage.com to 213.73.91.35 Jun 21 13:15:01 dnsmasq[28673]: query[A] startpage.com from 192.168.26.9 Jun 21 13:15:01 dnsmasq[28673]: forwarded startpage.com to 85.214.73.63 Jun 21 13:15:01 dnsmasq[28673]: query[A] www.manfbraun.de from 192.168.26.254 Jun 21 13:15:01 dnsmasq[28673]: cached www.manfbraun.de is 84.201.92.70 Jun 21 13:15:01 dnsmasq[28673]: query[AAAA] www.manfbraun.de from 192.168.26.254 Jun 21 13:15:01 dnsmasq[28673]: forwarded www.manfbraun.de to 213.73.91.35 Jun 21 13:15:06 dnsmasq[28673]: query[A] startpage.com.mbg.local from 192.168.26.9 Jun 21 13:15:06 dnsmasq[28673]: config startpage.com.mbg.local is NXDOMAIN-IPv4 Jun 21 13:15:06 dnsmasq[28673]: query[A] startpage.com from 192.168.26.9 Jun 21 13:15:06 dnsmasq[28673]: forwarded startpage.com to 213.73.91.35 R Jun 21 13:15:06 dnsmasq[28673]: reply startpage.com is 37.0.87.19 You'll easily see, that the first request to "startpage.com" [markey by Q] is followed by several other and even to different DNS, and the first reply arrives 20 seconds (!!) later [marked by R] and you'll not know, which DNS provided the answer. Has nothing to do with other apps-delays. A good logentry would look like this: > Jun 21 13:15:06.987 dnsmasq[28673]: reply startpage.com for client-req 192.168.26.10 (at Jun 21 13:15:05.337) is 37.0.87.19 from 213.73.91.35 [made it two lines]. I have the problem for a long time now and the provider always claims to fixed it - was never true. I think, they have a random genrator to make disturbences. I just this moment entered the IPS-DSN and everyworks well. Sad, that dnsmasq is not able to provide a protocol - I'll develop something on my own. Regards, Manfred > -----Original Message----- > From: Albert ARIBAUD [mailto:[email protected]] > Sent: Tuesday, June 21, 2016 5:36 PM > To: [email protected] > Cc: [email protected] > Subject: Re: [Dnsmasq-discuss] Logging milliseconds > > Bonjour, > > Le Tue, 21 Jun 2016 16:41:02 +0200 > <[email protected]> a écrit: > > > Hello ! > > > > Ok, for a short moment, this might be ok. > > Why 'for a short moment'? The only limit is storage for the tcpdump > dump to file, and that's relatively dense. Even if the machine on which > you are running tcpdump does not have enough storage space, it could > always send the output over the network to e.g. your desktop or laptop > machine, which is certainly able to handle it. > > > But request/response usually > > dont follow each other directly, because there are some more of them > > "on the road". DNSMasq has already all this internally, while > > externally, one must really write a piece of tracker, which is able > > to wait for the answer of each request. Not a nice bash onliner .. ;-) > > Wireshark is able to map responses to requests; in fact, in the packet > display window, it provides clickable links to jump from one to the > other. Wireshark also computes the time elapsed between request and > response, and displays it in the response packet. And you can export > all this as text, including references between requests and responses > and their time deltas. > > Granted, if you want to do stats on long capture logs (or just limit > the dump to what you think is valuable), you'll have to write some ad > hoc AWK or sed lines, but I'd suspect a few tens at most, and nothing > more complex than variable assignments, some arithmetic, and ouput > formattting. > > > But my question was just, if something like a format statement for the > > logoutput exists. It this exist (and I do not see it) then everything > > is already done. > > I don't think there is any log format control option in dnsmasq. > > > It's because I see huge delay for apps nearly each day. The provider > > declared to have the issue fixed. Sort of. The port are not longer > > blocked - but now, there are huge delay. The may probably have > > a contract with the NSA .... ;-) > > "Delays in apps" can have so many causes. What possible causes other > than remote DNS servers have you considered and how did you rule them > out? > > > Thanks anyway, > > > > Manfred > > Amicalement, > -- > Albert. _______________________________________________ Dnsmasq-discuss mailing list [email protected] http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
