idnits 2.17.1 draft-iab-dns-synthesis-concerns-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 825. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 836. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 843. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 849. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 16, 2007) is 6220 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC4592' on line 768 looks like a reference -- Missing reference section? 'RFC4034' on line 764 looks like a reference -- Missing reference section? 'RFC2219' on line 754 looks like a reference -- Missing reference section? 'RFC2782' on line 760 looks like a reference -- Missing reference section? 'RFC0793' on line 751 looks like a reference -- Missing reference section? 'RFC2629' on line 792 looks like a reference -- Missing reference section? 'IAB-wildcard-commentary' on line 779 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Kolkman, Ed. 3 Internet-Draft IAB 4 Intended status: Informational April 16, 2007 5 Expires: October 18, 2007 7 Architectural Concerns on the synthesis of non-existent names in DNS. 8 draft-iab-dns-synthesis-concerns-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 18, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 There are many architectural assumptions regarding DNS behavior that 42 are not specified in the IETF standards documents describing DNS, but 43 which are deeply embedded in the behavior as expected by Internet 44 protocols and applications. These assumptions are inherent parts of 45 the network architecture of which the DNS is one component. 47 It has long been known that it is possible to use DNS wildcards in 48 ways that violate these assumptions. More recently there have been 49 deployments of middleboxes -- in most cases recursive nameservers or 50 DNS proxies at the ISP level -- that synthesize answers in ways that 51 not only violate these assumptions but also violate the DNS 52 architecture. 54 Experience with DNS synthesis in the DNS infrastructure have show 55 that the cost of violating these assumptions is significant. In this 56 document we provide an explanation of how DNS wildcards function, and 57 many examples of how their injudicious use negatively impacts both 58 individual Internet applications and indeed the Internet architecture 59 itself. We also explain that similar problems arise with the 60 synthesis of DNS responses by middleboxes. 62 We recommend that DNS wildcards should not be used in a zone unless 63 the zone operator has a clear understanding of the risks, and that 64 they should not be used without the informed consent of those 65 entities which have been delegated below the zone. 67 In addition we recommend that middleboxes do not perform DNS query 68 synthesis unless (1)there are informed consents of those that use the 69 forwarding name server, and (2)there exists an opt-out mechanism that 70 allows them to receive the original DNS answers. 72 Table of Contents 74 1. DNS Queries and synthesis of answers . . . . . . . . . . . . . 4 75 1.1. A brief primer on DNS wildcards . . . . . . . . . . . . . 4 76 1.2. Synthesis by recursive forwarders or other middle-boxes . 5 77 2. Problems with DNS synthesis . . . . . . . . . . . . . . . . . 5 78 2.1. Problems specific to DNS wildcards . . . . . . . . . . . . 6 79 2.2. Problems specific to synthesis by middleboxes . . . . . . 7 80 3. Principles To Keep In Mind . . . . . . . . . . . . . . . . . . 8 81 4. Problems encountered in recent experiences with wildcards . . 8 82 4.1. Web Browsing . . . . . . . . . . . . . . . . . . . . . . . 9 83 4.2. Email . . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 4.3. Informing Users of Errors . . . . . . . . . . . . . . . . 12 85 4.4. Spam Filters . . . . . . . . . . . . . . . . . . . . . . . 13 86 4.5. Interactions with Other Protocols . . . . . . . . . . . . 13 87 4.6. Automated Tools . . . . . . . . . . . . . . . . . . . . . 14 88 4.7. Charging . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 4.8. Single Point of Failure . . . . . . . . . . . . . . . . . 14 90 4.8.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . 14 91 4.8.2. Reserved Names . . . . . . . . . . . . . . . . . . . . 14 92 5. Undesirable Workarounds . . . . . . . . . . . . . . . . . . . 15 93 6. Principles, Conclusions, and Recommendations . . . . . . . . . 15 94 6.1. Recomendations concerning deployment of wildcards . . . . 16 95 6.2. Recomendations against the synthesis by middleboxes . . . 17 96 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 98 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 99 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 100 Appendix B. Document Editing Details . . . . . . . . . . . . . . 18 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 102 Intellectual Property and Copyright Statements . . . . . . . . . . 19 104 1. DNS Queries and synthesis of answers 106 The most basic and by far the most common operation in the DNS 107 protocols is a query for all resource records matching a given query 108 name, query class, and query type. Assuming that all the software 109 and networks involved are working correctly, such a query will 110 produce one of three possible results: 112 no such name: If the system fails to find a match for the given 113 query name and query class, it returns an indication that the name 114 does not exist. 116 no data: If the system finds a match for the query name and query 117 class it will try to determine if there is data for the query 118 type. If such data can not be found it returns an indication that 119 the name exists but no data matching the given query type is 120 present. 122 success: If the system finds a match for all three parameters, it 123 returns the matching set of resource records; 125 Ordinarily, matches for all three parameters must be exact. But here 126 is where synthesis comes into play. Synthesis can take place when 127 there is no exact match on the query name, and possibly also, when 128 there is no match to the query type. Below we discuss two sorts of 129 synthesis: Wildcard synthesis and synthesis in middle-boxes. 131 1.1. A brief primer on DNS wildcards 133 The synthesis of answers using the DNS "wildcard" mechanism has been 134 part of the DNS protocol since the original specifications were 135 written twenty years ago, but the capabilities and limitations of 136 wildcards are sufficiently tricky that discussions of both the 137 protocol details of precisely how wildcards should be implemented and 138 the operational details of how wildcards should or should not be used 139 have continued to the present day. This section attempts to explain 140 the essential details of how wildcards work, but readers should refer 141 to the recent publication on "The Role of Wildcards in the Domain 142 Name System" ([RFC4592]) and references therein for the full details. 144 In essence, DNS wildcards are rules which enable an authoritative 145 name server to synthesize DNS resource records on the fly. The basic 146 mechanism is quite simple, the complexity is in the details and 147 implications. 149 A wildcard record is an otherwise ordinary DNS resource record whose 150 leftmost (least significant) label consists of a single asterisk 151 ("*") character, such as *.bar.example. Conceptually, the asterisk 152 matches one or more labels at the left (least significant) end of the 153 DNS name. 155 When wildcard records are present, the rules become more complicated 156 than an exact match for all three of the query parameters. 157 Specifically, if the query class matches, there is no exact match for 158 the query name, and the closest match for the query name is a 159 wildcard, the system in effect synthesizes a set of resource records 160 matching the query name on the fly by treating the resource records 161 present at the wildcard name as if they had been present at the query 162 name. Thus, if the wildcard name has records matching the desired 163 query type, the system will return those records, precisely as in the 164 "success" case above; otherwise, the system will return an indication 165 that the name exists but no data matching the given query type is 166 present, precisely as in the "no data" case above. The response is 167 identical to that of a normal "success" response for the query name, 168 so the resolver which issued the query can not tell that the results 169 it got back were the result of wildcard expansion. 171 Note that, in the case of a wildcard match, the "no such name" case 172 cannot occur; the wildcard match eliminates this possibility. Note 173 also that only the query name and query class matter for purposes of 174 determining whether a wildcard matches: any record type can produce a 175 wildcard match, regardless of whether or not the record type happens 176 to match the query type. Finally, in absence of the signature 177 records produced with DNSSEC [RFC4034] a client will not be able to 178 distinguish a wildcard match from a non-wildcard match. 180 1.2. Synthesis by recursive forwarders or other middle-boxes 182 This synthesis mechanism is not part of the DNS protocol but rather 183 it is a non-standard modifications to middle-boxes such as recursive 184 name servers, transparent DNS proxies, specific NAT boxes or other 185 devices through which the DNS packets pass. These machines perform a 186 deep packet inspection and substitute locally configured resource 187 records in reply packets. At the moment of writing we are only aware 188 of implementations that perform this synthesis for "no such name" 189 answers but there is no reason to assume that the same mechanism is 190 not applied to responses that are of the "no data" type. 192 2. Problems with DNS synthesis 194 One of the main known weaknesses and dangers of synthesis is that it 195 interacts poorly with any use of the DNS which depends on "no such 196 name" responses. The list of such uses turns out to be quite large, 197 and will be discussed in some detail in a later section. 199 2.1. Problems specific to DNS wildcards 201 A known weakness and danger of wildcard records stems from the fact 202 that the wildcard label will match anything at all, so long as no 203 non-wildcard name within the zone is a closer match to the query name 204 than the wildcard is. This doesn't sound like a major problem until 205 one considers the number of conventions and, in some cases, 206 protocols, which use labels at the left (least significant) ends of 207 the names of resource records to distinguish between records 208 associated with different services, rather than using different types 209 of records. That is, in these cases, otherwise unrelated services 210 use the same type of record and clients (or users) are expected to 211 use the name corresponding to the particular service desired. This 212 applies both to the ad-hoc naming conventions described in [RFC2219] 213 such as www.foo.example and also to mechanisms such as the SRV record 214 type [RFC2782] in which the naming scheme is part of the formal 215 protocol. When names of this type are covered by wildcards such as 216 an address record named *.bar.example, such a wildcard would hand 217 back the same address record regardless of the service name encoded 218 in the query name, thus ftp.foo.bar.example, mail.foo.bar.example, 219 ntp.foo.bar.example and so forth would all end up with the same 220 synthesized address record. This problem is even worse in the SRV 221 case. For example, suppose there is a SRV record owned by a wildcard 222 that directs all traffic to port 80 on a certain machine. Then 223 suppose that SRV records were defined for the finger protocol and a 224 client issued a query for _finger._tcp.foo.bar.example that got 225 resolved by the before mentioned wildcard pointing to port 80. This 226 causes the client to contact the wrong host and connect to a port on 227 which the finger protocol is not available. The only way to avoid 228 these problems with names of this type is to add explicit records for 229 such names to the DNS. 231 Finally, the two factors listed above ("match anything" behavior, and 232 poor interaction with anything that depends on "no such name" 233 responses) interact with normal and predictable human behavior to 234 allow wildcards to have effects far beyond their intended scope. 235 Properly speaking, a wildcard record's scope is limited to a single 236 zone, since, by definition, a wildcard record never matches any name 237 that really does exist in the zone, and thus will not match any (non- 238 wildcard) delegation of a portion of the name space from a parent 239 zone to its child. (The behavior of wildcard NS records is not 240 defined, see section 4.2 of [RFC4592].) So, at first blush, it would 241 seem that the administrator of a zone is free to use wildcards 242 without worrying about effects which this might have on the zone's 243 delegated children. Unfortunately, this turns out not to be the 244 case, because DNS names are heavily exposed in user interfaces, and 245 users, being humans, make mistakes. So, while delegating the 246 bar.example zone will prevent a wildcard record *.example from 247 affecting a user who typed foo.bar.example as foi.bar.example, it 248 will not prevent the same wildcard record from affecting the same 249 user when the error is foo.bat.example. Thus, from the users' point 250 of view, some of the effects of wildcards do leak from a parent zone 251 to its children. This is not a big deal if the parent and child 252 zones are associated with a single organization, but it can become a 253 real problem if the parent and child zones are associated with 254 different organizations whose interests are not perfectly aligned. 256 The above is probably not an exhaustive list. Even after twenty 257 years of experience with the DNS, the effects of unexpected uses of 258 wildcards can still be quite surprising, because the small but 259 fundamental way in which they change the record lookup rules has a 260 nasty way of violating implicit (or, sometimes, explicit) assumptions 261 in deployed software utilizing the DNS. 263 For these reasons, almost all use of DNS wildcards has been limited 264 to a relatively small number of reasonably well-understood roles, and 265 most wildcard use has been limited to a single role: the MX records 266 used in mail delivery. 268 Since MX records are only used for electronic mail delivery, wildcard 269 MX records are relatively safe, and since electronic mail for any 270 particular DNS name is generally handed by the organization that is 271 furthest down the delegation tree, wildcard MX records are most 272 likely to appear in zones where their effects will not cross 273 organizational boundaries. While the latter is not universally true, 274 the primary use of wildcard records has been and remains wildcard MX 275 records for handling an organization's own mail. 277 Given these issues, it seems clear that the use of wildcards with 278 record types that affect more than one protocol should be approached 279 with caution, that the use of wildcards in situations where their 280 effects cross organizational boundaries should also be approached 281 with caution, and that the use of wildcards with record types that 282 affect more than one protocol in situations where the effects cross 283 organizational boundaries should be approached with extreme caution, 284 if at all. 286 2.2. Problems specific to synthesis by middleboxes 288 While the wildcard synthesis is specified as part of the DNS protocol 289 the synthesis by recursive nameservers, proxies and other middle- 290 boxes interacts badly with the protocol itself. 292 The ultimate client of the DNS information are applications in need 293 for a resources tied to a given name. Usually those application use 294 so called stub resolvers to make that resource available through a 295 call to an OS supplied library. The stub resolver connects to a 296 recursive name server that will resolve the answer by querying the 297 authoritative name servers. The recursive nameserver is usually 298 deployed in location so that a large number of stub resolvers make 299 use of it (e.g. a by an ISP) and maintains a cache to decrease 300 response times for subsequent queries. In the path between the stub 301 resolver and the recursive nameserver there can be any number of 302 forwarding nameservers, or DNS proxies. 304 The DNS protocol has been designed around the assumption that the 305 authoritative data records supplied by the authoritative server in 306 response to a query is delivered to the application unmodified. In 307 that sense the authoritative server is one end, and the stub resolver 308 is the other end of the DNS end-to-end connection and there exists a 309 clean line of sight between them. Extensions to the DNS are designed 310 with this principle in mind. 312 In particular DNSSEC has been designed to allow validation of DNSSEC 313 by the stub resolver, or a similar component in the client operating 314 system. Any modification by middle-boxes to DNS resource records may 315 therefore cause validation failures. 317 In addition to this architectural issue the synthesis by middle-boxes 318 triggers the same problems that have been encountered recently with 319 the deployment of wildcards at high levels in the DNS tree. 321 3. Principles To Keep In Mind 323 In reading the rest of this document, it may be helpful to bear in 324 mind two basic principles of architectural design which have served 325 the Internet well for many years: 327 The Robustness Principle: "Be conservative in what you do, be 328 liberal in what you accept from others." (Jon Postel, [RFC0793]) 330 The Principle Of Least Astonishment: A program should always respond 331 in the way that is least likely to astonish the user. 332 [Traditional, original source unknown] 334 We will come back to these points after the next section. 336 4. Problems encountered in recent experiences with wildcards 338 In September 2003 we had the opportunity to observe the results of 339 the introduction of the use of wildcards in large and well- 340 established top-level domains, with some rather undesirable and 341 unintended consequences. This section attempts to detail some of the 342 problems that network users and operators around the world 343 encountered as a result of this deployment of wildcards in the TLD. 344 End-user applications are not able to assess where the synthesis took 345 place, hence the discussion of the problems encountered during the 346 deployment of the wildcard directly applies to synthesis by middle- 347 boxes as well. 349 While, technically, the synthesis in middle-boxes violates the 350 specifications, we must emphasize that deployment of wildcards in any 351 kind of zone, including a TLD zone, is not such violation. One of 352 our main points here is that simply complying with the letter of the 353 protocol specification is not sufficient to ensure the operational 354 stability of the applications which depend on the DNS: there are 355 protocol features which simply are not safe to use in some 356 circumstances. 358 The specific change which this operator chose to make was to add a 359 single wildcard address record at the zone apex of each of the 360 affected zones. As a direct result of this change, two things 361 happened: 363 o the authoritative servers for these two zones no longer give out 364 "no such name" responses for any possible name in these zones, and 366 o every possible name rooted in one of these zones, which did not 367 exist at all until this change, now has a synthesized address 368 record pointing at a "redirection server" run by the operator of 369 this zone. 371 The implications of this simple change were many and varied. The 372 list below is almost certainly incomplete: 374 4.1. Web Browsing 376 Web browsers all over the world stopped displaying "page not found" 377 in the local language and character set of the users when given 378 incorrect URLs rooted under these TLDs. Instead, these browsers now 379 display an English language search page from a web server run by the 380 zone operator. 382 It should be noted that the language tags in the HTTP protocol do not 383 always match the locale used in the local browser. So, even though 384 the global search page is dynamic and uses the information in the 385 HTTP request to guess what language and script is to be used -- it 386 will never be able to emulate what the user expected. There is, in 387 short, not enough context in the HTTP protocol for the engine which 388 generates the search page. 390 In many situations, web browsers have been written to provide some 391 assistance to the user, often based on local conventions, 392 directories, and language, when a DNS lookup fails. All such systems 393 are now disabled for the URLs rooted under these TLDs, since DNS 394 lookups no longer fail, even when the specified destination does not 395 exist. 397 In addition, the new mechanism has poor scaling properties, and 398 unless the operator chooses to invest significant resources in 399 maintaining a large, robust web server setup, the user experience is 400 going to get even worse: instead of either a local language error 401 message or an English search page, the user is going to get 402 "attempting to connect..." followed by a long wait. 404 In the case of synthesis by middle-boxes the scalability, and the 405 locality are arguably less significant issues. However one cannot 406 always assume that all users behind a middle-box use the same locale. 408 4.2. Email 410 When a wildcard is being deployed at the TLD level all mail to non- 411 existent host names under these TLDs now flows to the registry 412 operator's server, where the registry operator bounces it. Some 413 operators find this intolerable and might change their mail system 414 configurations to bypass this "bounce service", but the vast majority 415 of mail servers undoubtedly now route mail for nonexistent names 416 under these TLDs to the bounce server rather than just bouncing it 417 directly. This has a number of ramifications: 419 If operators choose to allow their mail to go to the bounce server, 420 they now have an increased mail load handling additional routing of 421 messages to the bounce server; if operators choose not to allow this 422 to happen, they have an additional development and maintenance burden 423 configuring their servers to prevent it. 425 Operators who allow mail to go to the bounce server are now dependent 426 on the performance of the bounce server. If the bounce server ever 427 slows or fails, mail that previously would bounce will now queue at 428 the SMTP relay for that relay's queue time before bouncing back to 429 the user. This creates a very poor user experience, since 430 typographical errors that in the past would have bounced immediately 431 may now go unnoticed for several days. 433 Operators who allow mail to go to the bounce server are also 434 dependent on the correct operation of the bounce server. If the 435 bounce server is buggy (which happened to be the case with this roll- 436 out), mail may not bounce at all: it may be reported to the user as 437 having been delivered correctly while actually vanishing without a 438 trace. This also creates a very poor user experience. 440 In some cases where the set of MX records associated with a 441 particular DNS name included a misconfigured record pointing to a 442 nonexistent host name, installing these wildcard records was the last 443 straw that broke a misconfigured-but-functional mail configuration: 444 previously, the nonexistent host name would have failed to resolve 445 and been ignored, now it bounces. 447 The normal flow of data from a client in SMTP when one address has a 448 typo is as follows: 450 o The client looks up the IP address of its outgoing SMTP proxy in 451 DNS. 453 o The client opens a TCP connection to its outgoing SMTP proxy. 455 o The client sends information about itself to the SMTP proxy. 457 o The proxy accepts or rejects the client. 459 o The client sends information about the recipient to the SMTP 460 proxy. 462 o The proxy looks up the destination in DNS, and gets "no such name" 463 back. 465 o The proxy sends information to the client that the address is 466 wrong. 468 With a wildcard for mistyped domain, the following happens: 470 o The client looks up the IP address of its outgoing SMTP proxy in 471 DNS. 473 o The client opens a TCP connection to its outgoing SMTP proxy. 475 o The client sends information about itself to the SMTP proxy. 477 o The proxy accepts or rejects the client. 479 o The client sends information about the recipient to the SMTP 480 proxy. 482 o The proxy looks up the destination in DNS, and gets "success" 483 back. 485 o The proxy accepts the message and closes the connection to the 486 client. 488 o The proxy opens a TCP connection to the bounce server. 490 o The proxy present itself to the bounce server. 492 o The bounce server indicates that the recipient address is not 493 acceptable. 495 o The proxy generates an error message which is sent back to the 496 sender's email address. 498 A different scenario happens if the SMTP client has been 499 misconfigured with the incorrect name of the outgoing SMTP proxy. As 500 the domain name resolves using a wildcard, the client will connect to 501 the bounce server, and start to send mail to it. The result is that 502 the bounce server (at the IP address of the wildcard) says that the 503 recipient address is wrong even though it is in fact correct. The 504 error presented to the user is incorrect, as it is the name of the 505 outgoing proxy which was wrong and not the name of the recipient. 507 Above we have assumed that the mailserver deployed by the TLD server 508 has been configured to bounce the mails. When such server were to be 509 configured to accept mails the privacy issues are obvious. While the 510 deployment of wildcards in a TLD zone can be 'audited' by many 511 Internet users, synthesis by middle-boxes is typically something that 512 only affects the users behind that middle-box. Therefore there is a 513 real risk that (malicious) misconfiguration will go unnoticed and 514 that mail is routed to places where the user did not intend to send 515 it to. 517 4.3. Informing Users of Errors 519 Many application GUIs check domain names for validity before allowing 520 the user to progress to the next step. Examples include email 521 clients that directly check the domain of the email addresses 522 resolves before sending, and network printer configuration tools that 523 check that the print spooler name is valid before accepting the 524 configuration. Previously the user would be prompted early that they 525 had made an error in the domain name. In the case of email, the 526 error may now remain unnoticed at the time of sending, till when 527 email bounces back later. In the case of the printer configuration, 528 the error may not be noticed during configuration, but only 529 afterwards when printing fails to work, where the problem diagnosis 530 is more difficult. 532 4.4. Spam Filters 534 Installing these wildcard records broke several simple spam filters 535 commonly used to front end inbound mail servers, as well as more 536 complex filtering that checks for the existence of a sending domain 537 in order to screen out obviously bogus senders. This technique for 538 spam has diminished as this filtering mechanism has increased, but 539 one sample operator reports that it still equals about 10% of inbound 540 mail attempts on their large shared MX cluster. ISPs who are aware 541 of this problem will probably extend their filtering rules to have 542 special knowledge of the address returned by these wildcard records, 543 but will have to carry the cost of doing so, both in terms of code 544 maintenance and increased execution time for their filtering. 546 4.5. Interactions with Other Protocols 548 The wildcard address records trap DNS lookups for any network 549 service, but the number of protocols somewhere in use on the Internet 550 (including private protocols used between two or more parties on 551 ports which they may or may not have registered with IANA) is large 552 enough that it simply is not possible for the zone operator who traps 553 the DNS loolups using wildcards (or anyone) to provide a redirection 554 service for every protocol. In a recent deployment of a wildcard in 555 a TLD zone, the zone operator only provided handlers for HTTP (which 556 they directed to a search page) and SMTP (which they attempted to 557 bounce). All other protocols received at best ICMP port unreachable 558 message, or, in some cases, simply had their packets dropped. Any 559 application that uses the DNS has (or should have) some way of 560 handling "no such name" errors; in almost all cases the error message 561 is sufficiently clear to an experienced user that it is immediately 562 obvious when the application has failed because it was given an 563 incorrect DNS name. With these wildcard records in place, however, 564 incorrect DNS names which are matched by the wildcard record will not 565 show up as DNS name errors at all, but instead will show up as 566 mysterious connection failures or as unreachable destinations for all 567 services that the zone operator does not redirect. Depending on the 568 details of the application protocol and implementation involved, this 569 change may also convert an obvious "hard failure" (incorrect name) 570 into a soft failure which the application thinks it should retry, as 571 seen above in the email case. This may result in very long delays, 572 perhaps of days or weeks, before even trivial errors are brought to 573 the user's attention. Transport protocols using UDP may also retry 574 until the transport protocol retry limit is reached (especially if 575 ICMP messages are being filtered at a firewall), which may be very 576 considerably longer than the time it would have taken to return an 577 error to the user indicating they mistyped the destination. 579 4.6. Automated Tools 581 Automated or embedded tools which use HTTP but which do not have a 582 user interface may also be confused by this change, since such tools 583 may expect configuration failures to show up as DNS errors and may 584 not realize that the HTTP response they have received from the zone 585 operator's search page is not the page which the tool expected to 586 reach. Such tools may fail in unpredictable ways, and may not be 587 easy to repair. 589 4.7. Charging 591 The current response from the service in question is just over 17 592 KBytes of data because the client has to open a TCP connection and 593 receive a not insignificant amount of data. A "no such data" 594 response would have fitted in one packet. In the case of volume- 595 based charging for Internet Access (as with most cellular data 596 services) the recipient will have to pay additional charges. 598 4.8. Single Point of Failure 600 Even for cases in which the redirection service works as intended, 601 such a service creates a very large single point of failure. Single 602 points of failure are obvious targets both for deliberate attacks and 603 for the sort of accidental "attacks" caused by bugs and configuration 604 errors which already generate much of the traffic at the DNS name 605 servers for the root zone. Furthermore, the IP address associated 606 with this single point of failure is a likely target both for routing 607 attacks intended to redirect the IP address to some other server. 609 4.8.1. Privacy 611 An interception service with this kind of scope raises significant 612 privacy concerns, since traffic received by the interception service 613 is, pretty much by definition, not going where its sender originally 614 intended. The potential for abuse in this situation is very high. 615 The mail received on the interception service can be parsed and saved 616 which makes the interception service an even more attractive target, 617 this time for attackers who wish to gain control of it in order to 618 practice such abuse. 620 4.8.2. Reserved Names 622 This sort of wildcard usage is incompatible with any use of DNS which 623 relies on reserving names in a registry with the express intent of 624 not adding them to the DNS zone itself. An example of such a use is 625 the JET-derived IDN approach of "registry restrictions" and "reserved 626 names", which depends on the existence of names that are reserved and 627 can be registered only by the holder of some related name, but which 628 do not appear in the DNS. By some readings of the current ICANN IDN 629 policy, support for that "reserved name" approach is required. To 630 accomplish the goal of reduced consumer confusion, the reserved names 631 must not be resolvable at all. This reserved name approach appears 632 to be completely incompatible with this sort of wildcard usage: since 633 the wildcard will always cause a result to be returned, even for a 634 reserved name which does not appear in the zone, one can support 635 either one or the other, but not both. 637 5. Undesirable Workarounds 639 ISPs have responded to the deployment of these wildcards in a number 640 of ways, all of which are both understandable and worrisome. Some 641 ISPs have contemplated modifying their routing systems to drop all 642 packets destined to the zone operator's redirection server into a 643 black hole. Others have deployed patches to their DNS resolvers 644 which attempt to reverse the effects of these wildcard records. 645 Still other ISPs have considered using this as an opportunity to play 646 the same game that the zone operator is playing, but for the ISP's 647 own benefit. All of these responses are both understandable and 648 predictable, but none of them are good. Even more worrisome is that 649 different ISPs have been taking different approaches to dealing the 650 unwanted effects of deployed wildcards, which may lead to a 651 balkanization problem and create an ongoing headache for anyone 652 having to deal with cross-network DNS or application debugging. 654 Since ISPs often control the middle-boxes there may not be many ways 655 for the end users to workaround the problem. Users may want to fall 656 back to alternative recursive forwarders but if transparent proxying 657 takes place and or traffic to alternative servers is blocked the 658 users have no choice than to accept the fact that they receive the 659 synthesized data from their ISP. In response to this software 660 developers may start to offer non-standard counter measures such as 661 the tunneling of DNS traffic over secured HTTP connections. 663 6. Principles, Conclusions, and Recommendations 665 The Robustness principle tells us that in some (not all) of the 666 problems detailed above, both parties could be construed as being at 667 fault. In some cases this is hardly surprising: spam filtering in 668 particular, by its nature, tends to be extremely ad hoc and somewhat 669 fragile. No doubt there are lessons here for all parties involved. 671 The Principle of Least Astonishment suggests that the deployment of 672 wildcards in the case described above was disastrous for the users. 674 It had widesweeping effects on other users of the Internet far beyond 675 those enumerated by the zone operator, created several brand new 676 problems, and caused other internet entities to make hasty, possibly 677 mutually incompatible and possibly deleterious (to the internet as a 678 whole) changes to their own operations in an attempt to react to the 679 change. 681 6.1. Recomendations concerning deployment of wildcards 683 Note that these considerations apply to any wildcard deployment of 684 this type. The list of problems encountered in this case clearly 685 demonstrates that, although wildcard records are part of the base DNS 686 protocol, there are situations in which it simply is not safe to use 687 them. As noted in an earlier section, two warning flags suggesting 688 that this type of wildcard deployment is dangerous were that it 689 affected more than one protocol, and it was done high enough up in 690 the DNS hierarchy that its effects were not limited to the 691 organization that chose to deploy these wildcard records. 693 Note also that a significant component of some of the listed problems 694 was not precisely the wildcard-induced behavior per se so much as it 695 was the abrupt change in the behavior of a long established 696 infrastructure mechanism. In conclusion, we would like to propose a 697 guideline for when wildcard records should be considered too risky to 698 deploy, and make a few recommendations on how to proceed from here. 700 Proposed guideline: If you want to use wildcards in your zone and 701 understand the risks, go ahead, but only do so with the informed 702 consent of the entities that are delegated within your zone e.g. in 703 those cases where there is a clear organisational dependency and 704 inter-linkage between parent and child zone. 706 Generally, we do not recommend the use of wildcards for record types 707 that affect more than one application protocol. At the present time, 708 the only record types that do not affect more than one application 709 protocol are MX records. 711 For zones that do delegations, we do not recommend even wildcard MX 712 records. If they are used, the owners of zones delegated from that 713 zone must be made aware of that policy and must be given assistance 714 to ensure appropriate behavior for MX names within the delegated 715 zone. In other words, the parent zone operator must not reroute mail 716 destined for the child zone without the child zone's permission. 718 We hesitate to recommend a flat prohibition against wildcards in 719 "registry"-class zones, but strongly suggest that the burden of proof 720 in such cases should be on the registry to demonstrate that their 721 intended use of wildcards will not pose a threat to stable operation 722 of the DNS or predictable behavior for applications and users. 724 We recommend that any and all TLDs which use wildcards in a manner 725 inconsistent with this guideline remove such wildcards at the 726 earliest opportunity. 728 6.2. Recomendations against the synthesis by middleboxes 730 As for the synthesis by middle-boxes the arguments are similar as the 731 arguments for wildcard deployment, but the amount of users affected 732 by the implementation is much smaller. On the other hand, this 733 method of synthesis is not part of the DNS specification and violates 734 architectural assumptions of 'clean light of sight' on which 735 extensions to the DNS protocol are developed against. 737 We therefore strongly recommend against the use of this kind of 738 synthesis. If an ISP or an other organization tries to offer 739 synthesis by middle-boxes as a service the should also offer 740 customers a DNS recursive forwarder that provides a clean line of 741 sight to the authoritative data. It is not sufficient to provide 742 opt-out mechanism that are purely web based since other applications 743 may still encounter problems. 745 7. References 747 7.1. Normative References 749 7.2. Informative References 751 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 752 RFC 793, September 1981. 754 [RFC2219] Hamilton, M. and R. Wright, "Use of DNS Aliases for 755 Network Services", BCP 17, RFC 2219, October 1997. 757 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 758 June 1999. 760 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 761 specifying the location of services (DNS SRV)", RFC 2782, 762 February 2000. 764 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 765 Rose, "Resource Records for the DNS Security Extensions", 766 RFC 4034, March 2005. 768 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 769 System", RFC 4592, July 2006. 771 [IAB-wildcard-commentary] 772 Internet Architecture Board, "IAB Commentary: 773 Architectural Concerns on the use of DNS Wildcards", 774 September 2003. 776 Appendix A. Acknowledgements 778 This document is based on a commentary that was published on the IAB 779 website[IAB-wildcard-commentary]. 781 The IAB acknowledges the kind assistance of David Schairer, John 782 Curran, John Klensin, and Steve Bellovin for helpful suggestions and, 783 in some cases, significant chunks of text for the original 784 commentary. 786 In addition the IAB also acknowledges .... for their contribution 787 during the production of this document. 789 None of these contributors bear any responsibility for what the IAB 790 has done with their contributions. 792 This document was produced using the xml2rfc tool[RFC2629]. 794 Appendix B. Document Editing Details 796 [To Be Removed after publication] 798 File with Revision ID 24 was the original conversion from 799 http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html 801 File with Revision ID 27 got the synthesis by middle-boxes added and 802 therefore the text was rearranged. 804 This is $Id: iab-synthesis.xml 35 2007-04-16 11:35:05Z olaf $ 806 Author's Address 808 Olaf M. Kolkman (editor) 809 IAB 811 Full Copyright Statement 813 Copyright (C) The IETF Trust (2007). 815 This document is subject to the rights, licenses and restrictions 816 contained in BCP 78, and except as set forth therein, the authors 817 retain all their rights. 819 This document and the information contained herein are provided on an 820 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 821 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 822 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 823 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 824 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 825 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 827 Intellectual Property 829 The IETF takes no position regarding the validity or scope of any 830 Intellectual Property Rights or other rights that might be claimed to 831 pertain to the implementation or use of the technology described in 832 this document or the extent to which any license under such rights 833 might or might not be available; nor does it represent that it has 834 made any independent effort to identify any such rights. Information 835 on the procedures with respect to rights in RFC documents can be 836 found in BCP 78 and BCP 79. 838 Copies of IPR disclosures made to the IETF Secretariat and any 839 assurances of licenses to be made available, or the result of an 840 attempt made to obtain a general license or permission for the use of 841 such proprietary rights by implementers or users of this 842 specification can be obtained from the IETF on-line IPR repository at 843 http://www.ietf.org/ipr. 845 The IETF invites any interested party to bring to its attention any 846 copyrights, patents or patent applications, or other proprietary 847 rights that may cover technology that may be required to implement 848 this standard. Please address the information to the IETF at 849 ietf-ipr@ietf.org. 851 Acknowledgment 853 Funding for the RFC Editor function is provided by the IETF 854 Administrative Support Activity (IASA).