Slow DNS after 22.05
-
@johnpoz said in Slow DNS after 22.05:
dig @1.2.3.4 www.google.com
Ran this and get the same results as you thankfully but this is really good to know.
It may be that disabling IPv6 has resolved it but I'm keeping an eye on it and will report back.
Pings seem decent:
That's from a client and directly from pfSense is even faster averaging 13ms.
-
Would urge others experiencing the issue to try this and report back as so far everything is MUCH faster now. Even though it's early days I haven't received any DNS issues / timeouts yet.
Seems like user error IPv6 mis-config
@gertjan said in Slow DNS after 22.05:
No IPv6 on LAN => Consider what @johnpoz proposed :
-
@kempain I’m gonna try this by reverting my forward and adding this option.
What ISP are you running btw?
-
@mikymike82 said in Slow DNS after 22.05:
What ISP are you running btw?
I'm in the UK with Virgin. They do issue IPv6 as far as I know so I think I can do full IPv6 if I knew what I was doing.
-
unbound unbound 44545 3 udp4 *:53 :
unbound unbound 44545 4 tcp4 *:53 :
unbound unbound 44545 5 udp4 *:853 :
unbound unbound 44545 6 tcp4 *:853 :
unbound unbound 44545 7 tcp4 127.0.0.1:953 :
unbound unbound 44545 8 dgram -> /var/run/logpriv
unbound unbound 44545 10 stream -> ??
unbound unbound 44545 11 stream -> ??
unbound unbound 44545 13 stream -> ??
unbound unbound 44545 14 stream -> ??
unbound unbound 44545 15 stream -> ??
unbound unbound 44545 16 stream -> ??
unbound unbound 44545 17 stream -> ??
unbound unbound 44545 18 stream -> ??
unbound unbound 44545 19 stream -> ??
unbound unbound 44545 20 stream -> ??
unbound unbound 44545 21 stream -> ??
unbound unbound 44545 22 stream -> ??
unbound unbound 44545 23 stream -> ??
unbound unbound 44545 24 stream -> ??
unbound unbound 44545 25 stream -> ??
unbound unbound 44545 26 stream -> ??dig @1.2.3.4 www.google.com
; <<>> DiG 9.16.16 <<>> @1.2.3.4 www.google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached; <<>> DiG 9.16.16 <<>> www.google.com +trace
;; global options: +cmd
. 238 IN NS e.root-servers.net.
. 238 IN NS f.root-servers.net.
. 238 IN NS g.root-servers.net.
. 238 IN NS h.root-servers.net.
. 238 IN NS a.root-servers.net.
. 238 IN NS i.root-servers.net.
. 238 IN NS j.root-servers.net.
. 238 IN NS k.root-servers.net.
. 238 IN NS l.root-servers.net.
. 238 IN NS m.root-servers.net.
. 238 IN NS b.root-servers.net.
. 238 IN NS c.root-servers.net.
. 238 IN NS d.root-servers.net.
. 238 IN RRSIG NS 8 0 518400 20220823050000 20220810040000 20826 . ldBIj1Q5BNWr/TNFQ/RebaJR/2ss3M1NFtp9BVvF8c0oBqYtsYE5lXdh x5SyEQNaY0TQedI0sUYGH1mxbb8do4TGvHlt/cHqdZlR0C4iQJZh1E2J hW7jvykFTd+GvcxoT4pd27WAKcphMxjMV0kv/nJ/R62py40o/x0q4MEh qOOX9xaXXrk9LE8+kF/xH6Hzk/FP1Tvqky5wYq3zu+0GRAGg6Ykornbd 48YZHrK4p4hMwmCfc+rqq2GA1qI///C8yE+c3JbZzMqpnA/Fd1ki7OPa uC4rdZBRTjffHYrHvPm4JQexycKi2yk1p3Zd4VUV5TXso6bQumLIMOuL w+8gXw==
;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 1 mscom. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 86400 IN RRSIG DS 8 1 86400 20220823050000 20220810040000 20826 . clI/vPSk2t2LVd1WtfHI8VklYtaUPAOK/8Sr30o0VjGp7xZXZ5EhlVRz YarbopAZ+8yOIwwbIl82ByVZFf/qJEprOKW6TiG8goIoPBG6jghCoglV p4IqNUVqqwpJpAxNKbOA0cOeOr6qTwqugtJnU5J7TGG4QBi63KjYBoin gyYxaKkV/fvK9njoqxbn2hzaKB08mLlYj/9TKxS285UaxbMxYfPDJejQ FA+33Y+KjJlGhdYrCFy/o/JW+YKrfmLrMs2C3+6XGUFFDGSN9WUCF59j LMuQ0ZVAmZQkodwaKM0L1dojQtJU73fEnRkm/1ZhhiDYkQv/HPFHM3ur f3bWww==
;; Received 1174 bytes from 193.0.14.129#53(k.root-servers.net) in 16 msgoogle.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q2D6NI4I7EQH8NA30NS61O48UL8G5 NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20220815042401 20220808031401 32298 com. If06bSVXL7llnV+iyjrWR5yStSfeLZzeCKgsfVsqNQKKnP35dCsaGffz dRWOIGK+WzMKxVCiJZLiNyG5iYR9RybjH9jXMhDyYqro3M8eplcZtHnd DN0XXqhP/UDjMThDkJHxFERmmzraaU1wQLMcse/uOLMzmZVmOalWkbC+ TtXIfd8f4KB+h/M6X23C9UZ7oyYI78gqwS3Rq0fKInDxXA==
S84BKCIBC38P58340AKVNFN5KR9O59QC.com. 86400 IN NSEC3 1 1 0 - S84BUO64GQCVN69RJFUO6LVC7FSLUNJ5 NS DS RRSIG
S84BKCIBC38P58340AKVNFN5KR9O59QC.com. 86400 IN RRSIG NSEC3 8 2 86400 20220816051414 20220809040414 32298 com. BI5XFgxbzwBugDjaV04ygejNaUOMRGmTaJvdufqfRnJPaDEHLnqVpw7p 8UdjQnXLbtO4Fns2BpPOTD9DSSaWGRjxeZxlb6Rwxw1n4RGmJGe9QyaI f/zBXzn69uRXpgeRP6FFBmUuFCb7OQTBqoReLat+3fwKkebSv7epenW1 SvO4dXilsSZzTAUN8RvIdz9SgkBe+QxG8TiioAFYuTqdkw==
;; Received 840 bytes from 192.54.112.30#53(h.gtld-servers.net) in 12 mswww.google.com. 300 IN A 142.250.181.196
;; Received 59 bytes from 216.239.36.10#53(ns3.google.com) in 8 ms -
All seems ok as far as I know.
Key metric seems to be total recursion time so try:
unbound-control -c /var/unbound/unbound.conf stats_noreset | grep total -
@kempain said in Slow DNS after 22.05:
unbound-control -c /var/unbound/unbound.conf stats_noreset | grep total
total.num.queries=516
total.num.queries_ip_ratelimited=0
total.num.cachehits=312
total.num.cachemiss=204
total.num.prefetch=7
total.num.expired=0
total.num.recursivereplies=204
total.requestlist.avg=0.412322
total.requestlist.max=8
total.requestlist.overwritten=0
total.requestlist.exceeded=0
total.requestlist.current.all=0
total.requestlist.current.user=0
total.recursion.time.avg=0.688891
total.recursion.time.median=0.073533
total.tcpusage=0 -
@kempain said in Slow DNS after 22.05:
root servers taking 64ms rather than 28ms which is a bit of a bump
Don't worry.
I havein 89 msas I'm still using a VDSL - 23 Mbits down 2 Mbits up.
John is probably using fibre.My google name servers ns1 to ns4 tell me
in 55 msOne of yhem gave me an IP :
in 26 ms@kempain said in Slow DNS after 22.05:
Key metric seems to be total recursion time so try:
I've
total.num.queries=17629 total.num.queries_ip_ratelimited=0 total.num.cachehits=11918 total.num.cachemiss=5711 total.num.prefetch=6157 total.num.expired=5857 total.num.recursivereplies=5711 total.requestlist.avg=3.53632 total.requestlist.max=62 total.requestlist.overwritten=0 total.requestlist.exceeded=0 total.requestlist.current.all=0 total.requestlist.current.user=0 total.recursion.time.avg=0.437151 total.recursion.time.median=0.105229 total.tcpusage=0and guess what : I don't care.
I've activated
so, ones in the unbound cache, unbound gets a fresh copy of that host when it times (TTL) out, ready to be served on my local lans if needed == no more waiting. I keep the initial '100 ms' delay' and then it's over for that host.
-
@gertjan fiber I wish ;) just cable connection
I keep checking for fiber options - what I would really like is the symmetrical connection. Limited to 50mbps up vs my 500 down. More up would help with my plex server to friends and family.. They have a gig plan but it doesn't get you more up, so not worth the extra money - 500 is more than adequate for down for my needs.
Yeah the prefetch option can help especially if your having longer resolve times than typical. I think it ties really good with the serve 0 option.. I am not a fan of these really short ttls many records are going with 30 seconds, 60 seconds - get out of here, there is no need for that other than you wanting to track something.. I have my min ttl set for 3600 seconds (1 hour) and have never ran into any issues with it.
-
Another report of DNS resolving prob's after 22.05-RELEASE upgrade (on a 3100 unit)... Had absolutely no issues before the upgrade (did last weekend); after the upgrade, many issues with slow/failed website rendering, app launch failures, etc. -- finally yesterday I applied the "DNS Query Forwarding > Enable Forwarding Mode = yes" option in the Services > DNS Resolver > General Settings GUI, and boom - problem gone... Will try the
do-ip6: noserver option and undo the forwarding, and see how I make out. But I do think some problem got introduced in the 22.05 version of unbound (1.15.0) that got shipped, perhaps only affecting the ARM platform. -
Really appreciate all the help, thanks @johnpoz , @Gertjan and others.
Still going strong here with really low recursion averages and speedy response times now so fingers and toes crossed it seems to be resolved for me at least.
Still a question as to why it was fine in the previous version but it was probably caused by me mis-configuring IPv6 and not disabling it fully. Need to spend some time learning about IPv6 as I initially disabled it so I didn't have to worry about IPv6 firewall rules between VLANS that I'm trying to segregate. Assume there will be some things that may require IPv6 these days so I probably shouldn't be blocking it anyway.
-
@pcol-it-admin said in Slow DNS after 22.05:
perhaps only affecting the ARM platform
I'm on intel and it impacted me
-
@kempain yeah those times look way way better.
There are so many variables at play here, its quite possible there is something in this version that presents itself different with some flaky IPv6 setup.. There was a thread posted by I believe bmeeks that mentioned the do-ip6 no setting related to what others (non pfsense users) were seeing with this version of unbound.
Keep in mind the old version was like 1.13 or 1.12, or it was 1.13 and then backed off to 1.12 again, etc. And now currently its 1.15.0 I believe - while I believe current unbound is like 1.16.2
Hopefully we have gotten you to a stable config that works for your environment. IPv6 can introduce more variables into network, you mention firewall for example - there is a learning curve for sure, and things are done differently to be sure. Clients love to use temp IPv6 for their outbound connections, that can be trickier to firewall than just single IPv4 being used, etc.
I do believe IPv6 is the future, and yes sure it would behoove you to get familiar with it - but its not something that you have to understand today, or even tmrw or next month even. I have yet to have anyone provide a single example of HAVING to have IPv6 on their network - many an ISP don't even support it, mine doesn't - I have to get my IPv6 via a HE tunnel for example because my isp doesn't offer it, and have not even seen it mentioned as coming soon, etc.
You deciding not to use it at this time, sure isn't going to hold up the global deployment schedule ;) hehehe I have been tinkering with it for like 12 years.. And do have it available on my network - but in a limited fashion for limited devices that I want to play with it on..
Keep in mind setting unbound to not use IPv6 as a transport for doing dns queries or serving dns to your clients does not prevent you from using IPv6 on your clients.. Its just unbound won't use it as a transport is all - it can still serve up AAAA records just fine. For your clients to use IPv6 with.
-
@johnpoz said in Slow DNS after 22.05:
Keep in mind setting unbound to not use IPv6 as a transport for doing dns queries or serving dns to your clients does not prevent you from using IPv6 on your clients.. Its just unbound won't use it as a transport is all - it can still serve up AAAA records just fine. For your clients to use IPv6 with.
Good to know cheers John
It has been interesting working through this and I'm definitely going to f'up my config in the future!
As long as I'm learning in the process that's fine, and I definitely learnt a few things here so thanks for sharing your knowledge. -
@pcol-it-admin said in Slow DNS after 22.05:
yesterday I applied the "DNS Query Forwarding > Enable Forwarding Mode = yes" option in the Services > DNS Resolver > General Settings GUI, and boom - problem gone...
Before, you, that is, unbound, was questioning of the 13 world wide root servers.
If one doesn't work, or was slower, the other was used.So, initially, my unbound talks to (I'll pick one out of 13) : 192.58.128.30 or j.root-servers.net.
As this is the closest to me.Now, you're sending all your DNS request to an upstream resolver.
This upstream resolver doesn't exactly what unbound could be doing in the first place.
With four new possibilities :- Your upstream resolver decides what IP gets send back - it could be anything from the correct IP to a spoofed one. You will never know.
- A resolver can have a safety net for spoofing (DNSSEC) - a forwarder can not.
- single point of failure ! When 8.8.8.8 goes down (to name a known one) your network DNS goes out. This actually happened ..... just 48 hours ago.
- you become a product.
Internet itself, works only with resolvers. Forwarders were useful in the past as our ISP could not give us expensive ISP routers with processors that could run local resolvers. So, every SOHO connection was forwarding.
Those who use pfSense do not have (small) SO HO connections. They, the admins, want the real thing.IMHO : why does 8.8.8.8 1.1.1.1 etc etc exist today ?
Because root, tld and domain DNS servers are not reachable ? If that's the case, consider (a part of) Internet down? That would be world wide news.
So, no.
You know why they (still) exist.
It's a big money question for them - and yes, I know, their usage is free ;)@pcol-it-admin said in Slow DNS after 22.05:
and boom
The boom was probably that you restarted unbound.
And you changed from resolver to forward mode.
I nice test would be : go back to resolver mode - this will restart unbound ones more.Does it still work ? If so : you have now solid proof that "resolver" or "forward" mode wasn't the issue, so neither the solution.
Resolving doesn't work ? So root servers etc are not reachable ? Some one is doing MITM above your head ? For me, I would go in mayday mode if resolver OR forward mode doesn't work. Both should work out of the box, and if not, I have an urgent issue - or a very .doubtful ISP or whatever else is happening above my connection. -
To follow up on previous replies to my "me too" post saying I was typing in the name of the sites I was attempting to get to wrong, here's an example of what I encountered today when attempting to access my O365 email from a Chrome session on one of my test client using the pfSense DNS resolver (opposed to my pi-hole VM):
Clicking reload a couple of times resolved the problem and brought up the site.
here's the logfile from unbound when this was occurring.
Aug 10 15:51:09 unbound 69581 [69581:0] notice: Restart of unbound 1.15.0. Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.524288 1.000000 1 Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.131072 0.262144 3 Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.065536 0.131072 2 Aug 10 15:51:09 unbound 69581 [69581:0] info: lower(secs) upper(secs) recursions Aug 10 15:51:09 unbound 69581 [69581:0] info: [25%]=0.114688 median[50%]=0.174763 [75%]=0.240299 Aug 10 15:51:09 unbound 69581 [69581:0] info: histogram of recursion processing times Aug 10 15:51:09 unbound 69581 [69581:0] info: average recursion processing time 0.238208 sec Aug 10 15:51:09 unbound 69581 [69581:0] info: server stats for thread 3: requestlist max 1 avg 0.7 exceeded 0 jostled 0 Aug 10 15:51:09 unbound 69581 [69581:0] info: server stats for thread 3: 11 queries, 1 answers from cache, 10 recursions, 0 prefetch, 0 rejected by ip ratelimiting Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.524288 1.000000 1 Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.262144 0.524288 1 Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.131072 0.262144 1 Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.065536 0.131072 2 Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.032768 0.065536 1 Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.000000 0.000001 2 Aug 10 15:51:09 unbound 69581 [69581:0] info: lower(secs) upper(secs) recursions Aug 10 15:51:09 unbound 69581 [69581:0] info: [25%]=1e-06 median[50%]=0.098304 [75%]=0.262144 Aug 10 15:51:09 unbound 69581 [69581:0] info: histogram of recursion processing times Aug 10 15:51:09 unbound 69581 [69581:0] info: average recursion processing time 0.170908 sec Aug 10 15:51:09 unbound 69581 [69581:0] info: server stats for thread 2: requestlist max 0 avg 0 exceeded 0 jostled 0 Aug 10 15:51:09 unbound 69581 [69581:0] info: server stats for thread 2: 10 queries, 2 answers from cache, 8 recursions, 0 prefetch, 0 rejected by ip ratelimiting Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.262144 0.524288 1 Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.131072 0.262144 3 Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.065536 0.131072 3 Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.032768 0.065536 1 Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.000000 0.000001 1 Aug 10 15:51:09 unbound 69581 [69581:0] info: lower(secs) upper(secs) recursions Aug 10 15:51:09 unbound 69581 [69581:0] info: [25%]=0.0709973 median[50%]=0.120149 [75%]=0.207531 Aug 10 15:51:09 unbound 69581 [69581:0] info: histogram of recursion processing times Aug 10 15:51:09 unbound 69581 [69581:0] info: average recursion processing time 0.122444 sec Aug 10 15:51:09 unbound 69581 [69581:0] info: server stats for thread 1: requestlist max 0 avg 0 exceeded 0 jostled 0 Aug 10 15:51:09 unbound 69581 [69581:0] info: server stats for thread 1: 11 queries, 2 answers from cache, 9 recursions, 0 prefetch, 0 rejected by ip ratelimiting Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.524288 1.000000 1 Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.262144 0.524288 1 Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.131072 0.262144 2 Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.065536 0.131072 1 Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.032768 0.065536 1 Aug 10 15:51:09 unbound 69581 [69581:0] info: 0.000000 0.000001 3 Aug 10 15:51:09 unbound 69581 [69581:0] info: lower(secs) upper(secs) recursions Aug 10 15:51:09 unbound 69581 [69581:0] info: [25%]=7.5e-07 median[50%]=0.098304 [75%]=0.24576 Aug 10 15:51:09 unbound 69581 [69581:0] info: histogram of recursion processing times Aug 10 15:51:09 unbound 69581 [69581:0] info: average recursion processing time 0.182405 sec Aug 10 15:51:09 unbound 69581 [69581:0] info: server stats for thread 0: requestlist max 7 avg 0.777778 exceeded 0 jostled 0 Aug 10 15:51:09 unbound 69581 [69581:0] info: server stats for thread 0: 11 queries, 2 answers from cache, 9 recursions, 0 prefetch, 0 rejected by ip ratelimiting Aug 10 15:51:09 unbound 69581 [69581:0] info: service stopped (unbound 1.15.0). Aug 10 15:50:28 unbound 69581 [69581:0] info: generate keytag query _ta-4f66. NULL IN Aug 10 15:50:27 unbound 69581 [69581:0] info: start of service (unbound 1.15.0). Aug 10 15:50:27 unbound 69581 [69581:0] notice: init module 1: iterator Aug 10 15:50:27 unbound 69581 [69581:0] notice: init module 0: validator Aug 10 15:50:27 unbound 69581 [69581:0] notice: Restart of unbound 1.15.0.Of course, I cannot replicate this on a regular basis. It is random, and will happen to random sites. Usually clicking the 'reload' button in my browser will properly resolve the next time.
As with other people, from my clients, if I attempt to do nslookups I do get initial time-out errors virtually 100%:
C:\Users\tentpiglet>nslookup cnn.com Server: pfsense.tentpiglet.XXXXXXXXXXX.org Address: 192.168.1.254 DNS request timed out. timeout was 2 seconds. Non-authoritative answer: Name: cnn.com Addresses: 2a04:4e42:600::323 2a04:4e42:400::323 2a04:4e42::323 2a04:4e42:200::323 151.101.193.67 151.101.65.67 151.101.129.67 151.101.1.67 -
@tentpiglet that domain has multiple cnames that need to be followed
; QUESTION SECTION: ;login.microsoftonline.com. IN A ;; ANSWER SECTION: login.microsoftonline.com. 30 IN CNAME ak.privatelink.msidentity.com. ak.privatelink.msidentity.com. 30 IN CNAME www.tm.ak.prd.aadg.akadns.net.If your having an issue with resolving - maybe because of flaky ipv6 then yeah such records would be more problematic than most.
edit: also if you setting strict qname you could have issues
-
@gertjan Just reporting what worked to resolve (no pun intended!) my issue (which was bad & disruptive, and only started after the 22.05 upgrade...) So I am going to try and re-enable it, but one thing I've noticed is that there's a lot of pushback from you and @johnpoz against anything being wrong with Unbound in 22.05... Can you at least accept that there is some issue going on (intermittently, which sucks for t-shooting) post 22.05 upgrade for some of us? Let's not blame the user just because "works on my machine"...
I have 22.05 now running on my 3100 (which was problematic), a 2100 under my admin (at my house of worship), and a 4100 I just deployed at work... (I also have three other Intel-based platforms running pfSense at work as well, would need to check the releases on those.) If we need data from these platforms to assist problem identification efforts, please let me know.
-
What is the current tally that disabling IPv6 was implicated in resolving the issue?
-
This from the 2100 gateway that I just upgraded to 22.05-RELEASE over the weekend:
[22.05-RELEASE][admin@pcol-gw.pclawrenceville.lan]/root: unbound-control -c /var/unbound/unbound.conf stats_noreset | grep total total.num.queries=588600 total.num.queries_ip_ratelimited=0 total.num.cachehits=404414 total.num.cachemiss=184186 total.num.prefetch=0 total.num.expired=0 total.num.recursivereplies=184160 total.requestlist.avg=7.03968 total.requestlist.max=128 total.requestlist.overwritten=0 total.requestlist.exceeded=0 total.requestlist.current.all=30 total.requestlist.current.user=7 total.recursion.time.avg=26.928807 total.recursion.time.median=0.0733518 total.tcpusage=0total.recursion.time.avglooks bad to me... I did a test from a browser to a domain I never used from this location (www.sniffer.com) and it did lag for ~10 sec's before the page rendered.
