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, Connect app clients and federated SfB environments 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. |
|
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.
DNS pool names
In some scenarios, including Teams Connector integrations, SIP proxies from third-party infrastructure / SBCs, or in SfB integrations, you may need to use a generic DNS "pool name" for handling a pool of Conferencing Nodes.
This is typically a set of round-robin DNS A records, with a common name such as px.vc.example.com, that refer to a pool of Conferencing Node resources, for example:
px.vc.example.com. 86400 IN A 198.51.100.40
px.vc.example.com. 86400 IN A 198.51.100.41
px.vc.example.com. 86400 IN A 198.51.100.42
Note that these A records defined for the px.vc.example.com pool are specified 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.
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
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.
Enabling access from the Poly Meeting Control App
You must set up DNS records so that the Poly Meeting Control App knows 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 Poly Meeting Control App, 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 Poly Meeting Control App to initially send its HTTP requests to host px01.vc.example.com (our primary node) on TCP port 443. The Poly Meeting Control App will also try to use host px02.vc.example.com (our fallback node) if it cannot contact px01.
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,
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.