Network Working Group P. Srisuresh
Request for Comments: 2694 Consultant
Category: Informational G. Tsirtsis
BT Laboratories
P. Akkiraju
Cisco Systems
A. Heffernan
Juniper Networks
September 1999
DNS extensions to Network Address Translators (DNS_ALG)
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（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の動作を示します。
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.
ネットワークの内部IPアドレスは、プライバシー上の理由や、それらがネットワーク外での使用のために無効であるため、いずれかのネットワーク外で使用することができないときネットワークアドレス変換器（NAT）がしばしば使用されています。
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 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.
理想的に言えば、ホスト名は、一意のホストを識別し、そのアドレスは、ホストへのルートを見つけるために使用されます。ただし、ホスト名とアドレスが頻繁に区別し、アプリケーションによっては交換可能に使用されていません。アプリケーションは、ペイロードにIPアドレスの代わりにホスト名を埋め込みます。代わりにサーバ名（例：user@private.com）の：例としては、彼らのMXサーバーアドレス（user@666.42.7.11 EX）を指定した電子メールになります送信者IDとして; IPアドレスの代わりに、URLの中に名前が含まれたHTMLファイルなどのペイロード内のホスト名の代わりにIPアドレスを使用すると、パケットがNATのアドレスレルムに合わせて、ネットワークおよびトランスポートヘッダを変更するため、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の単なるサブセットです。従って、文書の残りの部分での議論は、NAPTの設定は特に参照して、基本的なNAT、双方向NAT二回NAT構成に主に焦点を当てます。
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および関連する用語の定義は、に見出すことができる[参考文献3]及び[参考文献4]。 NATに関連する用語の定義は、[参考文献1]に見出すことができます。
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.
一般的に、組織は、権威ネームサーバの2種類があります。内部権威ネームサーバは、組織内のすべての（または多数の）企業のリソースを識別します。これらのホストの一部のみが外部の世界にアクセスすることが許可されています。残りのホストとその名前がプライベートネットワークに固有のものです。外部世界とのネットワーク・アドレスに自分の名前をマップする権威ネームサーバに見えるホストは、多くの場合、ファイアウォールの前に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
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ネームサーバに限定され、彼らは同じことが起こる場合を除き、内部ホストおよび内部ネームサーバーは含まれません。
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ホストが外部ドメインで自分のパブリックアドレスで識別することができます。
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ホストを持っている場合に、このオプションを追求しています。
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を使用すると、このアプローチの行政試練を取り除くでしょう。
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ホスト名は、各アドレスレルム（すなわち、内右のアドレスマッピングを持つように透明ペイロード変換を実行します）プライベートまたは外部。
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の重複が存在することはできません。 （DNS_ALG付き）NATデバイスをトラバースするDNSパケットはヘッダとペイロード変換の対象である方法を以下の図に示します。 DNSパケットは、DNSペイロードの変更を実行するためにIPとDNSパケットのTCP / UDPヘッダを翻訳し、DNS-ALGを通知します53. NATに設定し、ソースまたは宛先ポートとTCPやUDPのパケットであることができます。 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
Figure 2: NAT & DNS-ALG in the translation path of DNS packets
図2：DNSパケットの翻訳・パスでNAT＆DNS-ALG
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に状態を作成することができ、したがって、サービス妨害（DoS）攻撃の可能性になるので、この区別が必要になります。バインディング一時アドレスは、アドレスバインディングがバインディングを使用して、任意のNATのセッションなしに予約されている段階です。結合コミットアドレスが外部アドレスとプライベートアドレス間の結合を使用して、少なくとも1つのNATセッションが存在している段階です。バインディングのどちらのタイプには、DNSのペイロードを修正するためにDNS_ALGによって使用されています。 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 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.
設定可能なパラメータは、「バインド・ホールドアウト時間」は、結合一時アドレスがコミット結合へ移行することなく、アクティブ保持されている時間の最大期間として動的アドレスの割り当てのために定義されてもよいです。 DNS_ALGによる一時的な結合をそれぞれ使用して（DNSのペイロードを修正するために）、このバインド・ホールドアウト期間が更新されます。数分のデフォルトのバインド・ホールドアウトの時間は、ほとんどのDNS-ALG実装には十分かもしれません。それが今までの一時的な結合によって先行されることなく、発生する結合コミットアドレス可能である、注意してください。 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のタイプRRで応答します。
host7 A 10.0.0.7
host7 10.0.0.7
DNS_ALG would intercept the response packet and if 10.0.0.7 is not assigned an external address already, it would request NAT to create a temporary address binding with an external address and start Bind-holdout timer to age the binding. Say, the assigned external address is 198.76.29.1. DNS-ALG would use this temporary binding to modify the RR in DNS response, replacing 10.0.0.7 with its external address and reply with:
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
host7 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の他のフレーバーに適用されるにもかかわらず、以下のサブセクションでDNS_ALGによって一時的な結合の使用を説明するために双方向NATを検討します。
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アドレスの記録を持っていない場合は、検索クエリは、プライベートスタブドメインの（つまり、DMZ内）プライマリ/バックアップDNSサーバにある時点でリダイレクトされます。
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）は、ホストアドレスの名前クエリをホストする：結合ようなアドレスが既に存在する場合、対応する秘密V4アドレスに文字列「IN-ADDR.ARPA」の前）は、逆の順序で（外部V4アドレスオクテットを交換します。結合が存在しない場合は、DNS_ALGは単に（これは、ポリシー上の理由に応答することを拒否した）5の応答コード（RCODE）と（だろうネームサーバのような）応答と0にANCOUNT、NSCOUNTとARCOUTを設定しますレスポンスのヘッダ部。
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）のアドレスクエリ要求をホストするホスト名には、内部NATルータによって割り当てられたパブリックアドレスとDMZネームサーバによって送信されたプライベートアドレスを交換してください。パブリックアドレスが以前にホストのプライベートアドレスに割り当てられていない場合、NATは、この時点では1を割り当てます。
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）のホストアドレスの場合は、名前のクエリをホストする彼らの外部アドレスの割り当てとレスポンスのRR内の文字列「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はのRRのみ進行中のトランザクションのために使用すべきである、とキャッシュされないことを意味し、0にDNSリソースレコード（RR）にTTL値を変更します。より良い練習の仕事で壊れた実装で、1つのかもしれないのTTLとの互換性のために。
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.
明らかに、0にTTLを設定すると、名前とアドレスのマッピングがキャッシュされていないのでアドレスは、静的であればより多くのトラフィックを作成します。具体的には、ネットワークベースのアプリケーションは、ピア・ノードを識別するための名前ではなくアドレスを使用するために必要とされ、以前に実行するアプリケーションから共有することができない名前からアドレスへのマッピングとして、すべての名前解決のために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は、一時的な結合を終了させます。
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.
Basicおよび双方向NATのために、送信クエリのための一時的なコミットバインディングを区別する必要はありません。 DNS_ALGは、インバウンドDNSセッションとは異なり、または（アウトバウンドセッション中に使用される）外部のネームサーバから送ら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クエリは、内部のネームサーバ（1が存在する場合）に、そこからプライベートドメイン外の適切な権威/キャッシュネームサーバに送られます。返事は同じルートをたどるが、クエリでも応答でもないが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サーバによって送信されたときにプライベートアドレスバインディングを一時的に外部が作成されたときに、外部アドレスバインディングへの一時的なプライベートが作成されます。
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（10進数）と、すべてのDNSペイロードを使用してアクセスされるデータ[参考文献以下のフォーマットを有します
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
+---------------------+
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 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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 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.
DNS_ALGは、そのFQDNで（つまり、完全修飾ドメイン名）IN-ADDR.ARPAドメイン内に収まると（逆の順序で）アドレスオクテットを置き換える文字列「IN-ADDR.ARPA」の前に対応する割り当てられたアドレスのオクテットを持つすべての名前を特定しなければなりません逆の順序で、結合アドレスがNATルータ上でアクティブになっている場合にのみ。文字列「IN-ADDR.ARPA」の前のアドレスがNATアドレスマップ内にあるが、結合、少なくとも一時的なアドレスを持っていない場合は、DNS_ALGは単に単に（応答コード付き（DNSネームサーバと同じように）戻って応答することになります5のRCODE）が（これは、ポリシー上の理由に応答することを拒否した）とレスポンスのヘッダセクションに0にANCOUNT、NSCOUNTとARCOUTを設定します。
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 =に、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 =に、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で応答します。応答RRのDNS_ALG翻訳は、次のセクションで考慮されます。
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によって翻訳されなければならなかった場合、オフセットは右で新しいポインタを反映するために更新する必要があります。
For these queries, DNS_ALG would not modify any of the fields in the query section, not even the name field.
これらのクエリのために、DNS_ALGはないとしても名フィールド、クエリのセクションでの任意のフィールドを変更しません。
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のSERIALフィールドをチェックし、変更が行われたときに、新しいゾーンのコピーを入手します。
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、とconfirmenceではありません。
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 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.
ゾーン転送中に、DNS_ALGは、すべてのタイプのレコードを調べなければなりませんし、その静的に割り当てられたアドレスのオクテットで元のアドレスのオクテットを交換してください。静的アドレスを割り当てられていないホストのレコードを転送し、一人でそれらのレコードを落としたり、全体の転送をドロップしようとする試みがある場合DNS_ALGも調べることができます。これは設定ミスや人的ミスを最小限に抑えます。
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.
権威ネームサーバはとても長いものがアドレスレルム全体のDNSゾーンを広げる回避として、NATとDNS-ALGからの介入なしに、ゾーン内のノードからの動的更新を持つことができます。我々は、それは責任がある同じレルム内の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を介して固定しなければならない場合、さらに、そのような更新は、（セクション7で説明したように）DNS-ALGの範囲外にあることは明らかです。
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:
答えは、権限、および追加セクションはすべて、リソースレコードの可変数で、同じフォーマットを共有しています。セクションの各々に特異的なRRの数は、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.
オリジナルのRRに供給されたTTL値は、静的なアドレス割り当てのままであろう。動的アドレスの割り当てについては、DNS_ALGはTTLが0に変更されますので、RRがキャッシュされただけで、進行中のトランザクションのために使用され、されていません。 RFC 2181は、同じTTLを持つようにRRセット（同じ名前、クラスとタイプとが、異なるRDATAとのRR）内のすべてのRRを必要とします。 RRのTTLが0に設定されているのであれば、同一の資源レコード集合内の他のすべてのRRはまた0であることがDNS-ALGによって調整されます。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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タイプのRRの名前と同様に有効です。結合が存在する場合（オクテットの逆の順序で）文字列「IN-ADDR.ARPA」の前のプライベートアドレスは、（逆の順序で）その外部アドレス割り当てによって置き換えられなければなりません。このRRのための残りのフィールドは変更されません。
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は、レコードを削除し、ヘッダ部に対応するカウントフィールドをデクリメントしなければなりません。
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.
RDATAは、任意のIPアドレスが含まれていないとして、これらのRRのためDNS_ALGによって行われるために必要なの変更はありません。 RDATA内のホスト名は、レルム間で変わりません。
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)
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を使用してインターネットに接続するシナリオを描いています。 DNS_ALGは、必要なDNSペイロードの変更を行うためにNATデバイスに組み込まれています。 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サーバは、他のすべてのDNS解決のためのルートサーバへprivate.comドメインとポイントの権威です。同じことが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.
*ホストノード上のネームリゾルバは、それらの上に利用できる再帰を持っているし、サーバからの再帰的なサービスを望んでいません。すべてのネームサーバは再帰的なサービスを提供することができると想定されています。
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は、次のようにこれが進行するX.とのセッションを開始することexternal.comでホスト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は、DNSサーバーの静的に割り当てられた外部アドレスを反映するためにIPとUDPヘッダーを変更します。 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.ルートサーバは、順番に、External.comためのDNSサーバーを照会するローカルDNSサーバーを参照します。このreferalは、ローカルのDNSサーバにNAT途中を通過します。 NATは、単にDNSサーバのプライベートアドレスを反映するために、着信パケットのIPとUDPヘッダーを翻訳します。 DNS_ALGによってペイロードへの変更はありません。
4. Private.com DNS server will now send the query to the DNS server for external.com, once again, enroute NAT. Just as with the query to root, The NAT router would change the IP and UDP headers to reflect the DNS server's statically assigned external address. And, DNS_ALG will make no changes to the payload.
4. Private.comのDNSサーバーは、今、再び、external.comのためのDNSサーバへの途中でNATをクエリを送信します。ただ、ルートへのクエリと同様に、NATルータは、DNSサーバーの静的に割り当てられた外部アドレスを反映するためにIPとUDPヘッダーを変更します。そして、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は、DNSサーバのプライベートアドレスを反映するために、着信パケットのIPとUDPヘッダーを翻訳します。もう一度、DNS_ALGによってペイロードに変更なし。
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は、171.68.10.1の送信先IPアドレスを使用して、ホストXとのセッションを開始します。このセッションで続くこのデータグラムと他のものは、NATによっていつものように変換されます。
Note, DNS_ALG does not change the payload for DNS packets in either direction.
注意、DNS_ALGは、いずれかの方向にDNSパケットのペイロードを変更しません。
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がホストXのグローバルアドレスである171.68.10.1上の名前の逆引き参照を実行することによって、以前のケースに基づいています。以下は、一連のイベントです。
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は、のためにUDPベースの逆名前検索クエリ（PTRレコード）を送信し、「1.10.68.171.IN-ADDR.ARPA。」そのローカルDNSサーバへ。
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は、DNSサーバーの静的に割り当てられた外部アドレスを反映するためにIPとUDPヘッダーを変更します。 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.ルートサーバは、順番に、External.comためのDNSサーバーを照会するローカルDNSサーバーを参照します。このreferalは、ローカルのDNSサーバにNAT途中を通過します。 NATは、単にDNSサーバのプライベートアドレスを反映するために、着信パケットのIPとUDPヘッダーを翻訳します。 DNS_ALGによってペイロードへの変更はありません。
4. Private.com DNS server will now send the query to the DNS server for external.com, once again, enroute NAT. Just as with the query to root, The NAT router would change the IP and UDP headers to reflect the DNS server's statically assigned external address. And, DNS_ALG will make no changes to the payload.
4. Private.comのDNSサーバーは、今、再び、external.comのためのDNSサーバへの途中でNATをクエリを送信します。ただ、ルートへのクエリと同様に、NATルータは、DNSサーバーの静的に割り当てられた外部アドレスを反映するためにIPとUDPヘッダーを変更します。そして、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は、DNSサーバのプライベートアドレスを反映するために、着信パケットのIPとUDPヘッダーを翻訳します。もう一度、DNS_ALGによってペイロードに変更なし。
Note, DNS_ALG does not change the payload in either direction.
注意、DNS_ALGは、いずれかの方向にペイロードを変更しません。
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ベースの名前検索クエリ（レコード）を送信します。
3. The root server, in turn, refers the DNS server in External.com to query the DNS server for private.com,
3.ルートサーバは、順番に、private.comのためのDNSサーバーを照会するExternal.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は、DNSサーバのプライベートアドレスを反映するために、パケットのIPおよびUDPヘッダを変更します。 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は、外部アドレスとホストA（172.19.1.10）のための一時的結合（a）の設定にNATを要求し、（b）はバインド・ホールドアウトタイマーを開始します。 NATが正常に外部アドレス（たとえば、131.108.1.12）との一時的な結合を設定すると、DNS_ALGは、その外部に割り当てられたアドレスとAのプライベートアドレスを交換し、0にキャッシュのタイムアウトを設定するペイロードを変更します。
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は131.108.1.12の送信先IPアドレスを使用して、Aとのセッションを開始します。このセッションで続くこのデータグラムと他のものは、NATによっていつものように変換されます。
Note, DNS_ALG changes only the response packets from the DNS server for Private domain.
DNS_ALGは、プライベートドメインのDNSサーバからのみ応答パケットを変更し、注意してください。
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.
このシナリオでは、ホストAの割り当てられた外部アドレス131.108.1.12、の逆名前ルックアップを実行External.comのホストXを有することによって、前の場合（セクション5.3）に基づいています。以下の一連のイベントが行われます。
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は、のためにUDPベースの逆名前検索クエリ（PTRレコード）を送信し、「12.1.108.131.IN-ADDR.ARPA。」そのローカルDNSサーバへ。
2. Local DNS server in External.com sends the query to the root server.
External.com 2.ローカルDNSサーバーは、ルートサーバーにクエリを送信します。
3. The root server, in turn, refers the local DNS server to query the DNS server for Private.com.
3.ルートサーバは、順番に、Private.comためのDNSサーバーを照会するローカル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は、DNSサーバのプライベートアドレスを反映するためにIPとUDPヘッダーを変更します。
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は172.19.1.10のプライベートアドレスを131.108.1.12を置き換える、131.108.1.12の外部アドレスに関連付けられたプライベートアドレスにNATを尋ねるとペイロードを変更します。
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は、DNSサーバのプライベートアドレスを反映するために、着信パケットのIPとUDPヘッダーを翻訳します。
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は172.19.1.10のプライベートアドレスに関連付けられた割り当てられた外部アドレスに対してNATを尋ねるとペイロードを変更し、131.108.1.12の割り当てられた外部アドレスを172.19.1.10を交換します。
Note, DNS_ALG changes the query as well as response packets from DNS server for Private domain.
DNS_ALGは、プライベートドメインのDNSサーバからのクエリだけでなく、応答パケットを変更し、注意してください。
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.
次の図は、二度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
|
+-------------------------------------------+
| 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 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.
このシナリオでは、private.com内のホストは、RFC 1918から番号を付けていなかった172.19 / 16スペースを予約し、むしろexternal.comと同様、グローバルにルーティング可能な171.68 / 16のネットワークに番号を付けました。 private.com自身のホストアドレスのための翻訳サービスが必要ですが、それらのホストのいずれかがexternal.comでホストとデータグラムを交換することができるようになっている場合、それはまた、翻訳サービスを必要とするだけでなく。トワイスNATは、RFC 1918のアドレス空間から一意のアドレスブロック（10/8）でexternal.comで使用される重複アドレス空間を変換することにより遷移を収容します。ルートは、外部のグローバルネットワーク空間にトワイスNATデバイスを介してアドレス・ブロック10/8宛のダイレクトデータグラムにプライベートドメイン内に設置されています。
Simplifications and assumptions made in section 5.0 will be valid here as well.
セクション5.0で行われた簡略化および仮定は、ここにも有効となります。
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はそのアドレスを見つけるために、（ホストXがX.external.comのFQDNを持っている）external.comでホスト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は、DNSサーバーの静的に割り当てられた外部アドレスを反映するためにIPとUDPヘッダーを変更します。 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.ルートサーバは、順番に、External.comためのDNSサーバーを照会するローカルDNSサーバーを参照します。このreferalは、ローカルのDNSサーバにNAT途中を通過します。 NATは、単にDNSサーバのプライベートアドレスを反映するために、着信パケットのIPとUDPヘッダーを翻訳します。
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は、DNSサーバの外部アドレスを反映するためにIPとUDPヘッダーを変更します。すなわち、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 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サーバは、IPアドレス171.68.10.1で応答します。この応答はまた、NATを通過します。 NATは再びDNSサーバのプライベートアドレスを反映するために、着信のIPおよびUDPヘッダを翻訳します。すなわち、Private.comのDNSサーバーの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は、（A）にNATを要求するプライベートアドレスとホストX（171.68.10.1）の結合の一時を設定し、（b）はバインド・ホールドアウトタイマーを開始します。 NATが正常にプライベートアドレス（たとえば、10.0.0.254）との結合を一時的に設定した場合、DNS_ALGは、その割り当てられたプライベートアドレスとXの外部アドレスを交換し、0にキャッシュのタイムアウトを設定するペイロードを変更します。
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は10.0.0.254の宛先IPアドレスを使用して、ホストXとのセッションを開始します。このセッションで続くこのデータグラムと他のものは二度NATによっていつものように変換されます。
Note, the DNS_ALG has had to change payload in both directions.
DNS_ALGは両方向にペイロードを変更しなければならなかった、注意してください。
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がホストXに割り当てられたプライベートアドレスである10.0.0.254の名前の逆引き参照を実行することによって、以前のケースに基づいています。以下は、一連のイベントです。
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は、のためにUDPベースの逆名前検索クエリ（PTRレコード）を送信し、「254.0.0.10.IN-ADDR.ARPA。」そのローカルDNSサーバへ。
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は、DNSサーバーの静的に割り当てられた外部アドレスを反映するためにIPとUDPヘッダーを変更します。
DNS_ALG will translate the private assigned address 10.0.0.254 with its external address 171.68.10.1.
DNS_ALGは、その外部アドレス171.68.10.1とプライベート割り当てられたアドレス10.0.0.254を変換します。
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.ルートサーバは、順番に、External.comためのDNSサーバーを照会するローカルDNSサーバーを参照します。このreferalは、ローカルのDNSサーバにNAT途中を通過します。 NATは、単にDNSサーバのプライベートアドレスを反映するために、着信パケットのIPとUDPヘッダーを翻訳します。
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は、その外部アドレス171.68.10.1とプライベート割り当てられたアドレス10.0.0.254を変換します。また、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は、DNSサーバの外部アドレスを反映するためにIPとUDPヘッダーを変更します。すなわち、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は、その外部アドレス171.68.10.1とプライベート割り当てられたアドレス10.0.0.254を変換します。
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サーバはFQDNで応答「X.External.Com。」。この応答はまた、NATを通過します。 NATは再びDNSサーバのプライベートアドレスを反映するために、着信のIPおよびUDPヘッダを翻訳します。すなわち、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は10.0.0.254のその割り当てられたプライベートアドレスと外部アドレス171.68.10.1を置き換え、クエリ部分を翻訳します
Note, the DNS_ALG has had to change payload in both directions.
DNS_ALGは両方向にペイロードを変更しなければならなかった、注意してください。
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ベースの名前検索クエリ（レコード）を送信します。
3. The root server, in turn, refers the DNS server in External.com to query the DNS server for private.com,
3.ルートサーバは、順番に、private.comのためのDNSサーバーを照会するExternal.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は、DNSサーバのプライベートアドレスを反映するためにIPとUDPヘッダーを変更します。すなわち、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は再びDNSサーバの外部アドレスを反映するために、着信のIPおよびUDPヘッダを翻訳します。すなわち、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は、（A）にNATを要求する外部アドレスとホストA（171.68.1.10）の結合の一時を設定し、（b）はバインド・ホールドアウトタイマーを開始します。 NATは、一時的にAをホストするためにバインドするために、外部アドレス（たとえば、131.108.1.12）を見つけることに成功した場合、DNS_ALGは、その外部に割り当てられたアドレスとAのプライベートアドレスを交換し、0にキャッシュのタイムアウトを設定するペイロードを変更します。
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は131.108.1.12の送信先IPアドレスを使用して、Aとのセッションを開始します。このセッションで続くこのデータグラムと他のものは、NATによっていつものように変換されます。
Note, DNS_ALG changes only the response packets from the DNS server for Private domain.
DNS_ALGは、プライベートドメインのDNSサーバからのみ応答パケットを変更し、注意してください。
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.
このシナリオでは、ホストAの割り当てられた外部アドレス131.108.1.12、の逆名前ルックアップを実行External.comのホストXを有することによって、前の場合（6.3節）に基づいています。以下の一連のイベントが行われます。
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は、のためにUDPベースの逆名前検索クエリ（PTRレコード）を送信し、「12.1.108.131.IN-ADDR.ARPA。」そのローカルDNSサーバへ。
2. Local DNS server in External.com sends the query to the root server.
External.com 2.ローカルDNSサーバーは、ルートサーバーにクエリを送信します。
3. The root server, in turn, refers the local DNS server to query the DNS server for Private.com.
3.ルートサーバは、順番に、Private.comためのDNSサーバーを照会するローカル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は、DNSサーバのプライベートアドレスを反映するためにIPとUDPヘッダーを変更します。すなわち、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は171.68.1.10のプライベートアドレスを131.108.1.12を置き換える、131.108.1.12の外部アドレスに関連付けられたプライベートアドレスにNATを尋ねるとペイロードを変更します。
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は再びDNSサーバの外部アドレスを反映するために、着信のIPおよびUDPヘッダを翻訳します。すなわち、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は172.19.1.10のプライベートアドレスに関連付けられた割り当てられた外部アドレスに対してNATを尋ねるとペイロードを変更し、131.108.1.12の割り当てられた外部アドレスを171.68.1.10を交換します。
Note, DNS_ALG changes the query as well as response packets from DNS server for Private domain.
DNS_ALGは、プライベートドメインのDNSサーバからのクエリだけでなく、応答パケットを変更し、注意してください。
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ルータがマップを保持するように構成されているよりも長い期間アドレスマッピングに名前をキャッシュするホストは、そのセッションをmisaddressする可能性があります。これは主に彼らが可能となり、ここで説明したメカニズムに直接起因しないでTTLよりも長いDNSレコードを保持する悪いホストの実装に問題がある、注意してください。
DNS_ALG cannot support secure DNS name servers in the private domain. I.e., Signed replies from an authoritative DNS name server in the DMZ to queries originating from the external world will be broken by the DNS-ALG. At best, DNS-ALG would be able to transform secure dnssec data into unprotected data. End-node demanding DNS replies to be signed may reject replies that have been tampered with by DNS_ALG. Since, the DNS server does not have a way to find where the queries come from (i.e., internal or external), it will most likely have to resort to the common denomination of today's insecure DNS. Both are serious limitations to DNS_ALG. Zone transfers between DNS-SEC servers is also impacted the same way, if the transfer crosses address realms.
DNS_ALGはプライベートドメインでセキュアなDNSネームサーバーをサポートすることはできません。すなわち、外部の世界から発信クエリにDMZの権威DNSネームサーバからの署名付きの返信がDNS-ALGによって破壊されます。最高の状態で、DNS-ALGは保護されていないデータへの安全なDNSSECデータを変換することができるだろう。 DNS要求の厳しいエンド・ノードは、DNS_ALGによって改ざんされている応答を拒否することができる署名する返信。 DNSサーバーは、クエリが（すなわち、内部または外部の）どこから来た見つけるための方法を持っていない、ので、それはおそらく、今日の不安定なDNSの共通宗派に頼る必要があります。どちらも、DNS_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クエリは署名することができ、DNS_ALG発信DNSクエリーと着信応答をインターセプトしないので安全DMZおよび他の内部ホストによって受け入れられます。最後に、同じプライベートネットワーク内の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の展開で、この文書で提案方式では動作しません。
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.
DNSパケットがDNSSECごとに認証/暗号化されている場合は、ペイロードの変更を実行することができなくなりますので、その後、DNS_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
REFERENCES
[1] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[2] Egevang, K. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994.
[2] Egevang、K.およびP.フランシス、 "IPネットワークアドレス変換（NAT）"、RFC 1631、1994年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.、モスコウィッツ、B.、Karrenberg、D.、デ・グルート、G.、およびE.リア、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 1035、1987年11月。
[6] Reynolds J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[6]レイノルズJ.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月。
[7] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[7]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[8] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[8]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[9] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[9]ベイカー、F.、 "IPバージョン4つのルータのための要件"、RFC 1812、1995年6月。
[10] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[10]カーペンター、B.、クロウクロフト、J.およびY. Rekhter、 "IPv4アドレス動作今日"、RFC 2101、1997年2月。
[11] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[11]イーストレイク、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年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.、トンプソン、S.、Rekhter Y.及びJ.、 "ドメインネームシステムにおける動的更新（DNS更新）"、RFC 2136、1997年4月。
[13] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997.
[13]イーストレイク、D.は、RFC 2137、1997年4月、 "ドメインネームシステム動的な更新を固定します"。
[14] Elz R. and R. Bush, "Clarifications to the DNS specification", RFC 2181, July 1997.
[14]エルツR.とR.ブッシュ大統領、 "DNS仕様の明確化"、RFC 2181、1997年7月。
[15] Elz, R., R. Bush, Bradner S. and M. Patton, "Selection and Operation of Secondary DNS Servers", RFC 2182, July 1997.
[15]エルツ、R.、R.ブッシュ、ブラドナーのS.とM.パットン、 "セカンダリDNSサーバーの選択と運用"、RFC 2182、1997年7月。
Authors' Addresses
著者のアドレス
Pyda Srisuresh 849 Erie Circle Milpitas, CA 95035 U.S.A.
Pyda Srisuresh 849エリーサークルミルピタス、CA 95035 U.S.A.
Phone: +1 (408) 263-7527 EMail: srisuresh@yahoo.com
電話：+1（408）263-7527 Eメール：srisuresh@yahoo.com
George Tsirtsis Internet Transport Group B29 Room 129 BT Laboratories Martlesham Heath IPSWICH Suffolk IP5 3RE England
ジョージTsirtsisインターネット交通グループB29ルーム129 BT研究所MartleshamヒースイプスウィッチIP5 3REイングランド
Phone: +44 1473 640756 Fax: +44 1473 640709 EMail: george@gideon.bt.co.uk
電話：+44 1473 640756ファックス：+44 1473 640709 Eメール：george@gideon.bt.co.uk
Praveen Akkiraju cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
プラビーン・アッキーラジューシスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134 USA
Phone: +1 (408) 526-5066 EMail: spa@cisco.com
電話：+1（408）526-5066 Eメール：spa@cisco.com
Andy Heffernan Juniper Networks, Inc. 385 Ravensdale Drive. Mountain View, CA 94043 USA
アンディHeffernanのジュニパーネットワークス株式会社385 Ravensdaleドライブ。マウンテンビュー、CA 94043 USA
Phone: +1 (650) 526-8037 Fax: +1 (650) 526-8001 EMail: ahh@juniper.net
電話：+1（650）526-8037ファックス：+1（650）526-8001 Eメール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。