DNS

Types of DNS records

CM.com uses two types of DNS records to route SIP traffic: A-records and SRV-records.

A-records are simple: a name mapped to an IP address. CM.com publishes at least two IP addresses per region (see Outbound calling on the SIP Trunking Knowledge Center page). Client software (PBX, softphone) picks one after the query — this is called client-side (DNS) load balancing.

SRV-records are more advanced and also support multiple records per name, but carry more information about how to reach a service. The key difference is the queried name itself: SIP clients prepend the transport protocol and service type. For example, entering nl.voip.cm.com as your server name causes the client to query _udp._sip.nl.voip.cm.com_udp for transport, _sip for protocol. Currently, only UDP and TLS are advertised; TCP is not available (a client will infer this when its TCP query returns nothing).

Each SRV-record includes a weight and priority, which guide load balancing and failover — clients should distribute traffic across endpoints based on weight, and use priority to determine failover order. This is a client-side convention, not enforced by CM.com. SRV-records also specify the correct ports: 5060 for UDP, 5061 for TLS.

CM.com supports both record types to accommodate different clients. Most modern clients support and prefer SRV-records; older clients that don't fall back to A-records. If your client supports neither, use the IP addresses listed in the Voice Management App or your SIP account tech form — but implementing some form of client-side load balancing is still recommended.

DNS vs IPs

DNS and IP are sometimes seen as separate concepts, but they're not. Your connection to your SIP trunk at CM.com is always over IP — DNS is simply a layer on top that acts as a human-readable shortcut for identifying internet services.

When your client contacts CM.com , it sends the SIP message directly to an IP address. Using DNS adds one extra step beforehand: your client queries the DNS record to retrieve an IP address (possibly chosen randomly based on weight or priority), then sends the SIP message to that address.

The main benefit of DNS is flexibility. Because the hostname CM.com can point to a different IP at any moment, we can enable seamless failovers during emergencies or planned maintenance. For this reason, CM.com always recommends using DNS records rather than hardcoded IP addresses.

DNS and TTL

DNS records are cached by the client to speed up subsequent requests. So if you send multiple SIP messages to your CM.com SIP trunk, the DNS records are queried only once and then reused.

This cache isn't indefinite — it expires after the Time To Live (TTL) elapses. Each DNS response includes a TTL parameter specifying how many seconds the client should remember it. CM.com sets this TTL short so that if a change is needed, all clients forget the old response quickly and adapt swiftly. You don't need to do anything — clients handle the TTL automatically.

Outbound DNS

If your client supports SRV records, it will automatically retrieve all the information needed to set up connectivity for your CM.com SIP account. If your client only supports A records, you will need to manually enter the SIP port, which can be found in the tech form for your SIP account.

How DNS Resolution Works for SIP clients

  • A records: Your client queries the DNS and randomly selects one IP address from the response. This IP is cached until the TTL expires, after which the process repeats.

  • SRV records: Your client caches all IP addresses from the response until the TTL expires. For each SIP request, an IP address is selected at random from this cache (weighted according to the SRV record), meaning different messages may be sent to different CM.com IP addresses.

For example, your client might send a REGISTER message to one of our gateways, then send an INVITE for a new call to nl.voip.cm.com that resolves to a different gateway. This is expected behavior — all our gateways operate together seamlessly. Once a SIP dialog is established, subsequent requests within that dialog are routed to the same gateway, based on the Record-Route headers.

Inbound DNS

CM.com supports DNS SRV records for inbound calling. These can be added as hosts in a Distribution Group within the Voice Management App.

When entering a record, use only the hostname (e.g., pbx.domain.com) — do not include the transport protocol or SIP prefix (e.g., not _sip._udp.pbx.domain.com).

Important: Use one IP per DNS SRV record

Each DNS SRV record should point to only one IP or endpoint. This is because our routers mark the entire DNS name as inactive if an OPTIONS message goes unanswered or an INVITE times out. If one endpoint behind a DNS SRV name goes down, calls will stop routing to that name entirely — no traffic resumes until an OPTIONS request receives a positive response from an endpoint behind it again.

Since we already monitor the availability of each endpoint within a Distribution Group individually, this provides built-in redundancy. For this reason, each DNS SRV record should resolve to a single IP. If redundancy across multiple endpoints is needed, use separate DNS SRV names for each one.

Example:
Recommended:

sbc1.company.com → 1.1.1.1

sbc2.company.com → 1.1.1.2

Not recommended:

sbc.company.com → 1.1.1.1 and 1.1.1.2