|
to TSI Gabe
Re: Google DNS versus ourscallcentric.com
or
srv.callcentric.com |
|
wally_walrus |
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 |
|
nekoAll Hail Canada Premium Member join:2006-08-11 Canada |
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 DNSCallcentric DDOS Mega Thread |
|
mlord join:2006-11-05 Kanata, ON |
mlord
Member
2012-Oct-21 2:24 pm
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 |
|
nekoAll Hail Canada Premium Member join:2006-08-11 Canada |
neko
Premium Member
2012-Oct-21 2:57 pm
Here is a guy explaining what's happening: » DNS SRV - CallcentricHopefully 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. |
|
mlord join:2006-11-05 Kanata, ON |
mlord
Member
2012-Oct-21 3:37 pm
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 |
|
mlord |
mlord
Member
2012-Oct-21 3:45 pm
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 |
|
nekoAll Hail Canada Premium Member join:2006-08-11 Canada |
neko
Premium Member
2012-Oct-21 5:54 pm
said by mlord: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). So it is their problem, & not ours? That's all we wanted Gabe to know. That Tek's DNS doesn't work for our VOIP device settings. Hopefully a fix can be made. |
|
mlord join:2006-11-05 Kanata, ON |
mlord
Member
2012-Oct-21 6:21 pm
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. |
|
TSI GabeRouter of Packets Premium Member join:2007-01-03 Gatineau, QC |
TSI Gabe
Premium Member
2012-Oct-21 7:05 pm
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. |
|
jabley join:2012-10-21 London, ON |
jabley
Member
2012-Oct-21 8:24 pm
There are several things going on, here.
The resource record set (RRSet) that the ATA is looking for is unusually large. Large responses in the DNS are generally accommodated by either negotiating a large UDP response buffer with EDNS0 (see RFC 2671) or by setting the truncate bit (TC) to 1 in a response and forcing a second DNS request using TCP.
Both these approaches have problems. Large UDP buffer sizes result in fragmentation, and fragmentation can be problematic. Many firewalls and other middleware make bad assumptions about 53/tcp, and hence TCP requests don't always work.
So, solution 1: if I was callcentral, I would be reducing my response to that particular query to ensure that it fits in a 512 byte DNS response message without truncation. If they chose their server names more carefully they could still pack a good number of resource records in the ANSWER section by taking better advantage of label compression.
The ATA described here appears not to support EDNS0 or TCP, so it has no capability of receiving large (complete) DNS responses. Not supporting TCP means not following the specification. The ATA is definitively broken, here. It violates RFC 1035. (I realise it's not unique in that. There are lots of bad DNS implementations in the world.)
Solution 2: fix the ATA. It's broken. The fact that it has ever worked is a happy accident.
BIND9's behaviour when it falls back to TCP is to set TC=1 in the response header, and to populate the answer section with as much as will fit. This response is intended to be interpreted as "this is not an accurate response, but here is a partial answer and you should use TCP to get the rest of it".
Unbound's behaviour is not to return partial responses. It says "I can't give you a complete response, and I'm not going to risk giving you a partial answer because that might be bad, so you need to use TCP".
Needless to say, this level of detail (how to populate the ANSWER section in a truncated response) is not really specified in RFC 1035, which is old. Technically, I think it's fair to say that both unbound and BIND9 are following the specification, as far as it goes.
BIND9's behaviour here is more forgiving of the broken DNS code in the ATA. I don't see an option in unbound to emulate the BIND9 approach to this.
Solution 3: choose different nameservers that behave as BIND9 does.
Unbound is good, polished software in my opinion. It has performance advantages and is far harder to fool with cache poisoning attacks than BIND9. It's hard to argue that the correct solution here is to replace unbound with BIND9; in effect, that would be throwing out the benefits of unbound for all users simply to accommodate one buggy ATA that is used by a tiny minority. |
|
mlord join:2006-11-05 Kanata, ON |
to TSI Gabe
said by TSI Gabe: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. Sounds like the Right Crowd to find a solution with, but I'm with you on this one -- risky to modify the DNS behaviour to accommodate a clueless voip provider, especially as there's a definite risk of breaking other stuff. Don't forget to go out for some Real Beef BBQ down that way, and let us all know if you manage to reverse engineer the famous fountains down town (if you grok the pattern, you can stride up the middle without getting wet!). Cheers! |
|
|
to jabley
said by jabley:simply to accommodate one buggy ATA that is used by a tiny minority. I don't think anyone has specifically mentioned any ATA models yet in this thread. For me personally, I'm using a Linksys PAP2T which is probably the most widely deployed ATA for home users. I'm not saying it is good or that Linksys/Cisco isn't known for having buggy devices. They are also not likely to fix it in a new firmware at this point. |
|
|
+1. Even though some / most models are "buggy" they are widely used, so efforts should be made to support them. I am using an SPA-3102 |
|
|
mlord join:2006-11-05 Kanata, ON |
mlord
Member
2012-Oct-22 10:03 am
said by wally_walrus:+1. Even though some / most models are "buggy" they are widely used, so efforts should be made to support them. +100 The PAP2T are very likely the most common "non locked" ATA devices out there, with their cousins the SPA-3102 also fairly prevalent. So it's not feasible to simply ignore them. Callcentric.com needs to do better. Meanwhile, anyone affected by this can just use a different DNS service, or run a copy of bind9 locally to relay from Teksavvy DNS without the issue of Teksavvy DNS. I just checked here, and my local bind9 service does return partial results just fine, but the stripped down DNS in my router does not. I imagine that folks running OpenWRT on their routers would have the option of adding bind9 service onto those, which would take care of it as well. Cheers |
|
mlord 1 edit |
mlord
Member
2012-Oct-22 10:07 am
said by mlord:Meanwhile, anyone affected by this can just use a different DNS service, or run a copy of bind9 locally to relay from Teksavvy DNS without the issue of Teksavvy DNS. Or maybe TSI Gabe could channel the spirit of Teksavvy Past, and run bind9 on one server internally (doesn't need to be accessible outside of Teksavvy), and have it act as the authority for Callcentric.com for use by Teksavvy's public DNS servers. Hacky, and there are probably other similar/better workarounds that TSI Gabe could dream up. |
|
TSI GabeRouter of Packets Premium Member join:2007-01-03 Gatineau, QC |
TSI Gabe
Premium Member
2012-Oct-22 10:43 am
Well jabley is with me at NANOG and his reply here is what came out of the conversation we had. The reality here is that clearcable is knowingly serving a large RRSET that doesn't fit in a 512 byte buffer and they also know that this results in a half broken DNS reply when using a few well known ATAs. I've also talked to a few more people, some of them that work for TLDs and to be honest the opinion that I've heard loud and clear so far is what the heck is clearcable doing. By far the easiest way to fix this would be for clearcable to shorten the RRSET reply by using the various methods that jabley highlighted above. While I'm not against "fixing" this in the spirit of being nice. This issue is only specific to using certain ATAs on the clearcable service. |
|
mlord join:2006-11-05 Kanata, ON |
mlord
Member
2012-Oct-22 10:52 am
+1 |
|
34764170 (banned) join:2007-09-06 Etobicoke, ON |
to TSI Gabe
*sad Mac face* kinda disappointed to see TSI's resolvers failing OARC's DNS reply size test.
Boo Google and OpenDNS.
TSI $ dig @206.248.154.22 +short rs.dns-oarc.net txt rst.x1002.rs.dns-oarc.net. rst.x1007.rs.dns-oarc.net. rst.x1012.rs.dns-oarc.net. rst.x1257.x1012.rs.dns-oarc.net. rst.x1228.x1012.rs.dns-oarc.net.
Level 3 $ dig @4.2.2.2 +short rs.dns-oarc.net txt rst.x3827.rs.dns-oarc.net. rst.x3837.x3827.rs.dns-oarc.net. rst.x3843.x3837.x3827.rs.dns-oarc.net. "192.221.139.217 DNS reply size limit is at least 3843" "192.221.139.217 sent EDNS buffer size 4096" "Tested at 2012-10-22 21:01:17 UTC"
home; dnsmasq -> BIND 9.9 (DNS64) -> my Unbound recursive resolver $ dig @192.168.3.2 +short rs.dns-oarc.net txt rst.x3827.rs.dns-oarc.net. rst.x4049.x3827.rs.dns-oarc.net. rst.x4055.x4049.x3827.rs.dns-oarc.net. "2001:470:1d:8c::13 DNS reply size limit is at least 4055" "Tested at 2012-10-22 21:01:58 UTC" "2001:470:1d:8c::13 sent EDNS buffer size 4096" |
|
34764170 |
to mlord
said by mlord:Callcentric.com needs to do better. No, they don't. It's BYOD. You are responsible if you want to bring broken equipment to their service. If you want to use broken crap then you can support it. |
|
TSI Marc Premium Member join:2006-06-23 Chatham, ON |
to TSI Gabe
Gabe, what I don't understand is how come they're not signing up for our TekTalk service? |
|
GuspazGuspaz MVM join:2001-11-05 Montreal, QC |
to TSI Gabe
Well, TekTalk is a residential service, and ClearCable is an enterprise service provider, so they're not really comparable products. |
|
|
to TSI Marc
Marc,
When your prices and service are going to match Callcentric's I'll switch in an instant |
|
TSI Marc Premium Member join:2006-06-23 Chatham, ON |
to Guspaz
We have all we need to do business phone... Expanded the MetaSwitch a month ago to do it.. Just playing around with it all to see what we'd like to offer. |
|
TSI Marc |
to wally_walrus
What are you paying with them? |
|
|
All PAYG for the last month:
Total: 289 min 0 min 141 min $5.5818 $0.0000 $5.5818 |
|
TSI Marc Premium Member join:2006-06-23 Chatham, ON |
TSI Marc
Premium Member
2012-Oct-22 8:50 pm
What package are you getting from them? |
|
1 edit |
No package at all - I pay by the minute (only for what I use), and - BEST THING - the balance never expires
Their rates are at callcentric.com |
|
nekoAll Hail Canada Premium Member join:2006-08-11 Canada |
to TSI Marc
I'm on PAYG, too. About $5 every month.
Their back-end portal is fantastic with the call filtering options to prevent spam, re-route calls, free incoming/outgoing SIP, free voicemail. The list of features is outstanding.
My favorite feature is the call filtering. They even support wilcard numbers which add a granularity to the service that I find very useful.
They are rated as the best VOIP provider on DSLR. |
|
|
to TSI Marc
I'm also on the pay as you go with CallCentric. I pay $1.95 for my DID, $1.50 for E911, and most calling is about $0.015 per minute. Most months costs me about $5. I prepay with paypal on my account usually $50 and lasts at least a year, so its also one more bill I dont have to think about. They will send me an email when the balance in my account is low.
Also, as others have mentioned, the customer portal is really good. The amount of options is great. Rarely do I get telemarketers or credit cards scams calling, but if they do, its only 30 seconds to add them to a block list. |
|