From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2694.txt | 1627 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1627 insertions(+) create mode 100644 doc/rfc/rfc2694.txt (limited to 'doc/rfc/rfc2694.txt') diff --git a/doc/rfc/rfc2694.txt b/doc/rfc/rfc2694.txt new file mode 100644 index 0000000..035537e --- /dev/null +++ b/doc/rfc/rfc2694.txt @@ -0,0 +1,1627 @@ + + + + + + +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] + -- cgit v1.2.3