RFC5158 日本語訳
5158 6to4 Reverse DNS Delegation Specification. G. Huston. March 2008. (Format: TXT=25536 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Huston Request for Comments: 5158 APNIC Category: Informational March 2008
コメントを求めるワーキンググループG.ヒューストン要求をネットワークでつないでください: 5158年のAPNICカテゴリ: 情報の2008年3月
6to4 Reverse DNS Delegation Specification
6to4の逆のDNS委譲仕様
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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This memo describes the service mechanism for entering a delegation of DNS servers that provide reverse lookup of 6to4 IPv6 addresses into the 6to4 reverse zone file. The mechanism is based on a conventional DNS delegation service interface, allowing the service client to enter the details of a number of DNS servers for the delegated domain. In the context of a 6to4 reverse delegation, the client is primarily authenticated by its source address used in the delegation request, and is authorized to use the function if its IPv6 address prefix corresponds to an address from within the requested 6to4 delegation address block.
このメモは、6to4の逆のゾーンファイルの中に6to4 IPv6アドレスの逆のルックアップを供給するDNSサーバの委譲に入るためにサービスメカニズムについて説明します。 メカニズムは従来のDNS委譲サービスインタフェースに基づいています、サービスクライアントが多くのDNSサーバの詳細を代表として派遣されたドメインに入力するのを許可して。 6to4の逆の委譲の文脈では、クライアントは、委譲要求で使用されるソースアドレスによって主として認証されて、IPv6アドレス接頭語が要求された6to4委譲あて先ブロックからのアドレスに対応しているなら、機能を使用するのに権限を与えられます。
Huston Informational [Page 1] RFC 5158 6to4 Reverse DNS March 2008
2008年の[1ページ]RFC5158 6to4逆DNS行進の情報のヒューストン
1. Introduction
1. 序論
6to4 [RFC3056] defines a mechanism for allowing isolated IPv6 sites to communicate using IPv6 over the public IPv4 Internet. This is achieved through the use of a dedicated IPv6 global unicast address prefix. A 6to4 'router' can use its IPv4 address value in conjunction with this global prefix to create a local IPv6 site prefix. Local IPv6 hosts use this site prefix to form their local IPv6 address.
6to4[RFC3056]は、孤立しているIPv6サイトが交信するのを公共のIPv4インターネットの上でIPv6を使用することで許容するためにメカニズムを定義します。 これはひたむきなIPv6グローバルなユニキャストアドレス接頭語の使用で達成されます。 6to4'ルータ'は、ローカルのIPv6サイト接頭語を作成するのにこのグローバルな接頭語に関連してIPv4アドレス値を使用できます。 地元のIPv6ホストは、地元のIPv6アドレスを形成するのにこのサイト接頭語を使用します。
This address structure allows any site that is connected to the IPv4 Internet the ability to use IPv6 via automatically created IPv6 over IPv4 tunnels. The advantage of this approach is that it allows the piecemeal deployment of IPv6 using tunnels to traverse IPv4 network segments. A local site can connect to an IPv6 network without necessarily obtaining IPv6 services from its adjacent upstream network provider.
このアドレス構造はIPv4トンネルの上の自動的に作成されたIPv6を通してIPv6を使用する能力をIPv4インターネットにつなげられるどんなサイトにも許容します。 このアプローチの利点はトンネルを使用するIPv6のばらばらの展開がそれでIPv4ネットワークセグメントを横断できるということです。 必ず隣接している上流のネットワーク内の提供者からIPv6サービスを得るというわけではなくて、ローカル・サイトはIPv6ネットワークに接続できます。
As noted in [6to4-dns], the advantage of this approach is that: "it decouples deployment of IPv6 by the core of the network (e.g. Internet Service Providers or ISPs) from deployment of IPv6 at the edges (e.g. customer sites), allowing each site or ISP to deploy IPv6 support in its own time frame according to its own priorities. With 6to4, the edges may communicate with one another using IPv6 even if one or more of their ISPs do not yet provide native IPv6 service."
[6to4-dns]に述べられるように、このアプローチの利点は以下のことということです。 「縁(例えば、顧客サイト)でネットワーク(例えば、インターネットサービスプロバイダかISP)のコアのそばでIPv6の展開からIPv6の展開の衝撃を吸収します、それ自身のプライオリティに従って各サイトかISPが、それ自身の時間枠でIPv6がサポートであると配布するのを許容して。」 「6to4と共に、縁はお互いにそれらのISPのものか以上がまだネイティブのIPv6サービスを提供していなくてもIPv6を使用することでコミュニケートするかもしれません。」
The particular question here is the task of setting up a set of delegations that allows "reverse lookups" for this address space.
ここでの特定の質問はこのアドレス空間のために「逆のルックアップ」を許容する1セットの委譲をセットアップするタスクです。
"[This] requires that there be a delegation path for the IP
address being queried, from the DNS root to the servers for the
[DNS] zone which provides the PTR records for that IP address.
For ordinary IPv6 addresses, the necessary DNS servers and records
for IPv6 reverse lookups would be maintained by the each
organization to which an address block is delegated; the
delegation path of DNS records reflects the delegation of address
blocks themselves. However, for IPv6 addresses beginning with the
6to4 address prefix, the DNS records would need to reflect IPv4
address delegation. Since the entire motivation of 6to4 is to
decouple site deployment of IPv6 from infrastructure deployment of
IPv6, such records cannot be expected to be present for a site
using 6to4 - especially for a site whose ISP did not yet support
IPv6 in any form." [6to4-dns]
「IPのための委譲経路がアドレスであったならDNS根からサーバまでそのIPアドレスのためのPTR記録を提供する[DNS]ゾーンに質問されながら、そこでそれを必要とします[これ]。」 IPv6のための逆のルックアップが維持される普通のIPv6アドレス、必要なDNSサーバ、および記録、各組織、あて先ブロックがどれであるかへ代表として派遣します。 DNS記録の委譲経路はあて先ブロック自体の委譲を反映します。 しかしながら、6to4アドレス接頭語で始まるIPv6アドレスのために、DNS記録は、IPv4アドレス委譲を反映する必要があるでしょう。 「6to4の全体の動機がIPv6のインフラストラクチャ展開からIPv6のサイト展開の衝撃を吸収することであるので、そのような記録がサイトに特にISPがどんなフォームでもまだIPv6をサポートしていなかったサイトに6to4を使用することで存在させていることを期待できません。」 [6to4-dns]
Huston Informational [Page 2] RFC 5158 6to4 Reverse DNS March 2008
2008年の[2ページ]RFC5158 6to4逆DNS行進の情報のヒューストン
The desired characteristics of a reverse lookup delegation mechanism are that it:
逆のルックアップ委譲メカニズムの必要な特性がそれである、それ:
* is deployable with minimal overhead or tool development
* 配布可能が最小量のオーバーヘッドかツール開発と共にありますか?
* has no impact on existing DNS software and existing DNS
operations
* 既存のDNSソフトウェアと既存のDNS操作に影響力を全く持っていません。
* performs name lookup efficiently
* 効率的に名前ルックアップを実行します。
* does not compromise any DNS security functions
* どんなDNSセキュリティ機能もどんな感染にもしません。
2. Potential Approaches
2. ポテンシャル法
There are a number of approaches to this problem, ranging from a conventional explicit delegation structure to various forms of modified server behaviors that attempt to guess the location of non- delegated servers for fragments of this address space. These approaches have been explored in some detail in terms of their advantages and drawbacks in [6to4-dns], so only a summary of these approaches will be provided here.
この問題への多くのアプローチがあります、従来の明白な委譲構造から変更されたこのアドレス空間の断片のために非代表として派遣されたサーバの位置を推測するのを試みる様々な形式のサーバの振舞いまで及んで。 [6to4-dns]でそれらの利点と欠点で何らかの詳細にこれらのアプローチについて調査してあるので、これらのアプローチの概要だけをここに提供するでしょう。
2.1. Conventional Address Delegation
2.1. 従来のアドレス委譲
The problem with this form of delegation is the anticipated piecemeal deployment of 6to4 sites. The reason why an end site would use 6to4 is commonly that the upstream Internet Service Provider does not support an IPv6 transit service and the end site is using 6to4 to tunnel through to IPv6 connectivity. A conventional end site environment of this form would have the end site using provider-based IPv4 addresses, where the end site's IPv4 address is a more specific address block drawn from the upstream provider's address block, and the end site would have an entry in the upstream provider's reverse DNS zone file, or it would have authoritative local name servers that are delegated from the upstream provider's DNS zone. In the case of the 6to4 mapped IPv6 space, the upstream may not be providing any IPv6-based services at all, and therefore would not be expected to have a 6to4 reverse DNS delegation for its IPv4 address block. The general observation is that 6to4 IPv6 reverse DNS delegations cannot necessarily always precisely match the corresponding IPv4 reverse DNS delegations.
このフォームの委譲に関する問題は6to4サイトの予期されたばらばらの展開です。 端のサイトが6to4を使用する理由は一般的に、上流のインターネットサービスプロバイダが、IPv6トランジットがサービスであるとサポートしないということです、そして、端のサイトはIPv6の接続性に終えたトンネルに6to4を使用しています。 このフォームの従来の終わりのサイト環境には、端のサイトが端のサイトのIPv4アドレスが上流のプロバイダーのあて先ブロックから得られたより特定のあて先ブロックであるプロバイダーベースのIPv4住所を使用することであるでしょう、そして、端のサイトには、上流のプロバイダーの逆のDNSゾーンファイルにおけるエントリーがあるだろうか、またはそれに上流のプロバイダーのDNSゾーンから代表として派遣される正式の地方名サーバがあるでしょう。 写像しているIPv6スペース、上流がそうしない6to4の場合では、全くあらゆるIPv6ベースのサービスを前提としてください、そして、したがって、IPv4あて先ブロック6to4の逆のDNS委譲を持っていないと予想されるでしょう。 一般的な観測は6to4 IPv6の逆のDNS委譲が必ずいつも正確に対応するIPv4逆のDNS委譲に合うことができるというわけではないということです。
Huston Informational [Page 3] RFC 5158 6to4 Reverse DNS March 2008
2008年の[3ページ]RFC5158 6to4逆DNS行進の情報のヒューストン
Sub-delegations of IPv4 provider address space are not consistently recorded, and any 6to4 reverse zone operator would be required to undertake reverse zone delegations in the absence of reliable current address assignment information, undertaking a "hop over" of the upstream provider's address block. Similarly, a delegated entity may need to support the same "hop over" when undertaking further delegations in their reverse zone.
IPv4プロバイダーアドレス空間のサブ委譲は一貫して記録されません、そして、6to4逆のゾーンのオペレータが、信頼できる現在のアドレス課題情報(aが「跳ぶ」上流のプロバイダーのあて先ブロックの仕事)がないとき逆のゾーン委譲を引き受けるのに必要でしょう。 同様に、代表として派遣された実体はそれらの逆のゾーンでさらなる委譲を引き受けるとき同じくらいが「跳ぶ」サポートに必要とするかもしれません。
2.2. Guessing a Non-Delegated 6to4 Reverse Server
2.2. 非代表として派遣された6to4逆のサーバを推測します。
One way to avoid such unreliable delegations is to alter server behavior for reverse servers in this zone. Where no explicit delegation information exists in the zone file, the server could look up the in-addr.arpa domain for the servers for the equivalent IPv4 address root used in the 6to4 address. These servers could then be queried for the IPv6 PTR query.
そのような頼り無い委譲を避ける1つの方法はこのゾーンの逆のサーバのためのサーバの振舞いを変更することです。 どんな明白な委譲情報もゾーンファイルに存在していないところでは、サーバは6to4アドレスで使用される同等なIPv4アドレス根のためのサーバのためにaddr.arpaのドメインを見上げるかもしれません。 そして、IPv6 PTR質問のためにこれらのサーバについて質問できました。
The issues with fielding altered server behaviors for this domain are not to be taken lightly, and the delegation chain for IPv4 will not be the same for 6to4 in any case. An isolated 6to4 site uses a single IPv4 /32 address, and it is improbable that a single address would have explicit in-addr.arpa delegation. In other words, it is not likely that the delegation for IPv4 would parallel that of 6to4.
このドメインのための変えられたサーバの振舞いをさばく問題が軽く取られないことであり、どのような場合でも、IPv4のための委譲チェーンは6to4に同じにならないでしょう。 孤立している6to4サイトはただ一つのIPv4 /32アドレスを使用します、そして、ただ一つのアドレスにはaddr.arpaの明白な委譲があるのが、ありそうもないです。 言い換えれば、IPv4のための委譲は6to4のものに沿いそうにないでしょう。
2.3. Locating Local Servers at Reserved Addresses
2.3. 予約されたアドレスでローカルサーバの場所を見つけます。
Another approach uses an altered server to resolve non-delegated 6to4 reverse queries. The 6to4 query is decoded to recover the original 6to4 IP address. The site-specific part of the address is rewritten to a constant value, and this value is used as the target of a lookup query. This requires that a 6to4 site should reserve local addresses, and configure reverse servers on these addresses. Again, this is a weak approach in that getting the DNS to query non- delegated addresses is a case of generation of spurious traffic.
別のアプローチは、非代表として派遣された6to4逆の質問を決議するのに変えられたサーバを使用します。 6to4質問は、オリジナルの6to4IPアドレスを回復するために解読されます。 アドレスのサイト特有の部分は恒常価値に書き直されます、そして、この値はルックアップ質問の目標として使用されます。 これは、6to4サイトがローカルのアドレスを予約して、これらのアドレスで逆のサーバを構成するべきであるのを必要とします。 一方、これは、DNSに非代表として派遣されたアドレスについて質問させるのが、偽りのトラフィックの世代に関するケースであるので、弱いアプローチです。
2.4. Synthesized Responses
2.4. 統合応答
The final approach considered here is to synthesize an answer when no explicit delegation exists. This approach would construct a pseudo host name using the IPv6 query address as the seed. Given that the host name has no valid forward DNS mapping, then this becomes a case of transforming one invalid DNS object into another.
ここで考えられた最終進入はどんな明白な委譲も存在していないと答えを統合することです。 このアプローチは、種子としてIPv6質問アドレスを使用することで疑似ホスト名を構成するでしょう。 ホスト名にどんな有効な前進のDNSマッピングもないなら、これは1個の無効のDNSオブジェクトを別のものに変えるケースになります。
Huston Informational [Page 4] RFC 5158 6to4 Reverse DNS March 2008
2008年の[4ページ]RFC5158 6to4逆DNS行進の情報のヒューストン
2.5. Selecting a Reasonable Approach
2.5. 合理的なアプローチを選択します。
It would appear that the most reasonable approach from this set of potential candidates is to support a model of conventional standard delegation. The consequent task is to reduce the administrative overheads in managing the zone, supporting delegation of reverse zone files on a basis of providing a delegation capability directly to each 6to4 site.
このセットの有力候補からの最も合理的なアプローチが従来の標準の委譲のモデルをサポートすることであるように見えるでしょう。 結果のタスクはゾーンを管理しながら管理オーバーヘッドを下げることです、直接それぞれの6to4サイトに委譲能力を提供するベースの逆のゾーンファイルの委譲をサポートして。
3. 6to4 Networks Address Use
3. 6to4ネットワークは使用を扱います。
A 6to4 client network is an isolated IPv6 network composed as a set of IPv6 hosts and a dual stack (IPv4 and IPv6) local router connected to the local IPv6 network and the external IPv4 network.
6to4クライアントネットワークは1セットのIPv6ホストとデュアルスタック(IPv4とIPv6)ローカルルータがローカルのIPv6ネットワークと外部のIPv4ネットワークに接続したので構成された孤立しているIPv6ネットワークです。
An example of a 6to4 network is as follows:
6to4ネットワークの例は以下の通りです:
+-------------+
IPv6-in-IPv4 packets (A)| | IPv6 packets
------------------------| 6to4router |--------------------------
| | | | | | |
+-------------+ local IPv6 clients
+-------------+ IPv4のIPv6パケット(A)| | IPv6パケット------------------------| 6to4router|-------------------------- | | | | | | | +-------------+ 地元のIPv6クライアント
IPv4 network IPv6 network
IPv4ネットワークIPv6ネットワーク
Figure 1
図1
The IPv4 address used as part of the generation of 6to4 addresses for
the local IPv6 network is that of the external IPv4 network interface
address (labelled '(A)' in the above diagram). For example, if the
interface (A) has the IPv4 address 192.0.2.1, then the local IPv6
clients will use a common IPv6 address prefix of the form 2002:
{192.0.2.1}::/48 (or (2002:C000:201::/48 in hex notation). All the
local IPv6 clients share this common /48 address prefix, irrespective
of any local IPv4 address that such host may use if they are
operating in a dual stack mode.
ローカルのIPv6ネットワークに6to4アドレスの世代の一部として使用されるIPv4アドレスは外部のIPv4ネットワークインターフェース・アドレス(上のダイヤグラムで'(A)'とラベルされる)のものです。 インタフェース(A)でIPv4アドレスが例えばある、192.0、.2、.1、次に、地元のIPv6クライアントはフォーム2002の一般的なIPv6アドレス接頭語を使用するでしょう: {192.0.2.1}::/48、(. または、このコモン/48が彼らがデュアルスタックモードで作動しているならそのようなホストが使用するどんなローカルのIPv4アドレスの如何にかかわらず接頭語を扱うすべての(2002:C000:201: : 十六進法記法による/48)地方のIPv6クライアントシェア。
Huston Informational [Page 5] RFC 5158 6to4 Reverse DNS March 2008
2008年の[5ページ]RFC5158 6to4逆DNS行進の情報のヒューストン
An example of a 6to4 network with addressing:
アドレシングがある6to4ネットワークに関する例:
+-------------+
IPv4 network (A)| | IPv6 network
-------------------| 6to4router |-------------
192.0.2.1| | | | | interface identifier
+-------------+ 1A | | local IPv6 address
2002:C000:201::1A
| |
1B |
2002:C000:201::1B
|
1C
2002:C000:201::1C
+-------------+ IPv4ネットワーク(A)| | IPv6ネットワーク-------------------| 6to4router|------------- 192.0.2.1| | | | | インタフェース識別子+-------------+ 1A| | 地方のIPv6は2002:C000:201を扱います:、:1A| | 1B| 2002:C000:201:、:1B| 1 C2002:C000:201:、:1C
Figure 2
図2
4. Delegation Administration
4. 委譲政権
This specification uses a single delegation level in the 2.0.0.2.ip6.arpa zone (the ip6.arpa zone is specified in [RFC3596]), delegating zones only at the 48th bit position. This corresponds with individual delegations related to a single /32 IPv4 address, or the equivalent of a single 6to4 local site.
この仕様は2.0.0.2.ip6.arpaゾーンでただ一つの委譲レベルを使用します(ip6.arpaゾーンは[RFC3596]で指定されます)、48番目のビット位置だけでゾーンを代表として派遣して。 これはシングル/32IPv4アドレス、またはただ一つの6to4ローカル・サイトの同等物に関連する個々の委譲に対応しています。
The zone files containing the end site delegations are to be operated with a low TTL (configured to be a time value in the scale of hours rather than days or weeks), and updates for delegation requests in the 2.0.0.2.ipv6.arpa zone are to be made using dynamic DNS updates [RFC2136].
2.0.0.2.ipv6.arpaゾーンでの委譲要求のためのアップデートは終わりのサイト委譲を含むゾーンファイルが低いTTL(何日ものむしろ何時間ものスケールか週の間の時間的価値であることを構成する)と共に操作されることであり、ダイナミックなDNSアップデート[RFC2136]を使用することで作られていることです。
The delegation system is to be self-driven by clients residing within 6to4 networks. The 6to4 reverse DNS delegation function is to be accessible only by clients using 6to4 IPv6 source addresses, and the only delegation that can be managed is that corresponding to the /48 prefix of the IPv6 source address of the client.
委譲システムは6to4ネットワークの中に住んでいるクライアントによって自己に運転されることです。 6to4の逆のDNS委譲機能が単にクライアントが6to4 IPv6ソースアドレスを使用するのにおいてアクセスしやすいことであり、対処できる唯一の委譲がクライアントのIPv6ソースアドレスの/48接頭語にそんなに対応しています。
This service is to operate the delegation management service using web-based server access using Transport Layer Security (TLS) [RFC4346] (accessible via a "https:" URL). This is intended to ensure that the source address-driven delegation selection function cannot be disrupted through proxy caching of the web server's responses, and also to ensure that the delegation service cannot be readily mimicked.
このサービスは(aが「以下をhttpsする」というURLを通してアクセスしやすい)でTransport Layer Security(TLS)[RFC4346]を使用することでウェブベースのサーバアクセスを使用することで委譲経営指導を操作することです。 これは、ソースのアドレスやる気満々の委譲選択機能がウェブサーバーの応答のプロキシキャッシュで混乱させられることができないのを保証して、また、容易に委譲サービスをまねることができないのを保証することを意図します。
The service is to be found at https://6to4.nro.net
サービスは https://6to4.nro.net で見つけられることです。
Huston Informational [Page 6] RFC 5158 6to4 Reverse DNS March 2008
2008年の[6ページ]RFC5158 6to4逆DNS行進の情報のヒューストン
This service is implemented by web servers that are operated on a dual-stack IPv4 / IPv6 server, accessible via SSL. The web server's actions will be determined by the source address of the client. If the client uses a 6to4 source address, the server will present a delegation interface for the corresponding 6to4 reverse zone. Otherwise, the server will provide a description of the delegation process.
このサービスはデュアルスタックIPv4 / IPv6サーバで運転されて、SSLを通してアクセスしやすいウェブサーバーによって実装されます。 ウェブサーバーの動作はクライアントのソースアドレスで決定するでしょう。 クライアントが6to4ソースアドレスを使用すると、サーバは対応する6to4逆のゾーンに委譲インタフェースを提示するでしょう。 さもなければ、サーバは委譲プロセスの記述を提供するでしょう。
When accessed by a 6to4 source address, the interface presented by the delegation service is a conventional DNS delegation interface, allowing the client to enter the details of a number of DNS servers for the corresponding reverse domain. The targets of the DNS delegation are checked by the delegation manager using IPv4 and IPv6, according to the addresses of the targets, to ensure that they are responding, that they are configured consistently, and are authoritative for the delegated domain. If these conditions are met, the delegation details are entered into the zone at the primary master. In order to avoid the server being used as a denial of service platform, the server should throttle the number of DNS delegation requests made to any single IP address, and also throttle the number of redelegation requests for any single 6to4 zone.
6to4ソースアドレスによってアクセスされると、委譲サービスで提示されたインタフェースは従来のDNS委譲インタフェースです、クライアントが多くのDNSサーバの詳細を対応する逆のドメインに入力するのを許可して。 DNS委譲の目標は、目標のアドレスによると、確実に彼らが応じていて、一貫して構成されて、代表として派遣されたドメインに正式になるようにするのにIPv4とIPv6を使用することで委譲マネージャによってチェックされます。 これらの条件が満たされるなら、委譲の詳細はプライマリマスターでゾーンに入力されます。 サービスプラットホームの否定として使用されるサーバを避けるために、サーバは、どんなただ一つのIPアドレスにもされたDNS委譲要求の数を阻止して、また、どんなただ一つの6to4ゾーンを求める「再-委譲」要求の数も阻止するべきです。
In other cases the system provides diagnostic information to the client.
他の場合では、システムは診断情報をクライアントに提供します。
The benefits of this structure include a fully automated mode of operation. The service delivery is on demand and the system only permits self-operation of the delegation function.
この構造の利益は完全に自動化された運転モードを含んでいます。 要求にはサービス配送があります、そして、システムは委譲機能の自己操作を可能にするだけです。
The potential issues with this structure include:
この構造の潜在的問題は:
o Clients inside a 6to4 site could alter the delegation details
without the knowledge of the site administrator. It is noted that
this is intended for small-scale sites. Where there are potential
issues of unauthorized access to this delegation function, the
local site administrator could take appropriate access control
measures.
o 6to4サイトの中のクライアントはサイトの管理者に関する知識なしで委譲の詳細を変更できました。 これが小規模のサイトに意図することに注意されます。 この委譲機能への不正アクセスの潜在的問題があるところでは、ローカル・サイトの管理者は適切なアクセス制御対策を実施できました。
o IPv4 DHCP-based 6to4 sites, or any 6to4 site that uses
dynamically-assigned external IPv4 interface addresses, could
inherit nonsense reverse entries created by previous users of the
dynamically assigned address. In this case, the client site could
request delegation of the reverse zone as required. More
generally, given the potentially for inheritance of 'stale'
reverse DNS information in this context, in those cases where the
issues of potential inheritance of 'stale' reverse DNS information
is a concern, it is recommended that a 6to4 site either use a
static IPv4 address in preference to a dynamically-assigned
o IPv4 DHCPベースの6to4サイト、またはダイナミックに割り当てられた外部のIPv4インターフェース・アドレスを使用するどんな6to4サイトもダイナミックに割り当てられたアドレスの前のユーザによって作成されたナンセンス逆エントリーを引き継ぐかもしれません。 この場合、クライアントサイトは必要に応じて逆のゾーンの委譲を要求するかもしれません。 より多く、一般に当然のこと、潜在的に、この文脈、'聞き古した'逆のDNS情報の潜在的継承の問題が関心であるそれらのケースにおける'聞き古した'逆のDNS情報の継承に、6to4サイトがaに優先したIPv4アドレスがダイナミックに割り当てた静電気を使用するのは、お勧めです。
Huston Informational [Page 7] RFC 5158 6to4 Reverse DNS March 2008
2008年の[7ページ]RFC5158 6to4逆DNS行進の情報のヒューストン
address, or ensure that the reverse delegation information is
updated using the service mechanism described here upon each
dynamic address assignment event.
それぞれのダイナミックなアドレス課題イベントでここで説明されたサービスメカニズムを使用することで逆の委譲情報をアップデートするのを扱うか、または確実にしてください。
o The approach does not scale efficiently, as there is the potential
that the flat zone file may grow considerably. However, it is
noted that 6to4 is intended to be a transition mechanism useful
for a limited period of time in a limited context of an isolated
network where other forms of a tunnelled connection is not
feasible. It is envisaged that at some point the density of IPv6
adoption in stub network would provide adequate drivers for
widespread adoption of native IPv6 services, obviating the need
for continued scaling of 6to4 support services. An estimate of
the upper bound of the size of the 6to4 reverse delegation zone
would be of the order of millions of entries. It is also noted
that the value of a reverse delegation is a questionable
proposition and many deployment environments have no form of
reverse delegation.
o 平坦なゾーンファイルがかなり育てるかもしれない可能性があって、アプローチは効率的に比例しません。 しかしながら、6to4がトンネルを堀られた接続の他のフォームが可能でない孤立しているネットワークの限られた文脈の時間の限定期間の役に立つ変遷メカニズムであることを意図することに注意されます。 何らかのポイントでは、スタッブネットワークにおける、IPv6採用の密度がネイティブのIPv6サービスの広範囲の採用に適切なドライバーを提供するのが考えられます、6to4支援活動の継続的なスケーリングの必要性を取り除いて。 6to4の逆の委譲ゾーンのサイズの上限の見積りは何百万ものエントリーの注文のものでしょう。 また、逆の委譲の値が疑わしい提案であり、多くの展開環境には逆の委譲のフォームが全くないことに注意されます。
o It is also conceivable that an enterprise network could decide to
use 6to4 internally in some form of private context, with the
hosts only visible in internal DNS servers. In this mechanism the
reverse delegation, if desired, would need to be implemented in an
internal private (non-delegated) corresponding zone of the 6to4
reverse domain space.
o また、企業網が、何らかのフォームの個人的な関係で内部的に6to4を使用すると決めることができたのが想像できます、内部のDNSサーバだけで目に見えるホストと共に。 このメカニズムでは、望まれるなら、逆の委譲は、6to4の逆のドメインスペースの内部の個人的な(非代表として派遣された)対応するゾーンで実装される必要があるでしょう。
There may be circumstances where an IPv4 address controller wishes to "block" the ability for users of these addresses to use this 6to4 scheme. Scenarios that would motivate this concern would include situations when the IPv4 provider is also offering an IPv6 service, and native IPv6 should be deployed instead of 6to4. In such circumstances the 6to4 reverse zone operator should allow for such a 6to4 reverse delegation blocking function upon application to the delegation zone operator.
事情がIPv4アドレスコントローラがこれらのアドレスのユーザがこの6to4体系を使用する能力を「妨げたがっている」ところにあるかもしれません。 また、IPv4プロバイダーがIPv6サービスを提供しているとき、この関心を動機づけるシナリオが状況を含んでいるでしょう、そして、ネイティブのIPv6は6to4の代わりに配布されるべきです。 そのような事情では、6to4逆のゾーンのオペレータは委譲ゾーンのオペレータにとってアプリケーションでのそのような6to4の逆の委譲ブロッキング機能を考慮するべきです。
For a delegation to be undertaken the following conditions should hold:
委譲が引き受けられるために、以下の条件は成立するべきです:
o The 6to4 site must have configured a minimum of one primary and
one secondary server for the 6to4 IPv6 reverse address zone.
o 6to4サイトは最低1つのプライマリセカンダリサーバと1つのセカンダリサーバを6to4 IPv6の逆のアドレスゾーンに構成したに違いありません。
o At the time of the delegation request, the primary and secondary
servers must be online, reachable, correctly configured, and in a
mutually consistent state with respect to the 6to4 reverse zone.
In this context, "mutually consistent" implies the same SOA RR and
identical NS RRSets.
o 委譲要求時点で、プライマリの、そして、セカンダリのサーバは、オンラインで、届いて、正しく構成されていて、6to4に関する互いに一貫した状態でゾーンを逆にしなければなりません。 この文脈で「互いに一貫する、」 同じSOA RRと同じNS RRSetsを含意します。
Huston Informational [Page 8] RFC 5158 6to4 Reverse DNS March 2008
2008年の[8ページ]RFC5158 6to4逆DNS行進の情報のヒューストン
o The 6to4 reverse delegation service will only accept delegation
requests associated with the 6to4 source address of the requesting
client.
o 6to4の逆の委譲サービスは、委譲要求が要求しているクライアントの6to4ソースアドレスに関連していると受け入れるだけでしょう。
The approach described here, of a fully automated system driven by the site administrators of the 6to4 client networks, appears to represent an appropriate match of the operational requirements of managing reverse DNS domains for 6to4 addresses.
ここで説明されたアプローチは6to4クライアントネットワークのサイトの管理者によって動かされた完全に自動化されたシステムについて6to4アドレスのために逆のDNSドメインを管理する操作上の要件の適切なマッチを表すように見えます。
For maintenance of the reverse delegation zones the service maintains an email contact point for each active delegation, derived from the zone's SOA contact address (SOA RNAME), or explicitly entered in the delegation interface. This contact point would be informed upon any subsequent change of delegation details.
逆の委譲ゾーンのメインテナンスのために、サービスはゾーンのSOA連絡先(SOA RNAME)から派生したか、または明らかに委譲インタフェースに入れたそれぞれのアクティブな委譲のためのメール接点を維持します。 この接点は委譲の詳細のどんなその後の変化でも知識があるでしょう。
The 6to4 reverse DNS management system also undertakes a periodic sweep of all active delegations, so that each delegation is checked every 30 days. If the delegation fails this integrity check the email contact point is informed of the problem, and a further check is scheduled for 14 days later. If this second check fails, the delegation is automatically removed, and a further notice is issued to the contact point.
また、6to4の逆のDNSマネージメントシステムはすべてのアクティブな委譲の周期的な一掃を引き受けます、各委譲が30日間毎にチェックされるように。 委譲がこの保全チェックに失敗するなら、メール接点は問題において知識があります、そして、さらなるチェックは何日も後に14のために予定されています。 この2番目のチェックが失敗するなら、自動的に委譲を移します、そして、さらなる通知を接点に発行します。
5. Security Considerations
5. セキュリティ問題
This system offers a rudimentary level of assurance in attempting to ensure that delegation requests from a 6to4 site can only direct the delegation of the corresponding 6to4 reverse DNS domain and no other.
6to4サイトからの委譲要求が対応する6to4逆のDNSドメインと他のものでない委譲を指示できるだけであるのを保証するのを試みる際にこのシステムは初歩的なレベルを保証を提供します。
Address-based authentication is not a very robust method from a security perspective, as addresses can be readily spoofed. Accordingly, reverse delegation information does not provide reliable information in either validating a domain name or in validating an IP address, and no conclusions should be drawn from the presence or otherwise of a reverse DNS mapping for any IP address.
容易にアドレスを偽造することができるので、アドレスベースの認証はセキュリティ見解からの非常に強健なメソッドではありません。 それに従って、逆の委譲情報はドメイン名を有効にするか、どんな結論もIPアドレスが写像しますが、存在から引き出されるべきではありませんし、またそうでなければ、逆のDNSどんなIPアドレスのためにも写像するべきでない有効にするのに信頼できる情報を提供しません。
The service management interface allows a 6to4 client to insert any server name as a DNS server, potentially directing the delegation test system to make a DNS query to any nominated system. The server throttles the number of requests made to any single IP address to mitigate the attendant risk of a high volume of bogus DNS queries being generated by the server. For similar reasons, the server also throttles the number of redelegation requests for any single 6to4 zone.
6to4クライアントはDNSサーバとしてサービス管理インタフェースでどんなサーバー名も挿入できます、DNS質問をあらゆる指名システムにするよう潜在的に委譲テスト・システムに指示して。 サーバはサーバによって生成されるにせのDNS質問の高いボリュームの付き添いの危険を緩和するのがどんなただ一つのIPアドレスにもされた要求の数を阻止します。同様の理由で、また、サーバはどんなただ一つの6to4ゾーンを求める「再-委譲」要求の数も阻止します。
For a general threat analysis of 6to4, especially the additional risk of address spoofing in 2002::/16, see [RFC3964].
6to4の一般的な脅威分析、特に2002年に以下を偽造するアドレスの追加リスクのために:/、16 [RFC3964]を見てください。
Huston Informational [Page 9] RFC 5158 6to4 Reverse DNS March 2008
2008年の[9ページ]RFC5158 6to4逆DNS行進の情報のヒューストン
Section 4 notes that the local site administrator could take appropriate access control measures to prevent clients inside a 6to4 site performing unauthorized changes to the delegation details. This may be in the form of a firewall configuration, regarding control of access to the service from the interior of a 6to4 site, or a similar mechanism that enforces local access policies.
セクション4は、ローカル・サイトの管理者が6to4サイトの中のクライアントが委譲の詳細への未承認の変更を実行するのを防ぐ適切なアクセス制御対策を実施できたことに注意します。 これはファイアウォール構成の形にあるかもしれません、6to4サイトの内陸部からのサービスへのアクセスのコントロール、またはローカルのアクセス方針を実施する同様のメカニズムに関して。
6. IANA Considerations
6. IANA問題
The IANA has delegated the 2.0.0.2.ip6.arpa domain according to delegation instructions provided by the Internet Architecture Board.
インターネット・アーキテクチャ委員会によって提供された委譲指示に応じて、IANAは2.0.0.2.ip6.arpaドメインを代表として派遣しました。
7. Acknowledgements
7. 承認
The author acknowledges the prior work of Keith Moore in preparing a document that enumerated a number of possible approaches to undertake the delegation and discovery of reverse zones. The author acknowledges the assistance of George Michaelson and Andrei Robachevsky in preparing this document, and Peter Koch, Pekka Savola, Jun-ichiro Itojun Hagino, and Catherine Meadows for their helpful review comments.
作者は、書類を作成することにおける、多くの可能なアプローチを列挙したキース・ムーアの先の仕事が逆のゾーンの委譲と発見を引き受けると認めます。 作者は彼らの役立っているレビューコメントのためにこのドキュメント、ピーター・コッホ、ペッカSavola、6月-ichiro Itojun Hagino、およびキャサリン・メドースに準備させる際にジョージMichaelsonとアンドレイRobachevskyの支援を承諾します。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
Vixie、P.、トムソン、S.、Rekhter、Y.、およびJ.が縛った[RFC2136]、「ドメインネームシステムにおけるダイナミックなアップデート(DNSアップデート)」、RFC2136(1997年4月)。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] 大工とB.とK.ムーア、「IPv4 Cloudsを通したIPv6 Domainsの接続」、RFC3056、2001年2月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
[RFC3596] トムソンとS.とHuitemaとC.とKsinant、V.とM.Souissi、「バージョン6インチ、RFC3596、2003年10月をIPにサポートするDNS拡張子。」
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
8.2. Informative References
8.2. 有益な参照
[6to4-dns] Moore, K., "6to4 and DNS", Work in Progress, April 2003.
[6to4-dns] ムーアと、K.と、「6to4とDNS」は進歩、2003年4月に働いています。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for
6to4", RFC 3964, December 2004.
[RFC3964] SavolaとP.とC.パテル、「6to4"、RFC3964、2004年12月のためのセキュリティ問題。」
Huston Informational [Page 10] RFC 5158 6to4 Reverse DNS March 2008
2008年の[10ページ]RFC5158 6to4逆DNS行進の情報のヒューストン
Author's Address
作者のアドレス
Geoff Huston APNIC
ジェフヒューストンAPNIC
EMail: gih@apnic.net URI: http://www.apnic.net
メール: gih@apnic.net ユリ: http://www.apnic.net
Huston Informational [Page 11] RFC 5158 6to4 Reverse DNS March 2008
2008年の[11ページ]RFC5158 6to4逆DNS行進の情報のヒューストン
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Huston Informational [Page 12]
ヒューストンInformationalです。[12ページ]
一覧
スポンサーリンク
