 TSI GabePremium,VIP
join:2007-01-03
Chatham, ON
kudos:2 | Google DNS versus ours There's been a lot of talking going around lately about our DNS being slower/worst than Google/OpenDNS. We're just in the middle of moving in some new improved recursive servers and I think I'm happy with the results.
Here's a graph showing response times comparing one of our DNS servers to Google's.
Not only are the response times almost 3 folds faster, you also get the benefit of using local DNS servers which means that services such as Akamai will deliver local content to you.
Some of these have already been rolled in production, so we are running a mix of old and new. We should have them all working within a week.
--
TSI Gabe - TekSavvy Solutions Inc.
Authorized TSI employee ( »TekSavvy FAQ »Official support in the forum )
|
|
| Curious: where in the network are these measurements taking place?
(i.e. will we see 9ms from home, or would it be more like 16ms (assuming ~7ms RTT to first hop) ) |
|
TSI GabePremium,VIP
join:2007-01-03
Chatham, ON
kudos:2 | That was from my house. (like 10ms away) |
|
|
|
mlord
join:2006-11-05
Nepean, ON
kudos:9 Reviews:
 ·Start Communicat..
 ·TekSavvy Cable
·TekSavvy DSL
| reply to derekm
said by derekm:Curious: where in the network are these measurements taking place? That's a very good question, though I suppose it shouldn't make any difference -- all of our home traffic passes through TSI on its way elsewhere, so at that point it should still be quicker to use the "local" TSI DNS.
But lots of other more capable ISPs have tried and failed to get this right. Let's see how it works here once rolled out to us masses. |
|
| reply to TSI Gabe
My issue with TSI's DNS Servers hasn't been the speed of them, it's the accuracy. Too many times over the past 3 years I haven't been able to resolve certain websites that worked fine using GoogleDNS.
|
|
mlord
join:2006-11-05
Nepean, ON
kudos:9 | Same here. |
|
 HiVoltPremium
join:2000-12-28
Toronto, ON
kudos:17 | Same thing I've experienced... |
|
TSI GabePremium,VIP
join:2007-01-03
Chatham, ON
kudos:2 | k, well we are changing these. This is still surprising though since we were using bind...which is pretty much de facto standard DNS server out there. |
|
mlord
join:2006-11-05
Nepean, ON
kudos:9 Reviews:
·Start Communicat..
·TekSavvy Cable
·TekSavvy DSL
| Yes, very surprising to us when it happens, too.
If there was a good way to let TSI know about it (specific site lookup failing), we'd probably do it. But it's just easier to run my own DNS (bind) than to monkey around with rebooting my router, changing cables, disconnecting/reconnecting the modem etc.. just to report a DNS issue.
Cheers |
|
mlord
join:2006-11-05
Nepean, ON
kudos:9 | namebench gives me 25-26msec average lookups for the same server as in post #1 above, versus 45-46msec for 8.8.8.8.
Cheers |
|
| reply to TSI Gabe
said by TSI Gabe:There's been a lot of talking going around lately about our DNS being slower/worst than Google/OpenDNS. We're just in the middle of moving in some new improved recursive servers and I think I'm happy with the results.
Here's a graph showing response times comparing one of our DNS servers to Google's.
In the interest of completeness, since you raised it, where is the graph showing TSI DNS vs OpenDNS?
Just sayin'. |
|
| reply to mlord
said by mlord:said by derekm:Curious: where in the network are these measurements taking place? That's a very good question, though I suppose it shouldn't make any difference -- all of our home traffic passes through TSI on its way elsewhere, so at that point it should still be quicker to use the "local" TSI DNS. Yeah, it's relative, assuming the DNS server is before the xconnect to Google, which would make sense.
I was more asking if we're looking at 10ms + first hop RTT (done at NOC), or say 2ms + first hop RTT (done at home). |
|
TSI GabePremium,VIP
join:2007-01-03
Chatham, ON
kudos:2 | reply to MaynardKrebs
said by MaynardKrebs:said by TSI Gabe:There's been a lot of talking going around lately about our DNS being slower/worst than Google/OpenDNS. We're just in the middle of moving in some new improved recursive servers and I think I'm happy with the results.
Here's a graph showing response times comparing one of our DNS servers to Google's.
In the interest of completeness, since you raised it, where is the graph showing TSI DNS vs OpenDNS? Just sayin'. Here you go. OpenDNS performs better than Google, but ours is still better  |
|
 TSI MarcPremium,VIP
join:2006-06-23
Chatham, ON
kudos:14
1 edit | reply to Bugblndr
said by Bugblndr:My issue with TSI's DNS Servers hasn't been the speed of them, it's the accuracy. Too many times over the past 3 years I haven't been able to resolve certain websites that worked fine using GoogleDNS.
Can you point to a thread on here where that was proven to be our server.
Each time I've seen this it turned out that it was the site at the other end that was in fact down or had their dns records messed up and only showed up on google or opendns because those had not yet updated to the latest records or visa-versa..
--
Marc - CEO/TekSavvy |
|
| reply to TSI Gabe
These, in the vast majority of cases relate to who is caching what.
I looked at one of these complaints earlier, and it turns out, google had a later version of a DNS record.
A breakdown is like this:
Time 0:
A record is www.example.org 10.1.1.1 TTL 3600 (3600, one hour, usually much higher (like a day) for crappy dns providers)
TSI DNS: no copy
Google DNS: no copy
Time 1:
A Google user checks out the site
TSI DNS: no copy
Google DNS: 10.1.1.1, 3600 (will be cached for 3600 more seconds)
Time 1800:
A TekSavvy user checks out the site
TSI DNS: 10.1.1.1, 3600
Google DNS: 10.1.1.1, 1800
Time 3500:
Site decides they wish to update their A record to 10.1.1.2
TSI DNS: 10.1.1.1, 1900
Google DNS: 10.1.1.1, 100
Time 3600:
Googles cache expires
TSI DNS: 10.1.1.1, 1800
Google DNS: no copy
Time 3601:
Google user requests the site again
TSI DNS: 10.1.1.1, 1700
Google DNS: 10.1.1.2, 3600
For the next 1700 seconds (~29 mins), TSI will still be pointing at the old IP.
You can use dig to troubleshoot this:
$ dig teksavvy.com @8.8.8.8 && dig teksavvy.com @206.248.142.222
; <<>> DiG 9.8.1-P1 <<>> teksavvy.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27201
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;teksavvy.com. IN A
;; ANSWER SECTION:
teksavvy.com. 30 IN A 206.248.155.70
;; Query time: 35 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Oct 11 10:25:57 2012
;; MSG SIZE rcvd: 46
; <<>> DiG 9.8.1-P1 <<>> teksavvy.com @206.248.142.222
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39145
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;teksavvy.com. IN A
;; ANSWER SECTION:
teksavvy.com. 1800 IN A 206.248.155.70
;; Query time: 10 msec
;; SERVER: 206.248.142.222#53(206.248.142.222)
;; WHEN: Thu Oct 11 10:25:57 2012
;; MSG SIZE rcvd: 46
Here you can see the entry on 8.8.8.8 will live for another 30s (teksavvy.com. 30 IN A 206.248.155.70), while on 206.248.142.222, it will live for another 1800s. If the owner changes the record between 30 and 1800s google will get the right answer, TSI will not.
This is how DNS should work, just you are getting lucky sometimes, as opposed to TSI's servers being problematic.
Try this the next time you run into problems and see what you get.
EDIT: this was directed to people having problems with TSI servers, not to TSI |
|
1 edit | Might be interesting to automate a cache purge if requested from MyTools.
You could have the client submit problematic DNS record from the website, compare your DNS server's copy to google & opendns. If your serial is less than theirs, flush the cache entry.
You could report that the entry is fine, or out of date and flushed.
EDIT: all the lookups, and comparisons are done on the webserver, when authenticated, so it wouldn't affect actual DNS performance, and shouldn't raise security issues. Just the cache purge for that record happens on the name server see: rndc flushname |
|
TSI MarcPremium,VIP
join:2006-06-23
Chatham, ON
kudos:14 | reply to derekm
In the breakdown you show.. the times listed are how much longer it will remain cached based on when it was last refreshed.. in other words, in your example, it's not because google updates more often then ours, that's generally set by the DNS record holder.. it's like you say.. depends on when it was last updated..
Like I mentioned, each time I hear somebody say our dns this or that.. I kind of scratch my head because I haven't seen a case where it was clearly our dns server at fault...
this new upgrade though is pretty sweet.. nice to see that it's significantly faster.
--
Marc - CEO/TekSavvy |
|
| Agreed - it's how DNS should work.
You could build the facility to report out of date zones - and have it automatically QC'd. Would it ever get used? That's a different question! 
And yes, great job on the new servers! |
|
| reply to TSI Gabe
said by TSI Gabe:Some of these have already been rolled in production, so we are running a mix of old and new. We should have them all working within a week.
Please update once you have completed this. |
|
Reviews:
·TekSavvy DSL
·TekSavvy Cable
 ·voip.ms
| reply to TSI Marc
said by TSI Marc 
Can you point to a thread on here where that was proven to be our server.
Each time I've seen this it turned out that it was the site at the other end that was in fact down or had their dns records messed up and only showed up on google or opendns because those had not yet updated to the latest records or visa-versa..
Could it be related to caching as derekm suggests? Perhaps in the odd instance.
Either way, good work on speeding things up. |
|
