RFC2929 日本語訳
2929 Domain Name System (DNS) IANA Considerations. D. Eastlake 3rd, E.Brunner-Williams, B. Manning. September 2000. (Format: TXT=22454 bytes) (Obsoleted by RFC5395) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Eastlake, 3rd
Request for Comments: 2929 Motorola
BCP: 42 E. Brunner-Williams
Category: Best Current Practice Engage
B. Manning
ISI
September 2000
ワーキンググループのD.イーストレーク、コメントを求める第3要求をネットワークでつないでください: 2929モトローラBCP: 42E.ブルンナー-ウィリアムズカテゴリ: 最も良い現在の習慣はB.マニングISI2000年9月に従事します。
Domain Name System (DNS) IANA Considerations
ドメインネームシステム(DNS)IANA問題
Status of this Memo
このMemoの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
Internet Assigned Number Authority (IANA) parameter assignment considerations are given for the allocation of Domain Name System (DNS) classes, Resource Record (RR) types, operation codes, error codes, etc.
ドメインネームシステム(DNS)のクラス、Resource Record(RR)タイプ、命令コード、エラーコードなどの配分のためにISOCの機関の一つで(IANA)パラメタ課題問題を与えます。
Table of Contents
目次
1. Introduction................................................. 2 2. DNS Query/Response Headers................................... 2 2.1 One Spare Bit?.............................................. 3 2.2 Opcode Assignment........................................... 3 2.3 RCODE Assignment............................................ 4 3. DNS Resource Records......................................... 5 3.1 RR TYPE IANA Considerations................................. 6 3.1.1 Special Note on the OPT RR................................ 7 3.2 RR CLASS IANA Considerations................................ 7 3.3 RR NAME Considerations...................................... 8 4. Security Considerations...................................... 9 References...................................................... 9 Authors' Addresses.............................................. 11 Full Copyright Statement........................................ 12
1. 序論… 2 2. DNS質問/応答ヘッダ… 2 2.1 1つの予備ビット? 3 2.2Opcode課題… 3 2.3RCODE課題… 4 3. DNSリソース記録… 5 3.1 RRはIANA問題をタイプします… 6 3.1 .1の特別な注意、オンである、RRを選んでください… 7 3.2 RRクラスIANA問題… 7 3.3 RRは問題を命名します… 8 4. セキュリティ問題… 9つの参照箇所… 9人の作者のアドレス… 11 完全な著作権宣言文… 12
Eastlake, et al. Best Current Practice [Page 1] RFC 2929 DNS IANA Considerations September 2000
イーストレーク、他 最も良い現在の練習[1ページ]RFC2929DNS IANA問題2000年9月
1. Introduction
1. 序論
The Domain Name System (DNS) provides replicated distributed secure hierarchical databases which hierarchically store "resource records" (RRs) under domain names.
ドメインネームシステム(DNS)は階層的にドメイン名の下で「リソース記録」(RRs)を保存する模写された分配された安全な階層型データベースを提供します。
This data is structured into CLASSes and zones which can be independently maintained. See [RFC 1034, 1035, 2136, 2181, 2535] familiarity with which is assumed.
このデータは独自に維持できるCLASSesとゾーンに構造化されます。 どれがあるかで親しみが想定されるのを見てください[RFC1034、1035、2136、2181、2535]。
This document covers, either directly or by reference, general IANA parameter assignment considerations applying across DNS query and response headers and all RRs. There may be additional IANA considerations that apply to only a particular RR type or query/response opcode. See the specific RFC defining that RR type or query/response opcode for such considerations if they have been defined.
直接か、参照と、DNS質問の向こう側に適用される、一般的なIANAパラメタ課題問題と、応答ヘッダとすべてのRRsによるこのドキュメントカバー。 特定のRRタイプか質問/応答opcodeだけに適用される追加IANA問題があるかもしれません。 それらが定義されたなら特定のRFCがそのような問題のためにそのRRタイプか質問/応答opcodeを定義しているのを見てください。
IANA currently maintains a web page of DNS parameters. See <http://www.iana.org/numbers.htm>.
IANAは現在、1ウェブページのDNSパラメタを維持します。 <http://www.iana.org/numbers.htm>を見てください。
"IETF Standards Action", "IETF Consensus", "Specification Required", and "Private Use" are as defined in [RFC 2434].
"IETF Standards Action"、「IETFコンセンサス」、「仕様が必要である」、および「私用」が[RFC2434]で定義されるようにあります。
2. DNS Query/Response Headers
2. DNS質問/応答ヘッダ
The header for DNS queries and responses contains field/bits in the following diagram taken from [RFC 2136, 2535]:
DNS質問と応答のためのヘッダーは[RFC2136、2535]から取られた以下のダイヤグラムで分野/ビットを含んでいます:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode|AA|Tc|rd|RA| Z|西暦|CD| RCODE| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT/ZOCOUNT| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT/PRCOUNT| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT/UPCOUNT| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The ID field identifies the query and is echoed in the response so they can be matched.
ID分野は、それらを合わせることができるように質問を特定して、応答で反響されます。
Eastlake, et al. Best Current Practice [Page 2] RFC 2929 DNS IANA Considerations September 2000
イーストレーク、他 最も良い現在の練習[2ページ]RFC2929DNS IANA問題2000年9月
The QR bit indicates whether the header is for a query or a response.
QRビットは、ヘッダーが質問か応答に賛成するかを示します。
The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful only in queries or only in responses, depending on the bit. However, many DNS implementations copy the query header as the initial value of the response header without clearing bits. Thus any attempt to use a "query" bit with a different meaning in a response or to define a query meaning for a "response" bit is dangerous given existing implementation. Such meanings may only be assigned by an IETF Standards Action.
AA、TC、RD、RA、AD、およびCDビットは質問だけか応答だけでそれぞれ理論的に重要です、ビットによって。 しかしながら、ビットをきれいにしないで、多くのDNS実装が応答ヘッダの初期の値として質問ヘッダーをコピーします。 したがって、既存の実装を考えて、応答に異なった意味がある「質問」ビットを使用するか、または「応答」ビットのために質問意味を定義するどんな試みも危険です。 そのような意味はIETF Standards Actionによって割り当てられるだけであるかもしれません。
The unsigned fields query count (QDCOUNT), answer count (ANCOUNT), authority count (NSCOUNT), and additional information count (ARCOUNT) express the number of records in each section for all opcodes except Update. These fields have the same structure and data type for Update but are instead the counts for the zone (ZOCOUNT), prerequisite (PRCOUNT), update (UPCOUNT), and additional information (ARCOUNT) sections.
未署名の分野質問カウント(QDCOUNT)、答えカウント(ANCOUNT)、権威カウント(NSCOUNT)、および追加情報カウント(ARCOUNT)はUpdate以外のすべてのopcodesのために各セクションの記録の数を表します。 これらの分野は、Updateのために同じ構造とデータ型を持っていますが、代わりにゾーン(ZOCOUNT)(前提条件(PRCOUNT)、アップデート(UPCOUNT)、および追加情報(ARCOUNT)部)のためのカウントです。
2.1 One Spare Bit?
2.1 1つの予備ビット?
There have been ancient DNS implementations for which the Z bit being on in a query meant that only a response from the primary server for a zone is acceptable. It is believed that current DNS implementations ignore this bit.
質問でオンなZビットがゾーンへのプライマリサーバからの応答だけが許容できることを意味した古代のDNS実装がありました。 現在のDNS実装がこのビットを無視すると信じられています。
Assigning a meaning to the Z bit requires an IETF Standards Action.
Zビットに意味を割り当てるのはIETF Standards Actionを必要とします。
2.2 Opcode Assignment
2.2 Opcode課題
New OpCode assignments require an IETF Standards Action.
新しいOpCode課題はIETF Standards Actionを必要とします。
Currently DNS OpCodes are assigned as follows:
現在の、DNS OpCodesは以下の通り割り当てられます:
OpCode Name Reference
OpCode名前参照
0 Query [RFC 1035]
1 IQuery (Inverse Query) [RFC 1035]
2 Status [RFC 1035]
3 available for assignment
4 Notify [RFC 1996]
5 Update [RFC 2136]
6-15 available for assignment
0 課題に利用可能な質問[RFC1035]1IQuery(逆さのQuery)[RFC1035]の2Status[RFC1035]3課題4Notifyに利用可能な[RFC1996]5Update[RFC2136]6-15
Eastlake, et al. Best Current Practice [Page 3] RFC 2929 DNS IANA Considerations September 2000
イーストレーク、他 最も良い現在の練習[3ページ]RFC2929DNS IANA問題2000年9月
2.3 RCODE Assignment
2.3 RCODE課題
It would appear from the DNS header above that only four bits of RCODE, or response/error code are available. However, RCODEs can appear not only at the top level of a DNS response but also inside OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930]. The OPT RR provides an eight bit extension resulting in a 12 bit RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
それはRCODEの4ビット、または唯一の応答/エラーコードがそうである上のDNSヘッダーから利用可能に見えるでしょう。 しかしながら、RCODEsはDNS応答のトップレベルに現れるだけではなく、OPT RRs[RFC2671]、TSIG RRs[RFC2845]、およびTKEY RRs[RFC2930]の中にも現れることができます。 OPT RRは12ビットのRCODE分野をもたらす8ビットの拡大を提供します、そして、TSIGとTKEY RRsには、16ビットのRCODE分野があります。
Error codes appearing in the DNS header and in these three RR types all refer to the same error code space with the single exception of error code 16 which has a different meaning in the OPT RR from its meaning in other contexts. See table below.
DNSヘッダーとこれらの3つのRRタイプで現れるエラーコードはすべて、OPT RRに他の文脈での意味と異なった意味を持っているエラーコード16のただ一つの例外で同じエラーコードスペースについて言及します。 以下のテーブルを見てください。
RCODE Name Description Reference
Decimal
Hexadecimal
0 NoError No Error [RFC 1035]
1 FormErr Format Error [RFC 1035]
2 ServFail Server Failure [RFC 1035]
3 NXDomain Non-Existent Domain [RFC 1035]
4 NotImp Not Implemented [RFC 1035]
5 Refused Query Refused [RFC 1035]
6 YXDomain Name Exists when it should not [RFC 2136]
7 YXRRSet RR Set Exists when it should not [RFC 2136]
8 NXRRSet RR Set that should exist does not [RFC 2136]
9 NotAuth Server Not Authoritative for zone [RFC 2136]
10 NotZone Name not contained in zone [RFC 2136]
11-15 available for assignment
16 BADVERS Bad OPT Version [RFC 2671]
16 BADSIG TSIG Signature Failure [RFC 2845]
17 BADKEY Key not recognized [RFC 2845]
18 BADTIME Signature out of time window [RFC 2845]
19 BADMODE Bad TKEY Mode [RFC 2930]
20 BADNAME Duplicate key name [RFC 2930]
21 BADALG Algorithm not supported [RFC 2930]
22-3840 available for assignment
0x0016-0x0F00
3841-4095 Private Use
0x0F01-0x0FFF
4096-65535 available for assignment
0x1000-0xFFFF
RFC2136 7YXRRSet RR Set Existsではなく、そうするべきときのそうするべきでないときの5RCODE Name記述Reference Decimal Hexadecimal0NoErrorノーError RFC1035 1FormErr Format Error RFC1035 2ServFail Server Failure RFC1035の3のNXDomain Non目下のDomain RFC1035 4NotImp Not Implemented RFC1035Refused Query Refused RFC1035 6YXDomain Name Exists、存在するはずであるRFC2136 8NXRRSet RR SetがどんなRFCもしない、2136、9NotAuth Server Not Authoritative、ゾーンRFC2136 10NotZone Name; RFC2845 19BADMODE Bad TKEY Mode RFC2930 20のBADNAME Duplicateの主要な名前RFC2930 21BADALG Algorithmが0×1000課題0xFFFFに利用可能な課題の0×0016 0x0F00 3841-4095の兵士のUse 0x0F01-0x0FFF4096-65535に利用可能なRFC2930 22-3840をサポートしなかったタイムウィンドウから認識されたRFC2845 18BADTIME Signatureではなく、課題16BADVERS Bad OPTバージョンRFC2671 16BADSIG TSIG Signature Failure RFC2845 17BADKEY Keyに利用可能なゾーンRFC2136 11-15では、含まれていません。
Since it is important that RCODEs be understood for interoperability, assignment of new RCODE listed above as "available for assignment" requires an IETF Consensus.
RCODEsが相互運用性のために理解されているのが、重要であるので、「課題に利用可能である」として上に記載された新しいRCODEの課題はIETF Consensusを必要とします。
Eastlake, et al. Best Current Practice [Page 4] RFC 2929 DNS IANA Considerations September 2000
イーストレーク、他 最も良い現在の練習[4ページ]RFC2929DNS IANA問題2000年9月
3. DNS Resource Records
3. DNSリソース記録
All RRs have the same top level format shown in the figure below taken from [RFC 1035]:
すべてのRRsが同じ先端に以下の図に[RFC1035]から取った状態で示された書式を平らにさせます:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | ///名/| | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | タイプ| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | クラス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL| | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / /+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NAME is an owner name, i.e., the name of the node to which this resource record pertains. NAMEs are specific to a CLASS as described in section 3.2. NAMEs consist of an ordered sequence of one or more labels each of which has a label type [RFC 1035, 2671].
NAMEは所有者名、すなわち、このリソース記録が関係するノードの名前です。 NAMEsはセクション3.2で説明されるようにCLASSに特定です。 NAMEsはそれのそれぞれにはラベル形式[RFC1035、2671]がある1個以上のラベルの規則正しい系列から成ります。
TYPE is a two octet unsigned integer containing one of the RR TYPE codes. See section 3.1.
TYPEはRR TYPEの1つがコード化するa two八重奏符号のない整数含有です。 セクション3.1を見てください。
CLASS is a two octet unsigned integer containing one of the RR CLASS codes. See section 3.2.
CLASSはRR CLASSの1つがコード化するa two八重奏符号のない整数含有です。 セクション3.2を見てください。
TTL is a four octet (32 bit) bit unsigned integer that specifies the number of seconds that the resource record may be cached before the source of the information should again be consulted. Zero is interpreted to mean that the RR can only be used for the transaction in progress.
TTLは情報の源が再び参照されるべき前にキャッシュされたリソース記録が秒数を指定する符号のない整数であるかもしれませんが、噛み付かれた4八重奏(32ビット)です。 ゼロは、進行中のトランザクションにRRを使用できるだけであることを意味するために解釈されます。
RDLENGTH is an unsigned 16 bit integer that specifies the length in octets of the RDATA field.
RDLENGTHはRDATA分野の八重奏における長さを指定する16ビットの未署名の整数です。
Eastlake, et al. Best Current Practice [Page 5] RFC 2929 DNS IANA Considerations September 2000
イーストレーク、他 最も良い現在の練習[5ページ]RFC2929DNS IANA問題2000年9月
RDATA is a variable length string of octets that constitutes the resource. The format of this information varies according to the TYPE and in some cases the CLASS of the resource record.
RDATAはリソースを構成する八重奏の可変長ストリングです。 TYPEといくつかの場合リソース記録のCLASSによると、この情報の形式は異なります。
3.1 RR TYPE IANA Considerations
3.1 RRはIANA問題をタイプします。
There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs, and MetaTYPEs.
RR TYPE番号の3つの副カテゴリがあります: データTYPEs、QTYPEs、およびMetaTYPEs。
Data TYPEs are the primary means of storing data. QTYPES can only be used in queries. Meta-TYPEs designate transient data associated with an particular DNS message and in some cases can also be used in queries. Thus far, data TYPEs have been assigned from 1 upwards plus the block from 100 through 103 while Q and Meta Types have been assigned from 255 downwards (except for the OPT Meta-RR which is assigned TYPE 41). There have been DNS implementations which made caching decisions based on the top bit of the bottom byte of the RR TYPE.
データTYPEsはデータを保存するプライマリ手段です。 質問にQTYPESを使用できるだけです。 メタ-TYPEsは特定のDNSメッセージに関連している一時的なデータを指定して、また、いくつかの場合、質問に使用できます。 これまでのところ、データTYPEsは1から上向きに割り当てられました、そして、Qである間の100〜103でのブロックとMeta Typesは255から下向き(TYPE41が割り当てられるOPT Meta-RRを除いて)に割り当てられました。 RR TYPEの下部バイトのトップビットに基づいてキャッシュ決定をしたDNS実装がありました。
There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG [RFC 2845], and TKEY [RFC 2930].
現在、割り当てられた3Meta-TYPEsがあります: [RFC2671]、TSIG[RFC2845]、およびTKEY[RFC2930]を選んでください。
There are currently five QTYPEs assigned: * (all), MAILA, MAILB, AXFR, and IXFR.
現在、割り当てられた5QTYPEsがあります: * (すべて), MAILA、MAILB、AXFR、およびIXFR。
Considerations for the allocation of new RR TYPEs are as follows:
新しいRR TYPEsの配分のための問題は以下の通りです:
Decimal
Hexadecimal
10進16進
0
0
0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
2535] and in other circumstances and must never be allocated
for ordinary use.
0×0000--TYPEゼロを特別なインディケータとしてSIG RR[RFC2535]と他の事情で使用して、普通の使用のために決して割り当ててはいけません。
1 - 127
0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
TYPEs by IETF Consensus.
1--127 この範囲にTYPEsのままで残っている0×0001(0x007F)はデータTYPEsのためにIETF Consensusによって割り当てられます。
128 - 255
0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
Meta TYPEs by IETF Consensus.
128--、255、0×0080、--0x00FF--この激怒での残っているTYPEsはQとMeta TYPEsのためにIETF Consensusによって割り当てられます。
256 - 32767
0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF
Consensus.
0×0100(0x7FFF)がIETF Consensusによるデータ、Q、またはMeta TYPE使用のために割り当てた256--32767。
Eastlake, et al. Best Current Practice [Page 6] RFC 2929 DNS IANA Considerations September 2000
イーストレーク、他 最も良い現在の練習[6ページ]RFC2929DNS IANA問題2000年9月
32768 - 65279
0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
[RFC2434]で定義される32768--65279 0×8000(0xFEFF)仕様Required。
65280 - 65535
0xFF00 - 0xFFFF - Private Use.
65280--65535 0xFF00--0xFFFF--私用。
3.1.1 Special Note on the OPT RR
3.1.1 特別な注意、オンである、RRを選んでください。
The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its primary purpose is to extend the effective field size of various DNS fields including RCODE, label type, flag bits, and RDATA size. In particular, for resolvers and servers that recognize it, it extends the RCODE field from 4 to 12 bits.
OPT(OPTion)RR(No.41)は[RFC2671]で指定されます。 プライマリ目的はRCODE、ラベル形式、フラグビット、およびRDATAサイズを含む様々なDNS分野の有効磁界サイズを広げることです。 それを認識するレゾルバとサーバのために特に、それは4〜12ビットのRCODE分野を広げています。
3.2 RR CLASS IANA Considerations
3.2 RRクラスIANA問題
DNS CLASSes have been little used but constitute another dimension of the DNS distributed database. In particular, there is no necessary relationship between the name space or root servers for one CLASS and those for another CLASS. The same name can have completely different meanings in different CLASSes although the label types are the same and the null label is usable only as root in every CLASS. However, as global networking and DNS have evolved, the IN, or Internet, CLASS has dominated DNS use.
DNS CLASSesは少ししか使用されていませんが、DNS分散データベースの別次元を構成します。 特に、1CLASSのための名前スペースかルートサーバーと別のCLASSのためのそれらとのどんな必要な関係もありません。 ラベル形式は同じです、そして、ヌルラベルは単に根としてあらゆるCLASSで使用可能ですが、同じ名前は異なったCLASSesに完全に異なった意味を持つことができます。 しかしながら、グローバルなネットワークとDNSが発展したとき、IN、またはインターネット、CLASSがDNS使用を支配しました。
There are two subcategories of DNS CLASSes: normal data containing classes and QCLASSes that are only meaningful in queries or updates.
DNS CLASSesの2つの副カテゴリがあります: 質問かアップデートだけで重要なクラスとQCLASSesを含む正常なデータ。
The current CLASS assignments and considerations for future assignments are as follows:
将来の課題のための現在のCLASS課題と問題は以下の通りです:
Decimal
Hexadecimal
10進16進
0
0
0x0000 - assignment requires an IETF Standards Action.
0×0000--課題はIETF Standards Actionを必要とします。
1
0x0001 - Internet (IN).
1 0×0001--インターネット(IN)。
2
0x0002 - available for assignment by IETF Consensus as a data CLASS.
2 0×0002--IETF Consensusによる課題に、データCLASSとして、利用可能です。
3
0x0003 - Chaos (CH) [Moon 1981].
3 0×0003--カオス(CH)[1981にお尻を出します]。
4
0x0004 - Hesiod (HS) [Dyer 1987].
4 0×0004--ヘシオドス(HS)[紺屋1987]。
Eastlake, et al. Best Current Practice [Page 7] RFC 2929 DNS IANA Considerations September 2000
イーストレーク、他 最も良い現在の練習[7ページ]RFC2929DNS IANA問題2000年9月
5 - 127
0x0005 - 0x007F - available for assignment by IETF Consensus as data
CLASSes only.
5--127 0×0005--0x007F--IETF Consensusによる課題に、データCLASSesだけとして、利用可能です。
128 - 253
0x0080 - 0x00FD - available for assignment by IETF Consensus as
QCLASSes only.
128--253 0×0080--0x00FD--IETF Consensusによる課題に、QCLASSesだけとして、利用可能です。
254
0x00FE - QCLASS None [RFC 2136].
254 0x00FE--QCLASS、なし[RFC2136]。
255
0x00FF - QCLASS Any [RFC 1035].
255 0x00FF--QCLASS、いくらか[RFC1035]。
256 - 32767
0x0100 - 0x7FFF - assigned by IETF Consensus.
0×0100(0x7FFF)がIETF Consensusで割り当てた256--32767。
32768 - 65280
0x8000 - 0xFEFF - assigned based on Specification Required as defined
in [RFC 2434].
0×8000(0xFEFF)が[RFC2434]で定義されるSpecification Requiredに基づいて割り当てた32768--65280。
65280 - 65534
0xFF00 - 0xFFFE - Private Use.
65280--65534 0xFF00--0xFFFE--私用。
65535
0xFFFF - can only be assigned by an IETF Standards Action.
65535 0xFFFF--IETF Standards Actionは割り当てることができるだけです。
3.3 RR NAME Considerations
3.3 RR名前問題
DNS NAMEs are sequences of labels [RFC 1035]. The last label in each NAME is "ROOT" which is the zero length label. By definition, the null or ROOT label can not be used for any other NAME purpose.
DNS NAMEsはラベル[RFC1035]の系列です。 各NAMEにおける最後のラベルはゼロ・レングスラベルである「根」です。 定義上、いかなる他のNAME目的にもヌルかROOTラベルを使用できません。
At the present time, there are two categories of label types, data labels and compression labels. Compression labels are pointers to data labels elsewhere within an RR or DNS message and are intended to shorten the wire encoding of NAMEs. The two existing data label types are sometimes referred to as Text and Binary. Text labels can, in fact, include any octet value including zero octets but most current uses involve only [US-ASCII]. For retrieval, Text labels are defined to treat ASCII upper and lower case letter codes as matching. Binary labels are bit sequences [RFC 2673].
現在に、ラベル形式、データラベル、および圧縮ラベルの2つのカテゴリがあります。 圧縮ラベルは、RRかDNSメッセージの中のほかの場所のデータラベルへの指針であり、NAMEsのワイヤコード化を短くすることを意図します。 2つの既存のデータラベル形式が時々TextとBinaryと呼ばれます。 事実上、テキストラベルは大部分以外の現在の用途が伴わない八重奏[米国-ASCII]だけを全く含むどんな八重奏値も含むことができます。 検索において、Textラベルは、マッチングとしてASCII大文字と小文字レター・コードを扱うために定義されます。 2進のラベルは噛み付いている系列[RFC2673]です。
IANA considerations for label types are given in [RFC 2671].
ラベル形式のための問題が[RFC2671]で与えられているIANA。
Eastlake, et al. Best Current Practice [Page 8] RFC 2929 DNS IANA Considerations September 2000
イーストレーク、他 最も良い現在の練習[8ページ]RFC2929DNS IANA問題2000年9月
NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon 1981] CLASSes are essentially for local use. The IN or Internet CLASS is thus the only DNS CLASS in global use on the Internet at this time.
NAMEsはCLASSに地方です。 ヘシオドス[紺屋1987]とChaos[1981にお尻を出す]CLASSesは本質的には地方の使用のためのものです。 その結果、このとき、INかインターネットCLASSがインターネットにおけるグローバルな使用で唯一のDNS CLASSです。
A somewhat dated description of name allocation in the IN Class is given in [RFC 1591]. Some information on reserved top level domain names is in Best Current Practice 32 [RFC 2606].
IN Classでの配分が[RFC1591]で与えられている名前のいくらか時代遅れの記述。 予約された最上位ドメイン名の何らかの情報がBest Current Practice32[RFC2606]にあります。
4. Security Considerations
4. セキュリティ問題
This document addresses IANA considerations in the allocation of general DNS parameters, not security. See [RFC 2535] for secure DNS considerations.
このドキュメントはセキュリティではなく、一般的なDNSパラメタの配分における問題をIANAに扱います。 安全なDNS問題に関して[RFC2535]を見てください。
References
参照
[Dyer 1987] Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
Plan - Name Service, April 1987,
[紺屋1987] 紺屋、S.、およびF.シュー、「ヘシオドス」はアティナの技術的なプランを映し出します--1987年4月、サービスを命名してください。
[Moon 1981] D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
Institute of Technology Artificial Intelligence
Laboratory, June 1981.
[1981にお尻を出します] D.月、"Chaosnet"、A.I.メモ628、マサチューセッツ工科大学人工知能研究所、1981年6月。
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
Mockapetris、[RFC1034]P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
Mockapetris、[RFC1035]P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC 1591] Postel, J., "Domain Name System Structure and
Delegation", RFC 1591, March 1994.
[RFC1591] ポステルと、J.と、「ドメインネームシステム構造と委譲」(RFC1591)は1994を行進させます。
[RFC 1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC1996] Vixie、P.、「ゾーン変化(DNSは通知する)の迅速な通知のためのメカニズム」、RFC1996、1996年8月。
[RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2136] VixieとP.とトムソンとS.、RekhterとY.とJ.バウンド、「ドメインネームシステム(DNSアップデート)におけるダイナミックなアップデート」RFC2136(1997年4月)。
[RFC 2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2181] ElzとR.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、1997年7月。
[RFC 2434] 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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
Eastlake, et al. Best Current Practice [Page 9] RFC 2929 DNS IANA Considerations September 2000
イーストレーク、他 最も良い現在の練習[9ページ]RFC2929DNS IANA問題2000年9月
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC2535] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。
[RFC 2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", RFC 2606, June 1999.
[RFC2606] イーストレークとD.とA.パニツ、「予約された最高平らなDNS名」、RFC2606、1999年6月。
[RFC 2671] Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC2671] Vixie、P.、「DNS(EDNS0)のための拡張機能」、RFC2671、1999年8月。
[RFC 2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
2672, August 1999.
[RFC2672] クロフォード、M.、「非端末DNS名前リダイレクション」、RFC2672、1999年8月。
[RFC 2673] Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999.
[RFC2673] クロフォード、M.、「ドメインネームシステムにおける2進のラベル」、RFC2673、1999年8月。
[RFC 2845] 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)のための秘密鍵トランザクション認証」、RFC2845)は2000がそうするかもしれません。
[RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000.
[RFC2930] イーストレーク、D.、「DNS(TKEY RR)のための秘密鍵設立」、RFC2930、2000年9月。
[US-ASCII] ANSI, "USA Standard Code for Information Interchange",
X3.4, American National Standards Institute: New York,
1968.
[米国-ASCII]ANSI、「米国の標準の情報交換用符号」、X3.4、American National Standards Institut: ニューヨーク、1968。
Eastlake, et al. Best Current Practice [Page 10] RFC 2929 DNS IANA Considerations September 2000
イーストレーク、他 最も良い現在の練習[10ページ]RFC2929DNS IANA問題2000年9月
Authors' Addresses
作者のアドレス
Donald E. Eastlake 3rd Motorola 140 Forest Avenue Hudson, MA 01749 USA
ドナルドE.イーストレーク第3モトローラ140の森林Avenue MA01749ハドソン(米国)
Phone: +1-978-562-2827 (h)
+1-508-261-5434 (w)
Fax: +1-508-261-4447 (w)
EMail: Donald.Eastlake@motorola.com
以下に電話をしてください。 +1-978-562-2827 (h)+1-508-261-5434(w)Fax: +1-508-261-4447 (w) メールしてください: Donald.Eastlake@motorola.com
Eric Brunner-Williams Engage 100 Brickstone Square, 2nd Floor Andover, MA 01810
エリック・ブルンナー-ウィリアムズはアンドーバー、第2Floor MA 100Brickstone正方形、01810を従事させます。
Phone: +1-207-797-0525 (h)
+1-978-684-7796 (w)
Fax: +1-978-684-3118
EMail: brunner@engage.com
以下に電話をしてください。 +1-207-797-0525 (h)+1-978-684-7796(w)Fax: +1-978-684-3118 メールしてください: brunner@engage.com
Bill Manning USC/ISI 4676 Admiralty Way, #1001 Marina del Rey, CA 90292 USA
ビルマニングUSC/ISI4676海軍本部Way、#1001マリナデルレイ、カリフォルニア90292米国
Phone: +1-310-822-1511 EMail: bmanning@isi.edu
以下に電話をしてください。 +1-310-822-1511 メールしてください: bmanning@isi.edu
Eastlake, et al. Best Current Practice [Page 11] RFC 2929 DNS IANA Considerations September 2000
イーストレーク、他 最も良い現在の練習[11ページ]RFC2929DNS IANA問題2000年9月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Eastlake, et al. Best Current Practice [Page 12]
イーストレーク、他 最も良い現在の習慣[12ページ]
一覧
スポンサーリンク
