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 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
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", RFC2663, August 1999.
[2] Egevang, K. and P. Francis, "The IP Network Address Translator
(NAT)", RFC1631, 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.
[4] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC1034, November 1987.
[5] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC1035, November 1987.
[6] Reynolds J. and J. Postel, "Assigned Numbers", STD 2, RFC1700,
October 1994.
[7] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", STD 3, RFC1122, October 1989.
[8] Braden, R., "Requirements for Internet Hosts -- Application and
Support", STD 3, RFC1123, October 1989.
[9] Baker, F., "Requirements for IP Version 4 Routers", RFC1812,
June 1995.
[10] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
Behaviour Today", RFC2101, 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)", RFC2136, 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",
RFC2181, July 1997.
[15] Elz, R., R. Bush, Bradner S. and M. Patton, "Selection and
Operation of Secondary DNS Servers", RFC2182, July 1997.
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
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 RFCEditor function is currently provided by the
Internet Society.