O Canada! > Canadian > TekSavvy > Google DNS versus ours

reply to koitsu

Re: Google DNS versus ours

reply to koitsu

reply to TSI Gabe
Interesting and thanks for the information....

However, it is still always better to use a 3rd party DNS service anyway (even at a slight ms hit) because;

1) Privacy reasons. You want to fragment your services as much as possible.

2) Larger DNS providers like OpenDNS have larger CDN networks in place than a local ISP running a few Akamai servers.

Just my 2 cents....
--
www.613websites.com ● Budget Canadian Web Design and Hosting

interesting point, I'd add to that you can also use DNScrypt with opendns
Here's the thread I posted about it: »DNSCrypt for Teksavvy users?

Gabe is there any chance you could implement DNScrypt with the new DNS servers? I'm hoping to make use of the new Tek DNS servers

Thanks!

reply to TSI Gabe
Hello TSI Gabe,

Could you please tell if TSI DNS servers properly respond to DNS SRV queries as needed for correct SIP support? My VoIP provider (Callcentric) are currently experiencing major issues, and one of their suggestion to mitigate impact was to use 3rd party DNS servers as some don't properly resolve DNS SRV queries. This is copied from their status update page:

Update 10/19 - DNS SRV

We have received reports that some users are having problems using our DNS SRV based servers.

This is specifically because the new list of servers returned is not properly parsed by some DNS servers due to the size of the information, or not being returned at all. As such, we recommend using different DNS servers in your router and/or device if you are experiencing problems.

We have tested the servers below and found that they resolve our SRV records properly:

xxx.xxx.xx.x
xxx.xxx.xx.x

+1

Same problem on my end. Had to use DNS servers supplied on CC's webpage, within my device, to resolve.

Using Teksavvy's DNS servers resulted in registration failure on my device.

I was having lots of trouble with callcentric as well. both their recommend opendns and teksavvy were failing. i had to disable these two options to get it working again.

Use DNS SRV
DNS SRV Auto Prefix

They say it should work with either DNS SRV or not, and mine is still using it and registers properly. Teksavvy's DNS weren't working with DNS SRY set to yes. When I changed to their recommended DNS servers in my 3102 it started working.

Can we have an detailed answer from Teksavvy on this one?

reply to TSI Marc
I've been re-testing TSI DNS since this thread began, and thus far it hasn't failed on any sites for us (a record for TSI DNS here), and seems plenty quick enough now.

So TSI is now number one on the "Forwarders" list for our local DNS.
Good stuff, guys!

I can take a look but it would be really useful if you guys could provide me with a hostname to test against.

callcentric.com

or

srv.callcentric.com

Also could you please provide us with a method to test for this in the future? I'd really like to have all devices behind my router use the default servers (hopefully Teksavvy), instead of configuring different DNS servers on each and every one

reply to TSI Gabe
callcentric.com works & resolves through Teksavvy DNS, but that isn't the recommended solution from CallCentric.

They recommend using: srv.callcentric.com

That does not get resolved & causes my device to fail in registering with CallCentric. I had to use different DNS in the configuration of my device to have it correctly resolve the srv.callcentric.com

As Wally_Walrus said, i'd prefer to have it resolve using Teksavvy DNS, than having to hardcode an alternate into my device.

For reference:

Callcentric Problems Using ISP Assigned DNS

Callcentric DDOS Mega Thread
--
...virtue gives you heraldry.

MMmm.. the problem appears to be not with Teksavvy, but rather with callcentric's DNS provider (telengy.net):

$ whois callcentric.com
...
Domain servers in listed order:
NS1.TELENGY.NET 66.193.176.41
NS2.TELENGY.NET 204.11.192.20
NS3.TELENGY.NET 204.11.192.68
...

$ nslookup
> server ns1.telengy.net
Default server: ns1.telengy.net
Address: 66.193.176.41#53

> callcentric.com
Server: ns1.telengy.net
Address: 66.193.176.41#53

Name: callcentric.com
Address: 204.11.192.22
Name: callcentric.com
Address: 204.11.192.23
Name: callcentric.com
Address: 204.11.192.31
Name: callcentric.com
Address: 204.11.192.34
Name: callcentric.com
Address: 204.11.192.35
Name: callcentric.com
Address: 204.11.192.36
Name: callcentric.com
Address: 204.11.192.37
Name: callcentric.com
Address: 204.11.192.38
Name: callcentric.com
Address: 204.11.192.39
Name: callcentric.com
Address: 204.11.192.135
Name: callcentric.com
Address: 204.11.192.159
Name: callcentric.com
Address: 204.11.192.160

> srv.callcentric.com
Server: ns1.telengy.net
Address: 66.193.176.41#53

Non-authoritative answer:
*** Can't find srv.callcentric.com: No answer

> server ns2.telengy.net
Default server: ns2.telengy.net
Address: 204.11.192.20#53

> srv.callcentric.com
Server: ns2.telengy.net
Address: 204.11.192.20#53

*** Can't find srv.callcentric.com: No answer

Here is a guy explaining what's happening:

»DNS SRV - Callcentric

Hopefully you'll understand what he's on about, as I do not.

All I know for sure is Tekk's DNS doesn't allow my device to register & make calls; using an alternate DNS provider does work.

I'm sorry I can't be more helpful, as I have no clue about all this stuff.
--
...virtue gives you heraldry.

The discussion at that link is NOT looking for srv.callcentric.com at all.
Instead, they are using _sip._udp.callcentric.com. for the hostname.

Perhaps that's part of your problem?
The (successful) query below is using Teksavvy DNS:

[~] dig @206.248.154.22 _sip._udp.callcentric.com SRV
;; Truncated, retrying in TCP mode.

; > DiG 9.7.0-P1 > @206.248.154.22 _sip._udp.callcentric.com SRV
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER- opcode: QUERY, status: NOERROR, id: 54216
;; flags: qr rd ra; QUERY: 1, ANSWER: 24, AUTHORITY: 3, ADDITIONAL: 12

;; QUESTION SECTION:
;_sip._udp.callcentric.com. IN SRV

;; ANSWER SECTION:
_sip._udp.callcentric.com. 51 IN SRV 20 0 5080 alpha1.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 5080 alpha2.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 5080 alpha3.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 5080 alpha4.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 5080 alpha5.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 5080 alpha6.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 5080 alpha7.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 5080 alpha8.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 5080 alpha9.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 5080 alpha10.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 5080 alpha11.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 5080 alpha12.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 10123 alpha1.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 10123 alpha2.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 10123 alpha3.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 10123 alpha4.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 10123 alpha5.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 10123 alpha6.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 10123 alpha7.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 10123 alpha8.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 10123 alpha9.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 10123 alpha10.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 10123 alpha11.callcentric.com.
_sip._udp.callcentric.com. 51 IN SRV 20 0 10123 alpha12.callcentric.com.

;; AUTHORITY SECTION:
callcentric.com. 58 IN NS ns2.telengy.net.
callcentric.com. 58 IN NS ns3.telengy.net.
callcentric.com. 58 IN NS ns1.telengy.net.

;; ADDITIONAL SECTION:
alpha1.callcentric.com. 51 IN A 204.11.192.22
alpha2.callcentric.com. 58 IN A 204.11.192.23
alpha3.callcentric.com. 58 IN A 204.11.192.31
alpha4.callcentric.com. 51 IN A 204.11.192.34
alpha5.callcentric.com. 51 IN A 204.11.192.35
alpha6.callcentric.com. 51 IN A 204.11.192.36
alpha7.callcentric.com. 51 IN A 204.11.192.37
alpha8.callcentric.com. 51 IN A 204.11.192.38
alpha9.callcentric.com. 51 IN A 204.11.192.39
alpha10.callcentric.com. 59 IN A 204.11.192.135
alpha11.callcentric.com. 51 IN A 204.11.192.159
alpha12.callcentric.com. 51 IN A 204.11.192.160

;; Query time: 16 msec
;; SERVER: 206.248.154.22#53(206.248.154.22)
;; WHEN: Sun Oct 21 15:37:16 2012
;; MSG SIZE rcvd: 1401

Ah, but even with the correct hostname (_sip._udp.callcentric.com), there's still a problem with Teksavvy DNS: they don't return ANY results when "truncating" the response. This prevents voip devices (ATAs) from working at all unless the device supports TCP DNS lookups (not all do).

[~] dig @206.248.154.22 _sip._udp.callcentric.com SRV +notcp +noignore

; > DiG 9.7.0-P1 > @206.248.154.22 _sip._udp.callcentric.com SRV +notcp +noignore
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER- opcode: QUERY, status: NOERROR, id: 32860
;; flags: qr tc rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_sip._udp.callcentric.com. IN SRV

;; Query time: 30 msec
;; SERVER: 206.248.154.22#53(206.248.154.22)
;; WHEN: Sun Oct 21 15:43:19 2012
;; MSG SIZE rcvd: 43

Well, the real problem is callcentric.com. putting "too much" data into their DNS entry. Teksavvy *could* help out by having their DNS return partial (truncated) results to the UDP query, but they're not required to by any internet standards.

honestly I kinda hate doing this but I agree with mlord... the problem is that the record is too large therefore requires the use of TCP....knowing that most ATAs don't support this they are kind of shooting themselves in the foot.

What's even more questionable is that they expect the DNS entry to be truncated...so why not enter fewer SRV records in to begin with to allow UDP to work?

I'm not saying I don't want to fix this...fixing it though on the other end would be IMO a big hack and not even sure that this would really be RFC compliant....

luckily though I'm at NANOG right now and am surrounded by geeks that deal with this on a daily basis...I'll ask around when I get the chance.
--
TSI Gabe - TekSavvy Solutions Inc.
Authorized TSI employee ( »TekSavvy FAQ »Official support in the forum )