You are here: Installation > Planning and prerequisites > DNS record examples

DNS record examples

This section describes the DNS records required for endpoints, federated Lync / Skype for Business environments and Infinity Connect clients to access Pexip Infinity services.

You can use the tool at http://dns.pexip.com to lookup and check SRV records for a domain.

Enabling endpoints to discover Conferencing Nodes

The following examples show the records that are required in DNS for endpoints to discover Pexip Infinity Conferencing Nodes.

It shows example DNS A and SRV records for the domain example.com to allow:

  • SIP and H.323 endpoint registration messages to be routed to Pexip Infinity
  • calls from non-registered SIP and H.323 endpoints to be routed to Pexip Infinity

If you have multiple Conferencing Nodes, you must set up DNS A and SRV records for each node.

Host DNS A-records

This example assumes there are 2 Conferencing Nodes, thus 2 DNS A-records are required.

Hostname Host IP address
conf01.example.com. 198.51.100.40
conf02.example.com. 198.51.100.41

In your actual deployment, both the Hostname and Host IP address should be changed to use the real names and addresses of your Conferencing Nodes.

DNS SRV records

The following DNS SRV records are required for H.323 and SIP services. For each service there should be one record per host (Conferencing Node). Therefore, in this example, there are 2 records per service — one for each target host — conf01.example.com and conf02.example.com.

Name Service Protocol Priority Weight Port Target host
example.com.
example.com.
h323cs
h323cs
tcp
tcp
10
10
10
10
1720
1720
conf01.example.com.
conf02.example.com.
example.com.
example.com.
h323ls
h323ls
udp
udp
10
10
10
10
1719
1719
conf01.example.com.
conf02.example.com.
example.com.
example.com.
h323rs
h323rs
udp
udp
10
10
10
10
1719
1719
conf01.example.com.
conf02.example.com.
example.com.
example.com.
sip
sip
tcp
tcp
10
10
10
10
5060
5060
conf01.example.com.
conf02.example.com.
example.com.
example.com.
sip
sip
udp *
udp *
10
10
10
10
5060
5060
conf01.example.com.
conf02.example.com.
example.com.
example.com.
sips
sips
tcp
tcp
10
10
10
10
5061
5061
conf01.example.com.
conf02.example.com.
* SIP UDP is disabled on Pexip Infinity by default.

In your actual deployment, both the Name and the Target host should be changed to use the real domain name and host names of your Conferencing Nodes.

In these examples, the DNS records would be:

_h323cs._tcp.example.com. 86400 IN SRV 10 10 1720 conf01.example.com.
_h323cs._tcp.example.com. 86400 IN SRV 10 10 1720 conf02.example.com.

_h323ls._udp.example.com. 86400 IN SRV 10 10 1719 conf01.example.com.
_h323ls._udp.example.com. 86400 IN SRV 10 10 1719 conf02.example.com.

_h323rs._udp.example.com. 86400 IN SRV 10 10 1719 conf01.example.com.
_h323rs._udp.example.com. 86400 IN SRV 10 10 1719 conf02.example.com.

_sip._tcp.example.com.    86400 IN SRV 10 10 5060 conf01.example.com.
_sip._tcp.example.com.    86400 IN SRV 10 10 5060 conf02.example.com.

_sip._udp.example.com.    86400 IN SRV 10 10 5060 conf01.example.com.
_sip._udp.example.com.    86400 IN SRV 10 10 5060 conf02.example.com.

_sips._tcp.example.com.   86400 IN SRV 10 10 5061 conf01.example.com.
_sips._tcp.example.com.   86400 IN SRV 10 10 5061 conf02.example.com.

conf01.example.com.       86400 IN A 198.51.100.40
conf02.example.com.       86400 IN A 198.51.100.41

If the ability to implement geographically-aware DNS exists, then different weights and priorities could be set on the SRV records for different locations. For example, if there is both a European and a North American site, each with separate DNS servers, the European one could return European Pexip nodes at a higher priority than the North American nodes, and vice versa.

Enabling direct federation with remote Lync / Skype for Business environments

To ensure that calls from remote Lync / Skype for Business environments are routed to your Conferencing Node, a DNS SRV record in the format _sipfederationtls._tcp.<domain> must be created.

Example

Assume that the following _sipfederationtls._tcp.example.com DNS SRV and associated A-record have been created:

_sipfederationtls._tcp.example.com. 86400 IN SRV 1 100 5061 sip.example.com.
sip.example.com.                    86400 IN A 198.51.100.40

The SRV record points to the DNS A‑record sip.example.com (this is a typical convention in Lync / Skype for Business environments), port 5061, with a priority of 1 and a weight of 100. In other words, it tells Lync / Skype for Business to send its TLS requests to sip.example.com on TCP port 5061. The A-record then resolves sip.example.com to the node's IP address (198.51.100.40).

In your actual deployment, the domain and host IP address should be changed to use the real name and address of your Conferencing Node.

Note that the domain name used in the SRV record has to match the domain in the corresponding A-record. This is required due to the trust model for Lync/SfB federation. Using our example:

  • _sipfederationtls._tcp.example.com must use the same domain as sip.example.com
  • you cannot, for example, configure the _sipfederationtls._tcp.example.com SRV record to point to sip.video.example.com or conf01.otherdomain.com).

For more information, see Pexip Infinity configuration for public DMZ deployments with remote Lync / Skype for Business environments.

Enabling access from the Infinity Connect Mobile client and the Infinity Connect desktop client

To enable participants to connect to conferences within your deployment using the Infinity Connect desktop client or Infinity Connect Mobile client, you must provide a DNS lookup so that these clients know which host to contact. The host will typically be a reverse proxy (for deployments where Conferencing Nodes are located within a private network), but it can also be a public-facing Conferencing Node.

To enable access from these desktop and mobile clients, each domain used in aliases in your deployment must either have an SRV record for _pexapp._tcp.<domain>, or resolve directly to the IP address of a reverse proxy or a public-facing Conferencing Node.

The SRV records for _pexapp._tcp.<domain> should always:

  • point to an FQDN which must be valid for the TLS certificate on the target Conferencing Nodes or reverse proxy
  • reference port 443 on the host.

Example

Assume that the following _pexapp._tcp.example.com DNS SRV records have been created:

_pexapp._tcp.example.com. 86400 IN SRV 10 100 443 proxy1.example.com.
_pexapp._tcp.example.com. 86400 IN SRV 20 100 443 proxy2.example.com.

These point to the DNS A‑records proxy1.example.com, port 443 (HTTPS), with a priority of 10 and a weight of 100, and proxy2.example.com, port 443, with a relatively lower priority of 20 and a weight of 100.

  • This tells the Infinity Connect desktop client to initially send its HTTP requests to host proxy1.example.com (our primary reverse proxy server) on TCP port 443. The desktop client will also try to use host proxy2.example.com (our fallback server) if it cannot contact proxy1.
  • The Infinity Connect Mobile client will send its HTTP requests either to proxy1.example.com or to proxy2.example.com, depending on the order of the returned SRV records. If it fails to contact the first host, it will not attempt to contact the second host address.

For more information, see Setting up DNS records for Infinity Connect Mobile client and Infinity Connect desktop client use.