[要約] 要約：RFC 4183は、ネットワークとゲートウェイのDNS解決のための提案されたスキームについてのドキュメントです。 目的：このRFCの目的は、ネットワークとゲートウェイのDNS解決を効率的かつ一貫性のある方法で行うためのガイドラインを提供することです。
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
ネットワークとゲートウェイの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.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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は、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄し、公開する決定はIETFワークとの競合に関するIESGレビューとは別にIETFレビューに基づいていないことに注意してください。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。詳細については、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.
このドキュメントは、DNSを使用して、指定されたIPアドレス、そのネットワークのネットマスク、およびそのネットワーク上の最初のホップルーターのアドレス（ES）を含むネットワークを決定する方法を示唆しています。この方法は、可変長さのサブネットマスク、非オクテット境界上のサブネットの委任、およびサブネットあたりの複数のルーターをサポートします。
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 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ベースのメカニズムは、クラスフルネットワーク（RFC 1035 [1]）およびサブネット（RFC 1101 [2]）のルーターアドレスの解像度のために定義されています。RFC 1101は多くの欠陥に苦しんでおり、その中には、一般的にインターネットに展開される可変長さのサブネットマスクをサポートしていないという主なものがあります。現在のドキュメントでは、これらの欠陥を治すための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と同様の表記を使用して、RFC 2317表記の特定のネットワークのサブネットを列挙する一連のPTRレコードを指定するメカニズムを説明しています。このルックアッププロセスは、PTRレコードの内容がADDR.ARPA.由来のドメイン名にならないように継続します。これらの端子PTRレコード値は、そのネットワーク上のルーターのホスト名として扱われます。このRFCは、OCTET以外の境界での委任をサポートするRFC 2317の方法の拡張も指定します。
Using the Augmented BNF of RFC 2234 [4], we can describe a generic domain name for a network as follows:
RFC 2234 [4]の拡張BNFを使用して、ネットワークの一般的なドメイン名を次のように説明できます。
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
By way of reference, an IPv4 CIDR notation network address would be written
参照として、IPv4 CIDR表記ネットワークアドレスが記述されます
IPv4CIDR = decimaloctet "." decimaloctet "." decimaloctet "." decimaloctet "/" mask
ipv4cidr = decimaloctet "。"decimaloctet "。"decimaloctet "。"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サーバーとの互換性について懸念して「/」のように、「/」の代わりにマスコドクテットの区切り文字として使用されます。その多くは、「/」はホスト名の有効な文字であるとは考えていません。
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.
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を検討してください。エンティティAエンティティBへの代表ネットワーク10.1.0.0/18。エンティティBがサブネットを更新するたびにエンティティBのエントリを更新する必要がないようにするために、エンティティAは0-18.1.10.in-addr.arpaドメイン（通常どおりAのDNSテーブルのNSレコードがあります）をエンティティBに委任します。bその後、10.1.0.0/25のサブネット。0-25.0.0-18.1.10.in-addr.arpa（BのDNSテーブル）のこのネットワークのドメイン名を提供します。
In order to speak about the non-octet boundary case more easily, it is useful to define a few terms.
OCTET以外の境界ケースについてより簡単に話すために、いくつかの用語を定義することが役立ちます。
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.
最初の（左）ラベルの後にマスコドクテットを含まないネットワークドメイン名は、以降、そのネットワークの正規ドメイン名と呼ばれます。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: 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. フォームx.y.z.n/mの候補ネットワークが与えられた場合、adddr.arpa候補のドメイン名を作成します。1。マスクビットmの数が24以上で32以下の場合、候補ドメイン名は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.
4. 候補ドメイン名の検索から返されたPTRレコードが以前に定義されたネットワークのドメイン名の形式である場合（セクション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.
1. x1.y1.z1.p1/q1サブネットのいずれかが元のIPアドレスx.y.z.wを含む場合、PTRレコードリターンは新しい候補ドメイン名になります。手順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.
5. 候補ネットワークのPTRレコードがネットワークドメイン名の形式でない場合、それらは解決されるサブネットのゲートウェイのホスト名であると推定されます。
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.
1. このIPアドレスの候補ネットワークPTR検索が過去に成功し、最後の候補ネットワークのネットマスクが24または16ビットの長さであった場合、候補ネットワークのビットが8枚少なく、ステップ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番号を決定します。
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から64ビットインターフェイスIDを持っていることから始まらないすべてのIPv6ユニキャストアドレスが必要です。IPv6ユニキャストアドレスの最後のホップルーターを識別する観点から見ると、これはほとんどすべてのホストがA /64サブネットでライブと見なされる可能性があることを意味します。サブネットには、そのサブネットのルーターのanycastアドレスが必要であるという要件を考えると、このドキュメントでIPv4について説明したプロセスは、SNMPを介してAnycastアドレスをクエリすることで簡単に実現できます。したがって、このドキュメントでは、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. したがって、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. 10.15.162.3は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. 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。
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.
15. 10.15.162.3は10.15.162.0/23であるため、新しい候補ドメイン名は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のレコードを調べます。および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.0/23にあり、ゲートウェイ10.15.162.1および10.15.162.2があります。
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
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。128-18.15.10.in-addr.arpa。PTR 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。128-18.15.10.in-addr.arpa。PTR 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。162-23.128-18.15.10.in-addr.arpa。ptr gw1.example.netで。162-23.128-18.15.10.in-addr.arpa。ptr gw2.example.netで。gw1.example.net。10.15.162.1 gw2.example.net。10.15.162.2
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。、「ドメイン名 - 実装と仕様」、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.、de Groot、G。、およびP. Vixie、「クラスレスIn-Addr.Arpa Delegation」、RFC 2317、1998年3月。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[4] Crocker、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。and S. Deering、「インターネットプロトコルバージョン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エディタードキュメント：手順」、BCP 92、RFC 3932、2004年10月。
Author's Address
著者の連絡先
Edward A. Warnicke Cisco Systems Inc. 12515 Research Blvd., Building 4 Austin, TX 78759 USA
Edward A. Warnicke Cisco Systems Inc. 12515 Research Blvd.、Building 4 Austin、TX 78759 USA
Phone: (919) 392-8489 EMail: eaw@cisco.com
電話：（919）392-8489メール：eaw@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。