< draft-ietf-nat-dns-alg-03.txt   draft-ietf-nat-dns-alg-04.txt >
NAT Working Group P. Srisuresh, Lucent Technologies NAT Working Group P. Srisuresh, Lucent Technologies
INTERNET-DRAFT G. Tsirtsis, BT Laboratories INTERNET-DRAFT G. Tsirtsis, BT Laboratories
Category: Informational P. Akkiraju, Cisco Systems Category: Informational P. Akkiraju, Cisco Systems
Expire in six months A. Heffernan, Juniper Networks Expire in six months A. Heffernan, Juniper Networks
June 1999 June 1999
DNS extensions to Network Address Translators (DNS_ALG) DNS extensions to Network Address Translators (DNS_ALG)
<draft-ietf-nat-dns-alg-03.txt> <draft-ietf-nat-dns-alg-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. Internet-Drafts are with all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may its areas, and its working groups. Note that other groups may
also distribute working documents as Internet-Drafts. also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
skipping to change at page 1, line 36 skipping to change at page 1, line 36
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
Domain Name Service(DNS) provides name to address mapping within Domain Name Service(DNS) provides name to address mapping within
a routing class (ex: IP). Network Address Translators (NATs) a routing class (ex: IP). Network Address Translators (NATs)
attempt to provide transparent routing between hosts in disparate attempt to provide transparent routing between hosts in disparate
routing realms of the same routing class. Typically, NATs exist at address realms of the same routing class. Typically, NATs exist at
the border of a stub domain, hiding private addresses from external the border of a stub domain, hiding private addresses from external
addresses. This document identifies the need for DNS extensions addresses. This document identifies the need for DNS extensions
to NATs and outlines how a DNS Application Level Gateway (DNS_ALG) to NATs and outlines how a DNS Application Level Gateway (DNS_ALG)
can meet the need. DNS_ALG modifies payload transparently to alter can meet the need. DNS_ALG modifies payload transparently to alter
address mapping of hosts as DNS packets cross one routing realm address mapping of hosts as DNS packets cross one address realm
into another. The document also illustrates the operation of into another. The document also illustrates the operation of
DNS_ALG with specific examples. DNS_ALG with specific examples.
1. Introduction 1. Introduction
Network Address Translators (NATs) are often used when network's Network Address Translators (NATs) are often used when network's
internal IP addresses cannot be used outside the network either internal IP addresses cannot be used outside the network either
for privacy reasons or because they are invalid for use outside for privacy reasons or because they are invalid for use outside
the network. the network.
Ideally speaking, a host name uniquely identifies a host and its Ideally speaking, a host name uniquely identifies a host and its
address is used to locate routes to the host. However, host name address is used to locate routes to the host. However, host name
and address are often not distinguished and used interchangeably and address are often not distinguished and used interchangeably
by applications. Applications embed IP address instead of host by applications. Applications embed IP address instead of host
name in payload. Examples would be e-mails that specify their MX name in payload. Examples would be e-mails that specify their MX
server address instead of server name as sender ID; HTML files server address (ex: user@666.42.7.11) instead of server name
that include IP address instead of names in URLs, etc. Use of IP (ex: user@private.com) as sender ID; HTML files that include IP
address in place of host name in payload represents a problem as address instead of names in URLs, etc. Use of IP address in
the packet traverses a NAT device because NATs alter network and place of host name in payload represents a problem as the packet
transport headers to suit a routing realm, but not payload. 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 DNS provides Name to address mapping. Whereas, NAT performs
address translation (in network and transport headers) in address translation (in network and transport headers) in
datagrams traversing between private and external routing realms. datagrams traversing between private and external address realms.
DNS Application Level Gateway (DNS_ALG) outlined in this document DNS Application Level Gateway (DNS_ALG) outlined in this document
helps translate Name-to-Private-Address mapping in DNS payloads helps translate Name-to-Private-Address mapping in DNS payloads
into Name-to-external-address mapping and vice versa using state into Name-to-external-address mapping and vice versa using state
information available on NAT. information available on NAT.
A Network Address Port Translator (NAPT) performs address and A Network Address Port Translator (NAPT) performs address and
Transport level port translations (i.e, TCP, UDP ports and ICMP Transport level port translations (i.e, TCP, UDP ports and ICMP
query IDs). DNS name mapping granularity, however, is limited to query IDs). DNS name mapping granularity, however, is limited to
IP addresses and does not extend to transport level identifiers. IP addresses and does not extend to transport level identifiers.
As a result, the DNS_ALG processing for an NAPT configuration is As a result, the DNS_ALG processing for an NAPT configuration is
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Hence, the discussion in the remainder of the document will focus Hence, the discussion in the remainder of the document will focus
mainly on Basic NAT, Bi-directional NAT and Twice NAT mainly on Basic NAT, Bi-directional NAT and Twice NAT
configurations, with no specific reference to NAPT setup. configurations, with no specific reference to NAPT setup.
Definitions for DNS and related terms may be found in [Ref 3] and 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]. [Ref 4]. Definitions for NAT related terms may be found in [Ref 1].
2. Requirement for DNS extensions. 2. Requirement for DNS extensions.
There are many ways to ensure that a host name is mapped to an There are many ways to ensure that a host name is mapped to an
address relevant within a routing realm. In the following address relevant within an address realm. In the following
sections, we will identify where DNS extensions would be needed. sections, we will identify where DNS extensions would be needed.
Typically, organizations have two types of authoritative name Typically, organizations have two types of authoritative name
servers. Internal authoritative name servers identify all (or servers. Internal authoritative name servers identify all (or
majority of) corporate resources within the organization. Only a majority of) corporate resources within the organization. Only a
portion of these hosts are allowed to be accessed by the external portion of these hosts are allowed to be accessed by the external
world. The remaining hosts and their names are unique to the world. The remaining hosts and their names are unique to the
private network. Hosts visible to the external world and the private network. Hosts visible to the external world and the
authoritative name server that maps their names to network authoritative name server that maps their names to network
addresses are often configured within a DMZ (De-Militarized Zone) addresses are often configured within a DMZ (De-Militarized Zone)
skipping to change at page 4, line 7 skipping to change at page 4, line 7
| | | | | | | |
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
|__| |__| |__| |__| |__| |__| |__| |__|
/____\ /____\ /____\ /____\ /____\ /____\ /____\ /____\
Int-Host1 Int-Host2 ..... Int-Hostn Int-Name Server Int-Host1 Int-Host2 ..... Int-Hostn Int-Name Server
Figure 1: DMZ network configuration of a private Network. Figure 1: DMZ network configuration of a private Network.
Figure 1 above illustrates configuration of a private network which Figure 1 above illustrates configuration of a private network which
includes a DMZ. Actual configurations may vary. Internal name servers includes a DMZ. Actual configurations may vary. Internal name servers
are accessed by users within private network only. Internal DNS are accessed by users within the private network only. Internal DNS
queries and responses do not cross the private routing boundary. DMZ 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 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. and could be accessed by external as well as internal hosts.
Throughout this document, our focus will be limited to DMZ hosts and Throughout this document, our focus will be limited to DMZ hosts and
DMZ name servers and will not include internal hosts and internal DMZ name servers and will not include internal hosts and internal
name servers, unless they happen to be same. name servers, unless they happen to be same.
2.1. DMZ hosts assigned static external addresses on NAT 2.1. DMZ hosts assigned static external addresses on NAT
Take the case where DMZ hosts are assigned static external Take the case where DMZ hosts are assigned static external
addresses on the NAT device. Note, all hosts within private domain, addresses on the NAT device. Note, all hosts within private domain,
including the DMZ hosts are identified by their private addresses. including the DMZ hosts are identified by their private addresses.
Static mapping on the NAT device allows the the DMZ hosts to be Static mapping on the NAT device allows the DMZ hosts to be
identified by their public addresses in the external domain. identified by their public addresses in the external domain.
2.1.1. Private networks with no DMZ name servers 2.1.1. Private networks with no DMZ name servers
Take the case where a private network has no DMZ name server Take the case where a private network has no DMZ name server
for itself. If the private network is connected to a single service for itself. If the private network is connected to a single service
provider for external connectivity, the DMZ hosts may be listed provider for external connectivity, the DMZ hosts may be listed
by their external addresses in the authoritative name servers of by their external addresses in the authoritative name servers of
the service provider itself. the service provider within their forward and in-add.arpa reverse
zones.
If the network is connected to multiple service providers, the If the network is connected to multiple service providers, the
DMZ host names may be listed by their external address(es) within DMZ host names may be listed by their external address(es) within
the authoritative name servers of each of the service providers, the authoritative name servers of each of the service providers.
especially if the private network is assigned different address 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. prefixes by the service providers.
In both cases, externally generated DNS lookups will not reach the In both cases, externally generated DNS lookups will not reach the
private network. A large number of NAT based private domains private network. A large number of NAT based private domains
pursue this option to have their DMZ hosts listed by their pursue this option to have their DMZ hosts listed by their
external addresses on service provider's name servers. external addresses on service provider's name servers.
2.1.2. Private networks with DMZ name servers 2.1.2. Private networks with DMZ name servers
Take the case where a private network opts to keep an authoritative Take the case where a private network opts to keep an authoritative
skipping to change at page 5, line 9 skipping to change at page 5, line 11
network is connected to a single service provider, the DMZ name network is connected to a single service provider, the DMZ name
server may be configured to obviate DNS payload interceptions as server may be configured to obviate DNS payload interceptions as
follows. The hosts in DMZ name server must be mapped to their follows. The hosts in DMZ name server must be mapped to their
statically assigned external addresses and the internal name server statically assigned external addresses and the internal name server
must be configured to bypass the DMZ name server for queries must be configured to bypass the DMZ name server for queries
concerning external hosts. This scheme ensures that DMZ name concerning external hosts. This scheme ensures that DMZ name
servers are set for exclusive access to external hosts alone (not servers are set for exclusive access to external hosts alone (not
even to the DMZ hosts) and hence can be configured with external even to the DMZ hosts) and hence can be configured with external
addresses only. addresses only.
The above scheme fails to scale when the private network is The above scheme requires careful administrative planning to ensure
connected to multiple service providers, assigning different that DMZ name servers are not contacted by the private hosts
network addresses to the DMZ hosts. DNS extensions to NAT directly or indirectly (through the internal name servers). Using
would prove useful here. It is conceivable, however, to DNS-ALG would obviate the administrative ordeals with this approach.
have a separate pair of DMZ servers (primary and secondary)
configured for each network address prefix assigned by a
service provider for the organization.
2.2. DMZ hosts assigned external addresses dynamically on NAT 2.2. DMZ hosts assigned external addresses dynamically on NAT
Take the case where DMZ hosts in a private network are assigned Take the case where DMZ hosts in a private network are assigned
external addresses dynamically by NAT. While the addresses issued external addresses dynamically by NAT. While the addresses issued
to these hosts are fixed within the private network, their to these hosts are fixed within the private network, their
externally known addresses are ephemeral, as determined by NAT. externally known addresses are ephemeral, as determined by NAT.
In such a scenario, it is mandatory for the private organization 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 to have a DMZ name server in order to allow access to DMZ hosts
by their name. by their name.
The DMZ name server would be configured with private addresses The DMZ name server would be configured with private addresses
for DMZ hosts. DNS Application Level Gateway (DNS_ALG) residing for DMZ hosts. DNS Application Level Gateway (DNS_ALG) residing
on NAT device will intercept the DNS packets directed to or from on NAT device will intercept the DNS packets directed to or from
the DMZ name server(s) and perform transparent payload translations the DMZ name server(s) and perform transparent payload translations
so that a DMZ host name has the right address mapping within so that a DMZ host name has the right address mapping within
each routing boundary (i.e., private or external). each address realm (i.e., private or external).
3. Interactions between NAT and DNS_ALG 3. Interactions between NAT and DNS_ALG
This document operates on the paradigm that interconnecting routing This document operates on the paradigm that interconnecting address
realms may have overlapping address space. But, names of hosts realms may have overlapping address space. But, names of hosts
within interconnected realms must be end-to-end unique in order for 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 them to be accessed by all hosts. In other words, there cannot be
an overlap of FQDNs between end nodes communicating with each other. an overlap of FQDNs between end nodes communicating with each other.
The following diagram illustrates how a DNS packet traversing a NAT The following diagram illustrates how a DNS packet traversing a NAT
device (with DNS_ALG) is subject to header and payload translations. 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 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 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 headers of the DNS packet and notify DNS-ALG to perform DNS payload
changes. DNS-ALG would interact with NAT and use NAT state changes. DNS-ALG would interact with NAT and use NAT state
skipping to change at page 8, line 17 skipping to change at page 8, line 17
3.2. Incoming queries 3.2. Incoming queries
In order to initiate incoming sessions, an external host obtains 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 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 DNS request. This request constitutes prelude to the start of
a potential new session. a potential new session.
The external host resolver makes a name lookup for the DMZ host The external host resolver makes a name lookup for the DMZ host
through its DNS server. When the DNS server does not have a through its DNS server. When the DNS server does not have a
record of IPv4 address attached to this name, the lookup query record of IPv4 address attached to this name, the lookup query
is redirected at some point to the the Primary/Backup DNS server is redirected at some point to the Primary/Backup DNS server
(i.e., in DMZ) of the private stub domain. (i.e., in DMZ) of the private stub domain.
Enroute to DMZ name server, DNS_ALG would intercept the datagram Enroute to DMZ name server, DNS_ALG would intercept the datagram
and modify the query as follows. and modify the query as follows.
a) For Host name to Host address query requests: a) For Host name to Host address query requests:
Make no change to the DNS payload. Make no change to the DNS payload.
b) For Host address to Host name queries: b) For Host address to Host name queries:
Replace the external V4 address octets (in reverse order) Replace the external V4 address octets (in reverse order)
skipping to change at page 9, line 14 skipping to change at page 9, line 14
drop the reply. The sender will have to resend the query drop the reply. The sender will have to resend the query
(as would happen when a router enroute drops the response). (as would happen when a router enroute drops the response).
For static address assignments, the TTL value supplied in the For static address assignments, the TTL value supplied in the
original RR will be left unchanged. For dynamic address assignments, original RR will be left unchanged. For dynamic address assignments,
DNS_ALG would modify the TTL value on DNS resource records (RRs) to 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 be 0, implying that the RRs should only be used for transaction in
progress, and not be cached. For compatibility with broken progress, and not be cached. For compatibility with broken
implementations, TTL of 1 might in practice work better. 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 In addition, NAT would be requested to initiate a bind-holdout timer
following the assignment. If no session is initiated to the private following the assignment. If no session is initiated to the private
host within the Bind-holdout time period, NAT would terminate the host within the Bind-holdout time period, NAT would terminate the
temporary binding. temporary binding.
3.3. Outgoing Queries 3.3. Outgoing Queries
For Basic and bi-directional NATs, there is no need to distinguish For Basic and bi-directional NATs, there is no need to distinguish
between temporary and committed bindings for outgoing queries. This between temporary and committed bindings for outgoing queries. This
is because, DNS_ALG does not modify the DNS packets directed to or is because, DNS_ALG does not modify the DNS packets directed to or
skipping to change at page 9, line 48 skipping to change at page 10, line 11
address bindings are created when responses are sent by private DNS address bindings are created when responses are sent by private DNS
servers and temporary external to private address bindings are servers and temporary external to private address bindings are
created when responses are sent by external DNS servers. created when responses are sent by external DNS servers.
4. DNS payload modifications by DNS-ALG 4. DNS payload modifications by DNS-ALG
Typically, UDP is employed as the transport mechanism for DNS Typically, UDP is employed as the transport mechanism for DNS
queries and responses and TCP for Zone refresh activities. In queries and responses and TCP for Zone refresh activities. In
either case, name servers are accessed using a well-known DNS either case, name servers are accessed using a well-known DNS
server port 53 (decimal) and all DNS payloads have the following server port 53 (decimal) and all DNS payloads have the following
format of data [Ref 4]. The header section is always present and format of data [Ref 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 includes fields specifying which of the remaining sections are
present. The header identifies if the message is a query or a present. The header identifies if the message is a query or a
response. No changes are required to be made by NATs to the response. No changes are required to be made by DNS-ALG to the
Header section. DNS_ALG would parse only the DNS payloads whose Header section. DNS_ALG would parse only the DNS payloads whose
QCLASS is set to IN (IP class). QCLASS is set to IN (IP class).
+---------------------+ +---------------------+
| Header | | Header |
+---------------------+ +---------------------+
| Question | the question for the name server | Question | the question for the name server
+---------------------+ +---------------------+
| Answer | RRs answering the question | Answer | RRs answering the question
+---------------------+ +---------------------+
skipping to change at page 10, line 40 skipping to change at page 11, line 7
/ QNAME / / QNAME /
/ / / /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QTYPE | | QTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QCLASS | | QCLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4.1.1. PTR type Queries 4.1.1. PTR type Queries
DNS_ALG must identify all names, whose FQDNs (i.e., Fully Qualified DNS_ALG must identify all names, whose FQDNs (i.e., Fully Qualified
Domain Names) fall within IN-ADDR.ARPA domain and replace the Domain Names) fall within IN-ADDR.ARPA domain and replace the
address octets (in reverse order) preceding the string address octets (in reverse order) preceding the string
"IN-ADDR.ARPA" with the corresponding assigned address octets "IN-ADDR.ARPA" with the corresponding assigned address octets
in reverse order, only if the address binding is active on in reverse order, only if the address binding is active on
the NAT router. If the address preceding the string the NAT router. If the address preceding the string
"IN-ADDR.ARPA" falls within the NAT address map, but does not "IN-ADDR.ARPA" falls within the NAT address map, but does not
have at least a temporary address binding, DNS_ALG would simply have at least a temporary address binding, DNS_ALG would simply
simply respond back (as a DNS name server would) with a response simply respond back (as a DNS name server would) with a response
code (RCODE) of 5 (REFUSED to respond due to policy reasons) code (RCODE) of 5 (REFUSED to respond due to policy reasons)
and set ANCOUNT, NSCOUNT and ARCOUT to 0 in the header section and set ANCOUNT, NSCOUNT and ARCOUT to 0 in the header section
of the response. of the response.
Note that the above form of host address to host name type queries Note that the above form of host address to host name type queries
will likely yield different results at different times, depending will likely yield different results at different times, depending
upon address bind status in NAT at a given time. upon address bind status in NAT at a given time.
For example, a resolver that wanted to find out the hostname For example, a resolver that wanted to find out the hostname
corresponding to address 198.76.29.1 (externally) would pursue a corresponding to address 198.76.29.1 (externally) would pursue a
query of the form: query of the form:
QTYPE = PTR, QCLASS = IN, QNAME = 1.29.76.198.IN-ADDR.ARPA. 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 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 internally mapped to a private address of 10.0.0.1, modify the
query as below and forward to DMZ name server within private query as below and forward to DMZ name server within private
network. network.
QTYPE = PTR, QCLASS = IN, QNAME = 1.0.0.10.IN-ADDR.ARPA QTYPE = PTR, QCLASS = IN, QNAME = 1.0.0.10.IN-ADDR.ARPA
Presumably, the DMZ name server is the authoritative name server Presumably, the DMZ name server is the authoritative name server
for 10.IN-ADDR.ARPA zone and will respond with an RR of the for 10.IN-ADDR.ARPA zone and will respond with an RR of the
following form in answer section. DNS_ALG translations of the following form in answer section. DNS_ALG translations of the
response RRs will be considered in a following section. response RRs will be considered in a following section.
1.0.0.10.IN-ADDR.ARPA PTR host1.fooboo_org.provider_domain 1.0.0.10.IN-ADDR.ARPA PTR host1.fooboo_org.provider_domain
An example of Inverse translation is e-mail programs using An example of Inverse translation is e-mail programs using
inverse translation to trace e-mail originating hosts for spam inverse translation to trace e-mail originating hosts for spam
prevention. Verify if the address from which the e-mail was sent prevention. Verify if the address from which the e-mail was sent
does indeed belong to the same domain name the sender claims in does indeed belong to the same domain name the sender claims in
sender ID. sender ID.
Query modifications of this nature will likely change the length Query modifications of this nature will likely change the length
of DNS payload. As a result, the corresponding IP and TCP/UDP of DNS payload. As a result, the corresponding IP and TCP/UDP
header checksums must be updated. In case of TCP based queries, header checksums must be updated. In case of TCP based queries,
the sequence number deltas must be tracked by NAT so that the the sequence number deltas must be tracked by NAT so that the
delta can be applied to subsequent sequence numbers in datagrams delta can be applied to subsequent sequence numbers in datagrams
in the same direction and acknowledgement numbers in datagrams in in the same direction and acknowledgement numbers in datagrams in
the opposite direction. In case of UDP based queries, message the opposite direction. In case of UDP based queries, message
sizes are restricted to 512 bytes (not counting the IP or UDP sizes are restricted to 512 bytes (not counting the IP or UDP
headers). Longer messages must be truncated and the TC bit should headers). Longer messages must be truncated and the TC bit should
be set in the header. be set in the header.
Lastly, any compressed domain names using pointers to represent Lastly, any compressed domain names using pointers to represent
common domain denominations must be updated to reflect new common domain denominations must be updated to reflect new
pointers with the right offset, if the original domain name had pointers with the right offset, if the original domain name had
to be translated by NAT. to be translated by NAT.
4.1.2. A, MX, NS and SOA type Queries 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. 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 4.1.3. AXFR type Queries
AXFR is a special zone transfer type query. Zone transfers from AXFR is a special zone transfer type query. Zone transfers from
private routing realm must be avoided for address assignments private address realm must be avoided for address assignments
that are not static. Typically, TCP is used for AXFR requests. that are not static. Typically, TCP is used for AXFR requests.
When changes are made to a zone, they must be distributed to all When changes are made to a zone, they must be distributed to all
name servers. The general model of automatic zone transfer or name servers. The general model of automatic zone transfer or
refreshing is that one of the name servers is the master or refreshing is that one of the name servers is the master or
primary for the zone. Changes are coordinated at the primary, primary for the zone. Changes are coordinated at the primary,
typically by editing a master file for the zone. After editing, typically by editing a master file for the zone. After editing,
the administrator signals the master server to load the new zone. the administrator signals the master server to load the new zone.
The other non-master or secondary servers for the zone The other non-master or secondary servers for the zone
periodically check the SERIAL field of the SOA for the zone for periodically check the SERIAL field of the SOA for the zone for
changes (at some polling intervals) and obtain new zone copies changes (at some polling intervals) and obtain new zone copies
when changes have been made. when changes have been made.
Zone transfer is usually from primary to backup name servers. In Zone transfer is usually from primary to backup name servers. In
the case of NAT supported private networks, both primary and the case of NAT supported private networks, primary and backup
backup servers will likely be in the same private domain. servers are advised to be located in the same private domain
In such a case, zone transfer does not cross the realm and (say, private.zone) so zone transfer is not across the domain
DNS_ALG support for zone transfer is not an issue. In the case a and DNS_ALG support for zone transfer is not an issue. In
secondary name server is located outside the premisis of private the case a secondary name server is located outside the private
network, zone transfers must not be permitted for non-static domain, zone transfers must not be permitted for non-static
address assignments. 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 During zone transfers, DNS_ALG must examine all A type records
and replace the original address octets with their statically and replace the original address octets with their statically
assigned address octets. DNS_ALG could also examine if there is assigned address octets. DNS_ALG could also examine if there is
an attempt to transfer records for hosts that are not assigned an attempt to transfer records for hosts that are not assigned
static addresses and drop those records alone or drop the whole static addresses and drop those records alone or drop the whole
transfer. This would minimize misconfiguration and human errors. transfer. This would minimize misconfiguration and human errors.
4.1.4. Dynamic Updates to the DNS. 4.1.4. Dynamic Updates to the DNS.
An authoritative name server can have dynamic updates from the An authoritative name server can have dynamic updates from the
nodes within the zone without intervention from NAT and DNS-ALG, nodes within the zone without intervention from NAT and DNS-ALG,
so long as one avoids spreading a DNS zone across routing so long as one avoids spreading a DNS zone across address
realms. We recommend keeping a DNS zone within the same realm realms. We recommend keeping a DNS zone within the same realm
it is responsible for. By doing this, DNS update traffic will it is responsible for. By doing this, DNS update traffic will
not cross routing realms and hence will not be subject to not cross address realms and hence will not be subject to
consideration by DNS-ALG. consideration by DNS-ALG.
Further, if dynamic updates do cross routing relams, and the Further, if dynamic updates do cross address realms, and the
updates must always be secured via DNSSEC, then such updates are updates must always be secured via DNSSEC, then such updates are
clearly out of scope for DNS-ALG (as described in section 7). clearly out of scope for DNS-ALG (as described in section 7).
4.2. Resource records in all other sections 4.2. Resource records in all other sections
The answer, authority, and additional sections all share the same The answer, authority, and additional sections all share the same
format, with a variable number of resource records. The number of format, with a variable number of resource records. The number of
RRs specific to each of the sections may be found in the RRs specific to each of the sections may be found in the
corresponding count fields in DNS header. Each resource record corresponding count fields in DNS header. Each resource record
has the following format: 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.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | | |
/ / / /
/ NAME / / NAME /
| | | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE | | TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS | | CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL | | TTL |
| | | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH | | RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA / / RDATA /
/ / / /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The TTL value supplied in the original RRs is left unchanged For
static address assignments. For dynamic address assignments,
DNS_ALG would modify the TTL to be 0, so the RRs are used just
for the transaction in progress, and not cached.
4.2.1. PTR type RRs 4.2.1. PTR type RRs
The considerations specified in the Question section The considerations specified in the Question section
is equally valid with names for PTR type RRs. Private address is equally valid with names for PTR type RRs. Private address
preceding the string "IN-ADDR.ARPA" (in reverse order of preceding the string "IN-ADDR.ARPA" (in reverse order of
octets) must be replaced by its external address assignment octets) must be replaced by its external address assignment
(in reverse order), if a binding exists. The remaining fields (in reverse order), if a binding exists. The remaining fields
for this RR remain unchanged. for this RR remain unchanged.
4.2.2. A type RRs 4.2.2. A type RRs
skipping to change at page 18, line 42 skipping to change at page 18, line 42
for Private.com. This query traverses the NAT router. NAT would for Private.com. This query traverses the NAT router. NAT would
change the IP and UDP headers of the packet to reflect the DNS 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 server's private address. DNS_ALG will make no changes to the
payload. payload.
5. The DNS server for Private.com replies with the IP address 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 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 would translate the IP and UDP headers of the outgoing packet
from the DNS server. from the DNS server.
DNS_ALG will request NAT to (a) setup a temporary binding for i 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 Host A (172.19.1.10) with an external address and (b) initiate
Bind-holdout timer. When NAT successfully sets up a temporary Bind-holdout timer. When NAT successfully sets up a temporary
binding with an external address (say, 131.108.1.12), DNS_ALG binding with an external address (say, 131.108.1.12), DNS_ALG
would modify the payload to replace A's private address with would modify the payload to replace A's private address with
its external assigned address and set the Cache timeout to 0. its external assigned address and set the Cache timeout to 0.
6. The server in External.com replies to host X 6. The server in External.com replies to host X
When Host X finds the address of Host A, X initiates a session with 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 A, using a destination IP address of 131.108.1.12. This datagram and
skipping to change at page 25, line 47 skipping to change at page 25, line 47
same local address may be bound to different public address at same local address may be bound to different public address at
different times and vice versa. As a result, hosts that cache different times and vice versa. As a result, hosts that cache
the name to address mapping for longer periods than the NAT the name to address mapping for longer periods than the NAT
router is configured to hold the map are likely to misaddress router is configured to hold the map are likely to misaddress
their sessions. Note, this is mainly an issue with bad host their sessions. Note, this is mainly an issue with bad host
implementations that hold DNS records longer than the TTL implementations that hold DNS records longer than the TTL
in them allows and is not directly attributable to the in them allows and is not directly attributable to the
mechanism described here. mechanism described here.
DNS_ALG cannot support secure DNS name servers in the private DNS_ALG cannot support secure DNS name servers in the private
domain. I.e., an authoritative DNS name server in the DMZ cannot domain. I.e., Signed replies from an authoritative DNS name server
sign replies to queries that originate from the external world. in the DMZ to queries originating from the external world will be
Since the DNS server does not have a way to find where the queries broken by the DNS-ALG. At best, DNS-ALG would be able to transform
come from (i.e., internal or external), it will most likely have secure dnssec data into unprotected data. End-node demanding DNS
to resort to the common denomination of today's insecure 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
Secondly, an end-node that demands DNS replies to be signed will where the queries come from (i.e., internal or external), it will
reject replies that have been tampered with by DNS_ALG. Both are most likely have to resort to the common denomination of today's
serious limitations to DNS_ALG. Zone transfers between DNS-SEC insecure DNS. Both are serious limitations to DNS_ALG. Zone
servers is also impacted the same way, if the transfer crosses transfers between DNS-SEC servers is also impacted the same way,
routing realms. if the transfer crosses address realms.
The good news, however, is that only end-nodes in DMZ pay the The good news, however, is that only end-nodes in DMZ pay the
price for the above limitation in a traditional NAT (or, a price for the above limitation in a traditional NAT (or, a
bi-directional NAT), as external end-nodes may not access internal bi-directional NAT), as external end-nodes may not access internal
hosts due to DNS replies not being secure. However, for outgoing hosts due to DNS replies not being secure. However, for outgoing
sessions (from private network) in a bi-directional NAT setup, sessions (from private network) in a bi-directional NAT setup,
the DNS queries can be signed and securely accepted by DMZ and the DNS queries can be signed and securely accepted by DMZ and
other internal hosts since DNS_ALG does not intercept outgoing other internal hosts since DNS_ALG does not intercept outgoing
DNS queries and incoming replies. Lastly, zone transfers between DNS queries and incoming replies. Lastly, zone transfers between
DNS-SEC servers within the same private network are not impacted. DNS-SEC servers within the same private network are not impacted.
Clearly, with DNS SEC deployment in DNS servers and end-host Clearly, with DNS SEC deployment in DNS servers and end-host
resolvers, the scheme suggested in this document will not work. resolvers, the scheme suggested in this document will not work.
8. Security considerations. 8. Security considerations.
If DNS packets are encrypted/authenticated per DNSSEC, then DNS_ALG If DNS packets are encrypted/authenticated per DNSSEC, then DNS_ALG
will fail because it won't be able to perform payload modifications. will fail because it won't be able to perform payload modifications.
Alternately, if packets must be preserved in a routing realm, Alternately, if packets must be preserved in an address realm,
DNS_ALG will need to hold the secret key to decrypt/verify payload DNS_ALG will need to hold the secret key to decrypt/verify payload
before forwarding packets to a different realm. For example, if before forwarding packets to a different realm. For example, if
DNS-ALG, NAT and IPsec gateway (providing secure tunneling service) DNS-ALG, NAT and IPsec gateway (providing secure tunneling service)
are resident on the same device, DNS-ALG will have access to the are resident on the same device, DNS-ALG will have access to the
IPsec security association keys. The preceding section, "DNS-ALG IPsec security association keys. The preceding section, "DNS-ALG
limitations and Future Work" has coverage on DNS_ALG security limitations and Future Work" has coverage on DNS_ALG security
considerations. 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 REFERENCES
[1] P. Srisuresh, M. Holdrege, "The IP Network Address [1] P. Srisuresh, M. Holdrege, "The IP Network Address
Translator (NAT) terminology and considerations", Translator (NAT) terminology and considerations",
<draft-ietf-nat-terminology-01.txt> - Work in progress, <draft-ietf-nat-terminology-03.txt> - Work in progress.
October 1998
[2] K. Egevang, P. Francis, "The IP Network Address Translator [2] K. Egevang, P. Francis, "The IP Network Address Translator
(NAT)", RFC 1631. (NAT)", RFC 1631.
[3] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and, [3] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and,
Lear, E. "Address Allocation for Private Internets", RFC 1918 Lear, E. "Address Allocation for Private Internets", RFC 1918
[4] P. Mockapetris, "Domain Names - Concepts and facilities", [4] P. Mockapetris, "Domain Names - Concepts and facilities",
RFC 1034. RFC 1034.
skipping to change at page 27, line 31 skipping to change at page 27, line 34
[11] Donald E. Eastlake, "Domain Name System Security Extensions", [11] Donald E. Eastlake, "Domain Name System Security Extensions",
RFC 2535 RFC 2535
[12] P. Vixie, S. Thompson, Y. Rekhter and J. Bound, "Dynamic [12] P. Vixie, S. Thompson, Y. Rekhter and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136 Updates in the Domain Name System (DNS UPDATE)", RFC 2136
[13] D. Eastlake, "Secure Domain Name System Dynamic Update", [13] D. Eastlake, "Secure Domain Name System Dynamic Update",
RFC 2137 RFC 2137
[14] R. Elz and R. Bush, "Clarifications to the DNS
specification", RFC 2181
[15] R. Elz, R. Bush, S. Bradner and M. Patton, "Selection and
Operation of Secondary DNS Servers", RFC 2182
Authors' Addresses Authors' Addresses
Pyda Srisuresh Pyda Srisuresh
Lucent technologies Lucent technologies
Pleasanton, CA 94588-8519 Pleasanton, CA 94588-8519
U.S.A. U.S.A.
Phone: +1 (925) 737-2153 Phone: +1 (925) 737-2153
Fax: +1 (925) 737-2110 Fax: +1 (925) 737-2110
e-mail: suresh@ra.lucent.com e-mail: suresh@ra.lucent.com
 End of changes. 41 change blocks. 
138 lines changed or deleted 171 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/