idnits 2.17.1 draft-ietf-dnsop-dontpublish-unreachable-03.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 510 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 8 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 4 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 262 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 (February 2002) is 8106 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) ** Downref: Normative reference to an Informational RFC: RFC 1912 ** Obsolete normative reference: RFC 2553 (Obsoleted by RFC 3493) ** Obsolete normative reference: RFC 2893 (Obsoleted by RFC 4213) Summary: 8 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-03.txt University of Cambridge 3 Valid for six months February 2002 4 Category: Best Current Practice 6 IP Addresses that should never appear in the public DNS 8 Copyright (C) The Internet Society (2002). 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, and extends the 37 discussion to include IPv6 addresses. 39 Secondly, the document discusses the problems that can be caused 40 by the appearance of public addresses, or indirect references to 41 them, when the service implied by the address or reference is 42 inaccessible from the public Internet. 44 Specifying a blanket prohibition in the second case is difficult 45 because inaccessibility may arise from many causes, some possibly 46 legitimate. Instead, the document points out some of the problems 47 that can arise, and suggests that other means of achieving the 48 desired effects should be used wherever possible. 50 1. Introduction 52 The increasing use of firewalls, NAT boxes, and similar technology 53 has resulted in the fragmentation of the Internet into regions whose 54 boundaries do not allow general connectivity. There are two primary 55 reasons for this: 57 (1) The perceived shortage of IPv4 addresses has caused increasing 58 use of private IPv4 network addresses such as 10.0.0.0/8 on LANs. A 59 number of such private address ranges are designated in [RFC 1918], 60 and others may be also assigned by IANA. 62 [Note: For example, there's 169.254/16, which is mentioned in 63 draft-ietf-zeroconf-ipv4-linklocal-04.txt, but since that's still a 64 draft, I can't cite it.] 66 IPv6 addresses are not in short supply, but the IPv6 architecture 67 uses a scoped address model, in which non-global addresses have 68 limited reachability and domains of uniqueness. For instance, site- 69 local addresses are reachable only within a particular site. 71 Hosts using private addresses that wish to communicate with the 72 public Internet must do so via an address translation mechanism such 73 as a NAT box. This allows a host with a private address to send 74 packets to public Internet hosts, and to receive replies. However, 75 unsolicited incoming packets cannot reach these hosts from outside 76 their own private network. 78 (2) Increasing security concerns have caused many sites to install 79 firewalls or to implement restrictions in their boundary routers in 80 order to lock out certain kinds of connection to their hosts, even 81 when the hosts are using public Internet addresses, though in many 82 cases firewalls also provide NAT functionality. 84 Thus, there are two classes of host which some or all types of 85 unexpected incoming packet from the public Internet cannot reach: 86 those using truly private IPv4 or IPv6 addresses, and those using 87 public addresses where access is blocked. 89 A number of instances have been observed where IP addresses that are 90 never accessible from the public Internet have nevertheless been 91 inserted into resource records in the public DNS. This document seeks 92 to prohibit such behaviour in the case of truly private addresses, 93 and to discourage it in the case of public, but unreachable, 94 addresses. 96 Although this document is specifically concerned with the contents of 97 the public DNS, the principle of not publishing private IP addresses 98 is applicable to any other form of general publication. 100 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC 2119]. 104 The phrase "address record" means an A record or an AAAA record, or 105 any other kind of name-to-address record that may come into use. 107 2. Private network addresses 109 Examples of [RFC 1918] private host addresses are 10.0.0.1 and 110 172.16.42.53. In the case of IPv6, all link-local and site-local 111 addresses are private. 113 Packets cannot be routed to such addresses from the public Internet. 114 [RFC 1918] explains this in section 3, from where this paragraph is 115 taken: 117 Because private addresses have no global meaning, routing 118 information about private networks shall not be propagated on 119 inter-enterprise links, and packets with private source or 120 destination addresses should not be forwarded across such links. 121 Routers in networks not using private address space, especially 122 those of Internet service providers, are expected to be 123 configured to reject (filter out) routing information about 124 private networks. 126 Because the same private addresses are in use in many different 127 organizations, they are ambiguous. The appearance of private 128 addresses in the DNS could therefore lead to unpredictable and 129 unwanted behaviour. Consider this set of entries: 131 @ IN MX 10 smtp 132 smtp IN A 10.1.2.3 133 smtp IN A 131.111.10.206 135 The MX record resolves to two IP addresses, one of which is private 136 and one of which is public. Zones set up in this way have been seen, 137 and some administrators apparently believe this is useful, because 138 it allows mail on their local network to be delivered straight to 139 the internal server (the one with address 10.1.2.3). However, this 140 approach breaks down when a host on a foreign network that is also 141 using the address 10.1.2.3 attempts to send mail to the domain. 143 In section 5 of [RFC 1918] there is a prohibition of the appearance 144 of private addresses in publicly visible DNS records. It says: 146 If an enterprise uses the private address space, or a mix of 147 private and public address spaces, then DNS clients outside of 148 the enterprise should not see addresses in the private address 149 space used by the enterprise, since these addresses would be 150 ambiguous. 152 The wording "should not" is not a very strong prohibition, 153 considering the interworking problems that ignoring it can cause. 154 Therefore, this document makes a stronger statement: 156 Public DNS zones MUST NOT contain [RFC 1918] addresses, IPv6 link- 157 local or site-local addresses, or any other addresses designated 158 by IANA as private, in any resource records where the context makes 159 them appear to be globally-meaningful addresses. 161 3. Public network addresses that are inacessible 163 The situation with public network addresses is more complicated 164 because the Internet cannot in general be cleanly divided into 165 "public" and "private" parts in this case. Examples of situations 166 where the division is fuzzy are: 168 (1) A host with a public address that is behind a firewall may be 169 accessible for SSH sessions, but not for SMTP sessions. That is, 170 the blocking may apply only to certain ports. 172 (2) A host with a public address may make certain services available 173 only to specific client hosts, for example, those in partner 174 enterprises, or those in a specific geographic area. 176 (3) A host might respond to incoming packets only if the client host 177 is using IPsec. 179 When a host is providing any service at all over the public Internet, 180 a publicly visible address record is of course required to give 181 access to that host. 183 However, for some protocols and services, additional DNS records 184 are defined that reference hosts' address records. These are the NS 185 record for name servers, the MX record for SMTP, and the SRV record 186 for other services. The existence of such indirect records advertises 187 the availability of the relevant service. 189 If these services are always inaccessible over the public Internet, 190 it is bad practice to include the NS, MX or SRV records in public DNS 191 zones, for the following reason: 193 A host that tries to connect to an unreachable address (or port) 194 may not receive an immediate rejection; in many cases the connection 195 will fail only after a timeout expires. The wasted effort ties up 196 resources on the calling host and the network, possibly for some 197 considerable time (SMTP timeouts, for example, are of the order of 198 minutes). It may also cause a gratuitous slowing down of the 199 application. 201 Furthermore, in the case of dial-up connections, ISDN, or other kinds 202 of usage-based charged network connection, the wasted network 203 resources may cost real money. 205 Public DNS zones SHOULD NOT contain NS, MX or SRV records that point 206 to hosts for which the relevant services are never accessible over the 207 public Internet. In other words, if there is no host that is able to 208 make use of the service using the public Internet, the service SHOULD 209 NOT be publicly advertised. 211 4. Other kinds of IPv6 address 213 4.1 Anycast addresses 215 Anycast addresses should be treated as global addresses with limited 216 reachability. 218 4.2 Multicast addresses 220 Scoped multicast addresses (multicast addresses with a 4 bit scope 221 value less than 0x0e) MUST NOT be put into public DNS zones. Globally- 222 scoped multicast addresses MAY be put into public DNS zones. 224 4.3 IPv4-mapped addresses 226 IPv4-mapped addresses MUST NOT be put into public DNS zones, because 227 their use is limited to an internal representation of IPv4 peers within 228 the AF_INET6 socket API [RFC 2553]. 230 4.4 IPv4-compatible addresses 232 IPv4-compatible addresses MUST NOT be put into public DNS zones. 233 Although there might be a case for doing so in order to indicate 234 that the node is willing to accept auto-tunnelled packets [RFC 2893], 235 it is not clear that this transition mechanism will be widely used. 236 It is therefore preferable to keep the DNS operationally "clean" by 237 not allowing them. 239 5. Loopback addresses 241 The loopback addresses (127.0.0.1 for IPv4 and ::1 for IPv6) are 242 another form of private address. There has been a practice of including 243 them in DNS zones for two entirely different reasons. 245 5.1 The name "localhost" 247 Some hostmasters include records of this type in their zones: 249 localhost.some.domain.example. A 127.0.0.1 251 The reason for doing this is so that other hosts in the domain 252 that use the DNS for all their name resolution can make use of the 253 unqualified name "localhost". This works because DNS resolvers 254 normally add the local enclosing domain to unqualified names. 256 DNS zones MAY make use of this technique for the name "localhost" 257 only, if it is required in their environment, but SHOULD avoid it 258 if possible. See section 6.1 below for an alternative technique. 260 5.2 DNS "black lists" 262 There is an increasingly popular practice of creating "black 263 lists" of misbehaving hosts (for example, open mail relays) in 264 the DNS. The first of these was the "Realtime Blackhole List" 265 (RBL). Such lists make use of address values in the 127.0.0.0/8 266 network in DNS address records to give information about listed 267 hosts (which are looked up via their inverted IP addresses). 269 Such records are in specific "black list" domains, and are well 270 understood not to be invitations to attempt connections to the 271 addresses they publish. In other words, the values that appear 272 in these records do not appear in a context where they are 273 interpreted as IP addresses. 275 DNS zones MAY continue to make use of this technique. 277 5.3 Other uses of loopback networks 279 Apart from the exceptions mentioned in 5.1 and 5.2 above, the 280 loopback addresses MUST NOT appear in address records in the public 281 DNS, unless it is clear from the context that the value is not to be 282 interpreted as an IP address. 284 5.4 References to loopback addresses 286 When address records that contain loopback addresses do exist, 287 DNS zones MUST NOT contain indirect records (NS, MX or SRV) that 288 reference them. 290 6. Alternative techniques 292 6.1 Handling "localhost" 294 Instead of including "localhost" within every domain for which a name 295 server is authoritative, [RFC 1912] recommends setting up "localhost." 296 as a top-level domain in each name server. [RFC 2606] reserves the 297 name "localhost." for this purpose. 299 6.2 Splitting DNS zones 301 A site that is using private addresses may well want to use DNS 302 lookups for address resolution on its hosts. The lazy way approach is 303 simply to put the data into the public DNS zone, as in the example 304 shown in section 2 above. Because this can cause problems for 305 external hosts, this MUST NOT be done. 307 One approach that is commonly taken is to run a so-called "split 308 DNS". Two different authoritative servers are created: one containing 309 all the zone data is accessible only from within the private network. 310 External DNS queries are directed to the second server, which 311 contains a filtered version of the zone, without the private 312 addresses. 314 6.3 SMTP servers behind firewalls 316 The complication of a split DNS is not normally needed if it is only 317 SMTP traffic that is being blocked to a public address on a host 318 behind a firewall. Setting up MX records like this: 320 plc.example. MX 5 mail.plc.example. 321 MX 10 public.plc.example. 323 where both hosts have public IP addresses, but the first is blocked 324 at the firewall, SHOULD NOT be done. Only the publicly accessible 325 host should be used: 327 plc.example. MX 10 public.plc.example. 329 If a split DNS is in use, the host public.plc.example can use the 330 internal version to route the mail onwards. However, most MTAs have 331 configuration facilities to allow for explicit routing of mail, without 332 the need to use a DNS lookup. 334 6.4 Specification of no SMTP service 336 MX records that point to host names whose address records specify the 337 loopback address have been seen in the DNS. This seems to be a 338 misguided attempt to specify "no SMTP service for this domain" more 339 positively than just refusing connections to the SMTP port. (A refused 340 connection is treated as a temporary error, because it might be the 341 result of a system rebooting, for example.) 343 If such a facility is required, it SHOULD instead be done by 344 arranging for the hosts in question to return 346 554 No SMTP service here 348 to all SMTP connections. 350 7. Security Considerations 352 This document is not known to create new security issues in the DNS, 353 mail agents, etc. In some sense, it may reduce security exposure by 354 insisting that a site's inappropriate internal data not be exposed. 356 8. IANA Considerations 358 No IANA actions are required by this document. 360 9. Acknowledgements 362 Randy Bush read an early draft of this document and suggested several 363 improvements. 365 Draft 01 has benefitted from comments made by Daniel Senie, John 366 Schnizlein, Robert Elz, Bert Hubert, and Stuart Cheshire. 368 Draft 02 has benefitted from comments made by David Keegel and Simon 369 Josefsson. 371 Draft 03 has benefitted from comments made by Jun-ichiro itojun 372 Hagino, David Terrell, Erik Nordmark, Matt Larson, and Zefram. 374 10. Author's Address 376 Philip Hazel 377 University of Cambridge Computing Service 378 New Museums Site, Pembroke Street 379 Cambridge CB2 3QH, England 381 Phone: + 44 1223 334714 382 Email: ph10@cam.ac.uk 384 11. References 386 [RFC 1912] Barr, D. "Common DNS Operational and Configuration 387 Errors", RFC 1912, February 1996. 389 [RFC 1918] Rekhter, Y. et al "Address allocation for Private 390 Internets", BCP 5, RFC 1918, February 1996. 392 [RFC 2119] Bradner, S. "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [RFC 2553] Gilligan, S. et al "Basic Socket Interface Extensions 396 for IPv6", RFC 2553, March 1999. 398 [RFC 2606] Eastlake, D. and Panitz, A. "Reserved Top Level DNS 399 Names", BCP 32, RFC 2606, June 1999. 401 [RFC 2893] Gilligan, R. and Nordmark, E. "Transition Mechanisms 402 for IPv6 Hosts and Routers", RFC 2893, August 2000. 404 12. Changes made during development of this document 406 This section is provided for the convenients of those tracking the 407 document. It will be removed from the final draft. 409 12.1 Changes made to the -00 version to create -01 411 . While leaving the MUSTs in for truly private addresses, I've tried 412 to be more "educational" about the case of public addresses that are 413 inaccessible, and backed down to SHOULD in those cases. 415 . I've pointed out the lack of a clear-cut public/private boundary, 416 and tried to make the case for not advertising unavailable services 417 without being so probititive in the wording. This includes using 418 "never accessible" instead of "not accessible". 420 . Changed "hostmaster" to "zone" in a couple of cases. 422 . Included an example of bad MX practice with an [RFC 1918] address. 424 . Noted that [RFC 1918] is not the only list of private addresses. 426 . General tidying of the wording and rearrangement of the material. 428 . The Post Office changed our postcode! 430 12.2 Changes made to the -01 version to create -02 432 . Add NS to MX and SRV as another DNS record that advertises a service 433 indirectly. 435 . Changed the address 1.2.3.4 in an example to a genuine real address 436 to make it quite clear what I mean. 438 . Added "geographic area" as another example of a service restriction. 440 . Suggested why people might want something other than "connection 441 refused" from hosts that don't provide SMTP service. 443 . Some other very minor rewording. 445 12.3 Changes made to the -02 version to create -03 447 . Added more words about IPv6, with detail supplied by Jun-ichiro 448 itojun Hagino about specific kinds of IPv6 address. 450 . Added a references to RFCs 1912 and 2606 for the handling of 451 "localhost" by setting it up as a TLD. 453 . Generalized ideas such as "black hole lists" to talk about the 454 context of interpretation of addresses. 456 . Added a short statement about other (non-DNS) forms of publication. 458 Full Copyright Statement 460 Copyright (C) The Internet Society (2002). All Rights Reserved. 462 This document and translations of it may be copied and furnished to 463 others, and derivative works that comment on or otherwise explain it 464 or assist in its implementation may be prepared, copied, published 465 and distributed, in whole or in part, without restriction of any 466 kind, provided that the above copyright notice and this paragraph are 467 included on all such copies and derivative works. However, this 468 document itself may not be modified in any way, such as by removing 469 the copyright notice or references to the Internet Society or other 470 Internet organizations, except as needed for the purpose of 471 developing Internet standards in which case the procedures for 472 copyrights defined in the Internet Standards process must be 473 followed, or as required to translate it into languages other than 474 English. 476 The limited permissions granted above are perpetual and will not be 477 revoked by the Internet Society or its successors or assigns. 479 This document and the information contained herein is provided on an 480 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 481 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 482 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 483 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 484 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 486 Acknowledgement 488 Funding for the RFC Editor function is currently provided by the 489 Internet Society.