Traversal Using Relays around NAT (TURN) Resolution Mechanism
updated by
Extracted elements (18)
S-NAPTR (RFC 3958) was chosen over the existing RFC 5766 DNS SRV mechanism because SRV alone does not let TURN server administrators provision a preferred client-to-server transport protocol, nor allow clients to discover that preference. S-NAPTR with the 'RELAY' service tag and 'turn.udp'/'turn.tcp'/'turn.tls' protocol tags fills this gap.
The resolution mechanism supports a Remote Hosting scenario where a VoIP provider can delegate TURN service to a third-party operator by publishing a single NAPTR record pointing to the operator's domain, allowing the operator to manage servers independently while keeping the indirection opaque to end users.
In mixed deployments where not all TURN clients support RFC 5928 resolution, administrators should publish both NAPTR records (for RFC 5928 clients) and standard SRV records _turn._udp, _turn._tcp, and _turns._tcp (for RFC 5766 clients) to ensure both resolution paths work correctly from the same DNS configuration.
After an allocation succeeds or all allocations fail, the resolution context MUST be discarded and the resolution algorithm MUST be restarted from the beginning for any subsequent allocation attempt.
Servers temporarily blacklisted per RFC 5766 Section 6.4 (due to 437, 486, or 508 error codes) MUST NOT be used for the specified blacklist duration, even if returned by a subsequent resolution run.
Step 1: If <host> is an IP address and <port> is undefined, the default port for the 'turn' (if <secure>=false) or 'turns' (if <secure>=true) SRV service declared in RFC 5766 MUST be used. If the client cannot reach the server on any supported transport, the resolution MUST stop with an error.
Step 2: If <host> is a domain name and <port> is defined, <host> is resolved via DNS A and AAAA queries; if no server can be contacted on the specified port with any supported transport, the resolution MUST stop with an error.
Step 3: If <host> is a domain name and <port> is undefined but <transport> is defined, the RFC 2782 SRV algorithm is applied using <host> as Name, 'turn'/'turns' as Service based on <secure>, and <transport> as Protocol. If the SRV query returns no RR, the default RFC 5766 port MUST be used and A and AAAA queries MUST be performed.
Step 4: If <host> is a domain name and both <port> and <transport> are undefined, the S-NAPTR algorithm (RFC 3958) is applied using <host> as the initial target and 'RELAY' as the application service tag. Protocol tags 'turn.udp', 'turn.tcp', and 'turn.tls' map to UDP, TCP, and TLS respectively; if no NAPTR results are found, processing continues to Step 5.
Step 5 (fallback): If the NAPTR query in Step 4 returns no result, the RFC 2782 SRV algorithm is applied for each transport in the filtered supported-transport list using 'turn'/'turns' as Service. If no tuples are reachable, the resolution MUST stop with an error.
The resolution MUST stop with an error if: <secure>=false and <transport>='udp' but the application does not support UDP; <secure>=false and <transport>='tcp' but TCP is unsupported; <secure>=true and <transport>='udp'; <secure>=true and <transport>='tcp' but TLS is unsupported; <secure>=true and <transport> is empty but TLS is unsupported; or <transport> is defined but unknown.
When TLS is used, the client MUST verify the server's identity by following the identification procedure in RFC 5389 Section 7.2.2, using the value of the <host> parameter as the expected server identity.
The mapping from (<secure>, <transport>) to TURN transport is: false+'udp'→UDP, false+'tcp'→TCP, true+'tcp'→TLS. Combining <secure>=true with <transport>='udp' is explicitly invalid. This table governs transport selection throughout the five-step resolution algorithm.
The TURN resolution mechanism takes four inputs — a boolean <secure>, an IP address or domain name <host>, an optional port <port>, and an optional transport name <transport> ('udp', 'tcp', or empty) — plus an application-provided ordered list of supported TURN transports (UDP, TCP, TLS). It outputs an ordered list of {IP address, transport, port} tuples for the client to try when creating a TURN allocation.
This document registers the 'RELAY' S-NAPTR application service tag for use with the TURN resolution mechanism defined in Section 3. Registered per RFC 3958 with the IESG as change controller.
This document registers three S-NAPTR application protocol tags: 'turn.udp' (TURN over UDP), 'turn.tcp' (TURN over TCP), and 'turn.tls' (TURN over TLS). All three are used with the 'RELAY' application service tag in NAPTR records to express TURN transport preferences.
S-NAPTR-based resolution requires end-to-end authentication to ensure the correct TURN server is reached. RFC 5928 satisfies this requirement via the Long-Term Credential Mechanism defined in RFC 5389, which is mandatory for RFC 5766 deployments.
When SRV or NAPTR indirection is used, the TLS certificate must match the <host> configuration parameter (not the resolved server name). For example, a client configured with <host>='example.com' that resolves via SRV to 'turnserver.example.net' must find 'example.com' in the certificate, not 'turnserver.example.net'. This may require certificate changes when DNS records are added.