idnits 2.17.1 draft-iab-dns-applications-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 31, 2011) is 4561 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2761' is mentioned on line 488, but not defined == Missing Reference: 'RFC4398' is mentioned on line 616, but not defined == Unused Reference: 'RFC4366' is defined on line 1205, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-faltstrom-uri-06 == Outdated reference: A later version (-14) exists of draft-saintandre-tls-server-id-check-09 -- Obsolete informational reference (is this intentional?): RFC 882 (Obsoleted by RFC 1034, RFC 1035) -- Obsolete informational reference (is this intentional?): RFC 974 (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 2052 (Obsoleted by RFC 2782) -- Obsolete informational reference (is this intentional?): RFC 2168 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2915 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) -- Obsolete informational reference (is this intentional?): RFC 2916 (Obsoleted by RFC 3761) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 4871 (Obsoleted by RFC 6376) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Kolkman 3 Internet-Draft NLNet 4 Intended status: Informational J. Peterson 5 Expires: May 3, 2012 NeuStar, Inc. 6 H. Tschofenig 7 Nokia Siemens Networks 8 B. Aboba 9 Microsoft Corporation 10 October 31, 2011 12 Architectural Considerations on Application Features in the DNS 13 draft-iab-dns-applications-03 15 Abstract 17 A number of Internet applications rely on the Domain Name System 18 (DNS) to support their operations. Many applications use the DNS to 19 locate services for a domain, for example; more recently, some 20 applications have begun transforming identifiers other than domain 21 names into formats that the DNS can process. Proposals to 22 incorporate more sophisticated application behavior into the DNS, 23 however, have raised questions about the applicability and 24 extensibility of the DNS. This document explores the architectural 25 consequences of installing certain application features in the DNS, 26 and provides guidance to future application designers as to the sorts 27 of ways that application can make use of the DNS. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 3, 2012. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Overview of DNS Application Usages . . . . . . . . . . . . . . 6 77 2.1. Locating Services in a Domain . . . . . . . . . . . . . . 6 78 2.2. NAPTR and DDDS . . . . . . . . . . . . . . . . . . . . . . 7 79 2.3. Arbitrary Data in the DNS . . . . . . . . . . . . . . . . 9 80 3. Challenges for the DNS . . . . . . . . . . . . . . . . . . . . 11 81 3.1. Compound Queries . . . . . . . . . . . . . . . . . . . . . 11 82 3.1.1. Responses Tailored to the Originator . . . . . . . . . 13 83 3.2. Using DNS as a Generic Database . . . . . . . . . . . . . 14 84 3.2.1. Large Data in the DNS . . . . . . . . . . . . . . . . 14 85 3.3. Administrative Structures Misaligned with the DNS . . . . 16 86 3.3.1. Metadata about Tree Structure . . . . . . . . . . . . 17 87 3.4. Domain Redirection . . . . . . . . . . . . . . . . . . . . 19 88 4. Private DNS and Split Horizon . . . . . . . . . . . . . . . . 21 89 5. Principles and Guidance . . . . . . . . . . . . . . . . . . . 23 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 92 8. IAB Members . . . . . . . . . . . . . . . . . . . . . . . . . 27 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 94 10. Informative References . . . . . . . . . . . . . . . . . . . . 29 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 97 1. Motivation 99 The Domain Name System (DNS) has long provided a general means of 100 translating easily-memorized domain names into numeric Internet 101 Protocol addresses, which makes the Internet easier to use by 102 providing a valuable layer of indirection between well-known names 103 and lower-layer protocol elements. [RFC0974] documented a further 104 use of the DNS: to manage application services operating in a domain 105 with the Mail Exchange (MX) resource record, which helped email 106 addressed to the domain to find a mail service for the domain 107 sanctioned by the zone administrator. 109 The seminal MX record served as a prototype for other DNS resource 110 records that supported applications associated with a domain name. 111 The SRV resource record [RFC2052] provided a more general mechanism 112 for locating services in a domain, complete with a weighting system 113 and selection among transports. The Naming Authority Pointer (NAPTR, 114 originally [RFC2168]) resource record, especially as it evolved into 115 the more general Dynamic Delegation Discovery System (DDDS, [RFC3401] 116 passim) framework, added a new wrinkle - an algorithm for 117 transforming a string into a domain name, which might then be 118 resolved by the DNS to find NAPTR records. This enabled the 119 resolution of identifiers that do not have traditional host 120 components through the DNS; the best-known example of this are 121 telephone numbers, as resolved by the DDDS application ENUM. Recent 122 work such as Domain Keys Identified Mail (DKIM, [RFC4871]) has 123 enabled security features of applications to be advertised through 124 the DNS, via the TXT resource record. 126 As the amount of application intelligence available to the DNS has 127 increased, however, some proposed usages and extensions have become 128 misaligned with both the architecture and underlying protocols of the 129 DNS. In the global public DNS, for example, the resolution of domain 130 names to IP addresses is public information with no expectation of 131 confidentiality, and thus the underlying query/response protocol has 132 no authentication or encryption mechanism - typically, any security 133 required by an application or service is invoked after the DNS query, 134 when the resolved service has been contacted. Only in private DNS 135 environments (including split horizon DNS) where the identity of the 136 querier is assured through some external means does the DNS maintain 137 confidential records in this sense - although for load balancing 138 reasons, localization or related optimizations, the public DNS may 139 return different addresses in response to queries from different 140 sources, or even no response at all, which is discussed further in 141 Section 3.1.1. Applications in many environments require these sorts 142 of features from databases, and as the contexts in which applications 143 rely on the DNS have increased, some application protocols have 144 looked to extend the DNS to include these sorts of capabilities. 146 This document therefore provides guidance to designers of 147 applications and application protocols on the use or extension of the 148 DNS to provide features to applications. It offers an overview of 149 ways that applications have used the DNS in the past, as well as 150 proposed ways that applications could use the DNS that might raise 151 concerns. It gives some reasons to decide the question, "Should I 152 store this information in the DNS, or use some other means?" when 153 that question arises during protocol development. These guidelines 154 remind application protocol designers of the strengths and weaknesses 155 of the DNS in order to make it easier for designers to decide what 156 features the DNS should provide for their application. 158 The guidance in this document complements the guidance on extending 159 the DNS given in [RFC5507]. Whereas [RFC5507] considers the 160 preferred ways to add new information to the underlying syntax of the 161 DNS (such as defining new resource records or adding prefixes or 162 suffixes to labels), the current document considers broader 163 implications of offloading application features to the DNS, be it 164 through extending the DNS or simply reusing existing protocol 165 capabilities - implications that may concern the invocation of the 166 resolver by applications, the behavior of name servers, resolvers or 167 caches, extensions to the underlying DNS protocol, the operational 168 responsibilities of zone administrators, security, or the overall 169 architecture of names. When existing DNS protocol fields are used in 170 ways that their designers did not intend to handle new applications, 171 those applications may require further changes and extensions that 172 are fundamentally at odds with the strengths of the DNS. 174 2. Overview of DNS Application Usages 176 [RFC0882] identifies the original and fundamental connection between 177 the DNS and applications. It begins by describing how the 178 interdomain scope of applications creates "formidable problems when 179 we wish to create consistent methods for referencing particular 180 resources that are similar but scattered throughout the environment." 181 This motivated "the need to have a mapping between host names... and 182 ARPA Internet addresses" transition from a global table (the original 183 "hosts.txt" file) to a "distributed database that performs the same 184 function." [RFC0882] also envisioned some ways to find the resources 185 associated with mailboxes in a domain: without these extensions, a 186 user trying to send mail to a foreign domain lacked a discovery 187 mechanism to locate the right host in the remote domain to which to 188 connect. 190 While a special-purpose discovery mechanism could be built by each 191 such application protocol that needed this functionality, the 192 universality of the DNS invites installing these features into its 193 public tree. Over time, several other applications leveraged 194 resource records for locating services in a domain or for storing 195 application data associated with a domain in the DNS. This section 196 gives an overview of such application usage to date. 198 2.1. Locating Services in a Domain 200 The MX resource record provides the simplest motivating example for 201 an application advertising its resources in the Domain Name System. 202 The MX resource record contains the domain name of a server that 203 receives mail on behalf of the administrative domain in question; 204 that domain name must itself be resolved to one or more IP addresses 205 through the DNS in order to reach the mail server. While naming 206 conventions for applications might serve a similar purpose (a host 207 might be named "mail.example.com" for example), approaching service 208 location through the creation of a new resource record yields 209 important benefits. For example, one can put multiple MX records 210 under the same name, in order to designate backup resources or to 211 load balance across several such servers (see [RFC1794]); these 212 properties could not easily be captured by naming conventions (see 213 [RFC4367]). 215 While the MX record represents a substantial improvement over naming 216 conventions as a means of service location, it remains specific to a 217 single application. Thus, the general approach of the MX record was 218 adapted to fit a broader class of application through the Service 219 (SRV) resource record (originally [RFC2052]). The SRV record allows 220 DNS resolvers to query for particular services and underlying 221 transports (for example, HTTP running over TLS, see [RFC2818]) and to 222 learn a host name and port where that service resides in a given 223 domain. It also provides a weighting mechanism to allow load 224 balancing across several instances of a service. 226 The reliance of applications on the existence of MX and SRV records 227 has important implications for the way that applications manage 228 identifiers, and that way that applications pass DNS names to 229 resolvers. Email identifiers of the form "user@domain" rely on MX 230 records to provide the convenience of simply specifying a "domain" 231 component rather requiring to guess which particular host handles 232 mail on behalf of the domain. While for applications like web 233 browsing, naming conventions continue to abound ("www.example.com"), 234 SRV records allow applications to query for an application-specific 235 protocol and transport. For HTTP, the SRV service name corresponds 236 to the URL scheme of the identifier invoked by the application (e.g., 237 when "http://example.com" is the identifier, the SRV query is for 238 "_http._tcp.example.com"); for other applications, the SRV service 239 that the application passes to the resolver may be implicit in the 240 identifier. The identifier used at the application layer thus 241 designates the desired protocol and domain, but the application 242 offloads to the DNS finding the location of the host of that service 243 for the domain, the port where the service resided on that host, load 244 balancing and fault tolerance, and related application features. 245 Ultimately, resolvers that acquire MX or SRV records may use them as 246 intermediate transformations in order to arrive at an eventual domain 247 name that will resolve to the IP addresses to contact for the 248 service. 250 Locating specific services for a domain is thus the first major 251 function that applications offloaded to the DNS in addition to simple 252 name resolution. SRV broadened and generalized the precedent of MX 253 to make service location available to any application, rather than 254 just to mail. As the domain name of the located service might 255 require a second DNS query to resolve, [RFC1034] shows that the 256 Additional Data section of DNS responses may contain the 257 corresponding address records for the names of services designated by 258 the MX record; this optimization, which requires support in the 259 authoritative server and the resolver, is an initial example of how 260 support for application features requires changes to DNS operation. 262 2.2. NAPTR and DDDS 264 The NAPTR resource record evolved to fulfill a need in the transition 265 from Uniform Resource Locators (URLs) to the more mature URI 266 [RFC3986] framework, which incorporated Uniform Resources Names 267 (URNs). Unlike URLs, URNs typically do not convey enough semantics 268 internally to resolve them through the DNS, and consequently a 269 separate URI-transformation mechanism is required to convert these 270 types of URIs into domain names. This allowed identifiers with no 271 recognizable domain component to be treated as DNS names for the 272 purpose of name resolution. Once these transformations resulted in a 273 domain name, applications could retrieve NAPTR records under that 274 name in the DNS. NAPTR records contain a far more rich and complex 275 structure than MX or SRV resource records. A NAPTR record contains 276 two different weighting mechanisms ("order" and "preference"), a 277 "service" field to designate the application that the NAPTR record 278 described, and then two fields that could contain translations: a 279 "replacement" or "regular expression" field, only one of which 280 appeared in given NAPTR record. A "replacement," like NAPTR's 281 ancestor the PTR record, simply designates another domain name where 282 one would look for records associated with this service in the 283 domain. The "regexp," on the other hand, allows regular expression 284 transformations on the original URI intended to transform it into an 285 identifier that the DNS could resolve. 287 As the Abstract of [RFC2915] says, "This allows the DNS to be used to 288 lookup services for a wide variety of resource names (including URIs) 289 which are not in domain name syntax." Any sort of hierarchical 290 identifier can potentially be encoded as a DNS name, and thus 291 historically the DNS has often been used to resolve identifiers that 292 were never devised as a name for an Internet host. A prominent early 293 example is the in-addr domain [RFC0882], which transposes an IPv4 294 address into a domain name in order to query the DNS for name(s) 295 associated with the address. Similar mechanisms could obviously be 296 applied to other sorts of identifiers that lacked a domain component. 297 Eventually, this idea connected with activities to create a system 298 for resolving telephone numbers on the Internet, which became known 299 as ENUM (originally [RFC2916]). ENUM borrowed from an earlier 300 proposal, the "tpc.int" domain [RFC1530], which provided a means for 301 encoding telephone numbers as domain names by applying a string 302 preparation algorithm that required reversing the digits and treating 303 each individual digit as a label in a DNS name - thus, for example, 304 the number +15714345400 became 0.0.4.5.4.3.4.1.7.5.1.tpc.int. 306 In the ENUM system, in place of "tpc.int" the special domain 307 "e164.arpa" was reserved for use. In its more mature form in the 308 Dynamic Delegation and Discovery Service (DDDS) ([RFC3401] passim) 309 framework, this initial transformation of the telephone number to a 310 domain name was called the "First Well Known Rule." Its flexibility 311 has inspired a number of proposals beyond ENUM to encode and resolve 312 unorthodox identifiers in the DNS. Provided that the identifiers 313 transformed by the First Well Known Rule have some meaningful 314 structure and are not overly lengthy, virtually anything can serve as 315 an input for the DDDS structure: for example, civic addresses. 316 Though [RFC3402] stipulates of the identifier that "the lexical 317 structure of this string must imply a unique delegation path," there 318 is no requirement that the identifier be hierarchical, nor that the 319 points of delegation in the domain name created by the First Well 320 Known Rule correspond to any points of administrative delegation 321 implied by the structure of the identifier. 323 While this ability to look up names "which are not in the domain name 324 syntax" does not change the underlying DNS protocols - the names 325 generated by the DDDS algorithm are still just domain names - it does 326 change the context in which applications pass name to resolvers, and 327 can potentially require very different operational practices of zone 328 administrators(see Section 3.3). In terms of the results of a DNS 329 query, the presence of the "regexp" field of NAPTR records enabled 330 unprecedented flexibility in the types of identifiers that 331 applications could resolve with the DNS. Since the output of the 332 regular expression frequently took the form of a URI (in ENUM 333 resolution, for example, a telephone number might be converted into a 334 SIP URI [RFC3261]), anything that could be encoded as a URI might be 335 the result of resolving a NAPTR record - which, as the next section 336 explores, essentially means arbitrary data. 338 2.3. Arbitrary Data in the DNS 340 Since URI encoding has ways of carrying basically arbitrary data, 341 resolving a NAPTR record might result in an output other than an 342 identifier which would subsequently be resolved to IP addresses and 343 contacted for a particular application - it could give a literal 344 result consumed by the application. Originally, in [RFC2168], the 345 intended applicability of the regular expression field in NAPTR was 346 much more narrow: the regexp field contained a "substitution 347 expression that is applied to the original URI in order to construct 348 the next domain name to lookup," in order "change the host that is 349 contacted to resolve a URI" or as a way of "changing the path or host 350 once the URL has been assigned." The regular express tools available 351 to NAPTR record authors, however, grant much broader powers to alter 352 the input string, and thus applications began to rely on NAPTR to 353 perform more radical transformations. By [RFC3402], the output of 354 DDDS is wholly application-specific: "the Application must determine 355 what the expected output of the Terminal Rule should be," and the 356 example given in the document is one of identifying automobile parts 357 by inputting a part number is receiving at the end of the process 358 receiving information about the manufacturer (though this example 359 reflects that the DNS is only one database to which the DDDS 360 framework might apply). 362 NAPTR did not however pioneer the storage of arbitrary data in the 363 DNS. At the start, [RFC0882] observed that "it is unlikely that all 364 users of domain names will be able to agree on the set of resources 365 or resource information that names will be used to retrieve," and 366 consequently places little restriction on the information that DNS 367 records might carry: it might be "host addresses, mailbox data, and 368 other as yet undetermined information." [RFC1035] defined the TXT 369 record, a means to store arbitrary strings in the DNS; [RFC1034] 370 specifically stipulates that a TXT contains "descriptive text" and 371 that "the semantics of the text depends on the domain where it is 372 found." The existence of TXT records has long provided new 373 applications with a rapid way of storing data associated with a 374 domain name in the DNS, as adding data in this fashion require no 375 registration process. [RFC1464] added a means of incorporating name/ 376 value pairs to the TXT record structure, which allowed applications 377 to differentiate different chunks of data stored in a TXT record. In 378 this fashion, an application that wants to store additional data in 379 the DNS can do so without registering a new resource record type - 380 though [RFC5507] points out that it is "difficult to reliably 381 distinguish one application's record from otters, and for its parser 382 to avoid problems when it encounters other TXT records." 384 While open policies surrounding the use of the TXT record have 385 resulted in a checkered past for standardizing application usage of 386 TXT, TXT has been used as a technical solution for DKIM [RFC4871] to 387 store necessary information about the security of email in DNS, 388 though within a narrow naming convention (records stored under 389 "_domainkey" subdomains). Storing keys in the DNS became the 390 preferred solution for DKIM for several reasons: notably, because the 391 public keys associated with email required wide public distribution, 392 and because email identifiers contain a domain component that 393 applications can easily use to consult the DNS. If the application 394 had to negotiate support for the DKIM mechanism with mail servers, it 395 would give rise to bid-down attacks (where attackers misrepresent 396 that DKIM is unsupported in the domain) that are not possible if the 397 DNS delivers the keys (provided that DNSSEC [RFC4033] guarantees 398 authenticity of the data). However, there are potential issues with 399 story large data in the DNS, as discussed in Section 3.2.1. 401 3. Challenges for the DNS 403 The methods discussed in the previous section for transforming 404 arbitrary identifiers into domain names, and for returning arbitrary 405 data in response to DNS queries, both represent significant 406 departures from the basic function of translating host names to IP 407 addresses, yet neither fundamentally alters the underlying semantics 408 of the DNS. When we consider, however, that the URIs returned by 409 DDDS might be base 64 encoded binary data in the data URL [RFC2397], 410 the DNS could effectively implement the entire application feature 411 set of any simple query-response protocol. Effectively, the DDDS 412 framework overlays the DNS with a generic database - indeed, the DDDS 413 framework was designed to work with any sort of underlying database; 414 as [RFC3403] shows, the DNS is only one potential database for DDDS 415 to use. Whether the DNS as an underlying database can support the 416 features that some applications of DDDS require, however, is a more 417 complicated question. 419 As the following subsections will show, the potential that 420 applications might rely on the DNS as a generic database gives rise 421 to additional requirements that one might expect to find in a 422 database access protocol: authentication of the source of queries for 423 comparison to access control lists, formulating complex relational 424 queries, and asking questions about the structure of the database 425 itself. DNS was not designed to provide these sorts of properties, 426 and extending the DNS to encompass them would represent a fundamental 427 alteration to its model. Ultimately, this document concludes that 428 efforts to retrofit these capabilities into the DNS would be better 429 invested in selecting, or if necessary inventing, other Internet 430 services with broader powers than the DNS. If an application 431 protocol designer wants these properties from a database, in general 432 this is a good indication that the DNS cannot meet the needs of the 433 application in question. 435 Since many of these new requirements have emerged from the ENUM 436 space, the following sections use ENUM as an illustrative example; 437 however, any application using the DNS as a feature-rich database 438 could easily end up with similar requirements. 440 3.1. Compound Queries 442 Traditionally, the DNS requires resolvers to supply no information 443 other than the domain name, the type and the class of records sought 444 in order to receive a reply from an authoritative server. Outside of 445 the DNS space, however, there are plenty of query-response 446 applications that require a compound or relational search, which 447 takes into account more than one factor in formulating a response or 448 uses no single factor as a key to the database. For example, in the 449 telephony space, telephone call routing often takes into account 450 numerous factors aside from the dialed number, including originating 451 trunk groups, interexchange carrier selection, number portability 452 data, time of day, and so on. All are considered simultaneously in 453 generating a route. While in its original conception, ENUM hoped to 454 circumvent the traditional PSTN and route directly to Internet- 455 enabled devices, the infrastructure ENUM effort to support the 456 migration of traditional carrier routing functions to the Internet 457 aspires to achieve feature parity with traditional number routing. 458 However, [RFC3402] explicitly states that "it is an assumption of the 459 DDDS that the lexical element used to make a delegation decision is 460 simple enough to be contained within the Application Unique String 461 itself. The DDDS does not solve the case where a delegation decision 462 is made using knowledge contained outside the AUS and the Rule (time 463 of day, financial transactions, rights management, etc.)." 464 Consequently, some consideration has been given to ways to add 465 additional data to ENUM queries to give the DNS server sufficient 466 information to return a suitable URI (see Section 3.1.1). 468 From a sheer syntactical perspective, however, domain names do not 469 admit of this sort of rich structure. Several workarounds have 470 attempted to instantiate these sorts of features in DNS queries. 471 Most commonly, proposals piggyback additional query parameters as 472 EDNS0 extensions (see [RFC2671]); alternatively, the domain name 473 itself could be compounded with the additional parameters: one could 474 take a name like 0.0.4.5.4.3.4.1.7.5.1.e164.arpa and append a trunk 475 group identifier to it, for example, of the form 476 tg011.0.0.4.5.4.3.4.1.7.5.1.e164.arpa. While in the latter case, a 477 DNS server can adhere to its traditional behavior in locating 478 resource records, the syntactical viability of encoding additional 479 parameters in this fashion is very dubious, especially if more than 480 one additional parameter is required and the presence of parameters 481 is optional. The former EDNS0 case requires significant changes to 482 name server behavior. The intended applicability of the EDNS0 483 mechanism, as the [RFC2761] states, is to "a particular transport 484 level message and not to any actual DNS data," and consequently the 485 OPT Resource Records it specifies are never to be forwarded; the use 486 of EDNS0 for compound queries, however, clearly is intended to 487 discriminate actual DNS data rather than to facilitate transport- 488 layer handling. [RFC2761] also specifies that only one OPT pseudo- 489 Resource Record can appear in a single request, so the use of this 490 mechanism can only compound a query by a single field. For these 491 reasons, this draft recommends against the use of eDNS0 as a 492 mechanism for crafting compound DNS queries. 494 Moreover, the implications of these sorts of compound queries for 495 recursion and caching are potentially serious. The logic used by the 496 authoritative server to respond to a compound query may not be 497 understood by any recursive servers or caches; intermediaries that 498 naively assume that the response was selected based on the domain 499 name, type and class alone might serve responses to queries in a 500 different way than the authoritative server intends. Even 501 comparatively unambiguous expressions of server preference like the 502 time-to-live parameter are not always honored by caches. 504 3.1.1. Responses Tailored to the Originator 506 The most important subcase of the compound queries are DNS responses 507 tailored to the identity of their originator, where some sort of 508 administrative identity of the originator must be conveyed to the 509 DNS. We must first distinguish this from cases where the originating 510 IP address or a similar indication is used to serve a location- 511 specific name. For those sorts of applications, which generally lack 512 security implications, relying on factors like the source IP address 513 introduces little harm for example, when providing a web portal 514 customized to the region of the client, it would not be a security 515 breech if the client saw the localized portal of the wrong country. 516 Because recursive resolvers may obscure the origination network of 517 the DNS client, a recent proposal suggested introducing a new DNS 518 query parameter to be populated by DNS recursive resolvers in order 519 to preserve the originating IP address (see 520 [I-D.vandergaast-edns-client-ip]). However, aside from purely 521 cosmetic uses, these approaches have known limitations due to the 522 prevalence of private IP addresses, VPNs and so on which obscure the 523 source IP address and instead supply the IP address of an 524 intermediary that may be very distant from the originating endpoint. 525 Implementing vandergaast does require significant changes in the 526 operation of recursive resolvers and the authoritative servers that 527 would rely on the original source IP address to select Resource 528 Records, and moreover a fundamental change to caching behavior as 529 well. 531 In other deployments in use today, including those based on the BIND 532 "views" feature, the source IP address is used to grant access to a 533 private set of resource records. The security implications of 534 trusting the source IP address of a DNS query have prevented most 535 solutions along these lines from being standardized (see [RFC6269]), 536 though the practice remains widespread in "split horizon" private DNS 537 deployment (see Section 4) which typically rely on an underlying 538 security layer, such as a physical network or an IPsec VPN, to 539 prevent spoofing of the source IP address. These deployments do have 540 a confidentiality requirement to prevent information intended for a 541 constrained audience (internal to an enterprise, for example) from 542 leaking to the public Internet -- while these internal network 543 resources may use private IP addresses which would not be useful on 544 the public Internet anyway, in some cases this leakage would reveal 545 topology or other information that the name server provisioner hopes 546 to keep private. 548 These first two cases, regardless of their acceptance by the 549 standards community, have widespread acceptance in the field. Some 550 applications, however, go even further and propose extending the DNS 551 to add an application-layer identifier of the originator rather than 552 an IP address; for example, 553 [I-D.kaplan-dnsext-enum-sip-source-ref-opt-code] provides a SIP URI 554 in an eDNS0 parameter (though without any specific provision for 555 cryptographically verifying the claimed identity). Effectively, the 556 conveyance of application-layer information about the administrative 557 identity of the originator through the DNS is a weak authentication 558 mechanism, on the basis of which the DNS server makes an 559 authorization decision before sharing resource records. This can 560 parlay into a per-Resource Record confidentiality mechanism, where 561 only a specific set of originators are permitted to see resource 562 records, or a case where a query for the same name by different 563 entities results in completely different resource record sets. The 564 DNS, however, substantially lacks the protocol semantics to manage 565 access control lists for data, and again, caching and recursion 566 introduce significant challenges for applications that attempt to 567 offload this responsibility to the DNS. Achieving feature parity 568 with even the simplest authentication mechanisms available at the 569 application layer would like require significant rearchitecture of 570 the DNS. 572 3.2. Using DNS as a Generic Database 574 As previously noted, the use of the First Well Known Rule of DDDS 575 combined with data URLs (or potentially TXT records) effectively 576 allows the DNS to answer queries for arbitrary strings and to return 577 arbitrary data as a value. Some query-response applications, 578 however, require queries and responses that simply fall outside the 579 syntactic capabilities of the DNS. Domain names themselves must 580 conform to certain syntactic constraints: they must consist of labels 581 that do not exceed 63 characters while the total length of the 582 encoded name may not exceed 255 octets, they must obey fairly strict 583 encoding rules, and so on. The DNS therefore cannot be a completely 584 generic database. Similar concerns apply to the size of DNS 585 responses. 587 3.2.1. Large Data in the DNS 589 While the data URL specification [RFC2397] notes that it is "only 590 useful for short values," unfortunately it gives no particular 591 guidance about what "short" might mean. Many applications today use 592 quite large data URLs (containing a megabyte or more of data) as 593 workarounds in environments where only URIs can syntactically appear. 594 The meaning of "short" in an application context is probably very 595 different from how we should understand it in a DNS message. 596 Referring to a typical public DNS deployment, [RFC5507] observes that 597 "there's a strong incentive to keep DNS messages short enough to fit 598 in a UDP datagram, preferably a UDP datagram short enough not to 599 require IP fragmentation," which entails a maximum size of 512 600 octets. While the use of TCP and eDNS0 allows DNS responses to be 601 quite long, this requires stateful operation of servers which can be 602 costly in deployments where servers have only fleeting connections to 603 many clients. Ultimately, there are forms of data that an 604 application might store in the DNS that exceed reasonable limits: in 605 the ENUM context, for example, something like storing base 64 encoded 606 mp3 files of custom ringtones. 608 Designs relying on storage of large amounts of data within DNS RRs 609 furthermore need to minimize the potential damage achievable in a 610 reflection attack (see [RFC4732], Section 3), in which the attacker 611 sends DNS queries with a forged source address, and the victim 612 receives the response. By generating a large response to a small 613 query, the attacker can magnify the bandwidth directed at the victim. 614 Where the responder supports EDNS0, an attacker may set the requester 615 maximum payload size to a larger value while querying for a large 616 Resource Record, such as a certificate [RFC4398]. Thus the 617 combination of large data stored in DNS RRs and responders supporting 618 large payload sizes has the potential to increase the potential 619 damage achievable in a reflection attack. Since a reflection attack 620 can be launched from any network that does not implement source 621 address validation, these attacks are difficult to eliminate absent 622 the ubiquitous deployment of source address validation. Since 623 reflection attacks are most damaging when launched from high 624 bandwidth networks, the implementation of source address validation 625 on these networks is particularly important. 627 The bandwidth that can be mustered in a reflection attack directed by 628 a botnet controlling broadband hosts is sobering. For example, if a 629 responder could be directed to generate a 10KB response in reply to a 630 50 octet query, then magnification of 200:1 would be attainable. 631 This would enable a botnet controlling 10000 hosts with 1 Mbps of 632 bandwidth to focus 2000 Gbps of traffic on the victim, more than 633 sufficient to congest any site on the Internet. 635 Since it is difficult to complete a TCP three-way handshake begun 636 from a forged source address, DNS reflection attacks utilize UDP 637 queries. Unless the attacker uses EDNS0 [RFC2671] to enlarge the 638 requester's maximum payload size, a response can only reach 576 639 octets before the truncate bit is set in the response. This limits 640 the maximum magnification achievable from a DNS query that does not 641 utilize EDNS0. As the large disparity between the size of a query 642 and size of the response creates this amplification, implementations 643 should limit EDNS0 responses to a specific ratio compared to the 644 request size. The precise ratio can be configured on a per- 645 deployment basis, but without this limitation, EDNS0 can cause 646 significant harm. 648 3.3. Administrative Structures Misaligned with the DNS 650 While the DDDS framework enables any sort of alphanumeric data to 651 serve as a DNS name through the application of the First Well Known 652 Rule, the delegative structure of the resulting DNS name may not 653 reflect the division of responsibilities for the resources that the 654 alphanumeric data indicates. While [RFC3402] requires only that 655 "Application Unique String has some kind of regular, lexical 656 structure that the rules can be applied to," DDDS is first and 657 foremost a delegation system: its abstract stipulates that "Well- 658 formed transformation rules will reflect the delegation of management 659 of information associated with the string." Telephone numbers in the 660 United States, for example, are assigned and delegated in a 661 relatively complex manner. Historically, the first six digits of a 662 nationally specific number (called the "NPA/NXX") reflected a point 663 of administrative delegation from the number assignment agency to a 664 carrier; from these blocks of ten thousand numbers, the carrier would 665 in turn delegate individual assignments of the last four digits (the 666 "XXXX" portion) to particular customers. However, after the rise of 667 North American telephone number portability in the 1990s, the first 668 point of delegation went away: the delegation is effectively from the 669 number authority to the carrier for each the complete ten-digit 670 number (NPA/NXX-XXXX). While technical implementation details differ 671 from nation to nation, number portability systems with similar 672 administrative delegations now exist worldwide. 674 To render these identifiers as domain names in accordance with the 675 DDDS Rule for ENUM yields a large flat zone with no points of 676 administrative delegation (or zone cuts) from the country-code 677 administrator, e.g. 1.e164.arpa, down to the ultimately assignee of a 678 number. The scalability difficulties of maintaining a single DNS 679 zone with potentially over five billion names in it manifest in a 680 number of areas (in practice, there are closer to 300M allocated 681 telephone numbers in the United States today, but that is still more 682 than three times the number of .com domain names). The scalability 683 that results from caching depends on points of delegation so that 684 cached results for intermediate servers take the load off higher tier 685 servers. If there are no such delegations, then as in the telephone 686 number example the zone apex server must bear the entire load for 687 queries. Worse still, number portability also introduces far more 688 dynamism in number assignment, where in some regions updated 689 assignees for ported numbers must propagate within fifteen minutes of 690 a change in administration. Jointly, these two problems cacheing the 691 zone extremely problematic. Moreover, traditional tools for DNS 692 replication, such as the zone transfer protocol AXFR [RFC1034] and 693 IXFR [RFC1995], are not designed to accommodate zones with these 694 dimensions and properties. When traditional DNS management tools no 695 longer apply to the structures that an application tries to provision 696 in the DNS, this is another clue that the DNS might not be the right 697 place for an application to store its data. 699 DDDS provides a capability that transforms arbitrary strings into 700 domain names, but those names play well with the DNS only when the 701 input string have an administrative structure that maps on DNS 702 delegations. In the first place, delegation implies some sort of 703 hierarchical structure. Any mechanism to map a hierarchical 704 identifier into a DNS name should be constructed such that the 705 resulting DNS name does match the natural hierarchy of the original 706 identifier. Although telephone numbers, even in North America, have 707 some hierarchical qualities (like the geographical areas 708 corresponding to their first three digits), after the implementation 709 of number portability these points no longer mapped onto an 710 administrative delegation. If the input string to the DDDS does not 711 have a hierarchical structure representing administrative delegations 712 that can map onto the DNS distribution system, that string probably 713 is not a good candidate for translating into a domain name. 715 The difficulty of mapping the DNS to administrative structures can 716 even occur with traditional domain names, where applications expect 717 clients to infer or locate zone cuts. In the web context, for 718 example, it can be difficult for applications to determine whether 719 two domain names represent the same "site" when 721 3.3.1. Metadata about Tree Structure 723 There are also other ways in which the delegative structure of an 724 identifier may not map well onto the DNS. Traditionally, DNS 725 resolvers assume that when they receive a domain name from an 726 application, that the name is complete - that it is not a fragment of 727 a DNS name that a user is still in the middle of typing. For some 728 communications systems, however, this assumption does not apply. 729 ENUM use cases have surfaced a couple of optimization requirements to 730 reduce unnecessary calls and queries by including metadata in the DNS 731 that describes the contents and structure of ENUM DNS trees to help 732 applications to handle incomplete queries or queries for domains not 733 in use. In particular, the "send-n" proposal 734 [I-D.bellis-enum-send-n] hopes to reduce the number of DNS queries 735 sent in regions with variable-length numbering plans. When a dialed 736 number potentially has a variable length, a telephone switch 737 ordinarily cannot anticipate when a dialed number is complete, as 738 only the numbering plan administrator (who may be a national 739 regulator, or even in open number plans a private branch exchange) 740 knows how long a telephone number needs to be. Consequently, a 741 switch trying to resolve such a number through a system like ENUM 742 might send a query for a telephone number that has only partially 743 been dialed in order to test its completeness. The "send-n" proposal 744 installs in the DNS a hint informing the telephone switch of the 745 minimum number of digits that must be collected by placing in zones 746 corresponding to incomplete telephone numbers some Resource Records 747 which state how many more digits are required - effectively how many 748 steps down the DNS tree one must take before querying the DNS again. 749 Unsurprisingly, those boundaries reflect points of administrative 750 delegation, where the parent in a number plan yields authority to a 751 child. With this information, the application is not required to 752 query the DNS every time a new digit is dialed, but can wait to 753 collect sufficient digits to receive a response. As an optimization, 754 this practice thus saves the resources of the DNS server - though the 755 call cannot complete until all digits are collected, so at best this 756 mechanism only reduces the time the system will wait before sending 757 an ENUM query after collecting the final dialed digit. A 758 tangentially related proposal, [I-D.ietf-enum-unused], similarly 759 places resource records in the DNS that tell the application that it 760 need not attempt to reach a number on the telephone network, as the 761 number is unassigned - a comparable general DNS mechanism would 762 identify, for a domain name with no heather or not the domain had 763 been allocated to an owner. 765 Both proposals optimize application behavior by placing metadata in 766 the DNS that predicts the success of future queries or application 767 invocation by identifying points of administrative delegation or 768 assignment in the tree. In some respects, marking a point in the 769 tree where a zone begins or end has some features in common with the 770 traditional parent zone use of the NS record type, except instead of 771 pointing to a child zone, these metadata proposals point to distant 772 grandchildren. While this does not change resolver behavior as such 773 (instead, it changes the way that applications invoke the resolver), 774 it does have implications for the practices for zone administrators. 775 Metadata in the authoritative server remain synchronized with the 776 state of the resources it predicts. Maintaining that 777 synchronization, however, requires that the DNS have semi-real time 778 updates that may conflict with scale and caching mechanisms. 780 It may also raise questions about the authority and delegation model. 781 Who gets to supply records for unassigned names? While in the 782 original but little-used "golden" root model of ENUM, this would 783 almost certainly be a numbering plan administrator, it is far less 784 clear who that would be in the more common and successful 785 "infrastructure" ENUM models (see Section 4). Ultimately, these 786 metadata proposals share some qualities with DNS redirection services 787 offered by ISPs (for example, [I-D.livingood-dns-redirect]) which 788 "help" web users who try to browser to sites that do not exist - 789 though in those cases, at least the existence or non-existence of a 790 domain name is a fact about the Internet, rather than about an 791 external network like the telephone system which must be synchronized 792 with the DNS tree in the metadata proposals. In send-n, different 793 leaf zones, who administer telephone numbers of different lengths, 794 can only provision their hints at their own apex, which provides an 795 imperfect optimization: they cannot install it in a parent, both 796 because they lack the authority and because different zones would 797 want to provision contradictory data. An application protocol 798 designer who wants to manage identifiers whose administrative model 799 does not map well onto the DNS would be better served to implement 800 such features outside the DNS. 802 3.4. Domain Redirection 804 Most Internet application services provide a redirection feature - 805 when you attempt to contact a service, the service may refer you to a 806 different service instance, potentially in another domain, that is 807 for whatever reason better suited to address a request. In HTTP and 808 SIP, for example, this feature is implemented by the 300 class 809 responses containing one or more better URIs that may indicate that a 810 resource has moved temporarily or permanently to another service. 811 Several tools in the DNS, including the SRV record, can provide a 812 similar feature at a DNS level, and consequently some applications as 813 an optimization offload the responsibility for redirection to the 814 DNS; NAPTR can also provide this capability on a per-application 815 basis, and numerous DNS resource records can provide redirection on a 816 per-domain basis. This can prevent the unnecessary expenditure of 817 application resources on a function that could be performed as a 818 component of a DNS lookup that is already a prerequisite for 819 contacting the service. Consequently, in some deployment 820 architectures this DNS-layer redirection is used for virtual hosting 821 services. 823 Implementing domain redirection in the DNS, however, has important 824 consequences for application security. In the absence of universal 825 DNSSEC, applications must blindly trust that their request has not 826 been hijacked at the DNS layer and redirected to a potentially 827 malicious domain, unless some subsequent application mechanism can 828 provide the necessary assurance. By way of contrast, application- 829 layer redirections protocols like HTTP and SIP have widely deployed 830 security mechanisms such as TLS that can use certificates to vouch 831 that a 300 response came from the domain that the originator 832 initially hoped to contact. 834 A number of applications have attempted to provide an after-the-fact 835 security mechanism that verifies the authority of a DNS delegation in 836 the absence of DNSSEC. The specification for dereferencing SIP URIs 837 ([RFC3263], reaffirmed in [RFC5922]), requires that during TLS 838 establishment, the site eventually reached by a SIP request present a 839 certificate corresponding to the original URI expected by the user 840 (in other words, if example.com redirects to example.net in the DNS, 841 this mechanism expects that example.net will supply a certificate for 842 example.com in TLS, per the HTTP precedent in [RFC2818]), which 843 requires a virtual hosting service to possess a certificate 844 corresponding to the hosted domain. This restriction rules out many 845 styles of hosting deployments common in the web world today, however. 846 [I-D.barnes-hard-problem] explores this problem space, and 847 [I-D.saintandre-tls-server-id-check] proposes a solution for all 848 applications that use TLS. Potentially, new types of certificates 849 (similar to [RFC4985]) might bridge this gap, but support for those 850 certificates would require changes to existing certificate authority 851 practices as well as application behavior. 853 All of these application-layer measures attempt to mirror the 854 delegation of authority in the DNS, when the DNS itself serves as the 855 ultimate authority on how domains are delegated. Synchronizing a 856 static instrument like a certificate with a delegation in the DNS, 857 however, is problematic because delegations are not static: revoking 858 and reissuing a certificate every time a delegation changes is 859 cumbersome operationally. In environments where DNSSEC is not 860 available, the problems with securing DNS-layer redirections would be 861 avoided by performing redirections in the application-layer. 863 4. Private DNS and Split Horizon 865 The classic view of the uniqueness of DNS names is given in 866 [RFC2826]: 868 DNS names are designed to be globally unique, that is, for any 869 one DNS name at any one time there must be a single set of DNS 870 records uniquely describing protocol addresses, network resources and 871 services associated with that DNS name. All of the applications 872 deployed on the Internet which use the DNS assume this, and Internet 873 users expect such behavior from DNS names. 875 However, [RFC2826] "does not preclude private networks from operating 876 their own private name spaces," but notes that if private networks 877 "wish to make use of names uniquely defined for the global Internet, 878 they have to fetch that information from the global DNS naming 879 hierarchy." There are various DNS deployments outside of the global 880 public DNS, including "split horizon" deployments and DNS usages on 881 private (or virtual private) networks. In a split horizon, an 882 authoritative server gives different responses to queries from the 883 public Internet than they do to internal resolvers; as they typically 884 differentiate internal from public queries by the source IP address, 885 the concerns in Section 3.1.1 apply to such deployments. When the 886 internal address space range is private [RFC1918], this both makes it 887 easier for the server to discriminate public from private and harder 888 for public entities to impersonate nodes in the internal network. 889 Networks that are made private physically, or logically by 890 cryptographic tunnels, make these private deployments more secure. 891 The most complex deployments along these lines use multiple virtual 892 private networks to serve different answers for the same name to many 893 networks. 895 The use cases that motivate split horizon DNS typically involve 896 restricting access to some network services - intranet resources like 897 internal web site, development servers or directories, for example - 898 while preserving the ease of use offered by domain names for internal 899 users. While for many of these resources, the split horizon would 900 not return answers to public resolvers for those internal resources 901 (those records are kept confidential from the public), in some cases, 902 the same name (e.g., "mail.example.com") might resolve to one host 903 internally but another externally. The requirements for multiple-VPN 904 private deployments, however, are different: in this case the 905 authoritative server gives different, and confidential, answers to a 906 set of resolvers querying for the same name. While these sorts of 907 use cases rarely arise for traditional domain names, where, as 908 [RFC2826] says, users and applications expect a unique resolution for 909 a name, they can easily arise when other sorts of identifiers have 910 been translated by a mechanism like DDDS into "domain name syntax." 911 Telephone calls, for example, are traditionally routed through highly 912 mediated networks, and an attempt to find a route for a call often 913 requires finding an appropriate intermediary based on the source 914 network and location rather than finding an endpoint (see the 915 distinction between the Look-Up Function and Location Routing 916 Function in [RFC5486]). Moreover, the need for selective responses 917 and confidentially is easily motivated when the data returned by the 918 DNS is no longer "describing protocol addresses, network resources 919 and services," but instead arbitrary data. Although ENUM was 920 originally intended for deployment in the global public root of the 921 DNS (under e164.arpa), for example, the requirements of maintaining 922 telephone identifiers in the DNS quickly steered operators into 923 private deployments. 925 In private environments, it is also easier to deploy any necessary 926 extensions than it is in the public DNS: in the first place, 927 proprietary non-standard extensions and parameters can easily be 928 integrated into DNS queries or responses as the implementations of 929 resolvers and servers can likely be controlled; secondly, 930 confidentiality and custom responses can be provided by deploying, 931 respectively, underlying physical or virtual private networks to 932 shield the private tree from public queries, and effectively 933 different virtual DNS trees for each administrative entity that might 934 launch a query; thirdly, in these constrained environments, caching 935 and recursive resolvers can be managed or eliminated in order to 936 prevent any unexpected intermediary behavior. While these private 937 deployments serve an important role in the marketplace, there are 938 risks in using techniques intended only for deployment in private and 939 constrained environments as the basis of a standard solution. When 940 proprietary parameters or extensions are deployed in these private 941 environments, experience teaches us that these implementations will 942 begin to interact with the public DNS, and that the private practices 943 will leak. The history of SIP, for example, was full of supposedly 944 private extensions (notably the "P-" headers) which saw widespread 945 success and use outside of the constrained environments for which 946 they were specifically designed. Therefore, keeping these features 947 within higher-layer applications rather than offloading them to the 948 DNS is preferred. 950 5. Principles and Guidance 952 The success of the DNS relies on the fact that it is a distributed 953 database, one that has the property that it is loosely coherent and 954 that it offers lookup instead of search functionality. Loose 955 coherency means that answers to queries are coherent within the 956 bounds of data replication between authoritative servers and caching 957 behavior by recursive name servers. It is critical that application 958 designers who intend to use the DNS to support their applications 959 consider the implications that their uses have for the behavior of 960 resolvers, intermediaries including caches and recursive resolvers, 961 and authoritative servers. 963 It is likely that the DNS provides a good match whenever applications 964 needs are aligned with the following properties: 966 Data stored in the DNS can be propagated and cached using 967 conventional DNS mechanisms, without intermediaries needing to 968 understand exceptional logic (considerations beyond the name, type 969 and class of the query) used by the authoritative server to 970 formulate responses 972 Data stored in the DNS is indexed by keys that do not violate the 973 syntax or semantics of domain names 975 Applications invoke the DNS to resolve complete names, not 976 fragments 978 Answers do not depend on an application-layer identity of the 979 entity doing the query 981 Ultimately, applications invoke the DNS to assist in communicating 982 with the domain of the name they are resolving 984 Whenever one of the four properties above does not apply to one's 985 data, one should seriously consider whether the DNS is the best place 986 to store actual data. On the other hand, good indicators that the 987 DNS is not the appropriate tool for solving problems is when you have 988 to worry about: 990 Populating metadata about domain boundaries within the tree - the 991 points of administrative delegation in the DNS are something that 992 applications should in general not be aware off 994 Domain names derived from identifiers that do not share a 995 semantics or administrative model compatible with the DNS 996 Selective confidentiality of data stored in and provided by the 997 DNS 999 DNS responses not fitting into UDP packets, unless EDNS0 is 1000 available, and only then with the caveats discussed above 1002 In cases where applications require these sorts of features, they are 1003 simply better instantiated by independent application-layer protocols 1004 than the DNS. The query-response semantics of the DNS are similar to 1005 HTTP, for example, and the objects which HTTP can carry both in 1006 queries and responses can easily contain the necessary structure to 1007 manage compound queries. Many applications already use HTTP because 1008 of widespread support for it in middleboxes. Similarly, HTTP has 1009 numerous ways to provide the necessary authentication, authorization 1010 and confidentiality properties that some features require, as well as 1011 the redirection properties discussed in Section 3.4. The overhead of 1012 using HTTP may not be appropriate for all environments, but even in 1013 environments where a more lightweight protocol is appropriate, DNS is 1014 not the only alternative. 1016 Where the administrative delegations of the DNS form a necessary 1017 component in the instantiation of an application feature, there are 1018 various ways that the DNS can bootstrap access to an independent 1019 application-layer protocol better suited to field the queries in 1020 question. For example, since NAPTR or URI resource 1021 [I-D.faltstrom-uri] records can contain URIs, those URIs can in turn 1022 point to an external query-response service such as HTTP where more 1023 syntactically and semantically rich queries and answers might be 1024 exchanged. 1026 6. Security Considerations 1028 Many of the concerns about how applications use the DNS discussed in 1029 this document involve security. The perceived need to authenticate 1030 the source of DNS queries (see Section 3.1.1) and authorize access to 1031 particular resource records also illustrates the fundamental security 1032 principles that arise from offloading certain application features to 1033 the DNS. As Section 3.2.1 observes, large data in the DNS can 1034 provide a means of generating reflection attacks, and without the 1035 remedies discussed in that section (especially the use of EDNS0 and 1036 TCP) the presence of large records is not recommended. Section 3.4 1037 discusses a security problem concerning redirection that has surfaced 1038 in a number of protocols (see [I-D.barnes-hard-problem]). 1040 While DNSSEC, were it deployed universally, can play an important 1041 part in securing application redirection in the DNS, DNSSEC does not 1042 provide a means for a resolver to authenticate itself to a server, 1043 nor a framework for servers to return selective answers based on the 1044 authenticated identity of resolvers. The existing feature set of 1045 DNSSEC is however sufficient for providing security for most of the 1046 ways that applications traditionally have used the DNS. Nothing in 1047 this document is intended to discourage either the implementation, 1048 deployment, or use of Secure DNS Dynamic Updates ([RFC2136], 1049 [RFC3007]) to the DNS system, DNS Security ([RFC4033] and related 1050 specifications), or the use of Secure DNS Dynamic Updates in 1051 combination with DNS Security. 1053 7. IANA Considerations 1055 This document contains no considerations for the IANA. 1057 8. IAB Members 1059 Internet Architecture Board Members at the time this document was 1060 published were: 1062 [TO BE INSERTED] 1064 9. Acknowledgements 1066 The IAB appreciates the comments and often spirited disagreements of 1067 Ed Lewis, Dave Crocker, Ray Bellis, Lawrence Conroy, Ran Atkinson, 1068 Patrik Faltstrom and Eliot Lear. 1070 10. Informative References 1072 [I-D.barnes-hard-problem] 1073 Barnes, R. and P. Saint-Andre, "High Assurance Re- 1074 Direction (HARD) Problem Statement", 1075 draft-barnes-hard-problem-00 (work in progress), 1076 July 2010. 1078 [I-D.bellis-enum-send-n] 1079 Bellis, R., "IANA Registrations for the 'Send-N' 1080 Enumservice", draft-bellis-enum-send-n-02 (work in 1081 progress), June 2008. 1083 [I-D.faltstrom-uri] 1084 Faltstrom, P. and O. Kolkman, "The Uniform Resource 1085 Identifier (URI) DNS Resource Record", 1086 draft-faltstrom-uri-06 (work in progress), October 2010. 1088 [I-D.ietf-enum-unused] 1089 Stastny, R., Conroy, L., and J. Reid, "IANA Registration 1090 for Enumservice UNUSED", draft-ietf-enum-unused-04 (work 1091 in progress), March 2008. 1093 [I-D.kaplan-dnsext-enum-sip-source-ref-opt-code] 1094 Kaplan, H., Walter, R., Gorman, P., and M. Maharishi, 1095 "EDNS Option Code for SIP and PSTN Source Reference Info", 1096 draft-kaplan-dnsext-enum-sip-source-ref-opt-code-03 (work 1097 in progress), October 2011. 1099 [I-D.livingood-dns-redirect] 1100 Creighton, T., Griffiths, C., Livingood, J., and R. Weber, 1101 "DNS Redirect Use by Service Providers", 1102 draft-livingood-dns-redirect-03 (work in progress), 1103 October 2010. 1105 [I-D.saintandre-tls-server-id-check] 1106 Saint-Andre, P. and J. Hodges, "Representation and 1107 Verification of Domain-Based Application Service Identity 1108 in Certificates Used with Transport Layer Security", 1109 draft-saintandre-tls-server-id-check-09 (work in 1110 progress), August 2010. 1112 [I-D.vandergaast-edns-client-ip] 1113 Contavalli, C., Gaast, W., Leach, S., and D. Rodden, 1114 "Client IP information in DNS requests", 1115 draft-vandergaast-edns-client-ip-01 (work in progress), 1116 May 2010. 1118 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 1119 RFC 882, November 1983. 1121 [RFC0974] Partridge, C., "Mail routing and the domain system", 1122 RFC 974, January 1986. 1124 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1125 STD 13, RFC 1034, November 1987. 1127 [RFC1035] Mockapetris, P., "Domain names - implementation and 1128 specification", STD 13, RFC 1035, November 1987. 1130 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 1131 Arbitrary String Attributes", RFC 1464, May 1993. 1133 [RFC1530] Malamud, C. and M. Rose, "Principles of Operation for the 1134 TPC.INT Subdomain: General Principles and Policy", 1135 RFC 1530, October 1993. 1137 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 1138 April 1995. 1140 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1141 E. Lear, "Address Allocation for Private Internets", 1142 BCP 5, RFC 1918, February 1996. 1144 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1145 August 1996. 1147 [RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the 1148 location of services (DNS SRV)", RFC 2052, October 1996. 1150 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 1151 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1152 RFC 2136, April 1997. 1154 [RFC2168] Daniel, R. and M. Mealling, "Resolution of Uniform 1155 Resource Identifiers using the Domain Name System", 1156 RFC 2168, June 1997. 1158 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 1159 August 1998. 1161 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 1162 RFC 2671, August 1999. 1164 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1166 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 1167 Unique DNS Root", RFC 2826, May 2000. 1169 [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer 1170 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 1172 [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, 1173 September 2000. 1175 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1176 Update", RFC 3007, November 2000. 1178 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1179 A., Peterson, J., Sparks, R., Handley, M., and E. 1180 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1181 June 2002. 1183 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1184 Protocol (SIP): Locating SIP Servers", RFC 3263, 1185 June 2002. 1187 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1188 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 1190 [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1191 Part Two: The Algorithm", RFC 3402, October 2002. 1193 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1194 Part Three: The Domain Name System (DNS) Database", 1195 RFC 3403, October 2002. 1197 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1198 Resource Identifier (URI): Generic Syntax", STD 66, 1199 RFC 3986, January 2005. 1201 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1202 Rose, "DNS Security Introduction and Requirements", 1203 RFC 4033, March 2005. 1205 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1206 and T. Wright, "Transport Layer Security (TLS) 1207 Extensions", RFC 4366, April 2006. 1209 [RFC4367] Rosenberg, J. and IAB, "What's in a Name: False 1210 Assumptions about DNS Names", RFC 4367, February 2006. 1212 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 1213 Service Considerations", RFC 4732, December 2006. 1215 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 1216 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 1217 Signatures", RFC 4871, May 2007. 1219 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 1220 Subject Alternative Name for Expression of Service Name", 1221 RFC 4985, August 2007. 1223 [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia 1224 Interconnect (SPEERMINT) Terminology", RFC 5486, 1225 March 2009. 1227 [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design 1228 Choices When Expanding the DNS", RFC 5507, April 2009. 1230 [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 1231 Certificates in the Session Initiation Protocol (SIP)", 1232 RFC 5922, June 2010. 1234 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 1235 Roberts, "Issues with IP Address Sharing", RFC 6269, 1236 June 2011. 1238 Authors' Addresses 1240 Olaf Kolkman 1241 NLNet 1243 Email: olaf@nlnetlabs.nl 1245 Jon Peterson 1246 NeuStar, Inc. 1248 Email: jon.peterson@neustar.biz 1250 Hannes Tschofenig 1251 Nokia Siemens Networks 1253 Email: Hannes.Tschofenig@gmx.net 1255 Bernard Aboba 1256 Microsoft Corporation 1258 Email: bernarda@microsoft.com