Jay Daley wrote:
Hello All
I suspect many of you will already know that the Commerce Commission has released its report into broadband quality for the last six month of last year:
http://www.comcom.govt.nz/assets/Uploads/Report-on-New-Zealand-Broadband-Qua...
On page 31 there is a specific discussion about the impact of caching DNS resolution speeds:
"The DNS performance from remote test sites to the ISPs tested in all cities shows that webpage loading is slower the further the user is from the Auckland based DNS."
This implies that all ISPs have their caching DNS resolvers based in Auckland.
I would be very interested to know if that is that case. If anyone could enlighten me, on or off list, I would be very grateful.
As I'm sure you're aware, a recursive nameserver looking up a name starts with the root nameservers, and works its way down the tree towards the name you care about. So if you're looking up www.example.net, and we assume there is nothing in your nameservers cache, you get this sequence of events: 1) Your recursive nameserver looks up www.example.net by asking one of the root nameservers. We're spoilt for choice in New Zealand with I and F both having instances hosted within New Zealand, as I see it: a.root-servers.net ;; Query time: 209 msec b.root-servers.net ;; Query time: 146 msec c.root-servers.net ;; Query time: 147 msec d.root-servers.net ;; Query time: 234 msec e.root-servers.net ;; Query time: 169 msec f.root-servers.net ;; Query time: 8 msec g.root-servers.net ;; Query time: 192 msec h.root-servers.net ;; Query time: 219 msec i.root-servers.net ;; Query time: 235 msec j.root-servers.net ;; Query time: 205 msec k.root-servers.net ;; Query time: 72 msec l.root-servers.net ;; Query time: 209 msec m.root-servers.net ;; Query time: 248 msec 2) These then refer us to the gtld-servers.net. There aren't any instances inside NZ AFAIK so, again, as I see it: a.gtld-servers.net ;; Query time: 231 msec b.gtld-servers.net ;; Query time: 193 msec c.gtld-servers.net ;; Query time: 210 msec d.gtld-servers.net ;; Query time: 227 msec e.gtld-servers.net ;; Query time: 310 msec f.gtld-servers.net ;; Query time: 137 msec g.gtld-servers.net ;; Query time: 172 msec h.gtld-servers.net ;; Query time: 292 msec i.gtld-servers.net ;; Query time: 211 msec j.gtld-servers.net ;; Query time: 157 msec k.gtld-servers.net ;; Query time: 297 msec l.gtld-servers.net ;; Query time: 214 msec m.gtld-servers.net ;; Query time: 141 msec 3) Now we contact the name server for example.com (again, from my PoV): a.iana-servers.net ;; Query time: 139 msec b.iana-servers.net ;; Query time: 329 msec Now we're ready to start to fetch the page. Best case I've got 8ms (f.root) + 137ms (f.gtld) + 139ms (a.iana) = 284ms. Worst case I've got 248 (m.root) + 310ms (e.gtld) + 329ms (a.iana) = 887ms. And this is for a reasonably well connected site -- nearly .9 of a second before we've *begun* to fetch the page. Somewhere between about 20% and 70% of that time is spent talking to the GTLD servers. And the NS and A .com/.net glue are cachable for 86400, so once a day, at least one person has to wait almost an entire extra second. If you have 86,400 users that have to waste 1 extra second a day, you've just wasted an entire lifetime. If you want to improve Internet performance in New Zealand through improving DNS infrastructure, try and get at least one GTLD server instance hosted within New Zealand. the time it takes to go to the US for the GTLD .COM/.NET/.EDU lookups is by far the easiest of those to solve. Interestingly afilias's .org and .info infrastructure appears to have an instance within NZ (~5ms away), and the rest of their servers also seem to be fairly close. Also, you want to try and implement recursive name servers that have large caches, and have some kind of prefetching for commonly hit domains to avoid having end users wait. Try checking your local nameserver infrastructure with http://code.google.com/p/namebench/ to see how well it performs, it's quite eye opening.