idnits 2.17.1 draft-myers-mail-largesite-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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.) ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([XXXREF]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 119: '... There SHOULD be from three to six M...' RFC 2119 keyword, line 120: '... domain. There SHOULD be at most two...' RFC 2119 keyword, line 124: '...weights. A site MUST NOT have more th...' RFC 2119 keyword, line 127: '...e in a MX record SHOULD have exactly o...' RFC 2119 keyword, line 134: '... A site MUST NOT have more than five...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (December 1996) is 9994 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) -- Missing reference section? 'XXXREF' on line 251 looks like a reference -- Missing reference section? 'HOST-REQ' on line 255 looks like a reference -- Missing reference section? 'DNS-MX' on line 253 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Myers 3 Internet Draft Carnegie Mellon 4 Document: draft-myers-mail-largesite-00.txt December 1996 6 DNS MX Record Deployment for Large Mail Sites 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a 19 ``working draft'' or ``work in progress``. 21 To learn the current status of any Internet-Draft, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 24 munnari.oz.au. 26 A revised version of this draft document will be submitted to the RFC 27 editor as a Best Current Practice for the Internet Community. 28 Discussion and suggestions for improvement are requested. This 29 document will expire six months from date of issue. Distribution of 30 this draft is unlimited. 32 Abstract 34 Domains which recieve a large number of incoming mail messages have a 35 need to distribute incoming requests over a large number of SMTP 36 servers. The most obvious method for advertising DNS records these 37 SMTP servers leads to undesirable behavior when certain network 38 failures occur. For example, on XXXX, 1996 [XXXREF] a single routing 39 failure at a large site led to the catastrophic failure of a large 40 portion of mail systems on the Internet. This document gives 41 recommendations for how large sites should advertise DNS records for 42 their SMTP servers to avoid these problems and for how SMTP client 43 implementations should insulate themselves against large sites which 44 do not follow these recommendations. 46 Internet DRAFT MX Record Deployment 16 December 1996 48 1. The wrong way for large sites to advertise SMTP servers 50 The most obvious method for a large site to advertise DNS records for 51 its SMTP servers is to advertise some number of equal-weighted MX 52 records for the domain, where each host name in an MX record has 53 multiple A records. Each of the multiple A records contains the IP 54 address of one of the SMTP servers. 56 For example, a site might have the following MX records: 58 bigsite.com. 30491 MX 10 a.mx.bigsite.com. 59 bigsite.com. 30491 MX 10 b.mx.bigsite.com. 60 bigsite.com. 30491 MX 10 c.mx.bigsite.com. 61 bigsite..com. 30491 MX 10 d.mx.bigsite.com. 62 bigsite.com. 30491 MX 10 e.mx.bigsite.com. 63 bigsite.com. 30491 MX 10 f.mx.bigsite.com. 64 bigsite.com. 30491 MX 10 g.mx.bigsite.com. 65 bigsite.com. 30491 MX 10 h.mx.bigsite.com. 66 bigsite.com. 30491 MX 10 i.mx.bigsite.com. 68 Each host name mentioned in in one of the above MX records could have 69 A records like: 71 a.mx.bigsite.com. 5806 A 10.2.94.14 72 a.mx.bigsite.com. 5806 A 10.2.94.35 73 a.mx.bigsite.com. 5806 A 10.2.94.36 74 a.mx.bigsite.com. 5806 A 10.2.94.30 75 a.mx.bigsite.com. 5806 A 10.2.94.11 77 b.mx.bigsite.com. 5779 A 10.2.94.34 78 b.mx.bigsite.com. 5779 A 10.2.94.37 79 b.mx.bigsite.com. 5779 A 10.2.94.47 80 b.mx.bigsite.com. 5779 A 10.2.94.33 81 b.mx.bigsite.com. 5779 A 10.2.94.13 83 (and so on.) 85 The reason large sites use MX records containing host names which 86 have multiple A records instead of simply using one MX record for 87 each SMTP server is because the resulting set of MX records would be 88 too large for a DNS server to return all of them in a single UDP 89 packet. 91 This method of advertising DNS records for SMTP servers leads to 92 extremely undesirable behavior of SMTP clients in the face of certain 93 network problems. The fail-over semantics of multiple A records for 94 a host name are the exact opposite than are desired for mail 95 delivery. If an SMTP client gets a "connection refused" error or 4xx 97 Internet DRAFT MX Record Deployment 16 December 1996 99 greeting when attempting to contact the host b.mx.bigsite.com at 100 address 10.2.94.34, it knows that the "multihomed host" 101 b.mx.bigsite.com is not available and may fail over to the next MX 102 record. In this case, the IP addresses for the other A records are 103 not attempted. 105 If, on the other hand, the SMTP client recieves no response to 106 connection attempts to 10.2.94.34, it will time out and then attempt 107 to connect to 10.2.94.37 and so on. If there is a routing failure 108 which causes all packets either into or out of the big site's network 109 to be dropped, the SMTP client will in this example have to time out 110 a total of 45 times. At two minutes per timeout, this means the SMTP 111 client must wait a total of an hour and a half before it can give up 112 the delivery attempt. 114 2. Recommendations for large sites 116 In order to reduce the impact of network failures on SMTP clients, 117 large sites should advertise their SMTP servers as follows: 119 There SHOULD be from three to six MX records for each recieving mail 120 domain. There SHOULD be at most two different weights used amongst 121 the MX records for a domain, in order to allow SMTP clients to 122 randomly select their sorting per [HOST-REQ] 5.3.4(1). If all of the 123 SMTP servers are identically configured, it is preferred that all of 124 the MX records have equal weights. A site MUST NOT have more than 125 ten MX records for a given domain. 127 Each host name in a MX record SHOULD have exactly one A record. If 128 one or more MX records have multiple A records, each A record after 129 the first counts as an additional MX record with respect to the 130 limits stated in the previous paragraph. (Put another way, the 131 limits in the previous paragraph apply to the total number of A 132 records which are pointed to by the set of MX records for a domain.) 134 A site MUST NOT have more than five A records for a host name in an 135 MX record. Older resolver libraries do not deal correctly with six 136 or more A records per host name. 138 There are two suggestions for load-balancing amongst a pool of SMTP 139 servers larger than the number of MX records. Neither alternative is 140 preferred. 142 2.1. First alternative 144 Each host name pointed to by a MX record is in a zone served by a 145 load-balancing name server. For each appropriate query, this load- 146 balancing name server returns a single A record containing an address 148 Internet DRAFT MX Record Deployment 16 December 1996 150 selected from a pool of SMTP servers. To comply with the 151 requirements of the DNS protocol, each time the name server is 152 queried for the SOA record for the zone, the record it returns MUST 153 contain a different serial number. 155 The TTL for the returned A records SHOULD be non-zero. Returning 156 zero TTLs is likely to cause the load-balancing name server to be 157 innundated with queries. For sites large enough to need more than 158 six SMTP servers, it is most likely not going to be a problem when a 159 name server for any other domain caches one of these A records. 160 There will be enough different sending sites using different caching 161 name servers to keep the load from getting two uneven. Even when a 162 large sending site caches a set of A records, the multiple equal- 163 weighted MX records will cause some distribution of load across the 164 set of SMTP servers cached on the SMTP client's name server. 166 2.2. Second alternative 168 Each host name pointed to by a MX record has an A record with the 169 address of a proxy host or Network Address Translation router. Each 170 proxy host or NAT router then proxies/routes each SMTP connection to 171 an SMTP server selected from the pool. 173 3. Recommendations for SMTP client implementations 175 The second paragraph of section 5.3.1.1 of [HOST-REQ] states: 177 The sender MUST delay retrying a particular destination 178 after one attempt has failed. In general, the retry 179 interval SHOULD be at least 30 minutes; however, more 180 sophisticated and variable strategies will be beneficial 181 when the sender-SMTP can determine the reason for non- 182 delivery. 184 Implementing this directive is extremely important in order to avoid 185 tying up all resources attempting to deliver mulitple messages to a 186 domain with unresponsive SMTP servers. Implementing this directive 187 is not, however, sufficient to avoid the problem mentioned in section 188 1 of this document, since a delivery attempt time on the order of 90 189 minutes will completely overshadow a retry interval on the order of 190 30 minutes. 192 [DNS-MX] permits SMTP clients to have a fixed limit on the number of 193 MX records that are tried. [HOST-REQ] 5.3.4 extends this to permit a 194 configurable limit on the number of alternate addresses that can be 195 tried, further stating a host SHOULD try at least two addresses. 197 SMTP client implementations need to limit the amount of time they 199 Internet DRAFT MX Record Deployment 16 December 1996 201 spend attempting to connect to a server for a given mail domain. 202 This document gives two suggestions for doing this, an SMTP client 203 SHOULD implement one of the two following alternatives. The second 204 alternative is preferred. 206 3.1. First alternative 208 SMTP implementations following this alternative have a configurable 209 limit on the maximum number of connection attempts it makes across 210 all MX records for a domain. This limit SHOULD be at least two and 211 SHOULD have a default value no larger than 6. 213 At two minutes per timeout, this translates to a maximum of about 12 214 minutes per delivery attempt to a domain. 216 3.2. Second alternative 218 SMTP implementations following this alternative have a configurable 219 limit on the total amount of time it spends attempting to make a 220 connection to some MX server for a domain. After this time limit 221 expires, the SMTP client will attempt no new connections during that 222 delivery attempt. The default vaulue for this limit SHOULD be no 223 more than 10 minutes. 225 4. Security Considerations 227 Section 3 gives recommendations for SMTP client implementations to 228 insulate themselves against catastrophic denial of service due to a 229 known problem caused by a remote site having a combination of poor 230 DNS configuration and a particular type of network failure. 232 Otherwise, there are no known security considerations with this memo. 234 5. Author's Address 236 John G. Myers 237 Carnegie-Mellon University 238 5000 Forbes Ave. 239 Pittsburgh PA, 15213-3890 241 Email: jgm+@cmu.edu 243 Appendix A: lbnamed 245 XXX-todo 247 Internet DRAFT MX Record Deployment 16 December 1996 249 Appendix B: References 251 [XXXREF] some news article on the AOL failure 253 [DNS-MX] Partridge, C., "Mail routing and the domain system", RFC 974 255 [HOST-REQ] Braden, R., "Requirements for Internet hosts - application 256 and support", RFC 1123 258 Internet DRAFT MX Record Deployment 16 December 1996 260 TTaabbllee ooff CCoonntteennttss 262 Status of this Memo ............................................... i 263 Abstract .......................................................... i 264 1. The wrong way for large sites to advertise SMTP servers ...... 2 265 2. Recommendations for large sites .............................. 3 266 2.1. First alternative ............................................ 3 267 2.2. Second alternative ........................................... 4 268 3. Recommendations for SMTP client implementations .............. 4 269 3.1. First alternative ............................................ 5 270 3.2. Second alternative ........................................... 5 271 4. Security Considerations ...................................... 5 272 5. Author's Address ............................................. 5 273 Appendix A: lbnamed ............................................... 5 274 Appendix B: References ............................................ 6