Network Working Group P. Koch
Request for Comments: 3123 Universitaet Bielefeld
Category: Experimental June 2001
A DNS RR Type for Lists of Address Prefixes (APL RR)
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
The Domain Name System (DNS) is primarily used to translate domain names into IPv4 addresses using A RRs (Resource Records). Several approaches exist to describe networks or address ranges. This document specifies a new DNS RR type "APL" for address prefix lists.
ドメインネームシステム（DNS）は、主のRR（リソースレコード）を使用してIPv4アドレスにドメイン名を変換するために使用されます。いくつかのアプローチがネットワークまたはアドレス範囲を記述するために存在します。この文書では、アドレスプレフィクスリストのための新しいDNS RRタイプ「APL」を指定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Domain names herein are for explanatory purposes only and should not be expected to lead to useful information in real life [RFC2606].
ドメイン名は、ここだけの説明目的としたものであり、実際の生活[RFC2606]に有用な情報につながることが期待されてはなりません。
The Domain Name System [RFC1034], [RFC1035] provides a mechanism to associate addresses and other Internet infrastructure elements with hierarchically built domain names. Various types of resource records have been defined, especially those for IPv4 and IPv6 [RFC2874] addresses. In [RFC1101] a method is described to publish information about the address space allocated to an organisation. In older BIND versions, a weak form of controlling access to zone data was implemented using TXT RRs describing address ranges.
ドメインネームシステム[RFC1034]、[RFC1035]は階層的に構築されたドメイン名とアドレスと他のインターネットインフラストラクチャ要素を関連付けるためのメカニズムを提供します。リソースレコードの様々なタイプは、IPv4とIPv6 [RFC2874]アドレスの特に定義されています。 [RFC1101]での方法は、組織に割り当てられたアドレス空間についての情報を公開するために記載されています。古いBINDのバージョンでは、ゾーンデータへのアクセスを制御する弱いフォームは、アドレス範囲を記述するTXTのRRを用いて実施されました。
This document specifies a new RR type for address prefix lists.
この文書では、アドレスプレフィクスリストのための新しいRRタイプを指定します。
An APL record has the DNS type of "APL" and a numeric value of 42 [IANA]. The APL RR is defined in the IN class only. APL RRs cause no additional section processing.
APLレコードは、「APL」のDNSタイプと[IANA] 42の数値を有します。 APL RRは唯一のINクラスで定義されています。 APLのRRは追加のセクション処理を引き起こしません。
The RDATA section consists of zero or more items (<apitem>) of the form
RDATA部は、フォームの0個以上の項目（<apitem>）で構成され
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ADDRESSFAMILY |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| PREFIX | N | AFDLENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
/ AFDPART /
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
ADDRESSFAMILY 16 bit unsigned value as assigned by IANA (see IANA Considerations) PREFIX 8 bit unsigned binary coded prefix length. Upper and lower bounds and interpretation of this value are address family specific. N negation flag, indicates the presence of the "!" character in the textual format. It has the value "1" if the "!" was given, "0" else. AFDLENGTH length in octets of the following address family dependent part (7 bit unsigned). AFDPART address family dependent part. See below.
IANAによって割り当てられADDRESSFAMILY 16ビット符号なし値（IANAの考慮事項を参照）PREFIX 8ビットの符号なし2進符号化されたプレフィクス長。上限と下限と、この値の解釈は、アドレスファミリ固有のものです。 N否定フラグは、「！」の存在を示しますテキスト形式の文字。これは、もし「！」「1」の値を持ちます他に「0」、与えられました。次のアドレスファミリ依存部分（7ビット符号なし）のオクテットでAFDLENGTH長さ。 AFDPARTアドレスファミリに依存する部分。下記参照。
This document defines the AFDPARTs for address families 1 (IPv4) and 2 (IPv6). Future revisions may deal with additional address families.
このドキュメントは、アドレスファミリー1（IPv4）と2（IPv6）のためAFDPARTsを定義します。今後の改正は、追加のアドレスファミリを扱うことがあります。
The encoding of an IPv4 address (address family 1) follows the encoding specified for the A RR by [RFC1035], section 3.4.1.
IPv4アドレス（アドレスファミリー1）の符号化は、[RFC1035]、セクション3.4.1によってA RRに指定されたエンコーディングに従います。
PREFIX specifies the number of bits of the IPv4 address starting at the most significant bit. Legal values range from 0 to 32.
プレフィックスは、最上位ビットから始まるIPv4アドレスのビット数を指定します。有効な値は0から32の範囲です。
Trailing zero octets do not bear any information (e.g., there is no semantic difference between 10.0.0.0/16 and 10/16) in an address prefix, so the shortest possible AFDLENGTH can be used to encode it. However, for DNSSEC [RFC2535] a single wire encoding must be used by
ゼロオクテットの情報を担持していない後続のアドレスプレフィックスに（例えば、そこ10.0.0.0/16と10/16の間に意味的な違いはない）ので、最短AFDLENGTH、それを符号化するために使用することができます。しかし、DNSSEC [RFC2535]のための単一のワイヤエンコーディングはによって使用されなければなりません
all. Therefore the sender MUST NOT include trailing zero octets in the AFDPART regardless of the value of PREFIX. This includes cases in which AFDLENGTH times 8 results in a value less than PREFIX. The AFDPART is padded with zero bits to match a full octet boundary.
すべて。したがって、送信者は関係なく、PREFIXの値のAFDPARTゼロオクテットを末尾含んではいけません。これは、時間PREFIX未満の値で8つの結果をAFDLENGTHする場合を含みます。 AFDPARTフルオクテット境界に一致するようにゼロ・ビットが埋め込まれています。
An IPv4 AFDPART has a variable length of 0 to 4 octets.
IPv4のAFDPARTは0〜4オクテットの可変の長さを有します。
The 128 bit IPv6 address (address family 2) is encoded in network byte order (high-order byte first).
128ビットのIPv6アドレス（アドレスファミリー2）は、ネットワークバイト順（最初の上位バイト）で符号化されます。
PREFIX specifies the number of bits of the IPv6 address starting at the most significant bit. Legal values range from 0 to 128.
PREFIXは、最上位ビットから始まるIPv6アドレスのビット数を指定します。有効な値は0から128までの範囲。
With the same reasoning as in 4.1 above, the sender MUST NOT include trailing zero octets in the AFDPART regardless of the value of PREFIX. This includes cases in which AFDLENGTH times 8 results in a value less than PREFIX. The AFDPART is padded with zero bits to match a full octet boundary.
上記4.1と同様の理由で、送信者は関係なく、PREFIXの値のAFDPARTゼロオクテットを末尾含んではいけません。これは、時間PREFIX未満の値で8つの結果をAFDLENGTHする場合を含みます。 AFDPARTフルオクテット境界に一致するようにゼロ・ビットが埋め込まれています。
An IPv6 AFDPART has a variable length of 0 to 16 octets.
IPv6のAFDPARTは0〜16オクテットの可変長です。
The textual representation of an APL RR in a DNS zone file is as follows:
次のようにDNSゾーンファイル内のAPL RRのテキスト表現は、次のとおりです。
<owner> IN <TTL> APL {[!]afi:address/prefix}*
<所有者>の<TTL> APL {AFI [！]：アドレス/プレフィックス} *
The data consists of zero or more strings of the address family indicator <afi>, immediately followed by a colon ":", an address, immediately followed by the "/" character, immediately followed by a decimal numeric value for the prefix length. Any such string may be preceded by a "!" character. The strings are separated by whitespace. The <afi> is the decimal numeric value of that particular address family.
「：」、すぐにプレフィックス長の小数点以下の数値が続き、すぐに「/」文字が続くアドレス、データはすぐにコロンアドレスファミリインジケーター<AFI>のゼロ以上の文字列で構成されています。このような任意の文字列は「！」が先行することができますキャラクター。文字列は空白で区切られています。 <AFI>その特定のアドレスファミリの小数点以下の数値です。
An IPv4 address in the <address> part of an <apitem> is in dotted quad notation, just as in an A RR. The <prefix> has values from the interval 0..32 (decimal).
<アドレス>にIPv4アドレスは、<apitem>の部分は、ちょうどA RRと同様に、点線クワッド表記です。 <プレフィックス>は間隔0 32（10進数）の値を有します。
The representation of an IPv6 address in the <address> part of an <apitem> follows [RFC2373], section 2.2. Legal values for <prefix> are from the interval 0..128 (decimal).
<apitem>の<アドレス>部分におけるIPv6アドレスの表現は、[RFC2373]、セクション2.2に従います。 <プレフィックス>の有効な値は、間隔0 128（10進数）からです。
An APL RR with empty RDATA is valid and implements an empty list. Multiple occurrences of the same <apitem> in a single APL RR are allowed and MUST NOT be merged by a DNS server or resolver. <apitems> MUST be kept in order and MUST NOT be rearranged or aggregated.
空のRDATAとAPL RRが有効であり、空のリストを実装しています。単一のAPL RRで<apitem>同じの複数の発生が許可され、DNSサーバやリゾルバでマージされてはなりません。 <apitems>の順序で保管されなければならないと再配置または集約されてはなりません。
A single APL RR may contain <apitems> belonging to different address families. The maximum number of <apitems> is upper bounded by the available RDATA space.
単一APL RRは異なるアドレスファミリーに属する<apitems>が含まれていてもよいです。 <apitems>の最大数は、利用可能なRDATA空間によって境界上部です。
RRSets consisting of more than one APL RR are legal but the interpretation is left to the particular application.
複数のAPL RRからなる資源レコード集合は合法であるが、解釈は、特定のアプリケーションに任されます。
The APL RR defines a framework without specifying any particular meaning for the list of prefixes. It is expected that APL RRs will be used in different application scenarios which have to be documented separately. Those scenarios may be distinguished by characteristic prefixes placed in front of the DNS owner name.
APL RRは接頭辞のリストは、任意の特定の意味を指定せずにフレームワークを定義します。 APLのRRを個別に文書化する必要があり、異なるアプリケーションのシナリオで使用されることが期待されます。これらのシナリオでは、DNS所有者名の前に置か特性接頭辞によって区別することができます。
An APL application specification MUST include information on
APLのアプリケーション仕様は、上の情報を含まなければなりません
o the characteristic prefix, if any
特徴接頭O、もしあれば
o how to interpret APL RRSets consisting of more than one RR
Oつ以上のRRから成るAPLのRRセットを解釈する方法
o how to interpret an empty APL RR
O空のAPL RRを解釈する方法
o which address families are expected to appear in the APL RRs for that application
Oアドレスファミリは、そのアプリケーションのためのAPLのRRに表示されることが期待されています
o how to deal with APL RR list elements which belong to other address families, including those not yet defined
Oはまだ定義されていないものも含め、他のアドレスファミリーに属しているのAPL RRリスト要素に対処する方法
o the exact semantics of list elements negated by the "!" character
「！」によって否定リスト要素の正確な意味Oキャラクター
Possible applications include the publication of address ranges similar to [RFC1101], description of zones built following [RFC2317] and in-band access control to limit general access or zone transfer (AXFR) availability for zone data held in DNS servers.
可能な用途は、アドレスの公開が、と同様の範囲で含む[RFC1101]、[RFC2317]とDNSサーバに保持されたゾーンデータのための一般的なアクセスまたはゾーン転送（AXFR）の可用性を制限するためのインバンドアクセス制御次の組込みゾーンの説明。
The specification of particular application scenarios is out of the scope of this document.
特定のアプリケーションシナリオの仕様は、このドキュメントの範囲外です。
The following examples only illustrate some of the possible usages outlined in the previous section. None of those applications are hereby specified nor is it implied that any particular APL RR based application does exist now or will exist in the future.
以下の実施例は、前のセクションで概説した可能な用途のいくつかを示します。これらのアプリケーションのいずれもがここに指定されていないまたそれは、特定のAPL RRベースのアプリケーションは、現在存在しないか、将来的に存在することが暗示されます。
; RFC 1101-like announcement of address ranges for foo.example foo.example. IN APL 1:192.168.32.0/21 !1:192.168.38.0/28
;アドレスのRFC 1101のような発表はfoo.example foo.exampleのための範囲です。 APL IN 1：192.168.32.0/21 1：！192.168.38.0/28
; CIDR blocks covered by classless delegation 42.168.192.IN-ADDR.ARPA. IN APL ( 1:192.168.42.0/26 1:192.168.42.64/26 1:192.168.42.128/25 )
; CIDRブロックは、クラスレス委任42.168.192.IN-ADDR.ARPAでカバー。 APL IN（1：192.168.42.0/26 1：192.168.42.64/26 1：192.168.42.128/25）
; Zone transfer restriction _axfr.sbo.example. IN APL 1:127.0.0.1/32 1:172.16.64.0/22
;ゾーン転送制限_axfr.sbo.example。 APL IN 1：127.0.0.1/32 1：172.16.64.0/22
; List of address ranges for multicast multicast.example. IN APL 1:224.0.0.0/4 2:FF00:0:0:0:0:0:0:0/8
;アドレスのリストは、マルチキャストmulticast.exampleのための範囲です。 224.0.0.0/4 2：FF00：0：0：0：0：0：0：0/8 APL IN 1
Note that since trailing zeroes are ignored in the first APL RR the AFDLENGTH of both <apitems> is three.
末尾のゼロは、第一のAPL RRの両方のAFDLENGTHを無視しているので、<apitems> 3であることに留意されたいです。
Any information obtained from the DNS should be regarded as unsafe unless techniques specified in [RFC2535] or [RFC2845] were used. The definition of a new RR type does not introduce security problems into the DNS, but usage of information made available by APL RRs may compromise security. This includes disclosure of network topology information and in particular the use of APL RRs to construct access control lists.
[RFC2535]または[RFC2845]で指定された技術を使用した場合を除き、DNSから得られた任意の情報は安全でないとみなされるべきです。新しいRRタイプの定義は、DNSにセキュリティ上の問題を紹介しませんが、情報の利用は、セキュリティを損なう可能性APLのRRによって使用可能になりました。これは、ネットワークトポロジ情報の開示を含み、特にAPL RRの使用は、アクセス制御リストを構築します。
This section is to be interpreted as following [RFC2434].
このセクションでは、[RFC2434]を以下のように解釈されるべきです。
This document does not define any new namespaces. It uses the 16 bit identifiers for address families maintained by IANA in http://www.iana.org/numbers.html.
このドキュメントは、新しい名前空間を定義していません。それはhttp://www.iana.org/numbers.htmlにIANAによって維持アドレスファミリーのための16ビットの識別子を使用しています。
The IANA assigned numeric RR type value 42 for APL [IANA].
IANAは、APLの数値RRタイプ値42 [IANA]を割り当てます。
The author would like to thank Mark Andrews, Olafur Gudmundsson, Ed Lewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their review and constructive comments.
作者は彼らのレビューと建設的なコメントのためにマーク・アンドリュース、オラフルグドムンソン、エド・ルイス、トーマスNarten氏、エリックNordmarkと、そしてポール・ヴィクシーに感謝したいと思います。
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念および機能"、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装と仕様"、STD 13、RFC 1035、1987年11月。
[RFC1101] Mockapetris, P., "DNS Encoding of Network Names and Other Types", RFC 1101, April 1989.
[RFC1101] Mockapetris、P.、 "ネットワーク名および他のタイプのDNSエンコーディング"、RFC 1101、1989年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
"DNS仕様の明確化" [RFC2181]エルツ、R.とR.ブッシュ、RFC 2181、1997年7月。
[RFC2317] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
[RFC2317] Eidnes、H.、デ・グルート、G.とP.いるVixie、 "クラスレスIN-ADDR.ARPA委任"、BCP 20、RFC 2317、1998年3月。
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[RFC2373] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]イーストレイク、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]イーストレイク、D.とA. Panitz、 "予約トップレベルDNS名"、BCP 32、RFC 2606、1999年6月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]いるVixie、P.、グドムンソン、O.、イーストレイク、D.とB.ウェリントン、 "DNSのための秘密鍵トランザクション認証（TSIG）"、RFC 2845、2000年5月。
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[RFC2874]クロフォード、M.とC.のHuitemaは、RFC 2874、2000年7月 "DNSの拡張機能は、IPv6アドレスの集約とリナンバリングを支援します"。
[IANA] http://www.iana.org/assignments/dns-parameters
[IANA] http://www.iana.org/assignments/dns-parameters
Peter Koch Universitaet Bielefeld Technische Fakultaet D-33594 Bielefeld Germany
ビーレフェルト技術学部D-33594ビーレフェルト、ドイツのピーター・コッホ大学
Phone: +49 521 106 2902 EMail: pk@TechFak.Uni-Bielefeld.DE
電話：+49 521 106 2902 Eメール：pk@TechFak.Uni-Bielefeld.DE
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。