Properties of an Ideal Naming Service
ETH Zurich
Universitaetstrasse 6
Zurich
8092
Switzerland
ietf@trammell.ch
Internet-Draft
This document specifies a set of necessary functions and desirable properties
of an ideal system for resolving names to addresses and associated information
for establishing communication associations in the Internet. For each
property, it briefly explains the rationale behind it, and how the property is
or could be met with the present Domain Name System. It is intended to start a
discussion within the IAB’s Names and Identifiers program about gaps between
the present reality of DNS and the naming service the Internet needs by
returning to first principles.
The Internet’s Domain Name System (DNS) is an excellent
illustration of the advantages of the decentralized architecture that have
made the Internet able to scale to its present size. However, the choices made
in the evolution of the DNS since its initial design are only one path through
the design space of Internet-scale naming services. Many other naming services
have been proposed, though none has been remotely as successful for general-
purpose use in the Internet.
This document returns to first principles, to determine the dimensions of the
design space of desirable properties of an Internet-scale naming service. It
is a work in progress, intended to start a discussion within the IAB’s Names
and Identifiers program about gaps between the present reality of DNS and the
naming service the Internet needs.
and define the set of operations
a naming service should provide for queriers and authorities,
defines a set of desirable properties of the provision of this service,
and examines implications of these properties.
The following capitalized terms are defined and used in this document:
Subject: A name, address, or name-address pair about which the naming service can answer queries
Association: A mapping between a Subject and information about that Subject
Authority: An entity that has the right to determine which Associations exist within its namespace
Delegation: An Association that indicates that an Authority has given the right to make assertions about the Associations within the part of a namespace identified by a Subject to a subordinate Authority.
[EDITOR’S NOTE: need to make a terminology unification pass]
At its core, a naming service must provide a few basic functions for queriers,
associating a Subject of a query with information about that subject. The
information available from a naming service is that which is necessary for a
querier to establish a connection with some other entity in the Internet,
given a name identifying it.
Given a Subject name, the naming service returns a set of addresses associated
with that name, if such an association exists, where the association is
determined by the authority for that name. Names may be associated with
addresses in one or more address families (e.g. IP version 4, IP version 6). A
querier may specify which address families it is interested in receiving
addresses for, and the naming system treats all address families equally.
This mapping is implemented in the DNS protocol via the A and AAAA RRTYPES.
Given an Subject address, the naming service returns a set of names associated
with that address, if such an association exists, where the association is
determined by the authority for that address.
This mapping is implemented in the DNS protocol via the PTR RRTYPE. IPv4
mappings exist within the in-addr.arpa. zone, and IPv6 mappings in the
ip6.arpa. zone. This mechanism has the disadvantage that delegations in IPv4
only happen on octet (8-bit) boundaries, and in IPv6 only happen on hex digit
(4-bit) boundaries, which make delegations on other prefixes operationally
difficult.
Given a Subject name, the naming service returns a set of object names
associated with that name, if such an association exists, where the
association is determined by the authority for the subject name.
This mapping is implemented in the DNS protocol via the CNAME RRTYPE. CNAME
does not allow the association of multiple object names with a single subject,
and CNAME may not combine with other RRTYPEs (e.g. NS, MX) arbitrarily.
Given a Subject name, the naming service returns other auxiliary information
associated with that name that is useful for establishing communication over
the Internet with the entities associated with that name.
Most of the other RRTYPES in the DNS protocol implement these sort of mappings.
As a name might be associated with more than one address, auxiliary
information as above may be associated with a name/address pair, as opposed to
just with a name.
This mapping is not presently supported by the DNS protocol.
The query interface is not the only interface to the naming service: the
interface a naming service presents to an Authority allows updates to the set
of Associations and Delegations in that Authority’s namespace. Updates consist
of additions of, changes to, and deletions of Associations and Delegations. In
the present DNS, this interface consists of the publication of a new zone file
with an incremented version number, but other authority interfaces are
possible.
The following properties are desirable in a naming service providing the
functions in and .
Since the point of a naming service is to replace network-layer identifiers
with more useful identifiers for humans (whether end users, software
developers, or network administrators), the Subject names the naming service
can provide must meet two semantic criteria:
A naming service must provide the ability to name objects that its human users
find more meaningful than the objects themselves.
A naming service must make it possible to guarantee that two different names
are easily distinguishable from each other by its human users.
A naming service should impose as little structure on the names it supports as
practical in order to be universally applicable. Naming services that impose a
given organizational structure on the names expressible using the service will
not translate well to societies where that organizational structure is not
prevalent.
Every Association among names, addresses, and auxiliary data is subject to
some Authority: an entity which has the right to determine which Associations
and Subjects exist in its namespace. The following are properties of
Authorities in our ideal naming service:
An Authority can delegate some part of its namespace to some other subordinate
Authority. This property allows the naming service to scale to the size of the
Internet, and leads to a tree-structured namespace, where each Delegation is
itself identified with a Subject at a given level in the namespace.
In the DNS protocol, this federation of authority is implemented through
delegation using the NS RRTYPE, redirecting queries to subordinate authorities
recursively to the final authority. When DNSSEC is used, the DS RRTYPE is used
to verify this delegation.
For a given Subject, there is a single Authority that has the right to
determine the Associations and/or Delegations for that subject. The unitary
authority for the root of the namespace tree may be special, though; see
.
In the DNS protocol as deployed, unitary authority is approximated by the
entity identified by the SOA RRTYPE. The existence of registrars, which use
the Extensible Provisioning Protocol (EPP) to modify entries in
the zones under the authority of a top-level domain registry, complicates this
somewhat.
A querier can determine the identity of the Authority for a given Association.
An Authority cannot delegate its rights or responsibilities with respect to a
subject without that Delegation being exposed to the querier.
In DNS, the authoritative name server(s) to which a query is delegated via the
NS RRTYPE are known. However, we note that in the case of authorities which
delegate the ability to write to the zone to other entities (i.e., the
registry-registrar relationship), the current DNS provides no facility for a
querier to understand on whose behalf an authoritative assertion is being
made; this information is instead available via WHOIS. To our knowledge, no
present DNS name servers use WHOIS information retrieved out of band to make
policy decisions.
An ideal naming service allows the revocation and replacement of an authority
at any level in the namespace, and supports the revocation and replacement of
authorities with minimal operational disruption.
The current DNS allows the replacement of any level of delegation except the
root through changes to the appropriate NS and DS records. Authority
revocation in this case is as consistent as any other change to the DNS.
Authority at the top level of the namespace tree is delegated according to a
process such that there is universal agreement throughout the Internet as to
the subordinates of those Delegations.
A querier must be able to verify that the answers that it gets from the naming
service are authentic.
Given a Delegation from a superordinate to a subordinate Authority, a querier
can verify that the superordinate Authority authorized the
Delegation.
Authenticity of delegation in DNS is provided by DNSSEC .
The authenticity of every answer is verifiable by the querier. The
querier can confirm that the Association returned in the answer is
correct according to the Authority for the Subject of the query.
Authenticity of response in DNS is provided by DNSSEC.
Some queries will yield no answer, because no such Association exists. In
this case, the querier can confirm that the Authority for the
Subject of the query asserts this lack of Association.
Authenticity of negative response in DNS is provided by DNSSEC.
Consistency in a naming service is important. The naming service should
provide the most globally consistent view possible of the set of associations
that exist at a given point in time, within the limits of latency and
bandwidth tradeoffs.
When an Authority makes changes to an Association, every query for a given
Subject returns either the new valid result or a previously valid result,
with known and/or predictable bounds on “how previously”. Given that additions
of, changes to, and deletions of associations may have different operational
causes, different bounds may apply to different operations.
The time-to-live (TTL) on a resource record in DNS provides a mechanism for
expiring old resource records. We note that this mechanism makes additions to
the system propagate faster than changes and deletions, which may not be a
desirable property.
Some techniques require giving different answers to different queries, even in
the absence of changes: the stable state of the namespace is not globally
consistent. This inconsistency should be explicit: a querier can know that an
answer might be dependent on its identity, network location, or other factors.
One example of such desirable inconsistency is the common practice of “split
horizon” DNS, where an organization makes internal names available on its own
network, but only the names of externally-visible subjects available to the
Internet at large.
Another is the common practice of DNS-based content distribution, in which an
authoritative name server gives different answers for the same query depending
on the network location from which the query was received, or depending on the
subnet in which the end client originating a query is located (via the EDNS
Client Subnet extension {RFC7871}}). Such
inconsistency based on client identity or network address may increase query
linkability (see ).
We note that while DNS can be deployed to allow essentially unlimited kinds of
inconsistency in its responses, there is no protocol support for a query to
express the kind of consistency it desires, or for a response to explicitly
note that it is inconsistent. does allow
a querier to note that it would specifically like the view of the state of the
namespace offered to a certain part of the network, and as such can be seen as
inchoate support for this property.
A naming service must provide appropriate performance guarantees to its
clients. As these properties deal with the operational parameters of the
naming service, interesting tradeoffs are available among them, both at design
time as well as at run time (on which see ).
The naming service as a whole is resilient to failures of individual
nodes providing the naming service, as well as to failures of links among
them. Intentional prevention of successful, authenticated query by an
adversary should be as hard as practical.
The DNS protocol was designed to be highly available through the use of
secondary nameservers. Operational practices (e.g. anycast deployment) also
increase the availability of DNS as currently deployed.
The time for the entire process of looking up a name and other necessary
associated data from the point of view of the querier, amortized over all
queries for all connections, should not significantly impact connection setup
or resumption latency.
The bandwidth cost for looking up a name and other associated data necessary
for establishing communication with a given Subject, from the point of view of
the querier, amortized over all queries for all connections, should not
significantly impact total bandwidth demand for an application.
It should be costly for an adversary to monitor the infrastructure in order to
link specific queries to specific queriers.
DNS over TLS and DNS over DTLS provide this property between a querier and a recursive resolver; mixing by the recursive helps with mitigating upstream linkability.
A querier should be able to indicate the desire for a benefit with respect to
one performance property by accepting a tradeoff in another, including:
Reduced latency for reduced dynamic consistency
Increased dynamic consistency for increased latency
Reduced request linkability for increased latency and/or reduced dynamic consistency
Reduced aggregate bandwidth use for increased latency and/or reduced dynamic consistency
There is no support for explicit tradeoffs in performance properties available
to clients in the present DNS.
A querier should not need to trust any entity other than the authority as to the correctness of association information provided by the naming service. Specifically, the querier should not need to trust any intermediary of infrastructure between itself and the authority, other than that under its own control.
DNS does not provide this property without DNSSEC.
On a cursory examination, many of the properties of our ideal name service can
be met, or could be met, by the present DNS protocol or extensions thereto. We
note that there are further possibilities for the future evolution of naming
services meeting these properties. This section contains random observations
that might inform future work.
Any system which can provide the authenticity properties in
is freed from one of the design characteristics of the present domain name
system: the requirement to bind a zone of authority to a specific set of
authoritative servers. Since the authenticity of delegation must be a
protected by a chain of signatures back to the root of authority, the location
within the infrastructure where an authoritative mapping “lives” is no longer
bound to a specific name server. While the present design of DNS does have its
own scalability advantages, this implication allows a much larger design space
to be explored for future name service work, as a Delegation need not always
be implemented via redirection to another name server.
Much of the difficulty with explicit inconsistency ()
derives from the fact that assertions and queries about
subjects exist within a context: .local names on the local network (whether
link or site local), split-DNS names within the context of the “inside” side
of the recursive resolver, DNS geographic load balancing within the geographic
context of the client. Because DNS provides no protocol-level support for
expressing these contexts, they remain implicit.
We note that protocol-level support for this context explicit could point
toward solutions for a variety of problems in currently deployed naming
services, from generalized solutions with privacy/efficiency tradeoffs
({RFC7871}} aside), to explicit redirection to
alternate naming resolution for “special” names .
Allowing names to be encoded in Unicode goes a long way toward meeting the
meaningfulness property (see for the majority of speakers
of human languages. However, as noted by the Internet Architecture Board (see
) and discussed at the Locale-free Unicode Identifiers (LUCID)
BoF at IETF 92 in Dallas in March 2015 (see ), it is not in the
general case sufficient for distinguishability (see ).
An ideal naming service may therefore have to supplement Unicode by providing
runtime support for disambiguation of queries and assertions where the results
may be indistinguishable.
This document has no actions for IANA.
Protocols implementing name resolution systems that meet these ideal
properties will have to consider tradeoffs, especially with respect to privacy
() versus performance, as in . Many
properties are security and privacy relevant. All the properties in
must hold for a client to be able to trust that assertions
about a name are as intended by the authority for that name.
specifies a property which, when it does not hold, may
be exploitable for phishing attacks, and
specifies a property which may ease operational defense against malware abuse
of the naming system.
This document is, in part, an output of design work on naming services at the
Network Security Group at ETH Zurich. Thanks to the group, including Daniele
Asoni, Steve Matsumoto, and Stephen Shirley, for discussions leading to this
document. Thanks as well to Ted Hardie, Wendy Selzter, Andrew Sullivan, and
Suzanne Woolf for input and feedback.
Domain names - implementation and specification
This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.
DNS Security Introduction and Requirements
The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]
Extensible Provisioning Protocol (EPP)
This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK]
Special-Use Domain Names
This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names.
Client Subnet in DNS Queries
This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached. Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement.
Specification for DNS over Transport Layer Security (TLS)
This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.
DNS over Datagram Transport Layer Security (DTLS)
DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information, which is valuable to protect.This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechanism runs over port 853.
Specification for DNS over TLS
This document describes the use of TLS to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS-over-TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE working group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. Note: this document was formerly named draft-ietf-dprive-start-tls- for-dns. Its name has been changed to better describe the mechanism now used. Please refer to working group archives under the former name for history and previous discussion. [RFC Editor: please remove this paragraph prior to publication]
Specification for DNS over Datagram Transport Layer Security (DTLS)
DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information which is valuable to protect. This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce DTLS handshake size. The proposed mechanism runs over port 853.
LUCID problem (slides, IETF 92 LUCID BoF)
IAB Statement on Identifiers and Unicode 7.0.0