DNS Operations A. Durand Internet-Draft Comcast Expires: April 27, 2006 T. Chown University of Southampton October 24, 2005 To publish, or not to publish, that is the question draft-durand-dnsop-dont-publish-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 27, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document aims at restarting the discussion on what a site network administrator should publish in the global DNS and what they should not. The latest attempt was documented in a previous draft [4] was was ultimately an unsuccessful effort to clarify what to do with IPv4 private addresses RFC1918 [1] in the DNS. Since then, a number of similar issues coming from the IPv6 world have arisen and there is a sense that the situation needs to be clarified by a BCP Durand & Chown Expires April 27, 2006 [Page 1] Internet-Draft DNS: Don't Publish Unreachables October 2005 document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. What are the issues? . . . . . . . . . . . . . . . . . . . . . 3 2.1 Issues with Ambiguous . . . . . . . . . . . . . . . . . . 3 2.2 Issues with Unreachable . . . . . . . . . . . . . . . . . 4 2.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Is it a problem? . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Cases where it is not a problem . . . . . . . . . . . . . 4 3.2 Cases where it is a problem . . . . . . . . . . . . . . . 4 3.2.1 By scope . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.2 By IP version . . . . . . . . . . . . . . . . . . . . 5 4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Informative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . 7 Durand & Chown Expires April 27, 2006 [Page 2] Internet-Draft DNS: Don't Publish Unreachables October 2005 1. Introduction The question about what may be published in the global DNS started with RFC1918 [1] which stated: "DNS clients outside of the enterprise should not see addresses in the private address space used by the enterprise, since these addresses would be ambiguous." Note the use of lower case "should". Since then, some people have been trying to make this recommendation stronger, as was the case in the original Don't Publish draft text [4], which said that such addresses MUST NOT been published. The rationale was that, since they are ambiguous, those addresses could create problems for third parties if advertised globally via the DNS. However, some people claim that they should be able to publish whatever they want in the DNS zone they control without having to use two-faced DNS. Being something of a 'religious' issue, the discussions seemed to have stalled. The debate over IPv6 usage in DNS seems to have brought new reasons to clarify the situation. The first question that came was: o Should one publish IPv6 and IPv4 addresses for the same name, even when the IPv6 connectivity is not as good as it is for IPv4? Then the discussion on the deprecation of IPv6 Site Local addresses and their replacement by Unique Local IPv6 Unicast Addresses [3] shed new light on this topic. The issue is not only the ambiguous versus non ambiguous, but also reachable versus non-reachable. Unique Local IPv6 Unicast Addresses are global addresses, with global scope (where their site-local predecessors were not global) but by design they are not reachable from all places in the Internet. This is similar, however not exactly the same, as they are now "regular" global addresses that are filtered out by a firewall. The difference between the two is that one is unreachable by design whilst the other is unreachable because of a specific action taken by a network operator. So a new question was phrased as: o Should global addresses that are not reachable from anywhere in the Internet be published in the global DNS? 2. What are the issues? 2.1 Issues with Ambiguous One, if the address published in the DNS is ambiguous, anyone using Durand & Chown Expires April 27, 2006 [Page 3] Internet-Draft DNS: Don't Publish Unreachables October 2005 it may end up going to the "wrong" place. Not only will it mean that the service may fail, but there are also security issues related to that. An attacker may trick you into thinking you are on the correct server and get your password. In principle, IPv6 ULAs remove the ambiguity issue, as they should be unique, if administrators use them properly. 2.2 Issues with Unreachable IPv6 on By Default [2] 2.3 Discussion o During the transition phase, not all nodes will be reachable via IPv6. o Unique Local IPv6 Unicast Addresses, that are global addresses, but that are unreachable from most places in the Internet by design. For IPv6, there is also a current issue that a site connecting to 3. Is it a problem? One might observe that publishing unreachable/ambiguous records in the DNS seems to be a self correcting problem, in the sense that it only affects the domain that publishes them, and has no impact what so ever on a third party. If that is the case, then language such as MUST NOT publish may be too strong. But we should consider the cases to understand if that is true. 3.1 Cases where it is not a problem If addresses that are potentially ambiguous or unreachable are published for labels whose meaning is limited to a subset of the Internet where the addresses would be neither ambiguous or unreachable, one may claim that there is no problem. Example: If at home, I maintain a local file server, and this file server is not intended to be visible from the outside, there is little harm if I publish an RFC1918 address in my own zone file in the global DNS. Nobody from the outside is supposed to even know about this machine and failure to connect to it is actually considered a feature. 3.2 Cases where it is a problem However more serious problems may arise if one publishes several addresses for a DNS label that is supposed to be globally reachable Durand & Chown Expires April 27, 2006 [Page 4] Internet-Draft DNS: Don't Publish Unreachables October 2005 and some of the addresses are ambiguous, some not, or some are reachable and some not. 3.2.1 By scope Example: If I maintain a SMTP server at home, behind a NAT box, with port 25 redirected by the NAT box to the SMTP server, it is not a good idea to publish both 192.168.1.2 and the global external address of the NAT for smtp.mydomain.example.com. One could have expected that by doing so, I would have optimized the connections and the internal hosts will use the RFC1918 address, avoiding the round-trip to the NAT, but the situation is that this would only happen 50% of the cases (due to the DNS server potentially balancing the traffic on the two addresses). Actually, doing this would severely penalise connections from the outside, when 50% of the time they would simply fail. A simple solution to avoid this problem while still not requiring a two-faced DNS is to use two different domain names, one for the inside and one for the outside. I could publish: smtp IN A 1.2.3.4 smtp-i IN A 192.168.1.2 Then point the MX record to smtp.mydomain.example.com and configure the local machines to use smtp-i.mydomain.example.com. That way, external incoming traffic will always go through the NAT box and internal outgoing traffic will stay local. 3.2.2 By IP version However, there are other problems, e.g. a site advertising a AAAA MX record for email, where the connectivity from the sender is poor for IPv6 but good for IPv4. In this case it is not the localised scope that is the issue, rather the protocol version selected. The receiver may believe they have good IPv6 connectivity when adding the AAAA record, but it may be that the sender is the poorly connected (IPv6) node. And here the sender may be the one "paying" by having additional mail queued and retrying. This issue is highlighted in the IPv6 on by Default text. 4. Recommendation When publishing several addresses for a DNS label, one must take care not to publish at the same time addresses that are designed to be globally unique and reachable and addresses that are not. Durand & Chown Expires April 27, 2006 [Page 5] Internet-Draft DNS: Don't Publish Unreachables October 2005 5. IANA Considerations There are no IANA considerations for this document. 6. Security Considerations Publishing ambiguous addresses can enable an attacker to still data and/or credentials from clients that can be tricked into sending data to the wrong node. 7. Informative References [1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [2] Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 (work in progress), July 2004. [3] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in progress), January 2005. [4] Hazel, P., "IP Addresses that should never appear in the public DNS", draft-ietf-dnsop-dontpublish-unreachable-03 (work in progress), February 2002. Authors' Addresses Alain Durand Comcast Email: Alain_Durand@cable.comcast.com Tim Chown University of Southampton School of Electronics and Computer Science Southampton, Hampshire SO17 1BJ United Kingdom Email: tjc@ecs.soton.ac.uk Durand & Chown Expires April 27, 2006 [Page 6] Internet-Draft DNS: Don't Publish Unreachables October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Durand & Chown Expires April 27, 2006 [Page 7]