Internet Engineering Task Force Alain Durand INTERNET-DRAFT SUN Microsystems Feb. 14, 2005 Tim Chown Expires Aug 13, 2005 University of Southampton, UK To publish, or not to publish, that is the question. Status of this memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html" Abstract This document aims at restarting the discussion on what is allowed to publish in the global DNS and what is not. The latest attempt was documented in [1] in an unsuccessful effort to clarify what to do with IPv4 private addresses RFC1918 [2] in the DNS. Since then, a number of similar issues coming from the IPv6 world have popped up and there is a sense that situation need to be clarified by a BCP. 1. Introduction The question about what is Ok to publish in the global DNS started with RFC1918 [2] which says: 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 have been trying to make this recommendation stronger, like in [1] and say that such addresses MUST NOT been published. The rationale was that, being ambiguous, those addresses could create problems for 3rd parties. The opponents have essentially been claiming that they should be able to publish whatever they wanted in the zone they control without having to use two-face DNS. 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: - Should one publish IPv6 and IPv4 addresses for the same name when the IPv6 connectivity is not as good as the IPv4 one? Then the discussion on the deprecation of IPv6 Site Local addresses and their replacement by Unique Local IPv6 Unicast Addresses [3] shade new light on this topic. The issue is not only the ambiguous vs non ambiguous, but also reachable vs non reachable. Unique Local IPv6 Unicast Addresses are global addresses, but by design they are not reachable from all places in the Internet. This is similar, however not exactly the same, as regular global addresses that are filtered out by firewall. The difference between the two is that one is unreachable by design when the other is unreachable because of a specific action taken by a network operator. So a new question was phrased as: - 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 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. 2.2. Issues with Unreachable Trying to connect to an unreachable address does not always failed immediately. As described in [4], this may end up triggering transport time-out, which, for TCP can be up to 3 minutes... So if a number of those unreachable addresses have to be tried before a reachable one is found, the initial delay can be extremely long. 2.3. Discussion The issues highlighted above are IP version agnostic, but they are exacerbated by IPv6 for two reasons: - During the transition phase, not all nodes will be reachable via IPv6. - Unique Local IPv6 Unicast Addresses, that are unreachable from most places in the Internet by design. 3. Is it a problem? 3.1 Cases where it is not a problem If addresses that are potentially ambiguous or unreachable are publish for labels which semantic 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 in my own zone file in the global DNS an RFC1918 address. Nobody from the outside is supposed to even know about this machine and failure to connect to it is actually considered a feature. 3.1 Cases where it is a problem However more serious problems may arise if one publish several addresses for a DNS label that is supposed to be globally reachable and some of the addresses are ambiguous, some not, or some are reachable and some not. 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 penalized the 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-face DNS is to use two different name, 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. 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. 5. IANA considerations None 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. Author address Alain Durand SUN Microsystems, Inc USA EMail: Alain.Durand@sun.com Tim J. Chown University of Southampton, UK Electronics and Computer Science University of Southampton Southampton SO17 1BJ UK Phone: +44 23 8059 5415 Fax: +44 23 8059 2865 EMail: tjc@ecs.soton.ac.uk 8. References [1] draft-ietf-dnsop-dontpublish-unreachable-03.txt, P Hazel, IP Addresses that should never appear in the public DNS, February 2002, work in progress. [2] RFC1918. Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996. [3] draft-ietf-ipv6-unique-local-addr-09.txt, R. Hinden, B. Haberman, Unique Local IPv6 Unicast Addresses, January 2005, work in progress. [4] draft-ietf-v6ops-v6onbydefault-03.txt, S. Roy, J. Paugh, A. Durand, Issues with Dual Stack IPv6 on by Default, July 2004, work in progress. 9. Copyright Statement Copyright (C) The Internet Society (2004). 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. 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.