Tech Docs

DNS record examples

This section describes the DNS records required to allow endpoints and 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

DNS A‑records are required for endpoints and clients to discover Pexip Infinity Conferencing Nodes. Separate, additional records that resolve to these DNS A‑records are required for SIP and H.323 endpoints, federated Skype for Business / Lync environments and Infinity Connect clients respectively.

The examples below show DNS A and SRV records for the domain vc.example.com to allow:

  • SIP and H.323 endpoint registration messages to be routed to Pexip Infinity
  • calls from SIP and H.323 endpoints to be routed to Pexip Infinity
  • calls from remote Skype for Business / Lync environments to Pexip Infinity
  • Infinity Connect desktop client and mobile clients for Android to register to Pexip Infinity
  • Infinity Connect clients to make calls 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
px01.vc.example.com. 198.51.100.40
px02.vc.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 for SIP and H.323 endpoints

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 — px01.vc.example.com and px02.vc.example.com.

Name Service Protocol Priority Weight Port Target host
vc.example.com.
vc.example.com.
h323cs
h323cs
tcp
tcp
10
10
10
10
1720
1720
px01.vc.example.com.
px02.vc.example.com.
vc.example.com.
vc.example.com.
h323ls
h323ls
udp
udp
10
10
10
10
1719
1719
px01.vc.example.com.
px02.vc.example.com.
vc.example.com.
vc.example.com.
h323rs
h323rs
udp
udp
10
10
10
10
1719
1719
px01.vc.example.com.
px02.vc.example.com.
vc.example.com.
vc.example.com.
sip
sip
tcp
tcp
10
10
10
10
5060
5060
px01.vc.example.com.
px02.vc.example.com.
vc.example.com.
vc.example.com.
sips
sips
tcp
tcp
10
10
10
10
5061
5061
px01.vc.example.com.
px02.vc.example.com.
vc.example.com.
vc.example.com.
sip
sip
udp *
udp *
10
10
10
10
5060
5060
px01.vc.example.com.
px02.vc.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.

If you have a mixture of public-facing and privately-addressed Conferencing Nodes, ensure that your public-facing SRV records refer to your public-facing Conferencing Nodes (A-records), and vice versa for your local DNS records and your privately-addressed Conferencing Nodes.

In these examples, the DNS records would be:

_h323cs._tcp.vc.example.com. 86400 IN SRV 10 10 1720 px01.vc.example.com.
_h323cs._tcp.vc.example.com. 86400 IN SRV 10 10 1720 px02.vc.example.com.

_h323ls._udp.vc.example.com. 86400 IN SRV 10 10 1719 px01.vc.example.com.
_h323ls._udp.vc.example.com. 86400 IN SRV 10 10 1719 px02.vc.example.com.

_h323rs._udp.vc.example.com. 86400 IN SRV 10 10 1719 px01.vc.example.com.
_h323rs._udp.vc.example.com. 86400 IN SRV 10 10 1719 px02.vc.example.com.

_sip._tcp.vc.example.com.    86400 IN SRV 10 10 5060 px01.vc.example.com.
_sip._tcp.vc.example.com.    86400 IN SRV 10 10 5060 px02.vc.example.com.

_sips._tcp.vc.example.com.   86400 IN SRV 10 10 5061 px01.vc.example.com.
_sips._tcp.vc.example.com.   86400 IN SRV 10 10 5061 px02.vc.example.com.

_sip._udp.vc.example.com.    86400 IN SRV 10 10 5060 px01.vc.example.com.
_sip._udp.vc.example.com.    86400 IN SRV 10 10 5060 px02.vc.example.com.

px01.vc.example.com.         86400 IN A 198.51.100.40
px02.vc.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 Skype for Business / Lync environments

In public DMZ / hybrid deployments with remote Skype for Business / Lync environments, to ensure that calls from those remote SfB/Lync environments are routed to your Conferencing Nodes, a DNS SRV record in the format _sipfederationtls._tcp.<domain> must be created.

Example

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

_sipfederationtls._tcp.vc.example.com. 86400 IN SRV 1 100 5061 px.vc.example.com.
px.vc.example.com.                     86400 IN A 198.51.100.40
px.vc.example.com.                     86400 IN A 198.51.100.41

The SRV record points to the DNS A‑record px.vc.example.com, port 5061, with a priority of 1 and a weight of 100. In other words, it tells Skype for Business / Lync to send its TLS requests to px.vc.example.com on TCP port 5061.

We then have 2 round-robin DNS A-records for the px.vc.example.com pool hostname that resolves px.vc.example.com to the IP addresses of our 2 Conferencing Nodes (198.51.100.40 and 198.51.100.41).

Even if you only intend initially to use a single Conferencing Node to receive incoming SfB/Lync calls, this pool-based approach allows you to easily add more nodes in the future. (In your actual deployment, the hostnames (including the pool hostname) and host IP addresses should be changed to use the real hostnames and IP addresses of your Conferencing Nodes.)

Note that these A-records specified for the px.vc.example.com pool are required in addition to the "standard" A-records that will exist for each Conferencing Node based on their individual hostnames and resolve to the same IP addresses, as shown in the Host DNS A records section above.

The domain name used in the _sipfederationtls._tcp.<domain> SRV record has to match the domain in the corresponding A-record. This is required due to the trust model for SfB/Lync federation. For example:

  • An SRV record such as _sipfederationtls._tcp.vc.example.com must have a corresponding A-record with the same domain, such as px.vc.example.com.
  • You cannot, for example, configure the _sipfederationtls._tcp.vc.example.com SRV record to point to px.video.example.com or px01.otherdomain.com.

For more information, see Pexip Infinity configuration for public DMZ / hybrid deployments with remote Skype for Business / Lync environments and Certificate and DNS examples for public DMZ / hybrid integrations with Skype for Business / Lync.

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

You must set up DNS records so that the Infinity Connect clients know which host to contact when placing calls or registering to Pexip Infinity.

The host will typically be a public-facing Conferencing Node (for on-premises deployments where your Transcoding Conferencing Nodes are located within a private network we recommend that you deploy public-facing Proxying Edge Nodes).

To enable access from the Infinity Connect desktop clients and Infinity Connect mobile clients, each domain used in aliases in your deployment must either have a DNS SRV record for _pexapp._tcp.<domain>, or resolve directly to the IP address of 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
  • reference port 443 on the host.

Example

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

_pexapp._tcp.vc.example.com. 86400 IN SRV 10 100 443 px01.vc.example.com.
_pexapp._tcp.vc.example.com. 86400 IN SRV 20 100 443 px02.vc.example.com.

These point to the DNS A‑records px01.vc.example.com, port 443 (HTTPS), with a priority of 10 and a weight of 100, and px02.vc.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 px01.vc.example.com (our primary node) on TCP port 443. The desktop client will also try to use host px02.vc.example.com (our fallback node) if it cannot contact px01.
  • The Infinity Connect mobile client will send its HTTP requests either to px01.vc.example.com or to px02.vc.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 client connectivity.