RFC 2694 (rfc2694) - Page 2 of 29

DNS extensions to Network Address Translators (DNS_ALG)

RFC 2694                 DNS extensions to NAT            September 1999


   payload. Examples would be e-mails that specify their MX server
   address (ex: ) instead of server name (ex:
   ) 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