idnits 2.17.1 draft-iab-dns-applications-00.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 (October 17, 2010) is 4930 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4366' is defined on line 703, 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 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 (~~), 4 warnings (==), 8 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: Standards Track J. Peterson 5 Expires: April 20, 2011 NeuStar, Inc. 6 H. Tschofenig 7 Nokia Siemens Networks 8 B. Aboba 9 Microsoft Corporation 10 October 17, 2010 12 Architectural Considerations on Application Features in the DNS 13 draft-iab-dns-applications-00 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 the DNS, 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 April 20, 2011. 47 Copyright Notice 48 Copyright (c) 2010 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3. Overview of DNS Application Usages . . . . . . . . . . . . . . 7 78 3.1. Locating Services in a Domain . . . . . . . . . . . . . . 7 79 3.2. NAPTR and DDDS . . . . . . . . . . . . . . . . . . . . . . 8 80 3.3. Arbitrary Data in the DNS . . . . . . . . . . . . . . . . 9 81 4. Challenges for the DNS . . . . . . . . . . . . . . . . . . . . 11 82 4.1. Compound Queries . . . . . . . . . . . . . . . . . . . . . 11 83 4.1.1. Responses Tailored to the Originator . . . . . . . . . 12 84 4.2. Metadata about Tree Structure . . . . . . . . . . . . . . 12 85 4.3. Using DNS as a Generic Database . . . . . . . . . . . . . 13 86 4.3.1. Administrative Structures Misaligned with the DNS . . 14 87 4.4. Domain Redirection . . . . . . . . . . . . . . . . . . . . 14 88 5. Principles and Guidance . . . . . . . . . . . . . . . . . . . 16 89 5.1. Private DNS Deployments . . . . . . . . . . . . . . . . . 17 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 92 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 93 9. Informative References . . . . . . . . . . . . . . . . . . . . 21 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 96 1. Terminology 98 In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", 99 and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 101 2. Motivation 103 The Domain Name System (DNS) has long provided a general means of 104 translating easily-memorized domain names into numeric Internet 105 Protocol addresses, which made the Internet easier to use by 106 providing a valuable layer of indirection between well-known names 107 and lower layer protocol elements. [RFC0974], however, documented a 108 further use of the DNS: to manage application services operating in a 109 domain with the MX resource record, which helped email addressed to 110 the domain to find an authoritative mail service for the domain. 112 The MX record was the first of a long series of DNS resource records 113 that supported applications associated with a domain name. The SRV 114 resource record provided a more general mechanism for identifying 115 services in a domain, complete with a weighting system and selection 116 among transports. The NAPTR resource record, especially in its 117 reincarnation as the DDDS framework, added a new wrinkle - a way of 118 casting any sort of string as a domain name, which might then be 119 "resolved" by the DNS to find NAPTR records. This enabled the 120 resolution of identifiers other than traditional domain names through 121 the DNS; the best-known example of this are telephone numbers, as 122 resolved by the DDDS application ENUM. Recent work such as DKIM has 123 enabled security features of applications to be advertised through 124 the DNS, via the TXT resource record. 126 As the amount of application intelligence in the DNS has increased, 127 however, some proposed extensions have become misaligned with the 128 foundational assumptions of the DNS. One such assumption is that the 129 resolution of traditional domain names to IP addresses is public 130 information, lacking any confidentiality requirement - any security 131 needed by an application or service is invoked after the service has 132 been contacted. Typically, the translation is also global 133 information, meaning that the response to a resolution does not 134 depend on the identity of the querier (although for load balancing 135 reasons or related optimizations, the DNS may return different 136 addresses in response to different queries, or even no response at 137 all, which is discussed further below). These assumptions permit the 138 existence of a single authoritative unique global root of the DNS, 139 and also underlie the scaling capabilities of the DNS, notably the 140 ability of intermediaries to cache responses. At the point where 141 these assumptions no longer apply to the data that an application 142 requires, one can reasonably question whether or not that application 143 should use the DNS to deliver that data. 145 Increasingly, however, the flexibility of the DDDS framework has 146 encouraged the repurposing of the DNS into a generic database. Since 147 the output of DDDS can be a URI, and URIs themselves are containers 148 for basically arbitrary data, through the DDDS framework one can 149 query for an arbitrary string (provided it can be formatted and 150 contained within the syntactical limits of a domain name) and receive 151 as a response an equally arbitrary chunk of data. The use of the DNS 152 for generic database lookups is especially attractive in environments 153 that already use the DDDS framework, where deployments would prefer 154 to reuse the existing query/response interface of the DNS over 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 3. Overview of DNS Application Usages 169 While the fundamental motivation for the Domain Name System was to 170 replace lengthy numeric addresses with strings that are easier to 171 interpret and memorize, the hierarchical system of hosts and domains 172 rendered the DNS important for its administrative properties as well 173 as its mnemonics. In so far as the DNS explained how to reach an 174 administrative domain rather than simply a host, it naturally 175 extended to optimize for reaching particular applications within a 176 domain. Without these extensions, a user trying to send mail to a 177 foreign domain, for example, lacked a discovery mechanism to locate 178 the right host in the remote domain to connect to for mail. While 179 such a discovery mechanism could be built by each such application 180 protocol, the universality of the DNS invites installing these such 181 features in its public tree. 183 3.1. Locating Services in a Domain 185 The Mail Exchange (MX) DNS resource record provides the simplest 186 motivating example for an application advertising its host in the 187 Domain Name System. The MX resource record contains the hostname of 188 a server within the administrative domain in question that receives 189 mail; that hostname must itself be resolved to an IP address through 190 the DNS in order to reach the mail server. While naming conventions 191 for applications might serve a similar purpose (a host might be named 192 "mail.example.com" for example), approaching service location through 193 the creation of a new resource record yields several important 194 benefits. Firstly, one can put multiple MX records in a zone, in 195 order to designate backup hosts that can receive mail when the 196 primary server is offline. One can even load balance across several 197 such hosts. These properties could not easily be captured by naming 198 conventions (see [RFC4367]). 200 While the MX record represents a substantial improvement over naming 201 conventions as a means of service location, it remains specific to a 202 single application. Thus, the general approach of the MX record was 203 adapted to fit a broader class of application through the Service 204 (SRV) resource record (originally [RFC2052]. The SRV record allows 205 DNS resolvers to search for particular applications and underlying 206 transports (for example, HTTP running over TLS) and to learn the 207 hostname and port where that service resides in a given 208 administrative domain. It also provides a weighting mechanism to 209 allow load balancing across several (presumably equivalent) instances 210 of a service in a domain. 212 The reliance of applications on the existence of MX and SRV has 213 important implications for the way that applications manage 214 identifiers. Email identifiers of the form "user@domain" require the 215 presence of MX records to provide the convenience of simply 216 specifying that "domain" component rather than a "host.domain" 217 structure. While for applications like HTTP, naming conventions 218 continue to abound ("www.example.com"), the SRV algorithm queries for 219 the invoked protocol based, for protocol like HTTP derived from the 220 URL scheme of the identifier invoked by the application. The 221 application thus retained sole responsibility for carrying the 222 desired protocol and domain, but could offload to the DNS the 223 location of the host of that service within the domain, the port 224 where the service resided on that host, load balancing and fault 225 tolerance, and related application features. Ultimately, resolvers 226 that acquire MX or SRV records use them as intermediate 227 transformations in order to arrive at an eventual hostname that will 228 resolve to the IP address of a host to contact for the service. 230 [TBD: Potentially incorporate some discussion of Hammer's hostmeta or 231 the Webfingers approach as alternatives to using the DNS to identify 232 additional resources required for services] 234 3.2. NAPTR and DDDS 236 The Naming Authority Pointer (NAPTR, originally [RFC2168]) record 237 evolved to fulfill a need in the transition from Uniform Resource 238 Locators (URLs) to the more mature Uniform Resource Indicators (URIs) 239 framework, which incorporated Uniform Resources Names (URNs). Unlike 240 URLs, URNs typically do not convey enough semantics internally to 241 resolve them through the DNS, and consequently a separate URI- 242 transformation mechanism is required to convert these types of URIs 243 into domain names. This allowed identifiers with no recognizable 244 domain component to be resolved on the Internet. Once these 245 transformations resulted in a domain name, applications could receive 246 NAPTR records from that zone of the DNS. NAPTR records contain a far 247 more rich and complex structure than the MX or SRV resource records. 248 A NAPTR contained two different weighting mechanisms ("order" and 249 "preference"), a "service" field to designate the application that 250 the NAPTR record described, and then two fields that could contain 251 translations: a "replacement" or "regular expression" field, only one 252 of which appeared in given NAPTR record. A "replacement," like 253 NAPTR's ancestor the PTR record, simply designated another zone where 254 one would look for records associated with this service in the 255 domain. The "regexp," on the other hand, allowed sed-like 256 transformations on the original URI intended to transform it into an 257 identifier that the DNS could resolve. 259 The same mechanism could obviously be applied to other sorts of 260 identifiers that lacked a domain component, and thus this work 261 naturally combined with activities to create a system for resolving 262 telephone numbers on the Internet, which became known as ENUM 263 (originally [RFC2916]). ENUM borrowed from an earlier proposal, the 264 "tpc.int" domain ([RFC1530]), which provided a means for encoding 265 telephone numbers as domain names applying a string preparation 266 algorithm that required reversing the digits and treating each 267 individual digit as a zone of the DNS - thus, for example, the number 268 +15714345400 became 0.0.4.5.4.3.4.1.7.5.1.tpc.int. In the ENUM 269 system, in place of "tpc.int" the special domain "e164.arpa" was 270 reserved for use. In its more mature form in Dynamic Delegation and 271 Discovery Service (DDDS) ([RFC3401] passim) framework, this initial 272 transformation was called the "First Well Known Rule." Its 273 flexibility has inspired a number of proposals beyond ENUM to encode 274 and resolve unorthodox identifiers in the DNS. Provided that the 275 identifiers transformed by the First Well Known Rule have some 276 meaningful hierarchical structure and are not overly lengthy, 277 virtually anything can serve as an input for the DDDS structure: for 278 example, civic addresses (see draft-rosen-dns-sos). 280 The presence of the "regexp" field of NAPTR records enabled 281 unprecedented flexibility in the transformations that DNS resolution 282 could perform. Since the output of the regular expression frequently 283 took the form of a URI (in ENUM resolution, for example, a telephone 284 might be converted into a SIP URI), anything that could be encoded as 285 a URI might be the result of resolving a NAPTR record. Since URI 286 encoding has ways of carrying basically arbitrary data (see for 287 example, the base 64 encoded binary data in the data URL), resolving 288 a NAPTR record might result in an output other than an identifier 289 which would subsequently be resolved to an IP address and contacted 290 for a particular application - it could give a literal result 291 consumed by the application. For a query-response application, the 292 DNS could effectively implement the entire application feature set. 293 Effectively, the DDDS framework turned the DNS into a generic 294 database - indeed, the DNS serves as but one example of a possible 295 back-end for DDDS, and perhaps not the most suitable one. 297 3.3. Arbitrary Data in the DNS 299 NAPTR did not pioneer the possibility of storing arbitrary data in 300 the DNS. [RFC1464] defined the TXT record, a means to store 301 arbitrary string data in the DNS using a simple attribute name/value 302 pair syntax. The existence of TXT records has long provided new 303 applications with a rapid way of storing data associated with a 304 domain name in the DNS, as the attribute names require no 305 registration process and can simply be minted at will. This, an 306 application that wants to store additional data in the DNS can do so 307 without registering a new resource record type. 309 While the laxity of policies surrounding the use of the TXT record 310 has resulted in a checkered past for standardizing application usage 311 of TXT, it has provided a technical solution for DKIM ([RFC4871]) to 312 store cryptographic keys for email in DNS. Storing keys in the DNS 313 for DKIM made sense for several reasons: notably, because the public 314 keys associated because email required wide public distribution, and 315 because email identifiers contain a domain component that 316 applications can easily use to consult the DNS. If the application 317 had to negotiate support for the DKIM mechanism with mail servers, it 318 would give rise to bid-down attacks that are not possible if the DNS 319 delivers the keys (provided that DNSSEC guarantees authenticity of 320 zone files). 322 4. Challenges for the DNS 324 These methods for transforming arbitrary identifiers into domain 325 names, and for returning arbitrary data in response to DNS queries, 326 both represent significant extensions from the original concept of 327 the DNS, yet neither fundamentally alters the underlying model of the 328 DNS. The promise that applications might rely on the DNS as a 329 generic database, however, invariably gives rise to additional 330 requirements that one might expect to find in a database access 331 protocol: authentication of the source of queries for comparison to 332 access control lists, formulating complex relational queries, and 333 asking questions about the structure of the database itself. DNS was 334 not designed to provide these sorts of properties, and extending the 335 DNS to encompass them would represent a fundamental alteration to its 336 model. If an application desires these properties from a database, 337 in general this is a good indication that the DNS cannot meet the 338 needs of the application in question. 340 Since many of these new requirements have emerged from the ENUM 341 space, the following sections use ENUM as an illustrative example; 342 however, any application using the DNS as a feature-rich database 343 could easily end up with similar requirements. 345 4.1. Compound Queries 347 Traditionally, the DNS requires resolvers to supply no information 348 other than the domain name (and the type and class of records sought) 349 in order to receive a reply from an authoritative server. There are, 350 however, plenty of query-response applications in deployments that 351 require a compound search, which takes into account more than one 352 factor in formulating a response. For example, in the telephony 353 space, telephone call routing often takes into account numerous 354 factors aside from the dialed number, including originating trunk 355 groups, interexchange carrier selection, number portability data, 356 time of day, and so on. While in its original conception, ENUM hoped 357 to circumvent the traditional PSTN and route directly to Internet- 358 enabled devices, the infrastructure ENUM effort to support the 359 migration of traditional carrier routing functions to the Internet 360 aspires to achieve feature parity with traditional number routing. 361 Consequently, some consideration has been given to ways to add 362 additional data to ENUM queries to give the DNS server sufficient 363 information to return a suitable URI. 365 Several workaround have attempted to instantiate these sorts of 366 features in the DNS. Most commonly, proposals piggyback additional 367 query parameters as eDNS0 extensions (see [RFC2671]). Alternatively, 368 the domain name itself can be compounded with the additional 369 parameters: one could take a name like 370 0.0.4.5.4.3.4.1.7.5.1.e164.arpa and append a trunk group identifier 371 to it, for example, of the form 372 tg011.0.0.4.5.4.3.4.1.7.5.1.e164.arpa. While in the latter case, a 373 DNS server can adhere to its traditional behavior in locating 374 resource records, the syntactical viability of encoding additional 375 parameters in this fashion is very dubious, especially if more than 376 one additional parameter is required and the presence of parameters 377 is optional. The former case requires significant changes to DNS 378 server behavior. Moreover, the implications for these sorts of 379 compound queries on recursion and caching are potentially serious. 381 4.1.1. Responses Tailored to the Originator 383 The most important subcase of the compound queries are DNS responses 384 tailored to the identity of their originator, where some sort of 385 administrative identity of the originator must be conveyed to the 386 DNS. Often the source IP address is somehow mapped to the 387 administrative entity of the originator in deployments with this 388 requirement today. The security implications of trusting the source 389 IP address of a DNS query have prevented most solutions along these 390 lines from being standardized. Some applications require an 391 application-layer identifier of the originator rather than an IP 392 address; for example, draft-kaplan-enum-source-uri provides a SIP URI 393 in an eDNS0 parameter (though without any specific provision for 394 cryptographically verifying the claimed identity). Effectively, the 395 conveyance of this information about the administrative identity of 396 the originator is a weak authentication mechanism, on the basis of 397 which the DNS server makes an authorization decision before sharing 398 resource records. This can parlay into a selective confidentiality 399 mechanism, where only a specific set of originators are permitted to 400 see resource records, or a case where a query for the same name by 401 different entities results in completely different resource record 402 sets. The DNS, however, substantially lacks the protocol semantics 403 to manage access control list for data, and again, caching and 404 recursion introduce significant challenges for applications that 405 attempt to offload this responsibility to the DNS. Achieving feature 406 parity with even the simplest authentication mechanisms available at 407 the application layer would like require significant rearchitecture 408 of the DNS. 410 4.2. Metadata about Tree Structure 412 ENUM use cases have also surfaced a couple of optimization 413 requirements to reduce unnecessary calls and queries by including 414 metadata that describes the contents and structure of ENUM DNS trees. 415 In particular, the "send-n" proposal (draft-bellis-enum-send-n) hopes 416 to reduce the number of DNS queries sent in cases where a telephone 417 system is collecting dialed digits in a region that supports 418 "overlap" dialing, a form of variable-length number plan. In these 419 plans, a telephone switch ordinarily cannot anticipate when a dialed 420 number is complete, as only the terminating customer premise 421 equipment (typically a private branch exchange) knows how long a 422 telephone number needs to be. The "send-n" proposal offloads to the 423 DNS the responsibility for informing the telephone switch how many 424 digits must be collected by placing in zones corresponding to 425 incomplete telephone numbers some resource records which state how 426 many more digits are required - effectively how many steps down the 427 DNS tree one must take to reach a name for a complete number. With 428 this information, the application is not required to query the DNS 429 every time a new digit is dialed, but can wait to collect sufficient 430 digits to receive a response. A tangentially related proposal, 431 draft-ietf-enum-void, similarly places resource records in the DNS 432 that tell the application that it need not attempt to reach a number 433 on the PSTN, as the number is unassigned. 435 Both proposals optimize application behavior by placing metadata in 436 the DNS that predicts the success of future queries or application 437 invocations. These predictions require that the metadata remain 438 synchronized with the state of the resources it predicts. 439 Maintaining that synchronization, however, requires that the DNS have 440 semi-real time updates that may conflict with scale and caching 441 mechanisms. It is unclear why this data is better maintained by the 442 DNS than in an unrelated application protocol. 444 4.3. Using DNS as a Generic Database 446 As previously noted, the use of the First Well Known Rule of DDDS 447 combined with data URLs effectively allows the DNS to answer queries 448 for arbitrary strings and to return arbitrary data as value. Some 449 query-response applications, however, require queries and responses 450 that simply fall outside the syntactic capabilities of the DNS. 451 While the data URL specification (RFC2397) notes that it is "only 452 useful for short values," many applications today use quite large 453 data URLs as workarounds in environments where only URIs can be 454 interpolated. While the use of TCP and eDNS0 allows DNS responses to 455 be quite long, nonetheless there are forms of data that an 456 application might store in the DNS that exceed reasonable limits: in 457 the ENUM context, for example, something like storing base 64 encoded 458 mp3 files of custom ringtones. Similarly the domain names themselves 459 must conform with certain syntactic constraints: they must consist of 460 labels that do not exceed 63 characters while the total length of the 461 encoded name may not exceed 255 octets, they must obey fairly strict 462 encoding rules, and so on. 464 4.3.1. Administrative Structures Misaligned with the DNS 466 While the DDDS framework enables any sort of alphanumeric data to 467 serve as a DNS name through the application of the First Well Known 468 Rule, the delegative structure of the resulting DNS name may not 469 reflect the division of responsibilities for the resources that the 470 alphanumeric data indicates. Telephone numbers in the United States, 471 for example, are assigned and delegated in a relatively complex 472 manner: the first three digits of a nationally specific number are an 473 "area code" which is understood as an indivisible component of the 474 number, yet for the purpose of the DNS, those three digits are ranked 475 hierarchically. 477 4.4. Domain Redirection 479 Most Internet application services provide a redirection feature - 480 when you attempt to contact a service, the service may refer you to a 481 different service instance, potentially in another domain, that is 482 for whatever reason better suited to address a request. In HTTP and 483 SIP, for example, this feature is implemented by the 300 class 484 responses containing one or more better URIs that may indicate that a 485 resource has moved temporarily or permanently to another service. 486 Tools in the DNS like the SRV record, however, can provide a similar 487 feature at a DNS level, and consequently some applications as an 488 optimization offload the responsibility for redirection to the DNS; 489 NAPTR can also provide this capability on a per-application basis, 490 and numerous DNS resource records can provide redirection on a per- 491 domain basis. This can prevent the unnecessary expenditure of 492 application resources on a function that could be performed as a 493 component of a DNS lookup that is already a prerequisite for 494 contacting the service. Consequently, in some deployment 495 architectures this DNS-layer redirection is used for virtual hosting 496 services. 498 Implementing domain redirection in the DNS, however, has important 499 consequences for application security. Un the absence of universal 500 DNSSEC, applications must blindly trust the DNS in order to believe 501 that their request has not been hijacked and redirected to a 502 potentially malicious domain, unless some subsequent application 503 mechanism can provide the necessary assurance. By way of contrast, 504 for application-layer redirections protocols like HTTP and SIP have 505 widely deployed security mechanisms such as TLS that can use 506 certificates to vouch that a 300 response came from the domain that 507 the originator initially hoped to contact. 509 A number of applications have attempted to provide an after-the-fact 510 security mechanism that verifies the authority of a DNS delegation in 511 the absence of DNSSEC. The specification for deferencing SIP URIs 512 ([RFC3263], reaffirmed in [RFC5922]) requires that during TLS 513 establishment, the site eventually reached by a SIP request present a 514 certificate corresponding to the original URI expected by the user 515 (in other words, if example.com redirects to example.net in the DNS, 516 this mechanism expects that example.net will supply a certificate for 517 example.com in TLS), which requires a virtual hosting service to 518 possess a certificate corresponding to the hosted domain. This 519 restriction rules out many styles of hosting deployments common the 520 web world today, however. [I-D.barnes-hard-problem] explores this 521 problem space, and [I-D.saintandre-tls-server-id-check] proposes a 522 solution for all applications that use TLS. Potentially, new types 523 of certificates (similar to [RFC4985] might bridge this gap, but 524 support for those certificates would require changes to existing 525 certificate authority practices as well as application behavior. 527 All of these application-layer measures attempt to mirror the 528 delegation of authority in the DNS, when the itself DNS serves as the 529 ultimate authority on how domains are delegated. The difficulty of 530 synchronizing a static instrument like a certificate with a 531 delegation in the DNS, however, exposes the fundamentally problematic 532 nature of this endeavor. In environments where DNSSEC is not 533 available, the problems with securing DNS-layer redirections would be 534 avoided by performing redirections in the application-layer. 536 5. Principles and Guidance 538 The success of the DNS relies on the fact that it is a distributed 539 database that has the property that it is loosely coherent and that 540 it offers lookup instead of search functionality. Loose coherency 541 means that answers to queries are coherent within the bounds of data 542 replication between authoritative servers and caching behavior by 543 recursive name servers. 545 It is likely that the DNS provides a good match whenever applications 546 needs are aligned with the following properties: 548 Data can be stored in such a way that a single query name and 549 query type provide a direct answer 551 Answers are only depended on the question (name and type), not on 552 the location or identity of the entity doing the query 554 Data stored in the DNS is resilient to data propagation and 555 caching behavior 557 Whenever one of the 3 properties does not apply to ones data one 558 should seriously consider whether the DNS is the best place to store 559 actual data. On the other hand, good indicators that the DNS is not 560 the appropriate tool for solving problems is when you have to worry 561 about: 563 Trying to establish domain boundaries within the tree - the 564 delegation point in the DNS is something that applications should 565 in general not be aware off 567 Having to do more than one, two queries to get to ones answer 568 (consider a chain of NAPTR records) 570 The sensitivity of the data provided by the DNS 572 Highly volatile data 574 Location- or identity-dependent answers 576 There are many useful application features that can safely be 577 offloaded to the DNS: aside from locating services in a domain, the 578 DNS clearly can assist in the resolution of identifiers without a 579 domain component (including URNs), and moreover it can host some 580 static application data, like the cryptographic keys used by DKIM for 581 email, which are well suited to storage in the DNS. However, the 582 prospects for offloading application features like authentication of 583 query originators, structuring compound questions and implementing 584 metadata about the tree structure are more remote. While clearly 585 DNS-layer redirection is a widely deployed alternative to 586 application-layer redirection, many applications that choose to 587 offload this have struggled to meet the resulting security 588 challenges. 590 In cases where applications require these sorts of features, they are 591 simply better instantiated by independent application-layer protocols 592 than the DNS. The query-response semantics of the DNS are easily 593 replicated by HTTP, for example, and the objects which HTTP can carry 594 both in queries and responses can easily contain the necessary 595 structure to manage compound queries. Similarly, HTTP has numerous 596 ways to provide the necessary authentication, authorization and 597 confidentiality properties that some features require. 599 Where the administrative delegations of the DNS form a necessary 600 component in the instantiation of an application feature, there are 601 various ways that the DNS can bootstrap access to an independent 602 application-layer protocol better suited to field the queries in 603 question. For example, since NAPTR records can contain URIs, those 604 URI can point to an external query-response service such as HTTP, 605 with a NAPTR service field that signal to applications that questions 606 of interest can be answered at that service. 608 5.1. Private DNS Deployments 610 Today, many deployments that want to install these application 611 features in DNS do so in private environments rather than in the 612 public DNS tree. There are two motivations for this: in the first 613 place, proprietary non-standard parameters can easily be integrated 614 into DNS queries or responses; secondly, confidentiality and custom 615 responses can be provided by deploying, respectively, underlying VPNs 616 to shield the private tree from public queries, and effectively 617 different virtual DNS trees for each administrative entity that might 618 launch a query. In these constrained environments, caching and 619 recursive resolvers can be managed or eliminated in order to prevent 620 any unexpected intermediary behavior. 622 While these deployments address the requirements of applications that 623 rely on them, practically by definition these techniques will not 624 form the basis of a standard solution. Moreover, as implementations 625 come to support these proprietary parameters, it seems almost certain 626 that these private techniques will begin to leak into the public DNS. 627 Therefore, keeping these features within higher-layer applications 628 rather than offloading them to the DNS is preferred. 630 6. Security Considerations 632 Many of the concerns about offloading application features to the DNS 633 revolve around security. Section 4.4 discusses a security problem 634 concerning redirection that has surfaced in a number of protocols 635 (see [I-D.barnes-hard-problem]). The perceived need to authenticate 636 the source of DNS queries (see Section 4.1.1 and authorize access to 637 particular resource records also illustrates the fundamental security 638 principles that arise from offloading certain application features to 639 the DNS. 641 While DNSSEC, were it deployed universally, can play an important 642 part in securing application redirection in the DNS, DNSSEC does not 643 provide a means for a resolver to authenticate itself to a server, 644 nor a framework for servers to return selective answers based on the 645 authenticated identity of resolvers. 647 7. IANA Considerations 649 This document contains no considerations for the IANA. 651 8. Acknowledgements 653 The IAB would like to thank Patrik Faltstrom for his contribution. 655 9. Informative References 657 [I-D.barnes-hard-problem] 658 Barnes, R. and P. Saint-Andre, "High Assurance Re- 659 Direction (HARD) Problem Statement", 660 draft-barnes-hard-problem-00 (work in progress), 661 July 2010. 663 [I-D.saintandre-tls-server-id-check] 664 Saint-Andre, P. and J. Hodges, "Representation and 665 Verification of Domain-Based Application Service Identity 666 in Certificates Used with Transport Layer Security", 667 draft-saintandre-tls-server-id-check-09 (work in 668 progress), August 2010. 670 [RFC0974] Partridge, C., "Mail routing and the domain system", 671 RFC 974, January 1986. 673 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 674 Arbitrary String Attributes", RFC 1464, May 1993. 676 [RFC1530] Malamud, C. and M. Rose, "Principles of Operation for the 677 TPC.INT Subdomain: General Principles and Policy", 678 RFC 1530, October 1993. 680 [RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the 681 location of services (DNS SRV)", RFC 2052, October 1996. 683 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 684 Requirement Levels", BCP 14, RFC 2119, March 1997. 686 [RFC2168] Daniel, R. and M. Mealling, "Resolution of Uniform 687 Resource Identifiers using the Domain Name System", 688 RFC 2168, June 1997. 690 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 691 RFC 2671, August 1999. 693 [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, 694 September 2000. 696 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 697 Protocol (SIP): Locating SIP Servers", RFC 3263, 698 June 2002. 700 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 701 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 703 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 704 and T. Wright, "Transport Layer Security (TLS) 705 Extensions", RFC 4366, April 2006. 707 [RFC4367] Rosenberg, J. and IAB, "What's in a Name: False 708 Assumptions about DNS Names", RFC 4367, February 2006. 710 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 711 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 712 Signatures", RFC 4871, May 2007. 714 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 715 Subject Alternative Name for Expression of Service Name", 716 RFC 4985, August 2007. 718 [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design 719 Choices When Expanding the DNS", RFC 5507, April 2009. 721 [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 722 Certificates in the Session Initiation Protocol (SIP)", 723 RFC 5922, June 2010. 725 Authors' Addresses 727 Olaf Kolkman 728 NLNet 730 Email: olaf@nlnetlabs.nl 732 Jon Peterson 733 NeuStar, Inc. 735 Email: jon.peterson@neustar.biz 737 Hannes Tschofenig 738 Nokia Siemens Networks 740 Email: Hannes.Tschofenig@gmx.net 742 Bernard Aboba 743 Microsoft Corporation 745 Email: bernarda@microsoft.com