Network Working Group                                       P. Srisuresh
Request for Comments: 2694                                    Consultant
Category: Informational                                      G. Tsirtsis
                                                         BT Laboratories
                                                             P. Akkiraju
                                                           Cisco Systems
                                                            A. Heffernan
                                                        Juniper Networks
                                                          September 1999
        
Network Working Group                                       P. Srisuresh
Request for Comments: 2694                                    Consultant
Category: Informational                                      G. Tsirtsis
                                                         BT Laboratories
                                                             P. Akkiraju
                                                           Cisco Systems
                                                            A. Heffernan
                                                        Juniper Networks
                                                          September 1999
        

DNS extensions to Network Address Translators (DNS_ALG)

网络地址转换器的DNS扩展(DNS\u ALG)

Status of this Memo

本备忘录的状况

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

本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

Copyright Notice

版权公告

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

版权所有(C)互联网协会(1999年)。版权所有。

Abstract

摘要

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

域名服务(DNS)在路由类(例如:IP)内提供名称到地址的映射。网络地址转换器(NAT)试图在同一路由类别的不同地址域中的主机之间提供透明路由。通常,NAT存在于存根域的边界,对外部地址隐藏私有地址。本文档确定了NAT的DNS扩展需求,并概述了DNS应用程序级网关(DNS_ALG)如何满足需求。DNS_ALG透明地修改有效负载,以在DNS数据包跨越一个地址域进入另一个地址域时改变主机的地址映射。本文件还通过具体示例说明了DNS_ALG的操作。

1. Introduction
1. 介绍

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

网络地址转换器(NAT)通常用于网络的内部IP地址不能在网络外部使用时,无论是出于隐私原因还是因为它们在网络外部使用无效。

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

理想情况下,主机名唯一标识主机,其地址用于定位到主机的路由。然而,主机名和地址通常不能被应用程序区分和互换使用。应用程序将IP地址而不是主机名嵌入到

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

有效载荷。例如,指定其MX服务器地址的电子邮件(例如:user@666.42.7.11)而不是服务器名称(例如:user@private.com)作为发送者ID;在URL等中包含IP地址而不是名称的HTML文件。当数据包通过NAT设备时,使用IP地址代替有效负载中的主机名是一个问题,因为NAT改变网络和传输头以适应地址域,而不是有效负载。

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

DNS提供名称到地址的映射。然而,NAT在私有和外部地址域之间的数据报中执行地址转换(在网络和传输头中)。本文档中概述的DNS应用程序级网关(DNS_ALG)使用NAT上可用的状态信息帮助将DNS有效负载中的名称到私有地址映射转换为名称到外部地址映射,反之亦然。

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

网络地址端口转换器(NAPT)执行地址和传输级别的端口转换(即TCP、UDP端口和ICMP查询ID)。但是,DNS名称映射粒度仅限于IP地址,不扩展到传输级别标识符。因此,NAPT配置的DNS_ALG处理被简化,因为专用网络中的所有主机地址都绑定到单个外部地址。私有主机(来自外部主机)的DNS名称查找不要求新的私有外部地址绑定,因为所有私有主机都绑定到一个预定义的外部地址。但是,NAPT外部地址的反向名称查找不会映射到任何私有主机,而只会映射到NAPT路由器。可以说,支持NAPT配置的DNS_ALG的处理需求只是基本NAT的一个子集。因此,本文档其余部分中的讨论将主要集中在基本NAT、双向NAT和两次NAT配置上,而不涉及NAPT设置。

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].

DNS和相关术语的定义见[Ref 3]和[Ref 4]。NAT相关术语的定义见[参考文献1]。

2. Requirement for DNS extensions
2. DNS扩展的要求

There are many ways to ensure that a host name is mapped to an address relevant within an address realm. In the following sections, we will identify where DNS extensions would be needed.

有许多方法可以确保主机名映射到地址域中相关的地址。在以下部分中,我们将确定需要DNS扩展的位置。

Typically, organizations have two types of authoritative name servers. Internal authoritative name servers identify all (or majority of) corporate resources within the organization. Only a portion of these hosts are allowed to be accessed by the external world. The remaining hosts and their names are unique to the private network. Hosts visible to the external world and the authoritative

通常,组织有两种类型的权威名称服务器。内部权威名称服务器标识组织内的所有(或大部分)公司资源。外部世界只允许访问这些主机的一部分。其余主机及其名称对于专用网络是唯一的。外部世界和权威机构可见的主机

name server that maps their names to network addresses are often configured within a DMZ (De-Militarized Zone) in front of a firewall. We will refer the hosts and name servers within DMZ as DMZ hosts and DMZ name servers respectively. DMZ host names are end-to-end unique in that their FQDNs do not overlap with any end node that communicates with it.

将名称映射到网络地址的名称服务器通常配置在防火墙前面的DMZ(非军事化区域)内。我们将DMZ中的主机和名称服务器分别称为DMZ主机和DMZ名称服务器。DMZ主机名是端到端唯一的,因为它们的FQDN不会与与其通信的任何端节点重叠。

                                   \ | /
                           +-----------------------+
                           |Service Provider Router|
                           +-----------------------+
                            WAN  |
               Stub A .........|\|....
                               |
                     +-----------------+
                     |Stub Router w/NAT|
                     +-----------------+
                         |
                         |   DMZ - Network
   ------------------------------------------------------------
      |         |              |            |             |
     +--+      +--+           +--+         +--+      +----------+
     |__|      |__|           |__|         |__|      | Firewall |
    /____\    /____\         /____\       /____\     +----------+
   DMZ-Host1  DMZ-Host2 ...  DMZ-Name     DMZ-Web       |
                             Server       Server etc.   |
                                                        |
     Internal hosts (Private IP network)                |
   ------------------------------------------------------------
       |             |                 |           |
      +--+         +--+               +--+       +--+
      |__|         |__|               |__|       |__|
     /____\       /____\             /____\     /____\
    Int-Host1    Int-Host2  .....   Int-Hostn   Int-Name Server
        
                                   \ | /
                           +-----------------------+
                           |Service Provider Router|
                           +-----------------------+
                            WAN  |
               Stub A .........|\|....
                               |
                     +-----------------+
                     |Stub Router w/NAT|
                     +-----------------+
                         |
                         |   DMZ - Network
   ------------------------------------------------------------
      |         |              |            |             |
     +--+      +--+           +--+         +--+      +----------+
     |__|      |__|           |__|         |__|      | Firewall |
    /____\    /____\         /____\       /____\     +----------+
   DMZ-Host1  DMZ-Host2 ...  DMZ-Name     DMZ-Web       |
                             Server       Server etc.   |
                                                        |
     Internal hosts (Private IP network)                |
   ------------------------------------------------------------
       |             |                 |           |
      +--+         +--+               +--+       +--+
      |__|         |__|               |__|       |__|
     /____\       /____\             /____\     /____\
    Int-Host1    Int-Host2  .....   Int-Hostn   Int-Name Server
        

Figure 1: DMZ network configuration of a private Network.

图1:专用网络的DMZ网络配置。

Figure 1 above illustrates configuration of a private network which includes a DMZ. Actual configurations may vary. Internal name servers are accessed by users within the private network only. Internal DNS queries and responses do not cross the private network boundary. DMZ name servers and DMZ hosts on the other hand are end-to-end unique and could be accessed by external as well as internal hosts. Throughout this document, our focus will be limited to DMZ hosts and DMZ name servers and will not include internal hosts and internal name servers, unless they happen to be same.

上面的图1说明了包含DMZ的专用网络的配置。实际配置可能会有所不同。内部名称服务器仅由专用网络内的用户访问。内部DNS查询和响应不会跨越专用网络边界。另一方面,DMZ名称服务器和DMZ主机是端到端唯一的,可以由外部主机和内部主机访问。在本文档中,我们的重点将限于DMZ主机和DMZ名称服务器,不包括内部主机和内部名称服务器,除非它们恰好相同。

2.1. DMZ hosts assigned static external addresses on NAT
2.1. DMZ主机在NAT上分配静态外部地址

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

以DMZ主机在NAT设备上分配静态外部地址为例。注意,私有域中的所有主机(包括DMZ主机)都由其私有地址标识。NAT设备上的静态映射允许DMZ主机通过其在外部域中的公共地址进行标识。

2.1.1. Private networks with no DMZ name servers
2.1.1. 没有DMZ名称服务器的专用网络

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

以私有网络本身没有DMZ名称服务器为例。如果专用网络连接到单个服务提供商进行外部连接,则DMZ主机可能会在其转发和in-add.arpa反向区域内,通过其外部地址在服务提供商的权威名称服务器中列出。

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

如果网络连接到多个服务提供商,则可以通过每个服务提供商的权威名称服务器中的外部地址列出DMZ主机名。这在in-addr.arpa反向区域的情况下尤其重要,因为服务提供商可以为专用网络分配不同的地址前缀。

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

在这两种情况下,外部生成的DNS查找将不会到达专用网络。大量基于NAT的私有域采用此选项,将其DMZ主机按其外部地址列在服务提供商的名称服务器上。

2.1.2. Private networks with DMZ name servers
2.1.2. 具有DMZ名称服务器的专用网络

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

以一个私有网络选择在网络本身内为区域保留一个权威的DMZ名称服务器为例。如果网络连接到单个服务提供商,则可以如下配置DMZ名称服务器以避免DNS有效负载截获。DMZ名称服务器中的主机必须映射到其静态分配的外部地址,并且必须将内部名称服务器配置为绕过DMZ名称服务器以查询有关外部主机的信息。此方案确保将DMZ名称服务器设置为仅以独占方式访问外部主机(甚至不访问DMZ主机),因此只能配置外部地址。

The above scheme requires careful administrative planning to ensure that DMZ name servers are not contacted by the private hosts directly or indirectly (through the internal name servers). Using DNS-ALG would obviate the administrative ordeals with this approach.

上述方案需要仔细的管理规划,以确保私有主机不会直接或间接(通过内部名称服务器)联系DMZ名称服务器。使用DNS-ALG可以避免这种方法带来的管理难题。

2.2. DMZ hosts assigned external addresses dynamically on NAT
2.2. DMZ主机在NAT上动态分配外部地址

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

以私有网络中的DMZ主机由NAT动态分配外部地址为例。虽然发给这些主机的地址在专用网络中是固定的,但它们的外部已知地址是短暂的,由NAT确定。在这种情况下,私有组织必须拥有DMZ名称服务器,以便允许通过其名称访问DMZ主机。

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

DMZ名称服务器将配置DMZ主机的专用地址。驻留在NAT设备上的DNS应用程序级网关(DNS_ALG)将拦截指向或来自DMZ名称服务器的DNS数据包,并执行透明的有效负载转换,以便DMZ主机名在每个地址域(即私有或外部)内具有正确的地址映射。

3. Interactions between NAT and DNS_ALG
3. NAT和DNS_ALG之间的交互

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

本文档以互连地址域可能具有重叠地址空间的范例进行操作。但是,互联领域内的主机名称必须是端到端唯一的,以便所有主机都能访问它们。换句话说,在相互通信的终端节点之间,FQDN不能重叠。下图说明了穿过NAT设备(带有DNS_ALG)的DNS数据包如何进行报头和有效负载转换。DNS数据包可以是源端口或目标端口设置为53的TCP或UDP数据包。NAT将转换DNS数据包的IP和TCP/UDP报头,并通知DNS-ALG执行DNS有效负载更改。DNS-ALG将与NAT交互,并根据需要使用NAT状态信息修改有效负载。

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

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

图2:DNS数据包转换路径中的NAT和DNS-ALG

3.1. Address Binding considerations
3.1. 解决绑定问题

We will make a distinction between "Temporary Address Binding" and "Committed Address Binding" in NATs. This distinction becomes necessary because the DNS_ALG will allow external users to create state on NAT, and thus the potential for denial-of-service attacks. Temporary address binding is the phase in which an address binding is reserved without any NAT sessions using the binding. Committed address binding is the phase in which there exists at least one NAT session using the binding between the external and private addresses. Both types of bindings are used by DNS_ALG to modify DNS payloads. NAT uses only the committed address bindings to modify the IP and Transport headers of datagrams pertaining to NAT sessions.

我们将区分NAT中的“临时地址绑定”和“提交地址绑定”。这种区别是必要的,因为DNS_ALG将允许外部用户在NAT上创建状态,从而可能导致拒绝服务攻击。临时地址绑定是在没有使用绑定的任何NAT会话的情况下保留地址绑定的阶段。提交地址绑定是至少存在一个NAT会话的阶段,该会话使用外部地址和专用地址之间的绑定。DNS_ALG使用这两种类型的绑定来修改DNS有效负载。NAT仅使用提交的地址绑定来修改与NAT会话相关的数据报的IP和传输头。

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

对于静态映射地址,上述区别并不相关。对于动态映射的地址,临时地址绑定通常先于提交的绑定。查询DMZ名称服务器进行名称查找时,会发生临时绑定。名称查询很可能是查询发起人和查询主机之间的实际会话的前置游标。只有当NAT看到查询发起方和查询主机之间会话的第一个数据包时,临时绑定才会提交。

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

可以为动态地址分配定义一个可配置参数“绑定保持时间”,作为临时地址绑定保持活动状态而不转换为提交绑定的最长时间段。DNS_ALG每次使用临时绑定(修改DNS有效负载)时,此绑定保持期将被延长。对于大多数DNS-ALG实现,几分钟的默认绑定保持时间可能就足够了。注意,可以使用提交的地址

binding to occur without ever having to be preceded by a temporary binding. Lastly, when NAT is ready to unbind a committed address binding, the binding is transitioned into a temporary binding and kept in that phase for an additional Bind-holdout period. The binding is freed only upon expiry of Bind-holdout time. The Bind-holdout time preceding the committed-address-binding and the address-unbinding are required to ensure that end hosts have sufficient time in which to initiate a data session subsequent to a name lookup.

不必在临时绑定之前进行绑定。最后,当NAT准备解除已提交地址绑定的绑定时,绑定将转换为临时绑定,并在该阶段保持一段额外的绑定保持期。绑定仅在绑定保持时间到期时释放。提交的地址绑定之前的绑定保持时间和地址解除绑定是必需的,以确保最终主机有足够的时间在名称查找之后启动数据会话。

For example, say a private network with address prefix 10/8 is mapped to 198.76.29/24. When an external hosts makes a DNS query to host7, bearing address 10.0.0.7, the DMZ name server within private network responds with an A type RR for host7 as:

例如,假设地址前缀为10/8的专用网络映射到198.76.29/24。当外部主机对地址为10.0.0.7的host7进行DNS查询时,专用网络内的DMZ名称服务器会以host7的a类型RR作为响应:

host7 A 10.0.0.7

host7a10.0.0.7

DNS_ALG would intercept the response packet and if 10.0.0.7 is not assigned an external address already, it would request NAT to create a temporary address binding with an external address and start Bind-holdout timer to age the binding. Say, the assigned external address is 198.76.29.1. DNS-ALG would use this temporary binding to modify the RR in DNS response, replacing 10.0.0.7 with its external address and reply with:

DNS_ALG将截获响应数据包,如果10.0.0.7尚未分配外部地址,它将请求NAT创建一个带有外部地址的临时地址绑定,并启动绑定保持计时器以使绑定老化。例如,分配的外部地址是198.76.29.1。DNS-ALG将使用此临时绑定修改DNS响应中的RR,将10.0.0.7替换为其外部地址,并用以下内容回复:

host7 A 198.76.29.1

7 A旅馆198.76.29.1

When query initiator receives DNS response, only the assigned external address is seen. Within a short period (presumably before the bind-holdout time expires), the query initiator would initiate a session with host7. When NAT notices the start of new session directed to 198.76.29.1, NAT would terminate Bind-holdout timer and transition the temporary binding between 198.76.29.1 and 10.0.0.7 into a committed binding.

当查询发起程序收到DNS响应时,只会看到分配的外部地址。在短时间内(可能在绑定保持时间到期之前),查询启动器将启动与host7的会话。当NAT通知指向198.76.29.1的新会话开始时,NAT将终止绑定保持计时器,并将198.76.29.1和10.0.0.7之间的临时绑定转换为提交的绑定。

To minimize denial of service attacks, where a malicious user keeps attempting name resolutions, without ever initiating a connection, NAT would have to monitor temporary address bindings that have not transitioned into committed bindings. There could be a limit on the number of temporary bindings and attempts to generate additional temporary bindings could be simply rejected. There may be other heuristic solutions to counter this type of malicious attacks.

为了最大限度地减少拒绝服务攻击(恶意用户不断尝试名称解析,却从未启动连接),NAT必须监视尚未转换为提交绑定的临时地址绑定。临时绑定的数量可能有限制,生成额外临时绑定的尝试可能会被拒绝。可能还有其他启发式解决方案来对付这种类型的恶意攻击。

We will consider bi-directional NAT to illustrate the use of temporary binding by DNS_ALG in the following sub-sections, even though the concept is applicable to other flavors of NATs as well.

我们将考虑双向NAT来说明DNSY-ALG在以下子部分中使用临时绑定,即使该概念也适用于其他口味的NAT。

3.2. Incoming queries
3.2. 传入查询

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

为了启动传入会话,外部主机通过发出DNS请求来获取其试图连接到的DMZ主机的V4地址。这一请求构成了潜在新会议开始的前奏。

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

外部主机解析程序通过其DNS服务器查找DMZ主机的名称。当DNS服务器没有将IPv4地址记录附加到此名称时,查找查询将在某个点重定向到专用存根域的主/备份DNS服务器(即,在DMZ中)。

Enroute to DMZ name server, DNS_ALG would intercept the datagram and modify the query as follows.

在前往DMZ名称服务器的途中,DNS_ALG将截获数据报并修改查询,如下所示。

a) For Host name to Host address query requests: Make no change to the DNS payload.

a) 对于主机名到主机地址查询请求:不更改DNS有效负载。

b) For Host address to Host name queries: Replace the external V4 address octets (in reverse order) preceding the string "IN-ADDR.ARPA" with the corresponding private V4 address, if such an address binding exists already. However, if a binding does not exist, the DNS_ALG would simply respond (as a name server would) with a response code (RCODE) of 5 (REFUSED to respond due to policy reasons) and set ANCOUNT, NSCOUNT and ARCOUT to 0 in the header section of the response.

b) 对于主机地址到主机名查询:如果已经存在这样的地址绑定,则将字符串“in-ADDR.ARPA”前面的外部V4地址八位字节(按相反顺序)替换为相应的专用V4地址。但是,如果绑定不存在,DNS_ALG将简单地响应(正如名称服务器所做的那样),响应代码(RCODE)为5(由于策略原因拒绝响应),并在响应的头部分将ANCOUNT、NSCOUNT和ARCOUT设置为0。

In the opposite direction, as DNS response traverses from the DNS server in private network, DNS_ALG would once again intercept the packet and modify as follows.

相反,当DNS响应从专用网络中的DNS服务器穿过时,DNS_ALG将再次截获数据包并进行如下修改。

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

a) 对于主机名到主机地址查询请求,将DMZ名称服务器发送的专用地址替换为NAT路由器内部分配的公共地址。如果以前没有将公共地址分配给主机的专用地址,NAT此时将分配一个。

b) For host address to host name queries, replace the private address octets preceding the string "IN-ADDR.ARPA" in response RRs with their external address assignments. There is a chance here that by the time the DMZ name server replies, the bind-holdout timer in NAT for the address in question has expired. In such a case, DNS_ALG would simply drop the reply. The sender will have to resend the query (as would happen when a router enroute drops the response).

b) 对于主机地址到主机名查询,将响应RRs中字符串“IN-ADDR.ARPA”前面的专用地址八位字节替换为其外部地址分配。在DMZ名称服务器回复时,NAT中有关地址的绑定保持计时器可能已经过期。在这种情况下,DNS_ALG将直接删除回复。发送方将不得不重新发送查询(当路由器中途丢弃响应时会发生这种情况)。

For static address assignments, the TTL value supplied in the original RR will be left unchanged. For dynamic address assignments, DNS_ALG would modify the TTL value on DNS resource records (RRs) to be 0, implying that the RRs should only be used for transaction in progress, and not be cached. For compatibility with broken implementations, TTL of 1 might in practice work better.

对于静态地址分配,原始RR中提供的TTL值将保持不变。对于动态地址分配,DNS_ALG会将DNS资源记录(RRs)上的TTL值修改为0,这意味着RRs应仅用于正在进行的事务,而不是缓存。为了与中断的实现兼容,TTL为1实际上可能工作得更好。

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.

显然,将TTL设置为0将创建比地址为静态时更多的通信量,因为名称到地址的映射不会被缓存。具体而言,基于网络的应用程序需要使用名称而不是地址来标识对等节点,并且必须使用DNS进行每个名称解析,因为名称到地址的映射无法从以前运行的应用程序共享。

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

此外,NAT将被请求在分配之后启动绑定保持计时器。如果在绑定保持时间段内没有启动到私有主机的会话,NAT将终止临时绑定。

3.3. Outgoing Queries
3.3. 传出查询

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

对于基本和双向NAT,不需要区分传出查询的临时绑定和提交绑定。这是因为,与入站DNS会话不同,DNS_ALG不会修改指向或来自外部名称服务器(在出站会话期间使用)的DNS数据包。

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

例如,私有主机需要与外部主机通信。DNS查询转到内部名称服务器(如果存在),然后从那里转到私有域外的相应权威/缓存名称服务器。回复遵循相同的路径,但查询和响应都不受DNS_ALG翻译的影响。

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

然而,地址隔离两次NAT私有域和外部域的情况将不会如此。在这种情况下,NAT将截获所有DNS数据包并对有效负载进行地址修改,如前一节所述。当私有DNS服务器发送响应时,将创建临时私有到外部地址绑定;当外部DNS服务器发送响应时,将创建临时外部到私有地址绑定。

4. DNS payload modifications by DNS-ALG
4. DNS-ALG对DNS有效负载的修改

Typically, UDP is employed as the transport mechanism for DNS queries and responses and TCP for Zone refresh activities. In either case, name servers are accessed using a well-known DNS server port 53 (decimal) and all DNS payloads have the following format of data [Ref

通常,UDP用作DNS查询和响应的传输机制,TCP用作区域刷新活动的传输机制。在任何一种情况下,名称服务器都使用知名的DNS服务器端口53(十进制)进行访问,并且所有DNS有效负载的数据格式如下[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.

4]. NAT负责翻译DNS数据包的IP和TCP/UDP报头,而DNS-ALG负责更新DNS有效负载。

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

DNS有效负载中的标头部分始终存在,并包括指定剩余部分中存在哪些部分的字段。标头标识消息是查询还是响应。DNS-ALG无需对标头部分进行任何更改。DNS_ALG将仅解析QCLASS设置为IN(IP类)的DNS有效负载。

    +---------------------+
    |        Header       |
    +---------------------+
    |       Question      | the question for the name server
    +---------------------+
    |        Answer       | RRs answering the question
    +---------------------+
    |      Authority      | RRs pointing toward an authority
    +---------------------+
    |      Additional     | RRs holding additional information
    +---------------------+
        
    +---------------------+
    |        Header       |
    +---------------------+
    |       Question      | the question for the name server
    +---------------------+
    |        Answer       | RRs answering the question
    +---------------------+
    |      Authority      | RRs pointing toward an authority
    +---------------------+
    |      Additional     | RRs holding additional information
    +---------------------+
        
4.1. Question section
4.1. 问题部分

The question section contains QDCOUNT (usually 1) entries, as specified in Header section, with each of the entries in the following format:

问题部分包含标题部分中指定的QDCOUNT(通常为1)条目,每个条目的格式如下:

                                    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                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        
                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                                               |
    /                     QNAME                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     QTYPE                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     QCLASS                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        
4.1.1. PTR type Queries
4.1.1. PTR类型查询

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

DNS_ALG必须识别其FQDN(即完全限定的域名)属于IN-ADDR.ARPA域的所有名称,并将字符串“IN-ADDR.ARPA”前的地址八位字节(以相反顺序)替换为相应的分配地址八位字节(以相反顺序),前提是地址绑定在NAT路由器上处于活动状态。如果地址是

preceding the string "IN-ADDR.ARPA" falls within the NAT address map, but does not have at least a temporary address binding, DNS_ALG would simply simply respond back (as a DNS name server would) with a response code (RCODE) of 5 (REFUSED to respond due to policy reasons) and set ANCOUNT, NSCOUNT and ARCOUT to 0 in the header section of the response.

字符串“IN-ADDR.ARPA”位于NAT地址映射中,但至少没有临时地址绑定,DNS_ALG将简单地响应(就像DNS名称服务器所做的那样),响应代码(RCODE)为5(由于策略原因拒绝响应),并设置ANCOUNT,在响应的标题部分,NSCOUNT和ARCOUT为0。

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

请注意,上述形式的主机地址到主机名类型查询可能会在不同时间产生不同的结果,具体取决于给定时间NAT中的地址绑定状态。

For example, a resolver that wanted to find out the hostname corresponding to address 198.76.29.1 (externally) would pursue a query of the form:

例如,要查找地址198.76.29.1(外部)对应的主机名的解析程序将执行以下形式的查询:

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 internally mapped to a private address of 10.0.0.1, modify the query as below and forward to DMZ name server within private network.

DNS_ALG将进行干预,如果地址198.76.29.1在内部映射到10.0.0.1的专用地址,请按以下方式修改查询并转发到专用网络内的DMZ名称服务器。

        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 for 10.IN-ADDR.ARPA zone and will respond with an RR of the following form in answer section. DNS_ALG translations of the response RRs will be considered in a following section.

据推测,DMZ名称服务器是10.IN-ADDR.ARPA区域的权威名称服务器,并将在应答部分使用以下形式的RR进行响应。响应RRs的DNS_ALG翻译将在下一节中考虑。

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

1.0.0.10.IN-ADDR.ARPA PTR host1.fooboo\u org.provider\u域

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

反向翻译的一个例子是电子邮件程序,它使用反向翻译跟踪电子邮件源主机以防止垃圾邮件。验证发送电子邮件的地址是否确实属于发件人在发件人ID中声明的相同域名。

Query modifications of this nature will likely change the length of DNS payload. As a result, the corresponding IP and TCP/UDP header checksums must be updated. In case of TCP based queries, the sequence number deltas must be tracked by NAT so that the delta can be applied to subsequent sequence numbers in datagrams in the same direction and acknowledgement numbers in datagrams in the opposite direction. In case of UDP based queries, message sizes are restricted to 512 bytes (not counting the IP or UDP headers). Longer messages must be truncated and the TC bit should be set in the header.

这种性质的查询修改可能会更改DNS有效负载的长度。因此,必须更新相应的IP和TCP/UDP报头校验和。对于基于TCP的查询,序列号增量必须由NAT跟踪,以便增量可以应用于相同方向的数据报中的后续序列号和相反方向的数据报中的确认号。对于基于UDP的查询,消息大小限制为512字节(不包括IP或UDP头)。必须截断较长的消息,并且应在标头中设置TC位。

Lastly, any compressed domain names using pointers to represent common domain denominations must be updated to reflect new pointers with the right offset, if the original domain name had to be translated by NAT.

最后,如果原始域名必须由NAT翻译,则必须更新任何使用指针表示公共域名的压缩域名,以反映具有正确偏移量的新指针。

4.1.2. A, MX, NS and SOA type Queries
4.1.2. A、 MX、NS和SOA类型查询

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

对于这些查询,DNS_ALG不会修改查询部分中的任何字段,甚至不会修改名称字段。

4.1.3. AXFR type Queries
4.1.3. AXFR类型查询

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

AXFR是一种特殊的区域转移类型查询。对于非静态的地址分配,必须避免从专用地址域进行区域传输。通常,TCP用于AXFR请求。

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

对区域进行更改时,必须将更改分发到所有名称服务器。自动区域传输或刷新的一般模型是,其中一个名称服务器是该区域的主服务器或主服务器。通常通过编辑分区的主文件,在主分区协调更改。编辑后,管理员向主服务器发送信号以加载新区域。该区域的其他非主服务器或辅助服务器定期检查该区域的SOA序列字段是否有更改(以一些轮询间隔),并在进行更改时获取新的区域副本。

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

区域传输通常从主服务器传输到备份服务器。在支持NAT的专用网络的情况下,建议主服务器和备份服务器位于同一个专用域(例如private.zone),因此区域传输不会跨域进行,并且区域传输的DNS_ALG支持不是问题。如果辅助名称服务器位于私有域之外,则非静态地址分配不得允许区域传输。主服务器和辅助服务器必须位于同一个私有域中,因为必须捕获对区域中数据的所有引用。使用动态地址分配和绑定,无法将axfr数据转换为最新数据。因此,如果private.zone的辅助服务器位于域外部,它将包含错误数据。但是,请注意,此处概述的要求与RFC 2182不一致,RFC 2182建议将主服务器和辅助服务器放置在Internet上拓扑和地理位置分散的位置。

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

在区域传输期间,DNS_ALG必须检查所有A类型记录,并用静态分配的地址八位字节替换原始地址八位字节。DNS_ALG还可以检查是否有人试图

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

传输未分配静态地址的主机的记录,并单独删除这些记录或删除整个传输。这将最大限度地减少错误配置和人为错误。

4.1.4. Dynamic Updates to the DNS.

4.1.4. DNS的动态更新。

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

权威名称服务器可以从区域内的节点进行动态更新,而无需NAT和DNS-ALG的干预,只要避免将DNS区域分散到地址领域。我们建议将DNS区域保持在其负责的同一领域内。通过这样做,DNS更新流量将不会跨越地址域,因此不会受到DNS-ALG的考虑。

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

此外,如果动态更新确实跨地址域,并且更新必须始终通过DNSSEC进行保护,则此类更新显然超出DNS-ALG的范围(如第7节所述)。

4.2. Resource records in all other sections
4.2. 所有其他章节中的资源记录

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

答案、权限和其他部分都使用相同的格式,资源记录的数量也不尽相同。特定于每个部分的RRs数量可以在DNS报头中的相应计数字段中找到。每个资源记录具有以下格式:

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.

对于静态地址分配,原始RRs中提供的TTL值将保持不变。对于动态地址分配,DNS_ALG将TTL修改为0,因此RRs仅用于正在进行的事务,而不是缓存。RFC 2181要求一个RRs集中的所有RRs(具有相同名称、类和类型,但具有不同RDATA的RRs)具有相同的TTL。因此,如果RR的TTL设置为0,则同一RRs集中的所有其他RRs也将由DNS-ALG调整为0。

      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                                               |
    /                                               /
    /                      NAME                     /
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      TYPE                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     CLASS                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      TTL                      |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                   RDLENGTH                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
    /                     RDATA                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                                               |
    /                                               /
    /                      NAME                     /
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      TYPE                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     CLASS                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      TTL                      |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                   RDLENGTH                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
    /                     RDATA                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        
4.2.1. PTR type RRs
4.2.1. PTR型RRs

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

问题部分中指定的注意事项对PTR类型RRs的名称同样有效。如果存在绑定,则字符串“IN-ADDR.ARPA”(以八位字节的相反顺序)前面的专用地址必须替换为其外部地址分配(以相反顺序)。此RR的其余字段保持不变。

4.2.2. A type RRs
4.2.2. A型RRs

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

记录的RDATA是一个4字节的IP地址。如果DNS_ALG成功地找到了地址绑定,它将简单地用外部分配的IP地址替换RDATA中的原始地址。成功的地址转换不应导致有效负载长度的更改。只有传输头校验和需要更新。如果找不到地址绑定,DNS_ALG将不得不删除该记录并减少头部分中相应的计数字段。

4.2.3. CNAME, MX, NS and SOA type RRs
4.2.3. CNAME、MX、NS和SOA类型RRs

No changes required to be made by DNS_ALG for these RRs, as the RDATA does not contain any IP addresses. The host names within the RDATA remain unchanged between realms.

DNS_ALG无需对这些RRs进行任何更改,因为RDATA不包含任何IP地址。RDATA中的主机名在不同领域之间保持不变。

5. Illustration of DNS_ALG in conjunction with Bi-directional NAT
5. 结合双向NAT的DNS_ALG示意图

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

下图说明了在双向NAT路由器中DNS_ALG的操作。我们将演示如何处理名称查找和反向名称查找查询。

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

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

图3:双向NAT设置中的DNS-ALG操作

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

上图描述了使用专用地址空间172.19/16的公司private.com使用双向NAT连接到Internet的场景。DNS_ALG嵌入NAT设备中,以进行必要的DNS有效负载更改。NAT配置为将专用地址空间转换为

131.108.1/24. NAT is also configured with a static translation for private.com's DNS server, so it can be referred in the external domain by a valid address.

131.108.1/24. NAT还为private.com的DNS服务器配置了静态转换,因此可以通过有效地址在外部域中引用它。

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

公司external.com位于外部域中,使用171.68/16的注册地址块。拓扑中还显示了根DNS服务器。

Following simplifications are made to the above configuration:

对上述配置进行了以下简化:

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

* private.com不是多址的,所有到外部空间的流量都通过一个NAT传输。

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

* private.com的DNS服务器是private.com域的权威服务器,并指向所有其他DNS解析的根服务器。external.com中的DNS服务器也是如此。

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

* private.com和external.com的内部名称服务器与其DMZ名称服务器相同。这些域的DNS服务器配置了组织专用的地址。

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

* 主机节点上的名称解析程序上没有可用的递归,需要服务器提供递归服务。假设所有名称服务器都能够提供递归服务。

5.1. Outgoing Name-lookup queries
5.1. 传出名称查找查询

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

比如说,private.com中的主机A需要在external.com中为主机X执行名称查找,以启动与X的会话。这将按照以下步骤进行。

1. Host A sends a UDP based name lookup query (A record) for "X.External.Com" to its local DNS server.

1. 主机A向其本地DNS服务器发送“X.External.Com”的基于UDP的名称查找查询(记录)。

2. Local DNS server sends the query to the root server enroute NAT. NAT would change the IP and UDP headers to reflect DNS server's statically assigned external address. DNS_ALG will make no changes to the payload.

2. 本地DNS服务器在路由NAT时将查询发送到根服务器。NAT将更改IP和UDP头,以反映DNS服务器静态分配的外部地址。DNS_ALG不会对有效负载进行任何更改。

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

3. 根服务器反过来引用本地DNS服务器来查询DNS服务器的External.com。此引用将NAT传输到本地DNS服务器。NAT将简单地转换传入数据包的IP和UDP报头,以反映DNS服务器的私有地址。DNS\u ALG不对有效负载进行任何更改。

4. Private.com DNS server will now send the query to the DNS server for external.com, once again, enroute NAT. Just as with the query to root, The NAT router would change the IP and UDP headers to reflect the DNS server's statically assigned external address. And, DNS_ALG will make no changes to the payload.

4. Private.com DNS服务器现在将再次在路由NAT过程中将查询发送到external.com的DNS服务器。与对root用户的查询一样,NAT路由器将更改IP和UDP头以反映DNS服务器静态分配的外部地址。而且,DNS_ALG不会对有效负载进行任何更改。

5. The DNS server for external.com replies with the IP address 171.68.10.1. This reply also transits the NAT. NAT would translate the IP and UDP headers of the incoming packet to reflect DNS server's private address. Once again, no changes to the payload by DNS_ALG.

5. external.com的DNS服务器使用IP地址171.68.10.1进行回复。这个回复也会通过NAT。NAT将转换传入数据包的IP和UDP报头以反映DNS服务器的私有地址。同样,DNS_ALG不会对有效负载进行任何更改。

6. The DNS server in Private.com replies to host A.

6. Private.com中的DNS服务器答复主机A。

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

当主机A找到主机X的地址时,A使用目标IP地址171.68.10.1启动与主机X的会话。此数据报和本次会话中后续的任何其他数据报将像往常一样由NAT进行翻译。

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

注意,DNS_ALG不会在任何方向上更改DNS数据包的有效负载。

5.2. Reverse name lookups originated from private domain
5.2. 源自私有域的反向名称查找

This scenario builds on the previous case by having host A in Private.com perform a reverse name lookup on 171.68.10.1, which is host X's global address. Following is a sequence of events.

此场景基于前一种情况,让Private.com中的主机A在171.68.10.1(主机X的全局地址)上执行反向名称查找。以下是一系列事件。

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.

1. 主机A向其本地DNS服务器发送“1.10.68.171.IN-ADDR.ARPA.”的基于UDP的反向名称查找查询(PTR记录)。

2. Local DNS server sends the query to the root server enroute NAT. As before, NAT would change the IP and UDP headers to reflect DNS server's statically assigned external address. DNS_ALG will make no changes to the payload.

2. 本地DNS服务器在路由NAT时将查询发送到根服务器。和以前一样,NAT将更改IP和UDP头以反映DNS服务器静态分配的外部地址。DNS_ALG不会对有效负载进行任何更改。

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

3. 根服务器反过来引用本地DNS服务器来查询DNS服务器的External.com。此引用将NAT传输到本地DNS服务器。NAT将简单地转换传入数据包的IP和UDP报头,以反映DNS服务器的私有地址。DNS\u ALG不对有效负载进行任何更改。

4. Private.com DNS server will now send the query to the DNS server for external.com, once again, enroute NAT. Just as with the query to root, The NAT router would change the IP and UDP headers to reflect the DNS server's statically assigned external address. And, DNS_ALG will make no changes to the payload.

4. Private.com DNS服务器现在将再次在路由NAT过程中将查询发送到external.com的DNS服务器。与对root用户的查询一样,NAT路由器将更改IP和UDP头以反映DNS服务器静态分配的外部地址。而且,DNS_ALG不会对有效负载进行任何更改。

5. The DNS server for external.com replies with the host name of "X.External.Com.". This reply also transits the NAT. NAT would translate the IP and UDP headers of the incoming packet to reflect DNS server's private address. Once again, no changes to the payload by DNS_ALG.

5. external.com的DNS服务器以主机名“X.external.com”进行答复。这个回复也会通过NAT。NAT将转换传入数据包的IP和UDP报头以反映DNS服务器的私有地址。同样,DNS_ALG不会对有效负载进行任何更改。

6. The DNS server in Private.com replies to host A.

6. Private.com中的DNS服务器答复主机A。

Note, DNS_ALG does not change the payload in either direction.

注意,DNS_ALG不会在任何方向上更改有效负载。

5.3. Incoming Name-lookup queries
5.3. 传入名称查找查询

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

这一次,external.com中的主机X希望启动与Private.com中主机a的会话。下面是发生的事件的顺序。

1. Host X sends a UDP based name lookup query (A record) for "A.Private.com" to its local DNS server.

1. 主机X向其本地DNS服务器发送“a.Private.com”的基于UDP的名称查找查询(记录)。

2. Local DNS server in External.com sends the query to root server.

2. External.com中的本地DNS服务器将查询发送到根服务器。

3. The root server, in turn, refers the DNS server in External.com to query the DNS server for private.com,

3. 根服务器反过来引用External.com中的DNS服务器来查询private.com的DNS服务器,

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

4. External.com DNS服务器现在将查询发送到Private.com的DNS服务器。此查询遍历NAT路由器。NAT将更改数据包的IP和UDP报头,以反映DNS服务器的专用地址。DNS_ALG不会对有效负载进行任何更改。

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

5. Private.com的DNS服务器使用主机A的IP地址172.19.1.10进行回复。此回复还传输NAT。NAT将转换来自DNS服务器的传出数据包的IP和UDP报头。

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

DNS_ALG将请求NAT(a)使用外部地址为主机a(172.19.1.10)设置临时绑定,以及(b)启动绑定保持计时器。当NAT成功地与外部地址(例如131.108.1.12)建立临时绑定时,DNS_ALG将修改有效负载,以用外部分配的地址替换a的私有地址,并将缓存超时设置为0。

6. The server in External.com replies to host X

6. External.com中的服务器答复主机X

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

当主机X找到主机A的地址时,X使用目标IP地址131.108.1.12与A发起会话。NAT将一如既往地翻译此数据报和本次会话中后续的任何其他数据报。

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

注意,DNS_ALG仅更改来自专用域DNS服务器的响应数据包。

5.4. Reverse name lookups originated from external domain
5.4. 来自外部域的反向名称查找

This scenario builds on the previous case (section 5.3) by having host X in External.com perform a reverse name lookup on 131.108.1.12, which is host A's assigned external address. The following sequence of events take place.

此场景基于前一种情况(第5.3节),让External.com中的主机X在131.108.1.12上执行反向名称查找,这是主机a分配的外部地址。发生的事件顺序如下。

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.

1. 主机X向其本地DNS服务器发送“12.1.108.131.IN-ADDR.ARPA.”的基于UDP的反向名称查找查询(PTR记录)。

2. Local DNS server in External.com sends the query to the root server.

2. External.com中的本地DNS服务器将查询发送到根服务器。

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

3. 根服务器反过来引用本地DNS服务器来查询Private.com的DNS服务器。

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

4. External.com DNS服务器现在将查询发送到Private.com的DNS服务器。此查询遍历NAT路由器。NAT将更改IP和UDP头以反映DNS服务器的专用地址。

DNS_ALG will enquire NAT for the private address associated with the external address of 131.108.1.12 and modify the payload, replacing 131.108.1.12 with the private address of 172.19.1.10.

DNS_ALG将向NAT查询与131.108.1.12外部地址相关的专用地址,并修改有效负载,将131.108.1.12替换为172.19.1.10的专用地址。

5. The DNS server for Private.com replies with the host name of "A.Private.Com.". This reply also transits the NAT. NAT would translate the IP and UDP headers of the incoming packet to reflect DNS server's private address.

5. Private.com的DNS服务器以主机名“A.Private.com”进行答复。这个回复也会通过NAT。NAT将转换传入数据包的IP和UDP报头以反映DNS服务器的私有地址。

Once again, DNS_ALG will enquire NAT for the assigned external address associated with the private address of 172.19.1.10 and modify the payload, replacing 172.19.1.10 with the assigned external address of 131.108.1.12.

DNS_ALG将再次向NAT查询与172.19.1.10的专用地址相关联的指定外部地址,并修改有效负载,将172.19.1.10替换为131.108.1.12的指定外部地址。

6. The DNS server in External.com replies to host X.

6. External.com中的DNS服务器答复主机X。

Note, DNS_ALG changes the query as well as response packets from DNS server for Private domain.

注意,DNS_ALG更改来自专用域DNS服务器的查询和响应数据包。

6. Illustration of DNS_ALG in conjunction with Twice-NAT
6. 结合两次NAT的DNS_ALG图示

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

下图说明了DNS_ALG在两次NAT路由器中的操作。和前面一样,我们将通过遍历名称查找和反向名称查找查询是如何处理的来说明。

                                             .
                         ________________    .     External.com
                        (                )   .
                       (                  )  .   +-------------+
            +--+      (      Internet      )-.---|Border Router|
            |__|------ (                  )  .   +-------------+
           /____\       (________________)   .          |
            Root                 |           .          |
         DNS Server              |           .     ---------------
                         +---------------+   .       |         |
                         |Provider Router|   .     +--+       +--+
                         +---------------+   .     |__|       |__|
                                 |           .    /____\     /____\
                                 |           .  DNS Server   Host X
       External domain           |           .  171.68.1.1  171.68.10.1
     ............................|...............................
       Private domain            |
                                 |        Private.com
                                 |
                +-------------------------------------------+
                | Twice-NAT router with DNS_ALG             |
                |                                           |
                | Private addresses:  171.68/16             |
                | Assigned External addresses: 131.108.1/24 |
                |                                           |
                | External addresses:  171.68/16            |
                | Assigned Private addresses: 10/8          |
                +-------------------------------------------+
                              |      |
                      ----------    ----------
                        |                  |    DNS Server
                       +--+               +--+  Authoritative
                       |__|               |__|  for private.com
                      /____\             /____\
                      Host A           DNS Server
                   171.68.1.10        171.68.2.1
                                      (Mapped to 131.108.1.8)
        
                                             .
                         ________________    .     External.com
                        (                )   .
                       (                  )  .   +-------------+
            +--+      (      Internet      )-.---|Border Router|
            |__|------ (                  )  .   +-------------+
           /____\       (________________)   .          |
            Root                 |           .          |
         DNS Server              |           .     ---------------
                         +---------------+   .       |         |
                         |Provider Router|   .     +--+       +--+
                         +---------------+   .     |__|       |__|
                                 |           .    /____\     /____\
                                 |           .  DNS Server   Host X
       External domain           |           .  171.68.1.1  171.68.10.1
     ............................|...............................
       Private domain            |
                                 |        Private.com
                                 |
                +-------------------------------------------+
                | Twice-NAT router with DNS_ALG             |
                |                                           |
                | Private addresses:  171.68/16             |
                | Assigned External addresses: 131.108.1/24 |
                |                                           |
                | External addresses:  171.68/16            |
                | Assigned Private addresses: 10/8          |
                +-------------------------------------------+
                              |      |
                      ----------    ----------
                        |                  |    DNS Server
                       +--+               +--+  Authoritative
                       |__|               |__|  for private.com
                      /____\             /____\
                      Host A           DNS Server
                   171.68.1.10        171.68.2.1
                                      (Mapped to 131.108.1.8)
        

Figure 4: DNS-ALG operation in Twice-NAT setup

图4:两次NAT设置中的DNS-ALG操作

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

在这种情况下,private.com中的主机不是从RFC 1918保留的172.19/16空间进行编号,而是使用全局可路由171.68/16网络进行编号,与external.com相同。private.com不仅需要为其自己的主机地址提供翻译服务,而且如果这些主机中的任何一个能够与external.com中的主机交换数据报,它还需要翻译服务。两次NAT通过将external.com中使用的重叠地址空间转换为唯一的

address block (10/8) from RFC 1918 address space. Routes are set up within the private domain to direct datagrams destined for the address block 10/8 through Twice-NAT device to the external global network space.

来自RFC1918地址空间的地址块(10/8)。在私有域内建立路由,以通过两次NAT设备将目的地为地址块10/8的数据报定向到外部全局网络空间。

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

第5.0节中所作的简化和假设在此也将有效。

6.1. Outgoing Name-lookup queries
6.1. 传出名称查找查询

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

例如,private.com中的主机A需要在external.com中对主机X执行名称查找(主机X的FQDN为X.external.com),以查找其地址。这将按如下方式进行。

1. Host A sends a UDP based name lookup query (A record) for "X.External.Com" to its local DNS server.

1. 主机A向其本地DNS服务器发送“X.External.Com”的基于UDP的名称查找查询(记录)。

2. Local DNS server sends the query to the root server enroute NAT. NAT would change the IP and UDP headers to reflect DNS server's statically assigned external address. DNS_ALG will make no changes to the payload.

2. 本地DNS服务器在路由NAT时将查询发送到根服务器。NAT将更改IP和UDP头,以反映DNS服务器静态分配的外部地址。DNS_ALG不会对有效负载进行任何更改。

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

3. 根服务器反过来引用本地DNS服务器来查询DNS服务器的External.com。此引用将NAT传输到本地DNS服务器。NAT将简单地转换传入数据包的IP和UDP报头,以反映DNS服务器的私有地址。

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

DNS_ALG将请求NAT为参考服务器分配专用地址,并将外部地址替换为有效负载中分配的专用地址。

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

4. Private.com DNS服务器现在将使用其分配的专用地址,通过NAT向external.com的DNS服务器发送查询。这一次,NAT将更改IP和UDP头以反映DNS服务器的外部地址。即,Private.com DNS服务器的IP地址更改为其分配的外部地址,而external.com DNS服务器的分配的私有地址更改为其外部地址。

DNS_ALG will make no changes to the payload.

DNS_ALG不会对有效负载进行任何更改。

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

5. external.com的DNS服务器使用IP地址171.68.10.1进行回复。这个回复也会通过NAT。NAT将再次转换传入服务器的IP和UDP报头,以反映DNS服务器的私有地址。即Private.com DNS

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

服务器的IP地址更改为其专用地址,External.Com DNS服务器的外部地址更改为其分配的专用地址。

DNS_ALG will request NAT to (a) set up a temporary binding for Host X (171.68.10.1) with a private address and (b) initiate Bind-holdout timer. When NAT successfully sets up temporary binding with a private address (say, 10.0.0.254), DNS_ALG would modify the payload to replace X's external address with its assigned private address and set the Cache timeout to 0.

DNS_ALG将请求NAT(a)使用专用地址为主机X(171.68.10.1)设置临时绑定,以及(b)启动绑定保持计时器。当NAT成功地使用专用地址(例如10.0.0.254)设置临时绑定时,DNS_ALG将修改有效负载,以用其分配的专用地址替换X的外部地址,并将缓存超时设置为0。

6. The DNS server in Private.com replies to host A.

6. Private.com中的DNS服务器答复主机A。

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

当主机A找到主机X的地址时,A使用目标IP地址10.0.0.254启动与主机X的会话。此数据报和本次会话中后续的任何其他数据报将像往常一样通过两次NAT进行翻译。

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

注意,DNS_ALG必须在两个方向上更改有效负载。

6.2. Reverse name lookups originated from private domain
6.2. 源自私有域的反向名称查找

This scenario builds on the previous case by having host A in Private.com perform a reverse name lookup on 10.0.0.254, which is host X's assigned private address. Following is a sequence of events.

此场景基于前一种情况,让Private.com中的主机A在10.0.0.254上执行反向名称查找,这是主机X分配的专用地址。以下是一系列事件。

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.

1. 主机A向其本地DNS服务器发送“254.0.0.10.IN-ADDR.ARPA.”的基于UDP的反向名称查找查询(PTR记录)。

2. Local DNS server sends the query to the root server enroute NAT. As before, NAT would change the IP and UDP headers to reflect DNS server's statically assigned external address.

2. 本地DNS服务器在路由NAT时将查询发送到根服务器。和以前一样,NAT将更改IP和UDP头以反映DNS服务器静态分配的外部地址。

DNS_ALG will translate the private assigned address 10.0.0.254 with its external address 171.68.10.1.

DNS_ALG将专用分配地址10.0.0.254与其外部地址171.68.10.1进行转换。

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

3. 根服务器反过来引用本地DNS服务器来查询DNS服务器的External.com。此引用将NAT传输到本地DNS服务器。NAT将简单地转换传入数据包的IP和UDP报头,以反映DNS服务器的私有地址。

As with the original query, DNS_ALG will translate the private assigned address 10.0.0.254 with its external address 171.68.10.1. In addition, DNS_ALG will replace the external address of the referal server (i.e., the DNS server for External.com) with its assigned private address in the payload.

与原始查询一样,DNS_ALG将私有分配地址10.0.0.254与其外部地址171.68.10.1进行转换。此外,DNS_ALG将用有效负载中分配的私有地址替换referal服务器(即,external.com的DNS服务器)的外部地址。

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

4. Private.com DNS服务器现在将使用其静态分配的私有地址,通过NAT向external.com的DNS服务器发送查询。这一次,NAT将更改IP和UDP头以反映DNS服务器的外部地址。即,Private.com DNS服务器的IP地址更改为其分配的外部地址,而external.com DNS服务器的分配的私有地址更改为其外部地址。

As with the original query, DNS_ALG will translate the private assigned address 10.0.0.254 with its external address 171.68.10.1.

与原始查询一样,DNS_ALG将私有分配地址10.0.0.254与其外部地址171.68.10.1进行转换。

5. The DNS server for external.com replies with the FQDN of "X.External.Com.". This reply also transits the NAT. NAT would once again translate the IP and UDP headers of the incoming to reflect the private addresses of the DNS servers. I.e., Private.com DNS server's IP address is changed to its private address and External.Com DNS server's external address is changed to its assigned Private address.

5. external.com的DNS服务器以“X.external.com.”的FQDN进行答复。这个回复也会通过NAT。NAT将再次转换传入服务器的IP和UDP报头,以反映DNS服务器的私有地址。即,Private.com DNS服务器的IP地址更改为其专用地址,而External.com DNS服务器的外部地址更改为其分配的专用地址。

Once again, DNS_ALG will translate the query section, replacing the external address 171.68.10.1 with its assigned private address of 10.0.0.254

DNS_ALG将再次转换查询部分,将外部地址171.68.10.1替换为其分配的专用地址10.0.0.254

6. The DNS server in Private.com replies to host A.

6. Private.com中的DNS服务器答复主机A。

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

注意,DNS_ALG必须在两个方向上更改有效负载。

6.3. Incoming Name-lookup queries
6.3. 传入名称查找查询

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

这一次,external.com中的主机X希望启动与Private.com中主机a的会话。下面是发生的事件的顺序。

1. Host X sends a UDP based name lookup query (A record) for "A.Private.com" to its local DNS server.

1. 主机X向其本地DNS服务器发送“a.Private.com”的基于UDP的名称查找查询(记录)。

2. Local DNS server in External.com sends the query to root server.

2. External.com中的本地DNS服务器将查询发送到根服务器。

3. The root server, in turn, refers the DNS server in External.com to query the DNS server for private.com,

3. 根服务器反过来引用External.com中的DNS服务器来查询private.com的DNS服务器,

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

4. External.com DNS服务器现在将查询发送到Private.com的DNS服务器。此查询遍历NAT路由器。NAT将更改IP和UDP头以反映DNS服务器的私有地址。即,Private.com DNS服务器的IP地址更改为其专用地址,而External.com DNS服务器的外部地址更改为分配的专用地址。

DNS_ALG will make no changes to the payload.

DNS_ALG不会对有效负载进行任何更改。

5. The DNS server for Private.com replies with the IP address 171.68.1.10 for host A. This reply also transits the NAT. NAT would once again translate the IP and UDP headers of the incoming to reflect the external addresses of the DNS servers. I.e., Private.com DNS server's IP address is changed to its assigned external address and External.Com DNS server's assigned private address is changed to its external address.

5. Private.com的DNS服务器使用主机A的IP地址171.68.1.10进行回复。此回复还传输NAT。NAT将再次转换传入服务器的IP和UDP头,以反映DNS服务器的外部地址。即,Private.com DNS服务器的IP地址更改为其分配的外部地址,而external.com DNS服务器的分配的私有地址更改为其外部地址。

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

DNS_ALG将请求NAT(a)使用外部地址为主机a(171.68.1.10)设置临时绑定,以及(b)启动绑定保持计时器。当NAT成功找到要临时绑定到主机A的外部地址(例如131.108.1.12)时,DNS_ALG将修改有效负载,用外部分配的地址替换A的私有地址,并将缓存超时设置为0。

6. The server in External.com replies to host X

6. External.com中的服务器答复主机X

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

当主机X找到主机A的地址时,X使用目标IP地址131.108.1.12与A发起会话。NAT将一如既往地翻译此数据报和本次会话中后续的任何其他数据报。

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

注意,DNS_ALG仅更改来自专用域DNS服务器的响应数据包。

6.4. Reverse name lookups originated from external domain
6.4. 来自外部域的反向名称查找

This scenario builds on the previous case (section 6.3) by having host X in External.com perform a reverse name lookup on 131.108.1.12, which is host A's assigned external address. The following sequence of events take place.

此场景基于前一种情况(第6.3节),让External.com中的主机X在131.108.1.12上执行反向名称查找,这是主机a分配的外部地址。发生的事件顺序如下。

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.

1. 主机X向其本地DNS服务器发送“12.1.108.131.IN-ADDR.ARPA.”的基于UDP的反向名称查找查询(PTR记录)。

2. Local DNS server in External.com sends the query to the root server.

2. External.com中的本地DNS服务器将查询发送到根服务器。

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

3. 根服务器反过来引用本地DNS服务器来查询Private.com的DNS服务器。

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

4. External.com DNS服务器现在将查询发送到Private.com的DNS服务器。此查询遍历NAT路由器。NAT将更改IP和UDP头以反映DNS服务器的私有地址。即,Private.com DNS服务器的IP地址更改为其专用地址,而External.com DNS服务器的外部地址更改为分配的专用地址。

DNS_ALG will enquire NAT for the private address associated with the external address of 131.108.1.12 and modify the payload, replacing 131.108.1.12 with the private address of 171.68.1.10.

DNS_ALG将向NAT查询与131.108.1.12外部地址相关联的专用地址,并修改有效负载,将131.108.1.12替换为171.68.1.10的专用地址。

5. The DNS server for Private.com replies with the host name of "A.Private.Com.". This reply also transits the NAT. NAT would once again translate the IP and UDP headers of the incoming to reflect the external addresses of the DNS servers. I.e., Private.com DNS server's IP address is changed to its assigned external address and External.Com DNS server's assigned private address is changed to its external address.

5. Private.com的DNS服务器以主机名“A.Private.com”进行答复。这个回复也会通过NAT。NAT将再次转换传入服务器的IP和UDP头,以反映DNS服务器的外部地址。即,Private.com DNS服务器的IP地址更改为其分配的外部地址,而external.com DNS服务器的分配的私有地址更改为其外部地址。

Once again, DNS_ALG will enquire NAT for the assigned external address associated with the private address of 172.19.1.10 and modify the payload, replacing 171.68.1.10 with the assigned external address of 131.108.1.12.

DNS_ALG将再次向NAT查询与172.19.1.10的专用地址关联的分配外部地址,并修改有效负载,将171.68.1.10替换为131.108.1.12的分配外部地址。

6. The DNS server in External.com replies to host X.

6. External.com中的DNS服务器答复主机X。

Note, DNS_ALG changes the query as well as response packets from DNS server for Private domain.

注意,DNS_ALG更改来自专用域DNS服务器的查询和响应数据包。

7. DNS-ALG limitations and Future Work
7. DNS-ALG的局限性和未来的工作

NAT increases the probability of mis-addressing. For example, same local address may be bound to different public address at different times and vice versa. As a result, hosts that cache the name to address mapping for longer periods than the NAT router is configured to hold the map are likely to misaddress their sessions. Note, this is mainly an issue with bad host implementations that hold DNS records longer than the TTL in them allows and is not directly attributable to the mechanism described here.

NAT增加了误寻址的可能性。例如,相同的本地地址可能在不同的时间绑定到不同的公共地址,反之亦然。因此,缓存名称到地址映射的时间比NAT路由器配置为保存映射的时间长的主机很可能会对其会话进行错误寻址。注意,这主要是错误主机实现的一个问题,这些主机实现保存DNS记录的时间比其中的TTL允许的时间长,并且不能直接归因于此处描述的机制。

DNS_ALG cannot support secure DNS name servers in the private domain. I.e., Signed replies from an authoritative DNS name server in the DMZ to queries originating from the external world will be broken by the DNS-ALG. At best, DNS-ALG would be able to transform secure dnssec data into unprotected data. End-node demanding DNS replies to be signed may reject replies that have been tampered with by DNS_ALG. Since, the DNS server does not have a way to find where the queries come from (i.e., internal or external), it will most likely have to

DNS_ALG无法支持私有域中的安全DNS名称服务器。即,来自DMZ中权威DNS名称服务器对来自外部世界的查询的签名回复将被DNS-ALG破坏。DNS-ALG最多只能将安全的dnssec数据转换为不受保护的数据。要求签署DNS回复的终端节点可能会拒绝已被DNS_ALG篡改的回复。由于DNS服务器无法找到查询的来源(即内部或外部),因此它很可能不得不这样做

resort to the common denomination of today's insecure DNS. Both are serious limitations to DNS_ALG. Zone transfers between DNS-SEC servers is also impacted the same way, if the transfer crosses address realms.

求助于当今不安全DNS的共同名称。这两个都是对DNS\u ALG的严重限制。如果传输跨越地址域,DNS-SEC服务器之间的区域传输也会受到相同的影响。

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

然而,好消息是,只有DMZ中的终端节点为传统NAT(或双向NAT)中的上述限制付出了代价,因为外部终端节点可能无法访问内部主机,因为DNS应答不安全。但是,对于双向NAT设置中的传出会话(来自专用网络),DNS查询可以由DMZ和其他内部主机签名并安全接受,因为DNS_ALG不会拦截传出DNS查询和传入回复。最后,同一专用网络内DNS-SEC服务器之间的区域传输不受影响。

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

显然,在DNS服务器和终端主机解析程序中部署DNS SEC时,本文档中建议的方案将不起作用。

8. Security Considerations
8. 安全考虑

If DNS packets are encrypted/authenticated per DNSSEC, then DNS_ALG will fail because it won't be able to perform payload modifications. Alternately, if packets must be preserved in an address realm, DNS_ALG will need to hold the secret key to decrypt/verify payload before forwarding packets to a different realm. For example, if DNS-ALG, NAT and IPsec gateway (providing secure tunneling service) are resident on the same device, DNS-ALG will have access to the IPsec security association keys. The preceding section, "DNS-ALG limitations and Future Work" has coverage on DNS_ALG security considerations.

如果根据DNSSEC对DNS数据包进行加密/身份验证,则DNS\u ALG将失败,因为它将无法执行有效负载修改。或者,如果数据包必须保留在地址域中,则DNS_ALG将需要持有密钥以在将数据包转发到其他域之前解密/验证有效负载。例如,如果DNS-ALG、NAT和IPsec网关(提供安全隧道服务)驻留在同一设备上,则DNS-ALG将可以访问IPsec安全关联密钥。前一节“DNS-ALG限制和未来工作”涵盖了DNS_ALG安全注意事项。

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.

此外,如第3.1节所述,使用DNS-ALG,恶意用户可能会发起拒绝服务攻击。第3.1节提出了一些对付这种攻击的方法。

REFERENCES

参考资料

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

[1] Srisuresh,P.和M.Holdrege,“IP网络地址转换器(NAT)术语和注意事项”,RFC 2663,1999年8月。

[2] Egevang, K. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994.

[2] Egevang,K.和P.Francis,“IP网络地址转换器(NAT)”,RFC16311994年5月。

[3] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

[3] Rekhter,Y.,Moskowitz,B.,Karrenberg,D.,de Groot,G.和E.Lear,“私人互联网地址分配”,BCP 5,RFC 1918,1996年2月。

[4] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.

[4] Mockapetris,P.,“域名-概念和设施”,STD 13,RFC 1034,1987年11月。

[5] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.

[5] Mockapetris,P.,“域名-实现和规范”,STD 13,RFC 10351987年11月。

[6] Reynolds J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.

[6] Reynolds J.和J.Postel,“分配的数字”,标准2,RFC 1700,1994年10月。

[7] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.

[7] Braden,R.,“互联网主机的要求——通信层”,STD 3,RFC 1122,1989年10月。

[8] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.

[8] Braden,R.,“互联网主机的要求——应用和支持”,STD 3,RFC 1123,1989年10月。

[9] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.

[9] Baker,F.,“IP版本4路由器的要求”,RFC 1812,1995年6月。

[10] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.

[10] Carpenter,B.,Crowcroft,J.和Y.Rekhter,“今天的IPv4地址行为”,RFC21011997年2月。

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

[11] Eastlake,D.,“域名系统安全扩展”,RFC 25351999年3月。

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

[12] Vixie,P.,Thompson,S.,Rekhter Y.和J.Bound,“域名系统中的动态更新(DNS更新)”,RFC 21361997年4月。

[13] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997.

[13] Eastlake,D.,“安全域名系统动态更新”,RFC 2137,1997年4月。

[14] Elz R. and R. Bush, "Clarifications to the DNS specification", RFC 2181, July 1997.

[14] Elz R.和R.Bush,“DNS规范的澄清”,RFC 21811997年7月。

[15] Elz, R., R. Bush, Bradner S. and M. Patton, "Selection and Operation of Secondary DNS Servers", RFC 2182, July 1997.

[15] Elz,R.,R.Bush,Bradner S.和M.Patton,“二级DNS服务器的选择和操作”,RFC 2182,1997年7月。

Authors' Addresses

作者地址

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

美国加利福尼亚州米尔皮塔斯伊利环城皮达斯利苏雷什849号,邮编95035。

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

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

George Tsirtsis互联网传输集团B29室英国电信实验室Martlesham Heath IPSWICH Suffolk IP5 3RE英格兰

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

Praveen Akkiraju cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA

Praveen Akkiraju cisco Systems 170西塔斯曼大道圣何塞,加利福尼亚州95134

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

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

Andy Heffernan Juniper Networks,Inc.位于拉文斯代尔大道385号。美国加利福尼亚州山景城94043

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

Full Copyright Statement

完整版权声明

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

版权所有(C)互联网协会(1999年)。版权所有。

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

本文件及其译本可复制并提供给他人,对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发,不受任何限制,前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是,不得以任何方式修改本文件本身,例如删除版权通知或对互联网协会或其他互联网组织的引用,除非出于制定互联网标准的需要,在这种情况下,必须遵循互联网标准过程中定义的版权程序,或根据需要将其翻译成英语以外的其他语言。

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

上述授予的有限许可是永久性的,互联网协会或其继承人或受让人不会撤销。

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

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Acknowledgement

确认

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

RFC编辑功能的资金目前由互联网协会提供。