Many people don't like using DNS to route VoIP traffic. I suspect other distributed applications have similar questions. They've had too many problems with DNS being reliable, or too slow for real-time call processing. In addition, many VoIP carriers use private IP addresses for their servers! This breaks Internet Engineering principles, and severely complicates name-to-address lookup services.
So instead of using DNS, they usually go with one of these options:
(a) Don't use DNS at all; instead, just do everything with IP addresses. The upside is that there aren't and DNS or directory lookups. The downsides are that they lose a level of indirection, which makes the system less flexible for reconfiguration. They also lose the mnemonic that makes the system manageable; traffic is now going to "4.2.2.2" instead of "ns1.level3.net"
(b) Use /etc/hosts-type name lookups; i.e., they have an OS-level or application-level lookup service that maps names to IP addresses. The problem here is most name-to-IP-address lookups only support the equivalent of a single DNS A record. They can't do sophisticated records, like MX records, or SRV records.
Today, I learned that some folks are using a third option in a leading VoIP Carrier Softswitch system with a Quebecoise accent:
(c) "namedefs", a fake DNS zone file integrated into the application itself. This "namedefs" file vaguely resembles the DNS zonefile, but doesn't include an SOA (Start of Authority) section. It supports more complex lookups, like SRV, but doesn't seem to support MX, and has an extremely restricted syntax. The application consults this file before accessing the
The "namedefs" is a new idea. It gives the application the power of certain fancier lookups, but it can contradict DNS or /etc/hosts lookups. It's only used by the VoIP Softswitch application, so it's possible that the application will use these lookups, while another component will use DNS or /etc/hosts to do related lookups.
Why duplicate the functionality of DNS? Network Politics, probably. The DNS servers are usually operated by the ISP / Data group, and the VoIP softswitch is operated by the Switch Engineering and Translations groups. Fred Brooks predicted this in his book, "The Mythical Man Month: Essays on Software Engineering", first published in 1975. The organization of Software Systems will match that of the Business Organization that created them.
Modern VoIP Networks are large software systems and fit this model neatly. The sad thing is that DNS already provides a mechanism for this organizational boundary: DNS zones and delegation.
I haven't had time to analyze this new approach in depth. But my hunch is that it's not a good step. Rather than bypassing or avoiding DNS, Engineers should have the courage to make DNS work properly --
1. Setup dedicated, redundant DNS servers for important applications.
2. Use DNS zone delegation to give complete control over important applications.
3. Avoid breaking Internet Engineering rules: VoIP servers should have public IP addresses, and be integrated into the global DNS hierarchy, even if they're protected by firewalls.
4. Learn how to manage zone files safely.
