home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2694.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  67.7 KB  |  1,628 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       P. Srisuresh
  8. Request for Comments: 2694                                    Consultant
  9. Category: Informational                                      G. Tsirtsis
  10.                                                          BT Laboratories
  11.                                                              P. Akkiraju
  12.                                                            Cisco Systems
  13.                                                             A. Heffernan
  14.                                                         Juniper Networks
  15.                                                           September 1999
  16.  
  17.  
  18.         DNS extensions to Network Address Translators (DNS_ALG)
  19.  
  20. Status of this Memo
  21.  
  22.    This memo provides information for the Internet community.  It does
  23.    not specify an Internet standard of any kind.  Distribution of this
  24.    memo is unlimited.
  25.  
  26. Copyright Notice
  27.  
  28.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  29.  
  30. Abstract
  31.  
  32.    Domain Name Service (DNS) provides name to address mapping within a
  33.    routing class (ex: IP). Network Address Translators (NATs) attempt to
  34.    provide transparent routing between hosts in disparate address realms
  35.    of the same routing class. Typically, NATs exist at the border of a
  36.    stub domain, hiding private addresses from external addresses. This
  37.    document identifies the need for DNS extensions to NATs and outlines
  38.    how a DNS Application Level Gateway (DNS_ALG) can meet the need.
  39.    DNS_ALG modifies payload transparently to alter address mapping of
  40.    hosts as DNS packets cross one address realm into another. The
  41.    document also illustrates the operation of DNS_ALG with specific
  42.    examples.
  43.  
  44. 1. Introduction
  45.  
  46.    Network Address Translators (NATs) are often used when network's
  47.    internal IP addresses cannot be used outside the network either for
  48.    privacy reasons or because they are invalid for use outside the
  49.    network.
  50.  
  51.    Ideally speaking, a host name uniquely identifies a host and its
  52.    address is used to locate routes to the host. However, host name and
  53.    address are often not distinguished and used interchangeably by
  54.    applications. Applications embed IP address instead of host name in
  55.  
  56.  
  57.  
  58. Srisuresh, et al.            Informational                      [Page 1]
  59.  
  60. RFC 2694                 DNS extensions to NAT            September 1999
  61.  
  62.  
  63.    payload. Examples would be e-mails that specify their MX server
  64.    address (ex: user@666.42.7.11) instead of server name (ex:
  65.    user@private.com) as sender ID; HTML files that include IP address
  66.    instead of names in URLs, etc. Use of IP address in place of host
  67.    name in payload represents a problem as the packet traverses a NAT
  68.    device because NATs alter network and transport headers to suit an
  69.    address realm, but not payload.
  70.  
  71.    DNS provides Name to address mapping. Whereas, NAT performs address
  72.    translation (in network and transport headers) in datagrams
  73.    traversing between private and external address realms.  DNS
  74.    Application Level Gateway (DNS_ALG) outlined in this document helps
  75.    translate Name-to-Private-Address mapping in DNS payloads into Name-
  76.    to-external-address mapping and vice versa using state information
  77.    available on NAT.
  78.  
  79.    A Network Address Port Translator (NAPT) performs address and
  80.    Transport level port translations (i.e, TCP, UDP ports and ICMP query
  81.    IDs). DNS name mapping granularity, however, is limited to IP
  82.    addresses and does not extend to transport level identifiers.  As a
  83.    result, the DNS_ALG processing for an NAPT configuration is
  84.    simplified in that all host addresses in private network are bound to
  85.    a single external address. The DNS name lookup for private hosts
  86.    (from external hosts) do not mandate fresh private-external address
  87.    binding, as all private hosts are bound to a single pre-defined
  88.    external address. However, reverse name lookups for the NAPT external
  89.    address will not map to any of the private hosts and will simply map
  90.    to the NAPT router.  Suffices to say, the processing requirements for
  91.    a DNS_ALG supporting NAPT configuration are a mere subset of Basic
  92.    NAT.  Hence, the discussion in the remainder of the document will
  93.    focus mainly on Basic NAT, Bi-directional NAT and Twice NAT
  94.    configurations, with no specific reference to NAPT setup.
  95.  
  96.    Definitions for DNS and related terms may be found in [Ref 3] and
  97.    [Ref 4]. Definitions for NAT related terms may be found in [Ref 1].
  98.  
  99. 2. Requirement for DNS extensions
  100.  
  101.    There are many ways to ensure that a host name is mapped to an
  102.    address relevant within an address realm. In the following sections,
  103.    we will identify where DNS extensions would be needed.
  104.  
  105.    Typically, organizations have two types of authoritative name
  106.    servers. Internal authoritative name servers identify all (or
  107.    majority of) corporate resources within the organization. Only a
  108.    portion of these hosts are allowed to be accessed by the external
  109.    world. The remaining hosts and their names are unique to the private
  110.    network. Hosts visible to the external world and the authoritative
  111.  
  112.  
  113.  
  114. Srisuresh, et al.            Informational                      [Page 2]
  115.  
  116. RFC 2694                 DNS extensions to NAT            September 1999
  117.  
  118.  
  119.    name server that maps their names to network addresses are often
  120.    configured within a DMZ (De-Militarized Zone) in front of a firewall.
  121.    We will refer the hosts and name servers within DMZ as DMZ hosts and
  122.    DMZ name servers respectively. DMZ host names are end-to-end unique
  123.    in that their FQDNs do not overlap with any end node that
  124.    communicates with it.
  125.  
  126.                                    \ | /
  127.                            +-----------------------+
  128.                            |Service Provider Router|
  129.                            +-----------------------+
  130.                             WAN  |
  131.                Stub A .........|\|....
  132.                                |
  133.                      +-----------------+
  134.                      |Stub Router w/NAT|
  135.                      +-----------------+
  136.                          |
  137.                          |   DMZ - Network
  138.    ------------------------------------------------------------
  139.       |         |              |            |             |
  140.      +--+      +--+           +--+         +--+      +----------+
  141.      |__|      |__|           |__|         |__|      | Firewall |
  142.     /____\    /____\         /____\       /____\     +----------+
  143.    DMZ-Host1  DMZ-Host2 ...  DMZ-Name     DMZ-Web       |
  144.                              Server       Server etc.   |
  145.                                                         |
  146.      Internal hosts (Private IP network)                |
  147.    ------------------------------------------------------------
  148.        |             |                 |           |
  149.       +--+         +--+               +--+       +--+
  150.       |__|         |__|               |__|       |__|
  151.      /____\       /____\             /____\     /____\
  152.     Int-Host1    Int-Host2  .....   Int-Hostn   Int-Name Server
  153.  
  154.     Figure 1: DMZ network configuration of a private Network.
  155.  
  156.    Figure 1 above illustrates configuration of a private network which
  157.    includes a DMZ. Actual configurations may vary. Internal name servers
  158.    are accessed by users within the private network only. Internal DNS
  159.    queries and responses do not cross the private network boundary. DMZ
  160.    name servers and DMZ hosts on the other hand are end-to-end unique
  161.    and could be accessed by external as well as internal hosts.
  162.    Throughout this document, our focus will be limited to DMZ hosts and
  163.    DMZ name servers and will not include internal hosts and internal
  164.    name servers, unless they happen to be same.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Srisuresh, et al.            Informational                      [Page 3]
  171.  
  172. RFC 2694                 DNS extensions to NAT            September 1999
  173.  
  174.  
  175. 2.1. DMZ hosts assigned static external addresses on NAT
  176.  
  177.    Take the case where DMZ hosts are assigned static external addresses
  178.    on the NAT device. Note, all hosts within private domain, including
  179.    the DMZ hosts are identified by their private addresses.  Static
  180.    mapping on the NAT device allows the DMZ hosts to be identified by
  181.    their public addresses in the external domain.
  182.  
  183. 2.1.1. Private networks with no DMZ name servers
  184.  
  185.    Take the case where a private network has no DMZ name server for
  186.    itself. If the private network is connected to a single service
  187.    provider for external connectivity, the DMZ hosts may be listed by
  188.    their external addresses in the authoritative name servers of the
  189.    service provider within their forward and in-add.arpa reverse zones.
  190.  
  191.    If the network is connected to multiple service providers, the DMZ
  192.    host names may be listed by their external address(es) within the
  193.    authoritative name servers of each of the service providers.  This is
  194.    particularly significant in the case of in-addr.arpa reverse zones,
  195.    as  the private network may be assigned different address prefixes by
  196.    the service providers.
  197.  
  198.    In both cases, externally generated DNS lookups will not reach the
  199.    private network.  A large number of NAT based private domains pursue
  200.    this option to have their DMZ hosts listed by their external
  201.    addresses on service provider's name servers.
  202.  
  203. 2.1.2. Private networks with DMZ name servers
  204.  
  205.    Take the case where a private network opts to keep an authoritative
  206.    DMZ name server for the zone within the network itself. If the
  207.    network is connected to a single service provider, the DMZ name
  208.    server may be configured to obviate DNS payload interceptions as
  209.    follows. The hosts in DMZ name server must be mapped to their
  210.    statically assigned external addresses and the internal name server
  211.    must be configured to bypass the DMZ name server for queries
  212.    concerning external hosts. This scheme ensures that DMZ name servers
  213.    are set for exclusive access to external hosts alone (not even to the
  214.    DMZ hosts) and hence can be configured with external addresses only.
  215.  
  216.    The above scheme requires careful administrative planning to ensure
  217.    that DMZ name servers are not contacted by the private hosts directly
  218.    or indirectly (through the internal name servers). Using DNS-ALG
  219.    would obviate the administrative ordeals with this approach.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Srisuresh, et al.            Informational                      [Page 4]
  227.  
  228. RFC 2694                 DNS extensions to NAT            September 1999
  229.  
  230.  
  231. 2.2. DMZ hosts assigned external addresses dynamically on NAT
  232.  
  233.    Take the case where DMZ hosts in a private network are assigned
  234.    external addresses dynamically by NAT. While the addresses issued to
  235.    these hosts are fixed within the private network, their externally
  236.    known addresses are ephemeral, as determined by NAT.  In such a
  237.    scenario, it is mandatory for the private organization to have a DMZ
  238.    name server in order to allow access to DMZ hosts by their name.
  239.  
  240.    The DMZ name server would be configured with private addresses for
  241.    DMZ hosts. DNS Application Level Gateway (DNS_ALG) residing on NAT
  242.    device will intercept the DNS packets directed to or from the DMZ
  243.    name server(s) and perform transparent payload translations so that a
  244.    DMZ host name has the right address mapping within each address realm
  245.    (i.e., private or external).
  246.  
  247. 3. Interactions between NAT and DNS_ALG
  248.  
  249.    This document operates on the paradigm that interconnecting address
  250.    realms may have overlapping address space. But, names of hosts within
  251.    interconnected realms must be end-to-end unique in order for them to
  252.    be accessed by all hosts. In other words, there cannot be an overlap
  253.    of FQDNs between end nodes communicating with each other.  The
  254.    following diagram illustrates how a DNS packet traversing a NAT
  255.    device (with DNS_ALG) is subject to header and payload translations.
  256.    A DNS packet can be a TCP or UDP packet with the source or
  257.    destination port set to 53. NAT would translate the IP and TCP/UDP
  258.    headers of the DNS packet and notify DNS-ALG to perform DNS payload
  259.    changes. DNS-ALG would interact with NAT and use NAT state
  260.    information to modify payload, as necessary.
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Srisuresh, et al.            Informational                      [Page 5]
  283.  
  284. RFC 2694                 DNS extensions to NAT            September 1999
  285.  
  286.  
  287.                 Original-IP
  288.                  packet
  289.                    ||
  290.                    ||
  291.                    vv
  292.    +---------------------------------+    +-----------------------+
  293.    |                                 |    |DNS Appl. Level Gateway|
  294.    |Network Address Translation (NAT)|--->|     (DNS_ALG)         |
  295.    |  *IP & Transport header mods    |<---|  *DNS payload mods    |
  296.    |                                 |    |                       |
  297.    +---------------------------------+    +-----------------------+
  298.                    ||
  299.                    ||
  300.                    vv
  301.               Translated-IP
  302.                  packet
  303.  
  304.     Figure 2: NAT & DNS-ALG in the translation path of DNS packets
  305.  
  306. 3.1. Address Binding considerations
  307.  
  308.    We will make a distinction between "Temporary Address Binding" and
  309.    "Committed Address Binding" in NATs. This distinction becomes
  310.    necessary because the DNS_ALG will allow external users to create
  311.    state on NAT, and thus the potential for denial-of-service attacks.
  312.    Temporary address binding is the phase in which an address binding is
  313.    reserved without any NAT sessions using the binding. Committed
  314.    address binding is the phase in which there exists at least one NAT
  315.    session using the binding between the external and private addresses.
  316.    Both types of bindings are used by DNS_ALG to modify DNS payloads.
  317.    NAT uses only the committed address bindings to modify the IP and
  318.    Transport headers of datagrams pertaining to NAT sessions.
  319.  
  320.    For statically mapped addresses, the above distinction is not
  321.    relevant. For dynamically mapped addresses, temporary address binding
  322.    often precedes committed binding. Temporary binding occurs when DMZ
  323.    name server is queried for a name lookup. Name query is likely a
  324.    pre-cursor to a real session between query originator and the queried
  325.    host. The temporary binding becomes committed only when NAT sees the
  326.    first packet of a session between query initiator and queried host.
  327.  
  328.    A configurable parameter, "Bind-holdout time" may be defined for
  329.    dynamic address assignments as the maximum period of time for which a
  330.    temporary address binding is held active without transitioning into a
  331.    committed binding. With each use of temporary binding by DNS_ALG (to
  332.    modify DNS payload), this Bind-holdout period is renewed. A default
  333.    Bind-holdout time of a couple of minutes might suffice for most DNS-
  334.    ALG implementations. Note, it is possible for a committed address
  335.  
  336.  
  337.  
  338. Srisuresh, et al.            Informational                      [Page 6]
  339.  
  340. RFC 2694                 DNS extensions to NAT            September 1999
  341.  
  342.  
  343.    binding to occur without ever having to be preceded by a temporary
  344.    binding. Lastly, when NAT is ready to unbind a committed address
  345.    binding, the binding is transitioned into a temporary binding and
  346.    kept in that phase for an additional Bind-holdout period. The binding
  347.    is freed only upon expiry of Bind-holdout time. The Bind-holdout time
  348.    preceding the committed-address-binding and the address-unbinding are
  349.    required to ensure that end hosts have sufficient time in which to
  350.    initiate a data session subsequent to a name lookup.
  351.  
  352.    For example, say a private network with address prefix 10/8 is mapped
  353.    to 198.76.29/24. When an external hosts makes a DNS query to host7,
  354.    bearing address 10.0.0.7, the DMZ name server within private network
  355.    responds with an A type RR for host7 as:
  356.  
  357.        host7  A  10.0.0.7
  358.  
  359.    DNS_ALG would intercept the response packet and if 10.0.0.7 is not
  360.    assigned an external address already, it would request NAT to create
  361.    a temporary address binding with an external address and start Bind-
  362.    holdout timer to age the binding. Say, the assigned external address
  363.    is 198.76.29.1. DNS-ALG would use this temporary binding to modify
  364.    the RR in DNS response, replacing 10.0.0.7 with its external address
  365.    and reply with:
  366.  
  367.        host7  A  198.76.29.1
  368.  
  369.    When query initiator receives DNS response, only the assigned
  370.    external address is seen. Within a short period (presumably before
  371.    the bind-holdout time expires), the query initiator would initiate a
  372.    session with host7. When NAT notices the start of new session
  373.    directed to 198.76.29.1, NAT would terminate Bind-holdout timer and
  374.    transition the temporary binding between 198.76.29.1 and 10.0.0.7
  375.    into a committed binding.
  376.  
  377.    To minimize denial of service attacks, where a malicious user keeps
  378.    attempting name resolutions, without ever initiating a connection,
  379.    NAT would have to monitor temporary address bindings that have not
  380.    transitioned into committed bindings. There could be a limit on the
  381.    number of temporary bindings and attempts to generate additional
  382.    temporary bindings could be simply rejected.  There may be other
  383.    heuristic solutions to counter this type of malicious attacks.
  384.  
  385.    We will consider bi-directional NAT to illustrate the use of
  386.    temporary binding by DNS_ALG in the following sub-sections, even
  387.    though the concept is applicable to other flavors of NATs as well.
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Srisuresh, et al.            Informational                      [Page 7]
  395.  
  396. RFC 2694                 DNS extensions to NAT            September 1999
  397.  
  398.  
  399. 3.2. Incoming queries
  400.  
  401.    In order to initiate incoming sessions, an external host obtains the
  402.    V4 address of the DMZ-host it is trying to connect to by making a DNS
  403.    request.  This request constitutes prelude to the start of a
  404.    potential new session.
  405.  
  406.    The external host resolver makes a name lookup for the DMZ host
  407.    through its DNS server.  When the DNS server does not have a record
  408.    of IPv4 address attached to this name, the lookup query is redirected
  409.    at some point to the Primary/Backup DNS server (i.e., in DMZ) of the
  410.    private stub domain.
  411.  
  412.    Enroute to DMZ name server, DNS_ALG would intercept the datagram and
  413.    modify the query as follows.
  414.  
  415.       a) For Host name to Host address query requests:
  416.          Make no change to the DNS payload.
  417.  
  418.       b) For Host address to Host name queries:  Replace the external V4
  419.          address octets (in reverse order) preceding the string "IN-
  420.          ADDR.ARPA"  with the corresponding private V4 address, if such
  421.          an address binding exists already. However, if a binding does
  422.          not exist, the DNS_ALG would simply respond (as a name server
  423.          would) with a response code (RCODE) of 5 (REFUSED to respond
  424.          due to policy reasons) and set ANCOUNT, NSCOUNT and ARCOUT to 0
  425.          in the header section of the response.
  426.  
  427.    In the opposite direction, as DNS response traverses from the DNS
  428.    server in private network, DNS_ALG would once again intercept the
  429.    packet and modify as follows.
  430.  
  431.       a) For a host name to host address query requests, replace the
  432.          private address sent by DMZ name server with a public address
  433.          internally assigned by the NAT router. If a public address is
  434.          not previously assigned to the host's private address, NAT
  435.          would assign one at this time.
  436.  
  437.       b) For host address to host name queries, replace the private
  438.          address octets preceding the string "IN-ADDR.ARPA" in response
  439.          RRs with their external address assignments.  There is a chance
  440.          here that by the time the DMZ name server replies, the bind-
  441.          holdout timer in NAT for the address in question has expired.
  442.          In such a case, DNS_ALG would simply drop the reply. The sender
  443.          will have to resend the query (as would happen when a router
  444.          enroute drops the response).
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Srisuresh, et al.            Informational                      [Page 8]
  451.  
  452. RFC 2694                 DNS extensions to NAT            September 1999
  453.  
  454.  
  455.    For static address assignments, the TTL value supplied in the
  456.    original RR will be left unchanged. For dynamic address assignments,
  457.    DNS_ALG would modify the TTL value on DNS resource records (RRs) to
  458.    be 0, implying that the RRs should only be used for transaction in
  459.    progress, and not be cached. For compatibility with broken
  460.    implementations, TTL of 1 might in practice work better.
  461.  
  462.    Clearly, setting TTL to be 0 will create more traffic than if the
  463.    addresses were static, because name-to-address mapping is not cached.
  464.    Specifically, network based applications will be required to use
  465.    names rather than addresses for identifying peer nodes and must use
  466.    DNS for every name resolution, as name-to-address mapping cannot be
  467.    shared from the previously run applications.
  468.  
  469.    In addition, NAT would be requested to initiate a bind-holdout timer
  470.    following the assignment. If no session is initiated to the private
  471.    host within the Bind-holdout time period, NAT would terminate the
  472.    temporary binding.
  473.  
  474. 3.3. Outgoing Queries
  475.  
  476.    For Basic and bi-directional NATs, there is no need to distinguish
  477.    between temporary and committed bindings for outgoing queries. This
  478.    is because, DNS_ALG does not modify the DNS packets directed to or
  479.    from external name servers (used during outbound sessions), unlike
  480.    the inbound DNS sessions.
  481.  
  482.    Say, a private host needs to communicate with an external host.  The
  483.    DNS query  goes  to  the internal name server (if there exists one)
  484.    and from there to the appropriate authoritative/cache name server
  485.    outside the private domain.  The  reply follows the same route but
  486.    neither the query nor the response are subject to DNS_ALG
  487.    translations.
  488.  
  489.    This however will not be the case with address isolated twice NAT
  490.    private and external domains. In such a case, NAT would intercept all
  491.    DNS packets and make address modifications to payload as discussed in
  492.    the previous section. Temporary Private to external address bindings
  493.    are created when responses are sent by private DNS servers and
  494.    temporary external to private address bindings are created when
  495.    responses are sent by external DNS servers.
  496.  
  497. 4. DNS payload modifications by DNS-ALG
  498.  
  499.    Typically, UDP is employed as the transport mechanism for DNS queries
  500.    and responses and TCP for Zone refresh activities. In either case,
  501.    name servers are accessed using a well-known DNS server port 53
  502.    (decimal) and all DNS payloads have the following format of data [Ref
  503.  
  504.  
  505.  
  506. Srisuresh, et al.            Informational                      [Page 9]
  507.  
  508. RFC 2694                 DNS extensions to NAT            September 1999
  509.  
  510.  
  511.    4]. While NAT is responsible for the translation of IP and TCP/UDP
  512.    headers of a DNS packet, DNS-ALG is responsible for updating the DNS
  513.    payload.
  514.  
  515.    The header section within the DNS payload is always present and
  516.    includes fields specifying which of the remaining sections are
  517.    present. The header identifies if the message is a query or a
  518.    response. No changes are required to be made by DNS-ALG to the Header
  519.    section. DNS_ALG would parse only the DNS payloads whose QCLASS is
  520.    set to IN (IP class).
  521.  
  522.     +---------------------+
  523.     |        Header       |
  524.     +---------------------+
  525.     |       Question      | the question for the name server
  526.     +---------------------+
  527.     |        Answer       | RRs answering the question
  528.     +---------------------+
  529.     |      Authority      | RRs pointing toward an authority
  530.     +---------------------+
  531.     |      Additional     | RRs holding additional information
  532.     +---------------------+
  533.  
  534. 4.1. Question section
  535.  
  536.    The question section contains QDCOUNT (usually 1) entries, as
  537.    specified in Header section, with each of the entries in the
  538.    following format:
  539.  
  540.                                     1  1  1  1  1  1
  541.       0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  542.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  543.     |                                               |
  544.     /                     QNAME                     /
  545.     /                                               /
  546.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  547.     |                     QTYPE                     |
  548.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  549.     |                     QCLASS                    |
  550.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  551.  
  552. 4.1.1. PTR type Queries
  553.  
  554.    DNS_ALG must identify all names, whose FQDNs (i.e., Fully Qualified
  555.    Domain Names) fall within IN-ADDR.ARPA domain and replace the address
  556.    octets (in reverse  order)  preceding the string "IN-ADDR.ARPA"  with
  557.    the corresponding assigned address octets in reverse order, only if
  558.    the address binding is active on the NAT router. If the address
  559.  
  560.  
  561.  
  562. Srisuresh, et al.            Informational                     [Page 10]
  563.  
  564. RFC 2694                 DNS extensions to NAT            September 1999
  565.  
  566.  
  567.    preceding the string "IN-ADDR.ARPA" falls within the NAT address map,
  568.    but does not have at least a temporary address binding, DNS_ALG would
  569.    simply simply respond back (as a DNS name server would) with a
  570.    response code (RCODE) of 5 (REFUSED to respond due to policy reasons)
  571.    and set ANCOUNT, NSCOUNT and ARCOUT to 0 in the header section of the
  572.    response.
  573.  
  574.    Note that the above form of host address to host name type queries
  575.    will likely yield different results at different times, depending
  576.    upon address bind status in NAT at a given time.
  577.  
  578.    For example, a resolver that wanted to find out the hostname
  579.    corresponding to address 198.76.29.1 (externally)  would pursue a
  580.    query of the form:
  581.  
  582.         QTYPE = PTR, QCLASS = IN, QNAME = 1.29.76.198.IN-ADDR.ARPA.
  583.  
  584.    DNS_ALG would intervene and if the address 198.76.29.1 is internally
  585.    mapped to a private address of 10.0.0.1, modify the query as below
  586.    and forward to DMZ name server within private network.
  587.  
  588.         QTYPE = PTR, QCLASS = IN, QNAME = 1.0.0.10.IN-ADDR.ARPA
  589.  
  590.    Presumably, the DMZ name server is the authoritative name server for
  591.    10.IN-ADDR.ARPA zone and will respond with an RR of the following
  592.    form in answer section. DNS_ALG translations of the response RRs will
  593.    be considered in a following section.
  594.  
  595.         1.0.0.10.IN-ADDR.ARPA  PTR  host1.fooboo_org.provider_domain
  596.  
  597.    An example of Inverse translation is e-mail programs using inverse
  598.    translation to trace e-mail originating hosts for spam prevention.
  599.    Verify if the address from which the e-mail was sent does indeed
  600.    belong to the same domain name the sender claims in sender ID.
  601.  
  602.    Query modifications of this nature will likely change the length of
  603.    DNS payload. As a result, the corresponding IP and TCP/UDP header
  604.    checksums must be updated. In case of TCP based queries, the sequence
  605.    number deltas must be tracked by NAT so that the delta can be applied
  606.    to subsequent sequence numbers in datagrams in the same direction and
  607.    acknowledgement numbers in datagrams in the opposite direction. In
  608.    case of UDP based queries, message sizes are restricted to 512 bytes
  609.    (not counting the IP or UDP headers). Longer messages must be
  610.    truncated and the TC bit should be set in the header.
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Srisuresh, et al.            Informational                     [Page 11]
  619.  
  620. RFC 2694                 DNS extensions to NAT            September 1999
  621.  
  622.  
  623.    Lastly, any compressed domain names using pointers to represent
  624.    common domain denominations must be updated to reflect new pointers
  625.    with the right offset, if the original domain name had to be
  626.    translated by NAT.
  627.  
  628. 4.1.2. A, MX, NS and SOA type Queries
  629.  
  630.    For these queries, DNS_ALG would not modify any of the fields in the
  631.    query section, not even the name field.
  632.  
  633. 4.1.3. AXFR type Queries
  634.  
  635.    AXFR is a special zone transfer type query. Zone transfers from
  636.    private address realm must be avoided for address assignments that
  637.    are not static. Typically, TCP is used for AXFR requests.
  638.  
  639.    When changes are made to a zone, they must be distributed to all name
  640.    servers.  The general model of automatic zone transfer or refreshing
  641.    is that one of the name servers is the master or primary for the
  642.    zone.  Changes are coordinated at the primary, typically by editing a
  643.    master file for the zone.  After editing, the administrator signals
  644.    the master server to load the new zone.  The other non-master or
  645.    secondary servers for the zone periodically check the SERIAL field of
  646.    the SOA for the zone for changes (at some polling intervals) and
  647.    obtain new zone copies when changes have been made.
  648.  
  649.    Zone transfer is usually from primary to backup name servers. In the
  650.    case of NAT supported private networks, primary and backup servers
  651.    are advised to be located in the same private domain (say,
  652.    private.zone) so zone transfer is not across the domain and DNS_ALG
  653.    support for zone transfer is not an issue. In the case a secondary
  654.    name server is located outside the private domain, zone transfers
  655.    must not be permitted for non-static address assignments. Primary and
  656.    secondary servers are required to be within the same private domain
  657.    because all references to data in the zone had to be captured. With
  658.    dynamic address assignments and bindings, it is impossible to
  659.    translate the axfr data to be up-to-date. Hence, if a secondary
  660.    server for private.zone were to be located external to the domain, it
  661.    would contain bad data. Note, however, the requirement outlined here
  662.    is not in confirmence with RFC 2182, which recommends primary and
  663.    secondary servers to be placed at topologically and geographically
  664.    dispersed locations on the Internet.
  665.  
  666.    During zone transfers, DNS_ALG must examine all A type records and
  667.    replace the original address octets with their statically assigned
  668.    address octets. DNS_ALG could also examine if there is an attempt to
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Srisuresh, et al.            Informational                     [Page 12]
  675.  
  676. RFC 2694                 DNS extensions to NAT            September 1999
  677.  
  678.  
  679.    transfer records for hosts that are not assigned static addresses and
  680.    drop those records alone or drop the whole transfer. This would
  681.    minimize misconfiguration and human errors.
  682.  
  683. 4.1.4. Dynamic Updates to the DNS.
  684.  
  685.    An authoritative name server can have dynamic updates from the nodes
  686.    within the zone without intervention from NAT and DNS-ALG, so long as
  687.    one avoids spreading a DNS zone across address realms. We recommend
  688.    keeping a DNS zone within the same realm it is responsible for. By
  689.    doing this, DNS update traffic will not cross address realms and
  690.    hence will not be subject to consideration by DNS-ALG.
  691.  
  692.    Further, if dynamic updates do cross address realms, and the updates
  693.    must always be secured via DNSSEC, then such updates are clearly out
  694.    of scope for DNS-ALG (as described in section 7).
  695.  
  696. 4.2. Resource records in all other sections
  697.  
  698.    The answer, authority, and additional sections all share the same
  699.    format, with a variable number of resource records. The number of RRs
  700.    specific to each of the sections may be found in the corresponding
  701.    count fields in DNS header. Each resource record has the following
  702.    format:
  703.  
  704.    The TTL value supplied in the original RRs will be left unchanged for
  705.    static address assignments. For dynamic address assignments, DNS_ALG
  706.    will modify the TTL to be 0, so the RRs are used just for the
  707.    transaction in progress, and not cached.  RFC 2181 requires all RRs
  708.    in an RRset (RRs with the same name, class and type, but with
  709.    different RDATA) to have the same TTL. So if the TTL of an RR is set
  710.    to 0, all other RRs within the same RRset will also be adjusted by
  711.    the DNS-ALG to be 0.
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Srisuresh, et al.            Informational                     [Page 13]
  731.  
  732. RFC 2694                 DNS extensions to NAT            September 1999
  733.  
  734.  
  735.       0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  736.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  737.     |                                               |
  738.     /                                               /
  739.     /                      NAME                     /
  740.     |                                               |
  741.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  742.     |                      TYPE                     |
  743.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  744.     |                     CLASS                     |
  745.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  746.     |                      TTL                      |
  747.     |                                               |
  748.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  749.     |                   RDLENGTH                    |
  750.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
  751.     /                     RDATA                     /
  752.     /                                               /
  753.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  754.  
  755. 4.2.1. PTR type RRs
  756.  
  757.    The considerations specified in the Question section is equally valid
  758.    with names for PTR type RRs. Private address preceding the string
  759.    "IN-ADDR.ARPA" (in reverse order of octets) must be replaced by its
  760.    external address assignment (in reverse order), if a binding exists.
  761.    The remaining fields for this RR remain unchanged.
  762.  
  763. 4.2.2. A type RRs
  764.  
  765.    The RDATA for A records  is a 4-byte IP address. DNS_ALG would simply
  766.    replace the original address in RDATA with its externally assigned IP
  767.    address, if it succeeded in finding an address binding. Successful
  768.    address translation should cause no changes to payload length. Only
  769.    the transport header checksum would need updating. In case of failure
  770.    to find an address binding, DNS_ALG would have to drop the record and
  771.    decrement the corresponding COUNT field in the header section.
  772.  
  773. 4.2.3. CNAME, MX, NS and SOA type RRs
  774.  
  775.    No changes required to be made by DNS_ALG for these RRs, as the RDATA
  776.    does not contain any IP addresses. The host names within the RDATA
  777.    remain unchanged between realms.
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Srisuresh, et al.            Informational                     [Page 14]
  787.  
  788. RFC 2694                 DNS extensions to NAT            September 1999
  789.  
  790.  
  791. 5. Illustration of DNS_ALG in conjunction with Bi-directional NAT
  792.  
  793.    The following diagram illustrates the operation of DNS_ALG in a a
  794.    bi-directional NAT router. We will illustrate by walking through how
  795.    name lookup and reverse name lookup queries are processed.
  796.  
  797.                                              .
  798.                          ________________    .     External.com
  799.                         (                )   .
  800.                        (                  )  .   +-------------+
  801.             +--+      (      Internet      )-.---|Border Router|
  802.             |__|------ (                  )  .   +-------------+
  803.            /____\       (________________)   .          |
  804.             Root                 |           .          |
  805.          DNS Server              |           .     ---------------
  806.                          +---------------+   .       |         |
  807.                          |Provider Router|   .     +--+       +--+
  808.                          +---------------+   .     |__|       |__|
  809.                                  |           .    /____\     /____\
  810.                                  |           .  DNS Server   Host X
  811.        External domain           |           .  171.68.1.1  171.68.10.1
  812.      ............................|...............................
  813.        Private domain            |
  814.                                  |        Private.com
  815.                                  |
  816.                 +--------------------------------------+
  817.                 |Bi-Directional NAT router with DNS_ALG|
  818.                 |                                      |
  819.                 | Private addresses:  172.19/16        |
  820.                 | External addresses: 131.108.1/24     |
  821.                 +--------------------------------------+
  822.                               |      |
  823.                       ----------    ----------
  824.                         |                  |    DNS Server
  825.                        +--+               +--+  Authoritative
  826.                        |__|               |__|  for private.com
  827.                       /____\             /____\
  828.                       Host A           DNS Server
  829.                    172.19.1.10        172.19.2.1
  830.                                       (Mapped to 131.108.1.8)
  831.  
  832.     Figure 3: DNS-ALG operation in Bi-Directional NAT setup
  833.  
  834.    The above diagram depicts a scenario where a company private.com
  835.    using private address space 172.19/16 connects to the Internet using
  836.    bi-directional NAT. DNS_ALG is embedded in the NAT device to make
  837.    necessary DNS payload changes. NAT is configured to translate the
  838.    private addresses space into an external address block of
  839.  
  840.  
  841.  
  842. Srisuresh, et al.            Informational                     [Page 15]
  843.  
  844. RFC 2694                 DNS extensions to NAT            September 1999
  845.  
  846.  
  847.    131.108.1/24. NAT is also configured with a static translation for
  848.    private.com's DNS server, so it can be referred in the external
  849.    domain by a valid address.
  850.  
  851.    The company external.com is located in the external domain, using a
  852.    registered address block of 171.68/16.  Also shown in the topology is
  853.    a root DNS server.
  854.  
  855.    Following simplifications are made to the above configuration:
  856.  
  857.       *  private.com is not multihomed and all traffic to the external
  858.          space transits a single NAT.
  859.  
  860.       *  The DNS server for private.com is authoritative for the
  861.          private.com domain and points to the root server for all other
  862.          DNS resolutions.  The same is true for the DNS server in
  863.          external.com.
  864.  
  865.       *  The internal name servers for private.com and external.com are
  866.          same as their DMZ name servers. The DNS servers for these
  867.          domains are configured with addresses private to the
  868.          organization.
  869.  
  870.       *  The name resolvers on host nodes do not have recursion
  871.          available on them and desire recursive service from servers.
  872.          All name servers are assumed to be able to provide recursive
  873.          service.
  874.  
  875. 5.1. Outgoing Name-lookup queries
  876.  
  877.    Say, Host A in private.com needs to perform a name lookup for host X
  878.    in external.com to initiate a session with X.  This would proceed as
  879.    follows.
  880.  
  881.    1. Host A sends a UDP based name lookup query (A record) for
  882.       "X.External.Com" to its local DNS server.
  883.  
  884.    2. Local DNS server sends the query to the root server enroute NAT.
  885.       NAT would change the IP and UDP headers to reflect DNS server's
  886.       statically assigned external address.  DNS_ALG will make no
  887.       changes to the payload.
  888.  
  889.    3. The root server, in turn, refers the local DNS server to query the
  890.       DNS server for External.com. This referal transits the NAT enroute
  891.       to the local DNS server.  NAT would  simply translate the IP and
  892.       UDP headers of the incoming packet to reflect DNS server's private
  893.       address. No changes to the payload by DNS_ALG.
  894.  
  895.  
  896.  
  897.  
  898. Srisuresh, et al.            Informational                     [Page 16]
  899.  
  900. RFC 2694                 DNS extensions to NAT            September 1999
  901.  
  902.  
  903.    4. Private.com DNS server will now send the query to the DNS server
  904.       for external.com, once again, enroute NAT. Just as with the query
  905.       to root, The NAT router would change the IP and UDP headers to
  906.       reflect the DNS server's statically assigned external address.
  907.       And, DNS_ALG will make no changes to the payload.
  908.  
  909.    5. The DNS server for external.com replies with the IP address
  910.       171.68.10.1.  This reply also transits the NAT. NAT would
  911.       translate the IP and UDP headers of the incoming packet to reflect
  912.       DNS server's private address. Once again, no changes to the
  913.       payload by DNS_ALG.
  914.  
  915.    6. The DNS server in Private.com replies to host A.
  916.  
  917.    When Host A finds the address of Host X, A initiates a session with
  918.    host X, using a destination IP address of 171.68.10.1. This datagram
  919.    and any others that follow in this session will be translated as
  920.    usual by NAT.
  921.  
  922.    Note, DNS_ALG does not change the payload for DNS packets in either
  923.    direction.
  924.  
  925. 5.2. Reverse name lookups originated from private domain
  926.  
  927.    This scenario builds on the previous case by having host A in
  928.    Private.com perform a reverse name lookup on 171.68.10.1, which is
  929.    host X's global address. Following is a sequence of events.
  930.  
  931.    1. Host A sends a UDP based inverse name lookup query (PTR record)
  932.       for "1.10.68.171.IN-ADDR.ARPA." to its local DNS server.
  933.  
  934.    2. Local DNS server sends the query to the root server enroute NAT.
  935.       As before, NAT would change the IP and UDP headers to reflect DNS
  936.       server's statically assigned external address.  DNS_ALG will make
  937.       no changes to the payload.
  938.  
  939.    3. The root server, in turn, refers the local DNS server to query the
  940.       DNS server for External.com. This referal transits the NAT enroute
  941.       to the local DNS server.  NAT would  simply translate the IP and
  942.       UDP headers of the incoming packet to reflect DNS server's private
  943.       address. No changes to the payload by DNS_ALG.
  944.  
  945.    4. Private.com DNS server will now send the query to the DNS server
  946.       for external.com, once again, enroute NAT. Just as with the query
  947.       to root, The NAT router would change the IP and UDP headers to
  948.       reflect the DNS server's statically assigned external address.
  949.       And, DNS_ALG will make no changes to the payload.
  950.  
  951.  
  952.  
  953.  
  954. Srisuresh, et al.            Informational                     [Page 17]
  955.  
  956. RFC 2694                 DNS extensions to NAT            September 1999
  957.  
  958.  
  959.    5. The DNS server for external.com replies with the host name of
  960.       "X.External.Com.". This reply also transits the NAT. NAT would
  961.       translate the IP and UDP headers of the incoming packet to reflect
  962.       DNS server's private address. Once again, no changes to the
  963.       payload by DNS_ALG.
  964.  
  965.    6. The DNS server in Private.com replies to host A.
  966.  
  967.    Note, DNS_ALG does not change the payload in either direction.
  968.  
  969. 5.3. Incoming Name-lookup queries
  970.  
  971.    This time, host X in external.com wishes to initiate a session with
  972.    host A in Private.com. Below are the sequence of events that take
  973.    place.
  974.  
  975.    1. Host X sends a UDP based name lookup query  (A record) for
  976.       "A.Private.com" to its local DNS server.
  977.  
  978.    2. Local DNS server in External.com sends the query to root server.
  979.  
  980.    3. The root server, in turn, refers the DNS server in External.com to
  981.       query the DNS server for private.com,
  982.  
  983.    4. External.com DNS server will now send the query to the DNS server
  984.       for Private.com. This query traverses the NAT router. NAT would
  985.       change the IP and UDP headers of the packet to reflect the DNS
  986.       server's private address. DNS_ALG will make no changes to the
  987.       payload.
  988.  
  989.    5. The DNS server for Private.com replies with the IP address
  990.       172.19.1.10 for host A.  This reply also transits the NAT. NAT
  991.       would translate the IP and UDP headers of the outgoing packet from
  992.       the DNS server.
  993.  
  994.       DNS_ALG will request NAT to (a) setup a temporary binding for Host
  995.       A (172.19.1.10) with an external address and (b) initiate Bind-
  996.       holdout timer. When NAT successfully sets up a temporary binding
  997.       with an external address (say, 131.108.1.12), DNS_ALG would modify
  998.       the payload to replace A's private address with its external
  999.       assigned address and set the Cache timeout to 0.
  1000.  
  1001.    6. The server in External.com replies to host X
  1002.  
  1003.    When Host X finds the address of Host A, X initiates a session with
  1004.    A, using a destination IP address of 131.108.1.12. This datagram and
  1005.    any others that follow in this session will be translated as usual by
  1006.    the NAT.
  1007.  
  1008.  
  1009.  
  1010. Srisuresh, et al.            Informational                     [Page 18]
  1011.  
  1012. RFC 2694                 DNS extensions to NAT            September 1999
  1013.  
  1014.  
  1015.    Note, DNS_ALG changes only the response packets from the DNS server
  1016.    for Private domain.
  1017.  
  1018. 5.4. Reverse name lookups originated from external domain
  1019.  
  1020.    This scenario builds on the previous case (section 5.3) by having
  1021.    host X in External.com perform a reverse name lookup on 131.108.1.12,
  1022.    which is host A's assigned external address. The following sequence
  1023.    of events take place.
  1024.  
  1025.    1. Host X sends a UDP based inverse name lookup query (PTR record)
  1026.       for "12.1.108.131.IN-ADDR.ARPA." to its local DNS server.
  1027.  
  1028.    2. Local DNS server in External.com sends the query to the root
  1029.       server.
  1030.  
  1031.    3. The root server, in turn, refers the local DNS server to query the
  1032.       DNS server for Private.com.
  1033.  
  1034.    4. External.com DNS server will now send the query to the DNS server
  1035.       for Private.com. This query traverses the NAT router. NAT would
  1036.       change the IP and UDP headers to reflect the DNS server's private
  1037.       address.
  1038.  
  1039.       DNS_ALG will enquire NAT for the private address associated with
  1040.       the external address of 131.108.1.12 and modify the payload,
  1041.       replacing 131.108.1.12 with the private address of 172.19.1.10.
  1042.  
  1043.    5. The DNS server for Private.com replies with the host name of
  1044.       "A.Private.Com.". This reply also transits the NAT. NAT would
  1045.       translate the IP and UDP headers of the incoming packet to reflect
  1046.       DNS server's private address.
  1047.  
  1048.       Once again, DNS_ALG will enquire NAT for the assigned external
  1049.       address associated with the private address of 172.19.1.10 and
  1050.       modify the payload, replacing 172.19.1.10 with the assigned
  1051.       external address of 131.108.1.12.
  1052.  
  1053.    6. The DNS server in External.com replies to host X.
  1054.  
  1055.    Note, DNS_ALG changes the query as well as response packets from DNS
  1056.    server for Private domain.
  1057.  
  1058. 6. Illustration of DNS_ALG in conjunction with Twice-NAT
  1059.  
  1060.    The following diagram illustrates the operation of DNS_ALG in a Twice
  1061.    NAT router. As before, we will illustrate by walking through how name
  1062.    lookup and reverse name lookup queries are processed.
  1063.  
  1064.  
  1065.  
  1066. Srisuresh, et al.            Informational                     [Page 19]
  1067.  
  1068. RFC 2694                 DNS extensions to NAT            September 1999
  1069.  
  1070.  
  1071.                                              .
  1072.                          ________________    .     External.com
  1073.                         (                )   .
  1074.                        (                  )  .   +-------------+
  1075.             +--+      (      Internet      )-.---|Border Router|
  1076.             |__|------ (                  )  .   +-------------+
  1077.            /____\       (________________)   .          |
  1078.             Root                 |           .          |
  1079.          DNS Server              |           .     ---------------
  1080.                          +---------------+   .       |         |
  1081.                          |Provider Router|   .     +--+       +--+
  1082.                          +---------------+   .     |__|       |__|
  1083.                                  |           .    /____\     /____\
  1084.                                  |           .  DNS Server   Host X
  1085.        External domain           |           .  171.68.1.1  171.68.10.1
  1086.      ............................|...............................
  1087.        Private domain            |
  1088.                                  |        Private.com
  1089.                                  |
  1090.                 +-------------------------------------------+
  1091.                 | Twice-NAT router with DNS_ALG             |
  1092.                 |                                           |
  1093.                 | Private addresses:  171.68/16             |
  1094.                 | Assigned External addresses: 131.108.1/24 |
  1095.                 |                                           |
  1096.                 | External addresses:  171.68/16            |
  1097.                 | Assigned Private addresses: 10/8          |
  1098.                 +-------------------------------------------+
  1099.                               |      |
  1100.                       ----------    ----------
  1101.                         |                  |    DNS Server
  1102.                        +--+               +--+  Authoritative
  1103.                        |__|               |__|  for private.com
  1104.                       /____\             /____\
  1105.                       Host A           DNS Server
  1106.                    171.68.1.10        171.68.2.1
  1107.                                       (Mapped to 131.108.1.8)
  1108.  
  1109.     Figure 4: DNS-ALG operation in Twice-NAT setup
  1110.  
  1111.    In this scenario, hosts in private.com were not numbered from the RFC
  1112.    1918 reserved 172.19/16 space, but rather were numbered with the
  1113.    globally-routable 171.68/16 network, the same as external.com.  Not
  1114.    only does private.com need translation service for its own host
  1115.    addresses, but it also needs translation service if any of those
  1116.    hosts are to be able to exchange datagrams with hosts in
  1117.    external.com. Twice-NAT accommodates the transition by translating
  1118.    the overlapping address space used in external.com with a unique
  1119.  
  1120.  
  1121.  
  1122. Srisuresh, et al.            Informational                     [Page 20]
  1123.  
  1124. RFC 2694                 DNS extensions to NAT            September 1999
  1125.  
  1126.  
  1127.    address block (10/8) from RFC 1918 address space. Routes are set up
  1128.    within the private domain to direct datagrams destined for the
  1129.    address block 10/8 through Twice-NAT device to the external global
  1130.    network space.
  1131.  
  1132.    Simplifications and assumptions made in section 5.0 will be valid
  1133.    here as well.
  1134.  
  1135. 6.1. Outgoing Name-lookup queries
  1136.  
  1137.    Say, Host A in private.com needs to perform a name lookup for host X
  1138.    in external.com (host X has a FQDN of X.external.com), to find its
  1139.    address.  This would would proceed as follows.
  1140.  
  1141.    1. Host A sends a UDP based name lookup query (A record) for
  1142.       "X.External.Com" to its local DNS server.
  1143.  
  1144.    2. Local DNS server sends the query to the root server enroute NAT.
  1145.       NAT would change the IP and UDP headers to reflect DNS server's
  1146.       statically assigned external address.  DNS_ALG will make no
  1147.       changes to the payload.
  1148.  
  1149.    3. The root server, in turn, refers the local DNS server to query the
  1150.       DNS server for External.com. This referal transits the NAT enroute
  1151.       to the local DNS server.  NAT would  simply translate the IP and
  1152.       UDP headers of the incoming packet to reflect DNS server's private
  1153.       address.
  1154.  
  1155.       DNS_ALG will request NAT for an assigned private address for the
  1156.       referral server and replace the external address with its assigned
  1157.       private address in the payload.
  1158.  
  1159.    4. Private.com DNS server will now send the query to the DNS server
  1160.       for external.com, using its assigned private address, via NAT.
  1161.       This time, NAT would change the IP and UDP headers to reflect the
  1162.       External addresses of the DNS servers. I.e., Private.com DNS
  1163.       server's IP address is changed to its assigned external address
  1164.       and External.Com DNS server's assigned Private address is changed
  1165.       to its external address.
  1166.  
  1167.       DNS_ALG will make no changes to the payload.
  1168.  
  1169.    5. The DNS server for external.com replies with the IP address
  1170.       171.68.10.1.  This reply also transits the NAT. NAT would once
  1171.       again translate the IP and UDP headers of the incoming to reflect
  1172.       the private addresses of the DNS servers.  I.e., Private.com DNS
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Srisuresh, et al.            Informational                     [Page 21]
  1179.  
  1180. RFC 2694                 DNS extensions to NAT            September 1999
  1181.  
  1182.  
  1183.       server's IP address is changed to its private address and
  1184.       External.Com DNS server's external address is changed to its
  1185.       assigned Private address.
  1186.  
  1187.       DNS_ALG will request NAT to (a) set up a temporary binding for
  1188.       Host X (171.68.10.1) with a private address and (b) initiate
  1189.       Bind-holdout timer. When NAT successfully sets up temporary
  1190.       binding with a private address (say, 10.0.0.254), DNS_ALG would
  1191.       modify the payload to replace X's external address with its
  1192.       assigned private address and set the Cache timeout to 0.
  1193.  
  1194.    6. The DNS server in Private.com replies to host A.
  1195.  
  1196.    When Host A finds the address of Host X, A initiates a session with
  1197.    host X, using a destination IP address of 10.0.0.254. This datagram
  1198.    and any others that follow in this session will be translated as
  1199.    usual by Twice NAT.
  1200.  
  1201.    Note, the DNS_ALG has had to change payload in both directions.
  1202.  
  1203. 6.2. Reverse name lookups originated from private domain
  1204.  
  1205.    This scenario builds on the previous case by having host A in
  1206.    Private.com perform a reverse name lookup on 10.0.0.254, which is
  1207.    host X's assigned private address. Following is a sequence of events.
  1208.  
  1209.    1. Host A sends a UDP based inverse name lookup query (PTR record)
  1210.       for "254.0.0.10.IN-ADDR.ARPA." to its local DNS server.
  1211.  
  1212.    2. Local DNS server sends the query to the root server enroute NAT.
  1213.       As before, NAT would change the IP and UDP headers to reflect DNS
  1214.       server's statically assigned external address.
  1215.  
  1216.       DNS_ALG will translate the private assigned address 10.0.0.254
  1217.       with its external address 171.68.10.1.
  1218.  
  1219.    3. The root server, in turn, refers the local DNS server to query the
  1220.       DNS server for External.com. This referal transits the NAT enroute
  1221.       to the local DNS server.  NAT would  simply translate the IP and
  1222.       UDP headers of the incoming packet to reflect DNS server's private
  1223.       address.
  1224.  
  1225.       As with the original query, DNS_ALG will translate the private
  1226.       assigned address 10.0.0.254 with its external address 171.68.10.1.
  1227.       In addition, DNS_ALG will replace the external address of the
  1228.       referal server (i.e., the DNS server for External.com) with its
  1229.       assigned private address in the payload.
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Srisuresh, et al.            Informational                     [Page 22]
  1235.  
  1236. RFC 2694                 DNS extensions to NAT            September 1999
  1237.  
  1238.  
  1239.    4. Private.com DNS server will now send the query to the DNS server
  1240.       for external.com, using its statically assigned private address,
  1241.       via NAT. This time, NAT would change the IP and UDP headers to
  1242.       reflect the External addresses of the DNS servers. I.e.,
  1243.       Private.com DNS server's IP address is changed to its assigned
  1244.       external address and External.Com DNS server's assigned Private
  1245.       address is changed to its external address.
  1246.  
  1247.       As with the original query, DNS_ALG will translate the private
  1248.       assigned address 10.0.0.254 with its external address 171.68.10.1.
  1249.  
  1250.    5. The DNS server for external.com replies with the FQDN of
  1251.       "X.External.Com.".  This reply also transits the NAT. NAT would
  1252.       once again translate the IP and UDP headers of the incoming to
  1253.       reflect the private addresses of the DNS servers.  I.e.,
  1254.       Private.com DNS server's IP address is changed to its private
  1255.       address and External.Com DNS server's external address is changed
  1256.       to its assigned Private address.
  1257.  
  1258.       Once again, DNS_ALG will translate the query section, replacing
  1259.       the external address 171.68.10.1 with its assigned private address
  1260.       of 10.0.0.254
  1261.  
  1262.    6. The DNS server in Private.com replies to host A.
  1263.  
  1264.    Note, the DNS_ALG has had to change payload in both directions.
  1265.  
  1266. 6.3. Incoming Name-lookup queries
  1267.  
  1268.    This time, host X in external.com wishes to initiate a session with
  1269.    host A in Private.com. Below are the sequence of events that take
  1270.    place.
  1271.  
  1272.    1. Host X sends a UDP based name lookup query  (A record) for
  1273.       "A.Private.com" to its local DNS server.
  1274.  
  1275.    2. Local DNS server in External.com sends the query to root server.
  1276.  
  1277.    3. The root server, in turn, refers the DNS server in External.com to
  1278.       query the DNS server for private.com,
  1279.  
  1280.    4. External.com DNS server will now send the query to the DNS server
  1281.       for Private.com. This query traverses the NAT router. NAT would
  1282.       change the IP and UDP headers to reflect the private addresses of
  1283.       the DNS servers. I.e., Private.com DNS server's IP address is
  1284.       changed to its  private address and External.Com DNS server's
  1285.       external address is changed to assigned Private address.
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Srisuresh, et al.            Informational                     [Page 23]
  1291.  
  1292. RFC 2694                 DNS extensions to NAT            September 1999
  1293.  
  1294.  
  1295.       DNS_ALG will make no changes to the payload.
  1296.  
  1297.    5. The DNS server for Private.com replies with the IP address
  1298.       171.68.1.10 for host A.  This reply also transits the NAT. NAT
  1299.       would once again translate the IP and UDP headers of the incoming
  1300.       to reflect the external addresses of the DNS servers.  I.e.,
  1301.       Private.com DNS server's IP address is changed to its assigned
  1302.       external address and External.Com DNS server's assigned private
  1303.       address is changed to its external address.
  1304.  
  1305.       DNS_ALG will request NAT to (a) set up temporary binding for Host
  1306.       A (171.68.1.10) with an external address and (b) initiate Bind-
  1307.       holdout timer. When NAT succeeds in finding an external address
  1308.       (say, 131.108.1.12) to temporarily bind to host A, DNS_ALG would
  1309.       modify the payload to replace A's private address with its
  1310.       external assigned address and set the Cache timeout to 0.
  1311.  
  1312.    6. The server in External.com replies to host X
  1313.  
  1314.    When Host X finds the address of Host A, X initiates a session with
  1315.    A, using a destination IP address of 131.108.1.12. This datagram and
  1316.    any others that follow in this session will be translated as usual by
  1317.    the NAT.
  1318.  
  1319.    Note, DNS_ALG changes only the response packets from the DNS server
  1320.    for Private domain.
  1321.  
  1322. 6.4. Reverse name lookups originated from external domain
  1323.  
  1324.    This scenario builds on the previous case (section 6.3) by having
  1325.    host X in External.com perform a reverse name lookup on 131.108.1.12,
  1326.    which is host A's assigned external address. The following sequence
  1327.    of events take place.
  1328.  
  1329.    1. Host X sends a UDP based inverse name lookup query (PTR record)
  1330.       for "12.1.108.131.IN-ADDR.ARPA." to its local DNS server.
  1331.  
  1332.    2. Local DNS server in External.com sends the query to the root
  1333.       server.
  1334.  
  1335.    3. The root server, in turn, refers the local DNS server to query the
  1336.       DNS server for Private.com.
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346. Srisuresh, et al.            Informational                     [Page 24]
  1347.  
  1348. RFC 2694                 DNS extensions to NAT            September 1999
  1349.  
  1350.  
  1351.    4. External.com DNS server will now send the query to the DNS server
  1352.       for Private.com. This query traverses the NAT router. NAT would
  1353.       change the IP and UDP headers to reflect the private addresses of
  1354.       the DNS servers. I.e., Private.com DNS server's IP address is
  1355.       changed to its  private address and External.Com DNS server's
  1356.       external address is changed to assigned Private address.
  1357.  
  1358.       DNS_ALG will enquire NAT for the private address associated with
  1359.       the external address of 131.108.1.12 and modify the payload,
  1360.       replacing 131.108.1.12 with the private address of 171.68.1.10.
  1361.  
  1362.    5. The DNS server for Private.com replies with the host name of
  1363.       "A.Private.Com.". This reply also transits the NAT. NAT would once
  1364.       again translate the IP and UDP headers of the incoming to reflect
  1365.       the external addresses of the DNS servers.  I.e., Private.com DNS
  1366.       server's IP address is changed to its assigned external address
  1367.       and External.Com DNS server's assigned private address is changed
  1368.       to its external address.
  1369.  
  1370.       Once again, DNS_ALG will enquire NAT for the assigned external
  1371.       address associated with the private address of 172.19.1.10 and
  1372.       modify the payload, replacing 171.68.1.10 with the assigned
  1373.       external address of 131.108.1.12.
  1374.  
  1375.    6. The DNS server in External.com replies to host X.
  1376.  
  1377.    Note, DNS_ALG changes the query as well as response packets from DNS
  1378.    server for Private domain.
  1379.  
  1380. 7. DNS-ALG limitations and Future Work
  1381.  
  1382.    NAT increases the probability of mis-addressing. For example, same
  1383.    local address may be bound to different public address at different
  1384.    times and vice versa. As a result, hosts that cache the name to
  1385.    address mapping for longer periods than the NAT router is configured
  1386.    to hold the map are likely to misaddress their sessions. Note, this
  1387.    is mainly an issue with bad host implementations that hold DNS
  1388.    records longer than the TTL in them allows and is not directly
  1389.    attributable to the mechanism described here.
  1390.  
  1391.    DNS_ALG cannot support secure DNS name servers in the private domain.
  1392.    I.e., Signed replies from an authoritative DNS name server in the DMZ
  1393.    to queries originating from the external world will be broken by the
  1394.    DNS-ALG. At best, DNS-ALG would be able to transform secure dnssec
  1395.    data into unprotected data. End-node demanding DNS replies to be
  1396.    signed may reject replies that have been tampered with by DNS_ALG.
  1397.    Since, the DNS server does not have a way to find where the queries
  1398.    come from (i.e., internal or external), it will most likely have to
  1399.  
  1400.  
  1401.  
  1402. Srisuresh, et al.            Informational                     [Page 25]
  1403.  
  1404. RFC 2694                 DNS extensions to NAT            September 1999
  1405.  
  1406.  
  1407.    resort to the common denomination of today's insecure DNS. Both are
  1408.    serious limitations to DNS_ALG. Zone transfers between DNS-SEC
  1409.    servers  is also impacted the same way, if the transfer crosses
  1410.    address realms.
  1411.  
  1412.    The good news, however, is that only end-nodes in DMZ pay the price
  1413.    for the above limitation in a traditional NAT (or, a bi-directional
  1414.    NAT), as external end-nodes may not access internal hosts due to DNS
  1415.    replies not being secure. However, for outgoing sessions (from
  1416.    private network) in a bi-directional NAT setup, the DNS queries can
  1417.    be signed and securely accepted by DMZ and other internal hosts since
  1418.    DNS_ALG does not intercept outgoing DNS queries and incoming replies.
  1419.    Lastly, zone transfers between DNS-SEC servers  within the same
  1420.    private network are not impacted.
  1421.  
  1422.    Clearly, with DNS SEC deployment in DNS servers and end-host
  1423.    resolvers, the scheme suggested in this document will not work.
  1424.  
  1425. 8. Security Considerations
  1426.  
  1427.    If DNS packets are encrypted/authenticated per DNSSEC, then DNS_ALG
  1428.    will fail because it won't be able to perform payload modifications.
  1429.    Alternately, if packets must be preserved in an address realm,
  1430.    DNS_ALG will need to hold the secret key to decrypt/verify payload
  1431.    before forwarding packets to a different realm. For example, if DNS-
  1432.    ALG, NAT and IPsec gateway (providing secure tunneling service) are
  1433.    resident on the same device, DNS-ALG will have access to the IPsec
  1434.    security association keys.  The preceding section, "DNS-ALG
  1435.    limitations and Future Work" has coverage on DNS_ALG security
  1436.    considerations.
  1437.  
  1438.    Further, with DNS-ALG, there is a possibility of denial of service
  1439.    attack from a malicious user, as outlined in section 3.1.  Section
  1440.    3.1 suggests some ways to counter this attack.
  1441.  
  1442. REFERENCES
  1443.  
  1444.     [1] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
  1445.         (NAT) Terminology and Considerations", RFC 2663, August 1999.
  1446.  
  1447.     [2] Egevang, K. and  P. Francis, "The IP Network Address Translator
  1448.         (NAT)", RFC 1631, May 1994.
  1449.  
  1450.     [3] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E.
  1451.         Lear, "Address Allocation for Private Internets", BCP 5, RFC
  1452.         1918, February 1996.
  1453.  
  1454.  
  1455.  
  1456.  
  1457.  
  1458. Srisuresh, et al.            Informational                     [Page 26]
  1459.  
  1460. RFC 2694                 DNS extensions to NAT            September 1999
  1461.  
  1462.  
  1463.     [4] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
  1464.         13, RFC 1034, November 1987.
  1465.  
  1466.     [5] Mockapetris, P., "Domain Names - Implementation and
  1467.         Specification", STD 13, RFC 1035, November 1987.
  1468.  
  1469.     [6] Reynolds J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
  1470.         October 1994.
  1471.  
  1472.     [7] Braden, R., "Requirements for Internet Hosts -- Communication
  1473.         Layers", STD 3, RFC 1122, October 1989.
  1474.  
  1475.     [8] Braden, R., "Requirements for Internet Hosts -- Application and
  1476.         Support", STD 3, RFC 1123, October 1989.
  1477.  
  1478.     [9] Baker, F., "Requirements for IP Version 4 Routers",  RFC 1812,
  1479.         June 1995.
  1480.  
  1481.    [10] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
  1482.         Behaviour Today", RFC 2101, February 1997.
  1483.  
  1484.    [11] Eastlake, D., "Domain Name System Security Extensions", RFC
  1485.         2535, March 1999.
  1486.  
  1487.    [12] Vixie, P., Thompson, S., Rekhter Y. and J. Bound, "Dynamic
  1488.         Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
  1489.         1997.
  1490.  
  1491.    [13] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
  1492.         2137, April 1997.
  1493.  
  1494.    [14] Elz R. and R. Bush, "Clarifications to the DNS specification",
  1495.         RFC 2181, July 1997.
  1496.  
  1497.    [15] Elz, R., R. Bush, Bradner S. and M. Patton, "Selection and
  1498.         Operation of Secondary DNS Servers", RFC 2182, July 1997.
  1499.  
  1500.  
  1501.  
  1502.  
  1503.  
  1504.  
  1505.  
  1506.  
  1507.  
  1508.  
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514. Srisuresh, et al.            Informational                     [Page 27]
  1515.  
  1516. RFC 2694                 DNS extensions to NAT            September 1999
  1517.  
  1518.  
  1519. Authors' Addresses
  1520.  
  1521.    Pyda Srisuresh
  1522.    849 Erie Circle
  1523.    Milpitas, CA 95035
  1524.    U.S.A.
  1525.  
  1526.    Phone: +1 (408) 263-7527
  1527.    EMail: srisuresh@yahoo.com
  1528.  
  1529.  
  1530.    George Tsirtsis
  1531.    Internet Transport Group
  1532.    B29 Room 129
  1533.    BT Laboratories
  1534.    Martlesham Heath
  1535.    IPSWICH
  1536.    Suffolk IP5 3RE
  1537.    England
  1538.  
  1539.    Phone: +44 1473 640756
  1540.    Fax:   +44 1473 640709
  1541.    EMail: george@gideon.bt.co.uk
  1542.  
  1543.  
  1544.    Praveen Akkiraju
  1545.    cisco Systems
  1546.    170 West Tasman Drive
  1547.    San Jose, CA  95134  USA
  1548.  
  1549.    Phone: +1 (408) 526-5066
  1550.    EMail: spa@cisco.com
  1551.  
  1552.  
  1553.    Andy Heffernan
  1554.    Juniper Networks, Inc.
  1555.    385 Ravensdale Drive.
  1556.    Mountain View, CA  94043  USA
  1557.  
  1558.    Phone: +1 (650) 526-8037
  1559.    Fax:   +1 (650) 526-8001
  1560.    EMail: ahh@juniper.net
  1561.  
  1562.  
  1563.  
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569.  
  1570. Srisuresh, et al.            Informational                     [Page 28]
  1571.  
  1572. RFC 2694                 DNS extensions to NAT            September 1999
  1573.  
  1574.  
  1575. Full Copyright Statement
  1576.  
  1577.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  1578.  
  1579.    This document and translations of it may be copied and furnished to
  1580.    others, and derivative works that comment on or otherwise explain it
  1581.    or assist in its implementation may be prepared, copied, published
  1582.    and distributed, in whole or in part, without restriction of any
  1583.    kind, provided that the above copyright notice and this paragraph are
  1584.    included on all such copies and derivative works.  However, this
  1585.    document itself may not be modified in any way, such as by removing
  1586.    the copyright notice or references to the Internet Society or other
  1587.    Internet organizations, except as needed for the purpose of
  1588.    developing Internet standards in which case the procedures for
  1589.    copyrights defined in the Internet Standards process must be
  1590.    followed, or as required to translate it into languages other than
  1591.    English.
  1592.  
  1593.    The limited permissions granted above are perpetual and will not be
  1594.    revoked by the Internet Society or its successors or assigns.
  1595.  
  1596.    This document and the information contained herein is provided on an
  1597.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  1598.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  1599.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  1600.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  1601.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  1602.  
  1603. Acknowledgement
  1604.  
  1605.    Funding for the RFC Editor function is currently provided by the
  1606.    Internet Society.
  1607.  
  1608.  
  1609.  
  1610.  
  1611.  
  1612.  
  1613.  
  1614.  
  1615.  
  1616.  
  1617.  
  1618.  
  1619.  
  1620.  
  1621.  
  1622.  
  1623.  
  1624.  
  1625.  
  1626. Srisuresh, et al.            Informational                     [Page 29]
  1627.  
  1628.