[要約] RFC 2694は、ネットワークアドレストランスレータ（NAT）に対するDNS拡張（DNS_ALG）に関するものです。このRFCの目的は、NAT環境でのDNS通信の問題を解決するための仕様を提供することです。
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_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.
Copyright（c）The Internet Society（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はスタブドメインの境界に存在し、外部アドレスからプライベートアドレスを隠します。このドキュメントは、DNS拡張がNATSに必要であることを識別し、DNSアプリケーションレベルゲートウェイ（DNS_ALG）がニーズをどのように満たすことができるかを概説します。DNS_ALGはペイロードを透過的に変更して、DNSパケットが1つのアドレス領域を別のアドレスに横断するため、ホストのアドレスマッピングを変更します。ドキュメントは、特定の例を備えた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.
ネットワークアドレス翻訳者（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 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アドレスを埋め込みました。例は、サーバー名（ex：user@private.com）の代わりに、MXサーバーアドレス（ex：user@6666.42.7.11）を指定する電子メールです。URLの名前の代わりにIPアドレスを含む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）は、DNSペイロードの名前からプリベート - アドレスマッピングを名前から表記へのアドレスマッピングに変換し、NATで利用可能な状態情報を使用して逆に翻訳するのに役立ちます。
A Network Address Port Translator (NAPT) performs address and Transport level port translations (i.e, TCP, UDP ports and ICMP query IDs). DNS name mapping granularity, however, is limited to IP addresses and does not extend to transport level identifiers. As a result, the DNS_ALG processing for an NAPT configuration is simplified in that all host addresses in private network are bound to a single external address. The DNS name lookup for private hosts (from external hosts) do not mandate fresh private-external address binding, as all private hosts are bound to a single pre-defined external address. However, reverse name lookups for the NAPT external address will not map to any of the private hosts and will simply map to the NAPT router. Suffices to say, the processing requirements for a DNS_ALG supporting NAPT configuration are a mere subset of Basic NAT. Hence, the discussion in the remainder of the document will focus mainly on Basic NAT, Bi-directional NAT and Twice NAT configurations, with no specific reference to NAPT setup.
ネットワークアドレスポート翻訳者（NAPT）は、アドレスおよびトランスポートレベルのポート翻訳（つまり、TCP、UDPポート、ICMPクエリID）を実行します。ただし、DNS名のマッピングの粒度はIPアドレスに限定されており、輸送レベルの識別子には拡張されていません。その結果、NAPT構成のDNS_ALG処理は、プライベートネットワーク内のすべてのホストアドレスが単一の外部アドレスにバインドされているという点で簡素化されます。プライベートホストのDNS名の検索（外部ホストから）は、すべてのプライベートホストが単一の事前定義された外部アドレスにバインドされるため、新鮮なプライベートエクスナルアドレスバインディングを義務付けません。ただし、NAPT外部アドレスのリバースネームルックアップは、プライベートホストのいずれにもマッピングされず、NAPTルーターにマッピングするだけです。言うだけで十分です、DNS_ALGサポートNAPT構成の処理要件は、基本NATの単なるサブセットです。したがって、ドキュメントの残りの部分での議論は、主に基本的なNAT、双方向NAT、および2回の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関連の用語の定義は[Ref 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 Name Serverがない場合を使用してください。プライベートネットワークが外部接続のために単一のサービスプロバイダーに接続されている場合、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 Name Serverは、次のようにDNSペイロードインターセプトを除去するように構成されている場合があります。DMZ Name Serverのホストは、静的に割り当てられた外部アドレスにマッピングする必要があり、内部名サーバーは、外部ホストに関するクエリ用にDMZ Name Serverをバイパスするように構成する必要があります。このスキームにより、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 Name Serverを使用して、名前で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.
このドキュメントは、アドレスの領域を相互接続することで、アドレス空間が重複している可能性があるというパラダイムで動作します。しかし、相互接続された領域内のホストの名前は、すべてのホストがアクセスできるように、エンドツーエンドのユニークでなければなりません。言い換えれば、互いに通信するエンドノード間にFQDNSの重複はありません。次の図は、DNSパケットがNATデバイスを通過する（DNS_ALGを使用）どのようにヘッダーとペイロードの翻訳の対象となるかを示しています。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
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で状態を作成できるため、サービス拒否攻撃の可能性があるため、この区別が必要になります。一時的な住所バインディングは、バインディングを使用したNATセッションなしでアドレスバインディングが予約される位相です。コミットされたアドレスバインディングは、外部アドレスとプライベートアドレスの間のバインディングを使用して、少なくとも1つの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 Name Serverが名前のルックアップのためにクエリされているときに発生します。名前のクエリは、クエリオリジターとクエリのホストの間の実際のセッションの事前装飾品である可能性があります。一時的な拘束力は、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にマッピングされたとします。外部ホストがhost7にDNSクエリを作成すると、アドレス10.0.0.7を担います。プライベートネットワーク内のDMZ名サーバーは、host7のA型RRで応答します。
host7 A 10.0.0.7
host7 A 10.0.0.7
DNS_ALG would intercept the response packet and if 10.0.0.7 is not assigned an external address already, it would request NAT to create a temporary address binding with an external address and start Bind-holdout timer to age the binding. Say, the assigned external address is 198.76.29.1. DNS-ALG would use this temporary binding to modify the RR in DNS response, replacing 10.0.0.7 with its external address and reply with:
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 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を検討して、概念が他のNATのフレーバーにも適用できるにもかかわらず、次のサブセクションでのDNS_ALGによる一時的な結合の使用を説明します。
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-HOSTの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 Name Serverに到達すると、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は、5の応答コード（RCODE）を使用して（ポリシーの理由により応答を拒否）、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 Name Serverが送信したプライベートアドレスを、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) ホストアドレスをホストする名前のクエリの場合、文字列「in-addr.arpa」の前にあるプライベートアドレスオクテットを、RRSの外部アドレスの割り当てに置き換えます。ここでは、DMZ Name Serverが返信するまでに、問題のアドレスの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は進行中のトランザクションにのみ使用され、キャッシュされないことを意味します。壊れた実装との互換性のために、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.
明らかに、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は一時的な拘束力を終了します。
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_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クエリは、内部名サーバー（存在する場合）に移動し、そこからプライベートドメインの外側の適切な権威ある/キャッシュ名サーバーに送られます。返信は同じルートに従いますが、クエリも応答も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.
ただし、これは、2回のNATプライベートドメインと外部ドメインを2回分離したアドレスの場合は当てはまりません。このような場合、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 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.
通常、UDPは、DNSクエリと応答の輸送メカニズム、およびゾーンリフレッシュアクティビティのためのTCPとして採用されています。どちらの場合でも、有名なDNSサーバーポート53（小数）を使用して名前サーバーにアクセスされ、すべてのDNSペイロードには次のデータ形式があります[Ref 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が（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（つまり、完全に適格なドメイン名）がADDR.ARPAドメイン内に収まり、文字列「In-Addr.Arpa」の前に対応する割り当てられたアドレスオクテットを担当するアドレスオクテット（逆の順序で）を置き換える必要があります。逆の順序で、アドレスバインディングがNATルーターでアクティブである場合にのみ。文字列「In-Addr.Arpa」の前のアドレスがNATアドレスマップ内に収まるが、少なくとも一時的なアドレスバインディングがない場合、DNS_ALGは単に（DNSネームサーバーと同じ）応答コード（5のRcode）（政策上の理由により応答することを拒否）、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
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 Name Serverは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_org.provider_domain
An example of Inverse translation is e-mail programs using inverse translation to trace e-mail originating hosts for spam prevention. Verify if the address from which the e-mail was sent does indeed belong to the same domain name the sender claims in sender ID.
逆翻訳の例は、逆翻訳を使用して、スパム予防のための電子メール発信ホストをトレースする電子メールプログラムです。電子メールが送信されたアドレスが実際に同じドメイン名に属しているかどうかを確認します。
Query modifications of this nature will likely change the length of DNS payload. As a result, the corresponding IP and TCP/UDP header checksums must be updated. In case of TCP based queries, the sequence number deltas must be tracked by NAT so that the delta can be applied to subsequent sequence numbers in datagrams in the same direction and acknowledgement numbers in datagrams in the opposite direction. In case of UDP based queries, message sizes are restricted to 512 bytes (not counting the IP or UDP headers). Longer messages must be truncated and the TC bit should be set in the header.
この性質のクエリ変更により、DNSペイロードの長さが変更される可能性があります。その結果、対応するIPおよびTCP/UDPヘッダーチェックサムを更新する必要があります。TCPベースのクエリの場合、デルタを同じ方向のデータグラムの後続のシーケンス番号に適用し、データグラムの概念番号に反対方向の概念番号にシーケンス番号を追跡する必要があります。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は、Queryセクションのフィールドのいずれも変更せず、名前フィールドでさえも変更されません。
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.
ゾーンに変更が加えられた場合、それらはすべての名前サーバーに配布する必要があります。自動ゾーン転送またはリフレッシュの一般的なモデルは、名前サーバーの1つがゾーンのマスターまたはプライマリであることです。通常、ゾーンのマスターファイルを編集することにより、変化はプライマリで調整されます。編集後、管理者はマスターサーバーを信号して新しいゾーンを読み込みます。ゾーンの他の非マスターまたはセカンダリサーバーは、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の確認ではありません。これは、インターネット上のトポロジおよび地理的に分散した場所にプライマリおよびセカンダリサーバーを配置することを推奨しています。
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は、静的アドレスが割り当てられていないホストのレコードを転送し、それらのレコードを単独でドロップするか、転送全体をドロップする試みがあるかどうかを調べることもできます。これにより、誤解と人的誤りが最小限に抑えられます。
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-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で説明されています）。
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.
元のRRSで提供されるTTL値は、静的アドレスの割り当てのために変更されません。動的アドレスの割り当ての場合、DNS_ALGはTTLを0に変更するため、RRSは、キャッシュされていない進行中のトランザクションにのみ使用されます。RFC 2181では、同じTTLを持つためにRRSet（同じ名前、クラス、タイプ、しかし異なるRDATAのRRS）のすべてのRRSが必要です。したがって、RRのTTLが0に設定されている場合、同じRRST内の他のすべての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 /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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の残りのフィールドは変更されていません。
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は、RDATAの元のアドレスを、アドレスバインディングを見つけることに成功した場合、外部に割り当てられたIPアドレスに置き換えるだけです。アドレスの変換が成功するには、ペイロードの長さに変更を加えないはずです。トランスポートヘッダーチェックサムのみが更新する必要があります。アドレスバインディングを見つけられなかった場合、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アドレスが含まれていないため、これらのRRSについて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 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.
上記の図は、プライベートアドレススペース172.19/16を使用した会社Private.comが、Bi-Directional Natを使用してインターネットに接続するシナリオを示しています。DNS_ALGは、必要なDNSペイロードの変更を行うためにNATデバイスに埋め込まれています。NATは、プライベートアドレススペースを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.
同社の外部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.
* ホストノードの名前のリゾルバーには、それらで利用可能な再帰があり、サーバーからの再帰サービスを希望しています。すべての名前サーバーは、再帰サービスを提供できると想定されています。
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.
host a in private.comは、Xとのセッションを開始するために、futister.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は、「X.External.com」のUDPベースの名前Lookupクエリ（レコード）をローカルDNSサーバーに送信します。
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. ルートサーバーは、ローカルDNSサーバーを参照して、DNSサーバーをexternal.comを照会します。この参照は、NATをローカルDNSサーバーに通過します。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サーバーは、returnal.comのためにDNSサーバーにクエリを送信するようになりました。ルートするクエリと同様に、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は、DNSサーバーのプライベートアドレスを反映するように、着信パケットのIPおよびUDPヘッダーを翻訳します。繰り返しますが、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のアドレスを見つけると、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は、「1.10.68.171.in-Addr.arpa」のUDPベースの逆名ルックアップクエリ（PTRレコード）を送信します。ローカル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は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は、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サーバーは、returnal.comのためにDNSサーバーにクエリを送信するようになりました。ルートするクエリと同様に、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は、DNSサーバーのプライベートアドレスを反映するように、着信パケットのIPおよびUDPヘッダーを翻訳します。繰り返しますが、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はどちらの方向にもペイロードを変更しません。
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.
今回は、HOST Xのexternal.comは、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は、「a.private.com」のUDPベースの名前Lookupクエリ（レコード）をローカルDNSサーバーに送信します。
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. ルートサーバーは、fortence.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は、発信パケットのIPおよびUDPヘッダーをDNSサーバーから翻訳します。
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）外部アドレスを使用して、ホストA（172.19.1.10）の一時的なバインディングを（a）セットアップし、（b）バインドホールドアウトタイマーを開始するようにNATを要求します。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は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.
このシナリオは、Host XがHost Aに割り当てられた外部アドレスである131.108.1.12に逆名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は、「12.1.108.131.in-addr.arpa」のUDPベースの逆名ルックアップクエリ（PTRレコード）を送信します。ローカルDNSサーバーへ。
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は、131.108.1.12の外部アドレスに関連付けられたプライベートアドレスについてNATに問い合わせ、ペイロードを変更し、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は、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に問い合わせ、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サーバーからの応答パケットと同様にクエリを変更します。
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.
次の図は、2回の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：2倍のセットアップでの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スペースから番号が付けられていませんでしたが、むしろ外部comと同じグローバルにルート可能な171.68/16ネットワークで番号が付けられました。private.comは、独自のホストアドレスの翻訳サービスを必要とするだけでなく、それらのホストが外部com.comのホストとデータグラムを交換できる場合、翻訳サービスも必要です。2回NATは、RFC 1918アドレススペースの一意のアドレスブロック（10/8）を使用して、外部comで使用されるオーバーラップアドレススペースを翻訳することにより、遷移に対応します。ルートはプライベートドメイン内にセットアップされ、アドレスブロック10/8から2倍のナットデバイスに向けて外部のグローバルネットワークスペースに向けて誘導されます。
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は、そのアドレスを見つけるには、firate.com（Host XにはX.External.comのFQDNがあります）のホストXの名前を検索する必要があります。これは次のように進行します。
1. Host A sends a UDP based name lookup query (A record) for "X.External.Com" to its local DNS server.
1. ホストAは、「X.External.com」のUDPベースの名前Lookupクエリ（レコード）をローカルDNSサーバーに送信します。
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. ルートサーバーは、ローカルDNSサーバーを参照して、DNSサーバーをexternal.comを照会します。この参照は、NATをローカルDNSサーバーに通過します。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はIPおよびUDPヘッダーを変更して、DNSサーバーの外部アドレスを反映します。つまり、private.com DNSサーバーのIPアドレスが割り当てられた外部アドレスに変更され、外部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アドレスがprivateアドレスに変更され、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）プライベートアドレスを使用して、（a）ホストX（171.68.10.1）の一時的なバインディングを設定するようにNATを要求し、（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のアドレスを見つけると、10.0.0.254の宛先IPアドレスを使用して、ホストXとのセッションを開始します。このデータグラムとこのセッションで続く他のデータグラムは、通常どおりNATを2回翻訳します。
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に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は、「254.0.0.10.in-addr.arpa」のUDPベースの逆名ルックアップクエリ（PTRレコード）を送信します。ローカル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は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は、外部アドレス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. ルートサーバーは、ローカルDNSサーバーを参照して、DNSサーバーをexternal.comを照会します。この参照は、NATをローカルDNSサーバーに通過します。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はIPおよびUDPヘッダーを変更して、DNSサーバーの外部アドレスを反映します。つまり、private.com DNSサーバーのIPアドレスが割り当てられた外部アドレスに変更され、外部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サーバーは、「x.external.com」のfqdnで返信します。この返信もNATを通過します。NATは、DNSサーバーのプライベートアドレスを反映するために、着信のIPおよびUDPヘッダーを再度翻訳します。つまり、private.com DNSサーバーのIPアドレスがprivateアドレスに変更され、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は両方方向にペイロードを変更する必要がありました。
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.
今回は、HOST Xのexternal.comは、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は、「a.private.com」のUDPベースの名前Lookupクエリ（レコード）をローカルDNSサーバーに送信します。
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. ルートサーバーは、fortence.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は、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）外部アドレスを使用して（a）ホストA（171.68.1.10）の一時的なバインディングを設定し、（b）バインドホールドアウトタイマーを開始するようにNATを要求します。NATが外部アドレス（たとえば、131.108.1.12）を見つけることに成功して一時的にバインドしてA aにバインドすると、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は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.
このシナリオは、Host XがHost Aに割り当てられた外部アドレスである131.108.1.12で逆名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は、「12.1.108.131.in-addr.arpa」のUDPベースの逆名ルックアップクエリ（PTRレコード）を送信します。ローカルDNSサーバーへ。
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は、131.108.1.12の外部アドレスに関連付けられているプライベートアドレスについてNATを照会し、ペイロードを変更し、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は、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に問い合わせ、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サーバーからの応答パケットと同様にクエリを変更します。
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 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_ALGはDNSクエリと着信応答を傍受しないため、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展開により、このドキュメントで提案されているスキームは機能しません。
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.
さらに、DNS-ALGでは、セクション3.1で概説されているように、悪意のあるユーザーからのサービス拒否攻撃の可能性があります。セクション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、「The IP Networkアドレス翻訳者（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.、Moskowitz、B.、Karrenberg、D.、de Groot、G。and E. Lear、「Private Internetsのアドレス割り当て」、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] Reynolds J.およびJ. Postel、「割り当てられた番号」、STD 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。and Y. Rekhter、「IPv4アドレスToday」、RFC 2101、1997年2月。
[11] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[11] EastLake、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.、Thompson、S.、Rekhter Y.およびJ. Bound、「ドメイン名システムの動的更新（DNSアップデート）」、RFC 2136、1997年4月。
[13] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997.
[13] EastLake、D。、「Secure Domain Name System Dynamic Update」、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 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] 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.
Pyda Srisuresh 849 Erie Circle Milpitas、CA 95035 U.S.A.
Phone: +1 (408) 263-7527
EMail: srisuresh@yahoo.com
George Tsirtsis Internet Transport Group B29 Room 129 BT Laboratories Martlesham Heath IPSWICH Suffolk IP5 3RE England
George Tsirtsis Internet Transport Group B29ルーム129 BT Laboratories Martlesham Heath Suffolk IP5 3RE England
Phone: +44 1473 640756
Fax: +44 1473 640709
EMail: george@gideon.bt.co.uk
Praveen Akkiraju cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
Praveen Akkiraju Cisco Systems 170 West Tasman Drive San Jose、CA 95134 USA
Phone: +1 (408) 526-5066
EMail: spa@cisco.com
Andy Heffernan Juniper Networks, Inc. 385 Ravensdale Drive. Mountain View, CA 94043 USA
Andy Heffernan Juniper Networks、Inc。385 Ravensdale Drive。マウンテンビュー、CA 94043 USA
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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。