Opened 10 years ago

Closed 10 years ago

#237 closed defect (fixed)

Section 1

Reported by: bernard_aboba@… Owned by: jon.peterson@…
Priority: minor Milestone: milestone1
Component: draft-iab-dns-applications Version: 1.0
Severity: In WG Last Call Keywords:
Cc:

Description

  1. Motivation

The Domain Name System (DNS) has long provided a general means of
translating easily-memorized domain names into numeric Internet

s/easily-memorized [Since some domain names may not be memorable]
s/numeric Internet/Internet/? [Are there non-numeric IP addresses?]

Protocol addresses, which makes the Internet easier to use by
providing a valuable layer of indirection between well-known names

s/well-known names/domain names/ [Domain names need not necessarily be well-known]

and lower-layer protocol elements. [RFC0974] documented a further
use of the DNS: to manage application services operating in a domain
with the Mail Exchange (MX) resource record, which helped email
addressed to the domain to find a mail service for the domain
sanctioned by the zone administrator.

The seminal MX record served as a prototype for other DNS resource
records that supported applications associated with a domain name.
The SRV resource record [RFC2052] provided a more general mechanism
for locating services in a domain, complete with a weighting system
and selection among transports. The Naming Authority Pointer (NAPTR,
originally [RFC2168]) resource record, especially as it evolved into
the more general Dynamic Delegation Discovery System (DDDS, [RFC3401]
passim) framework, added a generic mechanism for storing application

[BA] What is "passim"?

data in the DNS - an algorithm for transforming a string into a
domain name, which might then be resolved by the DNS to find NAPTR

[BA] It may be worth clarifying that the string transformation is not
performed by the DNS client.

records. This enabled the resolution of identifiers that do not have
traditional host components through the DNS; the best-known example
of this are telephone numbers, as resolved by the DDDS application
ENUM. Recent work such as Domain Keys Identified Mail (DKIM,
[RFC6376]) has enabled security features of applications to be
advertised through the DNS, via the TXT resource record.

The amount of application intelligence that uses the DNS has thus

s/amount of application intelligence that uses/scope of application usage of/

increased over time. However, some proposed usages of, and
extensions to, the DNS have become misaligned with both the DNS
architecture and the DNS protocol. An example of such misalignment
is illustrated through the expectation of confidentiality: In the

s/illustrated through

global public DNS the resolution of domain names to IP addresses is
public information with no expectation of confidentiality, and thus
the underlying query/response protocol has no encryption mechanism -
typically, any security required by an application or service is
invoked after the DNS query, when the resolved service has been
contacted. Only in private DNS environments (including split horizon
DNS) where the identity of the querier is assured through some

s/assured/authenticated/

external means does the DNS maintain confidential records in this sense by providing answers to the private and public users of the

s/in this sense

DNS.

Another type of differentiation in answers is done for load balancing
reasons, localization or related optimizations, whereby the public DNS returns

s/Another type... the public/In order to support load balancing or other optimization, a
DNS server may return/

different addresses in response to queries from different

Peterson, et al. Expires April 25, 2013 [Page 4]

Internet-Draft Application Features in DNS October 2012

sources, or even no response at all, which is discussed further in
Section 3.1.1.

Applications in many environments require features such as
confidentiality, and as the contexts in which applications rely on
the DNS have increased, some application protocols have looked to
extend the DNS to include these sorts of capabilities.

This document therefore provides guidance to designers of
applications and application protocols on the use or extension of the
DNS to provide features to applications. It offers an overview of
ways that applications have used the DNS in the past, as well as
proposed ways that applications could use the DNS.

[BA] Change to:

This document provides guidance to applications designers looking
to use the DNS to support features in their applications.
It provide an overview of past application usage of the DNS,
as well as reviewing proposed new usages.

It identifies
concerns and trade-offs and gives some reasons to decide the

s/gives some reasons to decide/provides guidance on the/

question, "Should I store this information in the DNS, or use some
other means?" when that question arises during protocol development.
These guidelines remind application protocol designers of the
strengths and weaknesses of the DNS in order to make it easier for
designers to decide what features the DNS should provide for their
application.

The guidance in this document complements the guidance on extending
the DNS given in [RFC5507]. Whereas [RFC5507] considers the
preferred ways to add new information to the underlying syntax of the
DNS (such as defining new resource records or adding prefixes or
suffixes to labels), the current document considers broader
implications of applications that rely on the DNS for the
implementation of certain features, be it through extending the DNS
or simply reusing existing protocol capabilities - implications that
may concern the invocation of the resolver by applications, the
behavior of name servers, resolvers or caches, extensions to the
underlying DNS protocol, the operational responsibilities of zone
administrators, security, or the overall architecture of names. When
existing DNS protocol fields are used in ways that their designers
did not intend to handle new applications, those applications may
require further changes and extensions that are fundamentally at odds
with the strengths of the DNS.

Change History (1)

comment:1 Changed 10 years ago by jon.peterson@…

  • Resolution set to fixed
  • Status changed from new to closed

(mostly) fixed in -07; on the string transformation, the FWKR is actually performed by the client before the name is passed to the resolved, so that is left as-is

Note: See TracTickets for help on using tickets.