dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
44

HiVolt
Premium Member
join:2000-12-28
Toronto, ON

HiVolt to mlord

Premium Member

to mlord

Re: Google DNS versus ours

said by mlord:

Same here.

Same thing I've experienced...

TSI Gabe
Router of Packets
Premium Member
join:2007-01-03
Gatineau, QC

TSI Gabe

Premium Member

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
Kanata, ON

mlord

Member

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

mlord

Member

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

derekm
join:2008-02-26

derekm to TSI Gabe

Member

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
derekm

1 edit

derekm

Member

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 Marc
Premium Member
join:2006-06-23
Chatham, ON

TSI Marc to derekm

Premium Member

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.

derekm
join:2008-02-26

derekm

Member

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!
derekm

derekm

Member

@TSIMarc:
An even easier solution, set the max-cache-ttl and max-ncache-ttl :

»www.zytrax.com/books/dns ··· ache-ttl

You can auto-expire your cache settings every 10 minutes - 1 hour.

TSI Marc
Premium Member
join:2006-06-23
Chatham, ON

1 edit

TSI Marc

Premium Member

yeah but that doesn't lead to better performance.. you want records that are accurate to stay cached so their response is fast.. having to go query the auth dns server where the records are hosted is the part that takes the longest...

sometimes this is why larger dns servers may perform better since they have more queries cached by virtue of simply having more people use it... in that way they dont need to delay while it fetches the record, somebody else has already done that in some cases so to you it appears quicker. typically that's where people might argue that its better.

at our size now though I'd say that's fairly moot but to me that's the only real legitimate thing one could say.. the more users use our servers.. the less of an issue that is too..
The Mongoose
join:2010-01-05
Toronto, ON

The Mongoose

Member

I caught this thread and decided to re-run namebench...a while back I was having some trouble and switched everything over to Google DNS. Today's test results:

Fastest: TekSavvy
2nd: UltraDNS (31% slower than TSI)
3rd: Primus (35% slower)

Other notables...OpenDNS was 37% slower, Google DNS was 48% slower.

I've switched back to TekSavvy's servers as a result, so far working fine.

HiVolt
Premium Member
join:2000-12-28
Toronto, ON

HiVolt to TSI Marc

Premium Member

to TSI Marc
I'll switch back to the TSI servers and see how they perform now...

fluffybunny
@teksavvy.com

fluffybunny to TSI Marc

Anon

to TSI Marc
hmm..i get much worse performance with teksavvy DNS than with google :
using GRC nameserver benchmark :

206.248.142.222 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.000 | 0.016 | 0.081 | 0.021 | 100.0 |
- Uncached Name | 0.055 | 0.196 | 0.514 | 0.111 | 100.0 |
- DotCom Lookup | 0.077 | 0.163 | 0.272 | 0.052 | 98.0 |
------+-------+-------+-------+-------+-------+

vs

8.8.8.8 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
+ Cached Name | 0.000 | 0.019 | 0.082 | 0.023 | 100.0 |
+ Uncached Name | 0.047 | 0.165 | 0.440 | 0.101 | 100.0 |
+ DotCom Lookup | 0.048 | 0.166 | 0.283 | 0.060 | 100.0 |
------+-------+-------+-------+-------+-------+

derekm
join:2008-02-26

derekm to TSI Marc

Member

to TSI Marc
said by TSI Marc:

yeah but that doesn't lead to better performance.. you want records that are accurate to stay cached so their response is fast.. having to go query the auth dns server where the records are hosted is the part that takes the longest...

Understood. It wasn't to suggest it would improve performance. It would improve accuracy though. It's a trade off.

If it's 100-500ms (500 would be terrible) every 10-60 minutes that get hit with the latency, I don't think it would even be noticeable, if you look at the average response time.

Also, the end-users computer would respect the TTL in its DNS cache, so it would only be new requests.

You could override this TTL cap for the top 1% of the queries, fairly easily, which would give you better performance for most sites, and better accuracy for the 'long tail'.

Just throwing some (unrequested) ideas out there.

TSI Marc
Premium Member
join:2006-06-23
Chatham, ON

TSI Marc

Premium Member

yep. that's sort of how this is.. you kind of have to find a good balance based on the load that's on our servers.. there's no one size fits all kind of solution.

thanks for the input.

TSI Gabe
Router of Packets
Premium Member
join:2007-01-03
Gatineau, QC

TSI Gabe to fluffybunny

Premium Member

to fluffybunny
Much worse?

the Cached avg response time is lower for us and the std deviation is also lower.

The uncached is faster for Google by 9ms but still something seems odd with this report as the overall response times are much higher than what I would normally expect on a normal Internet Connection.

I don't know GRC that well...it runs on Windows it looks like
TSI Gabe

TSI Gabe

Premium Member

Alright, all servers are in production now

»tinyurl.com/9z899t3

Comparing our servers, 206.248.154.22 and 206.248.154.170 to OpenDNS and Google

And the clear winner is us
TSI Gabe

TSI Gabe

Premium Member

I should probably add that this test is being run from my house from a normal DSL connection, this isn't something that's being run right next to the server that would yield an unfair advantage.
jstory
join:2011-02-05
New Westminster, BC

jstory

Member

Here on the we(s)t coast, Google's DNS is the clear winner.

dig teksavvy.com @8.8.8.8
shows a query time of 25 msec.

whereas,

dig teksavvy.com @206.248.142.222
shows a query time of 74 msec

TSI Gabe
Router of Packets
Premium Member
join:2007-01-03
Gatineau, QC

TSI Gabe

Premium Member

That's because Vancouver has separate DNS servers.

You need to use 76.10.191.198 & 199
nbinont
join:2011-03-13

1 edit

nbinont to TSI Marc

Member

to TSI Marc
said by mlord:

If there was a good way to let TSI know about it (specific site lookup failing), we'd probably do it.

There is - and we have told them. Many times. All we need is for someone from TSI to spend the time to diagnose. And yes, it does take time, as a good class of the problems with TSI's DNS servers are due to very slow DNS resolutions when the entry is not cached. If you test it when it is cached, it works great, but the initial cache is a disaster.
said by TSI Marc:

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...

Look a bit harder:
»[Cable] Slow DNS resolution for site on Teksavvy
»Review of TekSavvy Cable by nbinont
»Teksavvy routing issues?

These are all DNS issues, despite the titles.

EDIT: I haven't tried the new servers yet.

TSI Gabe
Router of Packets
Premium Member
join:2007-01-03
Gatineau, QC

TSI Gabe

Premium Member

The first one, he's using 192.168.1.1 as his DNS server, not ours, hence why it's not working.

The second one...it's hard to tell, it's just a review that hasn't really been looked at to begin with.

The third one, the guy had just updated his DNS records on his own server, we forced a refresh for him as a courtesy.
mlord
join:2006-11-05
Kanata, ON

mlord

Member

said by TSI Gabe:

The first one, he's using 192.168.1.1 as his DNS server, not ours, hence why it's not working.

That's probably his router, which probably IS using TSI's server. Very standard setup, that.

TSI Marc
Premium Member
join:2006-06-23
Chatham, ON

TSI Marc

Premium Member

said by mlord:

said by TSI Gabe:

The first one, he's using 192.168.1.1 as his DNS server, not ours, hence why it's not working.

That's probably his router, which probably IS using TSI's server. Very standard setup, that.

Gabe appears to have looked that one up at the time and wrote this later in the thread:

»Re: [Cable] Slow DNS resolution for site on Teksavvy

AkFubar
Admittedly, A Teksavvy Fan
join:2005-02-28
Toronto CAN.

AkFubar

Member

Posted in the direct forum... no can read it...
nbinont
join:2011-03-13

nbinont to mlord

Member

to mlord
said by mlord:

said by TSI Gabe:

The first one, he's using 192.168.1.1 as his DNS server, not ours, hence why it's not working.

That's probably his router, which probably IS using TSI's server. Very standard setup, that.

Yep - my router using TSI's DNS servers. Though asking TSI's DNS servers directly with dig shows the same problem.

TSI Marc
Premium Member
join:2006-06-23
Chatham, ON

TSI Marc to AkFubar

Premium Member

to AkFubar
oh. hahaha, that's funny. I see says the blind man!?

looks like the first and the last are actually one and the same.

if we had problems with the dns servers.. we'd have thousands of calls... just look at the rogers outtage recently.. that's what happened.
TSI Marc

TSI Marc to nbinont

Premium Member

to nbinont
said by nbinont:

said by mlord:

said by TSI Gabe:

The first one, he's using 192.168.1.1 as his DNS server, not ours, hence why it's not working.

That's probably his router, which probably IS using TSI's server. Very standard setup, that.

Yep - my router using TSI's DNS servers. Though asking TSI's DNS servers directly with dig shows the same problem.

lets take a closer look see if we can figure out what's going on.
nbinont
join:2011-03-13

nbinont to AkFubar

Member

to AkFubar
said by AkFubar:

Posted in the direct forum... no can read it...

Sorry everyone - the problem occurs when the specific address is NOT in the TSI DNS cache. If I posted the site everyone here would check it out and TSI would not be able to see the effect on the first request. Hence the Direct forum post.

TSI Gabe
Router of Packets
Premium Member
join:2007-01-03
Gatineau, QC

TSI Gabe to TSI Marc

Premium Member

to TSI Marc
Are you saying this is still happening now?