Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery
Extracted elements (26)
A DNS-based approach was chosen over using the ALTO protocol itself (ALTO4ALTO) for cross-domain server discovery because the latter would require establishing a new registration administration authority.
For Endpoint Cost Service queries with multiple sources or destinations, all queries should be sent to a single ALTO server (discovered via the single source or destination address) to ensure cost values are comparable, since 'routingcost' lacks a well-defined base unit across servers.
The number of candidate domain names (up to 4 for IPv4, up to 6 for IPv6) is a deliberate compromise between deployment flexibility (fine-grained per-IP records) and avoiding excess DNS load. It is not a design goal to expose prefix delegation structure to clients.
The procedure uses DNS reverse trees ('in-addr.arpa.' and 'ip6.arpa.') because those authoritative for a given IP address or prefix are typically controlled by the ISP or organization that operates ALTO servers with accurate routing information for that space.
Resource-consumer-initiated discovery (ALTO requirement AR-32) is a special case of cross-domain discovery, but requires the client to first determine its public IP address using a protocol like STUN due to widespread NAT deployment; DHCP-based discovery is an alternative specified in RFC 7286.
The procedure is compatible with BCP 20 (RFC 2317) classless in-addr.arpa delegation for IPv4 prefixes shorter than /24. ISPs may publish NAPTR records at the /24 level even when BCP 20 delegations or no delegations are in use.
When a resource consumer is behind one or more NATs, the discovery procedure will use the public IP of the outermost NAT as the lookup parameter. Using a private RFC 1918 address as the parameter requires correct DNS split-horizon and DNSSEC trust anchors to yield usable results.
After all domain names have been tried at least once, the procedure MAY retry those domain names that had caused temporary lookup errors.
All implementations of the Cross-Domain ALTO Server Discovery Procedure MUST support DNSSEC or be able to use such functionality provided by the underlying operating system.
For an IPv4 address with prefix length L < 8, the procedure MUST abort and indicate an 'unsupported prefix length' error. For IPv6 with L < 32, it similarly aborts.
If no matching U-NAPTR records are found at the primary lookup domain, the procedure SHOULD try further lookups using the domain names from column 4 of the lookup table in the indicated order.
Mobile resource consumers SHOULD query the resource directory again after a change of IP address, to get an optimized candidate list for the new IP address.
Network operators that publish U-NAPTR resource records for the Cross-Domain ALTO Server Discovery Procedure SHOULD use DNSSEC to protect their subdomains of 'in-addr.arpa.' and/or 'ip6.arpa.'.
The ALTO Cross-Domain Server Discovery Procedure MUST support being called with any valid U-NAPTR Service Parameter, not just 'ALTO:https', to support future extensions.
The ALTO Cross-Domain Server Discovery Procedure SHOULD inform its caller when DNS queries have failed due to temporary errors, noting that retrying later might yield better results.
The domain name from column 3 of the lookup table and the U-NAPTR Service Parameter SP MUST be used for a U-NAPTR lookup to obtain one or more ALTO IRD URIs.
When DNS lookups fail (including temporary errors), and further domain names remain to be tried, the procedure SHOULD immediately try the next domain name without waiting for retries.
DNS queries during cross-domain ALTO server discovery can reveal to eavesdroppers that a client is using ALTO and which IP address it is optimizing traffic for. DNS over TLS (RFC 7858) and DNS over HTTPS (RFC 8484) can protect confidentiality of these queries.
Step 1 constructs a reverse DNS domain name from the input IP address: IPv4 addresses use the 'IN-ADDR.ARPA.' tree per RFC 1035 Section 3.5, IPv6 addresses use the 'IP6.ARPA.' tree per RFC 3596 Section 2.5.
Step 2 generates shortened domain names by progressively removing leading labels (octets for IPv4, nibbles for IPv6), producing up to four names (R32/R24/R16/R8) for IPv4 and up to six names (R128/R64/R56/R48/R40/R32) for IPv6.
The ALTO Cross-Domain Server Discovery Procedure takes two parameters: X (an IPv4 or IPv6 address or prefix in CIDR notation) and SP (a U-NAPTR Service Parameter, typically 'ALTO:https'). It returns one or more ALTO IRD URIs with order and preference values.
An attacker could cause a denial-of-service against the ALTO discovery procedure or underlying DNS, preventing clients from discovering any ALTO server. Applications must be prepared to operate without ALTO guidance; operators should follow best practices to secure DNS and ALTO infrastructure.
DNS record modification or spoofing could redirect ALTO clients to a wrong ALTO server, which may provide suboptimal or forged guidance, affect traffic distribution, or threaten user privacy. DNSSEC must be supported by all implementations and should be deployed by network operators to mitigate this threat.
HTTPS-based transport (TLS) protects ALTO client-server communication after discovery, but TLS certificate validation cannot detect attacks against the U-NAPTR DNS lookups used during the discovery procedure itself; those records must be secured via DNSSEC.
The discovery procedure sequentially performs DNS U-NAPTR lookups starting from the most-specific domain name (longest prefix) and falling back to shorter prefixes. It terminates successfully on first match, or unsuccessfully after exhausting all candidates from columns 3 and 4 of the lookup table.
U-NAPTR resource records in the 'in-addr.arpa.' or 'ip6.arpa.' trees carry the service parameter 'ALTO:https' and a regexp field mapping the domain name to an ALTO IRD URI, e.g., '!.*!https://alto1.example.net/ird!'. Order and preference fields indicate relative priority.