[要約] 要約：RFC 3123は、アドレスプレフィックスのリストを表すためのDNS RRタイプであるAPL RRについて説明しています。 目的：APL RRは、ネットワークアドレスのリストを効率的に表現し、DNSクエリの応答時間を短縮することを目的としています。
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)
アドレスプレフィックスのリストのDNS RRタイプ（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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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）は、主にドメイン名をRRS（リソースレコード）を使用して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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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]では、組織に割り当てられたアドレススペースに関する情報を公開する方法が説明されています。古いバインドバージョンでは、アドレス範囲を記述するTXT RRSを使用して、ゾーンデータへのアクセスを制御する弱い形式が実装されました。
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レコードには、DNSタイプの「APL」と42 [IANA]の数値があります。APL RRは、クラスのみで定義されています。APL RRSは追加のセクション処理を引き起こしません。
The RDATA section consists of zero or more items (<apitem>) of the form
rdataセクションは、フォームのゼロ以上のアイテム（<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.
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）のAFDPARTを定義しています。将来の改訂は、追加の住所ファミリを扱う場合があります。
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 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.
トレーリングゼロオクテットには、アドレスプレフィックスに情報が含まれていないため（たとえば、10.0.0.0/16と10/16の間にセマンティックな違いはありません）、可能な限り最短のafdlengthを使用してエンコードできます。ただし、DNSSEC [RFC2535]の場合、すべての人が単一のワイヤエンコードを使用する必要があります。したがって、送信者は、プレフィックスの値に関係なく、AFDPARTにトレーリングゼロオクテットを含めてはなりません。これには、Afdlength Times 8がプレフィックスよりも低い値になる場合が含まれます。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.
プレフィックスは、最も重要なビットから始まる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と同じ推論がある場合、送信者は、プレフィックスの値に関係なく、AFDPARTにトレーリングゼロオクテットを含めてはなりません。これには、Afdlength Times 8がプレフィックスよりも低い値になる場合が含まれます。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}*
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>は、その特定のアドレスファミリの10進数値です。
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).
<apitem>の<アドレス>の一部のIPv4アドレスは、A rrのように、点線のクワッド表記です。<Prefix>には、間隔0..32（小数）の値があります。
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に続きます。<prefix>の法的価値は、間隔0..128（小数）からです。
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で構成されるRRSetsは合法ですが、解釈は特定のアプリケーションに任されています。
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 RRSは、個別に文書化する必要があるさまざまなアプリケーションシナリオで使用されることが予想されます。これらのシナリオは、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 rrsetsを解釈する方法
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 RRSに登場することが期待されています
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 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.
o 「！」によって否定されたリスト要素の正確なセマンティクスキャラクター可能なアプリケーションには、[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
; 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 )
;Classless Dedimation 42.168.192.in-addr.arpaでカバーされているCIDRブロック。APL（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 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
Note that since trailing zeroes are ignored in the first APL RR the AFDLENGTH of both <apitems> is three.
トレーリングゼロは最初のAPL RRで無視されるため、両方の<Apitems>のafdlengthは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 RRSが利用できる情報の使用はセキュリティを損なう可能性があります。これには、ネットワークトポロジ情報の開示、特にアクセス制御リストを構築するためのAPL RRSの使用が含まれます。
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 [IANA]に数値RRタイプ値42を割り当てました。
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.
著者は、マーク・アンドリュース、オラファー・グドムンソン、エド・ルイス、トーマス・ナルテン、エリック・ノードマーク、ポール・ビクシーのレビューと建設的なコメントに感謝したいと思います。
[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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「DNS仕様の説明」、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.、de Groot、G。およびP. Vixie、「クラスレスIn-Addr.Arpa Delogation」、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. Deering、「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] Eastlake、D。、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606] Eastlake、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.、Gudmundsson、O.、Eastlake、D.およびB. Wellington、「DNSのシークレットキートランザクション認証」、RFC 2845、2000年5月。
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[RFC2874] Crawford、M。およびC. Huitema、「IPv6アドレスの集約と変更をサポートするDNS拡張」、RFC 2874、2000年7月。
[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
Peter Koch Universitaet Bielefeld Technische Fakultaet D-33594 Bielefeld Germany
Phone: +49 521 106 2902
EMail: pk@TechFak.Uni-Bielefeld.DE
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。