rfc2694.txt

NAT协议完整源代码

   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]