Network Working Group E. Warnicke
Request for Comments: 4183 Cisco Systems
Category: Informational September 2005
A Suggested Scheme for DNS Resolution of Networks and Gateways
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 [6] for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のために、このRFCのフィットネスの知識を否認し、公開する決定がIETF仕事との競合のためのIESGレビューとは別にIETFレビューに基づいていないことを指摘しています。 RFC Editorはその裁量でこの文書を公開することを選択しました。詳細については、RFC 3932 [6]を参照してください。
Abstract
抽象
This document suggests a method of using DNS to determine the network that contains a specified IP address, the netmask of that network, and the address(es) of first-hop routers(s) on that network. This method supports variable-length subnet masks, delegation of subnets on non-octet boundaries, and multiple routers per subnet.
この文書は、ネットワーク上の指定されたIPアドレスを含むネットワークは、そのネットワークのネットマスク、及び第一ホップルータ（複数可）のアドレスを決定するためにDNSを使用する方法を示唆しています。この方法は、可変長サブネットマスク、非オクテット境界上のサブネットの委任、およびサブネットごとに複数のルータをサポートしています。
As a variety of new devices are introduced to the network, many of them not traditional workstations or routers, there are requirements that the first-hop router provide some network service for a host. It may be necessary for a third-party server in the network to request some service related to the host from the first-hop router(s) for that host. It would be useful to have a standard mechanism for such a third-party device to find the first-hop router(s) for that host.
新しいデバイスの様々なネットワークに導入されると、それらの多くはない伝統的なワークステーションやルータは、ファーストホップルータがホストのためにいくつかのネットワークサービスを提供する要件があります。ネットワーク内のサードパーティのサーバがそのホストの最初のホップルータ（複数可）からホストに関連するいくつかのサービスを要求することが必要であり得ます。そのホストの最初のホップルータ（複数可）を見つけるために、このようなサードパーティのデバイスのための標準的なメカニズムを有することが有用であろう。
DNS-based mechanisms have been defined for the resolution of router addresses for classful networks (RFC 1035 [1]) and of subnets (RFC 1101 [2]). RFC 1101 suffers from a number of defects, chief among
DNSベースのメカニズムは、クラスフルネットワークのルータアドレスの解決のために定義されている（RFC 1035 [1]）とサブネットの（RFC 1101 [2]）。 RFC 1101は、欠陥の数、主のうちに苦しん
which are that it does not support variable-length subnet masks, which are commonly deployed in the Internet. The present document defines DNS-based mechanisms to cure these defects.
それは一般的にインターネットで展開されている可変長サブネットマスクをサポートしていないということです。本文書では、これらの欠陥を治癒するためにDNSベースのメカニズムを定義します。
Since the writing of RFC 1101, DNS mechanisms for dealing with classless networks have been defined, for example, RFC 2317 [3]. This document describes a mechanism that uses notation similar to that of RFC 2317 to specify a series of PTR records enumerating the subnets of a given network in the RFC 2317 notation. This lookup process continues until the contents of the PTR records are not an in-addr.arpa.-derived domain name. These terminal PTR record values are treated as the hostname(s) of the router(s) on that network. This RFC also specifies an extension to the method of RFC 2317 to support delegation at non-octet boundaries.
RFC 1101の書き込みので、クラスレスネットワークを扱うためのDNSメカニズムは、例えば、定義された、RFC 2317 [3]。この文書は、RFC 2317の表記で与えられたネットワークのサブネットを列挙PTRレコードの系列を指定するためにRFC 2317と同様の表記法を使用するメカニズムが記載されています。 PTRレコードの内容がインaddr.arpa.由来のドメイン名ではありませんまで、このルックアッププロセスが続行されます。これらの末端PTRレコードの値は、そのネットワーク上のルータ（複数可）のホスト名（複数可）として扱われます。このRFCはまた、非オクテット境界で委任をサポートするために、RFC 2317の方法に拡張子を指定します。
Using the Augmented BNF of RFC 2234 [4], we can describe a generic domain name for a network as follows:
RFC 2234の増補BNFを使用して、以下のように[4]、我々はネットワークのための一般的なドメイン名を記述することができます。
networkdomainname = maskedoctet "." *( decimaloctet / maskedoctet ".") "in-addr.arpa." maskedoctet = decimaloctet "-" mask mask = 1*2DIGIT ; representing a decimal integer value in the ; range 1-32 decimaloctet = 1*3DIGIT ; representing a decimal integer value in ; the range 0 through 255
networkdomainname = maskedoctet "" *（decimaloctet / maskedoctet ""） "in-addr.arpa。" maskedoctet = decimaloctet " - " マスクマスク= 1 * 2DIGIT。で10進数の整数値を表します。範囲1-32 decimaloctet = 1 * 3DIGIT。で10進数の整数値を表します。 255までの範囲0
By way of reference, an IPv4 CIDR notation network address would be written
参照により、IPv4のCIDR表記のネットワークアドレスが書き込まれることになります
IPv4CIDR = decimaloctet "." decimaloctet "." decimaloctet "." decimaloctet "/" mask
IPv4のCIDRは、小数点オクテット= ""小数オクテット「」小数オクテット「」 decimaloctet "/" マスク
A "-" is used as a delimiter in a maskedoctet instead of a "/" as in RFC 2317 out of concern about compatibility with existing DNS servers, many of which do not consider "/" to be a valid character in a hostname.
Aは「 - 」既存のDNSサーバとの互換性に関する懸念のうちRFC 2317のように、代わりに「/」のmaskedoctetで区切り文字として使用され、その多くは、ホスト名で有効な文字であることを「/」考えていません。
In RFC 2317, there is no mechanism for non-octet boundary delegation. Networks would be represented as being part of the domain of the next octet.
RFC 2317では、非オクテット境界委任のためのメカニズムはありません。ネットワークは、次のオクテットのドメインの一部として表されます。
Examples:
例：
10.100.2.0/26 -> 0-26.2.100.10.in-addr.arpa. 10.20.128.0/23 -> 128-23.20.10.in-addr.arpa. 10.192.0.0/13 -> 192-13.10.in-addr.arpa.
１０。１００。２。０／２６ ー＞ ０ー２６。２。１００。１０。いんーあっｄｒ。あｒぱ。 １０。２０。１２８。０／２３ ー＞ １２８ー２３。２０。１０。いんーあっｄｒ。あｒぱ。 １０。１９２。０。０／１３ ー＞ １９２ー１３。１０。いんーあっｄｒ。あｒぱ。
In the event that the entity subnetting does not actually own the network being subnetted on an octet break, a mechanism needs to be available to allow for the specification of those subnets. The mechanism is to allow the use of maskedoctet labels as delegation shims.
エンティティのサブネットが実際オクテット休憩にサブネット化されたネットワークを所有していないという場合には、この機構は、これらのサブネットの仕様を可能にするために利用できるようにする必要があります。メカニズムは、委任シムとしてmaskedoctetラベルの使用を可能にすることです。
For example, consider an entity A that controls a network 10.1.0.0/16. Entity A delegates to entity B the network 10.1.0.0/18. In order to avoid having to update entries for entity B whenever entity B updates subnetting, entity A delegates the 0-18.1.10.in-addr.arpa domain (with an NS record in A's DNS tables as usual) to entity B. Entity B then subnets off 10.1.0.0/25. It would provide a domain name for this network of 0-25.0.0-18.1.10.in-addr.arpa (in B's DNS tables).
たとえば、ネットワーク10.1.0.0/16を制御エンティティAを検討します。ネットワーク10.1.0.0/18 BエンティティにエンティティAは、デリゲート。たびにエンティティBの更新サブネットエンティティBのエントリを更新することを避けるために、エンティティA委譲（いつものようにAのDNSテーブルのNSレコードに）0-18.1.10.in-addr.arpaドメインエンティティB.エンティティにBは、10.1.0.0/25をオフサブネット。これは、（BのDNSテーブル内）0-25.0.0-18.1.10.in-addr.arpaのこのネットワークのドメイン名を提供することになります。
In order to speak about the non-octet boundary case more easily, it is useful to define a few terms.
より簡単に非オクテット境界のケースについて話をするためには、いくつかの用語を定義することが有用です。
Network domain names that do not contain any maskedoctets after the first (leftmost) label are hereafter referred to as canonical domain names for that network. 0-25.0.1.10.in-addr.arpa. is the canonical domain name for the network 10.1.0.0/25.
最初（一番左）ラベルの後に任意のmaskedoctetsが含まれていないネットワークのドメイン名は、今後、そのネットワークの標準的なドメイン名と呼ばれています。 0-25.0.1.10.in-addr.arpa。ネットワーク10.1.0.0/25のための正規のドメイン名です。
Network domain names that do contain maskedoctet labels after the first (leftmost) label can be reduced to a canonical domain name by dropping all maskedoctet labels after the first (leftmost) label. They are said to be reducible to the canonical network domain name. So for example 0-25.0.0-18.1.10.in-addr.arpa. is reducible to 0-25.0.1.10.in-addr.arpa. Note that a network domain name represents the same network as the canonical domain name to which it can be reduced.
最初（一番左）ラベルの後にmaskedoctetラベルを含まないネットワークドメイン名は最初（一番左）ラベルの後に、すべてのmaskedoctetラベルをドロップすることにより、正規のドメイン名に削減することができます。これらは、標準的なネットワークドメイン名に還元可能であると言われています。ですから、例えば0-25.0.0-18.1.10.in-addr.arpaため。 0-25.0.1.10.in-addr.arpaに還元可能です。ネットワークドメイン名は、それを低減することが可能に正規のドメイン名と同じネットワークを表すことに留意されたいです。
1. Take the initial IP address x.y.z.w and create a candidate network by assuming a 24-bit subnet mask. Thus, the initial candidate network is x.y.z.0/24.
1.最初のIPアドレスx.y.z.wを取り、24ビットのサブネットマスクを仮定することにより、候補ネットワークを作成します。したがって、最初の候補ネットワークがx.y.z.0 / 24です。
2. Given a candidate network of the form x.y.z.n/m create an in-addr.arpa candidate domain name:
2. in-addr.arpa候補ドメイン名を作成するフォームx.y.z.n / Mの候補ネットワークを考えます：
1. If the number of mask bits m is greater than or equal to 24
but less than or equal to 32, then the candidate domain name
is n-m.z.y.x.in-addr.arpa.
2. If the number of mask bits m is greater than or equal to 16 but less than 24, then the candidate domain name is z-m.y.x.in-addr.arpa.
2.マスクビットmの数がより大きいまたは16に等しいが24未満の場合には、候補ドメイン名はz-m.y.x.in-addr.arpaあります。
3. If the number of mask bits m is greater than or equal to 8 but less than 16, then the candidate domain name is y-m.x.in-addr.arpa.
3.マスクビットmの数が8以上であるが16未満の場合には、候補ドメイン名はy-m.x.in-addr.arpaあります。
4. The notion of fewer than 8 mask bits is not reasonable.
4未満の8ビットのマスクの概念は合理的ではありません。
3. Perform a DNS lookup for a PTR record for the candidate domain name.
3.候補ドメイン名のPTRレコードのDNSルックアップを実行します。
4. If the PTR records returned from looking up the candidate domain name are of the form of a domain name for a network as defined previously (Section 2), then for each PTR record reduce that returned domain name to the canonical form p1-q1.z1.y1.x1.in-addr.arpa. This represents a network x1.y1.z1.p1/q1.
以前に定義されている候補のドメイン名を検索から返されたPTRレコードは、ネットワークのドメイン名の形式である場合4.（第2節）は、その後、各PTRレコードのためにそれが正規の形式のP1-Q1にドメイン名を返さ減らします.z1.y1.x1.in-addr.arpa。これは、ネットワークx1.y1.z1.p1 / Q1を表します。
1. If one of the x1.y1.z1.p1/q1 subnets contains the original IP
address x.y.z.w, then the PTR record return becomes the new
candidate domain name. Repeat steps 3-4.
2. If none of the x1.y1.z1.p1/q1 subnets contain the original IP address x.y.z.w, then this process has failed.
2. x1.y1.z1.p1 / Q1サブネットのいずれも元のIPアドレスx.y.z.wが含まれていない場合、このプロセスは失敗しました。
5. If the PTR record(s) for the candidate network is not of the form of a network domain name, then they are presumed to be the hostname(s) of the gateway(s) for the subnet being resolved.
前記候補ネットワークのPTRレコード（単数または複数）は、次いで、それらが解決されるサブネットのゲートウェイ（S）のホスト名（S）であると推定され、ネットワークドメイン名の形式ではない場合。
6. If the PTR lookup fails (no PTR records are returned).
6. PTRルックアップが失敗した場合（何のPTRレコードが返されません）。
1. If no candidate network PTR lookup for this IP address has
succeeded in the past and the netmask for the last candidate
network was 24 or 16 bits long, then presume a netmask of 8
fewer bits for the candidate network and repeat steps 2-4.
2. If no candidate network PTR lookup for this IP address has succeeded in the past and the netmask of the last candidate network was not 24 or 16 bits long, then increase the netmask by 1 bit and repeat steps 2-4.
2.このIPアドレスのための候補ネットワークPTRルックアップは、過去に成功していないと、最後の候補ネットワークのネットマスクは24または16ビット長でなかった場合は、1ビットの繰り返しでネットマスクを増やす2-4を繰り返します。
3. If a candidate network PTR lookup for this IP address has succeeded in the past or the netmask of the last candidate network was 32 bits, then this process has failed.
3.このIPアドレスの候補ネットワークPTRルックアップは、過去に成功したか、最後の候補ネットワークのネットマスクは32ビットだった、そしてこのプロセスが失敗した場合。
7. Perform a DNS A record lookup for the domain name of the gateway to determine the IP number of the gateway.
7.ゲートウェイのIP番号を決定するためのゲートウェイのドメイン名のDNSのAレコード検索を実行します。
RFC 3513 [5] requires all IPv6 unicast addresses that do not begin with binary 000 have a 64-bit interface ID. From the point of view of identifying the last hop router for an IPv6 unicast address, this means that almost all hosts may be considered to live on a /64 subnet. Given the requirement that for any subnet there must be an anycast address for the routers on that subnet, the process described for IPv4 in this document can just as easily be achieved by querying the anycast address via SNMP. Therefore, this document does not speak to providing a DNS-based mechanism for IPv6.
RFC 3513 [5]バイナリ000で始まらないすべてのIPv6ユニキャストアドレスは、64ビットのインタフェースIDを持っている必要があります。 IPv6ユニキャストアドレスの最後のホップルータを識別するの観点から、これはほとんどすべてのホストが/ 64のサブネットに住んであると考えることができることを意味します。任意のサブネットにそのサブネット上のルータのエニーキャストアドレスが存在しなければならない要件を考えると、このドキュメントではIPv4の記載された方法は、同じように簡単にSNMP経由でエニーキャストアドレスを照会することによって達成することができます。したがって、このドキュメントはIPv6のDNSベースのメカニズムを提供することに話すことはありません。
Imagine we begin with the IP number 10.15.162.3.
我々はIP番号10.15.162.3で始まる想像してみてください。
1. Form a candidate network of 10.15.162.0/24.
1. 10.15.162.0/24の候補ネットワークを形成しています。
2. Form a domain name 0-24.162.15.10.in-addr.arpa.
2.ドメイン名0-24.162.15.10.in-addr.arpaを形成しています。
3. Look up the PTR records for 0-24.162.15.10.in-addr.arpa.
3. 0-24.162.15.10.in-addr.arpaのためのPTRレコードを検索します。
4. Suppose the lookup fails ( no PTR records returned ), then
4.その後、（何のPTRレコードが返されない）のルックアップに失敗したと仮定
5. Form a new candidate network 10.15.0.0/16.
5.新しい候補ネットワーク10.15.0.0/16を形成しています。
6. Form a domain name 0-16.15.10.in-addr.arpa.
6.ドメイン名0-16.15.10.in-addr.arpaを形成しています。
7. Look up the PTR records for 0-16.15.10.in-addr.arpa.
7. 0-16.15.10.in-addr.arpaのためのPTRレコードを検索します。
8. Lookup returns: 1. 0-17.15.10.in-addr.arpa. 2. 128-18.15.10.in-addr.arpa. 3. 192-18.15.10.in-addr.arpa.
8.検索が戻る：1. 0-17.15.10.in-addr.arpa。 2. 128-18.15.10.in-addr.arpa。 3. 192-18.15.10.in-addr.arpa。
9. So 10.15.0.0/16 is subnetted into 10.15.0.0/17, 10.15.128.0/18, and 10.15.192.0/18.
9. Soは10.15.0.0/16は10.15.0.0/17、10.15.128.0/18、および10.15.192.0/18にサブネット化されています。
10. Since 10.15.162.3 is in 10.15.128.0/18, the new candidate domain name is 128-18.15.10.in-addr.arpa.
10.15.162.3以来10が10.15.128.0/18であり、新たな候補ドメイン名は128-18.15.10.in-addr.arpaです。
11. Look up the PTR records for 128-18.15.10.in-addr.arpa.
11. 128-18.15.10.in-addr.arpaのためのPTRレコードを検索します。
12. Lookup returns 1. 128-19.128-18.15.10.in-addr.arpa. 2. 0-25.160.128-18.15.10.in-addr.arpa. 3. 128-25.160.128-18.15.10.in-addr.arpa. 4. 0-24.161.128-18.15.10.in-addr.arpa. 5. 162-23.128-18.15.10.in-addr.arpa.
12.ルックアップ1. 128-19.128-18.15.10.in-addr.arpaを返します。 2. 0-25.160.128-18.15.10.in-addr.arpa。 3. 128-25.160.128-18.15.10.in-addr.arpa。 4. 0-24.161.128-18.15.10.in-addr.arpa。 5. 162-23.128-18.15.10.in-addr.arpa。
13. The canonical network domains for these returned records are 1. 128-19.15.10.in-addr.arpa. 2. 0-25.160.15.10.in-addr.arpa. 3. 128-25.160.15.10.in-addr.arpa. 4. 0-24.161.15.10.in-addr.arpa. 5. 162-23.15.10.in-addr.arpa.
これらの返されたレコードの13標準的なネットワークドメインは1 128-19.15.10.in-addr.arpaです。 2. 0-25.160.15.10.in-addr.arpa。 3. 128-25.160.15.10.in-addr.arpa。 4. 0-24.161.15.10.in-addr.arpa。 5. 162-23.15.10.in-addr.arpa。
14. So the network 10.15.128.0/18 is subnetted into 10.15.128.0/19, 10.15.160.0/25, 10.15.160.128/25, 10.15.161.0/25, 10.15.162.0/ 23.
14.ように、ネットワーク10.15.128.0/18は10.15.128.0/19、10.15.160.0/25、10.15.160.128/25、10.15.161.0/25、10.15.162.0/ 23にサブネットれます。
15. Since 10.15.162.3 is in 10.15.162.0/23, the new candidate domain name is 162-23.128-18.15.10.in-addr.arpa.
10.15.162.3が10.15.162.0/23であるので15は、新しい候補ドメイン名は162-23.128-18.15.10.in-addr.arpaです。
16. Look up the PTR records for 162-23.128-18.15.10.in-addr.arpa.
16. 162-23.128-18.15.10.in-addr.arpaのためのPTRレコードを検索します。
17. Lookup returns: 1. gw1.example.net. 2. gw2.example.net.
17.参照を返します：1. gw1.example.netを。 2. gw2.example.net。
18. Look up the A records for gw1.example.net. and gw2.example.net.
18. gw1.example.netのためにAレコードを検索します。そしてgw2.example.net。
19. Lookup returns 1. gw1.example.net: 10.15.162.1 2. gw2.example.net: 10.15.162.2
19.ルックアップ1. gw1.example.netを返します：10.15.162.1 2. gw2.example.net：10.15.162.2
So the 10.15.162.3 is in network 10.15.162.0/23, which has gateways 10.15.162.1 and 10.15.162.2.
だから、10.15.162.3は、ゲートウェイ10.15.162.1と10.15.162.2を有し、ネットワーク10.15.162.0/23です。
The example of the lookup procedure (Section 4.3) would require DNS records as follows:
次のようにルックアップ手順（4.3節）の例では、DNSレコードが必要になります。
In entity A's DNS zone files: 0-16.15.10.in-addr.arpa. IN PTR 0-17.15.10.in-addr.arpa. 0-16.15.10.in-addr.arpa. IN PTR 128-18.15.10.in-addr.arpa. 0-16.15.10.in-addr.arpa. IN PTR 192-18.15.10.in-addr.arpa. 0-17.15.10.in-addr.arpa. IN NS ns1.example.org 128-18.15.10.in-addr.arpa. IN NS ns1.example.net 192-18.15.10.in-addr.arpa. IN NS ns1.example.com ns1.example.net IN A 10.15.0.50 ns1.example.org IN A 10.15.128.50 ns1.example.com IN A 10.15.192.50
エンティティAのDNSゾーンファイルで：0-16.15.10.in-addr.arpa。 PTR IN 0-17.15.10.in-addr.arpa。 0-16.15.10.in-addr.arpa。 PTRの128-18.15.10.in-addr.arpa、IN。 0-16.15.10.in-addr.arpa。 PTRの192-18.15.10.in-addr.arpa、IN。 0-17.15.10.in-addr.arpa。 NS ns1.example.org 128-18.15.10.in-addr.arpa、IN。 NS、IN ns1.example.net 192-18.15.10.in-addr.arpa。 NS ns1.example.com ns1.example.netのA 10.15.0.50 ns1.example.org、IN A 10.15.128.50 ns1.example.com 10.15.192.50のIn
In entity B's DNS zone files: 128-18.15.10.in-addr.arpa. IN PTR 128-19.128-18.15.10.in-addr.arpa. 128-18.15.10.in-addr.arpa. IN PTR 0-25.160.128-18.15.10.in-addr.arpa. 128-18.15.10.in-addr.arpa. IN PTR 128-25.160.128-18.15.10.in-addr.arpa. 128-18.15.10.in-addr.arpa. IN PTR 0-24.161.128-18.15.10.in-addr.arpa. 128-18.15.10.in-addr.arpa. IN PTR 162-23.128-18.15.10.in-addr.arpa. 162-23.128-18.15.10.in-addr.arpa. IN PTR gw1.example.net. 162-23.128-18.15.10.in-addr.arpa. IN PTR gw2.example.net. gw1.example.net. IN A 10.15.162.1 gw2.example.net. IN A 10.15.162.2
エンティティBのDNSゾーンファイルで：128-18.15.10.in-addr.arpa。 PTRの128-19.128-18.15.10.in-addr.arpa、IN。 128-18.15.10.in-addr.arpa。 PTR IN 0-25.160.128-18.15.10.in-addr.arpa。 128-18.15.10.in-addr.arpa。 PTRの128-25.160.128-18.15.10.in-addr.arpa、IN。 128-18.15.10.in-addr.arpa。 PTR IN 0-24.161.128-18.15.10.in-addr.arpa。 128-18.15.10.in-addr.arpa。 PTRの162-23.128-18.15.10.in-addr.arpa、IN。 162-23.128-18.15.10.in-addr.arpa。 PTRのgw1.example.net、IN。 162-23.128-18.15.10.in-addr.arpa。 PTRのgw2.example.net、IN。 gw1.example.net。 10.15.162.1 gw2.example.net、IN。 10.15.162.2、IN
Proper functioning of this method may required the cooperation of upstream network providers. Not all upstream network providers may wish to implement this method. If an upstream provider does not wish to implement this method, the method may still be used with an alternate domain suffix.
この方法の適切な機能は、上流のネットワークプロバイダの協力を必要とします。いないすべての上流のネットワークプロバイダは、このメソッドを実装することを望むかもしれません。上流プロバイダは、このメソッドを実装したくない場合は、この方法は、まだ代替ドメインサフィックスを使用することができます。
For example, if the upstream network provider of example.com did not wish to provide glue records in its branch of the in-addr.arpa. domain, then example.com might elect to use the suffix in-addr.example.com as an alternate domain suffix for that purpose.
たとえば、example.comの上流のネットワークプロバイダはin-addr.arpaの支店でグルーレコードを提供したくなかった場合。ドメインは、その後、example.comは、その目的のために代替ドメインサフィックスとしてサフィックスin-addr.example.comを使用することを選択することがあります。
For this reason, implementations of clients intending to use this method should use in-addr.arpa. as the default suffix, but allow for configuration of an alternate suffix.
このため、この方法を使用しようとするクライアントの実装はin-addr.arpa使用する必要があります。デフォルトの接尾辞としてではなく、別のサフィックスの設定を可能とします。
Any revelation of information to the public internet about the internal structure of your network may make it easier for nefarious persons to mount diverse attacks upon a network. Consequently, care should be exercised in deciding which (if any) of the DNS resource records described in this document should be made visible to the public internet.
ネットワークの内部構造についての公共のインターネットへの情報の任意の啓示は、それが簡単に極悪非道な人物がネットワーク上に多様な攻撃をマウントするために作ることがあります。そのため、注意が公共のインターネットに見えるようにする必要があり、この文書で説明するDNSリソースレコードのどの（もしあれば）を決定する際に行使しなければなりません。
[1] Mockapetris, P., "Domain Names - Implementation and Specficication", STD 13, RFC 1035, November 1987.
[1] Mockapetris、P.、 "ドメイン名 - 実装とSpecficication"、STD 13、RFC 1035、1987年11月。
[2] Mockapetris, P., "DNS Encoding of Network Names and Other Types", RFC 1101, April 1989.
[2] Mockapetris、P.、 "ネットワーク名および他のタイプのDNSエンコーディング"、RFC 1101、1989年4月を。
[3] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-ADDR.ARPA delegation", RFC 2317, March 1998.
[3] Eidnes、H.、デ・グルート、G.、およびP.いるVixie、 "クラスレスIN-ADDR.ARPA委任"、RFC 2317、1998年3月を。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[4]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[5] HindenとR.とS.デアリング、 "インターネットプロトコルバージョン6（IPv6）のアドレス指定アーキテクチャ"、RFC 3513、2003年4月。
[6] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004.
[6] Alvestrand、H.、 "IESGとRFC Editorのドキュメント：プロシージャ"、BCP 92、RFC 3932、2004年10月。
Author's Address
著者のアドレス
Edward A. Warnicke Cisco Systems Inc. 12515 Research Blvd., Building 4 Austin, TX 78759 USA
エドワードA. Warnickeシスコシステムズ12515リサーチ・ブルバード、4建物オースティン、TX 78759 USA
Phone: (919) 392-8489 EMail: eaw@cisco.com
電話：（919）392-8489 Eメール：eaw@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。