RFC2694 日本語訳
2694 DNS extensions to Network Address Translators (DNS_ALG). P.Srisuresh, G. Tsirtsis, P. Akkiraju, A. Heffernan. September 1999. (Format: TXT=67720 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Srisureshがコメントのために要求するワーキンググループP.をネットワークでつないでください: 2694年のコンサルタントカテゴリ: P.AkkirajuシスコシステムズA.ヘファーナン杜松が1999年9月にネットワークでつなぐ情報のG.Tsirtsis BT研究所
DNS extensions to Network Address Translators (DNS_ALG)
Network Address TranslatorsへのDNS拡張子(DNS_ALG)
Status of this Memo
この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)インターネット協会(1999)。 All rights reserved。
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.
ドメインName Service(DNS)はルーティングのクラスの中で(例えば、IP)を写像する扱う名前を提供します。 ネットワークAddress Translators(NATs)は、同じルーティングのクラスの異種のアドレス分野のホストの間に見え透いたルーティングを提供するのを試みます。 外部アドレスからプライベート・アドレスを隠して、通常、NATsはスタッブドメインの境界に存在しています。 このドキュメントは、DNS拡張子の必要性をNATsに特定して、DNS Application Levelゲートウェイ(DNS_ALG)がどう需要を満たすことができるかを概説します。 DNS_ALGは、DNSパケットが1つのアドレス分野を別のものに越えるときホストのアドレス・マッピングを変更するように透過的にペイロードを変更します。 また、ドキュメントはDNS_ALGの操作に特定の例を入れます。
1. Introduction
1. 序論
Network Address Translators (NATs) are often used when network's internal IP addresses cannot be used outside the network either for privacy reasons or because they are invalid for use outside the network.
プライバシーが推論するか、または使用に、それらがネットワークの外で無効であるのでネットワークの外でネットワークの内部のIPアドレスを使用できないとき、ネットワークAddress Translators(NATs)はしばしば使用されます。
Ideally speaking, a host name uniquely identifies a host and its address is used to locate routes to the host. However, host name and address are often not distinguished and used interchangeably by applications. Applications embed IP address instead of host name in
理想的に話すなら、ホスト名は唯一ホストを特定します、そして、アドレスは、ホストにルートの場所を見つけるのに使用されます。 しかしながら、ホスト名とアドレスは、アプリケーションで互換性を持ってしばしば顕著であるというわけではなくて使用されています。 アプリケーションはホスト名の代わりにIPアドレスを中に埋め込みます。
Srisuresh, et al. Informational [Page 1] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[1ページ]のRFC2694DNS拡張子
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.
ペイロード。 例はサーバー名(例えば、 user@private.com )の代わりに送付者IDとしてのそれらのMXサーバアドレス(例えば、 user@666.42.7.11 )を指定するメールでしょう。 名前の代わりにURLなどにおけるIPアドレスを含んでいるHTMLファイル NATsがペイロードではなく、アドレス分野に合うようにネットワークと輸送ヘッダーを変更するのでパケットがNATデバイスを横断するとき、ペイロードのホスト名に代わったIPアドレスの使用は問題を表します。
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はNameをアドレス・マッピングに提供します。 ところが、NATは個人的で外部のアドレス分野の間のデータグラムのアドレス変換(ネットワークと輸送ヘッダーの)横断を実行します。本書では概説されたDNS Application Levelゲートウェイ(DNS_ALG)が、DNSペイロードで個人的なアドレス・マッピングへのNameをNameに翻訳するのを助ける、-、逆もまた同様に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.
Network Address Port Translator(NAPT)はアドレスを実行します、そして、Transportはポート翻訳を平らにします(i.のe、TCP、UDPポート、およびICMPはIDについて質問します)。 DNS名前マッピング粒状は、しかしながら、IPアドレスに制限されて、平らな識別子を輸送するために広がっていません。 ホスト・アドレスが内緒でネットワークでつなぐのが、ただ一つの外部アドレスにバウンドすることであるので、その結果、NAPT構成のためのDNS_ALG処理は簡易型です。 個人的なホスト(外部のホストからの)のためのルックアップというDNS名はすべての個人的なホストがただ一つの事前に定義された外部アドレスに縛られるので付く新鮮な個人的な外部アドレスを強制しません。 しかしながら、外部アドレスが個人的なホストのいずれにも写像しないで、単にNAPTルータに写像するNAPTのために名前ルックアップを逆にしてください。 NAPTが構成であるとサポートするDNS_ALGのための処理所要がBasic NATの単なる部分集合であると言うために、十分です。 したがって、ドキュメントの残りにおける議論は主にNAPTセットアップへのBasic NATとBi方向のNATと特定指示のないTwice 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]で見つけられるかもしれません。
2. Requirement for DNS extensions
2. DNS拡張子のための要件
There are many ways to ensure that a host name is mapped to an address relevant within an address realm. In the following sections, we will identify where DNS extensions would be needed.
ホスト名がアドレス分野の中で関連しているアドレスに写像されるのを保証する多くの方法があります。 以下のセクションで、私たちは、DNS拡張子がどこで必要であるかを特定するつもりです。
Typically, organizations have two types of authoritative name servers. Internal authoritative name servers identify all (or majority of) corporate resources within the organization. Only a portion of these hosts are allowed to be accessed by the external world. The remaining hosts and their names are unique to the private network. Hosts visible to the external world and the authoritative
組織には、通常、2つのタイプの正式のネームサーバがあります。 内部の正式のネームサーバがすべてを特定する、(大多数、)、組織の中の企業の諸資源。 外界はこれらのホストの一部だけがアクセスできます。 残っているホストと彼らの名前は私設のネットワークにユニークです。 外界と正式に目に見えるホスト
Srisuresh, et al. Informational [Page 2] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[2ページ]のRFC2694DNS拡張子
name server that maps their names to network addresses are often configured within a DMZ (De-Militarized Zone) in front of a firewall. We will refer the hosts and name servers within DMZ as DMZ hosts and DMZ name servers respectively. DMZ host names are end-to-end unique in that their FQDNs do not overlap with any end node that communicates with it.
それらの名前をネットワーク・アドレスに写像するネームサーバがファイアウォールのDMZ(反-Militarized Zone)の中でしばしば構成されます。 私たちはDMZホストとDMZネームサーバとしてDMZの中でそれぞれホストとネームサーバを参照するつもりです。 それらのFQDNsがそれで交信するどんなエンドノードにも重ならないので、DMZホスト名は終わりから終わりにユニークです。
\ | /
+-----------------------+
|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
\ | / +-----------------------+ |サービスプロバイダールータ| +-----------------------+ WAN| Aを引き抜いてください… …|\|.... | +-----------------+ |NATがあるスタッブルータ| +-----------------+ | | 非武装地帯--ネットワーク------------------------------------------------------------ | | | | | +--+ +--+ +--+ +--+ +----------+ |__| |__| |__| |__| | ファイアウォール| /____\ /____\ /____\ /____\ +----------+ 非武装地帯-Host1非武装地帯-Host2… 非武装地帯名の非武装地帯ウェブ| サーバサーバなど | | 内部のホスト(プライベートアイピーネットワーク)| ------------------------------------------------------------ | | | | +--+ +--+ +--+ +--+ |__| |__| |__| |__| /____\ /____\ /____\ /____\Int-Host1 Int-Host2… Int-Hostn Int-ネームサーバ
Figure 1: DMZ network configuration of a private Network.
図1: DMZは個人的なNetworkの構成をネットワークでつなぎます。
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ネームサーバに制限されて、内部のホストと内部名サーバを含めないでしょう、たまたま同じでないなら。
Srisuresh, et al. Informational [Page 3] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[3ページ]のRFC2694DNS拡張子
2.1. DMZ hosts assigned static external addresses on NAT
2.1. 静的な外部アドレスがNATに割り当てられた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ホストが外部のドメインの彼らの場内放送によって特定されるのを許容します。
2.1.1. Private networks with no DMZ name servers
2.1.1. DMZネームサーバのない私設のネットワーク
Take the case where a private network has no DMZ name server for itself. If the private network is connected to a single service provider for external connectivity, the DMZ hosts may be listed by their external addresses in the authoritative name servers of the service provider within their forward and in-add.arpa reverse zones.
私設のネットワークがDMZネームサーバを全く持っていないケースをそれ自体に取ってください。 私設のネットワークが外部の接続性のためにただ一つのサービスプロバイダーに接続されるなら、DMZホストは前方と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.
ネットワークが複数のサービスプロバイダーに接続されるなら、それらの外部アドレス(es)によってDMZホスト名はそれぞれのサービスプロバイダーの正式のネームサーバの中に記載されるかもしれません。 これはaddr.arpaの逆のゾーンの場合で特に重要です、異なったアドレス接頭語がサービスプロバイダーによって私設のネットワークに配属されるとき。
In both cases, externally generated DNS lookups will not reach the private network. A large number of NAT based private domains pursue this option to have their DMZ hosts listed by their external addresses on service provider's name servers.
どちらの場合も、外部的に生成しているDNSルックアップは私設のネットワークに達しないでしょう。 多くのNATに基づいている個人的なドメインが、彼らの外部アドレスで彼らのDMZホストをサービスプロバイダーのネームサーバに記載させるためにこのオプションを追求します。
2.1.2. Private networks with DMZ name servers
2.1.2. DMZネームサーバがある私設のネットワーク
Take the case where a private network opts to keep an authoritative DMZ name server for the zone within the network itself. If the network is connected to a single service provider, the DMZ name server may be configured to obviate DNS payload interceptions as follows. The hosts in DMZ name server must be mapped to their statically assigned external addresses and the internal name server must be configured to bypass the DMZ name server for queries concerning external hosts. This scheme ensures that DMZ name servers are set for exclusive access to external hosts alone (not even to the DMZ hosts) and hence can be configured with external addresses only.
私設のネットワークがネットワーク自体の中で正式のDMZネームサーバをゾーンに保つために選ばれるケースを取ってください。 ネットワークがただ一つのサービスプロバイダーに接続されるなら、DMZネームサーバは、以下のDNSペイロード妨害を取り除くために構成されるかもしれません。 彼らの静的に割り当てられた外部アドレスにDMZネームサーバにおけるホストを写像しなければなりません、そして、質問のために外部のホストに関してDMZネームサーバを迂回させるために内部名サーバを構成しなければなりません。 この体系は、DMZネームサーバが単独で外部のホストへの排他的なアクセスに設定されるのを確実にして(DMZホストには、同等でない)、したがって、外部アドレスだけで構成できます。
The above scheme requires careful administrative planning to ensure that DMZ name servers are not contacted by the private hosts directly or indirectly (through the internal name servers). Using DNS-ALG would obviate the administrative ordeals with this approach.
上の体系は、DMZネームサーバが個人的なホストによって直接か間接的(内部名サーバを通して)に連絡されないのを保証するために慎重な管理計画を必要とします。 DNS-ALGを使用すると、管理試練はこのアプローチで取り除かれるでしょう。
Srisuresh, et al. Informational [Page 4] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[4ページ]のRFC2694DNS拡張子
2.2. DMZ hosts assigned external addresses dynamically on NAT
2.2. DMZホストはダイナミックに外部アドレスをNATに割り当てました。
Take the case where DMZ hosts in a private network are assigned external addresses dynamically by NAT. While the addresses issued to these hosts are fixed within the private network, their externally known addresses are ephemeral, as determined by NAT. In such a scenario, it is mandatory for the private organization to have a DMZ name server in order to allow access to DMZ hosts by their name.
NATで、ダイナミックに、外部アドレスが私設のネットワークのDMZホストに割り当てられるケースを取ってください。 これらのホストに発行されたアドレスは私設のネットワークの中で修理されていますが、彼らの外部的に知られているアドレスははかないです、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 Application Levelゲートウェイ(DNS_ALG)がネームサーバかDMZネームサーバから指示されたDNSパケットを妨害して、わかりやすいペイロード翻訳を実行するので、DMZホスト名はそれぞれのアドレス分野の中の正しいアドレス・マッピングを(すなわち、個人的であるか外部)であるのに持っています。
3. Interactions between NAT and DNS_ALG
3. NATとDNS_ALGとの相互作用
This document operates on the paradigm that interconnecting address realms may have overlapping address space. But, names of hosts within interconnected realms must be end-to-end unique in order for them to be accessed by all hosts. In other words, there cannot be an overlap of FQDNs between end nodes communicating with each other. The following diagram illustrates how a DNS packet traversing a NAT device (with DNS_ALG) is subject to header and payload translations. A DNS packet can be a TCP or UDP packet with the source or destination port set to 53. NAT would translate the IP and TCP/UDP headers of the DNS packet and notify DNS-ALG to perform DNS payload changes. DNS-ALG would interact with NAT and use NAT state information to modify payload, as necessary.
このドキュメントは、アドレス空間を重ね合わせながら、パラダイムでアドレス分野が持っているかもしれないその内部連絡を操作します。 しかし、インタコネクトされた分野の中のホストの名前は、それらがすべてのホストによってアクセスされる命令でユニークな終わりから終わりであるに違いありません。 言い換えれば、互いにコミュニケートするエンドノードの間には、FQDNsのオーバラップがあるはずがありません。 以下のダイヤグラムはNATデバイス(DNS_ALGと)を横断するDNSパケットがどうヘッダーとペイロード翻訳を受けることがあるかを例証します。 DNSパケットは、ソースがあるTCPかUDPパケットであるかもしれませんか仕向港が53にセットしました。 NATは、DNSパケットのIPとTCP/UDPヘッダーを翻訳して、DNS-ALGがDNSペイロード変化を実行するように通知するでしょう。 DNS-ALGは、必要に応じてペイロードを変更するのにNATと対話して、NAT州の情報を使用するでしょう。
Srisuresh, et al. Informational [Page 5] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[5ページ]のRFC2694DNS拡張子
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
オリジナルのIPパケット|| || vv+---------------------------------+ +-----------------------+ | | |DNS Appl。 ゲートウェイを平らにしてください。| |ネットワーク・アドレス翻訳(NAT)|、-、--、>| (DNS_ALG) | | *IPとTransportヘッダーモッズ| <、-、--、| *DNSペイロードモッズ| | | | | +---------------------------------+ +-----------------------+ || || vv Translated-IPパケット
Figure 2: NAT & DNS-ALG in the translation path of DNS packets
図2: DNSパケットの翻訳経路のNATとDNS-ALG
3.1. Address Binding considerations
3.1. アドレスBinding問題
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.
私たちはNATsで「仮の住所結合」と「遂行されたアドレス結合」の間で区別をするつもりです。 DNS_ALGが社外利用者はNATの状態を創設して、その結果、サービス不能攻撃の可能性を創設するのを許容するので、この区別は必要になります。 一時的なアドレス結合はアドレス結合が少しもNATセッションなしで結合を使用することで控えられるフェーズです。 遂行されたアドレス結合は外部的、そして、個人的なアドレスの間の結合を使用する少なくとも1つのNATセッションが存在するフェーズです。 両方のタイプの結合は、DNSペイロードを変更するのにDNS_ALGによって使用されます。 NATは、NATセッションに関してデータグラムのIPとTransportヘッダーを変更するのに遂行されたアドレス結合だけを使用します。
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ネームサーバが名前ルックアップのために質問されるとき、仮製本は起こります。 質問創始者と質問されたホストとの本当のセッションまで名前質問はありそうなa先駆です。 NATが質問創始者と質問されたホストとのセッションの最初のパケットを見るときだけ、仮製本は遂行されるようになります。
A configurable parameter, "Bind-holdout time" may be defined for dynamic address assignments as the maximum period of time for which a temporary address binding is held active without transitioning into a committed binding. With each use of temporary binding by DNS_ALG (to modify DNS payload), this Bind-holdout period is renewed. A default Bind-holdout time of a couple of minutes might suffice for most DNS- ALG implementations. Note, it is possible for a committed address
構成可能なパラメタ、「ひも拒否者時間」はダイナミックなアドレス課題のために一時的なアドレス結合が遂行された結合に移行しないでアクティブに保たれる最大の期間と定義されるかもしれません。 DNS_ALG(DNSペイロードを変更する)による仮製本の各使用のときに、このBind-拒否者の期間は更新されます。 2、3分のデフォルトBind-拒否者時間はほとんどのDNS- ALG実装に十分であるかもしれません。 遂行されたアドレスに、それが可能であることに注意してください。
Srisuresh, et al. Informational [Page 6] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[6ページ]のRFC2694DNS拡張子
binding to occur without ever having to be preceded by a temporary binding. Lastly, when NAT is ready to unbind a committed address binding, the binding is transitioned into a temporary binding and kept in that phase for an additional Bind-holdout period. The binding is freed only upon expiry of Bind-holdout time. The Bind-holdout time preceding the committed-address-binding and the address-unbinding are required to ensure that end hosts have sufficient time in which to initiate a data session subsequent to a name lookup.
かつて先行する必要はなくて、起こるように付いて、仮製本で先行されてください。 NATが遂行されたアドレス結合を解く準備ができているとき、追加Bind-拒否者の期間、最後に、結合は、仮製本に移行してそのフェーズで保たれます。 結合は単にBind-拒否者時間の満期に解放されます。 遂行されたアドレス結合に先行するBind-拒否者時間とアドレス解くことが、終わりのホストが十分な時間を名前ルックアップへのその後のデータセッションを開始する過すのを保証するのに必要です。
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がある私設のネットワークが.29/24に198.76に写像されると言ってください。 外部であるときに、ホストはDNS質問をhost7にします、アドレスを示して10.0、.0、.7、私設のネットワークの中のDMZネームサーバがhost7のためにAタイプRRと共に以下として応じます。
host7 A 10.0.0.7
host7A10.0.0.7
DNS_ALG would intercept the response packet and if 10.0.0.7 is not assigned an external address already, it would request NAT to create a temporary address binding with an external address and start Bind- holdout timer to age the binding. Say, the assigned external address is 198.76.29.1. DNS-ALG would use this temporary binding to modify the RR in DNS response, replacing 10.0.0.7 with its external address and reply with:
そして、DNS_ALGが応答パケットを妨害するだろう、10.0 .0 外部アドレスは既に.7に割り当てられないで、それは、外部アドレスで拘束力があった状態でa仮の住所を作成して、結合の年をとるようにBind拒否者タイマを始動するためにNATを要求するでしょう。 割り当てられた外部アドレスがそうであると言ってください。198.76 .29 .1。 DNS-ALGはDNS応答でRRを変更するのにこの仮製本を使用するでしょう、取り替える、10.0、.0、.7、以下があるその外部アドレスと回答
host7 A 198.76.29.1
host7A198.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がBind-拒否者タイマを終えて、変遷が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による仮製本の使用を例証すると考えるつもりです、概念はまた、NATsの他の風味に適切ですが。
Srisuresh, et al. Informational [Page 7] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[7ページ]のRFC2694DNS拡張子
3.2. Incoming queries
3.2. 入って来る質問
In order to initiate incoming sessions, an external host obtains the V4 address of the DMZ-host it is trying to connect to by making a DNS request. This request constitutes prelude to the start of a potential new session.
入って来るセッションを開始するために、外部のホストはそれがDNS要求をすることによって接しようとしているDMZ-ホストのV4アドレスを得ます。 この要求は潜在的新しいセッションの始まりようにプレリュードを構成します。
The external host resolver makes a name lookup for the DMZ host through its DNS server. When the DNS server does not have a record of IPv4 address attached to this name, the lookup query is redirected at some point to the Primary/Backup DNS server (i.e., in DMZ) of the private stub domain.
外部のホストレゾルバはDMZホストのためにDNSサーバを通して名前ルックアップを作ります。DNSサーバでIPv4アドレスに関する記録をこの名前に添付しないと、ルックアップ質問は何らかのポイントで個人的なスタッブドメインのPrimary/バックアップDNSサーバ(すなわち、DMZの)に向け直されます。
Enroute to DMZ name server, DNS_ALG would intercept the datagram and modify the query as follows.
DMZネームサーバへの途中で、DNS_ALGはデータグラムを妨害して、以下の質問を変更するでしょう。
a) For Host name to Host address query requests:
Make no change to the DNS payload.
a) Hostにちなんで、アドレス質問要求をHostと命名してください: 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) Hostに関しては、名前が質問であるとHostに扱ってください: 対応する個人的なV4アドレスがあるストリング「IN ADDR.ARPA」に先行して、外部のV4アドレス八重奏(逆順で)を取り替えてください、そのようなアドレス結合が既に存在しているなら。 しかしながら、結合が存在していないなら、DNS_ALGは5(方針理由のため応じるREFUSED)の応答コード(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) ホスト・アドレス質問要求へのホスト名には、場内放送が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) ホスト名質問へのホスト・アドレスには、彼らの外部アドレス課題で応答RRsでストリング「ADDR.ARPA」に先行するプライベート・アドレス八重奏を取り替えてください。 DMZネームサーバが返答する時までに問題のアドレスのためのNATにおけるひもの拒否者タイマが期限が切れたというここの見込みがあります。 このような場合には、DNS_ALGは単に回答を下げるでしょう。 送付者は質問を再送しなければならないでしょう(途中ルータが応答を下げると、起こるでしょう、したがって)。
Srisuresh, et al. Informational [Page 8] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[8ページ]のRFC2694DNS拡張子
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値は変わりがないままにされるでしょう。 ダイナミックなアドレス課題、ALGが変更するDNS_に関しては、TTLは0になるように、DNSでリソース記録(RRs)を評価します、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がひも拒否者タイマを開始するよう要求されているでしょう。 セッションが全くBind-拒否者の期間中に個人的なホストに開始されないなら、NATは仮製本を終えるでしょう。
3.3. Outgoing Queries
3.3. 外向的な質問
For Basic and bi-directional NATs, there is no need to distinguish between temporary and committed bindings for outgoing queries. This is because, DNS_ALG does not modify the DNS packets directed to or from external name servers (used during outbound sessions), unlike the inbound DNS sessions.
Basicと双方向のNATsのために、外向的な質問のための一時的で遂行された結合を見分ける必要は全くありません。 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サーバによって送られて、一時的であるときに、作成されて、プライベート・アドレス結合を作成するということです。
4. DNS payload modifications by DNS-ALG
4. DNS-ALGによるDNSペイロード変更
Typically, UDP is employed as the transport mechanism for DNS queries and responses and TCP for Zone refresh activities. In either case, name servers are accessed using a well-known DNS server port 53 (decimal) and all DNS payloads have the following format of data [Ref
ZoneのためのDNS質問のための移送機構、応答、およびTCPが活動をリフレッシュするとき、UDPは通常、採用しています。 どちらの場合ではも、ネームサーバがよく知られるDNSサーバポート53(小数)を使用することでアクセスされていて、すべてのDNSペイロードにはデータの以下の書式がある、[審判
Srisuresh, et al. Informational [Page 9] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[9ページ]のRFC2694DNS拡張子
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はIPに関する翻訳とDNSパケットの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によってHeader部に変化によって全く作られている必要はありません。 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
+---------------------+
+---------------------+ | ヘッダー| +---------------------+ | 問題| ネームサーバ+のための問題---------------------+ | 答え| 質問+に答えるRRs---------------------+ | 権威| 権威+に向かって指すRRs---------------------+ | 追加| 追加情報+を保持するRRs---------------------+
4.1. Question section
4.1. 質問部
The question section contains QDCOUNT (usually 1) entries, as specified in Header section, with each of the entries in the following format:
質問部はQDCOUNT(通常1)エントリーを含みます、Header部で指定されるように、以下の形式における、それぞれのエントリーで:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ QNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QCLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / QNAME / / /+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+| QTYPE| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QCLASS| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4.1.1. PTR type Queries
4.1.1. PTRはQueriesをタイプします。
DNS_ALG must identify all names, whose FQDNs (i.e., Fully Qualified Domain Names) fall within IN-ADDR.ARPA domain and replace the address octets (in reverse order) preceding the string "IN-ADDR.ARPA" with the corresponding assigned address octets in reverse order, only if the address binding is active on the NAT router. If the address
DNS_ALGは対応する割り当てられたアドレス八重奏で逆順でストリング「ADDR.ARPA」に先行しながら、FQDNs(すなわち、Fully Qualified Domain Names)がIN-ADDR.ARPAドメインの中に落ちるすべての名前を特定して、アドレス八重奏(逆順で)を取り替えなければなりません、アドレス結合がNATルータで活発である場合にだけ。 アドレスです。
Srisuresh, et al. Informational [Page 10] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[10ページ]のRFC2694DNS拡張子
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.
少なくとも一時的なアドレス結合(ALGが応答のヘッダー部分で逆(DNSネームサーバがそうするように)で5(方針理由のため応じるのを拒否する)、セットANCOUNT、NSCOUNT、およびARCOUTの応答コード(RCODE)で0に単に単に反応させるDNS_)を持っていないのを除いて、ストリング「ADDR.ARPA」に先行するのはNATアドレス地図の中で低下します。
Note that the above form of host address to host name type queries will likely yield different results at different times, depending upon address bind status in NAT at a given time.
ホスト名タイプ質問への上のフォームのホスト・アドレスがいろいろな時間におそらく異なった結果をもたらすことに注意してください、一時にNATにおけるアドレスひもの状態によって。
For example, a resolver that wanted to find out the hostname corresponding to address 198.76.29.1 (externally) would pursue a query of the form:
例えば、アドレス198.76.29に対応するホスト名から.1が(外部的に)形式の質問を追求するのがわかりたがっていたレゾルバ:
QTYPE = PTR, QCLASS = IN, QNAME = 1.29.76.198.IN-ADDR.ARPA.
QTYPE=PTR、QCLASS=IN QNAMEは1.29.76.198.IN-ADDR.ARPAと等しいです。
DNS_ALG would intervene and if the address 198.76.29.1 is internally mapped to a private address of 10.0.0.1, modify the query as below and forward to DMZ name server within private network.
DNS_ALGが介入するだろう、アドレスである、198.76、.29、.1、内部的にプライベート・アドレスに写像される、10.0 .0 .1 DMZネームサーバへの私設のネットワークの中の以下と前進として質問を変更してください。
QTYPE = PTR, QCLASS = IN, QNAME = 1.0.0.10.IN-ADDR.ARPA
QTYPE=PTR、QCLASS=IN QNAMEは1.0.0.10.IN-ADDR.ARPAと等しいです。
Presumably, the DMZ name server is the authoritative name server for 10.IN-ADDR.ARPA zone and will respond with an RR of the following form in answer section. DNS_ALG translations of the response RRs will be considered in a following section.
おそらく、DMZネームサーバは、10.IN-ADDR.ARPAゾーンへの正式のネームサーバであり、以下の形式のRRと共に答え部で応じるでしょう。 応答RRsに関するDNS_ALG翻訳は以下の章で考えられるでしょう。
1.0.0.10.IN-ADDR.ARPA PTR host1.fooboo_org.provider_domain
1.0.0.10. IN ADDR.ARPA PTR host1.fooboo_org.provider、_ドメイン
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.
Inverse翻訳に関する例はスパム防止のためにメール送信元ホストをつけるのに逆さの翻訳を使用するメールソフトです。 本当に、メールが送られたアドレスが送付者が送付者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ビットはヘッダーに設定されるべきです。
Srisuresh, et al. Informational [Page 11] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[11ページ]のRFC2694DNS拡張子
Lastly, any compressed domain names using pointers to represent common domain denominations must be updated to reflect new pointers with the right offset, if the original domain name had to be translated by NAT.
最後に、正しいオフセットで新しい指針を反映するために共通領域宗派を表すのに指針を使用するどんな圧縮されたドメイン名もアップデートしなければなりません、オリジナルのドメイン名がNATによって翻訳されなければならなかったなら。
4.1.2. A, MX, NS and SOA type Queries
4.1.2. A、MX、NS、およびSOAはQueriesをタイプします。
For these queries, DNS_ALG would not modify any of the fields in the query section, not even the name field.
これらの質問のために、DNS_ALGは名前欄さえではなく、質問部で分野のいずれも変更しないでしょう。
4.1.3. AXFR type Queries
4.1.3. AXFRはQueriesをタイプします。
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の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.
ネームサーバのバックアップをとるために、ゾーン転送は通常予備選挙からあります。 ゾーン転送がドメインのむこうになくて、またゾーン転送のDNS_ALGサポートが問題でなく同じ個人的なドメイン(たとえば、private.zone)に位置して、予備選挙とバックアップサーバによる中では、NATに関するケースが私設のネットワークをサポートしたように教えられます。 場合では、個人的なドメインの外にセカンダリネームサーバを位置させていて、非静的なアドレス課題のためにゾーン転送を受入れてはいけません。 プライマリの、そして、セカンダリのサーバが、ゾーンのデータのすべての参照を得なければならなかったので同じ個人的なドメインの中にあるのに必要です。 ダイナミックなアドレス課題と結合では、最新になるようにaxfrデータを翻訳するのは不可能です。 したがって、private.zoneのためのセカンダリサーバがそのドメインに外部であることの形で見つけられることであるなら、それは悪いデータを含んでいます。 しかしながら、ここに概説された要件がRFC2182と共にconfirmenceにないことに注意してください。(RFCは、プライマリの、そして、セカンダリのサーバがインターネットの位相的に地理的に分散している位置に置かれることを勧めます)。
During zone transfers, DNS_ALG must examine all A type records and replace the original address octets with their statically assigned address octets. DNS_ALG could also examine if there is an attempt to
ゾーン転送の間、DNS_ALGはすべてのAタイプ記録を調べて、オリジナルのアドレス八重奏を彼らの静的に割り当てられたアドレス八重奏に取り替えなければなりません。 また、DNS_ALGは、試みがあるかどうか調べることができました。
Srisuresh, et al. Informational [Page 12] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[12ページ]のRFC2694DNS拡張子
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.
静的なアドレスが割り当てられないで、単独でそれらの記録を下げるか、または全体の転送を下げるホストのために記録を移してください。 これはmisconfigurationと人為ミスを最小にするでしょう。
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からのゾーンの中の介入のないノードからのダイナミックなアップデートを持つことができます、1つが、アドレス分野の向こう側にDNSゾーンを広げるのを避ける限り。私たちは、それは責任がある同じ分野の中にDNSゾーンを保つことを勧めます。 そうすれば、DNSアップデートトラフィックは、アドレス分野に交差しないで、またしたがって、DNS-ALGによる考慮を受けることがないでしょう。
Further, if dynamic updates do cross address realms, and the updates must always be secured via DNSSEC, then such updates are clearly out of scope for DNS-ALG (as described in section 7).
さらに、ダイナミックなアップデートがアドレス分野に交差していて、DNSSECを通していつもアップデートを保証しなければならないなら、DNS-ALGのための明確に範囲の外にそのようなアップデートがあります(セクション7で説明されるように)。
4.2. Resource records in all other sections
4.2. 他のすべてのセクションでのリソース記録
The answer, authority, and additional sections all share the same format, with a variable number of resource records. The number of RRs specific to each of the sections may be found in the corresponding count fields in DNS header. Each resource record has the following format:
答え、権威、および追加セクションはすべて、可変数のリソース記録と同じ形式を共有します。 それぞれのセクションに特定のRRsの数はDNSヘッダーの対応するカウント野原で発見されるかもしれません。 それぞれのリソース記録には、以下の形式があります:
The TTL value supplied in the original RRs will be left unchanged for static address assignments. For dynamic address assignments, DNS_ALG will modify the TTL to be 0, so the RRs are used just for the transaction in progress, and not cached. RFC 2181 requires all RRs in an RRset (RRs with the same name, class and type, but with different RDATA) to have the same TTL. So if the TTL of an RR is set to 0, all other RRs within the same RRset will also be adjusted by the DNS-ALG to be 0.
オリジナルのRRsで供給されたTTL値は静的なアドレス課題に変わりがないままにされるでしょう。 ダイナミックなアドレス課題において、DNS_ALGが0になるようにTTLを変更するので、RRsはまさしく進行中のトランザクションに使用されて、キャッシュされません。 RFC2181は、RRset(同じ名前、クラス、およびタイプにもかかわらず、異なったRDATAとRRs)のすべてのRRsには同じTTLがあるのを必要とします。 それで、また、RRのTTLが0に用意ができていると、同じRRsetの中の他のすべてのRRsが、0になるようにDNS-ALGによって調整されるでしょう。
Srisuresh, et al. Informational [Page 13] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[13ページ]のRFC2694DNS拡張子
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | ///名/| | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | タイプ| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | クラス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL| | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / /+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4.2.1. PTR type RRs
4.2.1. PTRはRRsをタイプします。
The considerations specified in the Question section is equally valid with names for PTR type RRs. Private address preceding the string "IN-ADDR.ARPA" (in reverse order of octets) must be replaced by its external address assignment (in reverse order), if a binding exists. The remaining fields for this RR remain unchanged.
PTRタイプRRsには、Question部で指定された問題は名前によって等しく有効です。 ストリング「ADDR.ARPA」(八重奏の逆順で)に先行するプライベート・アドレスを外部アドレス課題(逆順で)に取り替えなければなりません、結合が存在しているなら。 このRRのための残っているフィールドは変わりがありません。
4.2.2. A type RRs
4.2.2. タイプRRs
The RDATA for A records is a 4-byte IP address. DNS_ALG would simply replace the original address in RDATA with its externally assigned IP address, if it succeeded in finding an address binding. Successful address translation should cause no changes to payload length. Only the transport header checksum would need updating. In case of failure to find an address binding, DNS_ALG would have to drop the record and decrement the corresponding COUNT field in the header section.
A記録のためのRDATAは4バイトのIPアドレスです。 DNS_ALGは単にRDATAのオリジナルのアドレスを外部的に割り当てられたIPアドレスに取り替えるでしょう、アドレス結合を見つけるのに成功したなら。 うまくいっているアドレス変換はペイロード長への変化を全く引き起こすべきではありません。 輸送ヘッダーチェックサムだけが、アップデートする必要があるでしょう。 アドレス結合を見つけないことの場合には、DNS_ALGはヘッダー部分で記録を下げて、対応するCOUNT分野を減少させなければならないでしょう。
4.2.3. CNAME, MX, NS and SOA type RRs
4.2.3. CNAME、MX、NS、およびSOAはRRsをタイプします。
No changes required to be made by DNS_ALG for these RRs, as the RDATA does not contain any IP addresses. The host names within the RDATA remain unchanged between realms.
RDATAが少しのIPアドレスも含んでいなくて、どんな変化もこれらのRRsのためにDNS_ALGによって作られているのが必要ではありません。 RDATAの中のホスト名は分野の間で変わりがありません。
Srisuresh, et al. Informational [Page 14] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[14ページ]のRFC2694DNS拡張子
5. Illustration of DNS_ALG in conjunction with Bi-directional NAT
5. Bi方向のNATに関連したDNS_ALGのイラスト
The following diagram illustrates the operation of DNS_ALG in a a bi-directional NAT router. We will illustrate by walking through how name lookup and reverse name lookup queries are processed.
以下のダイヤグラムはa双方向のNATルータにおける、DNS_ALGの操作を例証します。 私たちは、名前ルックアップと逆の名前ルックアップ質問がどう処理されるかを通って歩くことによって、例証するつもりです。
.
________________ . External.com
( ) .
( ) . +-------------+
+--+ ( Internet )-.---|Border Router|
|__|------ ( ) . +-------------+
/____\ (________________) . |
Root | . |
DNS Server | . ---------------
+---------------+ . | |
|Provider Router| . +--+ +--+
+---------------+ . |__| |__|
| . /____\ /____\
| . DNS Server Host X
External domain | . 171.68.1.1 171.68.10.1
............................|...............................
Private domain |
| Private.com
|
+--------------------------------------+
|Bi-Directional NAT router with DNS_ALG|
| |
| Private addresses: 172.19/16 |
| External addresses: 131.108.1/24 |
+--------------------------------------+
| |
---------- ----------
| | DNS Server
+--+ +--+ Authoritative
|__| |__| for private.com
/____\ /____\
Host A DNS Server
172.19.1.10 172.19.2.1
(Mapped to 131.108.1.8)
. ________________ . External.com( )( ) +-------------+ +--+ (インターネット)、----|境界ルータ| |__|------ ( ) . +-------------+ /____\ (________________) . | 根| . | DNSサーバ| . --------------- +---------------+ . | | |プロバイダールータ| . +--+ +--+ +---------------+ . |__| |__| | . /____\ /____\ | . DNS Server Host X Externalドメイン| . 171.68.1.1 171.68.10.1 ............................|............................... 個人的なドメイン| | Private.com| +--------------------------------------+ |DNS_ALGがある2方向のNATルータ| | | | プライベート・アドレス: 172.19/16 | | 外部アドレス: 131.108.1/24 | +--------------------------------------+ | | ---------- ---------- | | DNSサーバ+(+ +)+正式です。|__| |__| private.com/のために____\ /____\はDNSサーバ172.19.1.10 172.19.2.1を接待します。(.1を131.108に写像する、.8)
Figure 3: DNS-ALG operation in Bi-Directional NAT setup
図3: Bi方向の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
上のダイヤグラムは会社のprivate.comの使用の個人的なアドレス空間172.19/16が双方向のNATを使用することでインターネットに接続するシナリオについて表現します。 DNS_ALGは、必要なDNSをペイロード変化にするようにNATデバイスに埋め込まれています。 NATは、外部アドレスブロックへのプライベート・アドレススペースを翻訳するために構成されています。
Srisuresh, et al. Informational [Page 15] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[15ページ]のRFC2694DNS拡張子
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.
171.68/16の登録されたあて先ブロックを使用して、会社のexternal.comは外部のドメインに位置しています。 また、トポロジーに示されているのは、根のDNSサーバです。
Following simplifications are made to the above configuration:
次の簡素化を上の構成にします:
* private.com is not multihomed and all traffic to the external
space transits a single NAT.
* private.comは「マルチ-家へ帰」りません、そして、外部のスペースへのすべてのトラフィックがただ一つのNATを通過します。
* The DNS server for private.com is authoritative for the
private.com domain and points to the root server for all other
DNS resolutions. The same is true for the DNS server in
external.com.
* private.comのためのDNSサーバは、private.comドメインに正式であり、他のすべてのDNS解決のためにルートサーバーを示します。 external.comのDNSサーバに、同じくらいは本当です。
* The internal name servers for private.com and external.com are
same as their DMZ name servers. The DNS servers for these
domains are configured with addresses private to the
organization.
* private.comとexternal.comのための内部名サーバはそれらのDMZネームサーバと同じです。 これらのドメインへのDNSサーバは組織に個人的なアドレスによって構成されます。
* The name resolvers on host nodes do not have recursion
available on them and desire recursive service from servers.
All name servers are assumed to be able to provide recursive
service.
* ホストノードの上のネーム・リゾルバは、それらで利用可能な再帰を持っていて、サーバから再帰的なサービスを望んでいません。 すべてのネームサーバが再帰的なサービスを提供できると思われます。
5.1. Outgoing Name-lookup queries
5.1. 外向的なName-ルックアップ質問
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.
言ってください、external.comのホストXがThisが以下の通り続かせるX.とのセッションを開始するように名前ルックアップを実行するHost A in private.comの必要性。
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のベースの名前ルックアップ質問(記録)をローカルの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. ルートサーバーは、External.comのためにDNSサーバについて質問するのに順番にローカルのDNSサーバを参照します。 このreferalはローカルのDNSサーバへの途中で、NATを通過します。NATは、DNSサーバのプライベート・アドレスを反映するために単に入って来るパケットのIPとUDPヘッダーを翻訳するでしょう。 DNS_ALGによるペイロードへの変化がありません。
Srisuresh, et al. Informational [Page 16] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[16ページ]のRFC2694DNS拡張子
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によるペイロードへの変化がありません。
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.
Host AがHost Xのアドレスを見つけるとき、AはホストXとのセッションを開始します、.10がIPが.1に171.68を扱う目的地を使用して このセッションのときに続くこのデータグラムとどんな他のものもNATによっていつものように翻訳されるでしょう。
Note, DNS_ALG does not change the payload for DNS packets in either direction.
注意、DNS_ALGはDNSパケットのためにペイロードをどちらの方向にも変えません。
5.2. Reverse name lookups originated from private domain
5.2. 個人的なドメインから溯源された名前ルックアップを逆にしてください。
This scenario builds on the previous case by having host A in Private.com perform a reverse name lookup on 171.68.10.1, which is host X's global address. Following is a sequence of events.
Private.comのホストAに逆名前ルックアップを171.68に実行させることによって、このシナリオは先の事件の上に建てられます。.10 .1 ホストXのグローバルアドレスである。 以下に、イベントの系列があります。
1. Host A sends a UDP based inverse name lookup query (PTR record)
for "1.10.68.171.IN-ADDR.ARPA." to its local DNS server.
1. ホストAは"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は、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はペイロードへの変更を全く行わないでしょう。
Srisuresh, et al. Informational [Page 17] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[17ページ]のRFC2694DNS拡張子
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はペイロードをどちらの方向にも変えません。
5.3. Incoming Name-lookup queries
5.3. 入って来るName-ルックアップ質問
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は「A.Private.com」のために、UDPのベースの名前ルックアップ質問(記録)をローカルの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. ルートサーバーは、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サーバがIPアドレスで返答する、172.19、.1、.10、また、ホストA.Thisに関しては、回答は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)へのNATがHost Aのために仮製本をセットアップするよう要求する、(172.19 .1 外部アドレスと(b)がある.10は)Bind拒否者タイマを開始します。 NATが外部アドレスで首尾よく仮製本をセットアップする、(たとえば、131.108 .1 .12)、DNS_ALGはAのプライベート・アドレスを外部の割り当てられたアドレスに取り替えて、Cacheタイムアウトを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.
Host XがHost Aのアドレスを見つけるとき、XはAとのセッションを開始します、.1がIPが.12に131.108を扱う目的地を使用して このセッションのときに続くこのデータグラムとどんな他のものもNATによっていつものように翻訳されるでしょう。
Srisuresh, et al. Informational [Page 18] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[18ページ]のRFC2694DNS拡張子
Note, DNS_ALG changes only the response packets from the DNS server for Private domain.
注意、DNS_ALGは応答パケットだけをDNSサーバから兵士のドメインに変えます。
5.4. Reverse name lookups originated from external domain
5.4. 外部のドメインから溯源された名前ルックアップを逆にしてください。
This scenario builds on the previous case (section 5.3) by having host X in External.com perform a reverse name lookup on 131.108.1.12, which is host A's assigned external address. The following sequence of events take place.
External.comのホストXに逆名前ルックアップを131.108に実行させることによって、このシナリオは先の事件(セクション5.3)の上に建てられます。.1 .12 どれがAのホストものであるかは外部アドレスを割り当てました。 イベントの以下の系列は行われます。
1. Host X sends a UDP based inverse name lookup query (PTR record)
for "12.1.108.131.IN-ADDR.ARPA." to its local DNS server.
1. ホストXは"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. ルートサーバーは、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がプライベート・アドレスが131.108の外部アドレスに.1を関連づけたのでNATを尋ねるために望んでいる、.12、ペイロード、取り替えを変更してください、131.108、.1、.12、.1は兵卒が.10に172.19を扱います。
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が.1が兵卒に関連している外部アドレスが172.19を扱う割り当てのためにNATを尋ねる、.10、ペイロード、取り替えを変更してください、172.19、.1、.10、.1が外部が.12に131.108を扱う割り当て
6. The DNS server in External.com replies to host X.
6. External.comのDNSサーバはホストXに答えます。
Note, DNS_ALG changes the query as well as response packets from DNS server for Private domain.
注意、DNS_ALGはDNSサーバからの応答パケットと同様に質問を兵士のドメインに変えます。
6. Illustration of DNS_ALG in conjunction with Twice-NAT
6. Twice-NATに関連したDNS_ALGのイラスト
The following diagram illustrates the operation of DNS_ALG in a Twice NAT router. As before, we will illustrate by walking through how name lookup and reverse name lookup queries are processed.
以下のダイヤグラムはTwice NATルータにおける、DNS_ALGの操作を例証します。 従来と同様、私たちは、名前ルックアップと逆の名前ルックアップ質問がどう処理されるかを通って歩くことによって、例証するつもりです。
Srisuresh, et al. Informational [Page 19] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[19ページ]のRFC2694DNS拡張子
.
________________ . External.com
( ) .
( ) . +-------------+
+--+ ( Internet )-.---|Border Router|
|__|------ ( ) . +-------------+
/____\ (________________) . |
Root | . |
DNS Server | . ---------------
+---------------+ . | |
|Provider Router| . +--+ +--+
+---------------+ . |__| |__|
| . /____\ /____\
| . DNS Server Host X
External domain | . 171.68.1.1 171.68.10.1
............................|...............................
Private domain |
| Private.com
|
+-------------------------------------------+
| Twice-NAT router with DNS_ALG |
| |
| Private addresses: 171.68/16 |
| Assigned External addresses: 131.108.1/24 |
| |
| External addresses: 171.68/16 |
| Assigned Private addresses: 10/8 |
+-------------------------------------------+
| |
---------- ----------
| | DNS Server
+--+ +--+ Authoritative
|__| |__| for private.com
/____\ /____\
Host A DNS Server
171.68.1.10 171.68.2.1
(Mapped to 131.108.1.8)
. ________________ . External.com( )( ) +-------------+ +--+ (インターネット)、----|境界ルータ| |__|------ ( ) . +-------------+ /____\ (________________) . | 根| . | DNSサーバ| . --------------- +---------------+ . | | |プロバイダールータ| . +--+ +--+ +---------------+ . |__| |__| | . /____\ /____\ | . DNS Server Host X Externalドメイン| . 171.68.1.1 171.68.10.1 ............................|............................... 個人的なドメイン| | Private.com| +-------------------------------------------+ | DNS_ALGがある2倍NATルータ| | | | プライベート・アドレス: 171.68/16 | | 割り当てられたExternalアドレス: 131.108.1/24 | | | | 外部アドレス: 171.68/16 | | 割り当てられた兵士のアドレス: 10/8 | +-------------------------------------------+ | | ---------- ---------- | | DNSサーバ+(+ +)+正式です。|__| |__| private.com/のために____\ /____\はDNSサーバ171.68.1.10 171.68.2.1を接待します。(.1を131.108に写像する、.8)
Figure 4: DNS-ALG operation in Twice-NAT setup
図4: Twice-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
このシナリオでは、ホストin private.comはRFC1918予約された172.19/16スペースから付番されませんでしたが、グローバルに発送可能な171.68/16ネットワークと共にむしろ付番されました、external.comと同じです。 また、private.comはそれ自身のホスト・アドレスに翻訳サービスを必要とするだけではなく、それらのホストのどれかがホストとデータグラムを交換するつもりであることができるなら、それがexternal.comで翻訳サービスを必要とします。 2倍NATは、aがユニークな状態でexternal.comで使用される重なっているアドレス空間を翻訳することによって、変遷を収容します。
Srisuresh, et al. Informational [Page 20] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[20ページ]のRFC2694DNS拡張子
address block (10/8) from RFC 1918 address space. Routes are set up within the private domain to direct datagrams destined for the address block 10/8 through Twice-NAT device to the external global network space.
RFC1918アドレス空間からのブロック(10/8)を扱ってください。 ルートは、Twice-NATデバイスを通してあて先ブロック10/8に運命づけられたデータグラムを外部の世界的なネットワークスペースに向けるために個人的なドメインの中でセットアップされます。
Simplifications and assumptions made in section 5.0 will be valid here as well.
また、セクション5.0でされた簡素化と仮定はここで有効になるでしょう。
6.1. Outgoing Name-lookup queries
6.1. 外向的なName-ルックアップ質問
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.
言ってください、ホストXのためにexternal.com(ホストXはX.external.comのFQDNを持っている)で名前ルックアップを実行して、アドレスを見つけるHost A in private.comの必要性。 これは続くでしょう。以下の通り、続くでしょう。
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のベースの名前ルックアップ質問(記録)をローカルの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. ルートサーバーは、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サーバは現在external.comのためにDNSサーバに質問を送るでしょう、割り当てられたプライベート・アドレスを使用して、NATで。 今回、NATは、DNSサーバのExternalアドレスを反映するために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
5. external.comのためのDNSサーバはIPアドレス171.68.10.1で返答します。 また、この回答はNATを通過します。 NATは、DNSサーバのプライベート・アドレスを反映するためにもう一度入来のIPとUDPヘッダーを翻訳するでしょう。 すなわち、Private.com DNS
Srisuresh, et al. Informational [Page 21] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[21ページ]のRFC2694DNS拡張子
server's IP address is changed to its private address and
External.Com DNS server's external address is changed to its
assigned Private address.
サーバのIPアドレスはプライベート・アドレスに変わります、そして、External.Com DNSサーバの外部アドレスは割り当てられた兵士のアドレスに変わります。
DNS_ALG will request NAT to (a) set up a temporary binding for
Host X (171.68.10.1) with a private address and (b) initiate
Bind-holdout timer. When NAT successfully sets up temporary
binding with a private address (say, 10.0.0.254), DNS_ALG would
modify the payload to replace X's external address with its
assigned private address and set the Cache timeout to 0.
DNS_ALGが、(a)へのNATがHost Xのために仮製本をセットアップするよう要求する、(171.68 .10 プライベート・アドレスと(b)がある.1は)Bind-拒否者タイマを開始します。 NATがプライベート・アドレスで首尾よく仮製本をセットアップする、(たとえば、10.0 .0 .254)、DNS_ALGはXの外部アドレスを割り当てられたプライベート・アドレスに取り替えて、Cacheタイムアウトを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.
Host AがHost Xのアドレスを見つけるとき、AはホストXとのセッションを開始します、.0がIPが.254に10.0を扱う目的地を使用して このセッションのときに続くこのデータグラムとどんな他のものもTwice NATによっていつものように翻訳されるでしょう。
Note, the DNS_ALG has had to change payload in both directions.
注意、ペイロードを両方の方向に変えるためにALGにはあったDNS_。
6.2. Reverse name lookups originated from private domain
6.2. 個人的なドメインから溯源された名前ルックアップを逆にしてください。
This scenario builds on the previous case by having host A in Private.com perform a reverse name lookup on 10.0.0.254, which is host X's assigned private address. Following is a sequence of events.
Private.comのホストAに逆名前ルックアップを10.0に実行させることによって、このシナリオは先の事件の上に建てられます。.0 .254 どれがXのホストものであるかはプライベート・アドレスを割り当てました。 以下に、イベントの系列があります。
1. Host A sends a UDP based inverse name lookup query (PTR record)
for "254.0.0.10.IN-ADDR.ARPA." to its local DNS server.
1. ホストAは"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は、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は外部がある.254が171.68に.1に.10を扱う個人的な割り当てられたアドレス10.0.0を翻訳するでしょう。
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がオリジナルの質問の場合、個人的な割り当てられたアドレスを翻訳する、10.0、.0、.254、外部アドレス、171.68、.10、.1 さらに、DNS_ALGはreferalサーバ(すなわち、External.comのためのDNSサーバ)の外部アドレスをペイロードの割り当てられたプライベート・アドレスに置き換えるでしょう。
Srisuresh, et al. Informational [Page 22] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[22ページ]のRFC2694DNS拡張子
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サーバは現在external.comのためにDNSサーバに質問を送るでしょう、静的に割り当てられたプライベート・アドレスを使用して、NATで。 今回、NATは、DNSサーバのExternalアドレスを反映するために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がオリジナルの質問の場合、個人的な割り当てられたアドレスを翻訳する、10.0、.0、.254、外部アドレス、171.68、.10、.1
5. The DNS server for external.com replies with the FQDN of
"X.External.Com.". This reply also transits the NAT. NAT would
once again translate the IP and UDP headers of the incoming to
reflect the private addresses of the DNS servers. I.e.,
Private.com DNS server's IP address is changed to its private
address and External.Com DNS server's external address is changed
to its assigned Private address.
5. external.comのためのDNSサーバは「X.External.Com」のFQDNと共に返答します。 また、この回答はNATを通過します。 NATは、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が質問部を翻訳する、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.
注意、ペイロードを両方の方向に変えるためにALGにはあったDNS_。
6.3. Incoming Name-lookup queries
6.3. 入って来るName-ルックアップ質問
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は「A.Private.com」のために、UDPのベースの名前ルックアップ質問(記録)をローカルの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. ルートサーバーは、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サーバの外部アドレスは割り当てられた兵士のアドレスに変わります。
Srisuresh, et al. Informational [Page 23] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[23ページ]のRFC2694DNS拡張子
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サーバがIPアドレスで返答する、171.68、.1、.10、また、ホストA.Thisに関しては、回答は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がHost Aのために仮製本をセットアップするよう要求する、(171.68 .1 外部アドレスと(b)がある.10は)Bind拒否者タイマを開始します。 NATは、外部アドレスを見つけるのに成功します。いつ、(たとえば、131.108に、一時的への.12が)付く.1はAを接待して、DNS_ALGは、Aのプライベート・アドレスを外部の割り当てられたアドレスに取り替えて、Cacheタイムアウトを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.
Host XがHost Aのアドレスを見つけるとき、XはAとのセッションを開始します、.1がIPが.12に131.108を扱う目的地を使用して このセッションのときに続くこのデータグラムとどんな他のものもNATによっていつものように翻訳されるでしょう。
Note, DNS_ALG changes only the response packets from the DNS server for Private domain.
注意、DNS_ALGは応答パケットだけをDNSサーバから兵士のドメインに変えます。
6.4. Reverse name lookups originated from external domain
6.4. 外部のドメインから溯源された名前ルックアップを逆にしてください。
This scenario builds on the previous case (section 6.3) by having host X in External.com perform a reverse name lookup on 131.108.1.12, which is host A's assigned external address. The following sequence of events take place.
External.comのホストXに逆名前ルックアップを131.108に実行させることによって、このシナリオは先の事件(セクション6.3)の上に建てられます。.1 .12 どれがAのホストものであるかは外部アドレスを割り当てました。 イベントの以下の系列は行われます。
1. Host X sends a UDP based inverse name lookup query (PTR record)
for "12.1.108.131.IN-ADDR.ARPA." to its local DNS server.
1. ホストXは"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. ルートサーバーは、Private.comのためにDNSサーバについて質問するのに順番にローカルのDNSサーバを参照します。
Srisuresh, et al. Informational [Page 24] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[24ページ]のRFC2694DNS拡張子
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がプライベート・アドレスが131.108の外部アドレスに.1を関連づけたのでNATを尋ねるために望んでいる、.12、ペイロード、取り替えを変更してください、131.108、.1、.12、.1は兵卒が.10に171.68を扱います。
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が.1が兵卒に関連している外部アドレスが172.19を扱う割り当てのためにNATを尋ねる、.10、ペイロード、取り替えを変更してください、171.68、.1、.10、.1が外部が.12に131.108を扱う割り当て
6. The DNS server in External.com replies to host X.
6. External.comのDNSサーバはホストXに答えます。
Note, DNS_ALG changes the query as well as response packets from DNS server for Private domain.
注意、DNS_ALGはDNSサーバからの応答パケットと同様に質問を兵士のドメインに変えます。
7. DNS-ALG limitations and Future Work
7. DNS-ALG制限とFuture Work
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
DNS_ALGは、個人的なドメインで安全なDNSがネームサーバであるとサポートすることができません。 すなわち、DMZの正式のDNSネームサーバから外界から発する質問までのSigned回答はDNS-ALGによって壊されるでしょう。 せいぜい、DNS-ALGは安全なdnssecデータを保護のないデータに変えることができるでしょう。 署名されるエンドノードの過酷なDNS回答はDNS_ALGによっていじられた回答を拒絶するかもしれません。 以来、DNSサーバには、来るのが質問が(すなわち、内部か外部)から来るところでそれがたぶんならなければならないわかる方法がありません。
Srisuresh, et al. Informational [Page 25] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[25ページ]のRFC2694DNS拡張子
resort to the common denomination of today's insecure DNS. Both are serious limitations to DNS_ALG. Zone transfers between DNS-SEC servers is also impacted the same way, if the transfer crosses address realms.
今日の不安定なDNSの一般的な宗派に訴えてください。 両方がDNS_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展開と終わりホストレゾルバと共に、本書では示された体系はうまくいかないでしょう。
8. Security Considerations
8. セキュリティ問題
If DNS packets are encrypted/authenticated per DNSSEC, then DNS_ALG will fail because it won't be able to perform payload modifications. Alternately, if packets must be preserved in an address realm, DNS_ALG will need to hold the secret key to decrypt/verify payload before forwarding packets to a different realm. For example, if DNS- ALG, NAT and IPsec gateway (providing secure tunneling service) are resident on the same device, DNS-ALG will have access to the IPsec security association keys. The preceding section, "DNS-ALG limitations and Future Work" has coverage on DNS_ALG security considerations.
DNSパケットが暗号化されるか、またはDNSSEC単位で認証されると、ペイロード変更を実行できないので、DNS_ALGは失敗するでしょう。 交互に、アドレス分野にパケットを保存しなければならないと、DNS_ALGは、異なった分野にパケットを送る前にペイロードについて解読するか、または確かめるために秘密鍵を持つ必要があるでしょう。 例えば、DNS- ALG、NAT、およびIPsecゲートウェイ(安全なトンネリングサービスを提供する)が同じデバイスで居住していると、DNS-ALGはIPsecセキュリティ協会キーに近づく手段を持つでしょう。 先行するセクションであり、「DNS-ALG制限とFuture Work」は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)用語と問題をネットワークでつなぐ」RFC2663、1999年8月。
[2] Egevang, K. and P. Francis, "The IP Network Address Translator
(NAT)", RFC 1631, May 1994.
[2] EgevangとK.とP.フランシス、「IPネットワークアドレス変換機構(NAT)」(RFC1631)は1994がそうするかもしれません。
[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.、deグルート、G.、およびE.リア)は「個人的なインターネットのための配分を扱います」、BCP5、RFC1918、1996年2月。
Srisuresh, et al. Informational [Page 26] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[26ページ]のRFC2694DNS拡張子
[4] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, November 1987.
[4]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[5] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[5]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[6] Reynolds J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[6] レイノルズJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[7] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", STD 3, RFC 1122, October 1989.
[7] ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[8] Braden, R., "Requirements for Internet Hosts -- Application and
Support", STD 3, RFC 1123, October 1989.
[8] ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[9] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[9] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[10] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
Behaviour Today", RFC 2101, February 1997.
[10]大工、B.、クロウクロフト、J.、およびY.Rekhter、「IPv4は今日ふるまいを扱う」RFC2101、1997年2月。
[11] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[11] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、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アップデート)におけるダイナミックなアップデート」RFC2136(1997年4月)。
[13] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
2137, April 1997.
[13] イーストレーク、1997年4月、D.、「安全なドメインネームシステムダイナミック・アップデート」RFC2137。
[14] Elz R. and R. Bush, "Clarifications to the DNS specification",
RFC 2181, July 1997.
[14]Elz R.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、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.が茂って、ブラドナーS.とM.は、パットンと、「セカンダリDNSサーバの選択と操作」です、RFC2182、1997年7月。
Srisuresh, et al. Informational [Page 27] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[27ページ]のRFC2694DNS拡張子
Authors' Addresses
作者のアドレス
Pyda Srisuresh 849 Erie Circle Milpitas, CA 95035 U.S.A.
円のミルピタス、Pyda Srisuresh849カリフォルニア95035米国エリー湖
Phone: +1 (408) 263-7527 EMail: srisuresh@yahoo.com
以下に電話をしてください。 +1 (408) 263-7527 メールしてください: srisuresh@yahoo.com
George Tsirtsis Internet Transport Group B29 Room 129 BT Laboratories Martlesham Heath IPSWICH Suffolk IP5 3RE England
ジョージTsirtsisインターネット輸送グループB29余地の129BT研究所MartleshamヒースイプスウィッチサフォークIP5 3REイギリス
Phone: +44 1473 640756 Fax: +44 1473 640709 EMail: george@gideon.bt.co.uk
以下に電話をしてください。 +44 1473 640756、Fax: +44 1473 640709はメールされます: george@gideon.bt.co.uk
Praveen Akkiraju cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
Praveen AkkirajuコクチマスSystems170の西タスマンDriveサンノゼ(カリフォルニア)95134米国
Phone: +1 (408) 526-5066 EMail: spa@cisco.com
以下に電話をしてください。 +1 (408) 526-5066 メールしてください: spa@cisco.com
Andy Heffernan Juniper Networks, Inc. 385 Ravensdale Drive. Mountain View, CA 94043 USA
アンディヘファーナンJuniperはInc.385レーベンズデールのドライブをネットワークでつなぎます。 マウンテンビュー、カリフォルニア94043米国
Phone: +1 (650) 526-8037 Fax: +1 (650) 526-8001 EMail: ahh@juniper.net
以下に電話をしてください。 +1 (650) 526-8037Fax: +1 (650) 526-8001 メールしてください: ahh@juniper.net
Srisuresh, et al. Informational [Page 28] RFC 2694 DNS extensions to NAT September 1999
Srisuresh、他 NAT1999年9月への情報[28ページ]のRFC2694DNS拡張子
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Srisuresh, et al. Informational [Page 29]
Srisuresh、他 情報[29ページ]
一覧
スポンサーリンク
