idnits 2.17.1 draft-iab-dns-applications-01.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 : ---------------------------------------------------------------------------- No issues found here. 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 (March 14, 2011) is 4754 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4398' is mentioned on line 514, but not defined == Unused Reference: 'RFC4366' is defined on line 797, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-saintandre-tls-server-id-check-09 -- 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 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 (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Kolkman 3 Internet-Draft NLNet 4 Intended status: BCP J. Peterson 5 Expires: September 15, 2011 NeuStar, Inc. 6 H. Tschofenig 7 Nokia Siemens Networks 8 B. Aboba 9 Microsoft Corporation 10 March 14, 2011 12 Architectural Considerations on Application Features in the DNS 13 draft-iab-dns-applications-01 15 Abstract 17 While the principal purpose of the Domain Name System (DNS) is to 18 translate Internet domain names to IP addresses, over time a number 19 of Internet applications have integrated supplemental features into 20 the DNS to support their operations. Many of these features assist 21 in locating the appropriate service in a domain, or in transforming 22 intermediary identifiers into names that the DNS can process. 23 Proposals to piggyback more sophisticated application behavior on top 24 of the DNS, however, have raised questions about the propriety of 25 instantiating some features in that way, especially those with 26 security sensitivities. This document explores the architectural 27 consequences of installing application features in the DNS, and 28 provides guidance for future work in this area. 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 September 15, 2011. 47 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Overview of DNS Application Usages . . . . . . . . . . . . . . 6 77 2.1. Locating Services in a Domain . . . . . . . . . . . . . . 6 78 2.2. NAPTR and DDDS . . . . . . . . . . . . . . . . . . . . . . 7 79 2.3. Arbitrary Data in the DNS . . . . . . . . . . . . . . . . 8 80 3. Challenges for the DNS . . . . . . . . . . . . . . . . . . . . 10 81 3.1. Compound Queries . . . . . . . . . . . . . . . . . . . . . 10 82 3.1.1. Responses Tailored to the Originator . . . . . . . . . 11 83 3.2. Metadata about Tree Structure . . . . . . . . . . . . . . 12 84 3.3. Using DNS as a Generic Database . . . . . . . . . . . . . 13 85 3.3.1. Large Data in the DNS . . . . . . . . . . . . . . . . 13 86 3.4. Administrative Structures Misaligned with the DNS . . . . 14 87 3.5. Domain Redirection . . . . . . . . . . . . . . . . . . . . 14 88 4. Principles and Guidance . . . . . . . . . . . . . . . . . . . 16 89 4.1. Private DNS Deployments . . . . . . . . . . . . . . . . . 17 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 92 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 93 8. Informative References . . . . . . . . . . . . . . . . . . . . 22 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 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 made the Internet easier to use by 101 providing a valuable layer of indirection between well-known names 102 and lower layer protocol elements. [RFC0974], however, documented a 103 further use of the DNS: to manage application services operating in a 104 domain with the Mail Exchange (MX) resource record, which helped 105 email addressed to the domain to find an authoritative mail service 106 for the domain. 108 The seminal MX record served as a prototype for a long series of DNS 109 resource records that supported applications associated with a domain 110 name. The SRV resource record [RFC2052] provided a more general 111 mechanism for identifying services in a domain, complete with a 112 weighting system and selection among transports. The Naming 113 Authority Pointer (NAPTR, originally [RFC2168]) resource record, 114 especially in its reincarnation as the Dynamic Delegation Discovery 115 System (DDDS, [RFC3401]) framework, added a new wrinkle - a way of 116 casting any sort of string as a domain name, which might then be 117 "resolved" by the DNS to find NAPTR records. This enabled the 118 resolution of identifiers other than traditional domain names through 119 the DNS; the best-known example of this are telephone numbers, as 120 resolved by the DDDS application ENUM. Recent work such as 121 DomainKeys Identified Mail (DKIM, [RFC4871]) has enabled security 122 features of applications to be advertised through the DNS, via the 123 TXT resource record. 125 As the amount of application intelligence available to the DNS has 126 increased, however, some proposed extensions have become misaligned 127 with the foundational assumptions of the DNS. One such assumption is 128 that the resolution of domain names to IP addresses is public 129 information with no need for confidentiality - any security required 130 by an application or service is invoked after the DNS query, when the 131 resolved service has been contacted. Typically, the translation also 132 does not depend on the identity of the querier (although for load 133 balancing reasons or related optimizations, the DNS may return 134 different addresses in response to queries from different sources, or 135 even no response at all, which is discussed further in 136 Section 3.1.1). These assumptions permit the existence of a single 137 authoritative unique global root of the DNS (see [RFC2826], and also 138 underlie the scaling capabilities of the DNS, notably the ability of 139 intermediaries to cache responses. At the point where these 140 assumptions no longer apply to the data that an application requires, 141 one can reasonably question whether or not that application should 142 use the DNS to deliver that data. 144 Increasingly, however, the flexibility of the DDDS framework has 145 encouraged the repurposing of the DNS into a generic database. Since 146 the output of DDDS can be a Uniform Resource Indicator (URI 147 [RFC3986]), and URIs themselves are containers for basically 148 arbitrary data, one can query through the DDDS framework for an 149 arbitrary string (provided it can be formatted and contained within 150 the syntactical limits of a domain name) and receive as a response an 151 equally arbitrary chunk of data. The use of the DNS for generic 152 database lookups is especially attractive in environments that 153 already use the DDDS framework, where deployments would prefer to 154 reuse the existing query/response interface of the DNS rather than 155 installing a new and separate database capability. 157 The guidance in this document complements the guidance on extending 158 the DNS given in [RFC5507]. Whereas RFC5507 considers the preferred 159 ways to add new information to the underlying syntax of the DNS (such 160 as defining new resource records or adding prefixes or suffixes to 161 labels), the current document considers broader implications of 162 offloading application features to the DNS, be it through extending 163 the DNS or simply reusing existing protocol capabilities. It is the 164 features themselves, rather than any syntactical representation of 165 those features, that are considered here. 167 2. Overview of DNS Application Usages 169 While the original motivation for the Domain Name System was to 170 implement as an Internet service a means of masking lengthy numeric 171 addresses with strings that are easier to interpret and memorize, the 172 hierarchical system of domains rendered the DNS important for its 173 administrative properties as well as its mnemonics. Since the DNS 174 explained how to reach an administrative domain rather than simply a 175 host, it was natural to extend the DNS further to optimize for 176 reaching particular applications within a domain. Without these 177 extensions, a user trying to send mail to a foreign domain, for 178 example, lacked a discovery mechanism to locate the right host in the 179 remote domain to connect to for mail. While a special-purpose 180 discovery mechanism could be built by each such application protocol 181 that needed this functionality, the universality of the DNS invites 182 installing these features into its public tree. 184 2.1. Locating Services in a Domain 186 The MX resource record provides the simplest motivating example for 187 an application advertising its hosts in the Domain Name System. The 188 MX resource record contains the domain name of a server within the 189 administrative domain in question that receives mail; that domain 190 name must itself be resolved to an IP address through the DNS in 191 order to reach the mail server. While naming conventions for 192 applications might serve a similar purpose (a host might be named 193 "mail.example.com" for example), approaching service location through 194 the creation of a new resource record yields several important 195 benefits. Firstly, one can put multiple MX records in a zone, in 196 order to designate backup servers that can receive mail when the 197 primary server is offline. One can even load balance across several 198 such servers (see [RFC1794]. These properties could not easily be 199 captured by naming conventions (see [RFC4367]). 201 While the MX record represents a substantial improvement over naming 202 conventions as a means of service location, it remains specific to a 203 single application. Thus, the general approach of the MX record was 204 adapted to fit a broader class of application through the Service 205 (SRV) resource record (originally [RFC2052]). The SRV record allows 206 DNS resolvers to search for particular applications and underlying 207 transports (for example, HTTP running over TLS, see [RFC2818]) and to 208 learn the domain name and port where that service resides in a given 209 administrative domain. It also provides a weighting mechanism to 210 allow load balancing across several (presumably equivalent) instances 211 of a service in a domain. 213 The reliance of applications on the existence of MX and SRV records 214 has important implications for the way that applications manage 215 identifiers. Email identifiers of the form "user@domain" require the 216 presence of MX records to provide the convenience of simply 217 specifying that "domain" component rather than a "host.domain" 218 structure. While for applications like HTTP, naming conventions 219 continue to abound ("www.example.com"), the SRV algorithm queries for 220 an application-specific label combining the protocol and transport. 221 For a protocol like HTTP, the SRV label derives from the URL scheme 222 of the identifier invoked by the application. The application 223 identifier thus retained sole responsibility for carrying the desired 224 protocol and domain, but could offload to the DNS the location of the 225 host of that service within the domain, the port where the service 226 resided on that host, load balancing and fault tolerance, and related 227 application features. Ultimately, resolvers that acquire MX or SRV 228 records use them as intermediate transformations in order to arrive 229 at an eventual domain name that will resolve to the IP address of a 230 host to contact for the service. 232 [TBD: Potentially incorporate some discussion of Hammer's hostmeta or 233 the Webfingers approach as alternatives to using the DNS to identify 234 additional resources required for services] 236 2.2. NAPTR and DDDS 238 The NAPTR resource record evolved to fulfill a need in the transition 239 from Uniform Resource Locators (URLs) to the more mature URI 240 framework, which incorporated Uniform Resources Names (URNs). Unlike 241 URLs, URNs typically do not convey enough semantics internally to 242 resolve them through the DNS, and consequently a separate URI- 243 transformation mechanism is required to convert these types of URIs 244 into domain names. This allowed identifiers with no recognizable 245 domain component to treated as DNS names for the purpose of name 246 resolution. Once these transformations resulted in a domain name, 247 applications could retrieve NAPTR records from that zone in the DNS. 248 NAPTR records contain a far more rich and complex structure than MX 249 or SRV resource records. A NAPTR record contains two different 250 weighting mechanisms ("order" and "preference"), a "service" field to 251 designate the application that the NAPTR record described, and then 252 two fields that could contain translations: a "replacement" or 253 "regular expression" field, only one of which appeared in given NAPTR 254 record. A "replacement," like NAPTR's ancestor the PTR record, 255 simply designated another zone where one would look for records 256 associated with this service in the domain. The "regexp," on the 257 other hand, allowed sed-like transformations on the original URI 258 intended to transform it into an identifier that the DNS could 259 resolve. 261 The same mechanism could obviously be applied to other sorts of 262 identifiers that lacked a domain component, and thus this work 263 naturally combined with activities to create a system for resolving 264 telephone numbers on the Internet, which became known as ENUM 265 (originally [RFC2916]). ENUM borrowed from an earlier proposal, the 266 "tpc.int" domain ([RFC1530]), which provided a means for encoding 267 telephone numbers as domain names applying a string preparation 268 algorithm that required reversing the digits and treating each 269 individual digit as a zone of the DNS - thus, for example, the number 270 +15714345400 became 0.0.4.5.4.3.4.1.7.5.1.tpc.int. In the ENUM 271 system, in place of "tpc.int" the special domain "e164.arpa" was 272 reserved for use. In its more mature form in Dynamic Delegation and 273 Discovery Service (DDDS) ([RFC3401] passim) framework, this initial 274 transformation was called the "First Well Known Rule." Its 275 flexibility has inspired a number of proposals beyond ENUM to encode 276 and resolve unorthodox identifiers in the DNS. Provided that the 277 identifiers transformed by the First Well Known Rule have some 278 meaningful hierarchical structure and are not overly lengthy, 279 virtually anything can serve as an input for the DDDS structure: for 280 example, civic addresses (see draft-rosen-dns-sos). 282 The presence of the "regexp" field of NAPTR records enabled 283 unprecedented flexibility in the transformations that DNS resolution 284 could perform. Since the output of the regular expression frequently 285 took the form of a URI (in ENUM resolution, for example, a telephone 286 might be converted into a SIP URI), anything that could be encoded as 287 a URI might be the result of resolving a NAPTR record. Since URI 288 encoding has ways of carrying basically arbitrary data (see for 289 example, the base 64 encoded binary data in the data URL [RFC2397]), 290 resolving a NAPTR record might result in an output other than an 291 identifier which would subsequently be resolved to an IP address and 292 contacted for a particular application - it could give a literal 293 result consumed by the application. Thus, the DNS could effectively 294 implement the entire application feature set of any simple query- 295 response protocol. Effectively, the DDDS framework turned the DNS 296 into a generic database - indeed, the DNS serves as but one example 297 of a possible back-end for DDDS, and perhaps not the most suitable 298 one. 300 2.3. Arbitrary Data in the DNS 302 NAPTR did not pioneer the storage of arbitrary data in the DNS. 303 [RFC1464] defined the TXT record, a means to store arbitrary string 304 data in the DNS using a simple attribute name/value pair syntax. The 305 existence of TXT records has long provided new applications with a 306 rapid way of storing data associated with a domain name in the DNS, 307 as the attribute names require no registration process and can simply 308 be minted at will. Thus, an application that wants to store 309 additional data in the DNS can do so without registering a new 310 resource record type. 312 While lax policies surrounding the use of the TXT record has resulted 313 in a checkered past for standardizing application usage of TXT, it 314 has provided a technical solution for DKIM ([RFC4871]) to store 315 cryptographic keys for email in DNS. Storing keys in the DNS for 316 DKIM made sense for several reasons: notably, because the public keys 317 associated with email required wide public distribution, and because 318 email identifiers contain a domain component that applications can 319 easily use to consult the DNS. If the application had to negotiate 320 support for the DKIM mechanism with mail servers, it would give rise 321 to bid-down attacks that are not possible if the DNS delivers the 322 keys (provided that DNSSEC guarantees authenticity of zone files). 324 3. Challenges for the DNS 326 These methods for transforming arbitrary identifiers into domain 327 names, and for returning arbitrary data in response to DNS queries, 328 both represent significant extensions from the original concept of 329 the DNS, yet neither fundamentally alters the underlying model of the 330 DNS. The promise that applications might rely on the DNS as a 331 generic database, however, invariably gives rise to additional 332 requirements that one might expect to find in a database access 333 protocol: authentication of the source of queries for comparison to 334 access control lists, formulating complex relational queries, and 335 asking questions about the structure of the database itself. DNS was 336 not designed to provide these sorts of properties, and extending the 337 DNS to encompass them would represent a fundamental alteration to its 338 model. If an application desires these properties from a database, 339 in general this is a good indication that the DNS cannot meet the 340 needs of the application in question. 342 Since many of these new requirements have emerged from the ENUM 343 space, the following sections use ENUM as an illustrative example; 344 however, any application using the DNS as a feature-rich database 345 could easily end up with similar requirements. 347 3.1. Compound Queries 349 Traditionally, the DNS requires resolvers to supply no information 350 other than the domain name (along with the type and class of records 351 sought) in order to receive a reply from an authoritative server. 352 Outside of the DNS space, however, there are plenty of query-response 353 applications that require a compound or relational search, which 354 takes into account more than one factor in formulating a response or 355 uses no single factor as a key to the database. For example, in the 356 telephony space, telephone call routing often takes into account 357 numerous factors aside from the dialed number, including originating 358 trunk groups, interexchange carrier selection, number portability 359 data, time of day, and so on. All are considered simultaneously in 360 generating a route. While in its original conception, ENUM hoped to 361 circumvent the traditional PSTN and route directly to Internet- 362 enabled devices, the infrastructure ENUM effort to support the 363 migration of traditional carrier routing functions to the Internet 364 aspires to achieve feature parity with traditional number routing. 365 Consequently, some consideration has been given to ways to add 366 additional data to ENUM queries to give the DNS server sufficient 367 information to return a suitable URI. 369 Several workaround have attempted to instantiate these sorts of 370 features in the DNS. Most commonly, proposals piggyback additional 371 query parameters as eDNS0 extensions (see [RFC2671]). Alternatively, 372 the domain name itself can be compounded with the additional 373 parameters: one could take a name like 374 0.0.4.5.4.3.4.1.7.5.1.e164.arpa and append a trunk group identifier 375 to it, for example, of the form 376 tg011.0.0.4.5.4.3.4.1.7.5.1.e164.arpa. While in the latter case, a 377 DNS server can adhere to its traditional behavior in locating 378 resource records, the syntactical viability of encoding additional 379 parameters in this fashion is very dubious, especially if more than 380 one additional parameter is required and the presence of parameters 381 is optional. The former eDNS0 case requires significant changes to 382 DNS server behavior. Moreover, the implications of these sorts of 383 compound queries for recursion and caching are potentially serious. 385 3.1.1. Responses Tailored to the Originator 387 The most important subcase of the compound queries are DNS responses 388 tailored to the identity of their originator, where some sort of 389 administrative identity of the originator must be conveyed to the 390 DNS. We must first distinguish this from cases where the originating 391 IP address is used to serve a location-specific name. For those 392 sorts of applications, which general lack security implications (for 393 example, providing a web portal customized to the region of the 394 client), relying on the source IP address introduces little harm. 395 Because recurse resolvers may obscure the origination network of the 396 DNS client, a recent proposal suggested introducing a new DNS query 397 parameter to be populated by DNS recursive resolvers in order to 398 preserve the originating IP address (see 399 draft-vandergaast-edns-client-ip). However, aside from purely 400 cosmetic uses, these approaches have many known limitations due to 401 the prevalence of VPNs, onion routing systems, and so on. Some 402 transitional deployments today, however, use the source IP address is 403 often mapped to the administrative identity of the originator. The 404 security implications of trusting the source IP address of a DNS 405 query have prevented most solutions along these lines from being 406 standardized (see draft-ietf-intarea-shared-addressing-issues), 407 though the practice remains widespread in private DNS deployment (see 408 Section 4.1). Some applications go even further and propose 409 extending the DNS to add an application-layer identifier of the 410 originator rather than an IP address; for example, 411 draft-kaplan-enum-source-uri provides a SIP URI in an eDNS0 parameter 412 (though without any specific provision for cryptographically 413 verifying the claimed identity). Effectively, the conveyance of this 414 information about the administrative identity of the originator is a 415 weak authentication mechanism, on the basis of which the DNS server 416 makes an authorization decision before sharing resource records. 417 This can parlay into a selective confidentiality mechanism, where 418 only a specific set of originators are permitted to see resource 419 records, or a case where a query for the same name by different 420 entities results in completely different resource record sets. The 421 DNS, however, substantially lacks the protocol semantics to manage 422 access control list for data, and again, caching and recursion 423 introduce significant challenges for applications that attempt to 424 offload this responsibility to the DNS. Achieving feature parity 425 with even the simplest authentication mechanisms available at the 426 application layer would like require significant rearchitecture of 427 the DNS. 429 3.2. Metadata about Tree Structure 431 ENUM use cases have also surfaced a couple of optimization 432 requirements to reduce unnecessary calls and queries by including 433 metadata that describes the contents and structure of ENUM DNS trees. 434 In particular, the "send-n" proposal (draft-bellis-enum-send-n) hopes 435 to reduce the number of DNS queries sent in cases where a telephone 436 system is collecting dialed digits in a region that supports 437 "overlap" dialing, a practice which compensates for variable-length 438 numbering plans. When the dialed number potentially has a variable 439 length, a telephone switch ordinarily cannot anticipate when a dialed 440 number is complete, as only the terminating customer premise 441 equipment (typically a private branch exchange) knows how long a 442 telephone number needs to be. The "send-n" proposal offloads to the 443 DNS the responsibility for informing the telephone switch the minimum 444 number of digits that must be collected by placing in zones 445 corresponding to incomplete telephone numbers some resource records 446 which state how many more digits are required - effectively how many 447 steps down the DNS tree one must take before querying the DNS again. 448 With this information, the application is not required to query the 449 DNS every time a new digit is dialed, but can wait to collect 450 sufficient digits to receive a response. As an optimization, this 451 practice thus saves the resources of the DNS server - though it does 452 not result in faster call set-up, as the call cannot complete until 453 all digits are collected. A tangentially related proposal, 454 draft-ietf-enum-void, similarly places resource records in the DNS 455 that tell the application that it need not attempt to reach a number 456 on the PSTN, as the number is unassigned. 458 Both proposals optimize application behavior by placing metadata in 459 the DNS that predicts the success of future queries or application 460 invocations. These predictions require that the metadata remain 461 synchronized with the state of the resources it predicts. 462 Maintaining that synchronization, however, requires that the DNS have 463 semi-real time updates that may conflict with scale and caching 464 mechanisms. It may also raise questions about the authority and 465 delegation model, and whether the entities that control the zones 466 where changes occur have the authority to populate the zones where 467 synchronization must be maintained; in send-n, different leaf zones 468 might want to populate different information in a common parent. It 469 is ultimately unclear why this data is better maintained by the DNS 470 than in an unrelated application protocol, nor why applications 471 should wait until they are collecting digits to learn this 472 information. 474 3.3. Using DNS as a Generic Database 476 As previously noted, the use of the First Well Known Rule of DDDS 477 combined with data URLs effectively allows the DNS to answer queries 478 for arbitrary strings and to return arbitrary data as value. Some 479 query-response applications, however, require queries and responses 480 that simply fall outside the syntactic capabilities of the DNS. 481 Domain names themselves must conform with certain syntactic 482 constraints: they must consist of labels that do not exceed 63 483 characters while the total length of the encoded name may not exceed 484 255 octets, they must obey fairly strict encoding rules, and so on. 486 3.3.1. Large Data in the DNS 488 While the data URL specification (RFC2397) notes that it is "only 489 useful for short values," many applications today use quite large 490 data URLs as workarounds in environments where only URIs can 491 syntactically appear. While the use of TCP and eDNS0 allows DNS 492 responses to be quite long, nonetheless there are forms of data that 493 an application might store in the DNS that exceed reasonable limits: 494 in the ENUM context, for example, something like storing base 64 495 encoded mp3 files of custom ringtones. 497 Designs relying on storage of large amounts of data within DNS RRs 498 futhermore need to minimize the potential damage achievable in a 499 reflection attack, in which the attacker sends DNS queries with a 500 forged source address, and the victim receives the response. By 501 generating a large response to a small query, the attacker can 502 magnify the bandwidth directed at the victim. 504 Since it is difficult to complete a TCP three-way handshake begun 505 from a forged source address, DNS reflection attacks utilize UDP 506 queries. Unless the attacker utilizes EDNS0 [RFC2671] to enlarge the 507 requester's maximum payload size, a response can only reach 576 508 octets before the truncate bit is set in the response. This limits 509 the maximum magnification achievable from a DNS query that does not 510 utilize EDNS0. 512 However, where the responder supports EDNS0, an attacker may set the 513 requester maximum payload size to a larger value while querying for a 514 large RR, such as a certificate [RFC4398]. Thus the combination of 515 large data stored in DNS RRs and responders supporting large 516 requester payload sizes has the potential to increase the potential 517 damage achievable in a reflection attack. Since a reflection attack 518 can be launched from any network that does not implement source 519 address validation, these attacks are difficult to eliminate absent 520 the ubiquitous deployment of source address validation. Since 521 reflection attacks are most damaging when launched from high 522 bandwidth networks, the implementation of source address validation 523 on these networks is particularly important. 525 The bandwidth that can be mustered in a reflection attack directed by 526 a botnet controlling broadband hosts is sobering. For example, if a 527 responder could be directed to generate a 10KB response in reply to a 528 50 octet query, then magnification of 200:1 would be attainable. 529 This would enable a botnet controlling 10000 hosts with 1 Mbps of 530 bandwidth to focus 2000 Gbps of traffic on the victim, more than 531 sufficient to congest any site on the Internet. 533 3.4. Administrative Structures Misaligned with the DNS 535 While the DDDS framework enables any sort of alphanumeric data to 536 serve as a DNS name through the application of the First Well Known 537 Rule, the delegative structure of the resulting DNS name may not 538 reflect the division of responsibilities for the resources that the 539 alphanumeric data indicates. Telephone numbers in the United States, 540 for example, are assigned and delegated in a relatively complex 541 manner: the first three digits of a nationally specific number are an 542 "area code" which is understood as an indivisible component of the 543 number, yet for the purpose of the DNS, those three digits are ranked 544 hierarchically. 546 The difficulty of mapping the DNS to administrative structures can 547 even occur with traditional domain names, where applications expect 548 clients to infer or locate zone cuts. 550 3.5. Domain Redirection 552 Most Internet application services provide a redirection feature - 553 when you attempt to contact a service, the service may refer you to a 554 different service instance, potentially in another domain, that is 555 for whatever reason better suited to address a request. In HTTP and 556 SIP, for example, this feature is implemented by the 300 class 557 responses containing one or more better URIs that may indicate that a 558 resource has moved temporarily or permanently to another service. 559 Several tools in the DNS. including the SRV record, can provide a 560 similar feature at a DNS level, and consequently some applications as 561 an optimization offload the responsibility for redirection to the 562 DNS; NAPTR can also provide this capability on a per-application 563 basis, and numerous DNS resource records can provide redirection on a 564 per-domain basis. This can prevent the unnecessary expenditure of 565 application resources on a function that could be performed as a 566 component of a DNS lookup that is already a prerequisite for 567 contacting the service. Consequently, in some deployment 568 architectures this DNS-layer redirection is used for virtual hosting 569 services. 571 Implementing domain redirection in the DNS, however, has important 572 consequences for application security. Un the absence of universal 573 DNSSEC, applications must blindly trust the DNS in order to believe 574 that their request has not been hijacked and redirected to a 575 potentially malicious domain, unless some subsequent application 576 mechanism can provide the necessary assurance. By way of contrast, 577 for application-layer redirections protocols like HTTP and SIP have 578 widely deployed security mechanisms such as TLS that can use 579 certificates to vouch that a 300 response came from the domain that 580 the originator initially hoped to contact. 582 A number of applications have attempted to provide an after-the-fact 583 security mechanism that verifies the authority of a DNS delegation in 584 the absence of DNSSEC. The specification for deferencing SIP URIs 585 ([RFC3263], reaffirmed in [RFC5922]) requires that during TLS 586 establishment, the site eventually reached by a SIP request present a 587 certificate corresponding to the original URI expected by the user 588 (in other words, if example.com redirects to example.net in the DNS, 589 this mechanism expects that example.net will supply a certificate for 590 example.com in TLS), which requires a virtual hosting service to 591 possess a certificate corresponding to the hosted domain. This 592 restriction rules out many styles of hosting deployments common the 593 web world today, however. [I-D.barnes-hard-problem] explores this 594 problem space, and [I-D.saintandre-tls-server-id-check] proposes a 595 solution for all applications that use TLS. Potentially, new types 596 of certificates (similar to [RFC4985] might bridge this gap, but 597 support for those certificates would require changes to existing 598 certificate authority practices as well as application behavior. 600 All of these application-layer measures attempt to mirror the 601 delegation of authority in the DNS, when the itself DNS serves as the 602 ultimate authority on how domains are delegated. The difficulty of 603 synchronizing a static instrument like a certificate with a 604 delegation in the DNS, however, exposes the fundamentally problematic 605 nature of this endeavor. In environments where DNSSEC is not 606 available, the problems with securing DNS-layer redirections would be 607 avoided by performing redirections in the application-layer. 609 4. Principles and Guidance 611 The success of the DNS relies on the fact that it is a distributed 612 database, one that has the property that it is loosely coherent and 613 that it offers lookup instead of search functionality. Loose 614 coherency means that answers to queries are coherent within the 615 bounds of data replication between authoritative servers and caching 616 behavior by recursive name servers. 618 It is likely that the DNS provides a good match whenever applications 619 needs are aligned with the following properties: 621 Data can be stored in such a way that a single query name, class 622 and type provide a direct answer 624 Data is indexed by keys that are semantically and syntactically 625 uncomplicated 627 Answers only depend on the question (name, type and class), not on 628 the identity of the entity doing the query 630 Data stored in the DNS is resilient to data propagation and 631 caching behavior 633 Whenever one of the four properties above does not apply to ones data 634 one should seriously consider whether the DNS is the best place to 635 store actual data. On the other hand, good indicators that the DNS 636 is not the appropriate tool for solving problems is when you have to 637 worry about: 639 Trying to establish domain boundaries within the tree - the 640 delegation point in the DNS is something that applications should 641 in general not be aware off 643 Working from application identifiers that cannot be resolved by 644 the DNS without excessively complex transformations 646 The sensitivity of the data provided by the DNS, especially 647 confidentiality 649 Highly volatile data that synchronizes with the state of 650 applications external to the DNS 652 Answers dependent on the application-layer identity or location of 653 the source of the query 655 There are many useful application features that can safely be 656 offloaded to the DNS: aside from locating services in a domain, the 657 DNS clearly can assist in the resolution of identifiers without a 658 domain component (including URNs), and moreover it can host some 659 static application data, like the cryptographic keys used by DKIM for 660 email, which are well suited to storage in the DNS. However, the 661 prospects for offloading application features like authentication of 662 query originators, structuring compound questions and implementing 663 metadata about the tree structure are more remote. While clearly 664 DNS-layer redirection is a widely deployed alternative to 665 application-layer redirection, many applications that choose to 666 offload this have struggled to meet the resulting security 667 challenges. 669 In cases where applications require these sorts of features, they are 670 simply better instantiated by independent application-layer protocols 671 than the DNS. The query-response semantics of the DNS are easily 672 replicated by HTTP, for example, and the objects which HTTP can carry 673 both in queries and responses can easily contain the necessary 674 structure to manage compound queries. Similarly, HTTP has numerous 675 ways to provide the necessary authentication, authorization and 676 confidentiality properties that some features require. 678 Where the administrative delegations of the DNS form a necessary 679 component in the instantiation of an application feature, there are 680 various ways that the DNS can bootstrap access to an independent 681 application-layer protocol better suited to field the queries in 682 question. For example, since NAPTR records can contain URIs, those 683 URI can point to an external query-response service such as HTTP, 684 with a NAPTR service field that signal to applications that questions 685 of interest can be answered at that service. 687 4.1. Private DNS Deployments 689 Today, many deployments that want to install these rich application 690 features in DNS do so in private environments rather than in the 691 public DNS tree. There are two motivations for this: in the first 692 place, proprietary non-standard parameters can easily be integrated 693 into DNS queries or responses; secondly, confidentiality and custom 694 responses can be provided by deploying, respectively, underlying VPNs 695 to shield the private tree from public queries, and effectively 696 different virtual DNS trees for each administrative entity that might 697 launch a query (so-called "split horizon" DNS being one such 698 example). In these constrained environments, caching and recursive 699 resolvers can be managed or eliminated in order to prevent any 700 unexpected intermediary behavior. 702 While these deployments address the requirements of applications that 703 rely on them, by definition these techniques will not form the basis 704 of a standard solution. Moreover, as implementations come to support 705 these proprietary parameters, it seems almost certain that these 706 private techniques will begin to leak into the public DNS. 707 Therefore, keeping these features within higher-layer applications 708 rather than offloading them to the DNS is preferred. 710 5. Security Considerations 712 Many of the concerns about offloading application features to the DNS 713 revolve around security. Section 3.5 discusses a security problem 714 concerning redirection that has surfaced in a number of protocols 715 (see [I-D.barnes-hard-problem]). The perceived need to authenticate 716 the source of DNS queries (see Section 3.1.1 and authorize access to 717 particular resource records also illustrates the fundamental security 718 principles that arise from offloading certain application features to 719 the DNS. 721 While DNSSEC, were it deployed universally, can play an important 722 part in securing application redirection in the DNS, DNSSEC does not 723 provide a means for a resolver to authenticate itself to a server, 724 nor a framework for servers to return selective answers based on the 725 authenticated identity of resolvers. 727 6. IANA Considerations 729 This document contains no considerations for the IANA. 731 7. Acknowledgements 733 The IAB would like to thank Ed Lewis, Ray Bellis, Lawrence Conroy, 734 Ran Atkinson, Patrik Faltstrom and Eliot Lear for their 735 contributions. 737 8. Informative References 739 [I-D.barnes-hard-problem] 740 Barnes, R. and P. Saint-Andre, "High Assurance Re- 741 Direction (HARD) Problem Statement", 742 draft-barnes-hard-problem-00 (work in progress), 743 July 2010. 745 [I-D.saintandre-tls-server-id-check] 746 Saint-Andre, P. and J. Hodges, "Representation and 747 Verification of Domain-Based Application Service Identity 748 in Certificates Used with Transport Layer Security", 749 draft-saintandre-tls-server-id-check-09 (work in 750 progress), August 2010. 752 [RFC0974] Partridge, C., "Mail routing and the domain system", 753 RFC 974, January 1986. 755 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 756 Arbitrary String Attributes", RFC 1464, May 1993. 758 [RFC1530] Malamud, C. and M. Rose, "Principles of Operation for the 759 TPC.INT Subdomain: General Principles and Policy", 760 RFC 1530, October 1993. 762 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 763 April 1995. 765 [RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the 766 location of services (DNS SRV)", RFC 2052, October 1996. 768 [RFC2168] Daniel, R. and M. Mealling, "Resolution of Uniform 769 Resource Identifiers using the Domain Name System", 770 RFC 2168, June 1997. 772 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 773 August 1998. 775 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 776 RFC 2671, August 1999. 778 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 780 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 781 Unique DNS Root", RFC 2826, May 2000. 783 [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, 784 September 2000. 786 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 787 Protocol (SIP): Locating SIP Servers", RFC 3263, 788 June 2002. 790 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 791 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 793 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 794 Resource Identifier (URI): Generic Syntax", STD 66, 795 RFC 3986, January 2005. 797 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 798 and T. Wright, "Transport Layer Security (TLS) 799 Extensions", RFC 4366, April 2006. 801 [RFC4367] Rosenberg, J. and IAB, "What's in a Name: False 802 Assumptions about DNS Names", RFC 4367, February 2006. 804 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 805 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 806 Signatures", RFC 4871, May 2007. 808 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 809 Subject Alternative Name for Expression of Service Name", 810 RFC 4985, August 2007. 812 [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design 813 Choices When Expanding the DNS", RFC 5507, April 2009. 815 [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 816 Certificates in the Session Initiation Protocol (SIP)", 817 RFC 5922, June 2010. 819 Authors' Addresses 821 Olaf Kolkman 822 NLNet 824 Email: olaf@nlnetlabs.nl 826 Jon Peterson 827 NeuStar, Inc. 829 Email: jon.peterson@neustar.biz 831 Hannes Tschofenig 832 Nokia Siemens Networks 834 Email: Hannes.Tschofenig@gmx.net 836 Bernard Aboba 837 Microsoft Corporation 839 Email: bernarda@microsoft.com