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