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 Connect app 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
  • Poly/Polycom endpoints to register to One-Touch Join
  • Connect desktop apps and Connect mobile apps for Android to register to Pexip Infinity
  • Connect apps 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.

* Only required if you intend to enable SIP over UDP.

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 intelligent DNS (GeoDNS, GSLB, etc.) 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 environments and Certificate and DNS examples for public DMZ / hybrid integrations with Skype for Business.

Enabling Poly/Polycom endpoints to register to One-Touch Join

If you have a One-Touch Join deployment that includes Poly endpoints in a location with more than one Conferencing Node, you should spread the Poly endpoint registrations across all nodes in the location to maximize performance and provide redundancy. To achieve this, we recommend that all Poly endpoints in a location register to a single FQDN which uses round-robin DNS to resolve to each Conferencing Node in turn. This requires you to set up appropriate DNS records for all Conferencing Nodes in the location, and ensure that your DNS server is configured to round-robin between these records.

These records are specific to One-Touch Join, and are required in addition to the "standard" A-records that will exist for each Conferencing Node (which are based on their individual hostnames and resolve to the same IP addresses).

Note that all Conferencing Nodes in the location that is being used for One-Touch Join must be included in the DNS records.

Example

In this example, we have two locations being used for One-Touch Join that contain Poly endpoints. Each location has three Conferencing Nodes. We set up the following DNS A‑records:

otj01.vc.example.com.         86400 IN A 10.44.0.10
otj01.vc.example.com.         86400 IN A 10.44.0.11
otj01.vc.example.com.         86400 IN A 10.44.0.12
otj02.vc.example.com.         86400 IN A 10.44.0.20
otj02.vc.example.com.         86400 IN A 10.44.0.21
otj02.vc.example.com.         86400 IN A 10.44.0.22

All Poly endpoints in the first location are configured with otj01.vc.example.com as their Exchange Server, and those in the second location are configured with otj02.vc.example.com.

Enabling access from the Connect mobile app and the Connect desktop app

You must set up DNS records so that the Connect apps 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 Connect desktop apps and Connect mobile apps, 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
  • point to an A/AAAA record
  • 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 Connect desktop apps and Connect mobile apps to initially send their HTTP requests to host px01.vc.example.com (our primary node) on TCP port 443. The Connect apps will also try to use host px02.vc.example.com (our fallback node) if they cannot contact px01.

For more information, see Setting up DNS records and firewalls for Connect app connectivity.