Internet Engineering Task Force (IETF) D. Eastlake 3rd RFC: 6895 Huawei BCP: 42 2013年4月 廃止(Obsoletes): 6195 更新(Updates): 1183, 2845, 2930, 3597 分類: 現状の最良の方法(Best Current Practice) ISSN: 2070-1721 DNS(Domain Name System)のIANAに関する考慮点 要旨 本文書は、IANA(Internet Assigned Numbers Authority)によるDNS(Domain Name System)のリソースレコードタイプ、クラス、オペレーションコード、 エラーコード、DNSプロトコルヘッダービット、AFSDBリソースレコード サブタイプ等の登録エントリに関するパラメーター割り当ての考慮点を明記 する。本文書はRFC 6195を廃止し、RFC 1183、2845、2930、3597を更新する。 Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6895. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Eastlake Best Current Practice [Page 1] RFC 6895 DNS IANA Considerations April 2013 目次 1. はじめに ........................................................2 1.1. 用語 .......................................................3 2. DNS問い合わせ/応答ヘッダー ......................................3 2.1. Zビットの割り当て ..........................................4 2.2. OpCodeの割り当て ...........................................4 2.3. RCODEの割り当て ............................................4 3. DNSリソースレコード .............................................6 3.1. RRTYPEのIANAに関する考慮点 .................................7 3.1.1. DNS RRTYPE割り当てポリシー ..........................8 3.1.2. DNS RRTYPEエキスパートのガイドライン ...............10 3.1.3. OPT RRに関する特別な注記 ...........................10 3.1.4. AFSDB RRのサブタイプフィールド .....................10 3.2. RRクラスのIANAに関する考慮点 ..............................11 3.3. ラベルに関する考慮点 ......................................13 3.3.1. ラベルタイプ .......................................13 3.3.2. ラベルの内容と使用法 ...............................13 4. セキュリティに関する考慮点 .....................................14 5. IANAに関する考慮点 .............................................14 付録 A. RRTYPE割り当てテンプレート ................................15 Appendix B. Changes from RFC 6195 .................................16 Normative References ..............................................17 Informative References ............................................18 Acknowledgements ..................................................19 1. はじめに DNS(Domain Name System)は、ドメイン名配下の"リソースレコード(RR)"を 保存する、複製・分散型のセキュアな階層データベースを提供する。 DNSデータは、クラスと、それぞれ独立して維持管理が可能なゾーンに 構造化される。[RFC1034]、[RFC1035]、[RFC2136]、[RFC2181]、[RFC4033]への 精通が前提とされる。 本文書は、DNS問い合わせ・応答ヘッダー及び全RRを適用対象とした、IANAに よるパラメーター割り当てに関する一般的な考慮点を、直接または参照によって 提供する。特定のRRTYPEまたは問い合わせ/応答OpCodeにだけ適用される付加的な IANAに関する考慮点もあるかもしれない。そのような考慮点が定義済みで あれば、それらについてはそのRRTYPEまたは問い合わせ/応答OpCodeを定義する 特定のRFCを参照のこと。ただし、AFSDB RRの考慮点[RFC1183]は例外で、 本文書に含まれる。本RFCは[RFC6195]を廃止する。しかし、大幅な変更点は、 RRTYPEのIANA割り当て手順(手順の簡素化と、期待される関係者の振る舞いの 明確化を意図)と、AFSDBサブタイプレジストリの閉鎖だけである。 IANAは、DNSパラメーターのWebページを維持管理してり、で 利用できる。 Eastlake Best Current Practice [Page 2] RFC 6895 DNS IANA Considerations April 2013 1.1. 用語 "標準化活動(Standards Action)"、"IETFの審査(IETF Review)"、 "仕様文書要求(Specification Required)"、プライベート使用(Private Use)" 等の語は、[RFC5226]で定義されている通りのものである。 2. DNS問い合わせ/応答ヘッダー DNSの問い合わせ・応答用のヘッダーは、[RFC2136]から引用した以下の図に 記載されたフィールド/ビットを含む。 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 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ IDフィールドは問い合わせを特定する。また、応答でエコーバックされるので、 問い合わせと応答を対応付けられる。 QRビットは、このヘッダーが問い合わせ用か応答用かを提示する。 AA、TC、RD、RA、CDビットは、ビットに応じて問い合わせだけ、または応答だけ でしか理論上の意味を持たない。ADビットは応答でしか意味を持たなかったが、 (現在は)問い合わせでも応答とは別だが関連した意味を持つと期待されている ([RFC6840]のセクション5.7参照)。RDビットとCDビットだけが問い合わせから 応答にコピーされると期待されるが、幾つかのDNS実装は応答ヘッダーの初期値 として問い合わせヘッダーのすべてをコピーする。従って、既存の実装を考慮 すると、"問い合わせ"ビットを応答で異なる意味で使用したり、"応答"ビットに 問い合わせの意味を定義したりするあらゆる試みは危険だろう。これらのビットの 意味は、標準化活動によってのみ割り当てを行える。 符号無し整数フィールドの問い合わせ数(QDCOUNT)、回答データ数(ANCOUNT)、 権威データ数(NSCOUNT)、付加情報データ数(ARCOUNT)は、Update[RFC2136] 以外のOpCodeすべてについて、各セクションのレコード数を通知する。 Eastlake Best Current Practice [Page 3] RFC 6895 DNS IANA Considerations April 2013 これらのフィールドは、Updateに関しても同じ構造とデータタイプを持つが、 代わりにゾーンデータ数(ZOCOUNT)、要件データ数(PRCOUNT)、更新データ数 (UPCOUNT)、付加情報データ数(ARCOUNT)となる。 2.1. Zビットの割り当て 問い合わせ中に存在するZビットは、ゾーンのプライマリサーバーからの応答だけが 受理可能であると解釈するような、ひどく旧いDNS実装が現在も稼働し続けている。 現在のDNS実装は、このビットを無視すると考えられている。 Zビットに意味を割り当てるには標準化活動が必要である。 2.2. OpCodeの割り当て 現在、DNSのOpCodeは以下のように割り当てられている。 OpCode 名称 参照 0 Query(問い合わせ) [RFC1035] 1 IQuery(逆問い合わせ、廃止) [RFC3425] 2 Status(状態) [RFC1035] 3 Unassigned(未割り当て) 4 Notify(通知) [RFC1996] 5 Update(更新) [RFC2136] 6-15 Unassigned(未割り当て) OpCodeのStatusは[RFC1035]で予約されているが、その振る舞いは規定されて いない。新しいOpCodeの割り当てには標準化活動が必要である。[RFC4020]で 規定されたように早期割り当て(early allocation)も容認される。 2.3. RCODEの割り当て 先に示したDNSヘッダーからは、RCODEまたは問い合わせ/エラーコードとして 4ビットだけしか利用できないように見えるだろう。しかし、RCODEはDNS応答の トップレベルだけではなく、TSIG RR[RFC2845]、TKEY RR[RFC2930]、OPT RRに よる拡張[RFC6891]の中にも現れることがある。OPT RRは、ヘッダーの4ビットに 8ビットの拡張を提供するので、結果として12ビットのRCODEフィールドが 得られる。また、TSIGやTKEY RRは、それらを規定するRFCで"Error"フィールドと 提示される16ビットフィールドを持つ。 DNSヘッダーや他のRRタイプで現れるエラーコードはすべて同じエラーコード 空間を参照するが、幾つか例外がある。エラーコード16は、OPT RRとTSIG RRで 異なる意味を持つ。またエラーコード9の差異については、以下に示す表の後に 記述される。16への重複した割り当ては偶然に生じた。先行するどのRFCもOPT、 TSIG、TKEY RRに関して異なるエラー番号空間を一切暗示してこなかったことから、 これらは以下で提示する統合されたDNSエラー番号空間に置き換えられる (本文書が[RFC2845]及び[RFC2930]を更新する理由は本段落である)。 Eastlake Best Current Practice [Page 4] RFC 6895 DNS IANA Considerations April 2013 既存のエラー番号9と16を例外として、たとえ異なるRRタイプの中でだけ生じる エラーであっても、異なるエラーに対して同じエラー番号が割り当てられては ならない。以下の表を参照のこと。 RCODE 名称 説明 参照 10進 16進 0 NoError エラー無し [RFC1035] 1 FormErr フォーマットエラー [RFC1035] 2 ServFail サーバー障害 [RFC1035] 3 NXDomain ドメイン名不在 [RFC1035] 4 NotImp 未実装 [RFC1035] 5 Refused 問い合わせ拒否 [RFC1035] 6 YXDomain あるべきでないドメイン名が存在 [RFC2136] 7 YXRRSet あるべきでないRRsetが存在 [RFC2136] 8 NXRRSet あるべきドメイン名が不在 [RFC2136] 9 NotAuth サーバーはゾーンの権威を持たない [RFC2136] 9 NotAuth 不許可 [RFC2845] 10 NotZone ドメイン名がゾーンの範囲外 [RFC2136] 11 - 15 0xB - 0xF 未割り当て 16 BADVERS 不正OPTバージョン [RFC6891] 16 BADSIG TSIG署名検証失敗 [RFC2845] 17 BADKEY 未知の署名鍵 [RFC2845] 18 BADTIME 署名が有効期間外 [RFC2845] 19 BADMODE 不正なTKEYモード [RFC2930] 20 BADNAME 鍵名重複/鍵名不在 [RFC2930] 21 BADALG アルゴリズム未サポート [RFC2930] 22 BADTRUNC 不正な切り詰め [RFC4635] 23 - 3,840 0x0017 - 0x0F00 未割り当て 3,841 - 4,095 0x0F01 - 0x0FFF プライベート使用のために予約 4,096 - 65,534 0x1000 - 0xFFFE 未割り当て 65,535 0xFFFF 予約。標準化活動を通してのみ割り当て可 Eastlake Best Current Practice [Page 5] RFC 6895 DNS IANA Considerations April 2013 エラー番号9(NotAuth)に関する注記: このエラー番号は、"サーバーは ゾーンの権威を持たない(Not Authoritative)"[RFC2136]か"不許可(Not Authorized)"[RFC2845]のどちらかを意味する。DNS応答のヘッダーの RCODEに9が現れている場合、応答がTSIG RRを含まないか、エラーフィールド がゼロのTSIG RRを含むならば、RCODEは"サーバーはゾーンの権威を持たない" を意味する。これに対し、応答がゼロ以外の値のエラーフィールドを持つ TSIG RRを含むのであれば、RCODEは"不許可"を意味する。 相互運用のためにはRCODEが理解されることが重要なので、上記の表で "未割り当て"と記載された範囲から新しいRCODEを割り当てるにはIETFの審査 を必要とする。 3. DNSリソースレコード すべてのRRは同じトップレベルフォーマットを持つ。このフォーマットは[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 / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ NAMEは所有者名である。言い換えると、このリソースレコードが関連する ノードの名前である。セクション3.2に記述されるように、名前はクラスに固有 のものである。名前は順序づけられた一つ以上のラベルの並びで構成され、 各ラベルはラベルタイプを持つ[RFC1035][RFC6891]。 TYPEはRRTYPEコードの一つを保持する2オクテットの符号無し整数である。 セクション3.1参照。 CLASSはRRクラスコードの一つを保持する2オクテットの符号無し整数である。 セクション3.2参照。 Eastlake Best Current Practice [Page 6] RFC 6895 DNS IANA Considerations April 2013 TTLは4オクテット(32ビット)の符号無し整数で、データタイプに関して、情報源が 再び参照されるべき状況になるまで、そのリソースレコードをキャッシュしてよい 秒数を指定する。ゼロは、そのRRは進行中のトランザクションでだけ使用可能 という意味だと解釈される。 RDLENGTHは16ビットの符号無し整数で、RDATAフィールドのオクテット単位の 長さを指定する。 RDATAはリソースを構成する可変長のオクテット列である。この情報の フォーマットは、TYPEと、幾つかの状況ではレコードのクラスによって 異なる。 3.1. RRTYPEのIANAに関する考慮点 RRTYPE番号には三つのサブカテゴリー、データタイプ、QTYPE、メタタイプが 存在する。 データタイプはデータを保存する手段である。QTYPEは問い合わせでのみ使用可能 である。メタタイプは特定のDNSメッセージに関係する一時的なデータである ことを提示する。幾つかの状況では問い合わせでも使用することができる。 これまでのところ、データタイプは1から上方へ、100から103のブロック、 32,768から上方へと割り当てられてきた。一方、QTYPEとメタタイプは、 タイプ41を割り当てられたOPTメタRRを例外として、255から下方に割り当て られてきた。RRTYPEの最下位バイトの最上位ビットに基づいてキャッシュの 判断を行う実装も存在している。 現在、三つのメタタイプが割り当てられている。OPT[RFC6891]、TSIG[2845]、 TKEY[RFC2930]がそれに当たる。一方、QTYPEは現在五つが割り当てられている。 *(ALL/ANY)、MAILA、MAILB、AXFR、IXFRである。 割り当てられたRRTYPEはニーモニックを持つが、これはクラスで使用される ニーモニックとは全く重複してはならないことに加えて、以下に示す正規表現 に一致しなければならない。加えて、[RFC3597]のセクション5で規定される 汎用のクラス名及びRRTYPE名は、新しいRRTYPEニーモニックとして割り当て られることはできない。 [A-Z][A-Z0-9\-]*[A-Z0-9] ただし以下と一致してはならない (TYPE|CLASS)[0-9]* Eastlake Best Current Practice [Page 7] RFC 6895 DNS IANA Considerations April 2013 新しいRRTYPEの割り当てに関する考慮点は以下の通りである。 10進 16進 割り当てポリシー 0 0x0000 RRTYPEゼロはSIG(0) RR[RFC2931][RFC4034]及び他の 状況における特別な指標として使用され、通常使用のために 割り当てられるようなことは決してあってはならない。 1 - 127 0x0001 - 0x007F この範囲の残りのRRTYPEは、セクション3.1.1で規定される DNS RRTYPE割り当てポリシーに従って、データタイプに 割り当てられる。 128 - 255 0x0080 - 0x00FF この範囲の残りのRRTYPEは、セクション3.1.1で規定される DNS RRTYPE割り当てポリシーに従って、QTYPE及び メタタイプに割り当てられる。 256 - 61,439 0x0100 - 0xEFFF この範囲の残りのRRTYPEは、セクション3.1.1で規定される DNS RRTYPE割り当てポリシーに従って、データタイプに 割り当てられる。(これまでに32,768と32,769(0x8000と 0x8001)が割り当てられている)。 61,440 - 65,279 0xF000 - 0xFEFF 将来の使用のために予約。用途の定義にはIETFの審査が 要求される。 65,280 - 65,534 0xFF00 - 0xFFFE プライベート利用のために予約 65,535 0xFFFF 予約(標準化活動) 3.1.1. DNS RRTYPE割り当てポリシー 上述セクション3.1で指定されるパラメーター値は、DNS RRTYPE割り当て ポリシーに基づいて割り当てられる。具体的に、以下に列挙する二つの要件を 満たす場合に、エキスパートレビューを経て割り当てが行われる。IESGに 指定された少数のエキスパートの人材プールが存在することになるだろう。 各申請は、IANAが選任したエキスパートによって審議されるようになる。 選任されたエキスパートの手が空いていない場合や、エキスパートが利益相反 の立場にある場合、IANAは人材プールから別のエキスパートを選任してもよい。 エキスパートに関する幾つかのガイドラインはセクション3.1.2で与えられる。 Eastlake Best Current Practice [Page 8] RFC 6895 DNS IANA Considerations April 2013 以下の要件を満たさないRRTYPEも、標準化活動を通して割り当てを受ける ことができる。[RFC4020]で規定されたように早期割り当ても容認される。 1. 付録Aで指定されるテンプレートの完成版が dns-rrtype-applications@ietf.org メーリングリストに投稿され、エキスパートに受信される。 テンプレートの一部またはドラフトあるいは正式に提出されたテンプレートを 申請者またはエキスパートがdnsext@ietf.orgに投稿し、コメントや議論を 求めることが強く推奨されることに注意せよ。初回の申請棄却と修正・再提出の 可能性を低減させるために、RRTYPEテンプレートの正式な提出前に、 コミュニティの審査に提出し、その反応を考慮することを推奨する。 2. RRTYPEコードがリクエスト中のRRは、(a)[RFC3597]に記載される未知のRRと して処理できるもの、(b)処理が任意のメタタイプ、言い換えると、その メタタイプの問い合わせまたは応答を単純に破棄できるもの のどちらかである。 そのようなRRは、付加情報部の処理(その処理は任意)を含むかもしれない ことに注意せよ。 付録Aで指定されるテンプレートの完成版を申請者が dns-rrtype-applications@ietf.orgメーリングリストに送信することで 正式なIANAへの申請がなされた後、IANAはエキスパートを指定し、テンプレート 完成版をエキスパートに、コピーを申請者に送信する。申請受信後2週間を 越えない期間内にエキスパートは明示的に申請を承認または棄却し、その 結果をIANA、申請者、dnsext@ietf.orgメーリングリストに通知するものと する。棄却には棄却の理由が含まれるべきであり、改善への提案を含んでも よい。エキスパートは、必要に応じて他の技術エキスパートやdnsext@ietf.org メーリングリストに助言を求めるべきである。エキスパートが期間内に申請を 承認しなかった場合、申請は棄却されたと見なされる。IANAは応答しなかった エキスパートをIESGに報告すべきである。 IANAは承認されたテンプレートの公開アーカイブを維持管理するものとする。 加えて、申請されるRRTYPEの必要な記述がURLによって参照される場合、頻繁に 参照される文書のコピーもアーカイブに含まれるべきである。 Eastlake Best Current Practice [Page 9] RFC 6895 DNS IANA Considerations April 2013 3.1.2. DNS RRTYPEエキスパートのガイドライン 指定エキスパート(Designated Expert)は本来寛容であるべきで、リクエストの 大半の承認を選択すべきである。しかし、以下の基準を一つ以上満たすRRTYPE 割り当てリクエストについては、エキスパートは通常拒否すべきである。 1. リクエストが評価または実装できる程度に充分明確でないか、完全ではない 形で文書化されていた(エキスパートレビュー期間中の追加文書提供も可能 である)。 2. 提案された一つ以上のRRTYPEはDNS処理に影響を与え、上述セクション3.1.1の 2項の基準を満たさない。 3. 文書化された用途は、ワイルドカード、CNAME、DNAME等のDNSプロトコルの 振る舞いに関して不正確な前提を置いている。 4. 少数のRRTYPE値かプライベート使用の値を利用することで申請目的を充足 できる可能性がある場合に、法外な数のRRTYPE値がリクエストされている。 3.1.3. OPT RRに関する特別な注記 OPT(OPTion) RR(RRタイプ41)とそのIANAに関する考慮点は、[RFC6891]で規定 される。このRRの主たる目的は、RCODE、ラベルタイプ、OpCode、フラグビット、 RDATAサイズ等のさまざまなDNSフィールドの実行サイズを拡張することである。 特に、このRRを認識するリゾルバー及びサーバーに対して、このRRはRCODE フィールドを4ビットから12ビットに拡張する。 3.1.4. AFSDB RRのサブタイプフィールド AFSDB RR[RFC1183]は、MX RR[RFC1035]と同じRDATAフィールド構造を持つ、 クラスの影響を受けないRRである。しかし、RDATAの先頭16ビット符号無し整数 フィールドは、以下に示すようにサブタイプとして解釈される。AFSセル データベースサーバーの所在を特定するAFSDB RRの使用は、[RFC5864]に よって廃止見込みとなった。このサブタイプレジストリは本文書によって クローズされ、新しいサブタイプの割り当てはもはや許容されない。 Eastlake Best Current Practice [Page 10] RFC 6895 DNS IANA Considerations April 2013 10進 16進 割り当てポリシー 0 0x0000 予約。レジストリはクローズされた。 1 0x0001 指定されるホストはAFS v3.0ロケーションサーバー[RFC1183] 2 0x0002 指定されるホストはDCE/NCAのルートセルディレクトリノード [RFC1183] 3 - 65,279 0x0003 - 0xFEFF 割り当て無し。レジストリはクローズされた。 65,280 - 65,534 0xFF00 - 0xFFFE プライベート使用 65,535 0xFFFF 予約。レジストリはクローズされた。 3.2. RRクラスのIANAに関する考慮点 DNSクラスには、現在通常のデータを保持するクラスと、問い合わせまたは更新で のみ意味を持つQCLASSの二つのサブカテゴリーが存在する。 DNSクラスは、ほとんど使用されてこなかったが、DNS分散データベースの 異なる側面を構成する。具体的に、ある一つのデータクラスに関する名前空間 またはルートサーバーと、別のデータクラスの名前空間・ルートサーバーの 間に必須の関係は存在しない。異なるクラス間で、同じDNS名に全く異なる意味を 持たせることもできる。ラベルタイプは同じで、ヌル(null)ラベルは各クラスの ルートを表現するものとしてのみ使用できる。グローバルなネットワーキングと DNSが発展してきたことから、INまたはインターネットクラスがDNSの使用に おいて支配的となっている。 これまで"メタクラス"に関する要件は存在していない。あるとすればそれは、 特定のDNSメッセージに関連する、問い合わせ時に有用かもしれない一時的 データを提示するクラスであることだったろう。しかし、一つ以上のメタクラス に関して、将来要件が設定される可能性もある。 割り当てられたクラスはニーモニックを持つが、これはRRTYPEで使用される ニーモニックとは全く重複してはならないことに加えて、以下に示す正規表現 に一致しなければならない。加えて、[RFC3597]のセクション5で規定される 汎用のクラス名及びRRTYPE名は、新しいRRTYPEニーモニックとして割り当て られることはできない。 Eastlake Best Current Practice [Page 11] RFC 6895 DNS IANA Considerations April 2013 [A-Z][A-Z0-9\-]*[A-Z0-9] ただし以下と一致してはならない (TYPE|CLASS)[0-9]* 将来の割り当てに向けた、現状のクラスの割り当てと考慮点は以下の通り である。 10進 16進 割り当て / ポリシー、参照 0 0x0000 予約。割り当てには標準化活動が必要 1 0x0001 インターネット (IN) [RFC1035] 2 0x0002 IETFの審査により、データクラスとしての割り当てに 利用可能 3 0x0003 Chaos (CH) [Moon1981] 4 0x0004 Hesiod (HS) [Dyer1987] 5 - 127 0x0005 - 0x007F IETFの審査により、データクラス用の割り当てのみに 利用可能 128 - 253 0x0080 - 0x00FD IETFの審査により、QCLASS及びメタクラス用の 割り当てのみに利用可能 254 0x00FE QCLASS NONE [RFC2136] 255 0x00FF QCLASS * (ANY) [RFC1035] 256 - 32,767 0x0100 - 0x7FFF IETFの審査により、割り当てに利用可能 32,768 - 57,343 0x8000 - 0xDFFF データクラス用の割り当てのみに利用可能。 仕様文書要求 Eastlake Best Current Practice [Page 12] RFC 6895 DNS IANA Considerations April 2013 57,344 - 65,279 0xE000 - 0xFEFF QCLASSとメタクラス用の割り当てのみに利用可能。 仕様文書要求 65,280 - 65,534 0xFF00 - 0xFFFE プライベート使用 65,535 0xFFFF 予約。標準化活動によってのみ割り当て可能 3.3. ラベルに関する考慮点 DNS名はラベルの並びである[RFC1035]。 3.3.1. ラベルタイプ 現時点において、ラベルタイプは二つに分類される。データラベルと圧縮 ラベルである。圧縮ラベルはRRまたはDNSメッセージ内のどこかにあるデータ ラベルへのポインターで、名前のワイヤーエンコーディングを短くすることを 意図している。 既存の二つのデータラベルタイプは、それぞれテキスト・バイナリーと呼ばれる こともある。実際には、テキストラベルにはゼロ値オクテットを含むどのような オクテット値でも含むことができるが、多くの現行の使用法は、ASCIIの表示文字 [US-ASCII]だけを対象としている。検索に関して、テキストラベルはASCIIの 大文字と小文字の文字コードは一致するものとして扱われると定義されている [RFC4343]。バイナリーラベルはビットの並びである[RFC2673]。バイナリー ラベルは歴史的(Historic)となっている[RFC6891]。 3.3.2. ラベルの内容と使用法 各名前の最後のラベルは"ルート(ROOT)"で、これは長さゼロのラベルである。 定義により、ヌルまたはルートラベルは名前において他の目的で使用する ことはできない。 名前はクラスに対してローカルである。Hesiod[Dyer1987]やChaos[Moon1981] クラスは、本質的にローカルな利用向けのものである。従って、INまたは インターネットクラスは、現時点でインターネット上でグローバルに使用される 唯一のDNSクラスである。 INクラスの名前の割り当てに関する、少々時代遅れの説明が[RFC1591]で 与えられている。予約済みのトップレベルドメイン名に関する若干の情報が BCP 32[RFC2606]で得られる。 Eastlake Best Current Practice [Page 13] RFC 6895 DNS IANA Considerations April 2013 4. セキュリティに関する考慮点 本文書が扱うものは、一般的なDNSパラメーターの割り当てにおけるIANAに 関する考慮点であり、セキュリティに関するものではない。セキュアなDNSに 関する考慮点については[RFC4033]、[RFC4034]、[RFC4035]を参照のこと。 5. IANAに関する考慮点 本文書は、すべてがDNSのIANAに関する考慮点で構成されている。 IANAは、付録Aのテンプレートを受理し、そのテンプレートフォーム申請を 審査するために、指定された要員からエキスパートを選択するための手順を 確立した。IANAはテンプレートをエキスパートに、そのコピーを申請者に 転送する。IANAは、承認されたRRTYPE割り当てテンプレートと、(それらが 安定したURIですぐに利用できないのであれば)参照される文書すべてをアーカイブ し公開する。正式な申請テンプレートをdns-rrtype-applications@ietf.org メーリングリストに投稿するのは申請者の責務である。同メーリングリストを IANAはモニターする。dnsext@ietf.orgメーリングリストは、コミュニティに よる議論とコメントを求めるためのものである。詳細についてはセクション3.1と 付録Aを参照のこと。 Eastlake Best Current Practice [Page 14] RFC 6895 DNS IANA Considerations April 2013 付録 A. RRTYPE割り当てテンプレート DNSのRRTYPEパラメーター割り当てテンプレート (訳注：以下は理解補助のための訳であり、正式なテンプレートは 原文表記のものを用いなければならない) 正式な検討の準備が整ったならば、このテンプレートを dns-rrtype-applications@ietf.orgにメール送信することで、同テンプレートは IANAに提出され処理される。 A. 提出日: B.1 提出タイプ: [ ] 新しいRRTYPE [ ] RRTYPEの変更 B.2 RRの種別: [ ] データRR [ ] メタRR C. 提出者のコンタクト情報(本情報は公の場に提示される) 氏名: Emailアドレス: 国際電話番号: 他のコンタクト手段: D. 新しいRRTYPE申請の動機付け エキスパート及び審査担当者にRRTYPEの使用法を伝えるために、この 項目は高い品質レベルを維持して欲しい。大半の審査担当者はDNSの エキスパートであり、本申請の適用事例に関しては限定された知識しか 持たない可能性がある。 E. 提案RRタイプの説明 この説明は、テンプレートへのインライン記述、添付ファイル、公開された URL等によって提供することができる。 F. 要件の充足に最も近い既存のRRTYPEは何か。またそれらでは要件を満たせ ない理由は何か。 G. 新しいRRTYPEに対して要求されるニーモニック(任意) 注: ニーモニックが提供されない場合、許容されない場合、あるいは既存の RRTYPEやクラスのニーモニックと重複している場合、エキスパートが ニーモニックを割り当てる。 H. リクエストされたRRTYPEは既存のIANAレジストリを使用するか。あるいは、 DNSパラメーター内に新しいIANAサブレジストリ開設を必要とするか。 いずれかであれば、使用予定の、あるいは開設希望のレジストリを提示して ほしい。新しいサブレジストリが必要とされる場合、割り当てポリシーと 初期コンテンツを指定すること。また、変更手続きについてもここに 盛り込んでほしい。 I. 提案は、提案する新しいタイプが未知のRRTYPE([RFC3597]参照)として処理 されるのを抑制するような、DNSサーバー/リゾルバーの何らかの変更を 必要とする/期待するか。 J. コメント: Eastlake Best Current Practice [Page 15] RFC 6895 DNS IANA Considerations April 2013 Appendix B. Changes from RFC 6195 Dropped description of changes from RFC 5395 to [RFC6195], since those changes have already happened and we don't need to do them again. Added description of changes from [RFC6195] to this document. Cut back RRTYPE Expert Review period to two weeks and eliminated the mandatory dnsext@ietf.org comment period. Changed workflow description for RRTYPE review and allocation to correspond more closely to actual practice. Closed the AFSDB subtype registry and added an informative reference to [RFC5864] where the use of the AFSDB RR to locate AFS cell database servers is deprecated. Clarified IANA archiving of referenced documentation as well as approved RRTYPE application template. In the RRTYPE application template, changed the label of question "B" to "B.1" and added "B.2" to ask about the kind of RR. Added text and an exclusory regular expression to Sections 3.1 and 3.2 to prohibit the use of a slight generalization of the generic CLASS and RRTYPE names specified in [RFC3597] as the mnemonics for new CLASSes and RRTYPEs. Parenthetically listed "ANY" as well as "ALL" as a meaning for the "*" RRTYPE. Clarified that there is one DNS error number space for headers, OPT extended headers, TSIG RRs, and TKEY RRs. Noted that this is considered to update [RFC2845] and [RFC2930]. Noted the overloading of error number 9 as well as 16. Updated references for revised versions. Incorporated a number of editorial changes and typo fixes. Eastlake Best Current Practice [Page 16] RFC 6895 DNS IANA Considerations April 2013 Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996. [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000. [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 2002. [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. Eastlake Best Current Practice [Page 17] RFC 6895 DNS IANA Considerations April 2013 [RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", RFC 4635, August 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6840] Weiler, S., Ed., and D. Blacka, Ed., "Clarifications and Implementation Notes for DNS Security (DNSSEC)", RFC 6840, February 2013. [RFC6891] Damas, J., Graff, M., and Vixie, P., "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. [US-ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968. ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet. Informative References [Dyer1987] Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical Plan - Name Service, April 1987. [Moon1981] Moon, D., "Chaosnet", A.I. Memo 628, Massachusetts Institute of Technology Artificial Intelligence Laboratory, June 1981. [RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P. Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990. [RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994. [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999. [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999. [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000. Eastlake Best Current Practice [Page 18] RFC 6895 DNS IANA Considerations April 2013 [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, January 2006. [RFC5864] Allbery, R., "DNS SRV Resource Records for AFS", RFC 5864, April 2010. [RFC6195] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", RFC 6195, March 2011. Acknowledgements Alfred Hoenes' contributions are gratefully acknowledged as are those by Mark Andrews, Dick Franks, and Michael Sheldon. Author's Address Donald E. Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA Phone: +1-508-333-2270 EMail: d3e3e3@gmail.com Eastlake Best Current Practice [Page 19]