Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS
Extracted elements (21)
A single NAPTR record can be placed at a higher node of the reverse DNS tree (corresponding to /24 or /16 for IPv4; /64, /56, /48, or /32 for IPv6) to avoid proliferating identical records; records at lower points (longer prefix) override those at higher points, allowing exceptions.
Addresses from private address space can be used as input to this method when a DNS server with a view of the same address space is available, potentially yielding a more geographically specific LIS answer. Public DNS servers cannot provide useful records for private addresses.
The reverse DNS approach is designed as a transitional UNSAF mechanism because DHCP-based LIS discovery (RFC 5986) cannot work with legacy residential gateways — replacing or updating millions of deployed gateways solely to support LIS discovery is not economically viable. This method lets Devices discover their LIS without any gateway assistance.
The set of label-shortening steps (1 and 2 labels for IPv4; 16, 18, 20, and 24 labels for IPv6) is chosen to provide network operators flexibility in placing LIS discovery records while limiting DNS queries to at most five U-NAPTR resolutions per IP address. This does not create a classful addressing hierarchy.
In cases where a VPN or tunnel is used, the entity providing a public IP address may not be able to provide the Device with location information and is expected to indicate this via the HELD 'notLocatable' error or similar mechanism.
Use of STUN for reflexive address discovery is inherently brittle in the presence of multiple NATs or overlapping private address realms, because the DNS server used must be able to see the same address realm as the IP address in question. If address realms use overlapping address space, the DNS server may provide information not useful to the Device.
A Device relying on DNS records in the private address space portion of the '.in-addr.arpa.' or '.ip6.arpa.' trees MUST either use an alternative trust anchor for these records or rely on other means of ensuring the veracity of the DNS records, since normal DNSSEC trust anchors are ineffective for private address space.
A Device that discovers a LIS using this method MUST NOT provide that LIS with additional information that might reveal its position (such as location measurements per RFC 7105) unless it has a secondary method for determining the LIS's authenticity, such as a white list.
A network that operates NAT SHOULD provide NAPTR records referencing a LIS endpoint with a public address. Networks can also provide a direct route to the LIS to prevent requests from traversing the NAT.
Alternative methods for determining IP addresses (PCP, UPnP, NAT-PMP, proprietary methods) MAY be used by the Device, but are not mandated because there is no assurance these methods will be supported by any access network.
An access network provider SHOULD provide NAPTR records for each public IP address used for Devices within the access network, to enable successful LIS discovery.
Any DNS server internal to a NAT SHOULD also include NAPTR records for the private address range so that clients within the private address range can discover a LIS based on their IP address prior to any address translation.
For IPv4, the full reverse DNS name SHOULD be successively shortened by one and then two labels (corresponding to /24 and /16 prefixes) and the DDDS query repeated. For IPv6, the name SHOULD be shortened successively by 16, 18, 20, and 24 labels (corresponding to /64, /56, /48, and /32 prefixes).
The DHCP method described in RFC 5986 MUST be attempted on all local network interfaces before attempting the reverse DNS method. The reverse DNS method is employed only after DHCP fails, the DHCP server provides no access network domain name, or the resulting LIS returns a HELD 'notLocatable' error.
The mechanism allows a device to discover its local LIS, which could help an unauthorized third party identify the correct LIS server to attack for a given IP address and subsequently obtain location information. It is therefore important that a LIS meet the security requirements of the Location Configuration Protocol it implements.
A Device identifies a set of potential IP addresses that currently route packets to it, ordered by proximity. Local interface addresses are listed first; STUN 'Binding Request' with 'XOR-MAPPED-ADDRESS' response is used to determine the public reflexive transport address.
LIS discovery using IP addresses and reverse DNS provides alternative domain names as input to the DDDS process when DHCP-based discovery fails. A Device collects its IP addresses, converts them to reverse DNS names in the '.in-addr.arpa.' or '.ip6.arpa.' tree, performs DDDS queries, and shortens names iteratively to find a LIS.
The domain name for each IP address is the name used for a reverse DNS lookup. IPv4 addresses produce names in the '.in-addr.arpa.' tree per RFC 1035 Section 3.5; IPv6 addresses produce names in the '.ip6.arpa.' tree per RFC 3596 Section 2.5.
A falsified IP address could direct a Device to a malicious LIS controlled by the attacker, which could then provide false location information via verifiable DNS records. A valid LIS for the falsified address might also return a HELD 'notLocatable' error, resulting in denial of service.
An on-path attacker can manipulate STUN responses to supply a falsified reflexive transport address, causing the Device to discover a wrong or malicious LIS. Even though STUN uses HMAC MESSAGE-INTEGRITY, an on-path attacker can rewrite source/destination addresses. The recommended remedy is independent verification of the reflexive address.
DNS queries for private addresses that are not blocked as RFC 6303 requires, or directed to external servers, can expose the addresses in use within the network outside of it. Implementing RFC 6303 on resolvers inside the network avoids this; otherwise the problem cannot be prevented without blocking external DNS queries.