dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
16759
share rss forum feed

highwire2007

join:2008-05-17
Nepean, ON
reply to TSI Gabe

Re: Google DNS versus ours

I have rarely agreed about google/openDNS being better than TSI's DNS servers. Namebench consistently showed TSI being faster, with no time-outs, etc for me. Bell's were consistently the worst (very slow, lots of time-outs, etc.).

If this means performance gets even better, I'm happy!



TSI Gabe
Router of Packets
Premium,VIP
join:2007-01-03
Gatineau, QC
kudos:7
reply to nbinont

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.
--
TSI Gabe - TekSavvy Solutions Inc.
Authorized TSI employee ( »TekSavvy FAQ »Official support in the forum )



nitzguy
Premium
join:2002-07-11
Sudbury, ON
reply to TSI Gabe

said by TSI Gabe:

No that's just one of the DNS Servers that's behind the cluster of DNS servers...please stop testing against it because it was just for testing...

I never tested against it to begin with .

Was just curious....when I worked for a previous cable company, they had 4 DNS servers to autheticate, and it was always the 4th one that had the best results...presumably because it had the lowest load...so I set it as the primary manually....

Just was wondering if this was the case here... does .22 get more usage than .170 Gabe?


Jon111

@teksavvy.com
reply to TSI Gabe

Nice results on the DNS servers.

Where are they located? Are they in different sites etc for redundancy?


mlord

join:2006-11-05
Nepean, ON
kudos:13
Reviews:
·Start Communicat..
reply to TSI Gabe

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,VIP
join:2006-06-23
Chatham, ON
kudos:28

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
--
Marc - CEO/TekSavvy


AkFubar
Admittedly, A Teksavvy Fan

join:2005-02-28
Toronto CAN.

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


nbinont

join:2011-03-13
kudos:2
Reviews:
·Start Communicat..
·TekSavvy Cable
reply 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,VIP
join:2006-06-23
Chatham, ON
kudos:28
reply 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.
--
Marc - CEO/TekSavvy



TSI Marc
Premium,VIP
join:2006-06-23
Chatham, ON
kudos:28
reply 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.
--
Marc - CEO/TekSavvy

nbinont

join:2011-03-13
kudos:2
Reviews:
·Start Communicat..
·TekSavvy Cable
reply 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,VIP
join:2007-01-03
Gatineau, QC
kudos:7
reply to TSI Marc

Are you saying this is still happening now?


nbinont

join:2011-03-13
kudos:2
Reviews:
·Start Communicat..
·TekSavvy Cable
reply to TSI Marc

said by TSI Marc:

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

Yes, but the first time I believe the dig command was was not going to the right server: »Re: [Cable] Slow DNS resolution for site on Teksavvy

And this problem happens regularly. but only on TSI. Very repeatable.

nbinont

join:2011-03-13
kudos:2
Reviews:
·Start Communicat..
·TekSavvy Cable
reply to TSI Gabe

said by TSI Gabe:

Are you saying this is still happening now?

Yep, for the past 8 months. Everyday


TSI Gabe
Router of Packets
Premium,VIP
join:2007-01-03
Gatineau, QC
kudos:7

K...honestly this is going to be hard to reproduce now that we are running other DNS servers...I guess keep me posted if it happens again and I'll take another look. Since right now I'm able to resolve those domains just fine.


jstory

join:2011-02-05
New Westminster, BC
reply to TSI Gabe

Just did.

Got a query response time of 76 msec and 75 msec, respectively, compared to 33 msec for 8.8.8.8.

mtr reports a ping of 13 msec, so maybe the server is just under heavy load.



TSI Marc
Premium,VIP
join:2006-06-23
Chatham, ON
kudos:28
reply to nbinont

k, I've asked Gabe to look into it more closely. I'm sure it's something logical we just need to find what it is.
--
Marc - CEO/TekSavvy


nbinont

join:2011-03-13
kudos:2
Reviews:
·Start Communicat..
·TekSavvy Cable
reply to TSI Gabe

said by TSI Gabe:

K...honestly this is going to be hard to reproduce now that we are running other DNS servers...I guess keep me posted if it happens again and I'll take another look. Since right now I'm able to resolve those domains just fine.

Thanks! I'll follow up and try to reproduce it.


TSI Marc
Premium,VIP
join:2006-06-23
Chatham, ON
kudos:28
reply to jstory

said by jstory:

Just did.

Got a query response time of 76 msec and 75 msec, respectively, compared to 33 msec for 8.8.8.8.

mtr reports a ping of 13 msec, so maybe the server is just under heavy load.

Gabe responded to you earlier. you have to use the Vancouver DNS servers since you're in BC..

That's because Vancouver has separate DNS servers.

You need to use 76.10.191.198 & 199 (these servers are not yet updated though)

we too can make our IPs respond no matter where you are but we just haven't done that.. there's no real need.

Google has that 8.8.8.8 block anycasted.. it's a routing trick.. that make all the routers think that IP is really close but in fact there are srvers everywhere with the same IP...
--
Marc - CEO/TekSavvy


Mike2009

join:2009-01-13
Ottawa, ON
kudos:3
Reviews:
·TekSavvy DSL
reply to HiVolt

said by HiVolt:

said by mlord:

Same here.

Same thing I've experienced...

Me too that's why I switched to using google a couple of years ago. I'll try out the TSI ones again.


NytOwl

join:2012-09-27
canada
reply to TSI Gabe

A nifty tool for those interested in benchmarking DNS servers more from their connection(s), and/or comparing more alternatives to TSI's own:

»www.grc.com/dns/benchmark.htm

I haven't ran it yet, myself, but I will once I eventually get my network setup all sorted out.



Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23

1 recommendation

reply to TSI Marc

said by TSI Marc:

Google has that 8.8.8.8 block anycasted.. it's a routing trick.. that make all the routers think that IP is really close but in fact there are srvers everywhere with the same IP...

There's no reason TSI couldn't anycast the DNS server IPs so that the same DNS IPs are used anywhere in TSI's territory :P Of course, that's kind of pointless since the vast majority of people use DHCP/PPPoE to automatically set the DNS servers anyhow. Most of the people setting theirs by hand are DNS ricers :P
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org


TSI Marc
Premium,VIP
join:2006-06-23
Chatham, ON
kudos:28

well.. there is one good reason.. and well, it's that it would take a bit of lifting to do it and make sure it's done right and for what? not much value..

we'd have to move everything else off that class C...
--
Marc - CEO/TekSavvy


nbinont

join:2011-03-13
kudos:2
Reviews:
·Start Communicat..
·TekSavvy Cable
reply to nbinont

said by nbinont:

said by TSI Gabe:

K...honestly this is going to be hard to reproduce now that we are running other DNS servers...I guess keep me posted if it happens again and I'll take another look. Since right now I'm able to resolve those domains just fine.

Thanks! I'll follow up and try to reproduce it.

Well, it seems like whatever Gabe did over the last week has fixed it for me! I verified that it was still acting up a few days ago (and it was), but tonight it seems to be resolving correctly the first time.

I waited for the cached entry to expire in TSI's DNS server, then asked it to resolve the site again. Last week it would fail a few times before finally getting something for the cache, and then be good until the cache expired again.

Tonight, after the cache expired it worked the first time. Waited for the cache to expire again (30 min expiry in this case), and tried again. Success again!

I assume I must be on one of Gabe's new DNS servers - and they seem to be working well!

Guess I'll have to go update my review...

Bugblndr

join:2010-03-02
Burlington, ON

Good news, time to change things up on my setup a bit and see for myself.


mlord

join:2006-11-05
Nepean, ON
kudos:13
Reviews:
·Start Communicat..
reply to nbinont

said by TSI Marc:

Yes, but the first time I believe the dig command was was not going to the right server:
»Re: [Cable] Slow DNS resolution for site on Teksavvy

You do realize that only the originator (and TSI) can read threads in TSI Direct, right? Not the rest of us, so posting links to those threads doesn't help anyone here.


TSI Marc
Premium,VIP
join:2006-06-23
Chatham, ON
kudos:28

said by mlord:

said by TSI Marc:

Yes, but the first time I believe the dig command was was not going to the right server:
»Re: [Cable] Slow DNS resolution for site on Teksavvy

You do realize that only the originator (and TSI) can read threads in TSI Direct, right? Not the rest of us, so posting links to those threads doesn't help anyone here.

yeah hehe AkFubar pointed that out to me too.. hehe I didn't realise at the time.. looks like nbinont's issue is solved now too. so it's all good
--
Marc - CEO/TekSavvy


koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23
reply to TSI Gabe

I'm not a Teksavvy customer, but I have a question -- one which after scouring the Internet (assuming what you're using is namebench) nobody has asked.

What on earth does the vertical axis represent? It just says "%". Percentage of what? Packet loss? DNS query rejection (NXDOMAIN, or other error)?

Basically that graph doesn't mean anything unless it's explained 1) where the data is coming from, 2) the exact test being used, and 3) what each axis represents.

For example, namebench.py can send 250 queries to a DNS server. That's nice -- is that 250 concurrent lookups per second? Is that 250 queries total and then it graphs the response time? If the latter, then shouldn't the X axis be query number and the Y axis be response time (in milliseconds), with the visual results being a "scatter graph" followed by a line drawn which indicates the average median?

Surely I can't be the only one questioning what on earth that thing is actually showing.

Otherwise, if I take it to mean "percentage of queries and how long they took to be answered", it looks to me like TSI's servers are taking between 60-200ms about 70% of the time, and 10-20ms the remaining 30% of the time. While comparatively, Google's ervers are taking between 60-200ms about 80% of the time, and 20-30ms the remaining 20% of the time. And to me, that isn't impressive (if anything the results should be the opposite -- first-time query should be slow, but subsequent queries for the same NS/A/PTR/etc. should return almost instantly due to record caching, assuming all recursive records involved don't have stupid TTLs like 1 second. )

Let me show you what actual kernel developers working on UDP stacks tend to graph when it comes to nameserver performance:

»people.freebsd.org/~kris/scaling/bind-pt.png
»people.freebsd.org/~kris/scaling···gige.png
»people.freebsd.org/~kris/scaling···pt-2.png
»people.freebsd.org/~kris/scaling···-nsd.png

Welcome to why just blindly dumping "pretty pictures" isn't helpful without concise (and precise) documentation alongside.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.



TSI Marc
Premium,VIP
join:2006-06-23
Chatham, ON
kudos:28

I'm sure Gabe will chime in but I think it's pretty straight forward what the graph says...

85-90% of queries take 10ms to return a request and all requests always take less then 200ms...

your graphs show queries per second and load.. we're highlighting how quickly a query is returned not how many it can return which is also an important stat no doubt but given we have 4 servers.. load is less of an issue for us.
--
Marc - CEO/TekSavvy



koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23

I don't find this graph straight-forward in any way shape or form.

"85-90% of all queries take 10ms to get a result". Okay, that's because you look at the graph and see that the point where the graph "shoots off horizontally" starts at 85%, with the vertical axis being at 10ms, correct? That's the only way I can see how you reached that conclusion.

Except if you apply the same logic to the data shown on the rights side of the graph, you could safely say that 97% of all queries took 200ms to get a result...

The following graph (X axis = duration, Y axis = nameserver IP) makes perfect sense but doesn't really provide any hard data, though as I said, that one does make sense. It's the first graph that doesn't.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.