RFC4592 日本語訳
4592 The Role of Wildcards in the Domain Name System. E. Lewis. July 2006. (Format: TXT=43991 bytes) (Updates RFC1034, RFC2672) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Lewis Request for Comments: 4592 NeuStar Updates: 1034, 2672 July 2006 Category: Standards Track
コメントを求めるワーキンググループE.ルイスの要求をネットワークでつないでください: 4592のNeuStarアップデート: 1034、2672年2006年7月のカテゴリ: 標準化過程
The Role of Wildcards
in the Domain Name System
ドメインネームシステムにおけるワイルドカードの役割
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034.
これはRFC1034のワイルドカード定義へのアップデートです。 ワイルドカードとCNAMEとの相互作用を変えます、そして、エラー条件を取り除きます、そして、ワイルドカードに主要ないくつかの概念を定義する単語を変えます。 全体的な目的はワイルドカードを変えるのではなく、RFC1034の定義を洗練することです。
Lewis Standards Track [Page 1] RFC 4592 DNSEXT WCARD July 2006
ルイスStandardsはDNSEXT WCARD2006年7月にRFC4592を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Motivation .................................................3
1.2. The Original Definition ....................................3
1.3. Roadmap to This Document ...................................4
1.3.1. New Terms ...........................................5
1.3.2. Changed Text ........................................5
1.3.3. Considerations with Special Types ...................5
1.4. Standards Terminology ......................................6
2. Wildcard Syntax .................................................6
2.1. Identifying a Wildcard .....................................6
2.1.1. Wildcard Domain Name and Asterisk Label .............6
2.1.2. Asterisks and Other Characters ......................7
2.1.3. Non-terminal Wildcard Domain Names ..................7
2.2. Existence Rules ............................................7
2.2.1. An Example ..........................................8
2.2.2. Empty Non-terminals .................................9
2.2.3. Yet Another Definition of Existence ................10
2.3. When Is a Wildcard Domain Name Not Special? ...............10
3. Impact of a Wildcard Domain Name on a Response .................10
3.1. Step 2 ....................................................11
3.2. Step 3 ....................................................11
3.3. Part 'c' ..................................................12
3.3.1. Closest Encloser and the Source of Synthesis .......12
3.3.2. Closest Encloser and Source of Synthesis Examples ..13
3.3.3. Type Matching ......................................13
4. Considerations with Special Types ..............................14
4.1. SOA RRSet at a Wildcard Domain Name .......................14
4.2. NS RRSet at a Wildcard Domain Name ........................14
4.2.1. Discarded Notions ..................................15
4.3. CNAME RRSet at a Wildcard Domain Name .....................16
4.4. DNAME RRSet at a Wildcard Domain Name .....................16
4.5. SRV RRSet at a Wildcard Domain Name .......................17
4.6. DS RRSet at a Wildcard Domain Name ........................17
4.7. NSEC RRSet at a Wildcard Domain Name ......................18
4.8. RRSIG at a Wildcard Domain Name ...........................18
4.9. Empty Non-terminal Wildcard Domain Name ...................18
5. Security Considerations ........................................18
6. References .....................................................18
6.1. Normative References ......................................18
6.2. Informative References ....................................19
7. Others Contributing to the Document ............................19
1. 序論…3 1.1. 動機…3 1.2. オリジナルの定義…3 1.3. このドキュメントへの道路地図…4 1.3.1. 新学期…5 1.3.2. テキストを変えます…5 1.3.3. 特別なタイプがある問題…5 1.4. 規格用語…6 2. ワイルドカード構文…6 2.1. ワイルドカードを特定します…6 2.1.1. ワイルドカードドメイン名とアスタリスクラベル…6 2.1.2. アスタリスクと他のキャラクター…7 2.1.3. 非端末ワイルドカードドメイン名…7 2.2. 存在は統治されます…7 2.2.1. 例…8 2.2.2. 非端末を空にしてください…9 2.2.3. 存在のさらに別の定義…10 2.3. ワイルドカードドメイン名はいつ特別ではありませんか? ...............10 3. ワイルドカードドメイン名の応答への影響…10 3.1. ステップ2…11 3.2. ステップ3…11 3.3. 'c'を分けてください…12 3.3.1. 最も近いEncloserと統合の源…12 3.3.2. 統合の例の最も近いEncloserと源。13 3.3.3. マッチングをタイプしてください…13 4. 特別なタイプがある問題…14 4.1. ワイルドカードドメイン名におけるSOA RRSet…14 4.2. ワイルドカードドメイン名におけるナノ秒RRSet…14 4.2.1. 概念を捨てます…15 4.3. ワイルドカードドメイン名におけるCNAME RRSet…16 4.4. ワイルドカードドメイン名におけるDNAME RRSet…16 4.5. ワイルドカードドメイン名におけるSRV RRSet…17 4.6. ワイルドカードドメイン名におけるDS RRSet…17 4.7. ワイルドカードドメイン名におけるnsec RRSet…18 4.8. ワイルドカードドメイン名におけるRRSIG…18 4.9. 非端末ワイルドカードドメイン名を空にしてください…18 5. セキュリティ問題…18 6. 参照…18 6.1. 標準の参照…18 6.2. 有益な参照…19 7. ドキュメントに貢献する他のもの…19
Lewis Standards Track [Page 2] RFC 4592 DNSEXT WCARD July 2006
ルイスStandardsはDNSEXT WCARD2006年7月にRFC4592を追跡します[2ページ]。
1. Introduction
1. 序論
In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the synthesis of answers from special resource records (RRs) called wildcards. The definition in RFC 1034 is incomplete and has proven to be confusing. This document describes the wildcard synthesis by adding to the discussion and making limited modifications. Modifications are made to close inconsistencies that have led to interoperability issues. This description does not expand the service intended by the original definition.
セクション4.3 RFC1034[RFC1034]、.2、および4.3では、.3はワイルドカードと呼ばれる特別なリソース記録(RRs)から答えの統合について説明します。 RFC1034との定義は、不完全であり、混乱させていると判明しました。 このドキュメントは、議論の一助となって、限られた変更をすることによって、ワイルドカード統合について説明します。 相互運用性問題につながった矛盾を終えるのを変更をします。 この記述はオリジナルの定義で意図するサービスを広くしません。
Staying within the spirit and style of the original documents, this document avoids specifying rules for DNS implementations regarding wildcards. The intention is to only describe what is needed for interoperability, not restrict implementation choices. In addition, consideration is given to minimize any backward-compatibility issues with implementations that comply with RFC 1034's definition.
正本の精神とスタイルの範囲内にとどまって、このドキュメントは、ワイルドカードに関してDNS実現のための規則を指定するのを避けます。 意志は実現選択を制限するのではなく、相互運用性に必要であるものについて説明するだけであることです。 さらに、RFC1034の定義に従う実現のどんな後方の互換性の問題も最小にするために考慮を払います。
This document is focused on the concept of wildcards as defined in RFC 1034. Nothing is implied regarding alternative means of synthesizing resource record sets (RRSets), nor are alternatives discussed.
このドキュメントはRFC1034で定義されるようにワイルドカードの概念に焦点を合わせられます。 何もリソースレコードセット(RRSets)を統合する代替の手段に関して含意されません、そして、代替手段について議論しません。
1.1. Motivation
1.1. 動機
Many DNS implementations diverge, in different ways, from the original definition of wildcards. Although there is clearly a need to clarify the original documents in light of this alone, the impetus for this document lay in the engineering of the DNS security extensions [RFC4033]. With an unclear definition of wildcards, the design of authenticated denial became entangled.
多くのDNS実現がワイルドカードのオリジナルの定義と異なった方法で分岐します。 これの観点から単独で正本をはっきりさせる必要が明確にありましたが、DNSセキュリティ拡張子[RFC4033]の工学にはこのドキュメントのための起動力がありました。 ワイルドカードの不明瞭な定義によると、認証された否定のデザインはもつれるようになりました。
This document is intended to limit its changes, documenting only those deemed necessary based on implementation experience, and to remain as close to the original document as possible. To reinforce that this document is meant to clarify and adjust and not redefine wildcards, relevant sections of RFC 1034 are repeated verbatim to facilitate comparison of the old and new text.
このドキュメントは、実現経験に基づいて必要であると考えられたものだけを記録して、変化を制限して、できるだけ正本の近くに残っていることを意図します。 はっきりさせて、適応して、それを補強するために、このドキュメントはワイルドカードを再定義することになっていないで、1034人の関連RFCセクションが古くて新しいテキストの比較を容易にするために逐語的に繰り返されます。
1.2. The Original Definition
1.2. オリジナルの定義
The definition of the wildcard concept is comprised by the documentation of the algorithm by which a name server prepares a response (in RFC 1034's section 4.3.2) and the way in which a resource record (set) is identified as being a source of synthetic data (section 4.3.3).
ワイルドカード概念の定義はネームサーバが応答を準備するアルゴリズム(RFC1034のセクション4.3.2における)とリソース記録(設定する)が合成のデータの源であるとして特定される方法(セクション4.3.3)のドキュメンテーションによって包括されます。
Lewis Standards Track [Page 3] RFC 4592 DNSEXT WCARD July 2006
ルイスStandardsはDNSEXT WCARD2006年7月にRFC4592を追跡します[3ページ]。
This is the definition of the term "wildcard" as it appears in RFC 1034, section 4.3.3.
これはRFC1034、セクション4.3.3に現れるように「ワイルドカード」という用語の定義です。
# In the previous algorithm, special treatment was given to RRs with # owner names starting with the label "*". Such RRs are called # wildcards. Wildcard RRs can be thought of as instructions for # synthesizing RRs. When the appropriate conditions are met, the # name server creates RRs with an owner name equal to the query name # and contents taken from the wildcard RRs.
# 前のアルゴリズムで、#所有者名がラベル「*」から始まっていて、特別な処理をRRsに与えました。 そのようなRRsは#ワイルドカードと呼ばれます。 RRsを統合する#のための指示としてワイルドカードRRsを考えることができます。 適切な条件が満たされるとき、#ネームサーバは質問名#と等しい所有者名とワイルドカードRRsから取られたコンテンツでRRsを作成します。
This passage follows the algorithm in which the term wildcard is first used. In this definition, wildcard refers to resource records. In other usage, wildcard has referred to domain names, and it has been used to describe the operational practice of relying on wildcards to generate answers. It is clear from this that there is a need to define clear and unambiguous terminology in the process of discussing wildcards.
この通路は用語ワイルドカードが最初に使用されるアルゴリズムに従います。 この定義では、ワイルドカードはリソース記録を示します。 他の用法で、ワイルドカードはドメイン名を示しました、そして、それは、答えを発生させるようにワイルドカードを当てにする操作上の習慣について説明するのに使用されました。 これから、ワイルドカードについて議論することの途中に明確で明白な用語を定義する必要があるのは、明確です。
The mention of the use of wildcards in the preparation of a response is contained in step 3, part 'c' of RFC 1034's section 4.3.2, entitled "Algorithm". Note that "wildcard" does not appear in the algorithm, instead references are made to the "*" label. The portion of the algorithm relating to wildcards is deconstructed in detail in section 3 of this document; this is the beginning of the relevant portion of the "Algorithm".
応答の準備におけるワイルドカードの使用の言及はステップ3、「アルゴリズム」の権利を与えられたRFC1034のセクション4.3.2の一部'c'に含まれています。 「ワイルドカード」がアルゴリズムで現れないことに注意してください、そして、代わりに、「*」ラベルを参照します。 ワイルドカードに関連するアルゴリズムの部分はこのドキュメントのセクション3で詳細に脱構築されます。 これは「アルゴリズム」の関連部分の始まりです。
# c. If at some label, a match is impossible (i.e., the # corresponding label does not exist), look to see if [...] # the "*" label exists.
# c。 マッチが、あるラベルで不可能であるなら(すなわち、#対応するラベルは存在していません)、見るには、[…]であるなら見てください。 # 「*」ラベルは存在しています。
The scope of this document is the RFC 1034 definition of wildcards and the implications of updates to those documents, such as DNS Security (DNSSEC). Alternate schemes for synthesizing answers are not considered. (Note that there is no reference listed. No document is known to describe any alternate schemes, although there has been some mention of them in mailing lists.)
このドキュメントの範囲は、1034年のワイルドカードのRFC定義とそれらのドキュメントへのアップデートの含意です、DNS Security(DNSSEC)などのように。 答えを統合することの交互の計画は考えられません。 (どんな記載された参照もないことに注意してください。 メーリングリストにおける、それらの何らかの言及がありましたが、ドキュメントが全くどんな交互の計画についても説明するのが知られません。)
1.3. Roadmap to This Document
1.3. このドキュメントへの道路地図
This document accomplishes these three tasks.
このドキュメントはこれらの3つのタスクを達成します。
o Defines new terms
o 新学期を定義します。
o Makes minor changes to avoid conflicting concepts
o 闘争概念を避けるためにマイナーチェンジを作ります。
o Describes the actions of certain resource records as wildcards
o あるリソース記録の動作をワイルドカードとして記述します。
Lewis Standards Track [Page 4] RFC 4592 DNSEXT WCARD July 2006
ルイスStandardsはDNSEXT WCARD2006年7月にRFC4592を追跡します[4ページ]。
1.3.1. New Terms
1.3.1. 新学期
To help in discussing what resource records are wildcards, two terms will be defined: "asterisk label" and "wildcard domain name". These are defined in section 2.1.1.
どんなリソースレコードがワイルドカードであるかと議論するのを手伝うために、2つの用語が定義されるでしょう: 「アスタリスクラベル」と「ワイルドカードドメイン名。」 これらはセクション2.1.1で定義されます。
To assist in clarifying the role of wildcards in the name server algorithm in RFC 1034, section 4.3.2, "source of synthesis" and "closest encloser" are defined. These definitions are in section 3.3.1. "Label match" is defined in section 3.2.
RFC1034のネームサーバアルゴリズムでワイルドカードの役割をはっきりさせるのを助けるために、.2、「統合の源」というセクション4.3と「最も近いencloser」は定義されます。 セクション3.3.1にはこれらの定義があります。 「ラベルマッチ」はセクション3.2で定義されます。
The new terms are used to make discussions of wildcards clearer. Terminology does not directly have an impact on implementations.
新学期は、ワイルドカードの議論を明らかにするために費やされます。 用語は直接実現に影響を与えません。
1.3.2. Changed Text
1.3.2. 変えられたテキスト
The definition of "existence" is changed superficially. This change will not be apparent to implementations; it is needed to make descriptions more precise. The change appears in section 2.2.3.
表面的に「存在」の定義を変えます。 この変化は実現に明らかにならないでしょう。 それが、記述をより正確にするのに必要です。 変化はセクション2.2.3に現れます。
RFC 1034, section 4.3.3, seems to prohibit having two asterisk labels in a wildcard owner name. With this document, the restriction is removed entirely. This change and its implications are in section 2.1.3.
RFC1034(セクション4.3.3)は、ワイルドカード所有者名で2個のアスタリスクラベルを持っているのを禁止するように思えます。 このドキュメントで、制限を完全に取り除きます。 セクション2.1.3にはこの変化とその含意があります。
The actions when a source of synthesis owns a CNAME RR are changed to mirror the actions if an exact match name owns a CNAME RR. This is an addition to the words in RFC 1034, section 4.3.2, step 3, part 'c'. The discussion of this is in section 3.3.3.
統合の源がCNAME RRを所有しているとき、完全な一致名がCNAME RRを所有しているなら、動作を反映するために動作を変えます。 これがRFC1034の単語への追加である、セクション4.3.2(ステップ3)は'c'を分けます。 セクション3.3.3にはこの議論があります。
Only the latter change represents an impact to implementations. The definition of existence is not a protocol impact. The change to the restriction on names is unlikely to have an impact, as RFC 1034 contained no specification on when and how to enforce the restriction.
後者の変化だけが衝撃を実現に表します。 存在の定義はプロトコル衝撃ではありません。 名前における制限への変化には、影響力がありそうにはありません、RFC1034がいつ、どう制限を実施するかに関する仕様を全く含まなかったので。
1.3.3. Considerations with Special Types
1.3.3. 特別なタイプがある問題
This document describes semantics of wildcard RRSets for "interesting" types as well as empty non-terminal wildcards. Understanding these situations in the context of wildcards has been clouded because these types incur special processing if they are the result of an exact match. This discussion is in section 4.
このドキュメントは空の非端末ワイルドカードと同様に「おもしろい」タイプのためにワイルドカードRRSetsの意味論について説明します。 これらのタイプが彼らが完全な一致の結果であるなら特別な処理を被るので、ワイルドカードの文脈のこれらの状況を理解するのは曇らせられました。 この議論はセクション4にあります。
These discussions do not have an implementation impact; they cover existing knowledge of the types, but to a greater level of detail.
これらの議論には、実現影響力がありません。 タイプに関する既存の知識をカバーしていますが、それらは、より大きいレベルの詳細にそうします。
Lewis Standards Track [Page 5] RFC 4592 DNSEXT WCARD July 2006
ルイスStandardsはDNSEXT WCARD2006年7月にRFC4592を追跡します[5ページ]。
1.4. Standards Terminology
1.4. 規格用語
This document does not use terms as defined in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
このドキュメントは「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」[RFC2119]で定義されるように用語を使用しません。
Quotations of RFC 1034 are denoted by a '#' at the start of the line. References to section "4.3.2" are assumed to refer to RFC 1034's section 4.3.2, simply titled "Algorithm".
RFC1034の引用は線の始めで'#'によって指示されます。 「0.2インチが単に「アルゴリズム」と題をつけられたRFC1034のセクション4.3.2について言及すると思われる4.3」というセクションの参照。
2. Wildcard Syntax
2. ワイルドカード構文
The syntax of a wildcard is the same as any other DNS resource record, across all classes and types. The only significant feature is the owner name.
ワイルドカードの構文はすべてのクラスとタイプの向こう側のいかなる他のDNSリソース記録とも同じです。 唯一の著しい特徴が所有者名です。
Because wildcards are encoded as resource records with special names, they are included in zone transfers and incremental zone transfers [RFC1995] just as non-wildcard resource records are. This feature has been under appreciated until discussions on alternative approaches to wildcards appeared on mailing lists.
ワイルドカードがリソース記録として特別な名前でコード化されるので、それらはちょうど非ワイルドカードリソース記録のようにゾーン転送と増加のゾーン転送[RFC1995]に含まれています。 感謝される下にワイルドカードへの代替的アプローチについての議論がメーリングリストに現れるまで、この特徴はありました。
2.1. Identifying a Wildcard
2.1. ワイルドカードを特定します。
To provide a more accurate description of wildcards, the definition has to start with a discussion of the domain names that appear as owners. Two new terms are needed, "asterisk label" and "wildcard domain name".
ワイルドカードの、より正確な記述を提供するために、定義は所有者として現れるドメイン名の議論から始まらなければなりません。 2回の新学期が、必要な「アスタリスクラベル」と「ワイルドカードドメイン名」です。
2.1.1. Wildcard Domain Name and Asterisk Label
2.1.1. ワイルドカードドメイン名とアスタリスクラベル
A "wildcard domain name" is defined by having its initial (i.e., leftmost or least significant) label be, in binary format:
バイナリフォーマットには初期(すなわち、一番左の、または、最も重要でない)のラベルがあることによって、「ワイルドカードドメイン名」は定義されます:
0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
0000 0001 0010 1010(2進の)は0×01 0x2aと等しいです。(16進)
The first octet is the normal label type and length for a 1-octet- long label, and the second octet is the ASCII representation [RFC20] for the '*' character.
最初の八重奏は、1八重奏長いラベルのための正常なラベル形式と長さです、そして、2番目の八重奏は'*'キャラクタのASCII表現[RFC20]です。
A descriptive name of a label equaling that value is an "asterisk label".
その値と等しいラベルの描写的である名前は「アスタリスクラベル」です。
RFC 1034's definition of wildcard would be "a resource record owned by a wildcard domain name".
RFC1034のワイルドカードの定義は「ワイルドカードドメイン名によって所有されていたリソース記録」でしょう。
Lewis Standards Track [Page 6] RFC 4592 DNSEXT WCARD July 2006
ルイスStandardsはDNSEXT WCARD2006年7月にRFC4592を追跡します[6ページ]。
2.1.2. Asterisks and Other Characters
2.1.2. アスタリスクと他のキャラクター
No label values other than that in section 2.1.1 are asterisk labels, hence names beginning with other labels are never wildcard domain names. Labels such as 'the*' and '**' are not asterisk labels, so these labels do not start wildcard domain names.
セクション2.1.1におけるそれ以外のラベルなし値がアスタリスクラベルである、したがって、他のラベルで始まる名前は決してワイルドカードドメイン名ではありません。 ''*などのラベル'と'**'がアスタリスクラベルでないので、これらのラベルはワイルドカードドメイン名を始めません。
2.1.3. Non-terminal Wildcard Domain Names
2.1.3. 非端末ワイルドカードドメイン名
In section 4.3.3, the following is stated:
セクション4.3.3では、以下は述べられています:
# .......................... The owner name of the wildcard RRs is # of the form "*.<anydomain>", where <anydomain> is any domain name. # <anydomain> should not contain other * labels......................
# .......................... <anydomain>は「所有者名(ワイルドカードRRs)は」 *フォーム<anydomain>の#です」あらゆるドメイン名です。 # <anydomain>は他の*ラベルを含むはずがありません…
The restriction is now removed. The original documentation of it is incomplete and the restriction does not serve any purpose given years of operational experience.
現在、制限を取り除きます。 それのオリジナルのドキュメンテーションは不完全です、そして、何年もの運用経験を考えて、制限は少しの目的にも役立ちません。
There are three possible reasons for putting the restriction in place, but none of the three has held up over time. One is that the restriction meant that there would never be subdomains of wildcard domain names, but the restriction as stated still permits "example.*.example." for instance. Another is that wildcard domain names are not intended to be empty non-terminals, but this situation does not disrupt the algorithm in 4.3.2. Finally, "nested" wildcard domain names are not ambiguous once the concept of the closest encloser had been documented.
適所に制限を置く3つの可能な理由がありますが、3のいずれも時間がたつにつれて、上げられていません。 1つは制限が、ワイルドカードドメイン名に関するサブドメインが決してないことを意味したということですが、述べられるとしての制限はまだ「例*.example」を可能にしています。. 例えば。 別のものがワイルドカードドメイン名が人影のない非端末であることを意図しないということですが、この状況が中でアルゴリズムを混乱させない、4.3、.2 最終的に、最も近いencloserの概念がいったん記録されると、「入れ子にされた」ワイルドカードドメイン名はあいまいではありません。
A wildcard domain name can have subdomains. There is no need to inspect the subdomains to see if there is another asterisk label in any subdomain.
ワイルドカードドメイン名はサブドメインを持つことができます。 何かサブドメインで別のアスタリスクラベルがあるかを確認するためにサブドメインを点検する必要は全くありません。
A wildcard domain name can be an empty non-terminal. (See the upcoming sections on empty non-terminals.) In this case, any lookup encountering it will terminate as would any empty non-terminal match.
ワイルドカードドメイン名は人影のない非端末であるかもしれません。 (人影のない非端末の上の今度のセクションを見てください。) この場合、それに遭遇するどんなルックアップもどんな空の非端末マッチであるだろうことのようにも終わるでしょう。
2.2. Existence Rules
2.2. 存在規則
The notion that a domain name 'exists' is mentioned in the definition of wildcards. In section 4.3.3 of RFC 1034:
ワイルドカードの定義でドメイン名が'存在している'という概念について言及します。 .3セクション4.3RFC1034で:
# Wildcard RRs do not apply: # ... # - When the query name or a name between the wildcard domain and # the query name is know[n] to exist. . . .
# ワイルドカードRRsは適用しません: # ... # - ワイルドカードドメインと#の間の質問名か名前であるときに、質問名は[n]が存在するのを知ることです。 . . .
Lewis Standards Track [Page 7] RFC 4592 DNSEXT WCARD July 2006
ルイスStandardsはDNSEXT WCARD2006年7月にRFC4592を追跡します[7ページ]。
"Existence" is therefore an important concept in the understanding of wildcards. Unfortunately, the definition of what exists, in RFC 1034, is unclear. So, in sections 2.2.2. and 2.2.3, another look is taken at the definition of existence.
したがって、「存在」はワイルドカードの理解で重要な概念です。 残念ながら、RFC1034に存在するものに関する定義は不明瞭です。 それで、セクション2.2.2 2.2.3では、存在の定義のときにもう1つの外観を取ります。
2.2.1. An Example
2.2.1. 例
To illustrate what is meant by existence consider this complete zone:
存在によって意味されることを例証するには、この完全なゾーンを考えてください:
$ORIGIN example.
example. 3600 IN SOA <SOA RDATA>
example. 3600 NS ns.example.com.
example. 3600 NS ns.example.net.
*.example. 3600 TXT "this is a wildcard"
*.example. 3600 MX 10 host1.example.
sub.*.example. 3600 TXT "this is not a wildcard"
host1.example. 3600 A 192.0.2.1
_ssh._tcp.host1.example. 3600 SRV <SRV RDATA>
_ssh._tcp.host2.example. 3600 SRV <SRV RDATA>
subdel.example. 3600 NS ns.example.com.
subdel.example. 3600 NS ns.example.net.
$ORIGINの例例。 3600年のIN SOA<SOA RDATA>の例。 3600NS ns.example.com例。 3600NS ns.example.net。 *.example。 3600TXT「これはワイルドカードです」*.example。 3600MX10host1.example潜水艦*.example。 3600TXT「これはワイルドカードではありません」host1.example。 3600 A192.0.2.1_セキュアシェル (SSH)_tcp.host1.example。 3600年のSRV<SRV RDATA>_セキュアシェル (SSH)_tcp.host2.example。 3600SRV<SRV RDATA>subdel.example。 3600NS ns.example.com subdel.example。 3600NS ns.example.net。
A look at the domain names in a tree structure is helpful:
木構造のドメイン名への一見は役立っています:
|
-------------example------------
/ / \ \
/ / \ \
/ / \ \
* host1 host2 subdel
| | |
| | |
sub _tcp _tcp
| |
| |
_ssh _ssh
| -------------例------------ //\\//\\//\\*host1 host2 subdel| | | | | | 潜水艦_tcp_tcp| | | | _セキュアシェル (SSH)_セキュアシェル (SSH)
The following responses would be synthesized from one of the wildcards in the zone:
以下の応答はゾーンのワイルドカードの1つから統合されるでしょう:
QNAME=host3.example. QTYPE=MX, QCLASS=IN
the answer will be a "host3.example. IN MX ..."
QNAME=host3.example。 QTYPEはaが"host3.example"であったなら答えが望んでいるQCLASS=Mx(IN)と等しいです。 「Mx」で…
QNAME=host3.example. QTYPE=A, QCLASS=IN
the answer will reflect "no error, but no data"
because there is no A RR set at '*.example.'
QNAME=host3.example。 'A RRセットが全く'*.example'にないので、QTYPE=A、答えが望んでいるQCLASS=INは「しかし、誤りがない、データがありません」を反映します。
Lewis Standards Track [Page 8] RFC 4592 DNSEXT WCARD July 2006
ルイスStandardsはDNSEXT WCARD2006年7月にRFC4592を追跡します[8ページ]。
QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
the answer will be "foo.bar.example. IN TXT ..."
because bar.example. does not exist, but the wildcard
does.
QNAME=foo.bar.example。 QTYPE=TXT、QCLASSはINと等しいです。答えは"foo.bar.example"でしょう。 "IN TXT"、…bar.example、存在しなさい、ただし、ワイルドカードは存在しています。
The following responses would not be synthesized from any of the wildcards in the zone:
以下の応答はゾーンのワイルドカードのいずれからも統合されないでしょう:
QNAME=host1.example., QTYPE=MX, QCLASS=IN
because host1.example. exists
QNAME=host1.example、QTYPEがQCLASS=Mx(IN)と等しい、host1.example、存在
QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
because sub.*.example. exists
QNAME=sub*.example.、QTYPE=Mx(IN)、QCLASS=潜水艦*.example、存在
QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
because _tcp.host1.example. exists (without data)
QNAMEが_telnet_tcp.host1.exampleと等しい、QTYPE=SRV、QCLASS=IN、_tcp.host1.example、存在(データのない)
QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
because subdel.example. exists (and is a zone cut)
QNAME=host.subdel.example、QTYPE=A、QCLASS=IN、subdel.example、存在(ゾーンは切られます)
QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
because *.example. exists
QNAME=ghost*.example.、QTYPE=Mx(IN)、QCLASS=*.example、存在
The final example highlights one common misconception about wildcards. A wildcard "blocks itself" in the sense that a wildcard does not match its own subdomains. That is, "*.example." does not match all names in the "example." zone; it fails to match the names below "*.example.". To cover names under "*.example.", another wildcard domain name is needed--"*.*.example."--which covers all but its own subdomains.
最終的な例はワイルドカードに関して1つのありがちな誤解を強調します。 ワイルドカードはワイルドカードがそれ自身のサブドメインに合っていないという意味で「それ自体を妨げます」。 「」 すなわち、*.example」は「例」ゾーンのすべての名前に合っているというわけではありません。 「」 *.exampleの下で名前を合わせません。」 別のワイルドカードドメイン名が必要です--」 *。「名前をカバーする」*.example、」、*.example」 --それ自身のサブドメイン以外のすべてを覆う。
2.2.2. Empty Non-terminals
2.2.2. 人影のない非端末
Empty non-terminals [RFC2136, section 7.16] are domain names that own no resource records but have subdomains that do. In section 2.2.1, "_tcp.host1.example." is an example of an empty non-terminal name. Empty non-terminals are introduced by this text in section 3.1 of RFC 1034:
人影のない非端末[RFC2136、セクション7.16]はリソース記録を全く所有していませんが、そうするサブドメインを持っているドメイン名です。 「中で2.2に.1、インチ_tcp.host1.exampleを区分してください。」は空の非ターミナル名に関する例です。 本稿はRFC1034のセクション3.1で人影のない非端末を導入します:
# The domain name space is a tree structure. Each node and leaf on # the tree corresponds to a resource set (which may be empty). The # domain system makes no distinctions between the uses of the # interior nodes and leaves, and this memo uses the term "node" to # refer to both.
# ドメイン名スペースは木構造です。 #でページをめくってください。そして、各ノード、木はリソースセット(空であるかもしれない)に対応しています。 #ドメインシステムは、#の用途の区別を全く内部のノードと葉にしないで、これを#への「ノード」という用語が示す用途のメモ両方にします。
The parenthesized "which may be empty" specifies that empty non- terminals are explicitly recognized and that empty non-terminals "exist".
「空であるかもしれない」parenthesizedは人影のない非端末が明らかに認識されて、人影のない非端末が「存在する」と指定します。
Lewis Standards Track [Page 9] RFC 4592 DNSEXT WCARD July 2006
ルイスStandardsはDNSEXT WCARD2006年7月にRFC4592を追跡します[9ページ]。
Pedantically reading the above paragraph can lead to an interpretation that all possible domains exist--up to the suggested limit of 255 octets for a domain name [RFC1035]. For example, www.example. may have an A RR, and as far as is practically concerned, is a leaf of the domain tree. But the definition can be taken to mean that sub.www.example. also exists, albeit with no data. By extension, all possible domains exist, from the root on down.
上のパラグラフを訳知り顔で読むのはドメイン名[RFC1035]には、ドメインが存在するのがすべて255の八重奏の提案された限界までそんなに可能な解釈に通じることができます。 例えば、www.example A RRを持っているかもしれなくて、ドメイン木が実際に当該であるのと同じくらい遠くに、葉がありますか? しかし、それを意味するのを定義を取ることができます。sub.www.exampleまた、データなしで存在していますが、存在しています。 拡大で、すべての可能なドメインが根以下から存在しています。
As RFC 1034 also defines "an authoritative name error indicating that the name does not exist" in section 4.3.1, so this apparently is not the intent of the original definition, justifying the need for an updated definition in the next section.
これは明らかにオリジナルの定義の意図ではありません、次のセクションとのアップデートされた定義の必要性を正当化してまた、RFC1034がセクション4.3.1で「名前が存在しないのを示す正式の名前誤り」を定義するように。
2.2.3. Yet Another Definition of Existence
2.2.3. 存在のさらに別の定義
RFC 1034's wording is fixed by the following paragraph:
RFC1034の言葉遣いは以下のパラグラフによって修理されています:
The domain name space is a tree structure. Nodes in the tree either own at least one RRSet and/or have descendants that collectively own at least one RRSet. A node may exist with no RRSets only if it has descendants that do; this node is an empty non-terminal.
ドメイン名スペースは木構造です。 木のノードには、少なくとも1RRSetを所有している、そして/または、少なくとも1RRSetをまとめて所有している子孫がいます。 それにそうする子孫がいる場合にだけ、ノードはRRSetsなしで存在するかもしれません。 このノードは人影のない非端末です。
A node with no descendants is a leaf node. Empty leaf nodes do not exist.
子孫のいないノードは葉のノードです。 空の葉のノードは存在しません。
Note that at a zone boundary, the domain name owns data, including the NS RR set. In the delegating zone, the NS RR set is not authoritative, but that is of no consequence here. The domain name owns data; therefore, it exists.
ゾーン境界では、ドメイン名がNS RRセットを含むデータを所有していることに注意してください。 代表として派遣するゾーンでは、NS RRセットが正式ではありませんが、それはここの結果の全くものではありません。 ドメイン名はデータを所有しています。 したがって、それは存在しています。
2.3. When Is a Wildcard Domain Name Not Special?
2.3. ワイルドカードドメイン名はいつ特別ではありませんか?
When a wildcard domain name appears in a message's query section, no special processing occurs. An asterisk label in a query name only matches a single, corresponding asterisk label in the existing zone tree when the 4.3.2 algorithm is being followed.
ワイルドカードドメイン名がメッセージの質問部に現れる場合、どんな特別な処理も起こりません。 4.3.2アルゴリズムが続くことにされるのであるときだけ、質問名のアスタリスクラベルは既存のゾーン木で単一の、そして、対応するアスタリスクラベルに合っています。
When a wildcard domain name appears in the resource data of a record, no special processing occurs. An asterisk label in that context literally means just an asterisk.
ワイルドカードドメイン名が記録に関するリソースデータに現れる場合、どんな特別な処理も起こりません。 その文脈のアスタリスクラベルは文字通りまさしくアスタリスクを意味します。
3. Impact of a Wildcard Domain Name on a Response
3. ワイルドカードドメイン名の応答への影響
RFC 1034's description of how wildcards impact response generation is in its section 4.3.2. That passage contains the algorithm followed by a server in constructing a response. Within that algorithm, step 3, part 'c' defines the behavior of the wildcard.
セクション4.3.2にはワイルドカードがどう応答世代に影響を与えるかに関するRFC1034の記述があります。 その通路はアルゴリズムを含んでいます、続いて、応答を構成する際にサーバを含みます。 そのアルゴリズム、ステップ3の中では、部分'c'はワイルドカードの働きを定義します。
Lewis Standards Track [Page 10] RFC 4592 DNSEXT WCARD July 2006
ルイスStandardsはDNSEXT WCARD2006年7月にRFC4592を追跡します[10ページ]。
The algorithm in section 4.3.2 is not intended to be pseudo-code; that is, its steps are not intended to be followed in strict order. The "algorithm" is a suggested means of implementing the requirements. As such, in step 3, parts 'a', 'b', and 'c' do not have to be implemented in that order, provided that the result of the implemented code is compliant with the protocol's specification.
セクション4.3.2におけるアルゴリズムは中間コードであることを意図しません。 厳しいオーダーですなわち、ステップが続かれることを意図しません。 「アルゴリズム」は要件を実行する提案された手段です。 そういうものとして、部品'a'、'b'、および'c'はそのオーダーでステップ3では、実行される必要はありません、実行されたコードの結果がプロトコルの仕様で対応であれば。
3.1. Step 2
3.1. ステップ2
Step 2 of section 4.3.2 reads:
セクション4.3.2のステップ2は読みます:
# 2. Search the available zones for the zone which is the nearest # ancestor to QNAME. If such a zone is found, go to step 3, # otherwise step 4.
# 2. QNAMEの最も近い#先祖であるゾーンとして利用可能なゾーンを捜してください。 そのようなゾーンが見つけられるなら、ステップ3に行ってください。#さもなければ、4を踏んでください。
In this step, the most appropriate zone for the response is chosen. The significance of this step is that it means all of step 3 is being performed within one zone. This has significance when considering whether or not an SOA RR can ever be used for synthesis.
このステップでは、応答のための最も適切なゾーンは選ばれています。 このステップの意味はステップ3のすべてが1つのゾーンの中で実行されていることを意味するということです。 これには、今までに統合にSOA RRを使用できるかどうか考えるとき、意味があります。
3.2. Step 3
3.2. ステップ3
Step 3 is dominated by three parts, labeled 'a', 'b', and 'c'. But the beginning of the step is important and needs explanation.
ステップ3は'a'、'b'、および'c'とラベルされた3つの部品によって支配されます。 しかし、ステップの始まりは、重要であり、説明を必要とします。
# 3. Start matching down, label by label, in the zone. The # matching process can terminate several ways:
# 3. 合っている下である、ラベルごとに、ゾーンで始動してください。 #マッチング過程はいくつかの道を終えることができます:
The word 'matching' refers to label matching. The concept is based in the view of the zone as the tree of existing names. The query name is considered to be an ordered sequence of labels--as if the name were a path from the root to the owner of the desired data (which it is--3rd paragraph of RFC 1034, section 3.1).
'マッチ'という単語はラベルマッチングについて言及します。 概念は既存の名前の木としてゾーンの視点で基づいています。 質問名がまるで根から必要なデータの所有者まで名前が経路であるかのようにラベルの規則正しい系列であると考えられる、(どれ、それはそうです--、RFC1034の第3パラグラフ、セクション3.1)
The process of label matching a query name ends in exactly one of three choices, the parts 'a', 'b', and 'c'. Either the name is found, the name is below a cut point, or the name is not found.
ラベルが質問名に合う過程はちょうど3つの選択(部品'a'、'b'、および'c')の1つに終わります。 名前が見つけられるか、カットポイントの下に名前があるか、または名前は見つけられません。
Once one of the parts is chosen, the other parts are not considered (e.g., do not execute part 'c' and then change the execution path to finish in part 'b'). The process of label matching is also done independent of the query type (QTYPE).
部品の1つがいったん選ばれていると、他の部品は考えられません(例えば、部分'c'を実行しないでください、そして、次に、実行経路を変えて、'b'を一部終えてください)。 また、質問タイプ(QTYPE)の如何にかかわらずラベルマッチングの過程をします。
Parts 'a' and 'b' are not an issue for this clarification as they do not relate to record synthesis. Part 'a' is an exact match that results in an answer; part 'b' is a referral.
統合を記録するために関係しないとき、部品'a'と'b'はこの明確化のための問題ではありません。 パート'a'は答えをもたらす完全な一致です。 部分'b'は紹介です。
Lewis Standards Track [Page 11] RFC 4592 DNSEXT WCARD July 2006
ルイスStandardsはDNSEXT WCARD2006年7月にRFC4592を追跡します[11ページ]。
3.3. Part 'c'
3.3. 部分'c'
The context of part 'c' is that the process of label matching the labels of the query name has resulted in a situation in which there is no corresponding label in the tree. It is as if the lookup has "fallen off the tree".
部分'c'の文脈はラベルが質問名のラベルに合う過程がどんな対応するラベルも木にない状況をもたらしたということです。 それはルックアップが「木から落ちたこと」に似ています。
# c. If at some label, a match is impossible (i.e., the # corresponding label does not exist), look to see if [...] # the "*" label exists.
# c。 マッチが、あるラベルで不可能であるなら(すなわち、#対応するラベルは存在していません)、見るには、[…]であるなら見てください。 # 「*」ラベルは存在しています。
To help describe the process of looking 'to see if [...] the "*" label exists' a term has been coined to describe the last domain (node) matched. The term is "closest encloser".
'見る過程について説明するのを助けるために、'[…]「*」ラベルが存在しているなら用語が最後のドメイン(ノード)について説明するために鋳造されたのがわかるのが合っていました。 用語は「最も近いencloser」です。
3.3.1. Closest Encloser and the Source of Synthesis
3.3.1. 最も近いEncloserと統合の源
The closest encloser is the node in the zone's tree of existing domain names that has the most labels matching the query name (consecutively, counting from the root label downward). Each match is a "label match" and the order of the labels is the same.
最も近いencloserが最も多くのラベルが質問名に合っているゾーンの既存のドメイン名の木のノードである、(連続して、根から数えるのが下向きにラベルする、) 各マッチは「ラベルマッチ」です、そして、ラベルの注文は同じです。
The closest encloser is, by definition, an existing name in the zone. The closest encloser might be an empty non-terminal or even be a wildcard domain name itself. In no circumstances is the closest encloser to be used to synthesize records for the current query.
最も近いencloserは定義上ゾーンの既存の名前です。 最も近いencloserは人影のない非端末であるかワイルドカードドメイン名自体でさえあるかもしれません。 どんな事情でも、最も近いencloserは、現在の質問のための記録を統合するのに使用してはいけません。
The source of synthesis is defined in the context of a query process as that wildcard domain name immediately descending from the closest encloser, provided that this wildcard domain name exists. "Immediately descending" means that the source of synthesis has a name of the form:
統合の源は質問の過程の文脈ですぐに最も近いencloserから離すそのワイルドカードドメイン名と定義されます、このワイルドカードドメイン名が存在していれば。 aが統合の源で命名するフォームの「すぐに、下っている」手段:
<asterisk label>.<closest encloser>.
<アスタリスクラベル><の最も近いencloser>。
A source of synthesis does not guarantee having a RRSet to use for synthesis. The source of synthesis could be an empty non-terminal.
統合の源は統合の使用へのRRSetを有に保証しません。 統合の源は人影のない非端末であるかもしれません。
If the source of synthesis does not exist (not on the domain tree), there will be no wildcard synthesis. There is no search for an alternate.
統合の源が存在していないと(いずれのドメイン木に関しても、そうしません)、ワイルドカード統合が全くないでしょう。 補欠の捜索が全くありません。
The important concept is that for any given lookup process, there is at most one place at which wildcard synthetic records can be obtained. If the source of synthesis does not exist, the lookup terminates, and the lookup does not look for other wildcard records.
重要な概念はどんな与えられたルックアップの過程のためにも、ワイルドカードの合成の記録を得ることができる場所が最も1つにあるということです。 統合の源が存在していないなら、ルックアップは終わります、そして、ルックアップは他のワイルドカード記録を探しません。
Lewis Standards Track [Page 12] RFC 4592 DNSEXT WCARD July 2006
ルイスStandardsはDNSEXT WCARD2006年7月にRFC4592を追跡します[12ページ]。
3.3.2. Closest Encloser and Source of Synthesis Examples
3.3.2. 統合の例の最も近いEncloserと源
To illustrate, using the example zone in section 2.2.1 of this document, the following chart shows QNAMEs and the closest enclosers.
この.1通のセクション2.2ドキュメントの例のゾーンを使用して、例証するために、以下の図はQNAMEsと最も近いenclosersを見せています。
QNAME Closest Encloser Source of Synthesis
host3.example. example. *.example.
_telnet._tcp.host1.example. _tcp.host1.example. no source
_dns._udp.host2.example. host2.example. no source
_telnet._tcp.host3.example. example. *.example.
_chat._udp.host3.example. example. *.example.
foobar.*.example. *.example. no source
Synthesis host3.example例のQNAME Closest Encloser Source。 *.example。 _telnet_tcp.host1.example。 _ソース_dns_udp.host2.exampleいいえ、host2.example。tcp.host1.exampleいいえは_telnet_tcp.host3.example例の出典を明示します。 *.example。 _チャット_udp.host3.example例。 *.example foobar*.example。 *.exampleソースがありません。
3.3.3. Type Matching
3.3.3. マッチングをタイプしてください。
RFC 1034 concludes part 'c' with this:
RFC1034はこれで部分'c'を結論づけます:
# If the "*" label does not exist, check whether the name # we are looking for is the original QNAME in the query # or a name we have followed due to a CNAME. If the name # is original, set an authoritative name error in the # response and exit. Otherwise just exit. # # If the "*" label does exist, match RRs at that node # against QTYPE. If any match, copy them into the answer # section, but set the owner of the RR to be QNAME, and # not the node with the "*" label. Go to step 6.
# 「*」ラベルが存在しないなら、私たちが探している名前#が私たちがCNAMEのため従った質問#か名前でオリジナルのQNAMEであるかどうかチェックしてください。 名前#がオリジナルであるなら、#応答と出口に正式の名前誤りをはめ込んでください。 さもなければ、ただ出てください。 # # 「*」ラベルが存在するなら、そのノード#でQTYPEに対してRRsを合わせてください。 あらゆるマッチであるなら、答え#セクションにそれらをコピーしなさい、ただし、「*」ラベルでノードではなく、QNAMEと、#であるRRの所有者を設定してください。 ステップ6に行ってください。
The final paragraph covers the role of the QTYPE in the lookup process.
最終節はルックアップの過程でQTYPEの役割をカバーしています。
Based on implementation feedback and similarities between part 'a' and part 'c', a change to this passage has been made.
パート'a'と部分'c'の間の実現フィードバックと類似性に基づいて、この通路への変更は行われました。
The change is to add the following text to part 'c' prior to the instructions to "go to step 6":
変化は、指示の前に'c'を「何6インチも踏みに行ってください」に分けるために以下のテキストを加えることになっています。
If the data at the source of synthesis is a CNAME, and QTYPE
doesn't match CNAME, copy the CNAME RR into the answer section of
the response changing the owner name to the QNAME, change QNAME to
the canonical name in the CNAME RR, and go back to step 1.
統合の源のデータがCNAMEであり、QTYPEがCNAMEに合っていないなら、所有者名をQNAMEに変える応答の答え部にCNAME RRをコピーしてください、そして、QNAMEをCNAME RRの正準な名前に変えてください、そして、ステップ1に戻ってください。
This is essentially the same text in part 'a' covering the processing of CNAME RRSets.
これは一部CNAME RRSetsの処理をカバーであっている中の本質的には同じテキスト'a'です。
Lewis Standards Track [Page 13] RFC 4592 DNSEXT WCARD July 2006
ルイスStandardsはDNSEXT WCARD2006年7月にRFC4592を追跡します[13ページ]。
4. Considerations with Special Types
4. 特別なタイプがある問題
Sections 2 and 3 of this document discuss wildcard synthesis with respect to names in the domain tree and ignore the impact of types. In this section, the implication of wildcards of specific types is discussed. The types covered are those that have proven to be the most difficult to understand. The types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG, and "none", that is, empty non-terminal wildcard domain names.
このドキュメントのセクション2と3は、ドメイン木で名前に関してワイルドカード統合について論じて、タイプの影響を無視します。 このセクションで、特定のタイプのワイルドカードの含意について議論します。 カバーされたタイプは理解しているのが最も難しいと判明したものです。 タイプは、SOAと、NSと、CNAMEと、DNAMEと、SRVと、DSと、NSECと、RRSIGと、「なにも」、すなわち、空の非端末ワイルドカードドメイン名です。
4.1. SOA RRSet at a Wildcard Domain Name
4.1. ワイルドカードドメイン名におけるSOA RRSet
A wildcard domain name owning an SOA RRSet means that the domain is at the root of the zone (apex). The domain cannot be a source of synthesis because that is, by definition, a descendant node (of the closest encloser) and a zone apex is at the top of the zone.
SOA RRSetを所有しているワイルドカードドメイン名は、ドメインがゾーン(頂点)の根にあることを意味します。 それが定義上派生ノード(最も近いencloserの)であるので、ドメインは統合の源であるはずがありません、そして、ゾーンの頂点がゾーンの先端にあります。
Although a wildcard domain name owning an SOA RRSet can never be a source of synthesis, there is no reason to forbid the ownership of an SOA RRSet.
SOA RRSetを所有しているワイルドカードドメイン名は統合の源であるはずがありませんが、SOA RRSetの所有権を禁じる理由が全くありません。
For example, given this zone:
例えば、これを考えて、帯状になってください:
$ORIGIN *.example.
@ 3600 IN SOA <SOA RDATA>
3600 NS ns1.example.com.
3600 NS ns1.example.net.
www 3600 TXT "the www txt record"
$起源*.example。 @3600 IN SOA<SOA RDATA>3600NS ns1.example.com。 3600NS ns1.example.net「www txtは記録する」www3600TXT
A query for www.*.example.'s TXT record would still find the "the www txt record" answer. The asterisk label only becomes significant when section 4.3.2, step 3, part 'c' is in effect.
www*.example.のTXT記録のための質問はまだ「www txtは記録する」という答えに当たっているでしょう。 セクション4.3.2、ステップ3であるときにだけ、アスタリスクラベルは重要になって、部分'c'は有効です。
Of course, there would need to be a delegation in the parent zone, "example." for this to work too. This is covered in the next section.
もちろん、そこでは、親ゾーンの代表団、「例」であることが必要でしょう。. また、これが扱うように。 これは次のセクションで覆われています。
4.2. NS RRSet at a Wildcard Domain Name
4.2. ワイルドカードドメイン名におけるナノ秒RRSet
With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now in place, the semantics of a wildcard domain name owning an NS RRSet has come to be poorly defined. The dilemma relates to a conflict between the rules for synthesis in part 'c' and the fact that the resulting synthesis generates a record for which the zone is not authoritative. In a DNSSEC signed zone, the mechanics of signature management (generation and inclusion in a message) have become unclear.
現在のDNSSEC[RFC4033、RFC4034、RFC4035]の定義が適所にあった状態で、NS RRSetを所有しているワイルドカードドメイン名の意味論は不十分に定義されるようになりました。 ジレンマは統合のためのゾーンが正式でない一部'c'と結果として起こる統合がaを発生させるという事実が記録するという規則の間の闘争に関連します。 DNSSECでは、サインされたゾーン、署名管理(メッセージでの世代と包含)の整備士は不明瞭になりました。
Lewis Standards Track [Page 14] RFC 4592 DNSEXT WCARD July 2006
ルイスStandardsはDNSEXT WCARD2006年7月にRFC4592を追跡します[14ページ]。
Salient points of the working group discussion on this topic are summarized in section 4.2.1.
この話題についてのワーキンググループ議論の顕著なポイントはセクション4.2.1でまとめられます。
As a result of these discussions, there is no definition given for wildcard domain names owning an NS RRSet. The semantics are left undefined until there is a clear need to have a set defined, and until there is a clear direction to proceed. Operationally, inclusion of wildcard NS RRSets in a zone is discouraged, but not barred.
これらの議論の結果、NS RRSetを所有しているワイルドカードドメイン名のために与えられた定義が全くありません。 定義されたセットを持つ明確な必要があって、続かせる明確な指示があるまで、意味論は未定義の状態でおかれます。 ゾーンでのワイルドカードNS RRSetsの包含は、操作上、がっかりしていますが、禁じられません。
4.2.1. Discarded Notions
4.2.1. 捨てられた概念
Prior to DNSSEC, a wildcard domain name owning a NS RRSet appeared to be workable, and there are some instances in which it is found in deployments using implementations that support this. Continuing to allow this in the specification is not tenable with DNSSEC. The reason is that the synthesis of the NS RRSet is being done in a zone that has delegated away the responsibility for the name. This "unauthorized" synthesis is not a problem for the base DNS protocol, but DNSSEC in affirming the authorization model for DNS exposes the problem.
DNSSECの前では、NS RRSetを所有しているワイルドカードドメイン名は実行可能であるように見えました、そして、それが展開でこれを支持する実現を使用することで見つけられるいくつかの例があります。 仕様にずっとこれを許容するのはDNSSECと共に支持できません。 理由は名前への責任を遠くに代表として派遣したゾーンでNS RRSetの統合をしているということです。 この「権限のない」統合はベースDNSプロトコルのための問題ではありませんが、DNSのために認可モデルを確言することにおけるDNSSECは問題を露出します。
Outright banning of wildcards of type NS is also untenable as the DNS protocol does not define how to handle "illegal" data. Implementations may choose not to load a zone, but there is no protocol definition. The lack of the definition is complicated by having to cover dynamic update [RFC2136] and zone transfers, as well as loading at the master server. The case of a client (resolver, caching server) getting a wildcard of type NS in a reply would also have to be considered.
また、DNSプロトコルが「不法な」データを扱う方法を定義しないとき、タイプNSのワイルドカードの完全な禁止も支持できません。 実現は、ゾーンをロードしないのを選ぶかもしれませんが、プロトコル定義が全くありません。 定義の不足は、ダイナミックなアップデート[RFC2136]とマスターサーバでロードすることと同様にゾーン転送をカバーしなければならないことによって、複雑にされます。また、回答でタイプNSのワイルドカードを手に入れるクライアント(レゾルバ、キャッシュサーバ)のケースは考えられなければならないでしょう。
Given the daunting challenge of a complete definition of how to ban such records, dealing with existing implementations that permit the records today is a further complication. There are uses of wildcard domain name owning NS RRSets.
今日記録を可能にする既存の実現に対処して、どうそのような記録を禁止するかに関する完全な定義の手ごわい挑戦を与えているのは、さらなる複雑さです。 NS RRSetsを所有しているワイルドカードドメイン名の用途があります。
One compromise proposed would have redefined wildcards of type NS to not be used in synthesis, this compromise fell apart because it would have required significant edits to the DNSSEC signing and validation work. (Again, DNSSEC catches unauthorized data.)
提案された1つの妥協が統合に使用されないようにタイプNSのワイルドカードを再定義したでしょう、DNSSEC調印と合法化仕事に重要な編集を必要としたでしょう、したがって、この妥協はバラバラに壊れました。 (一方、DNSSECは権限のないデータを捕らえます。)
With no clear consensus forming on the solution to this dilemma, and the realization that wildcards of type NS are a rarity in operations, the best course of action is to leave this open-ended until "it matters".
最も良い行動はこのジレンマ、およびタイプNSのワイルドカードが稼働中であるまれなことであるという認識の解決策で形成されないどんな明確なコンセンサスをもってもこれを「重要になる」まで制限のない状態でおくことです。
Lewis Standards Track [Page 15] RFC 4592 DNSEXT WCARD July 2006
ルイスStandardsはDNSEXT WCARD2006年7月にRFC4592を追跡します[15ページ]。
4.3. CNAME RRSet at a Wildcard Domain Name
4.3. ワイルドカードドメイン名におけるCNAME RRSet
The issue of a CNAME RRSet owned by a wildcard domain name has prompted a suggested change to the last paragraph of step 3c of the algorithm in 4.3.2. The changed text appears in section 3.3.3 of this document.
ワイルドカードドメイン名によって所有されていたCNAME RRSetの問題が中でアルゴリズムのステップ3cの最後のパラグラフへの提案された変化をうながした、4.3、.2 変えられたテキストはこの.3通のセクション3.3ドキュメントに現れます。
4.4. DNAME RRSet at a Wildcard Domain Name
4.4. ワイルドカードドメイン名におけるDNAME RRSet
Ownership of a DNAME [RFC2672] RRSet by a wildcard domain name
represents a threat to the coherency of the DNS and is to be avoided
or outright rejected. Such a DNAME RRSet represents non-
deterministic synthesis of rules fed to different caches. As caches
are fed the different rules (in an unpredictable manner) the caches
will cease to be coherent. ("As caches are fed" refers to the
storage in a cache of records obtained in responses by recursive or
iterative servers.)
ワイルドカードドメイン名によるDNAME[RFC2672]RRSetの所有権は、DNSの一貫性への脅威を表して、避けられるか完全に拒絶されていることです。 そのようなDNAME RRSetは異なったキャッシュに与えられた規則の非決定論的な統合を表します。 異なった規則(予測できない方法による)をキャッシュに与えるとき、キャッシュは、一貫性を持っているのをやめるでしょう。 「キャッシュが食べさせられるとき」。(再帰的であるか繰り返しのサーバによって応答で得られた記録のキャッシュにおける格納について言及する、)
For example, assume one cache, responding to a recursive request, obtains the following record:
例えば、再帰的な要求に応じて、1つのキャッシュが以下の記録を得ると仮定してください:
"a.b.example. DNAME foo.bar.example.net."
「a.b.の例。」 "DNAME foo.bar.example.net"。
and another cache obtains:
そして、別のキャッシュは以下を得ます。
"b.example. DNAME foo.bar.example.net."
「b.の例。」 "DNAME foo.bar.example.net"。
both generated from the record:
両方を記録から発生させました:
"*.example. DNAME foo.bar.example.net."
「*.example。」 "DNAME foo.bar.example.net"。
by an authoritative server.
正式のサーバで。
The DNAME specification is not clear on whether DNAME records in a cache are used to rewrite queries. In some interpretations, the rewrite occurs; in others, it does not. Allowing for the occurrence of rewriting, queries for "sub.a.b.example. A" may be rewritten as "sub.foo.bar.tld. A" by the former caching server and may be rewritten as "sub.a.foo.bar.tld. A" by the latter. Coherency is lost, and an operational nightmare ensues.
キャッシュにおけるDNAME記録が質問を書き直すのに使用されるかどうかに関してDNAME仕様は明確ではありません。 いくつかの解釈では、書き直しは起こります。 他のものでは、それはそうしません。 書き直しの発生、「sub.a.b.の例」のための質問を考慮します。 「A」は"sub.foo.bar.tld"として書き直されるかもしれません。 前者による「A」は、サーバをキャッシュして、"sub.a. foo.bar.tld"として書き直されるかもしれません。 後者による「A。」 一貫性は無くなります、そして、操作上の悪夢は続きます。
Another justification for a recommendation to avoid the use of wildcard DNAME records is the observation that such a record could synthesize a DNAME owned by "sub.foo.bar.example." and "foo.bar.example.". There is a restriction in the DNAME definition that no domain exist below a DNAME-owning domain; hence, the wildcard DNAME is to be avoided.
ワイルドカードDNAME記録の使用を避けるという推薦のための別の正当化はそのような記録が"sub.foo.bar.example" "foo.bar.example"によって所有されていたDNAMEを統合するかもしれないという観測です。 ドメインが全くDNAMEを所有しているドメインの下に存在していないというDNAME定義における制限があります。 したがって、ワイルドカードDNAMEは避けられることになっています。
Lewis Standards Track [Page 16] RFC 4592 DNSEXT WCARD July 2006
ルイスStandardsはDNSEXT WCARD2006年7月にRFC4592を追跡します[16ページ]。
4.5. SRV RRSet at a Wildcard Domain Name
4.5. ワイルドカードドメイン名におけるSRV RRSet
The definition of the SRV RRset is RFC 2782 [RFC2782]. In the definition of the record, there is some confusion over the term "Name". The definition reads as follows:
SRV RRsetの定義はRFC2782です[RFC2782]。 記録の定義には、「名前」という期間、何らかの混乱があります。 定義は以下の通り読みます:
# The format of the SRV RR ... # _Service._Proto.Name TTL Class SRV Priority Weight Port Target ... # Name # The domain this RR refers to. The SRV RR is unique in that the # name one searches for is not this name; the example near the end # shows this clearly.
# SRV RRの形式… # _サービス_Proto.Name TTLクラスSRV優先権重さのポート目標… # このRRが言及するドメインと#、を命名してください。 SRV RRは1つが捜し求める#名がこの名前でないので、ユニークです。 終わり#頃の例は明確にこれを示しています。
Do not confuse the definition "Name" with the owner name. That is, once removing the _Service and _Proto labels from the owner name of the SRV RRSet, what remains could be a wildcard domain name but this is immaterial to the SRV RRSet.
定義「名前」を所有者名に間違えないでください。 すなわち、一度Serviceと_プロトが所有者名(SRV RRSet)からラベルする_を取り外して、残っているものはワイルドカードドメイン名であるかもしれませんが、これはSRV RRSetに重要でないです。
For example, if an SRV record is the following:
SRV記録が例えば以下であるなら:
_foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.
_foo_udp*.example。 10800 IN SRV0 1 9の古い遅いbox.example。
*.example is a wildcard domain name and although it is the Name of the SRV RR, it is not the owner (domain name). The owner domain name is "_foo._udp.*.example.", which is not a wildcard domain name.
*.exampleはワイルドカードドメイン名です、そして、SRV RRのNameですが、それは所有者(ドメイン名)ではありません。 ワイルドカードドメイン名でない「所有者ドメイン名は」 _が. _udp*.exampleをfooするということです。」
A query for the SRV RRSet of "_foo._udp.bar.example." (class IN), will result in a match of the name "*.example." (assuming there is no bar.example.) and not a match of the SRV record shown. If there is no SRV RRSet at "*.example.", the answer section will reflect that (be empty or a CNAME RRset).
「」 _foo_udp.bar.exampleのSRV RRSetのための質問。」 (中にクラスがある状態で), 「名前」 *.exampleのマッチをもたらすでしょう。」 (bar.exampleが全くないと仮定します。) そして、示されたSRV記録のマッチでない。 「いいえ、」 *.exampleのSRV RRSetあれば。」、答え部はそれを反映するでしょう(空であって、CNAME RRsetになってください)。
The confusion is likely based on the mixture of the specification of the SRV RR and the description of a "use case".
混乱は「ケースを使用する」というSRV RRとaの記述の仕様の混合物に基づいてありそうです。
4.6. DS RRSet at a Wildcard Domain Name
4.6. ワイルドカードドメイン名におけるDS RRSet
A DS RRSet owned by a wildcard domain name is meaningless and harmless. This statement is made in the context that an NS RRSet at a wildcard domain name is undefined. At a non-delegation point, a DS RRSet has no value (no corresponding DNSKEY RRSet will be used in DNSSEC validation). If there is a synthesized DS RRSet, it alone will not be very useful as it exists in the context of a delegation point.
ワイルドカードドメイン名によって所有されていたDS RRSetは無意味であって、無害です。 この声明はワイルドカードドメイン名におけるNS RRSetがある文脈で出されます。未定義。 非代表団ポイントでは、DS RRSetは値を全く持っていません(どんな対応するDNSKEY RRSetもDNSSEC合法化に使用されないでしょう)。 統合DS RRSetがあれば、代表団ポイントの文脈に存在するとき、だけそれほど役に立ちません。
Lewis Standards Track [Page 17] RFC 4592 DNSEXT WCARD July 2006
ルイスStandardsはDNSEXT WCARD2006年7月にRFC4592を追跡します[17ページ]。
4.7. NSEC RRSet at a Wildcard Domain Name
4.7. ワイルドカードドメイン名におけるnsec RRSet
Wildcard domain names in DNSSEC signed zones will have an NSEC RRSet. Synthesis of these records will only occur when the query exactly matches the record. Synthesized NSEC RRs will not be harmful as they will never be used in negative caching or to generate a negative response [RFC2308].
サインされたゾーンが望んでいるDNSSECのワイルドカードドメイン名には、NSEC RRSetがあります。 質問がまさに記録に合っていると、これらの記録の統合は起こるだけでしょう。 または、彼らが否定的キャッシュに決して使用されないので統合NSEC RRsが有害にならない、否定応答[RFC2308]を発生させるように。
4.8. RRSIG at a Wildcard Domain Name
4.8. ワイルドカードドメイン名におけるRRSIG
RRSIG records will be present at a wildcard domain name in a signed zone and will be synthesized along with data sought in a query. The fact that the owner name is synthesized is not a problem as the label count in the RRSIG will instruct the verifying code to ignore it.
RRSIG記録は、サインされたゾーンのワイルドカードドメイン名で存在して、質問で求められたデータと共に統合されるでしょう。 RRSIGでのラベルカウントが、それを無視するよう検証コードに命令するので、所有者名が統合されるという事実は問題ではありません。
4.9. Empty Non-terminal Wildcard Domain Name
4.9. 空の非端末ワイルドカードドメイン名
If a source of synthesis is an empty non-terminal, then the response will be one of no error in the return code and no RRSet in the answer section.
統合の源が人影のない非端末であるなら、応答は復帰コードにおける誤りがなくてまた答え部でRRSetがない1つになるでしょう。
5. Security Considerations
5. セキュリティ問題
This document is refining the specifications to make it more likely that security can be added to DNS. No functional additions are being made, just refining what is considered proper to allow the DNS, security of the DNS, and extending the DNS to be more predictable.
このドキュメントは、DNSにセキュリティを加えることができるのをよりありそうにするように仕様を洗練しています。 どんな機能的な追加もしていません、ただDNS、DNSと、より予測できるためにDNSを広げるセキュリティを許容するために適切であると考えられることを洗練して。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20,
October 1969.
[RFC20] サーフ、V.、「ネットワーク置き換えのためのASCII書式」、RFC20、1969年10月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996.
[RFC1995] 太田、M.、「DNSの増加のゾーン転送」、RFC1995、1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Lewis Standards Track [Page 18] RFC 4592 DNSEXT WCARD July 2006
ルイスStandardsはDNSEXT WCARD2006年7月にRFC4592を追跡します[18ページ]。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2308] アンドリュース、M.、「DNS質問(DNS NCACHE)の否定的キャッシュ」、RFC2308、1998年3月。
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
2672, August 1999.
[RFC2672] クロフォード、M.、「非端末DNS名前リダイレクション」、RFC2672、1999年8月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P.、およびL.Esibov、「サービスの位置を指定するためのDNS RR(DNS SRV)」、RFC2782(2000年2月)。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4033] Arends、R.Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.が上昇したと「リソースはDNSセキュリティ拡張子のために記録します」、RFC4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4035]Arends(R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ)は「DNSセキュリティ拡張子のための変更について議定書の中で述べます」、RFC4035、2005年3月。
6.2. Informative References
6.2. 有益な参照
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
Vixie、P.、トムソン、S.、Rekhter、Y.、およびJ.が縛った[RFC2136]、「ドメインネームシステムにおけるダイナミックなアップデート(DNSアップデート)」、RFC2136(1997年4月)。
7. Others Contributing to the Document
7. ドキュメントに貢献する他のもの
This document represents the work of a large working group. The editor merely recorded its collective wisdom.
このドキュメントは大きいワーキンググループの仕事を表します。 エディタは単に集合的な知恵を記録しました。
Comments on this document can be sent to the editor or the mailing list for the DNSEXT WG, namedroppers@ops.ietf.org.
DNSEXT WG、 namedroppers@ops.ietf.org のためのエディタかメーリングリストにこのドキュメントのコメントを送ることができます。
Editor's Address
エディタのアドレス
Edward Lewis NeuStar 46000 Center Oak Plaza Sterling, VA 20166, US
エドワードルイスNeuStar46000センターオーク広場英貨、ヴァージニア 20166、米国
Phone: +1-571-434-5468 EMail: ed.lewis@neustar.biz
以下に電話をしてください。 +1-571-434-5468 メールしてください: ed.lewis@neustar.biz
Lewis Standards Track [Page 19] RFC 4592 DNSEXT WCARD July 2006
ルイスStandardsはDNSEXT WCARD2006年7月にRFC4592を追跡します[19ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Lewis Standards Track [Page 20]
ルイス標準化過程[20ページ]
一覧
スポンサーリンク
