As per Relevance of the word extensions, we have this rfc below:

---

Network Working Group P.
Request for Comments: 2694
Category: Informational G.
BT
P.
Cisco
A.
Juniper
September 1999


DNS extensions to Network Address Translators (DNS_ALG

Status of this

This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited

Copyright

Copyright (C) The Internet Society (1999). All Rights Reserved



Domain Name Service (DNS) provides name to address mapping within
routing class (ex: IP). Network Address Translators (NATs) attempt
provide transparent routing between hosts in disparate address
of the same routing class. Typically, NATs exist at the border of
stub domain, hiding private addresses from external addresses.
document identifies the need for DNS extensions to NATs and
how a DNS Application Level Gateway (DNS_ALG) can meet the need
DNS_ALG modifies payload transparently to alter address mapping
hosts as DNS packets cross one address realm into another.
document also illustrates the operation of DNS_ALG with
examples

1.

Network Address Translators (NATs) are often used when network'
internal IP addresses cannot be used outside the network either
privacy reasons or because they are invalid for use outside
network

Ideally speaking, a host name uniquely identifies a host and
address is used to locate routes to the host. However, host name
address are often not distinguished and used interchangeably
applications. Applications embed IP address instead of host name



Srisuresh, et al. Informational [Page 1]

RFC 2694 DNS extensions to NAT September 1999


payload. Examples would be e-mails that specify their MX
address (ex: user@666.42.7.11) instead of server name (ex
user@private.com) as sender ID; HTML files that include IP
instead of names in URLs, etc. Use of IP address in place of
name in payload represents a problem as the packet traverses a
device because NATs alter network and transport headers to suit
address realm, but not payload

DNS provides Name to address mapping. Whereas, NAT performs
translation (in network and transport headers) in
traversing between private and external address realms.
Application Level Gateway (DNS_ALG) outlined in this document
translate Name-to-Private-Address mapping in DNS payloads into Name
to-external-address mapping and vice versa using state
available on NAT

A Network Address Port Translator (NAPT) performs address
Transport level port translations (i.e, TCP, UDP ports and ICMP
IDs). DNS name mapping granularity, however, is limited to
addresses and does not extend to transport level identifiers. As
result, the DNS_ALG processing for an NAPT configuration
simplified in that all host addresses in private network are bound
a single external address. The DNS name lookup for private
(from external hosts) do not mandate fresh private-external
binding, as all private hosts are bound to a single pre-
external address. However, reverse name lookups for the NAPT
address will not map to any of the private hosts and will simply
to the NAPT router. Suffices to say, the processing requirements
a DNS_ALG supporting NAPT configuration are a mere subset of
NAT. Hence, the discussion in the remainder of the document
focus mainly on Basic NAT, Bi-directional NAT and Twice
configurations, with no specific reference to NAPT setup

Definitions for DNS and related terms may be found in [Ref 3]
[Ref 4]. Definitions for NAT related terms may be found in [Ref 1].

2. Requirement for DNS

There are many ways to ensure that a host name is mapped to
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
servers. Internal authoritative name servers identify all (
majority of) corporate resources within the organization. Only
portion of these hosts are allowed to be accessed by the
world. The remaining hosts and their names are unique to the
network. Hosts visible to the external world and the



Srisuresh, et al. Informational [Page 2]

RFC 2694 DNS extensions to NAT September 1999


name server that maps their names to network addresses are
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
DMZ name servers respectively. DMZ host names are end-to-end
in that their FQDNs do not overlap with any end node
communicates with it

\ | /
+-----------------------+
|Service Provider Router
+-----------------------+
WAN |
Stub A .........|\|....
|
+-----------------+
|Stub Router w/NAT
+-----------------+
|
| DMZ -
------------------------------------------------------------
| | | | |
+--+ +--+ +--+ +--+ +----------+
|__| |__| |__| |__| | 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

Figure 1: DMZ network configuration of a private Network

Figure 1 above illustrates configuration of a private network
includes a DMZ. Actual configurations may vary. Internal name
are accessed by users within the private network only. Internal
queries and responses do not cross the private network boundary.
name servers and DMZ hosts on the other hand are end-to-end
and could be accessed by external as well as internal hosts
Throughout this document, our focus will be limited to DMZ hosts
DMZ name servers and will not include internal hosts and
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

Take the case where DMZ hosts are assigned static external
on the NAT device. Note, all hosts within private domain,
the DMZ hosts are identified by their private addresses.
mapping on the NAT device allows the DMZ hosts to be identified
their public addresses in the external domain

2.1.1. Private networks with no DMZ name

Take the case where a private network has no DMZ name server
itself. If the private network is connected to a single
provider for external connectivity, the DMZ hosts may be listed
their external addresses in the authoritative name servers of
service provider within their forward and in-add.arpa reverse zones

If the network is connected to multiple service providers, the
host names may be listed by their external address(es) within
authoritative name servers of each of the service providers. This
particularly significant in the case of in-addr.arpa reverse zones
as the private network may be assigned different address prefixes
the service providers

In both cases, externally generated DNS lookups will not reach
private network. A large number of NAT based private domains
this option to have their DMZ hosts listed by their
addresses on service provider's name servers

2.1.2. Private networks with DMZ name

Take the case where a private network opts to keep an
DMZ name server for the zone within the network itself. If
network is connected to a single service provider, the DMZ
server may be configured to obviate DNS payload interceptions
follows. The hosts in DMZ name server must be mapped to
statically assigned external addresses and the internal name
must be configured to bypass the DMZ name server for
concerning external hosts. This scheme ensures that DMZ name
are set for exclusive access to external hosts alone (not even to
DMZ hosts) and hence can be configured with external addresses only

The above scheme requires careful administrative planning to
that DMZ name servers are not contacted by the private hosts
or indirectly (through the internal name servers). Using DNS-
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

Take the case where DMZ hosts in a private network are
external addresses dynamically by NAT. While the addresses issued
these hosts are fixed within the private network, their
known addresses are ephemeral, as determined by NAT. In such
scenario, it is mandatory for the private organization to have a
name server in order to allow access to DMZ hosts by their name

The DMZ name server would be configured with private addresses
DMZ hosts. DNS Application Level Gateway (DNS_ALG) residing on
device will intercept the DNS packets directed to or from the
name server(s) and perform transparent payload translations so that
DMZ host name has the right address mapping within each address
(i.e., private or external).

3. Interactions between NAT and DNS_

This document operates on the paradigm that interconnecting
realms may have overlapping address space. But, names of hosts
interconnected realms must be end-to-end unique in order for them
be accessed by all hosts. In other words, there cannot be an
of FQDNs between end nodes communicating with each other.
following diagram illustrates how a DNS packet traversing a
device (with DNS_ALG) is subject to header and payload translations
A DNS packet can be a TCP or UDP packet with the source
destination port set to 53. NAT would translate the IP and TCP/
headers of the DNS packet and notify DNS-ALG to perform DNS
changes. DNS-ALG would interact with NAT and use NAT
information to modify payload, as necessary





















Srisuresh, et al. Informational [Page 5]

RFC 2694 DNS extensions to NAT September 1999


Original-

||
||

+---------------------------------+ +-----------------------+
| | |DNS Appl. Level Gateway
|Network Address Translation (NAT)|--->| (DNS_ALG) |
| *IP & Transport header mods |<---| *DNS payload mods |
| | | |
+---------------------------------+ +-----------------------+
||
||

Translated-


Figure 2: NAT & DNS-ALG in the translation path of DNS

3.1. Address Binding

We will make a distinction between "Temporary Address Binding"
"Committed Address Binding" in NATs. This distinction
necessary because the DNS_ALG will allow external users to
state on NAT, and thus the potential for denial-of-service attacks
Temporary address binding is the phase in which an address binding
reserved without any NAT sessions using the binding.
address binding is the phase in which there exists at least one
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
Transport headers of datagrams pertaining to NAT sessions

For statically mapped addresses, the above distinction is
relevant. For dynamically mapped addresses, temporary address
often precedes committed binding. Temporary binding occurs when
name server is queried for a name lookup. Name query is likely
pre-cursor to a real session between query originator and the
host. The temporary binding becomes committed only when NAT sees
first packet of a session between query initiator and queried host

A configurable parameter, "Bind-holdout time" may be defined
dynamic address assignments as the maximum period of time for which
temporary address binding is held active without transitioning into
committed binding. With each use of temporary binding by DNS_ALG (
modify DNS payload), this Bind-holdout period is renewed. A
Bind-holdout time of a couple of minutes might suffice for most DNS
ALG implementations. Note, it is possible for a committed



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
binding. Lastly, when NAT is ready to unbind a committed
binding, the binding is transitioned into a temporary binding
kept in that phase for an additional Bind-holdout period. The
is freed only upon expiry of Bind-holdout time. The Bind-holdout
preceding the committed-address-binding and the address-unbinding
required to ensure that end hosts have sufficient time in which
initiate a data session subsequent to a name lookup

For example, say a private network with address prefix 10/8 is
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
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
assigned an external address already, it would request NAT to
a temporary address binding with an external address and start Bind
holdout timer to age the binding. Say, the assigned external
is 198.76.29.1. DNS-ALG would use this temporary binding to
the RR in DNS response, replacing 10.0.0.7 with its external
and reply with

host7 A 198.76.29.1

When query initiator receives DNS response, only the
external address is seen. Within a short period (presumably
the bind-holdout time expires), the query initiator would initiate
session with host7. When NAT notices the start of new
directed to 198.76.29.1, NAT would terminate Bind-holdout timer
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
attempting name resolutions, without ever initiating a connection
NAT would have to monitor temporary address bindings that have
transitioned into committed bindings. There could be a limit on
number of temporary bindings and attempts to generate
temporary bindings could be simply rejected. There may be
heuristic solutions to counter this type of malicious attacks

We will consider bi-directional NAT to illustrate the use
temporary binding by DNS_ALG in the following sub-sections,
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

In order to initiate incoming sessions, an external host obtains
V4 address of the DMZ-host it is trying to connect to by making a
request. This request constitutes prelude to the start of
potential new session

The external host resolver makes a name lookup for the DMZ
through its DNS server. When the DNS server does not have a
of IPv4 address attached to this name, the lookup query is
at some point to the Primary/Backup DNS server (i.e., in DMZ) of
private stub domain

Enroute to DMZ name server, DNS_ALG would intercept the datagram
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 V
address octets (in reverse order) preceding the string "IN
ADDR.ARPA" with the corresponding private V4 address, if
an address binding exists already. However, if a binding
not exist, the DNS_ALG would simply respond (as a name
would) with a response code (RCODE) of 5 (REFUSED to
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
server in private network, DNS_ALG would once again intercept
packet and modify as follows

a) For a host name to host address query requests, replace
private address sent by DMZ name server with a public
internally assigned by the NAT router. If a public address
not previously assigned to the host's private address,
would assign one at this time

b) For host address to host name queries, replace the
address octets preceding the string "IN-ADDR.ARPA" in
RRs with their external address assignments. There is a
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
will have to resend the query (as would happen when a
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
original RR will be left unchanged. For dynamic address assignments
DNS_ALG would modify the TTL value on DNS resource records (RRs)
be 0, implying that the RRs should only be used for transaction
progress, and not be cached. For compatibility with
implementations, TTL of 1 might in practice work better

Clearly, setting TTL to be 0 will create more traffic than if
addresses were static, because name-to-address mapping is not cached
Specifically, network based applications will be required to
names rather than addresses for identifying peer nodes and must
DNS for every name resolution, as name-to-address mapping cannot
shared from the previously run applications

In addition, NAT would be requested to initiate a bind-holdout
following the assignment. If no session is initiated to the
host within the Bind-holdout time period, NAT would terminate
temporary binding

3.3. Outgoing

For Basic and bi-directional NATs, there is no need to
between temporary and committed bindings for outgoing queries.
is because, DNS_ALG does not modify the DNS packets directed to
from external name servers (used during outbound sessions),
the inbound DNS sessions

Say, a private host needs to communicate with an external host.
DNS query goes to the internal name server (if there exists one
and from there to the appropriate authoritative/cache name
outside the private domain. The reply follows the same route
neither the query nor the response are subject to DNS_
translations

This however will not be the case with address isolated twice
private and external domains. In such a case, NAT would intercept
DNS packets and make address modifications to payload as discussed
the previous section. Temporary Private to external address
are created when responses are sent by private DNS servers
temporary external to private address bindings are created
responses are sent by external DNS servers

4. DNS payload modifications by DNS-

Typically, UDP is employed as the transport mechanism for DNS
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 [



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/
headers of a DNS packet, DNS-ALG is responsible for updating the
payload

The header section within the DNS payload is always present
includes fields specifying which of the remaining sections
present. The header identifies if the message is a query or
response. No changes are required to be made by DNS-ALG to the
section. DNS_ALG would parse only the DNS payloads whose QCLASS
set to IN (IP class).

+---------------------+
| Header |
+---------------------+
| Question | the question for the name
+---------------------+
| Answer | RRs answering the
+---------------------+
| Authority | RRs pointing toward an
+---------------------+
| Additional | RRs holding additional
+---------------------+

4.1. Question

The question section contains QDCOUNT (usually 1) entries,
specified in Header section, with each of the entries in
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

DNS_ALG must identify all names, whose FQDNs (i.e., Fully
Domain Names) fall within IN-ADDR.ARPA domain and replace the
octets (in reverse order) preceding the string "IN-ADDR.ARPA"
the corresponding assigned address octets in reverse order, only
the address binding is active on the NAT router. If the



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
simply simply respond back (as a DNS name server would) with
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
response

Note that the above form of host address to host name type
will likely yield different results at different times,
upon address bind status in NAT at a given time

For example, a resolver that wanted to find out the
corresponding to address 198.76.29.1 (externally) would pursue
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
mapped to a private address of 10.0.0.1, modify the query as
and forward to DMZ name server within private network

QTYPE = PTR, QCLASS = IN, QNAME = 1.0.0.10.IN-ADDR.

Presumably, the DMZ name server is the authoritative name server
10.IN-ADDR.ARPA zone and will respond with an RR of the
form in answer section. DNS_ALG translations of the response RRs
be considered in a following section

1.0.0.10.IN-ADDR.ARPA PTR host1.fooboo_org.provider_

An example of Inverse translation is e-mail programs using
translation to trace e-mail originating hosts for spam prevention
Verify if the address from which the e-mail was sent does
belong to the same domain name the sender claims in sender ID

Query modifications of this nature will likely change the length
DNS payload. As a result, the corresponding IP and TCP/UDP
checksums must be updated. In case of TCP based queries, the
number deltas must be tracked by NAT so that the delta can be
to subsequent sequence numbers in datagrams in the same direction
acknowledgement numbers in datagrams in the opposite direction.
case of UDP based queries, message sizes are restricted to 512
(not counting the IP or UDP headers). Longer messages must
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
common domain denominations must be updated to reflect new
with the right offset, if the original domain name had to
translated by NAT

4.1.2. A, MX, NS and SOA type

For these queries, DNS_ALG would not modify any of the fields in
query section, not even the name field

4.1.3. AXFR type

AXFR is a special zone transfer type query. Zone transfers
private address realm must be avoided for address assignments
are not static. Typically, TCP is used for AXFR requests

When changes are made to a zone, they must be distributed to all
servers. The general model of automatic zone transfer or
is that one of the name servers is the master or primary for
zone. Changes are coordinated at the primary, typically by editing
master file for the zone. After editing, the administrator
the master server to load the new zone. The other non-master
secondary servers for the zone periodically check the SERIAL field
the SOA for the zone for changes (at some polling intervals)
obtain new zone copies when changes have been made

Zone transfer is usually from primary to backup name servers. In
case of NAT supported private networks, primary and backup
are advised to be located in the same private domain (say
private.zone) so zone transfer is not across the domain and DNS_
support for zone transfer is not an issue. In the case a
name server is located outside the private domain, zone
must not be permitted for non-static address assignments. Primary
secondary servers are required to be within the same private
because all references to data in the zone had to be captured.
dynamic address assignments and bindings, it is impossible
translate the axfr data to be up-to-date. Hence, if a
server for private.zone were to be located external to the domain,
would contain bad data. Note, however, the requirement outlined
is not in confirmence with RFC 2182, which recommends primary
secondary servers to be placed at topologically and
dispersed locations on the Internet

During zone transfers, DNS_ALG must examine all A type records
replace the original address octets with their statically
address octets. DNS_ALG could also examine if there is an attempt





Srisuresh, et al. Informational [Page 12]

RFC 2694 DNS extensions to NAT September 1999


transfer records for hosts that are not assigned static addresses
drop those records alone or drop the whole transfer. This
minimize misconfiguration and human errors

4.1.4. Dynamic Updates to the DNS

An authoritative name server can have dynamic updates from the
within the zone without intervention from NAT and DNS-ALG, so long
one avoids spreading a DNS zone across address realms. We
keeping a DNS zone within the same realm it is responsible for.
doing this, DNS update traffic will not cross address realms
hence will not be subject to consideration by DNS-ALG

Further, if dynamic updates do cross address realms, and the
must always be secured via DNSSEC, then such updates are clearly
of scope for DNS-ALG (as described in section 7).

4.2. Resource records in all other

The answer, authority, and additional sections all share the
format, with a variable number of resource records. The number of
specific to each of the sections may be found in the
count fields in DNS header. Each resource record has the
format

The TTL value supplied in the original RRs will be left unchanged
static address assignments. For dynamic address assignments, DNS_
will modify the TTL to be 0, so the RRs are used just for
transaction in progress, and not cached. RFC 2181 requires all
in an RRset (RRs with the same name, class and type, but
different RDATA) to have the same TTL. So if the TTL of an RR is
to 0, all other RRs within the same RRset will also be adjusted
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

The considerations specified in the Question section is equally
with names for PTR type RRs. Private address preceding the
"IN-ADDR.ARPA" (in reverse order of octets) must be replaced by
external address assignment (in reverse order), if a binding exists
The remaining fields for this RR remain unchanged

4.2.2. A type

The RDATA for A records is a 4-byte IP address. DNS_ALG would
replace the original address in RDATA with its externally assigned
address, if it succeeded in finding an address binding.
address translation should cause no changes to payload length.
the transport header checksum would need updating. In case of
to find an address binding, DNS_ALG would have to drop the record
decrement the corresponding COUNT field in the header section

4.2.3. CNAME, MX, NS and SOA type

No changes required to be made by DNS_ALG for these RRs, as the
does not contain any IP addresses. The host names within the
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

The following diagram illustrates the operation of DNS_ALG in a
bi-directional NAT router. We will illustrate by walking through
name lookup and reverse name lookup queries are processed

.
________________ . External.
( ) .
( ) . +-------------+
+--+ ( Internet )-.---|Border Router
|__|------ ( ) . +-------------+
/____\ (________________) . |
Root | . |
DNS Server | . ---------------
+---------------+ . | |
|Provider Router| . +--+ +--+
+---------------+ . |__| |__|
| . /____\ /____\
| . DNS Server Host
External domain | . 171.68.1.1 171.68.10.1
............................|...............................
Private domain |
| Private.
|
+--------------------------------------+
|Bi-Directional NAT router with DNS_ALG
| |
| Private addresses: 172.19/16 |
| External addresses: 131.108.1/24 |
+--------------------------------------+
| |
---------- ----------
| | DNS
+--+ +--+
|__| |__| for private.
/____\ /____\
Host A DNS
172.19.1.10 172.19.2.1
(Mapped to 131.108.1.8)

Figure 3: DNS-ALG operation in Bi-Directional NAT

The above diagram depicts a scenario where a company private.
using private address space 172.19/16 connects to the Internet
bi-directional NAT. DNS_ALG is embedded in the NAT device to
necessary DNS payload changes. NAT is configured to translate
private addresses space into an external address block



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
private.com's DNS server, so it can be referred in the
domain by a valid address

The company external.com is located in the external domain, using
registered address block of 171.68/16. Also shown in the topology
a root DNS server

Following simplifications are made to the above configuration

* private.com is not multihomed and all traffic to the
space transits a single NAT

* The DNS server for private.com is authoritative for
private.com domain and points to the root server for all
DNS resolutions. The same is true for the DNS server
external.com

* The internal name servers for private.com and external.com
same as their DMZ name servers. The DNS servers for
domains are configured with addresses private to
organization

* The name resolvers on host nodes do not have
available on them and desire recursive service from servers
All name servers are assumed to be able to provide
service

5.1. Outgoing Name-lookup

Say, Host A in private.com needs to perform a name lookup for host
in external.com to initiate a session with X. This would proceed
follows

1. Host A sends a UDP based name lookup query (A record)
"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'
statically assigned external address. DNS_ALG will make
changes to the payload

3. The root server, in turn, refers the local DNS server to query
DNS server for External.com. This referal transits the NAT
to the local DNS server. NAT would simply translate the IP
UDP headers of the incoming packet to reflect DNS server's
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
for external.com, once again, enroute NAT. Just as with the
to root, The NAT router would change the IP and UDP headers
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
171.68.10.1. This reply also transits the NAT. NAT
translate the IP and UDP headers of the incoming packet to
DNS server's private address. Once again, no changes to
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
host X, using a destination IP address of 171.68.10.1. This
and any others that follow in this session will be translated
usual by NAT

Note, DNS_ALG does not change the payload for DNS packets in
direction

5.2. Reverse name lookups originated from private

This scenario builds on the previous case by having host A
Private.com perform a reverse name lookup on 171.68.10.1, which
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
server's statically assigned external address. DNS_ALG will
no changes to the payload

3. The root server, in turn, refers the local DNS server to query
DNS server for External.com. This referal transits the NAT
to the local DNS server. NAT would simply translate the IP
UDP headers of the incoming packet to reflect DNS server's
address. No changes to the payload by DNS_ALG

4. Private.com DNS server will now send the query to the DNS
for external.com, once again, enroute NAT. Just as with the
to root, The NAT router would change the IP and UDP headers
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
"X.External.Com.". This reply also transits the NAT. NAT
translate the IP and UDP headers of the incoming packet to
DNS server's private address. Once again, no changes to
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

This time, host X in external.com wishes to initiate a session
host A in Private.com. Below are the sequence of events that
place

1. Host X sends a UDP based name lookup query (A record)
"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
query the DNS server for private.com

4. External.com DNS server will now send the query to the DNS
for Private.com. This query traverses the NAT router. NAT
change the IP and UDP headers of the packet to reflect the
server's private address. DNS_ALG will make no changes to
payload

5. The DNS server for Private.com replies with the IP
172.19.1.10 for host A. This reply also transits the NAT.
would translate the IP and UDP headers of the outgoing packet
the DNS server

DNS_ALG will request NAT to (a) setup a temporary binding for
A (172.19.1.10) with an external address and (b) initiate Bind
holdout timer. When NAT successfully sets up a temporary
with an external address (say, 131.108.1.12), DNS_ALG would
the payload to replace A's private address with its
assigned address and set the Cache timeout to 0.

6. The server in External.com replies to host

When Host X finds the address of Host A, X initiates a session
A, using a destination IP address of 131.108.1.12. This datagram
any others that follow in this session will be translated as usual
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
for Private domain

5.4. Reverse name lookups originated from external

This scenario builds on the previous case (section 5.3) by
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
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
server

3. The root server, in turn, refers the local DNS server to query
DNS server for Private.com

4. External.com DNS server will now send the query to the DNS
for Private.com. This query traverses the NAT router. NAT
change the IP and UDP headers to reflect the DNS server's
address

DNS_ALG will enquire NAT for the private address associated
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
"A.Private.Com.". This reply also transits the NAT. NAT
translate the IP and UDP headers of the incoming packet to
DNS server's private address

Once again, DNS_ALG will enquire NAT for the assigned
address associated with the private address of 172.19.1.10
modify the payload, replacing 172.19.1.10 with the
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
server for Private domain

6. Illustration of DNS_ALG in conjunction with Twice-

The following diagram illustrates the operation of DNS_ALG in a
NAT router. As before, we will illustrate by walking through how
lookup and reverse name lookup queries are processed



Srisuresh, et al. Informational [Page 19]

RFC 2694 DNS extensions to NAT September 1999


.
________________ . External.
( ) .
( ) . +-------------+
+--+ ( Internet )-.---|Border Router
|__|------ ( ) . +-------------+
/____\ (________________) . |
Root | . |
DNS Server | . ---------------
+---------------+ . | |
|Provider Router| . +--+ +--+
+---------------+ . |__| |__|
| . /____\ /____\
| . DNS Server Host
External domain | . 171.68.1.1 171.68.10.1
............................|...............................
Private domain |
| Private.
|
+-------------------------------------------+
| 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
+--+ +--+
|__| |__| for private.
/____\ /____\
Host A DNS
171.68.1.10 171.68.2.1
(Mapped to 131.108.1.8)

Figure 4: DNS-ALG operation in Twice-NAT

In this scenario, hosts in private.com were not numbered from the
1918 reserved 172.19/16 space, but rather were numbered with
globally-routable 171.68/16 network, the same as external.com.
only does private.com need translation service for its own
addresses, but it also needs translation service if any of
hosts are to be able to exchange datagrams with hosts
external.com. Twice-NAT accommodates the transition by
the overlapping address space used in external.com with a



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
within the private domain to direct datagrams destined for
address block 10/8 through Twice-NAT device to the external
network space

Simplifications and assumptions made in section 5.0 will be
here as well

6.1. Outgoing Name-lookup

Say, Host A in private.com needs to perform a name lookup for host
in external.com (host X has a FQDN of X.external.com), to find
address. This would would proceed as follows

1. Host A sends a UDP based name lookup query (A record)
"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'
statically assigned external address. DNS_ALG will make
changes to the payload

3. The root server, in turn, refers the local DNS server to query
DNS server for External.com. This referal transits the NAT
to the local DNS server. NAT would simply translate the IP
UDP headers of the incoming packet to reflect DNS server's
address

DNS_ALG will request NAT for an assigned private address for
referral server and replace the external address with its
private address in the payload

4. Private.com DNS server will now send the query to the DNS
for external.com, using its assigned private address, via NAT
This time, NAT would change the IP and UDP headers to reflect
External addresses of the DNS servers. I.e., Private.com
server's IP address is changed to its assigned external
and External.Com DNS server's assigned Private address is
to its external address

DNS_ALG will make no changes to the payload

5. The DNS server for external.com replies with the IP
171.68.10.1. This reply also transits the NAT. NAT would
again translate the IP and UDP headers of the incoming to
the private addresses of the DNS servers. I.e., Private.com





Srisuresh, et al. Informational [Page 21]

RFC 2694 DNS extensions to NAT September 1999


server's IP address is changed to its private address
External.Com DNS server's external address is changed to
assigned Private address

DNS_ALG will request NAT to (a) set up a temporary binding
Host X (171.68.10.1) with a private address and (b)
Bind-holdout timer. When NAT successfully sets up
binding with a private address (say, 10.0.0.254), DNS_ALG
modify the payload to replace X's external address with
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
host X, using a destination IP address of 10.0.0.254. This
and any others that follow in this session will be translated
usual by Twice NAT

Note, the DNS_ALG has had to change payload in both directions

6.2. Reverse name lookups originated from private

This scenario builds on the previous case by having host A
Private.com perform a reverse name lookup on 10.0.0.254, which
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
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
DNS server for External.com. This referal transits the NAT
to the local DNS server. NAT would simply translate the IP
UDP headers of the incoming packet to reflect DNS server's
address

As with the original query, DNS_ALG will translate the
assigned address 10.0.0.254 with its external address 171.68.10.1.
In addition, DNS_ALG will replace the external address of
referal server (i.e., the DNS server for External.com) with
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
for external.com, using its statically assigned private address
via NAT. This time, NAT would change the IP and UDP headers
reflect the External addresses of the DNS servers. I.e.,
Private.com DNS server's IP address is changed to its
external address and External.Com DNS server's assigned
address is changed to its external address

As with the original query, DNS_ALG will translate the
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
"X.External.Com.". This reply also transits the NAT. NAT
once again translate the IP and UDP headers of the incoming
reflect the private addresses of the DNS servers. I.e.,
Private.com DNS server's IP address is changed to its
address and External.Com DNS server's external address is
to its assigned Private address

Once again, DNS_ALG will translate the query section,
the external address 171.68.10.1 with its assigned private
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

This time, host X in external.com wishes to initiate a session
host A in Private.com. Below are the sequence of events that
place

1. Host X sends a UDP based name lookup query (A record)
"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
query the DNS server for private.com

4. External.com DNS server will now send the query to the DNS
for Private.com. This query traverses the NAT router. NAT
change the IP and UDP headers to reflect the private addresses
the DNS servers. I.e., Private.com DNS server's IP address
changed to its private address and External.Com DNS server'
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
171.68.1.10 for host A. This reply also transits the NAT.
would once again translate the IP and UDP headers of the
to reflect the external addresses of the DNS servers. I.e.,
Private.com DNS server's IP address is changed to its
external address and External.Com DNS server's assigned
address is changed to its external address

DNS_ALG will request NAT to (a) set up temporary binding for
A (171.68.1.10) with an external address and (b) initiate Bind
holdout timer. When NAT succeeds in finding an external
(say, 131.108.1.12) to temporarily bind to host A, DNS_ALG
modify the payload to replace A's private address with
external assigned address and set the Cache timeout to 0.

6. The server in External.com replies to host

When Host X finds the address of Host A, X initiates a session
A, using a destination IP address of 131.108.1.12. This datagram
any others that follow in this session will be translated as usual
the NAT

Note, DNS_ALG changes only the response packets from the DNS
for Private domain

6.4. Reverse name lookups originated from external

This scenario builds on the previous case (section 6.3) by
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
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
server

3. The root server, in turn, refers the local DNS server to query
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
for Private.com. This query traverses the NAT router. NAT
change the IP and UDP headers to reflect the private addresses
the DNS servers. I.e., Private.com DNS server's IP address
changed to its private address and External.Com DNS server'
external address is changed to assigned Private address

DNS_ALG will enquire NAT for the private address associated
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
"A.Private.Com.". This reply also transits the NAT. NAT would
again translate the IP and UDP headers of the incoming to
the external addresses of the DNS servers. I.e., Private.com
server's IP address is changed to its assigned external
and External.Com DNS server's assigned private address is
to its external address

Once again, DNS_ALG will enquire NAT for the assigned
address associated with the private address of 172.19.1.10
modify the payload, replacing 171.68.1.10 with the
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
server for Private domain

7. DNS-ALG limitations and Future

NAT increases the probability of mis-addressing. For example,
local address may be bound to different public address at
times and vice versa. As a result, hosts that cache the name
address mapping for longer periods than the NAT router is
to hold the map are likely to misaddress their sessions. Note,
is mainly an issue with bad host implementations that hold
records longer than the TTL in them allows and is not
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
to queries originating from the external world will be broken by
DNS-ALG. At best, DNS-ALG would be able to transform secure
data into unprotected data. End-node demanding DNS replies to
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
come from (i.e., internal or external), it will most likely have



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
serious limitations to DNS_ALG. Zone transfers between DNS-
servers is also impacted the same way, if the transfer
address realms

The good news, however, is that only end-nodes in DMZ pay the
for the above limitation in a traditional NAT (or, a bi-
NAT), as external end-nodes may not access internal hosts due to
replies not being secure. However, for outgoing sessions (
private network) in a bi-directional NAT setup, the DNS queries
be signed and securely accepted by DMZ and other internal hosts
DNS_ALG does not intercept outgoing DNS queries and incoming replies
Lastly, zone transfers between DNS-SEC servers within the
private network are not impacted

Clearly, with DNS SEC deployment in DNS servers and end-
resolvers, the scheme suggested in this document will not work

8. Security

If DNS packets are encrypted/authenticated per DNSSEC, then DNS_
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
before forwarding packets to a different realm. For example, if DNS
ALG, NAT and IPsec gateway (providing secure tunneling service)
resident on the same device, DNS-ALG will have access to the
security association keys. The preceding section, "DNS-
limitations and Future Work" has coverage on DNS_ALG
considerations

Further, with DNS-ALG, there is a possibility of denial of
attack from a malicious user, as outlined in section 3.1.
3.1 suggests some ways to counter this attack



[1] Srisuresh, P. and M. Holdrege, "IP Network Address
(NAT) Terminology and Considerations", RFC 2663, August 1999.

[2] Egevang, K. and P. Francis, "The IP Network Address
(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,
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",
13, RFC 1034, November 1987.

[5] Mockapetris, P., "Domain Names - Implementation
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 --
Layers", STD 3, RFC 1122, October 1989.

[8] Braden, R., "Requirements for Internet Hosts -- Application
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
Behaviour Today", RFC 2101, February 1997.

[11] Eastlake, D., "Domain Name System Security Extensions",
2535, March 1999.

[12] Vixie, P., Thompson, S., Rekhter Y. and J. Bound, "
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
1997.

[13] Eastlake, D., "Secure Domain Name System Dynamic Update",
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
Operation of Secondary DNS Servers", RFC 2182, July 1997.















Srisuresh, et al. Informational [Page 27]

RFC 2694 DNS extensions to NAT September 1999


Authors'

Pyda
849 Erie
Milpitas, CA 95035
U.S.A

Phone: +1 (408) 263-7527
EMail: srisuresh@yahoo.


George
Internet Transport
B29 Room 129
BT
Martlesham

Suffolk IP5 3


Phone: +44 1473 640756
Fax: +44 1473 640709
EMail: george@gideon.bt.co.


Praveen
cisco
170 West Tasman
San Jose, CA 95134

Phone: +1 (408) 526-5066
EMail: spa@cisco.


Andy
Juniper Networks, Inc
385 Ravensdale Drive
Mountain View, CA 94043

Phone: +1 (650) 526-8037
Fax: +1 (650) 526-8001
EMail: ahh@juniper.









Srisuresh, et al. Informational [Page 28]

RFC 2694 DNS extensions to NAT September 1999


Full Copyright

Copyright (C) The Internet Society (1999). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE



Funding for the RFC Editor function is currently provided by
Internet Society



















Srisuresh, et al. Informational [Page 29]

---

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.



RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX

---