DNS extensions to Network Address Translators (DNS_ALG)
RFC 2694

Document Type RFC - Informational (September 1999; Errata)
Authors Andy Heffernan  , George Tsirtsis  , Pyda Srisuresh  , Praveen Akkiraju 
Last updated 2020-01-21
Stream IETF
Formats plain text html pdf htmlized with errata bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state RFC 2694 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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.


   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

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

   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:
   user@private.com) 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
Show full document text