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.
                 <draft-durand-dnsop-dont-publish-00.txt>



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.


. 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?


. 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.


. 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.


. 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.



. IANA considerations

   None



. 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.



. 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


. References

   [] draft-ietf-dnsop-dontpublish-unreachable-03.txt, P Hazel,
       IP Addresses that should never appear in the public DNS, February 2002,
       work in progress.

   [] RFC1918. Address Allocation for Private Internets. Y. Rekhter, B.
       Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996.

   [] draft-ietf-ipv6-unique-local-addr-09.txt, R. Hinden, B. Haberman,
       Unique Local IPv6 Unicast Addresses, January 2005, work in progress.

   [] 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.



. 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.