idnits 2.17.1 draft-iab-dns-applications-07.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. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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 (February 26, 2013) is 4078 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3596' is mentioned on line 308, but not defined == Missing Reference: 'RFC2761' is mentioned on line 524, but not defined == Missing Reference: 'RFC4398' is mentioned on line 672, but not defined == Missing Reference: 'I-D.livingood-dns-direct' is mentioned on line 888, but not defined == Unused Reference: 'RFC3007' is defined on line 1323, but no explicit reference was found in the text == Unused Reference: 'RFC4366' is defined on line 1353, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-faltstrom-uri-06 -- 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 2845 (Obsoleted by RFC 8945) -- 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 6125 (Obsoleted by RFC 9525) Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft NeuStar, Inc. 4 Intended status: Informational O. Kolkman 5 Expires: August 30, 2013 NLnet Labs 6 H. Tschofenig 7 Nokia Siemens Networks 8 B. Aboba 9 Microsoft Corporation 10 February 26, 2013 12 Architectural Considerations on Application Features in the DNS 13 draft-iab-dns-applications-07 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; some for example transform identifiers 20 other than domain names into formats that the DNS can process, and 21 then fetch application data or service location data from the DNS. 22 Proposals incorporating sophisticated application behavior using DNS 23 as a substrate have raised questions about the role of the DNS as an 24 application platform. This document explores the architectural 25 consequences of using the DNS to implement certain application 26 features, and provides guidance to future application designers as to 27 the limitations of the DNS as a substrate and the situations in which 28 alternative designs should be considered. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 30, 2013. 47 Copyright Notice 48 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . 8 79 2.3. Arbitrary Data in the DNS . . . . . . . . . . . . . . . . 9 80 3. Challenges for the DNS . . . . . . . . . . . . . . . . . . . . 12 81 3.1. Compound Queries . . . . . . . . . . . . . . . . . . . . . 12 82 3.1.1. Responses Tailored to the Originator . . . . . . . . . 14 83 3.2. Using DNS as a Generic Database . . . . . . . . . . . . . 16 84 3.2.1. Large Data in the DNS . . . . . . . . . . . . . . . . 16 85 3.3. Administrative Structures Misaligned with the DNS . . . . 18 86 3.3.1. Metadata about Tree Structure . . . . . . . . . . . . 19 87 3.4. Domain Redirection . . . . . . . . . . . . . . . . . . . . 21 88 4. Private DNS and Split Horizon . . . . . . . . . . . . . . . . 24 89 5. Principles and Guidance . . . . . . . . . . . . . . . . . . . 27 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 92 8. IAB Members at Time of Approval . . . . . . . . . . . . . . . 31 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 94 10. Informative References . . . . . . . . . . . . . . . . . . . . 33 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 97 1. Motivation 99 The Domain Name System (DNS) has long provided a general means of 100 translating domain names into Internet Protocol addresses, which 101 makes the Internet easier to use by providing a valuable layer of 102 indirection between names and lower-layer protocol elements. 103 [RFC0974] documented a further use of the DNS: to manage application 104 services operating in a domain with the Mail Exchange (MX) resource 105 record, which helped email addressed to the domain to find a mail 106 service for the domain sanctioned by the zone administrator. 108 The seminal MX record served as a prototype for other DNS resource 109 records that supported applications associated with a domain name. 110 The SRV resource record [RFC2052] provided a more general mechanism 111 for locating services in a domain, complete with a weighting system 112 and selection among transports. The Naming Authority Pointer (NAPTR, 113 originally [RFC2168]) resource record, especially as it evolved into 114 the more general Dynamic Delegation Discovery System (DDDS, 115 [RFC3401]) framework, added a generic mechanism for storing 116 application data in the DNS. Primarily, this involved a client-side 117 algorithm for transforming a string into a domain name, which might 118 then be 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 examples of this are 121 telephone numbers, as resolved by the DDDS application ENUM. Recent 122 work such as Domain Keys Identified Mail (DKIM, [RFC6376]) has 123 enabled security features of applications to be advertised through 124 the DNS, via the TXT resource record. 126 The scope of application usage of the DNS has thus increased over 127 time. Applications in many environments require features such as 128 confidentiality, and as the contexts in which applications rely on 129 the DNS have increased, some application protocols have looked to 130 extend the DNS to include these sorts of capabilities. However, some 131 proposed usages of, and extensions to, the DNS have become misaligned 132 with both the DNS architecture and the DNS protocol. Taking the 133 example of confidentiality: In the global public DNS, the resolution 134 of domain names to IP addresses is public information with no 135 expectation of confidentiality, and thus the underlying query/ 136 response protocol has no encryption mechanism - typically, any 137 security required by an application or service is invoked after the 138 DNS query, when the resolved service has been contacted. Only in 139 private DNS environments (including split horizon DNS) where the 140 identity of the querier is assured through some external policy can 141 the DNS maintain confidential records, by providing distinct answers 142 to the private and public users of the DNS. In support of load 143 balancing or other optimizations, a DNS server may return different 144 addresses in response to queries from different sources, or even no 145 response at all, which is discussed further in Section 3.1.1. 147 This document provides guidance to application designers, and 148 application protocol designers, looking to use the DNS to support 149 features in their applications. It provides an overview of past 150 application usage of the DNS, as well as reviewing proposed new 151 usages. It identifies concerns and trade-offs and provides guidance 152 on the question, "Should I store this information in the DNS, or use 153 some other means?" when that question arises during protocol 154 development. These guidelines remind application protocol designers 155 of the strengths and weaknesses of the DNS in order to make it easier 156 for designers to decide what features the DNS should provide for 157 their application. 159 The guidance in this document complements the guidance on extending 160 the DNS given in [RFC5507]. Whereas [RFC5507] considers the 161 preferred ways to add new information to the underlying syntax of the 162 DNS (such as defining new resource records or adding prefixes or 163 suffixes to labels), the current document considers broader 164 implications of applications that rely on the DNS for the 165 implementation of certain features, be it through extending the DNS 166 or simply reusing existing protocol capabilities - implications that 167 may concern the invocation of the resolver by applications, the 168 behavior of name servers, resolvers or caches, extensions to the 169 underlying DNS protocol, the operational responsibilities of zone 170 administrators, security, or the overall architecture of names. When 171 existing DNS protocol fields are used in ways that their designers 172 did not intend to handle new applications, those applications may 173 demand further changes and extensions that are fundamentally at odds 174 with the strengths of the DNS. 176 2. Overview of DNS Application Usages 178 [RFC0882] identifies the original and fundamental connection between 179 the DNS and applications. It begins by describing how the 180 interdomain scope of applications creates "formidable problems when 181 we wish to create consistent methods for referencing particular 182 resources that are similar but scattered throughout the environment." 183 This motivated transitioning the "mapping between host names... and 184 ARPA Internet addresses" from a global table (the original "hosts" 185 file) to a "distributed database that performs the same function." 186 [RFC0882] also envisioned some ways to find the resources associated 187 with mailboxes in a domain: without these extensions, a user trying 188 to send mail to a foreign domain lacked a discovery mechanism to 189 locate the right host in the remote domain to which to connect. 191 While a special-purpose service discovery mechanism could be built 192 for each such application protocol that needed this functionality, 193 the universal support for the DNS encourages installing these 194 features into its public tree rather than inventing something new. 195 Thus, over time, several other applications leveraged DNS resource 196 records for locating services in a domain or for storing application 197 data associated with a domain in the DNS. This section gives 198 examples of various types of DNS usage by applications to date. 200 2.1. Locating Services in a Domain 202 The MX resource record provides the simplest example of an 203 application advertising its domain-level resources in the Domain Name 204 System. The MX resource record contains the domain name of a server 205 that receives mail on behalf of the administrative domain in 206 question; that domain name must itself be resolved to one or more IP 207 addresses through the DNS in order to reach the mail server. While 208 naming conventions for applications might serve a similar purpose (a 209 host might be named "mail.example.com" for example), approaching 210 service location through the creation of a new resource record yields 211 important benefits. For example, one can put multiple MX records 212 under the same name, in order to designate backup resources or to 213 load balance across several such servers (see [RFC1794]); these 214 properties could not easily be captured by naming conventions (see 215 [RFC4367], though more recently, DNS-SD 216 ([I-D.cheshire-dnsext-dns-sd]) codifies service instance naming 217 conventions for use across applications to locate services in a 218 domain). 220 While the MX record represents a substantial improvement over naming 221 conventions as a means of service location, it remains specific to a 222 single application. Thus, the general approach of the MX record was 223 adapted to fit a broader class of applications through the Service 224 (SRV) resource record (originally [RFC2052]). The SRV record allows 225 DNS resolvers to query for particular services and underlying 226 transports (for example, HTTP running over TLS, see [RFC2818]) and to 227 learn a host name and port where that service resides in a given 228 domain. It also provides a weighting mechanism to allow load 229 balancing across several instances of a service. 231 The reliance of applications on the existence of MX and SRV records 232 has important implications for the way that applications manage 233 identifiers, and the way that applications pass domain names to 234 resolvers. Email identifiers of the form "user@domain" rely on MX 235 records to provide the convenience of simply specifying a "domain" 236 component rather than requiring an application to guess which 237 particular host handles mail on behalf of the domain. While for 238 applications like web browsing, naming conventions continue to abound 239 ("www.example.com"), SRV records allow applications to query for an 240 application-specific protocol and transport in the domain. For LDAP, 241 the SRV service name corresponds to the URL scheme of the identifier 242 invoked by the application (e.g., when "ldap://example.com" is the 243 identifier, the SRV query passed to the resolver is for 244 "_ldap._tcp.example.com"); for other applications, the SRV service 245 name that the application passes to the resolver may be implicit in 246 the identifier rather than explicit. In either case, the application 247 delivers the service name to the DNS to find the location of the host 248 of that service for the domain, the port where the service resides on 249 that host, additional locations or ports for load balancing and fault 250 tolerance, and related application features. 252 Locating specific services for a domain was the first major function 253 for which applications started using the DNS beyond simple name 254 resolution. SRV broadened and generalized the precedent of MX to 255 make service location available to any application, rather than just 256 to mail. As applications that acquire MX (or SRV) records might need 257 to perform further queries or transformations in order to arrive at 258 an eventual domain name that will resolve to the IP addresses for the 259 service, [RFC1034] allowed that the Additional Data section of DNS 260 responses may contain the corresponding address records for the names 261 of services designated by the MX record; this optimization, which 262 requires support in the authoritative server and the resolver, is an 263 initial example of how support for application features requires 264 changes to DNS operation. At the same time this is an example of an 265 extension of the DNS that cannot be universally relied on: Many DNS 266 resolver implementations will ignore the addresses in the additional 267 section of the DNS answers because of the trustworthiness issues 268 described in [RFC2181]. 270 2.2. NAPTR and DDDS 272 The NAPTR resource record evolved to fulfill a need in the transition 273 from Uniform Resource Locators (URLs) to the more mature URI 274 [RFC3986] framework, which incorporated Uniform Resource Names 275 (URNs). Unlike URLs, URNs typically do not convey enough semantics 276 internally to resolve them through the DNS, and consequently a 277 separate URI-transformation mechanism is required to convert these 278 types of URIs into domain names. This allows identifiers with no 279 recognizable domain component to be treated as domain names for the 280 purpose of name resolution. Once these transformations result in a 281 domain name, applications can retrieve NAPTR records under that name 282 in the DNS. NAPTR records contain a far more rich and complex 283 structure than MX or SRV resource records. A NAPTR record contains 284 two different weighting mechanisms ("order" and "preference"), a 285 "service" field to designate the application that the NAPTR record 286 describes, and then two fields that can contain translations: a 287 "replacement" or "regular expression" field, only one of which 288 appears in given NAPTR record. A "replacement," like NAPTR's 289 ancestor the PTR record, simply designates another domain name where 290 one would look for records associated with this service in the 291 domain. The "regexp," on the other hand, allows regular expression 292 transformations on the original URI intended to turn it into an 293 identifier that the DNS can resolve. 295 As the Abstract of [RFC2915] says, "This allows the DNS to be used to 296 lookup services for a wide variety of resource names (including URIs) 297 which are not in domain name syntax." Any sort of hierarchical 298 identifier can potentially be encoded as a domain name, and thus 299 historically the DNS has often been used to resolve identifiers that 300 were never devised as a name for an Internet host. A prominent early 301 example is found in the in-addr domain [RFC0882], in which IPv4 302 addresses are encoded as domain names by applying a string 303 preparation algorithm that required reversing the octets and treating 304 each individual octet as a label in a domain name - thus, for 305 example, the address 192.0.2.1 became 1.2.0.192.in-addr.arpa. This 306 allowed resolvers to query the DNS to learn name(s) associated with 307 an IPv4 address. The same mechanism has been applied to IPv6 308 addresses [RFC3596] and other sorts of identifiers that lack a domain 309 component. Eventually, this idea connected with activities to create 310 a system for resolving telephone numbers on the Internet, which 311 became known as ENUM (originally [RFC2916]). ENUM borrowed from an 312 earlier proposal, the "tpc.int" domain [RFC1530], which provided a 313 means for encoding telephone numbers as domain names by applying a 314 string preparation algorithm that required reversing the digits and 315 treating each individual digit as a label in a domain name - thus, 316 for example, the number +15714345400 became 317 0.0.4.5.4.3.4.1.7.5.1.tpc.int. In the ENUM system, in place of 318 "tpc.int" the special domain "e164.arpa" was reserved for use. 320 In the more mature form of the NAPTR standard, in the Dynamic 321 Delegation and Discovery Service (DDDS) ([RFC3401] passim) framework, 322 the initial transformation of an identifier (such as a telephone 323 number) to a domain name was called the "First Well Known Rule." The 324 capability to define a "First Well Known Rule" for each application 325 of NAPTR generalizes the address-reversing mechanism used in- 326 addr.arpa. Its flexibility has inspired a number of proposals beyond 327 ENUM to encode and resolve unorthodox identifiers in the DNS. 328 Provided that the identifiers transformed by the "First Well Known 329 Rule" have some meaningful structure and are not overly lengthy, 330 virtually anything can serve as an input for the DDDS structure: for 331 example, civic addresses. Though [RFC3402] stipulates of the 332 identifier that "the lexical structure of this string must imply a 333 unique delegation path," there is no requirement that the identifier 334 be hierarchical, nor that the points of delegation in the domain name 335 created by the "First Well Known Rule" correspond to any points of 336 administrative delegation inherent in the structure of the 337 identifier. 339 While this ability to look up names "which are not in the domain name 340 syntax" does not change the underlying DNS protocol - the names 341 generated by the DDDS algorithm are still just domain names - it does 342 change the context in which applications pass name to resolvers, and 343 can potentially require very different operational practices of zone 344 administrators (see Section 3.3). In terms of the results of a DNS 345 query, the presence of the "regexp" field of NAPTR records enabled 346 unprecedented flexibility in the types of identifiers that 347 applications could resolve with the DNS. Since the output of the 348 regular expression frequently took the form of a URI (in ENUM 349 resolution, for example, a telephone number might be converted into a 350 SIP URI [RFC3261]), anything that could be encoded as a URI might be 351 the result of resolving a NAPTR record - which, as the next section 352 explores, essentially means arbitrary data. 354 2.3. Arbitrary Data in the DNS 356 URI encoding has ways of encapsulating basically arbitrary data: the 357 most extreme example is data URL [RFC2397]. Thus, resolving a NAPTR 358 record might result in an output other than an identifier that would 359 subsequently be resolved to IP addresses and contacted for a 360 particular application - it could give a literal result which would 361 be consumed by the application. Originally, in [RFC2168], the 362 intended applicability of the regular expression field in NAPTR was 363 narrower: the regexp field contained a "substitution expression that 364 is applied to the original URI in order to construct the next domain 365 name to lookup," in order to "change the host that is contacted to 366 resolve a URI" or as a way of "changing the path or host once the URL 367 has been assigned." The regular expression tools available to NAPTR 368 record authors, however, grant much broader powers to alter the input 369 string, and thus applications began to rely on NAPTR to perform more 370 radical transformations that did not serve any of those 371 aforementioned needs. By [RFC3402], the output of DDDS is wholly 372 application-specific: "the Application must determine what the 373 expected output of the Terminal Rule should be," and the example 374 given in the document is one of identifying automobile parts by 375 inputting a part number and receiving at the end of the process 376 information about the manufacturer. 378 Historically speaking, NAPTR did not pioneer the storage of arbitrary 379 data in the DNS. At the start, [RFC0882] observed that "it is 380 unlikely that all users of domain names will be able to agree on the 381 set of resources or resource information that names will be used to 382 retrieve," and consequently places little restriction on the 383 information that DNS records might carry: it might be "host 384 addresses, mailbox data, and other as yet undetermined information." 385 [RFC1035] defined the TXT record, a means to store arbitrary strings 386 in the DNS; [RFC1034] specifically stipulates that a TXT contains 387 "descriptive text" and that "the semantics of the text depends on the 388 domain where it is found." The existence of TXT records has long 389 provided new applications with a rapid way of storing data associated 390 with a domain name in the DNS, as adding data in this fashion 391 requires no registration process. [RFC1464] experimented with a 392 means of incorporating name/value pairs to the TXT record structure, 393 which allowed applications to differentiate different chunks of data 394 stored in a TXT record - surely not just "descriptive text" as the 395 TXT originally specified. In this fashion, an application that wants 396 to store additional data in the DNS can do so without registering a 397 new resource record type - though [RFC5507] points out that it is 398 "difficult to reliably distinguish one application's record from 399 others, and for its parser to avoid problems when it encounters other 400 TXT records." 402 While open policies surrounding the use of the TXT record have 403 resulted in a checkered past for standardizing application usage of 404 TXT, TXT has been used as a technical solution for many applications, 405 most recently for DKIM [RFC6376] to store necessary information about 406 the security of email in DNS, though within a narrow naming 407 convention (records stored under "_domainkey" subdomains). Storing 408 keys in the DNS became the preferred solution for DKIM for several 409 reasons: notably, because email applications already queried the DNS 410 in their ordinary operations, because the public keys associated with 411 email required wide public distribution, and because email 412 identifiers contain a domain component that applications can easily 413 use to consult the DNS. If the application had to negotiate support 414 for the DKIM mechanism with mail servers, it would give rise to bid- 415 down attacks (where attackers misrepresent that DKIM is unsupported 416 in the domain) that are not possible if the DNS delivers the keys 417 (provided that DNSSEC [RFC4033] guarantees authenticity of the data). 418 However, there are potential issues with storing large data in the 419 DNS, as discussed in Section 3.2.1 as well as with the DKIM namespace 420 conventions that prevent the use of DNS wildcards (as discussed in 421 section 6.1.2 of [RFC6376] and in more general terms in [RFC5507]). 422 If prefixes are used to identify TXT records used by an application, 423 potentially the use of wildcards may furthermore cause leakages that 424 other applications will need to detect. 426 3. Challenges for the DNS 428 The methods discussed in the previous section for transforming 429 arbitrary identifiers into domain names, and for returning arbitrary 430 data in response to DNS queries, both represent significant 431 departures from the basic function of translating host names to IP 432 addresses, yet neither fundamentally alters the underlying semantics 433 of the DNS. When we consider, however, that the URIs returned by 434 DDDS might be base 64 encoded binary data in a data URL, the DNS 435 could effectively implement the entire application feature set of any 436 simple query-response protocol. Effectively, the DDDS framework 437 considers the DNS a generic database - indeed, the DDDS framework was 438 designed to work with any sort of underlying database; as [RFC3403] 439 says, the DNS is only one potential database for DDDS to use. 440 Whether the DNS as an underlying database can support the features 441 that some applications of DDDS require, however, is a more 442 complicated question. 444 As the following subsections will show, the potential for 445 applications to rely on the DNS as a generic database gives rise to 446 additional requirements that one might expect to find in a database 447 access protocol: authentication of the source of queries for 448 comparison to access control lists, formulating complex relational 449 queries, and asking questions about the structure of the database 450 itself. The global public DNS was not designed to provide these 451 sorts of properties, and extending the DNS protocols to encompass 452 them could result in a fundamental alteration to its model. 453 Ultimately, this document concludes that efforts to retrofit these 454 capabilities into the DNS would be better invested in selecting, or 455 if necessary inventing, other Internet services with broader powers 456 than the DNS. If an application protocol designer wants these 457 properties from a database, in general this is a good indication that 458 the DNS cannot, or can only partly, meet the needs of the application 459 in question. 461 Since many of these new requirements have emerged from the ENUM 462 space, the following sections use ENUM as an illustrative example; 463 however, any application using the DNS as a feature-rich database 464 could easily end up with similar requirements. 466 3.1. Compound Queries 468 Traditionally, DNS RRsets are uniquely identified by domain name, 469 resource record type, and class. DNS queries are based on this 470 3-tuple and the replies are resource record sets that are to be 471 treated as atomic data elements (see [RFC2181]); to applications, the 472 behavior of the DNS has traditionally been that of an exact-match 473 query response lookup mechanism. Outside of the DNS space, however, 474 there are plenty of query-response applications that require a 475 compound or relational search, one taking into account more than one 476 factor in formulating a response or one that uses no single factor as 477 a key to the database. For example, in the telephony space, 478 telephone call routing often takes into account numerous factors 479 aside from the dialed number, including originating trunk groups, 480 interexchange carrier selection, number portability data, time of 481 day, and so on. All are considered simultaneously in generating a 482 route. While in its original conception, ENUM hoped to circumvent 483 the traditional PSTN and route directly to Internet-enabled devices, 484 the infrastructure ENUM effort to support the migration of 485 traditional carrier routing functions to the Internet aspires to 486 achieve feature parity with traditional number routing. However, 487 [RFC3402] explicitly states that "it is an assumption of the DDDS 488 that the lexical element used to make a delegation decision is simple 489 enough to be contained within the Application Unique String itself. 490 The DDDS does not solve the case where a delegation decision is made 491 using knowledge contained outside the AUS and the Rule (time of day, 492 financial transactions, rights management, etc.)." Consequently, 493 some consideration has been given to ways to add additional data to 494 ENUM queries to give the DNS server sufficient information to return 495 a suitable URI (see Section 3.1.1). 497 From a sheer syntactical perspective, however, domain names do not 498 admit of this sort of rich structure. Several workarounds have 499 attempted to instantiate these sorts of features in DNS queries. For 500 example, the domain name itself could be compounded with the 501 additional parameters: one could take a name like 502 0.0.4.5.4.3.4.1.7.5.1.e164.arpa and append a trunk group identifier 503 to it, for example, of the form 504 tg011.0.0.4.5.4.3.4.1.7.5.1.e164.arpa. While in this particular case 505 a DNS server can adhere to its traditional behavior in locating 506 resource records, the syntactical viability of encoding additional 507 parameters in this fashion is dubious, especially if more than one 508 additional parameter is required and the presence of parameters is 509 optional so that the application needs multiple queries to assess the 510 completeness of the information it needs to perform its function. 512 As an alternative, it has been proposed that we piggyback additional 513 query parameters as EDNS0 extensions (see [RFC2671]). This might be 514 problematic for three reasons. First, supporting EDNS0 such 515 extensions requires significant changes to name server behavior that 516 need to be supported by the authoritative and recursive nameservers 517 on which the application relies and might be very hard to realize on 518 a global scale. In addition, the intended applicability of the EDNS0 519 mechanism, as [RFC2761] states, is to "a particular transport level 520 message and not to any actual DNS data," and consequently the OPT 521 Resource Records it specifies are never to be forwarded; the use of 522 EDNS0 for compound queries, however, clearly is intended to 523 discriminate actual DNS data rather than to facilitate transport- 524 layer handling. Finally, [RFC2761] also specifies that OPT Resource 525 Records are never cached (see the next paragraph). For these 526 reasons, this memo recommends against crafting compound DNS queries 527 by using EDNS0. 529 The implications of these sorts of compound queries for recursion and 530 caching are potentially serious. The logic used by the authoritative 531 server to respond to a compound query may not be understood by any 532 recursive servers or caches; intermediaries that naively assume that 533 the response was selected based on the domain name, type and class 534 alone might serve responses to queries in a different way than the 535 authoritative server intends. Therefore, were EDNS0 to be employed 536 this way, its attributes would not be transitive, and if this were 537 not considered where intermediaries are employed, as is normally the 538 case in the global DNS, brokenness might occur. 540 3.1.1. Responses Tailored to the Originator 542 The most important subcase of these compound queries are DNS 543 responses tailored to the identity of their originator, where some 544 sort of administrative identity of the originator must be conveyed to 545 the DNS. We must first distinguish this from cases where the 546 originating IP address or a similar indication is used to serve a 547 location-specific name. For those sorts of applications, which 548 generally lack security implications, relying on factors like the 549 source IP address introduces little harm; for example, when providing 550 a web portal customized to the region of the client, it would not be 551 a security breach if the client saw the localized portal of the wrong 552 country. Because recursive resolvers may obscure the origination 553 network of the DNS client, a recent proposal suggested introducing a 554 new DNS query parameter to be populated by DNS recursive resolvers in 555 order to preserve the originating IP address (see 556 [I-D.vandergaast-edns-client-ip]). However, aside from purely 557 cosmetic uses, these approaches have known limitations due to the 558 prevalence of private IP addresses, VPNs and so on which obscure the 559 source IP address and instead supply the IP address of an 560 intermediary that may be very distant from the originating endpoint. 561 Implementing technology such as the one described by 562 [I-D.vandergaast-edns-client-ip] would require significant changes in 563 the operation of recursive resolvers and the authoritative servers 564 that would rely on the original source IP address to select Resource 565 Records, and moreover a fundamental change to caching behavior as 566 well. As a result such technology cannot be rolled out in an 567 incremental, unilateral fashion, but could only be successful when 568 implemented bilaterally (by authoritative server and recursive 569 resolver), a significant bar to deployment. 571 In other deployments in use today, including those based on the BIND 572 "views" feature, the source IP address is used to grant access to a 573 selected, and potentially sensitive, set of resource records. The 574 security implications of trusting the source IP address of a DNS 575 query have prevented most solutions along these lines from being 576 standardized (see [RFC6269]), though the practice remains widespread 577 in "split horizon" private DNS deployment (see Section 4) which 578 typically rely on an underlying security layer, such as a physical 579 network, a clear perimeter demarcation at a network perimeter point 580 (with network layer anti-spoofing countermeasures) or an IPsec VPN, 581 to prevent spoofing of the source IP address. These deployments do 582 have a confidentiality requirement to prevent information intended 583 for a constrained audience (internal to an enterprise, for example) 584 from leaking to the public Internet -- while these internal network 585 resources may use private IP addresses which should not be useful on 586 the public Internet anyway, in some cases this leakage would reveal 587 topology or other information that the name server administrator 588 hopes to keep private. More recently, TSIG [RFC2845] has been 589 employed as a way of selecting among "views" in BIND; this provides a 590 stronger level of security than merely relying on the source IP 591 address, but typically many users share the same secret to access a 592 given view, and moreover TSIG does not provide confidentiality 593 properties to DNS messages - without network-layer separation between 594 users of different views, eavesdroppers might capture the DNS queries 595 and responses. 597 The use of source IP addresses as a discriminator to select DNS 598 resource records, regardless of its lack of acceptance by the 599 standards community, has widespread acceptance in the field. Some 600 applications, however, go even further and propose extending the DNS 601 to add an application-layer identifier of the originator; for 602 example, [I-D.kaplan-dnsext-enum-sip-source-ref-opt-code] provides a 603 SIP URI in an EDNS0 parameter. Effectively, this conveyance of 604 application-layer information about the administrative identity of 605 the originator through the DNS is a weak authentication mechanism, on 606 the basis of which the DNS server makes an authorization decision 607 before sharing resource records. This can approximate a per-Resource 608 Record confidentiality mechanism, where only a specific set of 609 originators are permitted to see resource records, or a case where a 610 query for the same name by different entities results in completely 611 different resource record sets. However, without any underlying 612 cryptographic security, this mechanism must rely on external layers 613 for security (such as VPNs) rather than any direct assurance. Again, 614 caching, forwarding, and recursion introduce significant challenges 615 for applications that attempt to offload this responsibility to the 616 DNS. Achieving feature parity with even the simplest authentication 617 mechanisms available at the application layer would likely require 618 significant rearchitecture of the DNS. 620 3.2. Using DNS as a Generic Database 622 As previously noted, applications can use a method like the "First 623 Well Known Rule" of DDDS to transform an arbitrary string into a 624 domain name, and then receive from the DNS arbitrary data stored in 625 TXT RRs, in the "regexp" of NAPTRs or even in custom records. Some 626 query-response applications, however, require queries and responses 627 that simply fall outside the syntactic capabilities of the DNS. For 628 example, domain names themselves must consist of labels that do not 629 exceed 63 octets while the total length of the encoded name may not 630 exceed 255 octets, and applications that use label characters outside 631 the traditional ASCII set may run into problems (though see the 632 discussion in [RFC6055] Section 3 for definitive guidance on the use 633 of non-ASCII in the DNS). The DNS therefore cannot be a completely 634 generic database. Similar concerns apply to the size of DNS 635 responses. 637 3.2.1. Large Data in the DNS 639 While the data URL specification [RFC2397] notes that it is "only 640 useful for short values," unfortunately it gives no particular 641 guidance about what "short" might mean. Some applications today use 642 quite large data URLs (containing a megabyte or more of data) as 643 workarounds in environments where only URIs can syntactically appear 644 (for example, in Apple iOS, to pass objects between applications). 645 The meaning of "short" in an application context is probably very 646 different from how we should understand it in a DNS message. 647 Referring to a typical public DNS deployment, [RFC5507] observes that 648 "there's a strong incentive to keep DNS messages short enough to fit 649 in a UDP datagram, preferably a UDP datagram short enough not to 650 require IP fragmentation". And while EDNS0 allows for mechanisms to 651 negotiate DNS message sizes larger than the traditional 512 octets, 652 there is a high risk that a long payload will cause UDP 653 fragmentation, in particular when the DNS message already carries 654 DNSSEC information. If EDNS0 is not available, or the negotiated 655 EDNS0 packet size is too small to fit the data, or UDP fragments are 656 dropped, the DNS may (eventually) resort to using TCP. While TCP 657 allows DNS responses to be quite long, this requires stateful 658 operation of servers which can be costly in deployments where servers 659 have only fleeting connections to many clients. Ultimately, there 660 are forms of data that an application might store in the DNS that 661 exceed reasonable limits: in the ENUM context, for example, something 662 like storing base-64-encoded mp3 files of custom ringtones. 664 Designs relying on storage of large amounts of data within DNS RRs 665 furthermore need to minimize the potential damage achievable in a 666 reflection attack (see [RFC4732], Section 3), in which the attacker 667 sends UDP only DNS queries with a forged source address, and the 668 victim receives the response. The attacker relies on amplification, 669 where a small query generates a large response directed at the 670 victim. Where the responder supports EDNS0, an attacker may set the 671 requester maximum payload size to a larger value while querying for a 672 large Resource Record, such as a certificate [RFC4398]. Thus the 673 combination of large data stored in DNS RRs and responders supporting 674 large payload sizes has the potential to increase the potential 675 damage achievable in a reflection attack. 677 Since a reflection attack can be launched from any network that does 678 not implement source address validation, these attacks are difficult 679 to eliminate absent the ubiquitous deployment of source address 680 validation or "heavier" transport protocols such as TCP. The 681 bandwidth that can be mustered in a reflective amplification attack 682 directed by a botnet reflecting off a recursive nameserver on a high 683 bandwidth network is sobering. For example, if the responding 684 resolver could be directed to generate a 10KB response in reply to a 685 50 octet query, then magnification of 200:1 would be attainable. 686 This would enable a botnet controlling 10000 hosts with 1 Mbps of 687 bandwidth to focus 200 Gbps of traffic on the victim, more than 688 sufficient to congest any site on today's Internet. 690 DNS reflection attacks typically utilize UDP queries; it is 691 prohibitively difficult to complete a TCP three-way handshake begun 692 from a forged source address for DNS reflection attacks. Unless the 693 attacker uses EDNS0 [RFC2671] to enlarge the requester's maximum 694 payload size, a response can only reach 576 octets before the 695 truncate bit is set in the response. This limits the maximum 696 magnification achievable from a DNS query that does not utilize 697 EDNS0. As the large disparity between the size of a query and size 698 of the response creates this amplification, techniques for mitigating 699 this disparity should be further studied, though this is beyond the 700 scope of this memo (for an analysis of the effects of limiting EDNS0 701 responses while still accommodating DNSSEC, see [Lindsay]). For 702 example, some implementations could limit EDNS0 responses to a 703 specific ratio compared to the request size, where the precise ratio 704 can be configured on a per-deployment basis (taking into account 705 DNSSEC response sizes). Without some means of mitigating the 706 potential for amplification, EDNS0 could cause significant harm. 708 In summary, there are two operational forces that tend to drive the 709 practically available EDNS0 sizes down: possible UDP fragmentation 710 and minimizing amplification in case of reflection attacks. DNSSEC 711 data will use a significant fraction of the available space in a DNS 712 packet. Therefore -- appreciating that given the current DNSSEC and 713 EDNS0 deployment experience, precise numbers are impossible to give 714 -- the generic payload available to other DNS data, given the premise 715 that TCP fallback is to be minimized, is likely to be closer to 716 several hundred octets than a few thousand octets. 718 3.3. Administrative Structures Misaligned with the DNS 720 While the DDDS framework enables any sort of alphanumeric data to 721 serve as a domain name through the application of the "First Well 722 Known Rule," the delegative structure of the resulting domain name 723 may not reflect any administrative division of responsibilities 724 inherent in the original data. While [RFC3402] requires only that 725 the "Application Unique String has some kind of regular, lexical 726 structure that the rules can be applied to," DDDS is first and 727 foremost a delegation system: its abstract stipulates that "Well- 728 formed transformation rules will reflect the delegation of management 729 of information associated with the string." Telephone numbers in the 730 United States, for example, are assigned and delegated in a 731 relatively complex manner. Historically, the first six digits of a 732 nationally specific number (called the "NPA/NXX") reflected a point 733 of administrative delegation from the number assignment agency to a 734 carrier; from these blocks of ten thousand numbers, the carrier would 735 in turn delegate individual assignments of the last four digits (the 736 "XXXX" portion) to particular customers. However, after the rise of 737 North American telephone number portability in the 1990s, the first 738 point of delegation went away: the delegation is effectively from the 739 number authority to the carrier for each complete ten-digit number 740 (NPA/NXX-XXXX). While technical implementation details differ from 741 nation to nation, number portability systems with similar 742 administrative delegations now exist worldwide. 744 To render these identifiers as domain names in accordance with the 745 DDDS Rule for ENUM yields a large flat administrative domain with no 746 points of administrative delegation from the country-code 747 administrator, e.g. 1.e164.arpa, down to the ultimate assignee of a 748 number. Under the assumption that one administrative domain is 749 maintained within one DNS zone containing potentially over five 750 billion names, scalability difficulties manifest in a number of 751 areas: The scalability that results from caching depends on these 752 points of delegation, so that cached results for intermediate servers 753 take the load off higher tier servers. If there are no such 754 delegations, then as in the telephone number example the zone apex 755 server must bear the entire load for queries. Worse still, number 756 portability also introduces far more dynamism in number assignment, 757 where in some regions updated assignees for ported numbers must 758 propagate within fifteen minutes of a change in administration. 759 Jointly, these two problems make caching the zone extremely 760 problematic. Moreover, traditional tools for DNS replication, such 761 as the zone transfer protocol AXFR [RFC1034] and IXFR [RFC1995], 762 might not scale to accommodate zones with these dimensions and 763 properties. 765 In practice, the maximum sizes of telephone number administrative 766 domains are closer to 300M (the current amount of allocated telephone 767 numbers in the United States today - still more than three times the 768 number of .com domain names) and one can alleviate some of the 769 scalability issues mentioned above by artificially dividing the 770 administrative domain into a hierarchy of DNS zones. Still, the fact 771 that traditional DNS management tools no longer apply to the 772 structures that an application tries to provision in the DNS, is a 773 clue that the DNS might not be the right place for an application to 774 store its data. 776 While DDDS is the most obvious example of these concerns, the point 777 is more generic: for example, were address portability to be 778 implemented for IP addresses, and their administration thus to become 779 non-hierarchical, the same concerns would apply to in-addr.arpa 780 names. The difficulty of mapping the DNS to administrative 781 structures can even occur with traditional domain names, where 782 applications expect clients to infer or locate zone cuts. In the web 783 context, for example, it can be difficult for applications to 784 determine whether two domains represent the same "site" when 785 comparing security credentials with URLs (see Section 3.4 below for 786 more on this). This has also caused known problems in determining 787 the scope of web cookies, in contexts where applications must infer 788 where administrative domains end in order to grant cookies that are 789 as narrowly-scoped as possible. 791 In summary, the "First Well Known Rule" of DDDS provides a capability 792 that transforms arbitrary strings into domain names, but those names 793 play well with the DNS only when the input strings have an 794 administrative structure that maps to DNS delegations. In the first 795 place, delegation implies some sort of hierarchical structure. Any 796 mechanism to map a hierarchical identifier into a domain name should 797 be constructed such that the resulting domain name does match the 798 natural hierarchy of the original identifier. Although telephone 799 numbers, even in North America, have some hierarchical qualities 800 (like the geographical areas corresponding to their first three 801 digits), after the implementation of number portability these points 802 no longer mapped onto an administrative delegation. If the input 803 string to the DDDS does not have a hierarchical structure 804 representing administrative delegations that can map onto the DNS 805 distribution system, then that string probably is not a good 806 candidate for translating into a domain name. 808 3.3.1. Metadata about Tree Structure 810 There are also other ways in which the delegative structure of an 811 identifier may not map well onto the DNS. Traditionally, DNS 812 resolvers assume that when they receive a domain name from an 813 application, that the name is complete - that it is not a fragment of 814 a domain name that a user is still in the middle of typing. For some 815 communications systems, however, this assumption does not apply. 816 ENUM use cases have surfaced a couple of optimization requirements to 817 reduce unnecessary calls and queries; proposed solutions include 818 metadata in the DNS that describes the contents and structure of ENUM 819 DNS trees to help applications handle incomplete queries or queries 820 for domains not in use. 822 In particular, the "send-n" proposal [I-D.bellis-enum-send-n] hoped 823 to reduce the number of DNS queries sent in regions with variable- 824 length numbering plans. When a dialed number potentially has a 825 variable length, a telephone switch ordinarily cannot anticipate when 826 a dialed number is complete, as only the numbering plan administrator 827 (who may be a national regulator, or even in open number plans a 828 private branch exchange) knows how long a telephone number needs to 829 be. Consequently, a switch trying to resolve such a number through a 830 system like ENUM might send a query for a telephone number that has 831 only partially been dialed in order to test its completeness. The 832 "send-n" proposal installs in the DNS a hint informing the telephone 833 switch of the minimum number of digits that must be collected by 834 placing in zones corresponding to incomplete telephone numbers some 835 Resource Records which state how many more digits are required - 836 effectively how many steps down the DNS tree one must take before 837 querying the DNS again. Unsurprisingly, those boundaries reflect 838 points of administrative delegation, where the parent in a number 839 plan yields authority to a child. With this information, the 840 application is not required to query the DNS every time a new digit 841 is dialed, but can wait to collect sufficient digits to receive a 842 response. As an optimization, this practice thus saves the resources 843 of the DNS server - though the call cannot complete until all digits 844 are collected, so this mechanism simply reduces the time the system 845 will wait before sending an ENUM query after collecting the final 846 dialed digit. A tangentially related proposal, 847 [I-D.ietf-enum-unused], similarly places resource records in the DNS 848 that tell the application that it need not attempt to reach a number 849 on the telephone network, as the number is unassigned - a comparable 850 general DNS mechanism would identify, for a domain name with no 851 records available in the DNS, whether or not the domain had been 852 allocated by a registry to a registrant (which is a different 853 condition than a name merely being unresolvable, per the semantics of 854 NXDOMAIN). 856 Both proposals optimize application behavior by placing metadata in 857 the DNS that predicts the success of future queries or application 858 invocation by identifying points of administrative delegation or 859 assignment in the tree. In some respects, marking a point in the 860 tree where a zone begins or end has some features in common with the 861 traditional parent zone use of the NS record type, except instead of 862 pointing to a child zone, these metadata proposals point to distant 863 grandchildren. While this does not change resolver behavior as such 864 (instead, it changes the way that applications invoke the resolver), 865 it does have implications for the practices for zone administrators. 866 Metadata in one administrative domain would need to remain 867 synchronized with the state of the resources it predicts in another 868 administrative domain in the DNS namespace, in a case like overlap 869 dialing where the carrier delegates to a zone controlled by an 870 enterprise. When dealing with external resources associated with 871 other namespaces, like number assignments in the PSTN or the 872 databases of a registry operator, other synchronization requirements 873 arise; maintaining that synchronization requires that the DNS have 874 semi-real time updates that may conflict with scale and caching 875 mechanisms of the DNS. 877 It may also raise questions about the authority and delegation model. 878 Who gets to supply records for unassigned names? While in the 879 original but little-used e164.arpa root of ENUM, this would almost 880 certainly be a numbering plan administrator, it is far less clear who 881 that would be in the more common and successful "infrastructure" ENUM 882 models (see Section 4). Ultimately, these metadata proposals share 883 some qualities with DNS redirection services offered by ISPs (for 884 example, [I-D.livingood-dns-redirect]) which "help" web users who try 885 to browse to sites that do not exist - as proposals like [I-D.ietf- 886 enum-used] also create DNS records for unallocated zones that 887 redirect to a service provider's web page - though in the 888 [I-D.livingood-dns-direct] cases, at least the existence or non- 889 existence of a domain name is a fact about the Internet namespace, 890 rather than about an external namespace like the telephony E.164 891 namespace which must be synchronized with the DNS tree in the 892 metadata proposals. In send-n, different leaf zones, who administer 893 telephone numbers of different lengths, can only provision their 894 hints at their own apex, which provides an imperfect optimization: 895 they cannot install it themselves in a parent, both because they lack 896 the authority and because different zones would want to provision 897 contradictory data. The later the hint appears in the tree, however, 898 the less optimization will result. An application protocol designer 899 managing identifiers whose administrative model does not map well 900 onto the DNS namespace and delegations structure would be better 901 served to implement such features outside the DNS. 903 3.4. Domain Redirection 905 Most Internet application services provide a redirection feature - 906 when you attempt to contact a service, the service may refer you to a 907 different service instance, potentially in another domain, that is 908 for whatever reason better suited to service a request. In HTTP and 909 SIP, for example, this feature is implemented by the 300 class 910 responses containing one or more URIs, which may indicate that a 911 resource has moved temporarily or permanently to another service. 912 Several tools in the DNS, including the SRV record, can provide a 913 similar feature at a DNS level, and consequently some applications as 914 an optimization offload the responsibility for redirection to the 915 DNS; NAPTR can also provide this capability on a per-application 916 basis, and numerous DNS resource records can provide redirection on a 917 per-domain basis. This can prevent the unnecessary expenditure of 918 application resources on a function that could be performed as a 919 component of a DNS lookup that is already a prerequisite for 920 contacting the service. Consequently, in some deployment 921 architectures this DNS-layer redirection is used for virtual hosting 922 services. 924 Implementing domain redirection in the DNS, however, has important 925 consequences for application security. In the absence of universal 926 DNSSEC, applications must blindly trust that their request has not 927 been hijacked at the DNS layer and redirected to a potentially 928 malicious domain, unless some subsequent application mechanism can 929 provide the necessary assurance. By way of contrast, application- 930 layer protocols supporting redirection such as HTTP and SIP have 931 available security mechanisms, including as TLS, that can use 932 certificates to attest that a 300 response came from the domain that 933 the originator initially hoped to contact. 935 A number of applications have attempted to provide an after-the-fact 936 security mechanism that verifies the authority of a DNS delegation in 937 the absence of DNSSEC. The specification for dereferencing SIP URIs 938 ([RFC3263], reaffirmed in [RFC5922]), requires that during TLS 939 establishment, the site eventually reached by a SIP request present a 940 certificate corresponding to the original URI expected by the user 941 (in other words, if example.com redirects to example.net in the DNS, 942 this mechanism expects that example.net will supply a certificate for 943 example.com in TLS, per the HTTP precedent in [RFC2818]), which 944 requires a virtual hosting service to possess a certificate 945 corresponding to the hosted domain. This restriction rules out many 946 styles of hosting deployments common in the web world today, however. 947 [I-D.barnes-hard-problem] explores this problem space. [RFC6125] 948 proposes a solution for all applications that use TLS which relies on 949 new application-specific identifiers in certificates, as does 950 [RFC4985]), though note that support for such certificates would 951 require changes to existing certificate authority practices as well 952 as application behavior. With DNSSEC in place, DANE ([RFC6394]) 953 offers another way to bind certificates to particular applications 954 and services. 956 All of these application-layer measures attempt to mirror the 957 delegation of administrative authority in the DNS, when the DNS 958 itself serves as the ultimate authority on how domains are delegated 959 (Note: changing the technical delegation structure by changing NS 960 records in the DNS is not the same as administrative delegation e.g. 961 when a domain changes ownership). Synchronizing a static instrument 962 like a certificate with a delegation in the DNS, however, is 963 problematic because delegations are not static: revoking and 964 reissuing a certificate every time an administrative delegation 965 changes is cumbersome operationally. In environments where DNSSEC is 966 not available, the problems with securing DNS-layer redirections 967 would be avoided by performing redirections in the application-layer. 968 Necessarily, this gives rise to various design trade-offs involving 969 performance, load and related factors, but in these application 970 environments, the security properties typically take priority. 972 4. Private DNS and Split Horizon 974 The classic view of the uniqueness of domain names in the DNS is 975 given in [RFC2826]: 977 "DNS names are designed to be globally unique, that is, for any 978 one DNS name at any one time there must be a single set of DNS 979 records uniquely describing protocol addresses, network resources and 980 services associated with that DNS name. All of the applications 981 deployed on the Internet which use the DNS assume this, and Internet 982 users expect such behavior from DNS names." 984 [RFC2826] "does not preclude private networks from operating their 985 own private name spaces," but notes that if private networks "wish to 986 make use of names uniquely defined for the global Internet, they have 987 to fetch that information from the global DNS naming hierarchy." 988 There are various DNS deployments outside of the global public DNS, 989 including "split horizon" deployments and DNS usages on private (or 990 virtual private) networks. In a split horizon, an authoritative 991 server gives different responses to queries from the public Internet 992 than they do to internal resolvers; while some deployments 993 differentiate internal from public queries by the source IP address, 994 the concerns in Section 3.1.1 relating to trusting source IP 995 addresses apply to such deployments. When the internal address space 996 range is private [RFC1918], this both makes it easier for the server 997 to discriminate public from private and harder for public entities to 998 impersonate nodes in the private network. Networks that are made 999 private physically, or logically by cryptographic tunnels, make these 1000 private deployments more secure. The most complex deployments along 1001 these lines use multiple virtual private networks to serve different 1002 answers for the same name to many distinct networks. 1004 The use cases that motivate split horizon DNS typically involve 1005 restricting access to some network services - intranet resources such 1006 as internal web sites, development servers or directories, for 1007 example - while preserving the ease of use offered by domain names 1008 for internal users. While for many of these resources, the split 1009 horizon would not return answers to public resolvers for those 1010 internal resources (those records are kept confidential from the 1011 public), in some cases, the same name (e.g., "mail.example.com") 1012 might resolve to one host internally but another externally. The 1013 requirements for multiple-VPN private deployments, however, are 1014 different: in this case the authoritative server gives different, and 1015 confidential, answers to a set of resolvers querying for the same 1016 name. While these sorts of use cases rarely arise for traditional 1017 domain names, where, as [RFC2826] says, users and applications expect 1018 a unique resolution for a name, they can easily arise when other 1019 sorts of identifiers have been translated by a mechanism such as the 1020 "First Well Known Rule" of DDDS into "domain name syntax." Telephone 1021 calls, for example, are traditionally routed through highly mediated 1022 networks, in which an attempt to find a route for a call often 1023 requires finding an appropriate intermediary based on the source 1024 network and location rather than finding an endpoint (see the 1025 distinction between the Look-Up Function and Location Routing 1026 Function in [RFC5486]). Moreover, the need for responses tailored to 1027 the originator, and for confidentially, is easily motivated when the 1028 data returned by the DNS is no longer "describing protocol addresses, 1029 network resources and services," but instead arbitrary data. 1030 Although, for example, ENUM was originally intended for deployment in 1031 the global public root of the DNS (under e164.arpa), the requirements 1032 of maintaining telephone identifiers in the DNS quickly steered 1033 operators into private deployments. 1035 In private environments, it is also easier to deploy any necessary 1036 extensions than it is in the public DNS: in the first place, 1037 proprietary non-standard extensions and parameters can more easily be 1038 integrated into DNS queries or responses as the implementations of 1039 resolvers and servers can likely be controlled; secondly, 1040 confidentiality and custom responses can be provided by deploying, 1041 respectively, underlying physical or virtual private networks to 1042 shield the private tree from public queries, and effectively 1043 different virtual DNS trees for each administrative entity that might 1044 launch a query; thirdly, in these constrained environments, caching 1045 and recursive resolvers can be managed or eliminated in order to 1046 prevent any unexpected intermediary behavior. While these private 1047 deployments serve an important role in the marketplace, there are 1048 risks in using techniques intended only for deployment in private and 1049 constrained environments as the basis of a standard solution. When 1050 proprietary parameters or extensions are deployed in private 1051 environments, experience teaches us that these implementations will 1052 begin to interact with the public DNS, and that the private practices 1053 will leak. 1055 While such leakage is not a problem when using the mechanisms 1056 described in Sections 3.1, 3.2, and 3.5 (with private RR types) of 1057 [RFC5507], other extension mechanisms might cause confusion or harm 1058 if leaked. The use of a dedicated suffix (Section 3.3 [RFC5507]) in 1059 a private environment might cause confusion if leaked to the public 1060 internet, for example. 1062 That this kind of leakage of protocol elements from private 1063 deployments to public deployments does happen has been demonstrated, 1064 for example, with SIP: SIP implemented a category of supposedly 1065 private extensions ( the "P-" headers) which saw widespread success 1066 and use outside of the constrained environments for which they were 1067 specifically designed. There is no reason to think that 1068 implementations with similar "private" extensions to the DNS 1069 protocols would not similarly end up in use in public environments. 1071 5. Principles and Guidance 1073 The success of the global public DNS relies on the fact that it is a 1074 distributed database, one that has the property that it is loosely 1075 coherent and that it offers lookup instead of search functionality. 1076 Loose coherency means that answers to queries are coherent within the 1077 bounds of data replication between authoritative servers (as 1078 controlled by the administrator of the zone) and caching behavior by 1079 recursive name servers. Today, this term increasingly must also 1080 include load balancing or related features that rely on the source IP 1081 address of resolver. It is critical that application designers who 1082 intend to use the DNS to support their applications consider the 1083 implications that their uses have for the behavior of resolvers, 1084 intermediaries including caches and recursive resolvers, and 1085 authoritative servers. 1087 It is likely that the DNS provides a good match whenever applications 1088 needs are aligned with the following properties: 1090 Data stored in the DNS can be propagated and cached using 1091 conventional DNS mechanisms, without intermediaries needing to 1092 understand exceptional logic (considerations beyond the name, type 1093 and class of the query) used by the authoritative server to 1094 formulate responses 1096 Data stored in the DNS is indexed by keys that do not violate the 1097 syntax or semantics of domain names 1099 Applications invoke the DNS to resolve complete names, not 1100 fragments 1102 Answers do not depend on an application-layer identity of the 1103 entity doing the query 1105 Ultimately, applications invoke the DNS to assist in communicating 1106 with a service whose name is resolved through the DNS 1108 Whenever one of the five properties above does not apply to one's 1109 data, one should seriously consider whether the DNS is the best place 1110 to store actual data. On the other hand, good indicators that the 1111 DNS is not the appropriate tool for solving problems is when you have 1112 to worry about: 1114 Populating metadata about domain boundaries within the tree - the 1115 points of administrative delegation in the DNS are something that 1116 applications are not in general aware of 1117 Domain names derived from identifiers that do not share a semantic 1118 or administrative model compatible with the DNS 1120 Selective disclosure of data stored in and provided by the DNS 1122 DNS responses not fitting into UDP packets, unless EDNS0 is 1123 available, and only then with the caveats discussed in 1124 Section 3.2.1 1126 In cases where applications require these sorts of features, they are 1127 likely better instantiated by independent application-layer protocols 1128 than the DNS. For example, the objects which HTTP can carry both in 1129 queries and responses can easily contain the necessary structure to 1130 manage compound queries. Many applications already use HTTP because 1131 of widespread support for it in middleboxes. Similarly, HTTP has 1132 numerous ways to provide the necessary authentication, authorization 1133 and confidentiality properties that some features require, as well as 1134 the redirection properties discussed in Section 3.4. These 1135 differences highlight the fact that the DNS and HTTP protocols offer 1136 very different services and have different applicabilities; while 1137 both are query-response protocols, HTTP should not be doing the job 1138 of DNS, and DNS should not be doing the job of HTTP. Similarly, DNS 1139 should not be doing the job of DIAMETER, LDAP or other application- 1140 layer protocols. The overhead of using any application-layer 1141 protocol may not be appropriate for all environments, of course, but 1142 even in environments where a more lightweight protocol is 1143 appropriate, DNS is usually not the only alternative. 1145 Where the administrative delegations of the DNS form a necessary 1146 component in the instantiation of an application feature, there are 1147 various ways that the DNS can bootstrap access to an independent 1148 application-layer protocol better suited to field the queries in 1149 question. For example, since NAPTR or URI resource 1150 [I-D.faltstrom-uri] records can contain URIs, those URIs can in turn 1151 point to an external query-response service such as an HTTP service 1152 where more syntactically and semantically rich queries and answers 1153 might be exchanged. Any protocol designer considering where to 1154 implement features must perform their own gap analysis and determine 1155 whether or not implementing some features is worth the potential cost 1156 in increased network state, latency and so on, but implementing some 1157 features simply requires heavier structures than others. 1159 6. Security Considerations 1161 Many of the concerns about how applications use the DNS discussed in 1162 this document involve security. The perceived need to authenticate 1163 the source of DNS queries (see Section 3.1.1) and authorize access to 1164 particular resource records also illustrates the fundamental security 1165 principles that arise from offloading certain application features to 1166 the DNS. As Section 3.2.1 observes, large data in the DNS can 1167 provide a means of generating reflection attacks, and without the 1168 remedies discussed in that section (regarding the use of EDNS0 and 1169 TCP) the presence of large sets of records (e.g. ANY queries) is not 1170 recommended. Section 3.4 discusses a security problem concerning 1171 redirection that has surfaced in a number of protocols (see 1172 [I-D.barnes-hard-problem]). 1174 While DNSSEC, were it deployed universally, can play an important 1175 part in securing application redirection in the DNS, DNSSEC does not 1176 provide a means for a resolver to authenticate itself to a server, 1177 nor a framework for servers to return selective answers based on the 1178 authenticated identity of resolvers, nor a confidential mechanism. 1179 Some implementations may support authenticating users through TSIG, 1180 provided that the security association with a compliant server has 1181 been pre-established, though authentication is typically not needed 1182 for queries in the global public DNS. The existing feature set of 1183 DNSSEC is however sufficient for providing security for most of the 1184 ways that applications traditionally have used the DNS. The 1185 deployment of DNSSEC ([RFC4033] and related specifications) is 1186 heartily encouraged. Nothing in this document is intended to 1187 discourage the implementation, deployment, or use of Secure DNS 1188 Dynamic Updates ([RFC2136], though this document does recommend that 1189 large data in the DNS be treated in accordance with the guidance in 1190 Section 3.2.1. 1192 7. IANA Considerations 1194 This document contains no considerations for the IANA. 1196 8. IAB Members at Time of Approval 1198 Internet Architecture Board Members at the time this document was 1199 approved were: 1201 [TO BE INSERTED] 1203 9. Acknowledgements 1205 The IAB appreciates the comments and often spirited disagreements of 1206 Eric Osterweil, John Levine, Stephane Bortzmeyer, Ed Lewis, Dave 1207 Crocker, Ray Bellis, Lawrence Conroy, Ran Atkinson, Patrik Faltstrom 1208 and Eliot Lear. 1210 10. Informative References 1212 [I-D.barnes-hard-problem] 1213 Barnes, R. and P. Saint-Andre, "High Assurance Re- 1214 Direction (HARD) Problem Statement", 1215 draft-barnes-hard-problem-00 (work in progress), 1216 July 2010. 1218 [I-D.bellis-enum-send-n] 1219 Bellis, R., "IANA Registrations for the 'Send-N' 1220 Enumservice", draft-bellis-enum-send-n-02 (work in 1221 progress), June 2008. 1223 [I-D.cheshire-dnsext-dns-sd] 1224 Cheshire, S. and M. Krochmal, "DNS-Based Service 1225 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in 1226 progress), December 2011. 1228 [I-D.faltstrom-uri] 1229 Faltstrom, P. and O. Kolkman, "The Uniform Resource 1230 Identifier (URI) DNS Resource Record", 1231 draft-faltstrom-uri-06 (work in progress), October 2010. 1233 [I-D.ietf-enum-unused] 1234 Stastny, R., Conroy, L., and J. Reid, "IANA Registration 1235 for Enumservice UNUSED", draft-ietf-enum-unused-04 (work 1236 in progress), March 2008. 1238 [I-D.kaplan-dnsext-enum-sip-source-ref-opt-code] 1239 Kaplan, H., Walter, R., Gorman, P., and M. Maharishi, 1240 "EDNS Option Code for SIP and PSTN Source Reference Info", 1241 draft-kaplan-dnsext-enum-sip-source-ref-opt-code-03 (work 1242 in progress), October 2011. 1244 [I-D.livingood-dns-redirect] 1245 Creighton, T., Griffiths, C., Livingood, J., and R. Weber, 1246 "DNS Redirect Use by Service Providers", 1247 draft-livingood-dns-redirect-03 (work in progress), 1248 October 2010. 1250 [I-D.vandergaast-edns-client-ip] 1251 Contavalli, C., Gaast, W., Leach, S., and D. Rodden, 1252 "Client IP information in DNS requests", 1253 draft-vandergaast-edns-client-ip-01 (work in progress), 1254 May 2010. 1256 [Lindsay] Lindsay, G., "DNSSEC and DNS Amplification Attacks", 1257 April 2012. 1259 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 1260 RFC 882, November 1983. 1262 [RFC0974] Partridge, C., "Mail routing and the domain system", 1263 RFC 974, January 1986. 1265 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1266 STD 13, RFC 1034, November 1987. 1268 [RFC1035] Mockapetris, P., "Domain names - implementation and 1269 specification", STD 13, RFC 1035, November 1987. 1271 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 1272 Arbitrary String Attributes", RFC 1464, May 1993. 1274 [RFC1530] Malamud, C. and M. Rose, "Principles of Operation for the 1275 TPC.INT Subdomain: General Principles and Policy", 1276 RFC 1530, October 1993. 1278 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 1279 April 1995. 1281 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1282 E. Lear, "Address Allocation for Private Internets", 1283 BCP 5, RFC 1918, February 1996. 1285 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1286 August 1996. 1288 [RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the 1289 location of services (DNS SRV)", RFC 2052, October 1996. 1291 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 1292 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1293 RFC 2136, April 1997. 1295 [RFC2168] Daniel, R. and M. Mealling, "Resolution of Uniform 1296 Resource Identifiers using the Domain Name System", 1297 RFC 2168, June 1997. 1299 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1300 Specification", RFC 2181, July 1997. 1302 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 1303 August 1998. 1305 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 1306 RFC 2671, August 1999. 1308 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1310 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 1311 Unique DNS Root", RFC 2826, May 2000. 1313 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 1314 Wellington, "Secret Key Transaction Authentication for DNS 1315 (TSIG)", RFC 2845, May 2000. 1317 [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer 1318 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 1320 [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, 1321 September 2000. 1323 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1324 Update", RFC 3007, November 2000. 1326 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1327 A., Peterson, J., Sparks, R., Handley, M., and E. 1328 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1329 June 2002. 1331 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1332 Protocol (SIP): Locating SIP Servers", RFC 3263, 1333 June 2002. 1335 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1336 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 1338 [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1339 Part Two: The Algorithm", RFC 3402, October 2002. 1341 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1342 Part Three: The Domain Name System (DNS) Database", 1343 RFC 3403, October 2002. 1345 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1346 Resource Identifier (URI): Generic Syntax", STD 66, 1347 RFC 3986, January 2005. 1349 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1350 Rose, "DNS Security Introduction and Requirements", 1351 RFC 4033, March 2005. 1353 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1354 and T. Wright, "Transport Layer Security (TLS) 1355 Extensions", RFC 4366, April 2006. 1357 [RFC4367] Rosenberg, J. and IAB, "What's in a Name: False 1358 Assumptions about DNS Names", RFC 4367, February 2006. 1360 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 1361 Service Considerations", RFC 4732, December 2006. 1363 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 1364 Subject Alternative Name for Expression of Service Name", 1365 RFC 4985, August 2007. 1367 [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia 1368 Interconnect (SPEERMINT) Terminology", RFC 5486, 1369 March 2009. 1371 [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design 1372 Choices When Expanding the DNS", RFC 5507, April 2009. 1374 [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 1375 Certificates in the Session Initiation Protocol (SIP)", 1376 RFC 5922, June 2010. 1378 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on 1379 Encodings for Internationalized Domain Names", RFC 6055, 1380 February 2011. 1382 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1383 Verification of Domain-Based Application Service Identity 1384 within Internet Public Key Infrastructure Using X.509 1385 (PKIX) Certificates in the Context of Transport Layer 1386 Security (TLS)", RFC 6125, March 2011. 1388 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 1389 Roberts, "Issues with IP Address Sharing", RFC 6269, 1390 June 2011. 1392 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 1393 Identified Mail (DKIM) Signatures", RFC 6376, 1394 September 2011. 1396 [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based 1397 Authentication of Named Entities (DANE)", RFC 6394, 1398 October 2011. 1400 Authors' Addresses 1402 Jon Peterson 1403 NeuStar, Inc. 1405 Email: jon.peterson@neustar.biz 1407 Olaf Kolkman 1408 NLnet Labs 1410 Email: olaf@nlnetlabs.nl 1412 Hannes Tschofenig 1413 Nokia Siemens Networks 1415 Email: Hannes.Tschofenig@gmx.net 1417 Bernard Aboba 1418 Microsoft Corporation 1420 Email: bernarda@microsoft.com