rfc2694.txt

NAT协议完整源代码

Network Working Group                                       P. Srisuresh
Request for Comments: 2694                                    Consultant
Category: Informational                                      G. Tsirtsis
                                                         BT Laboratories
                                                             P. Akkiraju
                                                           Cisco Systems
                                                            A. Heffernan
                                                        Juniper Networks
                                                          September 1999


        DNS extensions to Network Address Translators (DNS_ALG)

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   Domain Name Service (DNS) provides name to address mapping within a
   routing class (ex: IP). Network Address Translators (NATs) attempt to
   provide transparent routing between hosts in disparate address realms
   of the same routing class. Typically, NATs exist at the border of a
   stub domain, hiding private addresses from external addresses. This
   document identifies the need for DNS extensions to NATs and outlines
   how a DNS Application Level Gateway (DNS_ALG) can meet the need.
   DNS_ALG modifies payload transparently to alter address mapping of
   hosts as DNS packets cross one address realm into another. The
   document also illustrates the operation of DNS_ALG with specific
   examples.

1. Introduction

   Network Address Translators (NATs) are often used when network's
   internal IP addresses cannot be used outside the network either for
   privacy reasons or because they are invalid for use outside the
   network.

   Ideally speaking, a host name uniquely identifies a host and its
   address is used to locate routes to the host. However, host name and
   address are often not distinguished and used interchangeably by
   applications. Applications embed IP address instead of host name in



Srisuresh, et al.            Informational                      [Page 1]

RFC 2694                 DNS extensions to NAT            September 1999


   payload. Examples would be e-mails that specify their MX server
   address (ex: user@666.42.7.11) instead of server name (ex:
   [e-mail]) as sender ID; HTML files that include IP address
   instead of names in URLs, etc. Use of IP address in place of host
   name in payload represents a problem as the packet traverses a NAT
   device because NATs alter network and transport headers to suit an
   address realm, but not payload.

   DNS provides Name to address mapping. Whereas, NAT performs address
   translation (in network and transport headers) in datagrams
   traversing between private and external address realms.  DNS
   Application Level Gateway (DNS_ALG) outlined in this document helps
   translate Name-to-Private-Address mapping in DNS payloads into Name-
   to-external-address mapping and vice versa using state information
   available on NAT.

   A Network Address Port Translator (NAPT) performs address and
   Transport level port translations (i.e, TCP, UDP ports and ICMP query
   IDs). DNS name mapping granularity, however, is limited to IP
   addresses and does not extend to transport level identifiers.  As a
   result, the DNS_ALG processing for an NAPT configuration is
   simplified in that all host addresses in private network are bound to
   a single external address. The DNS name lookup for private hosts
   (from external hosts) do not mandate fresh private-external address
   binding, as all private hosts are bound to a single pre-defined
   external address. However, reverse name lookups for the NAPT external
   address will not map to any of the private hosts and will simply map
   to the NAPT router.  Suffices to say, the processing requirements for
   a DNS_ALG supporting NAPT configuration are a mere subset of Basic
   NAT.  Hence, the discussion in the remainder of the document will
   focus mainly on Basic NAT, Bi-directional NAT and Twice NAT
   configurations, with no specific reference to NAPT setup.

   Definitions for DNS and related terms may be found in [Ref 3] and
   [Ref 4]. Definitions for NAT related terms may be found in [Ref 1].

2. Requirement for DNS extensions

   There are many ways to ensure that a host name is mapped to an
   address relevant within an address realm. In the following sections,
   we will identify where DNS extensions would be needed.

   Typically, organizations have two types of authoritative name
   servers. Internal authoritative name servers identify all (or
   majority of) corporate resources within the organization. Only a
   portion of these hosts are allowed to be accessed by the external
   world. The remaining hosts and their names are unique to the private
   network. Hosts visible to the external world and the authoritative



Srisuresh, et al.            Informational                      [Page 2]

RFC 2694                 DNS extensions to NAT            September 1999


   name server that maps their names to network addresses are often
   configured within a DMZ (De-Militarized Zone) in front of a firewall.
   We will refer the hosts and name servers within DMZ as DMZ hosts and
   DMZ name servers respectively. DMZ host names are end-to-end unique
   in that their FQDNs do not overlap with any end node that
   communicates with it.

                                   \ | /
                           +-----------------------+
                           |Service Provider Router|
                           +-----------------------+
                            WAN  |
               Stub A .........|\|....
                               |
                     +-----------------+
                     |Stub Router w/NAT|
                     +-----------------+
                         |
                         |   DMZ - Network
   ------------------------------------------------------------
      |         |              |            |             |
     +--+      +--+           +--+         +--+      +----------+
     |__|      |__|           |__|         |__|      | Firewall |
    /____\    /____\         /____\       /____\     +----------+
   DMZ-Host1  DMZ-Host2 ...  DMZ-Name     DMZ-Web       |
                             Server       Server etc.   |
                                                        |
     Internal hosts (Private IP network)                |
   ------------------------------------------------------------
       |             |                 |           |
      +--+         +--+               +--+       +--+
      |__|         |__|               |__|       |__|
     /____\       /____\             /____\     /____\
    Int-Host1    Int-Host2  .....   Int-Hostn   Int-Name Server

    Figure 1: DMZ network configuration of a private Network.

   Figure 1 above illustrates configuration of a private network which
   includes a DMZ. Actual configurations may vary. Internal name servers
   are accessed by users within the private network only. Internal DNS
   queries and responses do not cross the private network boundary. DMZ
   name servers and DMZ hosts on the other hand are end-to-end unique
   and could be accessed by external as well as internal hosts.
   Throughout this document, our focus will be limited to DMZ hosts and
   DMZ name servers and will not include internal hosts and internal
   name servers, unless they happen to be same.





Srisuresh, et al.            Informational                      [Page 3]

RFC 2694                 DNS extensions to NAT            September 1999


2.1. DMZ hosts assigned static external addresses on NAT

   Take the case where DMZ hosts are assigned static external addresses
   on the NAT device. Note, all hosts within private domain, including
   the DMZ hosts are identified by their private addresses.  Static
   mapping on the NAT device allows the DMZ hosts to be identified by
   their public addresses in the external domain.

2.1.1. Private networks with no DMZ name servers

   Take the case where a private network has no DMZ name server for
   itself. If the private network is connected to a single service
   provider for external connectivity, the DMZ hosts may be listed by
   their external addresses in the authoritative name servers of the
   service provider within their forward and in-add.arpa reverse zones.

   If the network is connected to multiple service providers, the DMZ
   host names may be listed by their external address(es) within the
   authoritative name servers of each of the service providers.  This is
   particularly significant in the case of in-addr.arpa reverse zones,
   as  the private network may be assigned different address prefixes by
   the service providers.

   In both cases, externally generated DNS lookups will not reach the
   private network.  A large number of NAT based private domains pursue
   this option to have their DMZ hosts listed by their external
   addresses on service provider's name servers.

2.1.2. Private networks with DMZ name servers

   Take the case where a private network opts to keep an authoritative
   DMZ name server for the zone within the network itself. If the
   network is connected to a single service provider, the DMZ name
   server may be configured to obviate DNS payload interceptions as
   follows. The hosts in DMZ name server must be mapped to their
   statically assigned external addresses and the internal name server
   must be configured to bypass the DMZ name server for queries
   concerning external hosts. This scheme ensures that DMZ name servers
   are set for exclusive access to external hosts alone (not even to the
   DMZ hosts) and hence can be configured with external addresses only.

   The above scheme requires careful administrative planning to ensure
   that DMZ name servers are not contacted by the private hosts directly
   or indirectly (through the internal name servers). Using DNS-ALG
   would obviate the administrative ordeals with this approach.






Srisuresh, et al.            Informational                      [Page 4]

RFC 2694                 DNS extensions to NAT            September 1999


2.2. DMZ hosts assigned external addresses dynamically on NAT

   Take the case where DMZ hosts in a private network are assigned
   external addresses dynamically by NAT. While the addresses issued to
   these hosts are fixed within the private network, their externally
   known addresses are ephemeral, as determined by NAT.  In such a
   scenario, it is mandatory for the private organization to have a DMZ
   name server in order to allow access to DMZ hosts by their name.

   The DMZ name server would be configured with private addresses for
   DMZ hosts. DNS Application Level Gateway (DNS_ALG) residing on NAT
   device will intercept the DNS packets directed to or from the DMZ
   name server(s) and perform transparent payload translations so that a
   DMZ host name has the right address mapping within each address realm
   (i.e., private or external).

3. Interactions between NAT and DNS_ALG

   This document operates on the paradigm that interconnecting address
   realms may have overlapping address space. But, names of hosts within
   interconnected realms must be end-to-end unique in order for them to
   be accessed by all hosts. In other words, there cannot be an overlap
   of FQDNs between end nodes communicating with each other.  The
   following diagram illustrates how a DNS packet traversing a NAT
   device (with DNS_ALG) is subject to header and payload translations.
   A DNS packet can be a TCP or UDP packet with the source or
   destination port set to 53. NAT would translate the IP and TCP/UDP
   headers of the DNS packet and notify DNS-ALG to perform DNS payload
   changes. DNS-ALG would interact with NAT and use NAT state
   information to modify payload, as necessary.





















Srisuresh, et al.            Informational                      [Page 5]

RFC 2694                 DNS extensions to NAT            September 1999


                Original-IP
                 packet
                   ||
                   ||
                   vv
   +---------------------------------+    +-----------------------+
   |                                 |    |DNS Appl. Level Gateway|
   |Network Address Translation (NAT)|--->|     (DNS_ALG)         |
   |  *IP & Transport header mods    |<---|  *DNS payload mods    |
   |                                 |    |                       |
   +---------------------------------+    +-----------------------+
                   ||
                   ||
                   vv
              Translated-IP
                 packet

    Figure 2: NAT & DNS-ALG in the translation path of DNS packets

3.1. Address Binding considerations

   We will make a distinction between "Temporary Address Binding" and
   "Committed Address Binding" in NATs. This distinction becomes