GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2694

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:
 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
 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
 necessary because the DNS_ALG will allow external users to create
 state on NAT, and thus the potential for denial-of-service attacks.
 Temporary address binding is the phase in which an address binding is
 reserved without any NAT sessions using the binding. Committed
 address binding is the phase in which there exists at least one NAT
 session using the binding between the external and private addresses.
 Both types of bindings are used by DNS_ALG to modify DNS payloads.
 NAT uses only the committed address bindings to modify the IP and
 Transport headers of datagrams pertaining to NAT sessions.
 For statically mapped addresses, the above distinction is not
 relevant. For dynamically mapped addresses, temporary address binding
 often precedes committed binding. Temporary binding occurs when DMZ
 name server is queried for a name lookup. Name query is likely a
 pre-cursor to a real session between query originator and the queried
 host. The temporary binding becomes committed only when NAT sees the
 first packet of a session between query initiator and queried host.
 A configurable parameter, "Bind-holdout time" may be defined for
 dynamic address assignments as the maximum period of time for which a
 temporary address binding is held active without transitioning into a
 committed binding. With each use of temporary binding by DNS_ALG (to
 modify DNS payload), this Bind-holdout period is renewed. A default
 Bind-holdout time of a couple of minutes might suffice for most DNS-
 ALG implementations. Note, it is possible for a committed address

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

 binding to occur without ever having to be preceded by a temporary
 binding. Lastly, when NAT is ready to unbind a committed address
 binding, the binding is transitioned into a temporary binding and
 kept in that phase for an additional Bind-holdout period. The binding
 is freed only upon expiry of Bind-holdout time. The Bind-holdout time
 preceding the committed-address-binding and the address-unbinding are
 required to ensure that end hosts have sufficient time in which to
 initiate a data session subsequent to a name lookup.
 For example, say a private network with address prefix 10/8 is mapped
 to 198.76.29/24. When an external hosts makes a DNS query to host7,
 bearing address 10.0.0.7, the DMZ name server within private network
 responds with an A type RR for host7 as:
     host7  A  10.0.0.7
 DNS_ALG would intercept the response packet and if 10.0.0.7 is not
 assigned an external address already, it would request NAT to create
 a temporary address binding with an external address and start Bind-
 holdout timer to age the binding. Say, the assigned external address
 is 198.76.29.1. DNS-ALG would use this temporary binding to modify
 the RR in DNS response, replacing 10.0.0.7 with its external address
 and reply with:
     host7  A  198.76.29.1
 When query initiator receives DNS response, only the assigned
 external address is seen. Within a short period (presumably before
 the bind-holdout time expires), the query initiator would initiate a
 session with host7. When NAT notices the start of new session
 directed to 198.76.29.1, NAT would terminate Bind-holdout timer and
 transition the temporary binding between 198.76.29.1 and 10.0.0.7
 into a committed binding.
 To minimize denial of service attacks, where a malicious user keeps
 attempting name resolutions, without ever initiating a connection,
 NAT would have to monitor temporary address bindings that have not
 transitioned into committed bindings. There could be a limit on the
 number of temporary bindings and attempts to generate additional
 temporary bindings could be simply rejected.  There may be other
 heuristic solutions to counter this type of malicious attacks.
 We will consider bi-directional NAT to illustrate the use of
 temporary binding by DNS_ALG in the following sub-sections, even
 though the concept is applicable to other flavors of NATs as well.

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

3.2. Incoming queries

 In order to initiate incoming sessions, an external host obtains the
 V4 address of the DMZ-host it is trying to connect to by making a DNS
 request.  This request constitutes prelude to the start of a
 potential new session.
 The external host resolver makes a name lookup for the DMZ host
 through its DNS server.  When the DNS server does not have a record
 of IPv4 address attached to this name, the lookup query is redirected
 at some point to the Primary/Backup DNS server (i.e., in DMZ) of the
 private stub domain.
 Enroute to DMZ name server, DNS_ALG would intercept the datagram and
 modify the query as follows.
    a) For Host name to Host address query requests:
       Make no change to the DNS payload.
    b) For Host address to Host name queries:  Replace the external V4
       address octets (in reverse order) preceding the string "IN-
       ADDR.ARPA"  with the corresponding private V4 address, if such
       an address binding exists already. However, if a binding does
       not exist, the DNS_ALG would simply respond (as a name server
       would) with a response code (RCODE) of 5 (REFUSED to respond
       due to policy reasons) and set ANCOUNT, NSCOUNT and ARCOUT to 0
       in the header section of the response.
 In the opposite direction, as DNS response traverses from the DNS
 server in private network, DNS_ALG would once again intercept the
 packet and modify as follows.
    a) For a host name to host address query requests, replace the
       private address sent by DMZ name server with a public address
       internally assigned by the NAT router. If a public address is
       not previously assigned to the host's private address, NAT
       would assign one at this time.
    b) For host address to host name queries, replace the private
       address octets preceding the string "IN-ADDR.ARPA" in response
       RRs with their external address assignments.  There is a chance
       here that by the time the DMZ name server replies, the bind-
       holdout timer in NAT for the address in question has expired.
       In such a case, DNS_ALG would simply drop the reply. The sender
       will have to resend the query (as would happen when a router
       enroute drops the response).

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

 For static address assignments, the TTL value supplied in the
 original RR will be left unchanged. For dynamic address assignments,
 DNS_ALG would modify the TTL value on DNS resource records (RRs) to
 be 0, implying that the RRs should only be used for transaction in
 progress, and not be cached. For compatibility with broken
 implementations, TTL of 1 might in practice work better.
 Clearly, setting TTL to be 0 will create more traffic than if the
 addresses were static, because name-to-address mapping is not cached.
 Specifically, network based applications will be required to use
 names rather than addresses for identifying peer nodes and must use
 DNS for every name resolution, as name-to-address mapping cannot be
 shared from the previously run applications.
 In addition, NAT would be requested to initiate a bind-holdout timer
 following the assignment. If no session is initiated to the private
 host within the Bind-holdout time period, NAT would terminate the
 temporary binding.

3.3. Outgoing Queries

 For Basic and bi-directional NATs, there is no need to distinguish
 between temporary and committed bindings for outgoing queries. This
 is because, DNS_ALG does not modify the DNS packets directed to or
 from external name servers (used during outbound sessions), unlike
 the inbound DNS sessions.
 Say, a private host needs to communicate with an external host.  The
 DNS query  goes  to  the internal name server (if there exists one)
 and from there to the appropriate authoritative/cache name server
 outside the private domain.  The  reply follows the same route but
 neither the query nor the response are subject to DNS_ALG
 translations.
 This however will not be the case with address isolated twice NAT
 private and external domains. In such a case, NAT would intercept all
 DNS packets and make address modifications to payload as discussed in
 the previous section. Temporary Private to external address bindings
 are created when responses are sent by private DNS servers and
 temporary external to private address bindings are created when
 responses are sent by external DNS servers.

4. DNS payload modifications by DNS-ALG

 Typically, UDP is employed as the transport mechanism for DNS queries
 and responses and TCP for Zone refresh activities. In either case,
 name servers are accessed using a well-known DNS server port 53
 (decimal) and all DNS payloads have the following format of data [Ref

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

 4]. While NAT is responsible for the translation of IP and TCP/UDP
 headers of a DNS packet, DNS-ALG is responsible for updating the DNS
 payload.
 The header section within the DNS payload is always present and
 includes fields specifying which of the remaining sections are
 present. The header identifies if the message is a query or a
 response. No changes are required to be made by DNS-ALG to the Header
 section. DNS_ALG would parse only the DNS payloads whose QCLASS is
 set to IN (IP class).
  +---------------------+
  |        Header       |
  +---------------------+
  |       Question      | the question for the name server
  +---------------------+
  |        Answer       | RRs answering the question
  +---------------------+
  |      Authority      | RRs pointing toward an authority
  +---------------------+
  |      Additional     | RRs holding additional information
  +---------------------+

4.1. Question section

 The question section contains QDCOUNT (usually 1) entries, as
 specified in Header section, with each of the entries in the
 following format:
                                  1  1  1  1  1  1
    0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                                               |
  /                     QNAME                     /
  /                                               /
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                     QTYPE                     |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                     QCLASS                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

4.1.1. PTR type Queries

 DNS_ALG must identify all names, whose FQDNs (i.e., Fully Qualified
 Domain Names) fall within IN-ADDR.ARPA domain and replace the address
 octets (in reverse  order)  preceding the string "IN-ADDR.ARPA"  with
 the corresponding assigned address octets in reverse order, only if
 the address binding is active on the NAT router. If the address

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

 preceding the string "IN-ADDR.ARPA" falls within the NAT address map,
 but does not have at least a temporary address binding, DNS_ALG would
 simply simply respond back (as a DNS name server would) with a
 response code (RCODE) of 5 (REFUSED to respond due to policy reasons)
 and set ANCOUNT, NSCOUNT and ARCOUT to 0 in the header section of the
 response.
 Note that the above form of host address to host name type queries
 will likely yield different results at different times, depending
 upon address bind status in NAT at a given time.
 For example, a resolver that wanted to find out the hostname
 corresponding to address 198.76.29.1 (externally)  would pursue a
 query of the form:
      QTYPE = PTR, QCLASS = IN, QNAME = 1.29.76.198.IN-ADDR.ARPA.
 DNS_ALG would intervene and if the address 198.76.29.1 is internally
 mapped to a private address of 10.0.0.1, modify the query as below
 and forward to DMZ name server within private network.
      QTYPE = PTR, QCLASS = IN, QNAME = 1.0.0.10.IN-ADDR.ARPA
 Presumably, the DMZ name server is the authoritative name server for
 10.IN-ADDR.ARPA zone and will respond with an RR of the following
 form in answer section. DNS_ALG translations of the response RRs will
 be considered in a following section.
      1.0.0.10.IN-ADDR.ARPA  PTR  host1.fooboo_org.provider_domain
 An example of Inverse translation is e-mail programs using inverse
 translation to trace e-mail originating hosts for spam prevention.
 Verify if the address from which the e-mail was sent does indeed
 belong to the same domain name the sender claims in sender ID.
 Query modifications of this nature will likely change the length of
 DNS payload. As a result, the corresponding IP and TCP/UDP header
 checksums must be updated. In case of TCP based queries, the sequence
 number deltas must be tracked by NAT so that the delta can be applied
 to subsequent sequence numbers in datagrams in the same direction and
 acknowledgement numbers in datagrams in the opposite direction. In
 case of UDP based queries, message sizes are restricted to 512 bytes
 (not counting the IP or UDP headers). Longer messages must be
 truncated and the TC bit should be set in the header.

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

 Lastly, any compressed domain names using pointers to represent
 common domain denominations must be updated to reflect new pointers
 with the right offset, if the original domain name had to be
 translated by NAT.

4.1.2. A, MX, NS and SOA type Queries

 For these queries, DNS_ALG would not modify any of the fields in the
 query section, not even the name field.

4.1.3. AXFR type Queries

 AXFR is a special zone transfer type query. Zone transfers from
 private address realm must be avoided for address assignments that
 are not static. Typically, TCP is used for AXFR requests.
 When changes are made to a zone, they must be distributed to all name
 servers.  The general model of automatic zone transfer or refreshing
 is that one of the name servers is the master or primary for the
 zone.  Changes are coordinated at the primary, typically by editing a
 master file for the zone.  After editing, the administrator signals
 the master server to load the new zone.  The other non-master or
 secondary servers for the zone periodically check the SERIAL field of
 the SOA for the zone for changes (at some polling intervals) and
 obtain new zone copies when changes have been made.
 Zone transfer is usually from primary to backup name servers. In the
 case of NAT supported private networks, primary and backup servers
 are advised to be located in the same private domain (say,
 private.zone) so zone transfer is not across the domain and DNS_ALG
 support for zone transfer is not an issue. In the case a secondary
 name server is located outside the private domain, zone transfers
 must not be permitted for non-static address assignments. Primary and
 secondary servers are required to be within the same private domain
 because all references to data in the zone had to be captured. With
 dynamic address assignments and bindings, it is impossible to
 translate the axfr data to be up-to-date. Hence, if a secondary
 server for private.zone were to be located external to the domain, it
 would contain bad data. Note, however, the requirement outlined here
 is not in confirmence with RFC 2182, which recommends primary and
 secondary servers to be placed at topologically and geographically
 dispersed locations on the Internet.
 During zone transfers, DNS_ALG must examine all A type records and
 replace the original address octets with their statically assigned
 address octets. DNS_ALG could also examine if there is an attempt to

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

 transfer records for hosts that are not assigned static addresses and
 drop those records alone or drop the whole transfer. This would
 minimize misconfiguration and human errors.

4.1.4. Dynamic Updates to the DNS.

 An authoritative name server can have dynamic updates from the nodes
 within the zone without intervention from NAT and DNS-ALG, so long as
 one avoids spreading a DNS zone across address realms. We recommend
 keeping a DNS zone within the same realm it is responsible for. By
 doing this, DNS update traffic will not cross address realms and
 hence will not be subject to consideration by DNS-ALG.
 Further, if dynamic updates do cross address realms, and the updates
 must always be secured via DNSSEC, then such updates are clearly out
 of scope for DNS-ALG (as described in section 7).

4.2. Resource records in all other sections

 The answer, authority, and additional sections all share the same
 format, with a variable number of resource records. The number of RRs
 specific to each of the sections may be found in the corresponding
 count fields in DNS header. Each resource record has the following
 format:
 The TTL value supplied in the original RRs will be left unchanged for
 static address assignments. For dynamic address assignments, DNS_ALG
 will modify the TTL to be 0, so the RRs are used just for the
 transaction in progress, and not cached.  RFC 2181 requires all RRs
 in an RRset (RRs with the same name, class and type, but with
 different RDATA) to have the same TTL. So if the TTL of an RR is set
 to 0, all other RRs within the same RRset will also be adjusted by
 the DNS-ALG to be 0.

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

    0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                                               |
  /                                               /
  /                      NAME                     /
  |                                               |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                      TYPE                     |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                     CLASS                     |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                      TTL                      |
  |                                               |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                   RDLENGTH                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
  /                     RDATA                     /
  /                                               /
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

4.2.1. PTR type RRs

 The considerations specified in the Question section is equally valid
 with names for PTR type RRs. Private address preceding the string
 "IN-ADDR.ARPA" (in reverse order of octets) must be replaced by its
 external address assignment (in reverse order), if a binding exists.
 The remaining fields for this RR remain unchanged.

4.2.2. A type RRs

 The RDATA for A records  is a 4-byte IP address. DNS_ALG would simply
 replace the original address in RDATA with its externally assigned IP
 address, if it succeeded in finding an address binding. Successful
 address translation should cause no changes to payload length. Only
 the transport header checksum would need updating. In case of failure
 to find an address binding, DNS_ALG would have to drop the record and
 decrement the corresponding COUNT field in the header section.

4.2.3. CNAME, MX, NS and SOA type RRs

 No changes required to be made by DNS_ALG for these RRs, as the RDATA
 does not contain any IP addresses. The host names within the RDATA
 remain unchanged between realms.

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

5. Illustration of DNS_ALG in conjunction with Bi-directional NAT

 The following diagram illustrates the operation of DNS_ALG in a a
 bi-directional NAT router. We will illustrate by walking through how
 name lookup and reverse name lookup queries are processed.
                                           .
                       ________________    .     External.com
                      (                )   .
                     (                  )  .   +-------------+
          +--+      (      Internet      )-.---|Border Router|
          |__|------ (                  )  .   +-------------+
         /____\       (________________)   .          |
          Root                 |           .          |
       DNS Server              |           .     ---------------
                       +---------------+   .       |         |
                       |Provider Router|   .     +--+       +--+
                       +---------------+   .     |__|       |__|
                               |           .    /____\     /____\
                               |           .  DNS Server   Host X
     External domain           |           .  171.68.1.1  171.68.10.1
   ............................|...............................
     Private domain            |
                               |        Private.com
                               |
              +--------------------------------------+
              |Bi-Directional NAT router with DNS_ALG|
              |                                      |
              | Private addresses:  172.19/16        |
              | External addresses: 131.108.1/24     |
              +--------------------------------------+
                            |      |
                    ----------    ----------
                      |                  |    DNS Server
                     +--+               +--+  Authoritative
                     |__|               |__|  for private.com
                    /____\             /____\
                    Host A           DNS Server
                 172.19.1.10        172.19.2.1
                                    (Mapped to 131.108.1.8)
  Figure 3: DNS-ALG operation in Bi-Directional NAT setup
 The above diagram depicts a scenario where a company private.com
 using private address space 172.19/16 connects to the Internet using
 bi-directional NAT. DNS_ALG is embedded in the NAT device to make
 necessary DNS payload changes. NAT is configured to translate the
 private addresses space into an external address block of

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

 131.108.1/24. NAT is also configured with a static translation for
 private.com's DNS server, so it can be referred in the external
 domain by a valid address.
 The company external.com is located in the external domain, using a
 registered address block of 171.68/16.  Also shown in the topology is
 a root DNS server.
 Following simplifications are made to the above configuration:
  • private.com is not multihomed and all traffic to the external

space transits a single NAT.

  • The DNS server for private.com is authoritative for the

private.com domain and points to the root server for all other

       DNS resolutions.  The same is true for the DNS server in
       external.com.
  • The internal name servers for private.com and external.com are

same as their DMZ name servers. The DNS servers for these

       domains are configured with addresses private to the
       organization.
  • The name resolvers on host nodes do not have recursion

available on them and desire recursive service from servers.

       All name servers are assumed to be able to provide recursive
       service.

5.1. Outgoing Name-lookup queries

 Say, Host A in private.com needs to perform a name lookup for host X
 in external.com to initiate a session with X.  This would proceed as
 follows.
 1. Host A sends a UDP based name lookup query (A record) for
    "X.External.Com" to its local DNS server.
 2. Local DNS server sends the query to the root server enroute NAT.
    NAT would change the IP and UDP headers to reflect DNS server's
    statically assigned external address.  DNS_ALG will make no
    changes to the payload.
 3. The root server, in turn, refers the local DNS server to query the
    DNS server for External.com. This referal transits the NAT enroute
    to the local DNS server.  NAT would  simply translate the IP and
    UDP headers of the incoming packet to reflect DNS server's private
    address. No changes to the payload by DNS_ALG.

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

 4. Private.com DNS server will now send the query to the DNS server
    for external.com, once again, enroute NAT. Just as with the query
    to root, The NAT router would change the IP and UDP headers to
    reflect the DNS server's statically assigned external address.
    And, DNS_ALG will make no changes to the payload.
 5. The DNS server for external.com replies with the IP address
    171.68.10.1.  This reply also transits the NAT. NAT would
    translate the IP and UDP headers of the incoming packet to reflect
    DNS server's private address. Once again, no changes to the
    payload by DNS_ALG.
 6. The DNS server in Private.com replies to host A.
 When Host A finds the address of Host X, A initiates a session with
 host X, using a destination IP address of 171.68.10.1. This datagram
 and any others that follow in this session will be translated as
 usual by NAT.
 Note, DNS_ALG does not change the payload for DNS packets in either
 direction.

5.2. Reverse name lookups originated from private domain

 This scenario builds on the previous case by having host A in
 Private.com perform a reverse name lookup on 171.68.10.1, which is
 host X's global address. Following is a sequence of events.
 1. Host A sends a UDP based inverse name lookup query (PTR record)
    for "1.10.68.171.IN-ADDR.ARPA." to its local DNS server.
 2. Local DNS server sends the query to the root server enroute NAT.
    As before, NAT would change the IP and UDP headers to reflect DNS
    server's statically assigned external address.  DNS_ALG will make
    no changes to the payload.
 3. The root server, in turn, refers the local DNS server to query the
    DNS server for External.com. This referal transits the NAT enroute
    to the local DNS server.  NAT would  simply translate the IP and
    UDP headers of the incoming packet to reflect DNS server's private
    address. No changes to the payload by DNS_ALG.
 4. Private.com DNS server will now send the query to the DNS server
    for external.com, once again, enroute NAT. Just as with the query
    to root, The NAT router would change the IP and UDP headers to
    reflect the DNS server's statically assigned external address.
    And, DNS_ALG will make no changes to the payload.

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

 5. The DNS server for external.com replies with the host name of
    "X.External.Com.". This reply also transits the NAT. NAT would
    translate the IP and UDP headers of the incoming packet to reflect
    DNS server's private address. Once again, no changes to the
    payload by DNS_ALG.
 6. The DNS server in Private.com replies to host A.
 Note, DNS_ALG does not change the payload in either direction.

5.3. Incoming Name-lookup queries

 This time, host X in external.com wishes to initiate a session with
 host A in Private.com. Below are the sequence of events that take
 place.
 1. Host X sends a UDP based name lookup query  (A record) for
    "A.Private.com" to its local DNS server.
 2. Local DNS server in External.com sends the query to root server.
 3. The root server, in turn, refers the DNS server in External.com to
    query the DNS server for private.com,
 4. External.com DNS server will now send the query to the DNS server
    for Private.com. This query traverses the NAT router. NAT would
    change the IP and UDP headers of the packet to reflect the DNS
    server's private address. DNS_ALG will make no changes to the
    payload.
 5. The DNS server for Private.com replies with the IP address
    172.19.1.10 for host A.  This reply also transits the NAT. NAT
    would translate the IP and UDP headers of the outgoing packet from
    the DNS server.
    DNS_ALG will request NAT to (a) setup a temporary binding for Host
    A (172.19.1.10) with an external address and (b) initiate Bind-
    holdout timer. When NAT successfully sets up a temporary binding
    with an external address (say, 131.108.1.12), DNS_ALG would modify
    the payload to replace A's private address with its external
    assigned address and set the Cache timeout to 0.
 6. The server in External.com replies to host X
 When Host X finds the address of Host A, X initiates a session with
 A, using a destination IP address of 131.108.1.12. This datagram and
 any others that follow in this session will be translated as usual by
 the NAT.

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

 Note, DNS_ALG changes only the response packets from the DNS server
 for Private domain.

5.4. Reverse name lookups originated from external domain

 This scenario builds on the previous case (section 5.3) by having
 host X in External.com perform a reverse name lookup on 131.108.1.12,
 which is host A's assigned external address. The following sequence
 of events take place.
 1. Host X sends a UDP based inverse name lookup query (PTR record)
    for "12.1.108.131.IN-ADDR.ARPA." to its local DNS server.
 2. Local DNS server in External.com sends the query to the root
    server.
 3. The root server, in turn, refers the local DNS server to query the
    DNS server for Private.com.
 4. External.com DNS server will now send the query to the DNS server
    for Private.com. This query traverses the NAT router. NAT would
    change the IP and UDP headers to reflect the DNS server's private
    address.
    DNS_ALG will enquire NAT for the private address associated with
    the external address of 131.108.1.12 and modify the payload,
    replacing 131.108.1.12 with the private address of 172.19.1.10.
 5. The DNS server for Private.com replies with the host name of
    "A.Private.Com.". This reply also transits the NAT. NAT would
    translate the IP and UDP headers of the incoming packet to reflect
    DNS server's private address.
    Once again, DNS_ALG will enquire NAT for the assigned external
    address associated with the private address of 172.19.1.10 and
    modify the payload, replacing 172.19.1.10 with the assigned
    external address of 131.108.1.12.
 6. The DNS server in External.com replies to host X.
 Note, DNS_ALG changes the query as well as response packets from DNS
 server for Private domain.

6. Illustration of DNS_ALG in conjunction with Twice-NAT

 The following diagram illustrates the operation of DNS_ALG in a Twice
 NAT router. As before, we will illustrate by walking through how name
 lookup and reverse name lookup queries are processed.

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

                                           .
                       ________________    .     External.com
                      (                )   .
                     (                  )  .   +-------------+
          +--+      (      Internet      )-.---|Border Router|
          |__|------ (                  )  .   +-------------+
         /____\       (________________)   .          |
          Root                 |           .          |
       DNS Server              |           .     ---------------
                       +---------------+   .       |         |
                       |Provider Router|   .     +--+       +--+
                       +---------------+   .     |__|       |__|
                               |           .    /____\     /____\
                               |           .  DNS Server   Host X
     External domain           |           .  171.68.1.1  171.68.10.1
   ............................|...............................
     Private domain            |
                               |        Private.com
                               |
              +-------------------------------------------+
              | Twice-NAT router with DNS_ALG             |
              |                                           |
              | Private addresses:  171.68/16             |
              | Assigned External addresses: 131.108.1/24 |
              |                                           |
              | External addresses:  171.68/16            |
              | Assigned Private addresses: 10/8          |
              +-------------------------------------------+
                            |      |
                    ----------    ----------
                      |                  |    DNS Server
                     +--+               +--+  Authoritative
                     |__|               |__|  for private.com
                    /____\             /____\
                    Host A           DNS Server
                 171.68.1.10        171.68.2.1
                                    (Mapped to 131.108.1.8)
  Figure 4: DNS-ALG operation in Twice-NAT setup
 In this scenario, hosts in private.com were not numbered from the RFC
 1918 reserved 172.19/16 space, but rather were numbered with the
 globally-routable 171.68/16 network, the same as external.com.  Not
 only does private.com need translation service for its own host
 addresses, but it also needs translation service if any of those
 hosts are to be able to exchange datagrams with hosts in
 external.com. Twice-NAT accommodates the transition by translating
 the overlapping address space used in external.com with a unique

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

 address block (10/8) from RFC 1918 address space. Routes are set up
 within the private domain to direct datagrams destined for the
 address block 10/8 through Twice-NAT device to the external global
 network space.
 Simplifications and assumptions made in section 5.0 will be valid
 here as well.

6.1. Outgoing Name-lookup queries

 Say, Host A in private.com needs to perform a name lookup for host X
 in external.com (host X has a FQDN of X.external.com), to find its
 address.  This would would proceed as follows.
 1. Host A sends a UDP based name lookup query (A record) for
    "X.External.Com" to its local DNS server.
 2. Local DNS server sends the query to the root server enroute NAT.
    NAT would change the IP and UDP headers to reflect DNS server's
    statically assigned external address.  DNS_ALG will make no
    changes to the payload.
 3. The root server, in turn, refers the local DNS server to query the
    DNS server for External.com. This referal transits the NAT enroute
    to the local DNS server.  NAT would  simply translate the IP and
    UDP headers of the incoming packet to reflect DNS server's private
    address.
    DNS_ALG will request NAT for an assigned private address for the
    referral server and replace the external address with its assigned
    private address in the payload.
 4. Private.com DNS server will now send the query to the DNS server
    for external.com, using its assigned private address, via NAT.
    This time, NAT would change the IP and UDP headers to reflect the
    External addresses of the DNS servers. I.e., Private.com DNS
    server's IP address is changed to its assigned external address
    and External.Com DNS server's assigned Private address is changed
    to its external address.
    DNS_ALG will make no changes to the payload.
 5. The DNS server for external.com replies with the IP address
    171.68.10.1.  This reply also transits the NAT. NAT would once
    again translate the IP and UDP headers of the incoming to reflect
    the private addresses of the DNS servers.  I.e., Private.com DNS

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

    server's IP address is changed to its private address and
    External.Com DNS server's external address is changed to its
    assigned Private address.
    DNS_ALG will request NAT to (a) set up a temporary binding for
    Host X (171.68.10.1) with a private address and (b) initiate
    Bind-holdout timer. When NAT successfully sets up temporary
    binding with a private address (say, 10.0.0.254), DNS_ALG would
    modify the payload to replace X's external address with its
    assigned private address and set the Cache timeout to 0.
 6. The DNS server in Private.com replies to host A.
 When Host A finds the address of Host X, A initiates a session with
 host X, using a destination IP address of 10.0.0.254. This datagram
 and any others that follow in this session will be translated as
 usual by Twice NAT.
 Note, the DNS_ALG has had to change payload in both directions.

6.2. Reverse name lookups originated from private domain

 This scenario builds on the previous case by having host A in
 Private.com perform a reverse name lookup on 10.0.0.254, which is
 host X's assigned private address. Following is a sequence of events.
 1. Host A sends a UDP based inverse name lookup query (PTR record)
    for "254.0.0.10.IN-ADDR.ARPA." to its local DNS server.
 2. Local DNS server sends the query to the root server enroute NAT.
    As before, NAT would change the IP and UDP headers to reflect DNS
    server's statically assigned external address.
    DNS_ALG will translate the private assigned address 10.0.0.254
    with its external address 171.68.10.1.
 3. The root server, in turn, refers the local DNS server to query the
    DNS server for External.com. This referal transits the NAT enroute
    to the local DNS server.  NAT would  simply translate the IP and
    UDP headers of the incoming packet to reflect DNS server's private
    address.
    As with the original query, DNS_ALG will translate the private
    assigned address 10.0.0.254 with its external address 171.68.10.1.
    In addition, DNS_ALG will replace the external address of the
    referal server (i.e., the DNS server for External.com) with its
    assigned private address in the payload.

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

 4. Private.com DNS server will now send the query to the DNS server
    for external.com, using its statically assigned private address,
    via NAT. This time, NAT would change the IP and UDP headers to
    reflect the External addresses of the DNS servers. I.e.,
    Private.com DNS server's IP address is changed to its assigned
    external address and External.Com DNS server's assigned Private
    address is changed to its external address.
    As with the original query, DNS_ALG will translate the private
    assigned address 10.0.0.254 with its external address 171.68.10.1.
 5. The DNS server for external.com replies with the FQDN of
    "X.External.Com.".  This reply also transits the NAT. NAT would
    once again translate the IP and UDP headers of the incoming to
    reflect the private addresses of the DNS servers.  I.e.,
    Private.com DNS server's IP address is changed to its private
    address and External.Com DNS server's external address is changed
    to its assigned Private address.
    Once again, DNS_ALG will translate the query section, replacing
    the external address 171.68.10.1 with its assigned private address
    of 10.0.0.254
 6. The DNS server in Private.com replies to host A.
 Note, the DNS_ALG has had to change payload in both directions.

6.3. Incoming Name-lookup queries

 This time, host X in external.com wishes to initiate a session with
 host A in Private.com. Below are the sequence of events that take
 place.
 1. Host X sends a UDP based name lookup query  (A record) for
    "A.Private.com" to its local DNS server.
 2. Local DNS server in External.com sends the query to root server.
 3. The root server, in turn, refers the DNS server in External.com to
    query the DNS server for private.com,
 4. External.com DNS server will now send the query to the DNS server
    for Private.com. This query traverses the NAT router. NAT would
    change the IP and UDP headers to reflect the private addresses of
    the DNS servers. I.e., Private.com DNS server's IP address is
    changed to its  private address and External.Com DNS server's
    external address is changed to assigned Private address.

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

    DNS_ALG will make no changes to the payload.
 5. The DNS server for Private.com replies with the IP address
    171.68.1.10 for host A.  This reply also transits the NAT. NAT
    would once again translate the IP and UDP headers of the incoming
    to reflect the external addresses of the DNS servers.  I.e.,
    Private.com DNS server's IP address is changed to its assigned
    external address and External.Com DNS server's assigned private
    address is changed to its external address.
    DNS_ALG will request NAT to (a) set up temporary binding for Host
    A (171.68.1.10) with an external address and (b) initiate Bind-
    holdout timer. When NAT succeeds in finding an external address
    (say, 131.108.1.12) to temporarily bind to host A, DNS_ALG would
    modify the payload to replace A's private address with its
    external assigned address and set the Cache timeout to 0.
 6. The server in External.com replies to host X
 When Host X finds the address of Host A, X initiates a session with
 A, using a destination IP address of 131.108.1.12. This datagram and
 any others that follow in this session will be translated as usual by
 the NAT.
 Note, DNS_ALG changes only the response packets from the DNS server
 for Private domain.

6.4. Reverse name lookups originated from external domain

 This scenario builds on the previous case (section 6.3) by having
 host X in External.com perform a reverse name lookup on 131.108.1.12,
 which is host A's assigned external address. The following sequence
 of events take place.
 1. Host X sends a UDP based inverse name lookup query (PTR record)
    for "12.1.108.131.IN-ADDR.ARPA." to its local DNS server.
 2. Local DNS server in External.com sends the query to the root
    server.
 3. The root server, in turn, refers the local DNS server to query the
    DNS server for Private.com.

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

 4. External.com DNS server will now send the query to the DNS server
    for Private.com. This query traverses the NAT router. NAT would
    change the IP and UDP headers to reflect the private addresses of
    the DNS servers. I.e., Private.com DNS server's IP address is
    changed to its  private address and External.Com DNS server's
    external address is changed to assigned Private address.
    DNS_ALG will enquire NAT for the private address associated with
    the external address of 131.108.1.12 and modify the payload,
    replacing 131.108.1.12 with the private address of 171.68.1.10.
 5. The DNS server for Private.com replies with the host name of
    "A.Private.Com.". This reply also transits the NAT. NAT would once
    again translate the IP and UDP headers of the incoming to reflect
    the external addresses of the DNS servers.  I.e., Private.com DNS
    server's IP address is changed to its assigned external address
    and External.Com DNS server's assigned private address is changed
    to its external address.
    Once again, DNS_ALG will enquire NAT for the assigned external
    address associated with the private address of 172.19.1.10 and
    modify the payload, replacing 171.68.1.10 with the assigned
    external address of 131.108.1.12.
 6. The DNS server in External.com replies to host X.
 Note, DNS_ALG changes the query as well as response packets from DNS
 server for Private domain.

7. DNS-ALG limitations and Future Work

 NAT increases the probability of mis-addressing. For example, same
 local address may be bound to different public address at different
 times and vice versa. As a result, hosts that cache the name to
 address mapping for longer periods than the NAT router is configured
 to hold the map are likely to misaddress their sessions. Note, this
 is mainly an issue with bad host implementations that hold DNS
 records longer than the TTL in them allows and is not directly
 attributable to the mechanism described here.
 DNS_ALG cannot support secure DNS name servers in the private domain.
 I.e., Signed replies from an authoritative DNS name server in the DMZ
 to queries originating from the external world will be broken by the
 DNS-ALG. At best, DNS-ALG would be able to transform secure dnssec
 data into unprotected data. End-node demanding DNS replies to be
 signed may reject replies that have been tampered with by DNS_ALG.
 Since, the DNS server does not have a way to find where the queries
 come from (i.e., internal or external), it will most likely have to

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

 resort to the common denomination of today's insecure DNS. Both are
 serious limitations to DNS_ALG. Zone transfers between DNS-SEC
 servers  is also impacted the same way, if the transfer crosses
 address realms.
 The good news, however, is that only end-nodes in DMZ pay the price
 for the above limitation in a traditional NAT (or, a bi-directional
 NAT), as external end-nodes may not access internal hosts due to DNS
 replies not being secure. However, for outgoing sessions (from
 private network) in a bi-directional NAT setup, the DNS queries can
 be signed and securely accepted by DMZ and other internal hosts since
 DNS_ALG does not intercept outgoing DNS queries and incoming replies.
 Lastly, zone transfers between DNS-SEC servers  within the same
 private network are not impacted.
 Clearly, with DNS SEC deployment in DNS servers and end-host
 resolvers, the scheme suggested in this document will not work.

8. Security Considerations

 If DNS packets are encrypted/authenticated per DNSSEC, then DNS_ALG
 will fail because it won't be able to perform payload modifications.
 Alternately, if packets must be preserved in an address realm,
 DNS_ALG will need to hold the secret key to decrypt/verify payload
 before forwarding packets to a different realm. For example, if DNS-
 ALG, NAT and IPsec gateway (providing secure tunneling service) are
 resident on the same device, DNS-ALG will have access to the IPsec
 security association keys.  The preceding section, "DNS-ALG
 limitations and Future Work" has coverage on DNS_ALG security
 considerations.
 Further, with DNS-ALG, there is a possibility of denial of service
 attack from a malicious user, as outlined in section 3.1.  Section
 3.1 suggests some ways to counter this attack.

REFERENCES

  [1] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
      (NAT) Terminology and Considerations", RFC 2663, August 1999.
  [2] Egevang, K. and  P. Francis, "The IP Network Address Translator
      (NAT)", RFC 1631, May 1994.
  [3] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E.
      Lear, "Address Allocation for Private Internets", BCP 5, RFC
      1918, February 1996.

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

  [4] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
      13, RFC 1034, November 1987.
  [5] Mockapetris, P., "Domain Names - Implementation and
      Specification", STD 13, RFC 1035, November 1987.
  [6] Reynolds J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
      October 1994.
  [7] Braden, R., "Requirements for Internet Hosts -- Communication
      Layers", STD 3, RFC 1122, October 1989.
  [8] Braden, R., "Requirements for Internet Hosts -- Application and
      Support", STD 3, RFC 1123, October 1989.
  [9] Baker, F., "Requirements for IP Version 4 Routers",  RFC 1812,
      June 1995.
 [10] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
      Behaviour Today", RFC 2101, February 1997.
 [11] Eastlake, D., "Domain Name System Security Extensions", RFC
      2535, March 1999.
 [12] Vixie, P., Thompson, S., Rekhter Y. and J. Bound, "Dynamic
      Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
      1997.
 [13] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
      2137, April 1997.
 [14] Elz R. and R. Bush, "Clarifications to the DNS specification",
      RFC 2181, July 1997.
 [15] Elz, R., R. Bush, Bradner S. and M. Patton, "Selection and
      Operation of Secondary DNS Servers", RFC 2182, July 1997.

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

Authors' Addresses

 Pyda Srisuresh
 849 Erie Circle
 Milpitas, CA 95035
 U.S.A.
 Phone: +1 (408) 263-7527
 EMail: srisuresh@yahoo.com
 George Tsirtsis
 Internet Transport Group
 B29 Room 129
 BT Laboratories
 Martlesham Heath
 IPSWICH
 Suffolk IP5 3RE
 England
 Phone: +44 1473 640756
 Fax:   +44 1473 640709
 EMail: george@gideon.bt.co.uk
 Praveen Akkiraju
 cisco Systems
 170 West Tasman Drive
 San Jose, CA  95134  USA
 Phone: +1 (408) 526-5066
 EMail: spa@cisco.com
 Andy Heffernan
 Juniper Networks, Inc.
 385 Ravensdale Drive.
 Mountain View, CA  94043  USA
 Phone: +1 (650) 526-8037
 Fax:   +1 (650) 526-8001
 EMail: ahh@juniper.net

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

Full Copyright Statement

 Copyright (C) The Internet Society (1999).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Srisuresh, et al. Informational [Page 29]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2694.txt · Last modified: 1999/09/15 21:33 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki