rfc2694.txt

NAT协议完整源代码


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