idnits 2.17.1 draft-ietf-dnsop-dontpublish-unreachable-00.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 331 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 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 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 168 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 8249 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: 4 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-00.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 prohibits the appearance of private IP 35 addresses in publicly visible DNS records. It also prohibits the 36 appearance of public addresses, or indirect references to them, when 37 the service implied by the address or reference is inaccessible from 38 the public Internet. Specifying the second prohibition is more 39 difficult because inaccessibility may arise from many causes, some 40 possibly legitimate. 42 1. Introduction 44 The increasing use of firewalls, NAT boxes, and similar technology 45 has resulted in the fragmentation of the Internet into regions whose 46 boundaries do not allow general connectivity. There are two primary 47 reasons for this: 49 (1) The perceived shortage of IPv4 addresses has caused increasing 50 use of private IP network addresses such as 10.0.0.0/8 on LANs. A 51 number of private address ranges are designated in [RFC 1918]. Hosts 52 using private addresses that wish to communicate with the public 53 Internet must do so via an address translation mechanism such as a 54 NAT box. This allows a host with a private address to send packets to 55 public Internet hosts, and to receive replies. However, unsolicited 56 incoming packets cannot reach these hosts from outside their own 57 private network. 59 (2) Increasing security concerns have caused many sites to install 60 firewalls or to implement restrictions in their boundary routers in 61 order to lock out certain kinds of connection to their hosts, even 62 when the hosts are using public Internet addresses, though in many 63 cases firewalls also provide NAT functionality. 65 Thus, there are two classes of host which some or all types of 66 unexpected incoming packet from the public Internet cannot reach. 68 A number of instances have been observed where IP addresses that are 69 not accessible from the public Internet have nevertheless been 70 inserted into resource records in the public DNS. This document seeks 71 to prohibit such behaviour. 73 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC 2119]. 77 The phrase "address record" means an A record or an AAAA record, or 78 any other kind of name-to-address record that may come into use. 80 2. Private network addresses 82 Examples of [RFC 1918] private host addresses are 10.0.0.1 and 83 172.16.42.53. Packets cannot be routed to such addresses from the 84 public Internet. [RFC 1918] explains this in section 3, from where 85 this paragraph is taken: 87 Because private addresses have no global meaning, routing 88 information about private networks shall not be propagated on 89 inter-enterprise links, and packets with private source or 90 destination addresses should not be forwarded across such links. 91 Routers in networks not using private address space, especially 92 those of Internet service providers, are expected to be 93 configured to reject (filter out) routing information about 94 private networks. 96 In section 5 of [RFC 1918] there is already a prohibition of the 97 appearance of private addresses in publicly visible DNS records. 98 However, the wording is merely "should not". This document makes a 99 stronger statement: 101 Public DNS zones MUST NOT contain [RFC 1918] private addresses in 102 any resource records. 104 Because the same private addresses are in use in many different 105 organizations, they are ambiguous. The appearance of private 106 addresses in the DNS could therefore lead to unpredictable and 107 unwanted behaviour. 109 3. Public network addresses that are blocked 111 The situation with public network addresses is more complicated. 112 For example, a host with a public address that is behind a firewall 113 may be accessible for SSH sessions, but not for SMTP sessions. That 114 is, the blocking may apply only to certain ports. A publicly visible 115 address record is therefore required to give access to those ports 116 that are accessible, and there can be no blanket prohibition. 118 However, for some protocols and services, additional DNS records 119 are defined that reference hosts' address records. These are the MX 120 record for SMTP, and the SRV record for other services. The existence 121 of such indirect records advertises the availability of the relevant 122 service. 124 Public DNS zones MUST NOT contain MX or SRV records that point to 125 hosts for which the relevant services are not accessible from the 126 public Internet. In other words, if a DNS resource record that 127 yields an IP address is visible to some part of the Internet, the 128 IP address yielded must be reachable by the protocol(s) implied by 129 the resource record type from the parts of the Internet where the 130 record is visible. 132 4. Why publishing public but unreachable addresses is bad 134 A host that tries to connect to an unreachable address (or port) 135 may not receive an immediate rejection; in many cases the connection 136 will only fail after a timeout expires. The wasted effort ties up 137 resources on the calling host and the network, possibly for some 138 considerable time (SMTP timeouts are of the order of minutes). 139 It also causes a gratuitous slowing down of the application. 141 Furthermore, in the case of dial-up, ISDN, or other kinds of 142 usage-based charged network connection, the wasted network resources 143 may cost real money. 145 5. Loopback addresses 147 The loopback addresses (127.0.0.1 for IPv4 and ::1 for IPv6) are 148 another form of private address. There has been a practice of including 149 them in DNS zones for two entirely different reasons. 151 5.1 The name "localhost" 153 Some hostmasters include records of this type in their zones: 155 localhost.some.domain.example. A 127.0.0.1 157 The reason for doing this is so that other hosts in the domain 158 that use the DNS for all their name resolution can make use of the 159 unqualified name "localhost". This works because DNS resolvers 160 normally add the local enclosing domain to unqualified names. 162 DNS zones MAY make use of this technique for the name "localhost" 163 only, if it is required in their environment, but SHOULD avoid it 164 if possible. 166 5.3 DNS "black lists" 168 There is an increasingly popular practice of creating "black 169 lists" of misbehaving hosts (for example, open mail relays) in 170 the DNS. The first of these was the "Realtime Blackhole List" 171 (RBL). Such lists make use of addresses in the 127.0.0.0/8 172 network in DNS address records to give information about listed 173 hosts (which are looked up via their inverted IP addresses). 175 Such records are in specific "black list" domains, and are well 176 understood not to be invitations to attempt connections to the 177 addresses they publish. 179 Hostmasters MAY continue to make use of this technique. 181 5.4 Other uses of loopback networks 183 Apart from the exceptions mentioned in 5.2 and 5.3, the loopback 184 addresses MUST NOT appear in address records in the public DNS. 186 5.5 References to loopback addresses 188 When address records that contain loopback addresses do exist, 189 hostmasters MUST NOT create indirect records (MX or SRV) that 190 reference them. 192 6. Alternative techniques 194 6.1 Splitting DNS zones 196 A site that is using private addresses may well want to use DNS 197 lookups for address resolution on its hosts. The lazy way approach is 198 simply to put the data into the public DNS zone. Because this can 199 cause problems for external hosts, this MUST NOT be done. 201 One approach that is commonly taken is to run a so-called "split 202 DNS". Two different authoritative servers are created: one containing 203 all the zone data is accessible only from within the private network. 204 External DNS queries are directed to the second server, which 205 contains a filtered version of the zone, without the private 206 addresses. 208 6.2 SMTP servers behind firewalls 210 The complication of a split DNS is not normally needed if it is only 211 SMTP traffic that is being blocked to a public address on a host 212 behind a firewall. Public MX records must always point to publicly 213 accessible hosts. Setting up MX records like this: 215 plc.example. MX 5 mail.plc.example. 216 MX 10 public.plc.example. 218 where both hosts have public IP addresses, but the first is blocked 219 at the firewall, MUST NOT be done. Only the publicly accessible host 220 must be used: 222 plc.example. MX 10 public.plc.example. 224 If a split DNS is in use, the host public.plc.example can use the 225 internal version to route the mail onwards. However, most MTAs have 226 configuration facilities to allow for explicit routing of mail, without 227 the use of the DNS. 229 6.3 Specification of no SMTP service 231 MX records that point to host names whose address records specify the 232 loopback address have been seen in the DNS. This seems to be a 233 misguided attempt to specify "no SMTP service for this domain". 235 If such a facility is required, it should instead be done by 236 arranging for the hosts in question to return 238 554 No SMTP service here 240 to all SMTP connections. 242 7. Security Considerations 244 This document is not known to create new security issues in the DNS, 245 mail agents, etc. In some sense, it may reduce security exposure by 246 insisting that a site's inappropriate internal data not be exposed. 248 8. IANA Considerations 250 No IANA actions are required by this document. 252 9. Acknowledgements 254 Randy Bush read an early draft of this document and suggested several 255 improvements. 257 10. Author's Address 259 Philip Hazel 260 University of Cambridge Computing Service 261 New Museums Site, Pembroke Street 262 Cambridge CB2 3QG, England 264 Phone: + 44 1223 334714 265 Email: ph10@cam.ac.uk 267 11. References 269 [RFC 1918] Rekhter, Y. et al "Address allocation for Private 270 Internets", BCP 5, RFC 1918, February 1996. 272 [RFC 2119] Bradner, S."Key words for use in RFCs to Indicate 273 Requirement Levels", BCP 14, RFC 2119, March 1997. 275 Full Copyright Statement 277 Copyright (C) The Internet Society (2001). All Rights Reserved. 279 This document and translations of it may be copied and furnished to 280 others, and derivative works that comment on or otherwise explain it 281 or assist in its implementation may be prepared, copied, published 282 and distributed, in whole or in part, without restriction of any 283 kind, provided that the above copyright notice and this paragraph are 284 included on all such copies and derivative works. However, this 285 document itself may not be modified in any way, such as by removing 286 the copyright notice or references to the Internet Society or other 287 Internet organizations, except as needed for the purpose of 288 developing Internet standards in which case the procedures for 289 copyrights defined in the Internet Standards process must be 290 followed, or as required to translate it into languages other than 291 English. 293 The limited permissions granted above are perpetual and will not be 294 revoked by the Internet Society or its successors or assigns. 296 This document and the information contained herein is provided on an 297 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 298 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 299 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 300 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 301 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 303 Acknowledgement 305 Funding for the RFC Editor function is currently provided by the 306 Internet Society.