idnits 2.17.1 draft-ietf-dnsop-dontpublish-unreachable-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 401 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([RFC1918]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 213 has weird spacing: '...e is an incre...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (September 2001) is 8259 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Philip Hazel 2 draft-ietf-dnsop-dontpublish-unreachable-01.txt University of Cambridge 3 Valid for six months September 2001 4 Category: Best Current Practice 6 IP Addresses that should never appear in the public DNS 8 Copyright (C) The Internet Society (2001). All Rights Reserved. 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document specifies an Internet Best Current Practice for the 34 Internet Community. It has two themes. Firstly, it reinforces the 35 prohibition in [RFC 1918] about the appearance of private IP 36 addresses in publicly visible DNS records. Secondly, the document 37 discusses the problems that can be caused by the appearance of public 38 addresses, or indirect references to them, when the service implied 39 by the address or reference is inaccessible from the public Internet. 40 Specifying a blanket prohibition in the second case is difficult 41 because inaccessibility may arise from many causes, some possibly 42 legitimate. Instead, the document points out some of the problems 43 that can arise, and suggests that other means of achieving the 44 desired effects should be used wherever possible. 46 1. Introduction 48 The increasing use of firewalls, NAT boxes, and similar technology 49 has resulted in the fragmentation of the Internet into regions whose 50 boundaries do not allow general connectivity. There are two primary 51 reasons for this: 53 (1) The perceived shortage of IPv4 addresses has caused increasing 54 use of private IP network addresses such as 10.0.0.0/8 on LANs. A 55 number of such private address ranges are designated in [RFC 1918], 56 and others may be also assigned by IANA. 58 [Note: For example, there's 169.254/16, which is mentioned in 59 draft-ietf-zeroconf-ipv4-linklocal-04.txt, but since that's still a 60 draft, I can't cite it.] 62 Hosts using private addresses that wish to communicate with the 63 public Internet must do so via an address translation mechanism such 64 as a NAT box. This allows a host with a private address to send 65 packets to public Internet hosts, and to receive replies. However, 66 unsolicited incoming packets cannot reach these hosts from outside 67 their own private network. 69 (2) Increasing security concerns have caused many sites to install 70 firewalls or to implement restrictions in their boundary routers in 71 order to lock out certain kinds of connection to their hosts, even 72 when the hosts are using public Internet addresses, though in many 73 cases firewalls also provide NAT functionality. 75 Thus, there are two classes of host which some or all types of 76 unexpected incoming packet from the public Internet cannot reach. 78 A number of instances have been observed where IP addresses that are 79 never accessible from the public Internet have nevertheless been 80 inserted into resource records in the public DNS. This document seeks 81 to prohibit such behaviour in the case of truly private addresses, 82 and to discourage it in the case of public, but unreachable, 83 addresses. 85 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC 2119]. 89 The phrase "address record" means an A record or an AAAA record, or 90 any other kind of name-to-address record that may come into use. 92 2. Private network addresses 94 Examples of [RFC 1918] private host addresses are 10.0.0.1 and 95 172.16.42.53. Packets cannot be routed to such addresses from the 96 public Internet. [RFC 1918] explains this in section 3, from where 97 this paragraph is taken: 99 Because private addresses have no global meaning, routing 100 information about private networks shall not be propagated on 101 inter-enterprise links, and packets with private source or 102 destination addresses should not be forwarded across such links. 103 Routers in networks not using private address space, especially 104 those of Internet service providers, are expected to be 105 configured to reject (filter out) routing information about 106 private networks. 108 Because the same private addresses are in use in many different 109 organizations, they are ambiguous. The appearance of private 110 addresses in the DNS could therefore lead to unpredictable and 111 unwanted behaviour. Consider this set of entries: 113 @ IN MX 10 smtp 114 smtp IN A 10.1.2.3 115 smtp IN A 1.2.3.4 117 Zones set up in this way have been seen, and some administrators 118 apparently believe this is useful, because it allows mail on their 119 local network to be delivered straight to the internal server (the 120 one with address 10.1.2.3). However, it all breaks down when a host 121 on a foreign network that is also using the address 10.1.2.3 122 attempts to send mail to the domain. 124 In section 5 of [RFC 1918] there is a prohibition of the appearance of 125 private addresses in publicly visible DNS records. It says: 127 If an enterprise uses the private address space, or a mix of 128 private and public address spaces, then DNS clients outside of 129 the enterprise should not see addresses in the private address 130 space used by the enterprise, since these addresses would be 131 ambiguous. 133 The wording "should not" is not a very strong prohibition, 134 considering the interworking problems that ignoring it can cause. 135 Therefore, this document makes a stronger statement: 137 Public DNS zones MUST NOT contain [RFC 1918] addresses, or any other 138 addresses designated by IANA as private, in any resource records. 140 3. Public network addresses that are inacessible 142 The situation with public network addresses is more complicated 143 because the Internet cannot in general be cleanly divided into 144 "public" and "private" parts in this case. Examples of situations 145 where the division is fuzzy are: 147 (1) A host with a public address that is behind a firewall 148 may be accessible for SSH sessions, but not for SMTP sessions. That 149 is, the blocking may apply only to certain ports. 151 (2) A host with a public address may make certain services available 152 only to specific client hosts, for example, those in partner 153 enterprises. 155 (3) A host might respond to incoming packets only if the client host 156 is using IPsec. 158 When a host is providing any service at all over the public Internet, 159 a publicly visible address record is of course required to give 160 access to the host. 162 However, for some protocols and services, additional DNS records 163 are defined that reference hosts' address records. These are the MX 164 record for SMTP, and the SRV record for other services. The existence 165 of such indirect records advertises the availability of the relevant 166 service. 168 If these services are always inaccessible over the public Internet, 169 it is bad practice to include the MX or SRV records in public DNS 170 zones, for the following reason: 172 A host that tries to connect to an unreachable address (or port) 173 may not receive an immediate rejection; in many cases the connection 174 will fail only after a timeout expires. The wasted effort ties up 175 resources on the calling host and the network, possibly for some 176 considerable time (SMTP timeouts, for example, are of the order of 177 minutes). It may also cause a gratuitous slowing down of the 178 application. 180 Furthermore, in the case of dial-up connections, ISDN, or other kinds 181 of usage-based charged network connection, the wasted network 182 resources may cost real money. 184 Public DNS zones SHOULD NOT contain MX or SRV records that point to 185 hosts for which the relevant services are never accessible over the 186 public Internet. In other words, if there is no host that is able to 187 make use of the service using the public Internet, the service SHOULD 188 NOT be publicly advertised. 190 4. Loopback addresses 192 The loopback addresses (127.0.0.1 for IPv4 and ::1 for IPv6) are 193 another form of private address. There has been a practice of including 194 them in DNS zones for two entirely different reasons. 196 4.1 The name "localhost" 198 Some hostmasters include records of this type in their zones: 200 localhost.some.domain.example. A 127.0.0.1 202 The reason for doing this is so that other hosts in the domain 203 that use the DNS for all their name resolution can make use of the 204 unqualified name "localhost". This works because DNS resolvers 205 normally add the local enclosing domain to unqualified names. 207 DNS zones MAY make use of this technique for the name "localhost" 208 only, if it is required in their environment, but SHOULD avoid it 209 if possible. 211 4.2 DNS "black lists" 213 There is an increasingly popular practice of creating "black 214 lists" of misbehaving hosts (for example, open mail relays) in 215 the DNS. The first of these was the "Realtime Blackhole List" 216 (RBL). Such lists make use of addresses in the 127.0.0.0/8 217 network in DNS address records to give information about listed 218 hosts (which are looked up via their inverted IP addresses). 220 Such records are in specific "black list" domains, and are well 221 understood not to be invitations to attempt connections to the 222 addresses they publish. 224 DNS zones MAY continue to make use of this technique. 226 4.3 Other uses of loopback networks 228 Apart from the exceptions mentioned in 4.1 and 4.2 above, the 229 loopback addresses MUST NOT appear in address records in the public 230 DNS. 232 4.4 References to loopback addresses 234 When address records that contain loopback addresses do exist, 235 DNS zones MUST NOT contain indirect records (MX or SRV) that 236 reference them. 238 5. Alternative techniques 240 5.1 Splitting DNS zones 242 A site that is using private addresses may well want to use DNS 243 lookups for address resolution on its hosts. The lazy way approach is 244 simply to put the data into the public DNS zone, as in the example 245 shown in section 2 above. Because this can cause problems for 246 external hosts, this MUST NOT be done. 248 One approach that is commonly taken is to run a so-called "split 249 DNS". Two different authoritative servers are created: one containing 250 all the zone data is accessible only from within the private network. 251 External DNS queries are directed to the second server, which 252 contains a filtered version of the zone, without the private 253 addresses. 255 5.2 SMTP servers behind firewalls 257 The complication of a split DNS is not normally needed if it is only 258 SMTP traffic that is being blocked to a public address on a host 259 behind a firewall. Setting up MX records like this: 261 plc.example. MX 5 mail.plc.example. 262 MX 10 public.plc.example. 264 where both hosts have public IP addresses, but the first is blocked 265 at the firewall, SHOULD NOT be done. Only the publicly accessible 266 host should be used: 268 plc.example. MX 10 public.plc.example. 270 If a split DNS is in use, the host public.plc.example can use the 271 internal version to route the mail onwards. However, most MTAs have 272 configuration facilities to allow for explicit routing of mail, without 273 the need to use a DNS lookup. 275 5.3 Specification of no SMTP service 277 MX records that point to host names whose address records specify the 278 loopback address have been seen in the DNS. This seems to be a 279 misguided attempt to specify "no SMTP service for this domain". 281 If such a facility is required, it SHOULD instead be done by 282 arranging for the hosts in question to return 284 554 No SMTP service here 286 to all SMTP connections. 288 6. Security Considerations 290 This document is not known to create new security issues in the DNS, 291 mail agents, etc. In some sense, it may reduce security exposure by 292 insisting that a site's inappropriate internal data not be exposed. 294 7. IANA Considerations 296 No IANA actions are required by this document. 298 8. Acknowledgements 300 Randy Bush read an early draft of this document and suggested several 301 improvements. 303 Draft 01 has benefitted from comments made by Daniel Senie, John 304 Schnizlein, Robert Elz, Bert Hubert, and Stuart Cheshire. 306 9. Author's Address 308 Philip Hazel 309 University of Cambridge Computing Service 310 New Museums Site, Pembroke Street 311 Cambridge CB2 3QH, England 313 Phone: + 44 1223 334714 314 Email: ph10@cam.ac.uk 316 10. References 318 [RFC 1918] Rekhter, Y. et al "Address allocation for Private 319 Internets", BCP 5, RFC 1918, February 1996. 321 [RFC 2119] Bradner, S."Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, March 1997. 324 11. Changes made during development of this document 326 This section is provided for the convenients of those tracking the 327 document. It will be removed from the final draft. 329 11.1 Changes made to the -00 version 331 . While leaving the MUSTs in for truly private addresses, I've tried 332 to be more "educational" about the case of public addresses that are 333 inaccessible, and backed down to SHOULD in those cases. 335 . I've pointed out the lack of a clear-cut public/private boundary, 336 and tried to make the case for not advertising unavailable services 337 without being so probititive in the wording. This includes using 338 "never accessible" instead of "not accessible". 340 . Changed "hostmaster" to "zone" in a couple of cases. 342 . Included an example of bad MX practice with an [RFC 1918] address. 344 . Noted that [RFC 1918] is not the only list of private addresses. 346 . General tidying of the wording and rearrangement of the material. 348 . The Post Office changed our postcode! 350 Full Copyright Statement 352 Copyright (C) The Internet Society (2001). All Rights Reserved. 354 This document and translations of it may be copied and furnished to 355 others, and derivative works that comment on or otherwise explain it 356 or assist in its implementation may be prepared, copied, published 357 and distributed, in whole or in part, without restriction of any 358 kind, provided that the above copyright notice and this paragraph are 359 included on all such copies and derivative works. However, this 360 document itself may not be modified in any way, such as by removing 361 the copyright notice or references to the Internet Society or other 362 Internet organizations, except as needed for the purpose of 363 developing Internet standards in which case the procedures for 364 copyrights defined in the Internet Standards process must be 365 followed, or as required to translate it into languages other than 366 English. 368 The limited permissions granted above are perpetual and will not be 369 revoked by the Internet Society or its successors or assigns. 371 This document and the information contained herein is provided on an 372 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 373 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 374 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 375 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 376 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 378 Acknowledgement 380 Funding for the RFC Editor function is currently provided by the 381 Internet Society.