rfc2694.txt

NAT协议完整源代码

   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: [phone]
   EMail: [e-mail]


   George Tsirtsis
   Internet Transport Group
   B29 Room 129
   BT Laboratories
   Martlesham Heath
   IPSWICH
   Suffolk IP5 3RE
   England

   Phone: [phone]
   Fax:   [phone]
   EMail: george