Why DNS names make lousy endpoint identifiers

The problem

In IPv6 more often than in IPv4, attachment points (i.e. IP addresses) change for various reasons:

• A host moves relative to the network (either a mobile host, one which moves while attempting to stay connected, or a peripatetic host, one which moves from place to place and is intermittently connected.)
• A host with multiple network interfaces switches from one interface to another, as when a host with both 802.11 and 100Mb Ethernet interfaces connects to the Ethernet interface in order to get better bandwidth.
• A network to which a host is a attached moves in physical space and thus is forced to move its point(s) of attachment to the rest of the network, and this in turn forces prefix changes.
• A network switches ISPs and therefore receives a different PA prefix.
• A network changes its connectivity in such a way that it is desirable for it to change the prefixes it uses (e.g. from PI to PA or vice versa).
• An upstream network provider renumbers its subscribers in order to improve aggregatability.
• A conflict is detected between randomly-chosen addresses (e.g. v4 link-local) or address prefixes (e.g. v6 PUPIs).

• IPv6 address assignment attempts to avoid routing table explosion and expects leaf networks to obtain PA addresses
• More hosts have multiple network interfaces
• More hosts have wireless network interfaces
• There is a greater demand for mobile access
• A greater variety of network connection facilities, with varying costs and capabilities, is in use
• Whereas NATs have previously been used to address some of these problems, this has been found to cause other problems
• There is an increased demand to be able to use IP with ad hoc and private networks which do not benefit from centralized address assignment

• used by TCP and other transport protocols (so that TCP connections can stay up across renumbering)
• can be used for rendezvous (e.g. "call me back at XXX when you're done") so that long-running tasks (e.g. compute jobs, print jobs, data aquisition) can be accomplished without keeping connections open between the tasks that are performing the operations and the tasks that are monitoring them.
• can be used for referrals between hosts

Requirements for connection endpoint identifiers

• They must be unambiguous within the set of all processes that are participating in an application
• They must be usable with TCP, SCTP, etc. without major changes

Requirements for mapping connection endpoint identifiers to addresses

• The function that maps identifiers to addresses needs to be fast
• The function that maps identifiers to addresses needs to be reliable
• The function that maps identifiers to addresses needs to be appropriately secure, so that (e.g.) it is not easily attacked for the purpose of redirecting traffic to other locations or to deny service to the hosts using those identifiers
• The mapping must be effective within the set of all processes that are participating in an application
• The function must be able to quickly reflect address or prefix changes

Problems with using DNS names

• Incompatible with existing transport protocols.
• Ambiguous and overloaded. Quite often, a DNS name doesn't refer to a host. Instead it refers to a service (as in imap.example.com or www.example.com) which might map to numerous hosts. There can also be many domains associated with a single host and yet be semantically different; http://a.example.com and http://b.example.com are different resources even if they are both served by the same hosts. The mapping from domains to hosts is essentially arbitrary. In email, a domain is a name for a set of mailboxes; it doesn't have to correspond to an actual host at all. MX records made this true for email; SRV records extend this concept to other protocols.
  What this means among other things is that existing domain names that we use cannot be expected to be host identifiers. Even when they are sufficient to identify a host for initial connection purposes, resolving the same DNS name again may not produce a locator for the same host as before. Therefore the existing DNS names that we currently use to name services cannot be assumed to be suitable as endpoint identifiers for rendezvous or referral.
• Not organized favorably. Existing DNS names are organized according to a hierarchy of administrative entities, and write access to DNS RRs is also organized in this fashion. The components of domain names are usually intended to be recognizable by humans, and humans therefore attach meaning to those names. This further implies that those administrative entities often want to restrict use of their domains, so that their names aren't associated with behavior that they cannot control. By contrast, users (and their hosts) are often actors in multiple domains, sometimes concurrently. Insisting that an existing domain name be tightly bound to such a host is unrealistic.
  Of course, it would still be possible to create a new tree of domain names that did not have these characteristics, but this would remove what many see as the primary advantage of using DNS names - the ability to avoid creating new infrastructure.

Problems with using DNS lookup facilities

• Slow. A substantial percentage of lookups take several seconds, and many lookups time out.
• Slow to propagate changes. (because DNS makes heavy use of caching)
• Unreliable. DNS lookup failures are common, even when the domains are valid.
• Not secure in practice. DNSSEC exists but is still in flux, and is not widely used.
• Sometimes disconnected from reality. For a variety of reasons, hosts often move and/or change addresses without DNS being updated.

Conclusion

Existing DNS names are not suitable as general-purpose endpoint identifiers for the purpose of rendezvous and referral. They may be suitable as general-purpose identifiers for initial connections, if the concerns about association with administrative entities can be remedied. For rendezvous and referral purposes it is highly desirable to produce a set of stable identifiers that are compatible with existing transport protocols, for which changes in the identifier-to-locator bindings can be propagaged quickly and be effective for existing connections without advance notice.