Quote from: Judgeless on October 26, 2012, 03:06:47 PM
I got it working. There are having major DNS issues and they want you to force all devices like the Obi box to use their DNS servers and not your ISP.
I don't get it. If they would have mentioned this on their web site I would have fixed the issue and moved on.
No. CallCentric is NOT having major DNS issues. USERS of CallCentric services and some ATA devices are having major DNS issues after reconfiguring to use CallCentric's suggested setup to fend off the massive attack they're under.
In the beginning, like everyone else, CallCentric was using regular "A" records for DNS resolution to their proxy servers for registration. A DNS query by the USER'S device is a UDP packet and expects a UDP response because the overhead is low. The response contains one or two IP addresses of the proxy servers and the registration begins using those. Then came the huge denial of service attack that swamped their proxy servers.
CallCentric added memory and resources to their proxy servers, but it wasn't enough to fend off the attack. So, they started adding proxy servers. I think they're up to 20 or more by now. The also set up new DNS SRV type records to return a randomized list of the entire pool of servers. That will balance the load over the entire set of servers and they can continue to add servers as necessary to thwart the attack. They asked their users to reconfigure their SIP and ATA devices to request the new SRV type DNS records. (They continue to support the "A" record DNS queries, but those servers have little defense against the attack and are prone to overloading.)
Whereas the old "A" record DNS query responses were quite small, the new SRV responses are much larger because of the number of servers CallCentric has configured into the server pool. The new SRV response is too large to fit in a UDP packet. By protocol standards, when that happens, the DNS is supposed to mark the UDP response
truncated. It isn't defined whether a partial list of servers (whatever will fit) is to be returned in the UDP response or not. Some DNS servers include the partial response and some don't. The popular Google and OpenDNS servers do not. Most ISP provider DNS servers appear the include them.
What should happen is the device (i.e. OBI) sees the truncated flag and re-queries the DNS using TCP, which allows for a larger, multi-packet response. Unfortunately, most devices seem not have implemented this part of the DNS protocol. So, they are relying on the partial list of servers supplied in the truncated UDP response sent by
some DNS servers. CallCentric even provided the addresses of a couple of DNS servers they knew to "work" by supplying the truncated list.
Using the truncated partial list of proxy servers is much better than using the "A" record servers from a stability point of view, but not without problems. SIP devices re-register periodically. If the new partial list of randomly ordered servers doesn't include the currently registered server, the device will drop the registration and register on one of the new IP addresses. That leaves a small window with the device unregistered and no calls. I've heard that some devices are dumb enough to actually drop a call in progress when this happens, but I haven't seen it to know for sure.
So, the bottom line is CallCentric is adding servers in parallel with each other to fend off an attack. They have asked their users to use SRV type DNS requests to automatically load balance across the new set of servers. Different DNS servers behave differently when sending truncated UDP responses and many (most?) SIP and ATA devices don't properly implement TCP DNS queries in response to receiving a truncated UDP response.