Ticket #165: draft-iab-dns-applications-04.txt

File draft-iab-dns-applications-04.txt, 82.0 KB (added by bernard_aboba@…, 11 years ago)

Bernard's review comments

Line 
1
2
3
4Network Working Group                                        J. Peterson
5Internet-Draft                                             NeuStar, Inc.
6Intended status: Informational                                O. Kolkman
7Expires: September 13, 2012                                   NLnet Labs
8                                                           H. Tschofenig
9                                                  Nokia Siemens Networks
10                                                                B. Aboba
11                                                   Microsoft Corporation
12                                                          March 12, 2012
13
14
15    Architectural Considerations on Application Features in the DNS
16                     draft-iab-dns-applications-04
17
18Abstract
19
20   A number of Internet applications rely on the Domain Name System
21   (DNS) to support their operations.  Many applications use the DNS to
22   locate services for a domain.  For example, some applications
23   transform identifiers other than domain names into formats that the
24   DNS can process and then fetch application data or service location
25
26[BA] "into formats that the DNS can process": does this mean domain names?
27
28   from the DNS.  Proposals to incorporate more sophisticated
29   application behavior into the DNS, however, have raised questions
30   about the applicability and extensibility of the DNS. 
31
32[BA] I would rephrase this "Proposals incorporating sophisticated application
33behavior using DNS as a substrate have raised questions about the
34role of the DNS as an application platform."
35
36   This document
37   explores the architectural consequences of using the DNS for storing
38   and retrieving certain application features, and provides guidance to
39
40[BA] I might say "using the DNS to implement certain application features"
41
42   future application designers as to the sorts of ways that application
43   can make use of the DNS.
44
45[BA] Might say "as to the limitations of the DNS as a substrate and the
46situations in which alternative designs should be considered."
47
48
49Status of this Memo
50
51   This Internet-Draft is submitted in full conformance with the
52   provisions of BCP 78 and BCP 79.
53
54   Internet-Drafts are working documents of the Internet Engineering
55   Task Force (IETF).  Note that other groups may also distribute
56   working documents as Internet-Drafts.  The list of current Internet-
57   Drafts is at http://datatracker.ietf.org/drafts/current/.
58
59   Internet-Drafts are draft documents valid for a maximum of six months
60   and may be updated, replaced, or obsoleted by other documents at any
61   time.  It is inappropriate to use Internet-Drafts as reference
62   material or to cite them other than as "work in progress."
63
64   This Internet-Draft will expire on September 13, 2012.
65
66Copyright Notice
67
68
69
70
71Peterson, et al.       Expires September 13, 2012               [Page 1]
72
73Internet-Draft             Applications in DNS                March 2012
74
75
76   Copyright (c) 2012 IETF Trust and the persons identified as the
77   document authors.  All rights reserved.
78
79   This document is subject to BCP 78 and the IETF Trust's Legal
80   Provisions Relating to IETF Documents
81   (http://trustee.ietf.org/license-info) in effect on the date of
82   publication of this document.  Please review these documents
83   carefully, as they describe your rights and restrictions with respect
84   to this document.  Code Components extracted from this document must
85   include Simplified BSD License text as described in Section 4.e of
86   the Trust Legal Provisions and are provided without warranty as
87   described in the Simplified BSD License.
88
89   This document may contain material from IETF Documents or IETF
90   Contributions published or made publicly available before November
91   10, 2008.  The person(s) controlling the copyright in some of this
92   material may not have granted the IETF Trust the right to allow
93   modifications of such material outside the IETF Standards Process.
94   Without obtaining an adequate license from the person(s) controlling
95   the copyright in such materials, this document may not be modified
96   outside the IETF Standards Process, and derivative works of it may
97   not be created outside the IETF Standards Process, except to format
98   it for publication as an RFC or to translate it into languages other
99   than English.
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127Peterson, et al.       Expires September 13, 2012               [Page 2]
128
129Internet-Draft             Applications in DNS                March 2012
130
131
132Table of Contents
133
134   1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  4
135   2.  Overview of DNS Application Usages . . . . . . . . . . . . . .  6
136     2.1.  Locating Services in a Domain  . . . . . . . . . . . . . .  6
137     2.2.  NAPTR and DDDS . . . . . . . . . . . . . . . . . . . . . .  7
138     2.3.  Arbitrary Data in the DNS  . . . . . . . . . . . . . . . .  9
139   3.  Challenges for the DNS . . . . . . . . . . . . . . . . . . . . 11
140     3.1.  Compound Queries . . . . . . . . . . . . . . . . . . . . . 11
141       3.1.1.  Responses Tailored to the Originator . . . . . . . . . 13
142     3.2.  Using DNS as a Generic Database  . . . . . . . . . . . . . 14
143       3.2.1.  Large Data in the DNS  . . . . . . . . . . . . . . . . 15
144     3.3.  Administrative Structures Misaligned with the DNS  . . . . 16
145       3.3.1.  Metadata about Tree Structure  . . . . . . . . . . . . 18
146     3.4.  Domain Redirection . . . . . . . . . . . . . . . . . . . . 20
147   4.  Private DNS and Split Horizon  . . . . . . . . . . . . . . . . 22
148   5.  Principles and Guidance  . . . . . . . . . . . . . . . . . . . 25
149   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
150   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
151   8.  IAB Members  . . . . . . . . . . . . . . . . . . . . . . . . . 29
152   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
153   10. Informative References . . . . . . . . . . . . . . . . . . . . 31
154   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183Peterson, et al.       Expires September 13, 2012               [Page 3]
184
185Internet-Draft             Applications in DNS                March 2012
186
187
1881.  Motivation
189
190   The Domain Name System (DNS) has long provided a general means of
191   translating easily-memorized domain names into numeric Internet
192   Protocol addresses, which makes the Internet easier to use by
193   providing a valuable layer of indirection between well-known names
194   and lower-layer protocol elements.  [RFC0974] documented a further
195   use of the DNS: to manage application services operating in a domain
196   with the Mail Exchange (MX) resource record, which helped email
197   addressed to the domain to find a mail service for the domain
198   sanctioned by the zone administrator.
199
200   The seminal MX record served as a prototype for other DNS resource
201   records that supported applications associated with a domain name.
202   The SRV resource record [RFC2052] provided a more general mechanism
203   for locating services in a domain, complete with a weighting system
204   and selection among transports.  The Naming Authority Pointer (NAPTR,
205   originally [RFC2168]) resource record, especially as it evolved into
206   the more general Dynamic Delegation Discovery System (DDDS, [RFC3401]
207   passim) framework, added a generic mechanism for storing application
208   data in the DNS - an algorithm for transforming a string into a
209   domain name, which might then be resolved by the DNS to find NAPTR
210   records.  This enabled the resolution of identifiers that do not have
211   traditional host components through the DNS; the best-known example
212   of this are telephone numbers, as resolved by the DDDS application
213   ENUM.  Recent work such as Domain Keys Identified Mail (DKIM,
214   [RFC4871]) has enabled security features of applications to be
215   advertised through the DNS, via the TXT resource record.
216
217   The amount of application intelligence that uses the DNS has thus
218   increased over time.  However, some proposed usages of, and
219
220[BA] I would say "The development of DNS features to support
221application usage has thus increased over time."
222
223
224   extensions to the DNS have become misaligned with both the DNS
225   architecture and the DNS protocols.  An example of such misalignment
226   is illustrated through the expectation of confidentiality: In the
227   global public DNS the resolution of domain names to IP addresses is
228   public information with no expectation of confidentiality, and thus
229   the underlying query/response protocol has no authentication or
230   encryption mechanism - typically, any security required by an
231   application or service is invoked after the DNS query, when the
232   resolved service has been contacted. 
233
234[BA] The example of misalignment is given without referring to an
235application that requires confidentiality and therefore can be
236said to be "misaligned". 
237
238I might introduce these considerations by stating:
239
240   "Applications in many environments require features such as confidentiality,
241   source-specific responses and database capabilities that are not easily
242   provided by the DNS.  As applications have increasingly relied upon the
243   DNS, proposals have emerged for incorporating these capabilities into the
244   DNS."
245
246   Only in private DNS
247   environments (including split horizon DNS) where the identity of the
248   querier is assured through some external means does the DNS maintain
249   confidential records in this sense by providing answers to the
250   private and public users of the DNS.
251
252   Another type of differentiation in answers is done for load balancing
253   reasons, localization or related optimizations, whereby the public
254   DNS returns different addresses in response to queries from different
255
256
257
258Peterson, et al.       Expires September 13, 2012               [Page 4]
259
260Internet-Draft             Applications in DNS                March 2012
261
262
263   sources, or even no response at all, which is discussed further in
264   Section 3.1.1.
265
266   Applications in many environments require these sorts of features
267   like confidentiality, differentiation from databases, and as the
268   contexts in which applications rely on the DNS have increased, some
269   application protocols have looked to extend the DNS to include these
270   sorts of capabilities.
271
272[BA] It is probably best for the arguments in this paragraph to be moved upfront.
273
274   This document therefore provides guidance to designers of
275   applications and application protocols on the use or extension of the
276   DNS to provide features to applications.  It offers an overview of
277   ways that applications have used the DNS in the past, as well as
278   proposed ways that applications could use the DNS.  It identifies
279   concerns and trade-offs and gives some reasons to decide the
280   question, "Should I store this information in the DNS, or use some
281   other means?" when that question arises during protocol development.
282   These guidelines remind application protocol designers of the
283   strengths and weaknesses of the DNS in order to make it easier for
284   designers to decide what features the DNS should provide for their
285   application.
286
287   The guidance in this document complements the guidance on extending
288   the DNS given in [RFC5507].  Whereas [RFC5507] considers the
289   preferred ways to add new information to the underlying syntax of the
290   DNS (such as defining new resource records or adding prefixes or
291   suffixes to labels), the current document considers broader
292   implications of application that rely on the DNS for the
293   implementations of certain features, be it through extending the DNS
294   or simply reusing existing protocol capabilities - implications that
295   may concern the invocation of the resolver by applications, the
296   behavior of name servers, resolvers or caches, extensions to the
297   underlying DNS protocol, the operational responsibilities of zone
298   administrators, security, or the overall architecture of names.  When
299   existing DNS protocol fields are used in ways that their designers
300   did not intend to handle new applications, those applications may
301   require further changes and extensions that are fundamentally at odds
302   with the strengths of the DNS.
303
304
305
306
307
308
309
310
311
312
313
314
315
316Peterson, et al.       Expires September 13, 2012               [Page 5]
317
318Internet-Draft             Applications in DNS                March 2012
319
320
3212.  Overview of DNS Application Usages
322
323   [RFC0882] identifies the original and fundamental connection between
324   the DNS and applications.  It begins by describing how the
325   interdomain scope of applications creates "formidable problems when
326   we wish to create consistent methods for referencing particular
327   resources that are similar but scattered throughout the environment."
328   This motivated "the need to have a mapping between host names... and
329   ARPA Internet addresses" transition from a global table (the original
330   "hosts.txt" file) to a "distributed database that performs the same
331   function."  [RFC0882] also envisioned some ways to find the resources
332   associated with mailboxes in a domain: without these extensions, a
333   user trying to send mail to a foreign domain lacked a discovery
334   mechanism to locate the right host in the remote domain to which to
335   connect.
336
337   While a special-purpose discovery mechanism could be built by each
338   such application protocol that needed this functionality, the
339   universality of the DNS invites installing these features into its
340   public tree.  Over time, several other applications leveraged
341   resource records for locating services in a domain or for storing
342   application data associated with a domain in the DNS.  This section
343   gives examples of various types of DNS usage by applications to date.
344
3452.1.  Locating Services in a Domain
346
347   The MX resource record provides the simplest motivating example for
348   an application advertising its resources in the Domain Name System.
349   The MX resource record contains the domain name of a server that
350   receives mail on behalf of the administrative domain in question;
351   that domain name must itself be resolved to one or more IP addresses
352   through the DNS in order to reach the mail server.  While naming
353   conventions for applications might serve a similar purpose (a host
354   might be named "mail.example.com" for example), approaching service
355   location through the creation of a new resource record yields
356   important benefits.  For example, one can put multiple MX records
357   under the same name, in order to designate backup resources or to
358   load balance across several such servers (see [RFC1794]); these
359   properties could not easily be captured by naming conventions (see
360   [RFC4367]).
361
362   While the MX record represents a substantial improvement over naming
363   conventions as a means of service location, it remains specific to a
364   single application.  Thus, the general approach of the MX record was
365   adapted to fit a broader class of application through the Service
366   (SRV) resource record (originally [RFC2052]).  The SRV record allows
367   DNS resolvers to query for particular services and underlying
368   transports (for example, HTTP running over TLS, see [RFC2818]) and to
369
370
371
372Peterson, et al.       Expires September 13, 2012               [Page 6]
373
374Internet-Draft             Applications in DNS                March 2012
375
376
377   learn a host name and port where that service resides in a given
378   domain.  It also provides a weighting mechanism to allow load
379   balancing across several instances of a service.
380
381   The reliance of applications on the existence of MX and SRV records
382   has important implications for the way that applications manage
383   identifiers, and that way that applications pass DNS names to
384
385[BA] "and that way" -> "and the way"
386
387   resolvers.  Email identifiers of the form "user@domain" rely on MX
388   records to provide the convenience of simply specifying a "domain"
389   component rather requiring to guess which particular host handles
390   mail on behalf of the domain.  While for applications like web
391   browsing, naming conventions continue to abound ("www.example.com"),
392   SRV records allow applications to query for an application-specific
393   protocol and transport.  For HTTP, the SRV service name corresponds
394   to the URL scheme of the identifier invoked by the application (e.g.,
395   when "http://example.com" is the identifier, the SRV query is for
396   "_http._tcp.example.com"); for other applications, the SRV service
397   that the application passes to the resolver may be implicit in the
398   identifier.  The identifier used at the application layer thus
399   designates the desired protocol and domain, but the application uses
400   the DNS to find the location of the host of that service for the
401   domain, the port where the service resided on that host, load
402   balancing and fault tolerance, and related application features.
403   Ultimately, applications that acquire MX or SRV records may use them
404   as intermediate transformations in order to arrive at an eventual
405   domain name that will resolve to the IP addresses to contact for the
406   service.
407
408   Locating specific services for a domain is thus the first major
409   function for which applications started using the DNS in addition to
410   simple name resolution.  SRV broadened and generalized the precedent
411   of MX to make service location available to any application, rather
412   than just to mail.  As the domain name of the located service might
413   require a second DNS query to resolve, [RFC1034] shows that the
414   Additional Data section of DNS responses may contain the
415   corresponding address records for the names of services designated by
416   the MX record; this optimization, which requires support in the
417   authoritative server and the resolver, is an initial example of how
418   support for application features requires changes to DNS operation.
419   At the same time this is an example of an extension of the DNS that
420   cannot be relied on: Many DNS resolver implementations will remove
421   the addresses in the additional section of the DNS answers because of
422   the trustworthiness issues described in [RFC2181].
423
424[BA] Does it make sense to include a discussion of DNS-SD and its additional
425level of indirection?
426
4272.2.  NAPTR and DDDS
428
429   The NAPTR resource record evolved to fulfill a need in the transition
430   from Uniform Resource Locators (URLs) to the more mature URI
431
432
433
434Peterson, et al.       Expires September 13, 2012               [Page 7]
435
436Internet-Draft             Applications in DNS                March 2012
437
438
439   [RFC3986] framework, which incorporated Uniform Resources Names
440   (URNs).  Unlike URLs, URNs typically do not convey enough semantics
441   internally to resolve them through the DNS, and consequently a
442   separate URI-transformation mechanism is required to convert these
443   types of URIs into domain names.  This allows identifiers with no
444   recognizable domain component to be treated as DNS names for the
445   purpose of name resolution.  Once these transformations result in a
446   domain name, applications can retrieve NAPTR records under that name
447   in the DNS.  NAPTR records contain a far more rich and complex
448   structure than MX or SRV resource records.  A NAPTR record contains
449   two different weighting mechanisms ("order" and "preference"), a
450   "service" field to designate the application that the NAPTR record
451   described, and then two fields that can contain translations: a
452   "replacement" or "regular expression" field, only one of which
453   appears in given NAPTR record.  A "replacement," like NAPTR's
454   ancestor the PTR record, simply designates another domain name where
455   one would look for records associated with this service in the
456   domain.  The "regexp," on the other hand, allows regular expression
457   transformations on the original URI intended to transform it into an
458   identifier that the DNS can resolve.
459
460   As the Abstract of [RFC2915] says, "This allows the DNS to be used to
461   lookup services for a wide variety of resource names (including URIs)
462   which are not in domain name syntax."  Any sort of hierarchical
463   identifier can potentially be encoded as a DNS name, and thus
464   historically the DNS has often been used to resolve identifiers that
465   were never devised as a name for an Internet host.  A prominent early
466   example is found in the in-addr domain [RFC0882], in which IPv4
467   address are transposed into a domain name in order to query the DNS
468   for name(s) associated with the address.  Similar mechanisms could
469   obviously be applied to other sorts of identifiers that lacked a
470   domain component.  Eventually, this idea connected with activities to
471   create a system for resolving telephone numbers on the Internet,
472   which became known as ENUM (originally [RFC2916]).  ENUM borrowed
473   from an earlier proposal, the "tpc.int" domain [RFC1530], which
474   provided a means for encoding telephone numbers as domain names by
475   applying a string preparation algorithm that required reversing the
476   digits and treating each individual digit as a label in a DNS name -
477   thus, for example, the number +15714345400 became
478   0.0.4.5.4.3.4.1.7.5.1.tpc.int.
479
480   In the ENUM system, in place of "tpc.int" the special domain
481   "e164.arpa" was reserved for use.  In its more mature form in the
482   Dynamic Delegation and Discovery Service (DDDS) ([RFC3401] passim)
483   framework, this initial transformation of the telephone number to a
484   domain name was called the "First Well Known Rule."  Its flexibility
485   has inspired a number of proposals beyond ENUM to encode and resolve
486   unorthodox identifiers in the DNS.  Provided that the identifiers
487
488
489
490Peterson, et al.       Expires September 13, 2012               [Page 8]
491
492Internet-Draft             Applications in DNS                March 2012
493
494
495   transformed by the First Well Known Rule have some meaningful
496   structure and are not overly lengthy, virtually anything can serve as
497   an input for the DDDS structure: for example, civic addresses.
498   Though [RFC3402] stipulates of the identifier that "the lexical
499   structure of this string must imply a unique delegation path," there
500   is no requirement that the identifier be hierarchical, nor that the
501   points of delegation in the domain name created by the First Well
502   Known Rule correspond to any points of administrative delegation
503   implied by the structure of the identifier.
504
505   While this ability to look up names "which are not in the domain name
506   syntax" does not change the underlying DNS protocols - the names
507   generated by the DDDS algorithm are still just domain names - it does
508   change the context in which applications pass name to resolvers, and
509   can potentially require very different operational practices of zone
510   administrators(see Section 3.3).  In terms of the results of a DNS
511   query, the presence of the "regexp" field of NAPTR records enabled
512   unprecedented flexibility in the types of identifiers that
513   applications could resolve with the DNS.  Since the output of the
514   regular expression frequently took the form of a URI (in ENUM
515   resolution, for example, a telephone number might be converted into a
516   SIP URI [RFC3261]), anything that could be encoded as a URI might be
517   the result of resolving a NAPTR record - which, as the next section
518   explores, essentially means arbitrary data.
519
5202.3.  Arbitrary Data in the DNS
521
522   Since URI encoding has ways of carrying basically arbitrary data,
523   resolving a NAPTR record might result in an output other than an
524   identifier which would subsequently be resolved to IP addresses and
525   contacted for a particular application - it could give a literal
526   result consumed by the application.  Originally, in [RFC2168], the
527   intended applicability of the regular expression field in NAPTR was
528   much more narrow: the regexp field contained a "substitution
529   expression that is applied to the original URI in order to construct
530   the next domain name to lookup," in order "change the host that is
531   contacted to resolve a URI" or as a way of "changing the path or host
532   once the URL has been assigned."  The regular express tools available
533   to NAPTR record authors, however, grant much broader powers to alter
534   the input string, and thus applications began to rely on NAPTR to
535   perform more radical transformations.  By [RFC3402], the output of
536   DDDS is wholly application-specific: "the Application must determine
537   what the expected output of the Terminal Rule should be," and the
538   example given in the document is one of identifying automobile parts
539   by inputting a part number is receiving at the end of the process
540   receiving information about the manufacturer (though this example
541   reflects that the DNS is only one database to which the DDDS
542   framework might apply).
543
544
545
546Peterson, et al.       Expires September 13, 2012               [Page 9]
547
548Internet-Draft             Applications in DNS                March 2012
549
550
551   NAPTR did not however pioneer the storage of arbitrary data in the
552   DNS.  At the start, [RFC0882] observed that "it is unlikely that all
553   users of domain names will be able to agree on the set of resources
554   or resource information that names will be used to retrieve," and
555   consequently places little restriction on the information that DNS
556   records might carry: it might be "host addresses, mailbox data, and
557   other as yet undetermined information."  [RFC1035] defined the TXT
558   record, a means to store arbitrary strings in the DNS; [RFC1034]
559   specifically stipulates that a TXT contains "descriptive text" and
560   that "the semantics of the text depends on the domain where it is
561   found."  The existence of TXT records has long provided new
562   applications with a rapid way of storing data associated with a
563   domain name in the DNS, as adding data in this fashion require no
564   registration process.  [RFC1464] experimented with a means of
565   incorporating name/value pairs to the TXT record structure, which
566   allowed applications to differentiate different chunks of data stored
567   in a TXT record.  In this fashion, an application that wants to store
568   additional data in the DNS can do so without registering a new
569   resource record type - though [RFC5507] points out that it is
570   "difficult to reliably distinguish one application's record from
571   otters, and for its parser to avoid problems when it encounters other
572   TXT records."
573
574   While open policies surrounding the use of the TXT record have
575   resulted in a checkered past for standardizing application usage of
576   TXT, TXT has been used as a technical solution for DKIM [RFC4871] to
577   store necessary information about the security of email in DNS,
578   though within a narrow naming convention (records stored under
579   "_domainkey" subdomains).  Storing keys in the DNS became the
580   preferred solution for DKIM for several reasons: notably, because the
581   public keys associated with email required wide public distribution,
582   and because email identifiers contain a domain component that
583   applications can easily use to consult the DNS.  If the application
584   had to negotiate support for the DKIM mechanism with mail servers, it
585   would give rise to bid-down attacks (where attackers misrepresent
586   that DKIM is unsupported in the domain) that are not possible if the
587   DNS delivers the keys (provided that DNSSEC [RFC4033] guarantees
588   authenticity of the data).  However, there are potential issues with
589   story large data in the DNS, as discussed in Section 3.2.1 as well as
590   with the DKIM namespace conventions that prevent the use of DNS
591   wildcards (as discussed in section 3.6.2.1. of [RFC4871] and in more
592   general terms in [RFC5507]).
593
594
595
596
597
598
599
600
601
602Peterson, et al.       Expires September 13, 2012              [Page 10]
603
604Internet-Draft             Applications in DNS                March 2012
605
606
6073.  Challenges for the DNS
608
609   The methods discussed in the previous section for transforming
610   arbitrary identifiers into domain names, and for returning arbitrary
611   data in response to DNS queries, both represent significant
612   departures from the basic function of translating host names to IP
613   addresses, yet neither fundamentally alters the underlying semantics
614   of the DNS.  When we consider, however, that the URIs returned by
615   DDDS might be base 64 encoded binary data in the data URL [RFC2397],
616   the DNS could effectively implement the entire application feature
617   set of any simple query-response protocol.  Effectively, the DDDS
618   framework considers the DNS a generic database - indeed, the DDDS
619   framework was designed to work with any sort of underlying database;
620   as [RFC3403] shows, the DNS is only one potential database for DDDS
621   to use.  Whether the DNS as an underlying database can support the
622   features that some applications of DDDS require, however, is a more
623   complicated question.
624
625   As the following subsections will show, the potential that
626   applications might rely on the DNS as a generic database gives rise
627   to additional requirements that one might expect to find in a
628   database access protocol: authentication of the source of queries for
629   comparison to access control lists, formulating complex relational
630   queries, and asking questions about the structure of the database
631   itself.  DNS was not designed to provide these sorts of properties,
632   and extending the DNS to encompass them would represent a fundamental
633   alteration to its model.  Ultimately, this document concludes that
634   efforts to retrofit these capabilities into the DNS would be better
635   invested in selecting, or if necessary inventing, other Internet
636   services with broader powers than the DNS.  If an application
637   protocol designer wants these properties from a database, in general
638   this is a good indication that the DNS cannot, or only partly, meet
639   the needs of the application in question.
640
641   Since many of these new requirements have emerged from the ENUM
642   space, the following sections use ENUM as an illustrative example;
643   however, any application using the DNS as a feature-rich database
644   could easily end up with similar requirements.
645
6463.1.  Compound Queries
647
648   Traditionally, DNS information is uniquely identified by the domain
649   name, resource record type, and class.  DNS queries are based on this
650   3-tuple and the replies are resource record sets that are to be
651   treated as atomic data elements (see [RFC2181]); to applications the
652   behavior of the DNS has traditionally been that of an exact-match
653   query response lookup mechanism.  Outside of the DNS space, however,
654   there are plenty of query-response applications that require a
655
656
657
658Peterson, et al.       Expires September 13, 2012              [Page 11]
659
660Internet-Draft             Applications in DNS                March 2012
661
662
663   compound or relational search, which takes into account more than one
664   factor in formulating a response or uses no single factor as a key to
665   the database.  For example, in the telephony space, telephone call
666   routing often takes into account numerous factors aside from the
667   dialed number, including originating trunk groups, interexchange
668   carrier selection, number portability data, time of day, and so on.
669   All are considered simultaneously in generating a route.  While in
670   its original conception, ENUM hoped to circumvent the traditional
671   PSTN and route directly to Internet-enabled devices, the
672   infrastructure ENUM effort to support the migration of traditional
673   carrier routing functions to the Internet aspires to achieve feature
674   parity with traditional number routing.  However, [RFC3402]
675   explicitly states that "it is an assumption of the DDDS that the
676   lexical element used to make a delegation decision is simple enough
677   to be contained within the Application Unique String itself.  The
678   DDDS does not solve the case where a delegation decision is made
679   using knowledge contained outside the AUS and the Rule (time of day,
680   financial transactions, rights management, etc.)."  Consequently,
681   some consideration has been given to ways to add additional data to
682   ENUM queries to give the DNS server sufficient information to return
683   a suitable URI (see Section 3.1.1).
684
685   From a sheer syntactical perspective, however, domain names do not
686   admit of this sort of rich structure.  Several workarounds have
687   attempted to instantiate these sorts of features in DNS queries.  For
688   example, the domain name itself could be compounded with the
689   additional parameters: one could take a name like
690   0.0.4.5.4.3.4.1.7.5.1.e164.arpa and append a trunk group identifier
691   to it, for example, of the form
692   tg011.0.0.4.5.4.3.4.1.7.5.1.e164.arpa.  While in this particular case
693   a DNS server can adhere to its traditional behavior in locating
694   resource records, the syntactical viability of encoding additional
695   parameters in this fashion is dubious, especially if more than one
696   additional parameter is required and the presence of parameters is
697   optional so that the application needs multiple queries to assess the
698   completeness of the information it needs to perform its function.
699
700   More commonly, proposals piggyback additional query parameters as
701   EDNS0 extensions (see [RFC2671]).  This might be problematic for
702   three reasons.  First, supporting EDNS0 extensions requires
703   significant changes to name server behavior that needs to be
704   supported by the authoritative and recursive nameservers on which the
705   application relies and might be very hard to realize on a global
706   scale.  In addition, the intended applicability of the EDNS0
707   mechanism, as the [RFC2761] states, is to "a particular transport
708   level message and not to any actual DNS data," and consequently the
709   OPT Resource Records it specifies are never to be forwarded; the use
710   of EDNS0 for compound queries, however, clearly is intended to
711
712
713
714Peterson, et al.       Expires September 13, 2012              [Page 12]
715
716Internet-Draft             Applications in DNS                March 2012
717
718
719   discriminate actual DNS data rather than to facilitate transport-
720   layer handling.  Finally, [RFC2761] also specifies that OPT pseudo-
721   Resource Records are never cached (see the next paragraph).  For
722   these reasons, this memo recommends against the use of EDNS0 as a
723   mechanism for crafting compound DNS queries.
724
725   The implications of these sorts of compound queries for recursion and
726   caching are potentially serious.  The logic used by the authoritative
727   server to respond to a compound query may not be understood by any
728   recursive servers or caches; intermediaries that naively assume that
729   the response was selected based on the domain name, type and class
730   alone might serve responses to queries in a different way than the
731   authoritative server intends.
732
7333.1.1.  Responses Tailored to the Originator
734
735   The most important subcase of the compound queries are DNS responses
736   tailored to the identity of their originator, where some sort of
737   administrative identity of the originator must be conveyed to the
738   DNS.  We must first distinguish this from cases where the originating
739   IP address or a similar indication is used to serve a location-
740   specific name.  For those sorts of applications, which generally lack
741   security implications, relying on factors like the source IP address
742   introduces little harm; for example, when providing a web portal
743   customized to the region of the client, it would not be a security
744   breach if the client saw the localized portal of the wrong country.
745   Because recursive resolvers may obscure the origination network of
746   the DNS client, a recent proposal suggested introducing a new DNS
747   query parameter to be populated by DNS recursive resolvers in order
748   to preserve the originating IP address (see
749   [I-D.vandergaast-edns-client-ip]).  However, aside from purely
750   cosmetic uses, these approaches have known limitations due to the
751   prevalence of private IP addresses, VPNs and so on which obscure the
752   source IP address and instead supply the IP address of an
753   intermediary that may be very distant from the originating endpoint.
754   Implementing technology such as the one described by
755   [I-D.vandergaast-edns-client-ip] does require significant changes in
756   the operation of recursive resolvers and the authoritative servers
757   that would rely on the original source IP address to select Resource
758   Records, and moreover a fundamental change to caching behavior as
759   well.  As a result such technology can only be deployed after
760   bilateral (authoritative-resolver) agreement and is not likely to
761   deploy to ubiquitous Internet scale use.
762
763   In other deployments in use today, including those based on the BIND
764   "views" feature, the source IP address is used to grant access to a
765   private set of resource records.  The security implications of
766   trusting the source IP address of a DNS query have prevented most
767
768
769
770Peterson, et al.       Expires September 13, 2012              [Page 13]
771
772Internet-Draft             Applications in DNS                March 2012
773
774
775   solutions along these lines from being standardized (see [RFC6269]),
776   though the practice remains widespread in "split horizon" private DNS
777   deployment (see Section 4) which typically rely on an underlying
778   security layer, such as a physical network or an IPsec VPN, to
779   prevent spoofing of the source IP address.  These deployments do have
780   a confidentiality requirement to prevent information intended for a
781   constrained audience (internal to an enterprise, for example) from
782   leaking to the public Internet -- while these internal network
783   resources may use private IP addresses which would not be useful on
784   the public Internet anyway, in some cases this leakage would reveal
785   topology or other information that the name server provisioner hopes
786   to keep private.
787
788   These first two cases, regardless of their acceptance by the
789   standards community, have widespread acceptance in the field.  Some
790   applications, however, go even further and propose extending the DNS
791   to add an application-layer identifier of the originator rather than
792   an IP address; for example,
793   [I-D.kaplan-dnsext-enum-sip-source-ref-opt-code] provides a SIP URI
794   in an eDNS0 parameter.  Effectively, the conveyance of application-
795   layer information about the administrative identity of the originator
796   through the DNS is a weak authentication mechanism, on the basis of
797   which the DNS server makes an authorization decision before sharing
798   resource records.  This can parlay into a per-Resource Record
799   confidentiality mechanism, where only a specific set of originators
800   are permitted to see resource records, or a case where a query for
801   the same name by different entities results in completely different
802   resource record sets.  The DNS, however, substantially lacks the
803   protocol semantics to manage access control lists for data, and
804   again, caching, forwarding, and recursion introduce significant
805   challenges for applications that attempt to offload this
806   responsibility to the DNS.  Achieving feature parity with even the
807   simplest authentication mechanisms available at the application layer
808   would like require significant rearchitecture of the DNS.
809
8103.2.  Using DNS as a Generic Database
811
812   As previously noted, applications can use the DNS by transferring an
813   arbitrary string into a query (using a method like the First Well
814   Known Rule of DDDS) and receiving arbitrary data stored in custom
815   resource records (or potentially TXT RRs).  Some query-response
816   applications, however, require queries and responses that simply fall
817   outside the syntactic capabilities of the DNS.  Domain names
818   themselves must conform to certain syntactic constraints: they must
819   consist of labels that do not exceed 63 characters while the total
820   length of the encoded name may not exceed 255 octets, they must obey
821   fairly strict encoding rules, and so on.  The DNS therefore cannot be
822   a completely generic database.  Similar concerns apply to the size of
823
824
825
826Peterson, et al.       Expires September 13, 2012              [Page 14]
827
828Internet-Draft             Applications in DNS                March 2012
829
830
831   DNS responses.
832
8333.2.1.  Large Data in the DNS
834
835   While the data URL specification [RFC2397] notes that it is "only
836   useful for short values," unfortunately it gives no particular
837   guidance about what "short" might mean.  Many applications today use
838   quite large data URLs (containing a megabyte or more of data) as
839   workarounds in environments where only URIs can syntactically appear.
840   The meaning of "short" in an application context is probably very
841   different from how we should understand it in a DNS message.
842   Referring to a typical public DNS deployment, [RFC5507] observes that
843   "there's a strong incentive to keep DNS messages short enough to fit
844   in a UDP datagram, preferably a UDP datagram short enough not to
845   require IP fragmentation".  And while EDNS0 allows for mechanisms to
846   negotiate DNS message sizes larger than the traditional 512 octets
847   there is a high risk that a long payload will cause UDP
848   fragmentation, in particular when the DNS message already carries
849   DNSSEC information.  If EDNS0 is not available, or the negotiated
850   EDNS0 packet size is too small to fit the data, or UDP fragments are
851   dropped, the DNS will (eventually) resort to use TCP.  While TCP
852   allows DNS responses to be quite long, this requires stateful
853   operation of servers which can be costly in deployments where servers
854   have only fleeting connections to many clients.  Ultimately, there
855   are forms of data that an application might store in the DNS that
856   exceed reasonable limits: in the ENUM context, for example, something
857   like storing base 64 encoded mp3 files of custom ringtones.
858
859   Designs relying on storage of large amounts of data within DNS RRs
860   furthermore need to minimize the potential damage achievable in a
861   reflection attack (see [RFC4732], Section 3), in which the attacker
862   sends DNS queries with a forged source address, and the victim
863   receives the response.  By generating a large response to a small
864   query, the attacker can magnify the bandwidth directed at the victim.
865   Where the responder supports EDNS0, an attacker may set the requester
866   maximum payload size to a larger value while querying for a large
867   Resource Record, such as a certificate [RFC4398].  Thus the
868   combination of large data stored in DNS RRs and responders supporting
869   large payload sizes has the potential to increase the potential
870   damage achievable in a reflection attack.
871
872   Since a reflection attack can be launched from any network that does
873   not implement source address validation, these attacks are difficult
874   to eliminate absent the ubiquitous deployment of source address
875   validation.
876
877   The bandwidth that can be mustered in a reflection attack directed by
878   a botnet reflecting of a recursive nameserver on a high bandwidth
879
880
881
882Peterson, et al.       Expires September 13, 2012              [Page 15]
883
884Internet-Draft             Applications in DNS                March 2012
885
886
887   network is sobering.  For example, if the responding resolver could
888   be directed to generate a 10KB response in reply to a 50 octet query,
889   then magnification of 200:1 would be attainable.  This would enable a
890   botnet controlling 10000 hosts with 1 Mbps of bandwidth to focus 2000
891   Gbps of traffic on the victim, more than sufficient to congest any
892   site on the Internet.
893
894   Since it is prohibitively difficult to complete a TCP three-way
895   handshake begun from a forged source address, DNS reflection attacks
896   utilize UDP queries.  Unless the attacker uses EDNS0 [RFC2671] to
897   enlarge the requester's maximum payload size, a response can only
898   reach 576 octets before the truncate bit is set in the response.
899   This limits the maximum magnification achievable from a DNS query
900   that does not utilize EDNS0.  As the large disparity between the size
901   of a query and size of the response creates this amplification,
902   implementations should limit EDNS0 responses to a specific ratio
903   compared to the request size.  The precise ratio can be configured on
904   a per-deployment basis (taking into account DNSSEC response sizes),
905   but without this limitation, EDNS0 can cause significant harm.
906
907[BA] Dan Kaminsky has written a good article on DNSSEC and amplification
908attacks:
909http://technet.microsoft.com/en-us/security/hh972393.aspx
910
911As noted in the article, limiting EDNS0 replies to a maximum of 4K can
912limit the amplication factor while not impacting the scalability of
913DNSSEC.  Extending the maximum UDP packet size beyond this is probably
914inadvisable.
915
916   In summary, there are two operational forces that tend to drive the
917   practically available EDNS0 sizes down: possible UDP fragmentation
918   and minimizing magnification in case of reflection attacks.  DNSSEC
919   data will use a significant fraction of the available space in a DNS
920   packet.  Therefore -- appreciating that given the current DNSSEC and
921   EDNS0 deployment experience precise numbers are impossible to give --
922   the generic payload available to other DNS data, given the premise
923   that TCP fallback is to be minimized, is likely to be closer to of
924   several hundreds than a few thousand octets.
925
9263.3.  Administrative Structures Misaligned with the DNS
927
928   While the DDDS framework enables any sort of alphanumeric data to
929   serve as a DNS name through the application of the First Well Known
930   Rule, the delegative structure of the resulting DNS name may not
931   reflect the division of responsibilities for the resources that the
932   alphanumeric data indicates.  While [RFC3402] requires only that
933   "Application Unique String has some kind of regular, lexical
934   structure that the rules can be applied to," DDDS is first and
935   foremost a delegation system: its abstract stipulates that "Well-
936   formed transformation rules will reflect the delegation of management
937   of information associated with the string."  Telephone numbers in the
938   United States, for example, are assigned and delegated in a
939   relatively complex manner.  Historically, the first six digits of a
940   nationally specific number (called the "NPA/NXX") reflected a point
941   of administrative delegation from the number assignment agency to a
942   carrier; from these blocks of ten thousand numbers, the carrier would
943   in turn delegate individual assignments of the last four digits (the
944
945
946
947Peterson, et al.       Expires September 13, 2012              [Page 16]
948
949Internet-Draft             Applications in DNS                March 2012
950
951
952   "XXXX" portion) to particular customers.  However, after the rise of
953   North American telephone number portability in the 1990s, the first
954   point of delegation went away: the delegation is effectively from the
955   number authority to the carrier for each the complete ten-digit
956   number (NPA/NXX-XXXX).  While technical implementation details differ
957   from nation to nation, number portability systems with similar
958   administrative delegations now exist worldwide.
959
960   To render these identifiers as domain names in accordance with the
961   DDDS Rule for ENUM yields a large flat administrative domain with no
962   points of administrative delegation from the country-code
963   administrator, e.g. 1.e164.arpa, down to the ultimately assignee of a
964   number.  Under the assumption that one administrative domain is
965   maintained within one DNS zone containing potentially over five
966   billion names, scalability difficulties manifest in a number of
967   areas: The scalability that results from caching depends on points of
968   delegation so that cached results for intermediate servers take the
969   load off higher tier servers.  If there are no such delegations, then
970   as in the telephone number example the zone apex server must bear the
971   entire load for queries.  Worse still, number portability also
972   introduces far more dynamism in number assignment, where in some
973   regions updated assignees for ported numbers must propagate within
974   fifteen minutes of a change in administration.  Jointly, these two
975   problems make caching the zone extremely problematic.  Moreover,
976   traditional tools for DNS replication, such as the zone transfer
977   protocol AXFR [RFC1034] and IXFR [RFC1995], might not scale to
978   accommodate zones with these dimensions and properties.
979
980   In practice, the maximum sizes of telephone number administrative
981   domains are closer to 300M (the current amount of allocated telephone
982   numbers in the United States today - still more than three times the
983   number of .com domain names) and one can alleviate some of the
984   scalability issues mentioned above by artificially dividing the
985   administrative domain into a hierarchy of DNS zones.  Still, the fact
986   that traditional DNS management tools no longer apply to the
987   structures that an application tries to provision in the DNS, is clue
988   that the DNS might not be the right place for an application to store
989   its data.
990
991   DDDS provides a capability that transforms arbitrary strings into
992   domain names, but those names play well with the DNS only when the
993   input string have an administrative structure that maps on DNS
994   delegations.  In the first place, delegation implies some sort of
995   hierarchical structure.  Any mechanism to map a hierarchical
996   identifier into a DNS name should be constructed such that the
997   resulting DNS name does match the natural hierarchy of the original
998   identifier.  Although telephone numbers, even in North America, have
999   some hierarchical qualities (like the geographical areas
1000
1001
1002
1003Peterson, et al.       Expires September 13, 2012              [Page 17]
1004
1005Internet-Draft             Applications in DNS                March 2012
1006
1007
1008   corresponding to their first three digits), after the implementation
1009   of number portability these points no longer mapped onto an
1010   administrative delegation.  If the input string to the DDDS does not
1011   have a hierarchical structure representing administrative delegations
1012   that can map onto the DNS distribution system, that string probably
1013   is not a good candidate for translating into a domain name.
1014
1015   The difficulty of mapping the DNS to administrative structures can
1016   even occur with traditional domain names, where applications expect
1017   clients to infer or locate zone cuts.  In the web context, for
1018   example, it can be difficult for applications to determine whether
1019   two domains represent the same "site" when comparing security
1020   credentials with URLs (see Section 3.4 below for more on this).
1021
10223.3.1.  Metadata about Tree Structure
1023
1024   There are also other ways in which the delegative structure of an
1025   identifier may not map well onto the DNS.  Traditionally, DNS
1026   resolvers assume that when they receive a domain name from an
1027   application, that the name is complete - that it is not a fragment of
1028   a DNS name that a user is still in the middle of typing.  For some
1029   communications systems, however, this assumption does not apply.
1030   ENUM use cases have surfaced a couple of optimization requirements to
1031   reduce unnecessary calls and queries by including metadata in the DNS
1032   that describes the contents and structure of ENUM DNS trees to help
1033   applications to handle incomplete queries or queries for domains not
1034   in use.  In particular, the "send-n" proposal
1035   [I-D.bellis-enum-send-n] hopes to reduce the number of DNS queries
1036   sent in regions with variable-length numbering plans.  When a dialed
1037   number potentially has a variable length, a telephone switch
1038   ordinarily cannot anticipate when a dialed number is complete, as
1039   only the numbering plan administrator (who may be a national
1040   regulator, or even in open number plans a private branch exchange)
1041   knows how long a telephone number needs to be.  Consequently, a
1042   switch trying to resolve such a number through a system like ENUM
1043   might send a query for a telephone number that has only partially
1044   been dialed in order to test its completeness.  The "send-n" proposal
1045   installs in the DNS a hint informing the telephone switch of the
1046   minimum number of digits that must be collected by placing in zones
1047   corresponding to incomplete telephone numbers some Resource Records
1048   which state how many more digits are required - effectively how many
1049   steps down the DNS tree one must take before querying the DNS again.
1050   Unsurprisingly, those boundaries reflect points of administrative
1051   delegation, where the parent in a number plan yields authority to a
1052   child.  With this information, the application is not required to
1053   query the DNS every time a new digit is dialed, but can wait to
1054   collect sufficient digits to receive a response.  As an optimization,
1055   this practice thus saves the resources of the DNS server - though the
1056
1057
1058
1059Peterson, et al.       Expires September 13, 2012              [Page 18]
1060
1061Internet-Draft             Applications in DNS                March 2012
1062
1063
1064   call cannot complete until all digits are collected, so at best this
1065   mechanism only reduces the time the system will wait before sending
1066   an ENUM query after collecting the final dialed digit.  A
1067   tangentially related proposal, [I-D.ietf-enum-unused], similarly
1068   places resource records in the DNS that tell the application that it
1069   need not attempt to reach a number on the telephone network, as the
1070   number is unassigned - a comparable general DNS mechanism would
1071   identify, for a domain name with no records available in the DNS,
1072   whether or not the domain had been allocated to an owner.
1073
1074   Both proposals optimize application behavior by placing metadata in
1075   the DNS that predicts the success of future queries or application
1076   invocation by identifying points of administrative delegation or
1077   assignment in the tree.  In some respects, marking a point in the
1078   tree where a zone begins or end has some features in common with the
1079   traditional parent zone use of the NS record type, except instead of
1080   pointing to a child zone, these metadata proposals point to distant
1081   grandchildren.  While this does not change resolver behavior as such
1082   (instead, it changes the way that applications invoke the resolver),
1083   it does have implications for the practices for zone administrators.
1084   Metadata in one administrative domain needs to remain synchronized
1085   with the state of the resources it predicts in another administrative
1086   domain in the DNS namespace, or resources associated with other
1087   namespaces.  Besides, maintaining that synchronization requires that
1088   the DNS have semi-real time updates that may conflict with scale and
1089   caching mechanisms of the DNS.
1090
1091   It may also raise questions about the authority and delegation model.
1092   Who gets to supply records for unassigned names?  While in the
1093   original but little-used "golden" root model of ENUM, this would
1094   almost certainly be a numbering plan administrator, it is far less
1095   clear who that would be in the more common and successful
1096   "infrastructure" ENUM models (see Section 4).  Ultimately, these
1097   metadata proposals share some qualities with DNS redirection services
1098   offered by ISPs (for example, [I-D.livingood-dns-redirect]) which
1099   "help" web users who try to browser to sites that do not exist -
1100   though in those cases, at least the existence or non-existence of a
1101   domain name is a fact about the Internet namespace, rather than about
1102   an external namespace like the telephone's e.164 namespace which must
1103   be synchronized with the DNS tree in the metadata proposals.  In
1104   send-n, different leaf zones, who administer telephone numbers of
1105   different lengths, can only provision their hints at their own apex,
1106   which provides an imperfect optimization: they cannot install it in a
1107   parent, both because they lack the authority and because different
1108   zones would want to provision contradictory data.  An application
1109   protocol designer who wants to manage identifiers whose
1110   administrative model does not map well onto the DNS namespace and
1111   delegations structure would be better served to implement such
1112
1113
1114
1115Peterson, et al.       Expires September 13, 2012              [Page 19]
1116
1117Internet-Draft             Applications in DNS                March 2012
1118
1119
1120   features outside the DNS.
1121
11223.4.  Domain Redirection
1123
1124   Most Internet application services provide a redirection feature -
1125   when you attempt to contact a service, the service may refer you to a
1126   different service instance, potentially in another domain, that is
1127   for whatever reason better suited to address a request.  In HTTP and
1128   SIP, for example, this feature is implemented by the 300 class
1129   responses containing one or more better URIs that may indicate that a
1130   resource has moved temporarily or permanently to another service.
1131   Several tools in the DNS, including the SRV record, can provide a
1132   similar feature at a DNS level, and consequently some applications as
1133   an optimization offload the responsibility for redirection to the
1134   DNS; NAPTR can also provide this capability on a per-application
1135   basis, and numerous DNS resource records can provide redirection on a
1136   per-domain basis.  This can prevent the unnecessary expenditure of
1137   application resources on a function that could be performed as a
1138   component of a DNS lookup that is already a prerequisite for
1139   contacting the service.  Consequently, in some deployment
1140   architectures this DNS-layer redirection is used for virtual hosting
1141   services.
1142
1143   Implementing domain redirection in the DNS, however, has important
1144   consequences for application security.  In the absence of universal
1145   DNSSEC, applications must blindly trust that their request has not
1146   been hijacked at the DNS layer and redirected to a potentially
1147   malicious domain, unless some subsequent application mechanism can
1148   provide the necessary assurance.  By way of contrast, application-
1149   layer redirections protocols like HTTP and SIP have available
1150
1151[BA] Might say "application-layer protocol supporting redirection such
1152as HTTP and SIP"
1153
1154   security mechanisms such as TLS that can use certificates to vouch
1155   that a 300 response came from the domain that the originator
1156   initially hoped to contact.
1157
1158   A number of applications have attempted to provide an after-the-fact
1159   security mechanism that verifies the authority of a DNS delegation in
1160   the absence of DNSSEC.  The specification for dereferencing SIP URIs
1161   ([RFC3263], reaffirmed in [RFC5922]), requires that during TLS
1162   establishment, the site eventually reached by a SIP request present a
1163   certificate corresponding to the original URI expected by the user
1164   (in other words, if example.com redirects to example.net in the DNS,
1165   this mechanism expects that example.net will supply a certificate for
1166   example.com in TLS, per the HTTP precedent in [RFC2818]), which
1167   requires a virtual hosting service to possess a certificate
1168   corresponding to the hosted domain.  This restriction rules out many
1169   styles of hosting deployments common in the web world today, however.
1170   [I-D.barnes-hard-problem] explores this problem space, and
1171   [I-D.saintandre-tls-server-id-check] proposes a solution for all
1172
1173[BA] The saintandre draft has subsequently been published as RFC 6125.
1174Section 3 provides recommendations, including:
1175
1176   o  Does your technology use DNS SRV records to resolve the DNS domain
1177      names of application services?  If so, consider recommending or
1178      requiring support for the SRV-ID identifier type in PKIX
1179      certificates issued and used in your technology community.  (Note
1180      that many existing application technologies use DNS SRV records to
1181      resolve the DNS domain names of application services, but do not
1182      rely on representations of those records in PKIX certificates by
1183      means of SRV-IDs as defined in [SRVNAME].)
1184
1185   o  Does your technology use URIs to identify application services?
1186      If so, consider recommending or requiring support for the URI-ID
1187      identifier type.  (Note that many existing application
1188      technologies use URIs to identify application services, but do not
1189      rely on representation of those URIs in PKIX certificates by means
1190      of URI-IDs.)
1191
1192Note that RFC 6125, the original URI is verified against the SRV-ID or
1193URI-ID identifier in the certificate supplied by the virtual hosting
1194service.
1195
1196
1197Peterson, et al.       Expires September 13, 2012              [Page 20]
1198
1199Internet-Draft             Applications in DNS                March 2012
1200
1201
1202   applications that use TLS.  Potentially, new types of certificates
1203   (similar to [RFC4985]) might bridge this gap, but support for those
1204   certificates would require changes to existing certificate authority
1205   practices as well as application behavior.
1206
1207   All of these application-layer measures attempt to mirror the
1208   delegation of administrative authority in the DNS, when the DNS
1209   itself serves as the ultimate authority on how domains are delegated
1210   (Note: changing the technical delegation structure by changing NS
1211   records in the DNS is not the same as administrative delegation e.g.
1212   when a domain changes ownership).  Synchronizing a static instrument
1213   like a certificate with a delegation in the DNS, however, is
1214   problematic because delegations are not static: revoking and
1215   reissuing a certificate every time an administrative delegation
1216   changes is cumbersome operationally.  In environments where DNSSEC is
1217   not available, the problems with securing DNS-layer redirections
1218   would be avoided by performing redirections in the application-layer.
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253Peterson, et al.       Expires September 13, 2012              [Page 21]
1254
1255Internet-Draft             Applications in DNS                March 2012
1256
1257
12584.  Private DNS and Split Horizon
1259
1260   The classic view of the uniqueness of DNS names is given in
1261   [RFC2826]:
1262
1263   DNS names are designed to be globally unique, that is, for any
1264   one DNS name at any one time there must be a single set of DNS
1265   records uniquely describing protocol addresses, network resources and
1266   services associated with that DNS name.  All of the applications
1267   deployed on the Internet which use the DNS assume this, and Internet
1268   users expect such behavior from DNS names.
1269
1270   However, [RFC2826] "does not preclude private networks from operating
1271   their own private name spaces," but notes that if private networks
1272   "wish to make use of names uniquely defined for the global Internet,
1273   they have to fetch that information from the global DNS naming
1274   hierarchy."  There are various DNS deployments outside of the global
1275   public DNS, including "split horizon" deployments and DNS usages on
1276   private (or virtual private) networks.  In a split horizon, an
1277   authoritative server gives different responses to queries from the
1278   public Internet than they do to internal resolvers; as they typically
1279   differentiate internal from public queries by the source IP address,
1280   the concerns in Section 3.1.1 apply to such deployments.  When the
1281   internal address space range is private [RFC1918], this both makes it
1282   easier for the server to discriminate public from private and harder
1283   for public entities to impersonate nodes in the internal network.
1284   Networks that are made private physically, or logically by
1285   cryptographic tunnels, make these private deployments more secure.
1286   The most complex deployments along these lines use multiple virtual
1287   private networks to serve different answers for the same name to many
1288   networks.
1289
1290   The use cases that motivate split horizon DNS typically involve
1291   restricting access to some network services - intranet resources like
1292   internal web site, development servers or directories, for example -
1293   while preserving the ease of use offered by domain names for internal
1294   users.  While for many of these resources, the split horizon would
1295   not return answers to public resolvers for those internal resources
1296   (those records are kept confidential from the public), in some cases,
1297   the same name (e.g., "mail.example.com") might resolve to one host
1298   internally but another externally.  The requirements for multiple-VPN
1299   private deployments, however, are different: in this case the
1300   authoritative server gives different, and confidential, answers to a
1301   set of resolvers querying for the same name.  While these sorts of
1302   use cases rarely arise for traditional domain names, where, as
1303   [RFC2826] says, users and applications expect a unique resolution for
1304   a name, they can easily arise when other sorts of identifiers have
1305   been translated by a mechanism like DDDS into "domain name syntax."
1306
1307
1308
1309Peterson, et al.       Expires September 13, 2012              [Page 22]
1310
1311Internet-Draft             Applications in DNS                March 2012
1312
1313
1314   Telephone calls, for example, are traditionally routed through highly
1315   mediated networks, and an attempt to find a route for a call often
1316   requires finding an appropriate intermediary based on the source
1317   network and location rather than finding an endpoint (see the
1318   distinction between the Look-Up Function and Location Routing
1319   Function in [RFC5486]).  Moreover, the need for selective responses
1320   and confidentially is easily motivated when the data returned by the
1321   DNS is no longer "describing protocol addresses, network resources
1322   and services," but instead arbitrary data.  Although ENUM was
1323   originally intended for deployment in the global public root of the
1324   DNS (under e164.arpa), for example, the requirements of maintaining
1325   telephone identifiers in the DNS quickly steered operators into
1326   private deployments.
1327
1328   In private environments, it is also easier to deploy any necessary
1329   extensions than it is in the public DNS: in the first place,
1330   proprietary non-standard extensions and parameters can easily be
1331   integrated into DNS queries or responses as the implementations of
1332   resolvers and servers can likely be controlled; secondly,
1333   confidentiality and custom responses can be provided by deploying,
1334   respectively, underlying physical or virtual private networks to
1335   shield the private tree from public queries, and effectively
1336   different virtual DNS trees for each administrative entity that might
1337   launch a query; thirdly, in these constrained environments, caching
1338   and recursive resolvers can be managed or eliminated in order to
1339   prevent any unexpected intermediary behavior.  While these private
1340   deployments serve an important role in the marketplace, there are
1341   risks in using techniques intended only for deployment in private and
1342   constrained environments as the basis of a standard solution.  When
1343   proprietary parameters or extensions are deployed in private
1344   environments, experience teaches us that these implementations will
1345   begin to interact with the public DNS, and that the private practices
1346   will leak.
1347
1348   While such leakage is not a problem when using the extension
1349   mechanisms described in Sections 3.1, 3.2, and 3.5 (with private RR
1350   types) of [RFC5507], other extension mechanisms might cause
1351   confusion, or harm if leaked.  However, the use of a dedicated suffix
1352   (Section 3.3 [RFC5507]) in a private environment might cause
1353   confusion if leaked to the public internet, for example.
1354
1355   That this kind of leakage leakage of protocol elements from private
1356   deployments to public deployments does happen has been demonstrated,
1357   for example, with SIP: SIP implemented a category supposedly private
1358   extensions (notably the "P-" headers) which saw widespread success
1359   and use outside of the constrained environments for which they were
1360   specifically designed.  There is no reason to think that
1361   implementations with similar "private" extensions to the DNS
1362
1363
1364
1365Peterson, et al.       Expires September 13, 2012              [Page 23]
1366
1367Internet-Draft             Applications in DNS                March 2012
1368
1369
1370   protocols would not similarly end up in use in public environments.
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421Peterson, et al.       Expires September 13, 2012              [Page 24]
1422
1423Internet-Draft             Applications in DNS                March 2012
1424
1425
14265.  Principles and Guidance
1427
1428   The success of the DNS relies on the fact that it is a distributed
1429   database, one that has the property that it is loosely coherent and
1430   that it offers lookup instead of search functionality.  Loose
1431   coherency means that answers to queries are coherent within the
1432   bounds of data replication between authoritative servers (as
1433   controlled by the administrator of the zone) and caching behavior by
1434   recursive name servers.  It is critical that application designers
1435   who intend to use the DNS to support their applications consider the
1436   implications that their uses have for the behavior of resolvers,
1437   intermediaries including caches and recursive resolvers, and
1438   authoritative servers.
1439
1440   It is likely that the DNS provides a good match whenever applications
1441   needs are aligned with the following properties:
1442
1443      Data stored in the DNS can be propagated and cached using
1444      conventional DNS mechanisms, without intermediaries needing to
1445      understand exceptional logic (considerations beyond the name, type
1446      and class of the query) used by the authoritative server to
1447      formulate responses
1448
1449      Data stored in the DNS is indexed by keys that do not violate the
1450      syntax or semantics of domain names
1451
1452      Applications invoke the DNS to resolve complete names, not
1453      fragments
1454
1455      Answers do not depend on an application-layer identity of the
1456      entity doing the query
1457
1458      Ultimately, applications invoke the DNS to assist in communicating
1459      with the domain of the name they are resolving
1460
1461   Whenever one of the four properties above does not apply to one's
1462   data, one should seriously consider whether the DNS is the best place
1463   to store actual data.  On the other hand, good indicators that the
1464   DNS is not the appropriate tool for solving problems is when you have
1465   to worry about:
1466
1467      Populating metadata about domain boundaries within the tree - the
1468      points of administrative delegation in the DNS are something that
1469      applications should in general not be aware off
1470
1471      Domain names derived from identifiers that do not share a
1472      semantics or administrative model compatible with the DNS
1473
1474
1475
1476
1477Peterson, et al.       Expires September 13, 2012              [Page 25]
1478
1479Internet-Draft             Applications in DNS                March 2012
1480
1481
1482      Selective confidentiality of data stored in and provided by the
1483      DNS
1484
1485      DNS responses not fitting into UDP packets, unless EDNS0 is
1486      available, and only then with the caveats discussed above
1487
1488   In cases where applications require these sorts of features, they are
1489   simply better instantiated by independent application-layer protocols
1490   than the DNS.  The query-response semantics of the DNS are similar to
1491   HTTP, for example, and the objects which HTTP can carry both in
1492   queries and responses can easily contain the necessary structure to
1493   manage compound queries.  Many applications already use HTTP because
1494   of widespread support for it in middleboxes.  Similarly, HTTP has
1495   numerous ways to provide the necessary authentication, authorization
1496   and confidentiality properties that some features require, as well as
1497   the redirection properties discussed in Section 3.4.  The overhead of
1498   using HTTP may not be appropriate for all environments, but even in
1499   environments where a more lightweight protocol is appropriate, DNS is
1500   not the only alternative.
1501
1502   Where the administrative delegations of the DNS form a necessary
1503   component in the instantiation of an application feature, there are
1504   various ways that the DNS can bootstrap access to an independent
1505   application-layer protocol better suited to field the queries in
1506   question.  For example, since NAPTR or URI resource
1507   [I-D.faltstrom-uri] records can contain URIs, those URIs can in turn
1508   point to an external query-response service such as HTTP where more
1509   syntactically and semantically rich queries and answers might be
1510   exchanged.
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533Peterson, et al.       Expires September 13, 2012              [Page 26]
1534
1535Internet-Draft             Applications in DNS                March 2012
1536
1537
15386.  Security Considerations
1539
1540   Many of the concerns about how applications use the DNS discussed in
1541   this document involve security.  The perceived need to authenticate
1542   the source of DNS queries (see Section 3.1.1) and authorize access to
1543   particular resource records also illustrates the fundamental security
1544   principles that arise from offloading certain application features to
1545   the DNS.  As Section 3.2.1 observes, large data in the DNS can
1546   provide a means of generating reflection attacks, and without the
1547   remedies discussed in that section (especially the use of EDNS0 and
1548   TCP) the presence of large records is not recommended.  Section 3.4
1549   discusses a security problem concerning redirection that has surfaced
1550   in a number of protocols (see [I-D.barnes-hard-problem]).
1551
1552[BA] Might be better to refer to RFC 6125.
1553
1554   While DNSSEC, were it deployed universally, can play an important
1555   part in securing application redirection in the DNS, DNSSEC does not
1556   provide a means for a resolver to authenticate itself to a server,
1557   nor a framework for servers to return selective answers based on the
1558   authenticated identity of resolvers.  The existing feature set of
1559   DNSSEC is however sufficient for providing security for most of the
1560   ways that applications traditionally have used the DNS.  The
1561   deployment of DNSSEC ([RFC4033] and related specifications) is
1562   therefore encouraged.  Nothing in this document is intended to
1563   discourage either the implementation, deployment, or use of Secure
1564   DNS Dynamic Updates ([RFC2136].
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591Peterson, et al.       Expires September 13, 2012              [Page 27]
1592
1593Internet-Draft             Applications in DNS                March 2012
1594
1595
15967.  IANA Considerations
1597
1598   This document contains no considerations for the IANA.
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647Peterson, et al.       Expires September 13, 2012              [Page 28]
1648
1649Internet-Draft             Applications in DNS                March 2012
1650
1651
16528.  IAB Members
1653
1654   Internet Architecture Board Members at the time this document was
1655   published were:
1656
1657   [TO BE INSERTED]
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703Peterson, et al.       Expires September 13, 2012              [Page 29]
1704
1705Internet-Draft             Applications in DNS                March 2012
1706
1707
17089.  Acknowledgements
1709
1710   The IAB appreciates the comments and often spirited disagreements of
1711   Ed Lewis, Dave Crocker, Ray Bellis, Lawrence Conroy, Ran Atkinson,
1712   Patrik Faltstrom and Eliot Lear.
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759Peterson, et al.       Expires September 13, 2012              [Page 30]
1760
1761Internet-Draft             Applications in DNS                March 2012
1762
1763
176410.  Informative References
1765
1766   [I-D.barnes-hard-problem]
1767              Barnes, R. and P. Saint-Andre, "High Assurance Re-
1768              Direction (HARD) Problem Statement",
1769              draft-barnes-hard-problem-00 (work in progress),
1770              July 2010.
1771
1772   [I-D.bellis-enum-send-n]
1773              Bellis, R., "IANA Registrations for the 'Send-N'
1774              Enumservice", draft-bellis-enum-send-n-02 (work in
1775              progress), June 2008.
1776
1777   [I-D.faltstrom-uri]
1778              Faltstrom, P. and O. Kolkman, "The Uniform Resource
1779              Identifier (URI) DNS Resource Record",
1780              draft-faltstrom-uri-06 (work in progress), October 2010.
1781
1782   [I-D.ietf-enum-unused]
1783              Stastny, R., Conroy, L., and J. Reid, "IANA Registration
1784              for Enumservice UNUSED", draft-ietf-enum-unused-04 (work
1785              in progress), March 2008.
1786
1787   [I-D.kaplan-dnsext-enum-sip-source-ref-opt-code]
1788              Kaplan, H., Walter, R., Gorman, P., and M. Maharishi,
1789              "EDNS Option Code for SIP and PSTN Source Reference Info",
1790              draft-kaplan-dnsext-enum-sip-source-ref-opt-code-03 (work
1791              in progress), October 2011.
1792
1793   [I-D.livingood-dns-redirect]
1794              Creighton, T., Griffiths, C., Livingood, J., and R. Weber,
1795              "DNS Redirect Use by Service Providers",
1796              draft-livingood-dns-redirect-03 (work in progress),
1797              October 2010.
1798
1799   [I-D.saintandre-tls-server-id-check]
1800              Saint-Andre, P. and J. Hodges, "Representation and
1801              Verification of Domain-Based Application Service Identity
1802              in Certificates Used with Transport Layer Security",
1803              draft-saintandre-tls-server-id-check-09 (work in
1804              progress), August 2010.
1805
1806   [I-D.vandergaast-edns-client-ip]
1807              Contavalli, C., Gaast, W., Leach, S., and D. Rodden,
1808              "Client IP information in DNS requests",
1809              draft-vandergaast-edns-client-ip-01 (work in progress),
1810              May 2010.
1811
1812
1813
1814
1815Peterson, et al.       Expires September 13, 2012              [Page 31]
1816
1817Internet-Draft             Applications in DNS                March 2012
1818
1819
1820   [RFC0882]  Mockapetris, P., "Domain names: Concepts and facilities",
1821              RFC 882, November 1983.
1822
1823   [RFC0974]  Partridge, C., "Mail routing and the domain system",
1824              RFC 974, January 1986.
1825
1826   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
1827              STD 13, RFC 1034, November 1987.
1828
1829   [RFC1035]  Mockapetris, P., "Domain names - implementation and
1830              specification", STD 13, RFC 1035, November 1987.
1831
1832   [RFC1464]  Rosenbaum, R., "Using the Domain Name System To Store
1833              Arbitrary String Attributes", RFC 1464, May 1993.
1834
1835   [RFC1530]  Malamud, C. and M. Rose, "Principles of Operation for the
1836              TPC.INT Subdomain: General Principles and Policy",
1837              RFC 1530, October 1993.
1838
1839   [RFC1794]  Brisco, T., "DNS Support for Load Balancing", RFC 1794,
1840              April 1995.
1841
1842   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
1843              E. Lear, "Address Allocation for Private Internets",
1844              BCP 5, RFC 1918, February 1996.
1845
1846   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
1847              August 1996.
1848
1849   [RFC2052]  Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
1850              location of services (DNS SRV)", RFC 2052, October 1996.
1851
1852   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
1853              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
1854              RFC 2136, April 1997.
1855
1856   [RFC2168]  Daniel, R. and M. Mealling, "Resolution of Uniform
1857              Resource Identifiers using the Domain Name System",
1858              RFC 2168, June 1997.
1859
1860   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
1861              Specification", RFC 2181, July 1997.
1862
1863   [RFC2397]  Masinter, L., "The "data" URL scheme", RFC 2397,
1864              August 1998.
1865
1866   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
1867              RFC 2671, August 1999.
1868
1869
1870
1871Peterson, et al.       Expires September 13, 2012              [Page 32]
1872
1873Internet-Draft             Applications in DNS                March 2012
1874
1875
1876   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
1877
1878   [RFC2826]  Internet Architecture Board, "IAB Technical Comment on the
1879              Unique DNS Root", RFC 2826, May 2000.
1880
1881   [RFC2915]  Mealling, M. and R. Daniel, "The Naming Authority Pointer
1882              (NAPTR) DNS Resource Record", RFC 2915, September 2000.
1883
1884   [RFC2916]  Faltstrom, P., "E.164 number and DNS", RFC 2916,
1885              September 2000.
1886
1887   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
1888              Update", RFC 3007, November 2000.
1889
1890   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
1891              A., Peterson, J., Sparks, R., Handley, M., and E.
1892              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
1893              June 2002.
1894
1895   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
1896              Protocol (SIP): Locating SIP Servers", RFC 3263,
1897              June 2002.
1898
1899   [RFC3401]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
1900              Part One: The Comprehensive DDDS", RFC 3401, October 2002.
1901
1902   [RFC3402]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
1903              Part Two: The Algorithm", RFC 3402, October 2002.
1904
1905   [RFC3403]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
1906              Part Three: The Domain Name System (DNS) Database",
1907              RFC 3403, October 2002.
1908
1909   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1910              Resource Identifier (URI): Generic Syntax", STD 66,
1911              RFC 3986, January 2005.
1912
1913   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
1914              Rose, "DNS Security Introduction and Requirements",
1915              RFC 4033, March 2005.
1916
1917   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
1918              and T. Wright, "Transport Layer Security (TLS)
1919              Extensions", RFC 4366, April 2006.
1920
1921   [RFC4367]  Rosenberg, J. and IAB, "What's in a Name: False
1922              Assumptions about DNS Names", RFC 4367, February 2006.
1923
1924
1925
1926
1927Peterson, et al.       Expires September 13, 2012              [Page 33]
1928
1929Internet-Draft             Applications in DNS                March 2012
1930
1931
1932   [RFC4732]  Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
1933              Service Considerations", RFC 4732, December 2006.
1934
1935   [RFC4871]  Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
1936              J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
1937              Signatures", RFC 4871, May 2007.
1938
1939   [RFC4985]  Santesson, S., "Internet X.509 Public Key Infrastructure
1940              Subject Alternative Name for Expression of Service Name",
1941              RFC 4985, August 2007.
1942
1943   [RFC5486]  Malas, D. and D. Meyer, "Session Peering for Multimedia
1944              Interconnect (SPEERMINT) Terminology", RFC 5486,
1945              March 2009.
1946
1947   [RFC5507]  IAB, Faltstrom, P., Austein, R., and P. Koch, "Design
1948              Choices When Expanding the DNS", RFC 5507, April 2009.
1949
1950   [RFC5922]  Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
1951              Certificates in the Session Initiation Protocol (SIP)",
1952              RFC 5922, June 2010.
1953
1954   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
1955              Roberts, "Issues with IP Address Sharing", RFC 6269,
1956              June 2011.
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983Peterson, et al.       Expires September 13, 2012              [Page 34]
1984
1985Internet-Draft             Applications in DNS                March 2012
1986
1987
1988Authors' Addresses
1989
1990   Jon Peterson
1991   NeuStar, Inc.
1992
1993   Email: jon.peterson@neustar.biz
1994
1995
1996   Olaf Kolkman
1997   NLnet Labs
1998
1999   Email: olaf@nlnetlabs.nl
2000
2001
2002   Hannes Tschofenig
2003   Nokia Siemens Networks
2004
2005   Email: Hannes.Tschofenig@gmx.net
2006
2007
2008   Bernard Aboba
2009   Microsoft Corporation
2010
2011   Email: bernarda@microsoft.com
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039Peterson, et al.       Expires September 13, 2012              [Page 35]