RFC2915 日本語訳
2915 The Naming Authority Pointer (NAPTR) DNS Resource Record. M.Mealling, R. Daniel. September 2000. (Format: TXT=41521 bytes) (Obsoleted by RFC3401, RFC3402, RFC3403, RFC3404) (Updates RFC2168) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Mealling
Request for Comments: 2915 Network Solutions, Inc.
Updates: 2168 R. Daniel
Category: Standards Track DATAFUSION, Inc.
September 2000
コメントを求める要求を荒びきにして、作業部会M.をネットワークでつないでください: 2915はソリューションInc.アップデートをネットワークでつなぎます: 2168年のR.ダニエルカテゴリ: 標準化過程DATAFUSION Inc.2000年9月
The Naming Authority Pointer (NAPTR) DNS Resource Record
命名権威ポインタ(NAPTR)DNSリソース記録
Status of this Memo
この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 (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document describes a Domain Name System (DNS) resource record which specifies a regular expression based rewrite rule that, when applied to an existing string, will produce a new domain label or Uniform Resource Identifier (URI). Depending on the value of the flags field of the resource record, the resulting domain label or URI may be used in subsequent queries for the Naming Authority Pointer (NAPTR) resource records (to delegate the name lookup) or as the output of the entire process for which this system is used (a resolution server for URI resolution, a service URI for ENUM style e.164 number to URI mapping, etc).
このドキュメントはどれが正規表現を指定するかが既存のストリングに適用されると新しいドメインラベルかUniform Resource Identifier(URI)を作り出す書換規則を基礎づけたというドメインネームシステム(DNS)リソース記録について説明します。 旗の値によって、Naming Authority Pointer(NAPTR)リソース記録(ルックアップという名前を代表として派遣する)かこのシステムが使用されている全体の過程の出力(URI解決のための解決サーバ、URIマッピングへのENUMスタイルe.164番号のためのサービスURIなど)として結果として起こるリソース記録、ドメインラベルまたはURIの分野はその後の質問に使用されるかもしれません。
This allows the DNS to be used to lookup services for a wide variety of resource names (including URIs) which are not in domain name syntax. Reasons for doing this range from URN Resource Discovery Systems to moving out-of-date services to new domains.
これは、DNSがドメイン名構文でないさまざまなリソース名(URIを含んでいる)にルックアップサービスに使用されるのを許容します。 これをする理由はURN ResourceディスカバリーSystemsから新しいドメインに対する感動的な時代遅れなサービスに変化します。
This document updates the portions of RFC 2168 specifically dealing with the definition of the NAPTR records and how other, non-URI specific applications, might use NAPTR.
このドキュメントは、明確にNAPTR記録とどのようにに関する他の定義の取扱う、非URIのRFC2168の特定のアプリケーションの部分をアップデートするか、そして、NAPTRを使用するかもしれません。
Mealling & Daniel Standards Track [Page 1] RFC 2915 NAPTR DNS RR September 2000
食事とダニエルStandardsはNAPTR DNS RR2000年9月にRFC2915を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . 3
3. Substitution Expression Grammar . . . . . . . . . . . . . . 7
4. The Basic NAPTR Algorithm . . . . . . . . . . . . . . . . . 8
5. Concerning How NAPTR Uses SRV Records . . . . . . . . . . . 9
6. Application Specifications . . . . . . . . . . . . . . . . . 10
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. DNS Packet Format . . . . . . . . . . . . . . . . . . . . . 13
9. Master File Format . . . . . . . . . . . . . . . . . . . . . 14
10. Advice for DNS Administrators . . . . . . . . . . . . . . . 14
11. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
13. Security Considerations . . . . . . . . . . . . . . . . . . 15
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 NAPTR RRは.3 3をフォーマットします。 代替表現文法. . . . . . . . . . . . . . 7 4。 基本的なNAPTRアルゴリズム. . . . . . . . . . . . . . . . . 8 5。 NAPTRがどうSRV記録. . . . . . . . . . . 9 6を使用するかに関して。 アプリケーション仕様. . . . . . . . . . . . . . . . . 10 7。 例. . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1の例1の.107.2の例2の.127.3の例3の.138。 DNSパケット・フォーマット. . . . . . . . . . . . . . . . . . . . . 13 9。 基本ファイル形式. . . . . . . . . . . . . . . . . . . . . 14 10。 DNS管理者. . . . . . . . . . . . . . . 14 11のためのアドバイス。 注意. . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12。 IANA問題. . . . . . . . . . . . . . . . . . . . 15 13。 セキュリティ問題. . . . . . . . . . . . . . . . . . 15 14。 作者の.16の参照箇所. . . . . . . . . . . . . . . . . . . . . . . . . 16のものが.17の完全な著作権宣言文. . . . . . . . . . . . . . . . . . 18を記述するという承認
1. Introduction
1. 序論
This RR was originally produced by the URN Working Group [3] as a way to encode rule-sets in DNS so that the delegated sections of a URI could be decomposed in such a way that they could be changed and re- delegated over time. The result was a Resource Record that included a regular expression that would be used by a client program to rewrite a string into a domain name. Regular expressions were chosen for their compactness to expressivity ratio allowing for a great deal of information to be encoded in a rather small DNS packet.
このRRは元々、URIの代表として派遣されたセクションをそれらを変えることができたような方法で分解して、時間がたつにつれて再代表として派遣することができるようにDNSで規則セットをコード化する方法としてURN作業部会[3]によって生産されました。 結果はストリングをドメイン名に書き直すのにクライアントプログラムで使用される正規表現を含んでいたResource Recordでした。 多くの情報がかなり小さいDNSパケットでコード化されるのを許容して、正規表現は表現度比への彼らのコンパクト性に選ばれました。
The function of rewriting a string according to the rules in a record has usefulness in several different applications. This document defines the basic assumptions to which all of those applications must adhere to. It does not define the reasons the rewrite is used, what the expected outcomes are, or what they are used for. Those are specified by applications that define how they use the NAPTR record and algorithms within their contexts.
記録の規則に従ってストリングを書き直す機能には、いくつかの異なったアプリケーションにおける有用性があります。 このドキュメントはそれらのアプリケーションのすべてがくっつかなければならない基本仮定を定義します。 それは理由を定義しません。使用される書き直し、期待される成果が何であるかということである、またはそれらが使用されること。 それらはそれらがそれらの文脈の中でどうNAPTR記録とアルゴリズムを使用するかを定義するアプリケーションで指定されます。
Flags and other fields are also specified in the RR to control the rewrite procedure in various ways or to provide information on how to communicate with the host at the domain name that was the result of the rewrite.
また、旗と他の分野は、いろいろ書き直し手順を制御するか、または書き直しの結果であったドメイン名でどうホストとコミュニケートするかの情報を提供するためにRRで指定されます。
Mealling & Daniel Standards Track [Page 2] RFC 2915 NAPTR DNS RR September 2000
食事とダニエルStandardsはNAPTR DNS RR2000年9月にRFC2915を追跡します[2ページ]。
The final result is a RR that has several fields that interact in a non-trivial but implementable way. This document specifies those fields and their values.
最終的な結果は重要な、しかし、実行可能な方法で相互作用するいくつかの分野を持っているRRです。 このドキュメントはそれらの分野とそれらの値を指定します。
This document does not define applications that utilizes this rewrite functionality. Instead it specifies just the mechanics of how it is done. Why its done, what the rules concerning the inputs, and the types of rules used are reserved for other documents that fully specify a particular application. This separation is due to several different applications all wanting to take advantage of the rewrite rule lookup process. Each one has vastly different reasons for why and how it uses the service, thus requiring that the definition of the service be generic.
このドキュメントはこの書き直しの機能性を利用するアプリケーションを定義しません。 代わりに、それはまさしくどう完了しているかに関する整備士を指定します。 入力に関する規則、および使用される規則のタイプはそうです。それが行われた何、特定用途を完全に指定する他のドキュメントのために、予約されるか。 この分離は書換規則ルックアップの過程を利用したがっているいくつかの異なったアプリケーションのすべてためです。 それぞれには、なぜとそれがどうサービスを利用するか広大に異なった理由があります、その結果、サービスの定義が一般的であることが必要です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
All references to Uniform Resource Identifiers in this document
adhere to the 'absoluteURI' production of the "Collected ABNF"
found in RFC 2396 [9]. Specifically, the semantics of URI
References do not apply since the concept of a Base makes no sense
here.
Uniform Resource Identifierのすべての参照が本書ではRFC2396[9]で見つけられた「集まっているABNF」の'absoluteURI'生産を固く守ります。 明確に、基地の概念以来Referencesが適用しないURIの意味論はここで意味をなさないです。
2. NAPTR RR Format
2. NAPTR RR形式
The format of the NAPTR RR is given below. The DNS type code [1] for NAPTR is 35.
NAPTR RRの書式を以下に与えます。 NAPTRのためのDNSタイプコード[1]は35です。
Domain TTL Class Type Order Preference Flags Service Regexp Replacement
ドメインTTLクラスタイプオーダー好みはサービスRegexp交換に旗を揚げさせます。
Domain
The domain name to which this resource record refers. This is the
'key' for this entry in the rule database. This value will either
be the first well known key (<something>.uri.arpa for example) or
a new key that is the output of a replacement or regexp rewrite.
Beyond this, it has the standard DNS requirements [1].
ドメイン、このリソース記録が参照されるドメイン名。 これは規則データベースにおけるこのエントリーのための'キー'です。 この値が最初のよく知られているキーになる、(<、何か、例えば、>.uri.arpa) または、交換かregexp書き直しの出力である新しいキー。 これを超えて、それには、標準のDNS要件[1]があります。
TTL
Standard DNS meaning [1].
TTL Standard DNS意味[1]。
Class
Standard DNS meaning [1].
クラスStandard DNS意味[1]。
Type
The Type Code [1] for NAPTR is 35.
[1] NAPTRが35歳であるので、Type Codeをタイプしてください。
Mealling & Daniel Standards Track [Page 3] RFC 2915 NAPTR DNS RR September 2000
食事とダニエルStandardsはNAPTR DNS RR2000年9月にRFC2915を追跡します[3ページ]。
Order
A 16-bit unsigned integer specifying the order in which the NAPTR
records MUST be processed to ensure the correct ordering of
rules. Low numbers are processed before high numbers, and once a
NAPTR is found whose rule "matches" the target, the client MUST
NOT consider any NAPTRs with a higher value for order (except as
noted below for the Flags field).
規則の正しい注文を確実にするためにNAPTR記録を処理しなければならないオーダーをA16ビットの符号のない整数指定に注文してください。 低い数字は大きい数の前に処理されます、そして、規則が目標に「合わせている」NAPTRがいったん見つけられると、クライアントはオーダー(Flags分野のために以下に述べられるのを除いた)のために、より高い値がある少しのNAPTRsも考えてはいけません。
Preference
A 16-bit unsigned integer that specifies the order in which NAPTR
records with equal "order" values SHOULD be processed, low
numbers being processed before high numbers. This is similar to
the preference field in an MX record, and is used so domain
administrators can direct clients towards more capable hosts or
lighter weight protocols. A client MAY look at records with
higher preference values if it has a good reason to do so such as
not understanding the preferred protocol or service.
同輩と共にどのNAPTR記録でオーダーを指定する16ビットの符号のない整数が「注文される」という好みのA値のSHOULDが処理されて、安値は大きい数の前に処理されていた状態で存在に付番します。 これは、MX記録の選択領域と同様であり、ドメイン管理者が、よりできるホストか、より軽い重さのプロトコルにクライアントを向けることができるように、使用されています。 それに都合のよいプロトコルかサービスを理解していないのなどようにそうする十分な理由があるなら、クライアントは、より高い好みの値がある記録を見るかもしれません。
The important difference between Order and Preference is that
once a match is found the client MUST NOT consider records with a
different Order but they MAY process records with the same Order
but different Preferences. I.e., Preference is used to give weight
to rules that are considered the same from an authority
standpoint but not from a simple load balancing standpoint.
OrderとPreferenceの重要な違いはマッチがいったん見つけられるとクライアントが異なったOrderがある記録を考えてはいけませんが、彼らが同じOrderにもかかわらず、異なったPreferencesと共に記録を処理するかもしれないということです。 すなわち、Preferenceは権威見地から同じように考えられる規則を補強するのに使用されますが、簡単なロードバランシング見地から使用されるというわけではありません。
Flags
A <character-string> containing flags to control aspects of the
rewriting and interpretation of the fields in the record. Flags
are single characters from the set [A-Z0-9]. The case of the
alphabetic characters is not significant.
書き直しの局面と記録における、分野の解釈を制御するために旗を含むA<文字列>に旗を揚げさせます。 旗はセット[A-Z0-9]からの単独のキャラクタです。 英字のケースは重要ではありません。
At this time only four flags, "S", "A", "U", and "P", are
defined. The "S", "A" and "U" flags denote a terminal lookup.
This means that this NAPTR record is the last one and that the
flag determines what the next stage should be. The "S" flag
means that the next lookup should be for SRV records [4]. See
Section 5 for additional information on how NAPTR uses the SRV
record type. "A" means that the next lookup should be for either
an A, AAAA, or A6 record. The "U" flag means that the next step
is not a DNS lookup but that the output of the Regexp field is an
URI that adheres to the 'absoluteURI' production found in the
ABNF of RFC 2396 [9]. Since there may be applications that use
NAPTR to also lookup aspects of URIs, implementors should be
aware that this may cause loop conditions and should act
accordingly.
このとき、「S」、「A」、「U」、および「P」という4個の旗だけが、定義されます。 旗が指示する「S」、「A」、および「u」a端末のルックアップ。 これは、このNAPTR記録が最後のものであり、旗が、次のステージが何であるべきであるかを決定することを意味します。 「S」旗は、次のルックアップがSRV記録[4]のためのものであるべきであることを意味します。 NAPTRがどうSRVレコード種類を使用するかに関する追加情報に関してセクション5を見てください。 次のルックアップがA、AAAA、またはA6記録のためのものであるべきである手段。 「U」旗は、次のステップがDNSルックアップではありませんが、Regexp分野の出力がRFC2396[9]のABNFで見つけられた'absoluteURI'生産を固く守るURIであることを意味します。 URIのルックアップ局面にもNAPTRを使用する利用があるかもしれないので、作成者はこれが輪の状態を引き起こすかもしれなくて、善処するべきであるのを意識しているべきです。
Mealling & Daniel Standards Track [Page 4] RFC 2915 NAPTR DNS RR September 2000
食事とダニエルStandardsはNAPTR DNS RR2000年9月にRFC2915を追跡します[4ページ]。
The "P" flag says that the remainder of the application side
algorithm shall be carried out in a Protocol-specific fashion.
The new set of rules is identified by the Protocol specified in
the Services field. The record that contains the 'P' flag is the
last record that is interpreted by the rules specified in this
document. The new rules are dependent on the application for
which they are being used and the protocol specified. For
example, if the application is a URI RDS and the protocol is WIRE
then the new set of rules are governed by the algorithms
surrounding the WIRE HTTP specification and not this document.
「P」旗は、アプリケーションサイドアルゴリズムの残りがプロトコル特有のファッションで行われると言います。 新しいセットの規則はServices分野で指定されたプロトコルによって特定されます。 'P'旗を含む記録は本書では指定された規則で解釈される最後の記録です。 新しい規則はそれらが使用されていて、プロトコルが指定したアプリケーションに依存しています。 例えば、アプリケーションがURI RDSであり、プロトコルがWIREであるなら、新しいセットの規則はこのドキュメントではなく、WIRE HTTP仕様を囲むアルゴリズムで支配されます。
The remaining alphabetic flags are reserved for future versions
of the NAPTR specification. The numeric flags may be used for
local experimentation. The S, A, U and P flags are all mutually
exclusive, and resolution libraries MAY signal an error if more
than one is given. (Experimental code and code for assisting in
the creation of NAPTRs would be more likely to signal such an
error than a client such as a browser). It is anticipated that
multiple flags will be allowed in the future, so implementers
MUST NOT assume that the flags field can only contain 0 or 1
characters. Finally, if a client encounters a record with an
unknown flag, it MUST ignore it and move to the next record. This
test takes precedence even over the "order" field. Since flags
can control the interpretation placed on fields, a novel flag
might change the interpretation of the regexp and/or replacement
fields such that it is impossible to determine if a record
matched a given target.
残っているアルファベット旗はNAPTR仕様の将来のバージョンのために予約されます。 数値旗は地方の実験に使用されるかもしれません。 S、A、U、およびP旗はすべて互いに排他的です、そして、1つ以上を与えるなら、解決ライブラリは誤りを示すかもしれません。 (NAPTRsの創造を助けるための実験コードとコードはブラウザなどのクライアントよりそのような誤りに合図しそうでしょう。) implementersが、旗の分野が0か1文字しか含むことができないと仮定してはいけなくて、複数の旗が将来許容されると予期されます。 最終的に、未知の旗でクライアントが記録に遭遇するなら、それは、それを無視して、次の記録に動かなければなりません。 このテストは「オーダー」分野の上でさえ優先します。 旗がフィールドに置かれた解釈を制御できるので、目新しい旗がregexp、そして/または、交換分野の解釈を変えるかもしれないので、記録が与えられた目標に合っていたかどうか決定するのは不可能です。
The "S", "A", and "U" flags are called 'terminal' flags since
they halt the looping rewrite algorithm. If those flags are not
present, clients may assume that another NAPTR RR exists at the
domain name produced by the current rewrite rule. Since the "P"
flag specifies a new algorithm, it may or may not be 'terminal'.
Thus, the client cannot assume that another NAPTR exists since
this case is determined elsewhere.
ループ書き直しアルゴリズムを止めるので、「S」、「」 「旗が呼ばれるU」'端末'は弛みます。 それらの旗が存在していないなら、クライアントは、別のNAPTR RRが現在の書換規則で生産されたドメイン名で存在すると仮定するかもしれません。 「P」旗が新しいアルゴリズムを指定するので、それは'端末であるかもしれません'。 したがって、クライアントは、本件がほかの場所で決定しているので別のNAPTRが存在すると仮定できません。
DNS servers MAY interpret these flags and values and use that
information to include appropriate SRV and A,AAAA, or A6 records
in the additional information portion of the DNS packet. Clients
are encouraged to check for additional information but are not
required to do so.
DNSサーバは、DNSパケットの追加情報一部に適切なSRVとAか、AAAAか、A6記録を含むのにこれらの旗と値を解釈して、その情報を使用するかもしれません。 クライアントは、追加情報がないかどうかチェックするよう奨励されますが、そうする必要はありません。
Service
Specifies the service(s) available down this rewrite path. It may
also specify the particular protocol that is used to talk with a
service. A protocol MUST be specified if the flags field states
that the NAPTR is terminal. If a protocol is specified, but the
flags field does not state that the NAPTR is terminal, the next
Specifiesを調整してください。この書き直し経路の下側に利用可能なサービス。 また、それはサービスと話すのに使用される特定のプロトコルを指定するかもしれません。 旗の分野が、NAPTRが端末であると述べるなら、プロトコルを指定しなければなりません。 プロトコルが指定されますが、分野がする旗が、NAPTRが端末、次であると述べないなら
Mealling & Daniel Standards Track [Page 5] RFC 2915 NAPTR DNS RR September 2000
食事とダニエルStandardsはNAPTR DNS RR2000年9月にRFC2915を追跡します[5ページ]。
lookup MUST be for a NAPTR. The client MAY choose not to perform
the next lookup if the protocol is unknown, but that behavior
MUST NOT be relied upon.
ルックアップはNAPTRのためのものであるに違いありません。 プロトコルが未知であるなら、クライアントは、次のルックアップを実行しないのを選ぶかもしれませんが、その振舞いを当てにされてはいけません。
The service field may take any of the values below (using the
Augmented BNF of RFC 2234 [5]):
サービスグラウンドが以下で値のどれかで出るかもしれない、(RFC2234[5])のAugmented BNFを使用します:
service_field = [ [protocol] *("+" rs)]
protocol = ALPHA *31ALPHANUM
rs = ALPHA *31ALPHANUM
; The protocol and rs fields are limited to 32
; characters and must start with an alphabetic.
サービス_分野=[[プロトコル]*(「+」 rs)]プロトコル=アルファ*31ALPHANUM rsはアルファ*31ALPHANUMと等しいです。 プロトコルとrs分野は32に制限されます。 キャラクタと必須が始まる、アルファベットです。
For example, an optional protocol specification followed by 0 or
more resolution services. Each resolution service is indicated by
an initial '+' character.
例えば、0つ以上の解決サービスで任意のプロトコル仕様は従いました。 各解決サービスは初期の'+'キャラクタによって示されます。
Note that the empty string is also a valid service field. This
will typically be seen at the beginning of a series of rules,
when it is impossible to know what services and protocols will be
offered by a particular service.
また、空のストリングが有効なサービス分野であることに注意してください。 これは一連の規則の始めに通常見られるでしょう。(その時、どんなサービスとプロトコルが特定のサービスで提供されるかを知るのは不可能です)。
The actual format of the service request and response will be
determined by the resolution protocol, and is the subject for
other documents. Protocols need not offer all services. The
labels for service requests shall be formed from the set of
characters [A-Z0-9]. The case of the alphabetic characters is
not significant.
サービスのリクエストと応答の実際の形式は、解決プロトコルで決定して、他のドキュメントのための対象です。 プロトコルはすべてのサービスを提供しなければならないというわけではありません。 サービスのリクエストのためのラベルはキャラクタ[A-Z0-9]のセットから形成されるものとします。 英字のケースは重要ではありません。
The list of "valid" protocols for any given NAPTR record is any
protocol that implements some or all of the services defined for
a NAPTR application. Currently, THTTP [6] is the only protocol
that is known to make that claim at the time of publication. Any
other protocol that is to be used must have documentation
specifying:
どんな与えられたNAPTR記録のための「有効な」プロトコルのリストもNAPTRアプリケーションのために定義されたサービスのいくつかかすべてを実行するあらゆるプロトコルです。 現在、THTTP[6]は公表時点でそのクレームをするのが知られている唯一のプロトコルです。 使用されていることになっているいかなる他のプロトコルも以下を指定するドキュメンテーションを持たなければなりません。
* how it implements the services of the application
* それはどうアプリケーションのサービスを実行するか。
* how it is to appear in the NAPTR record (i.e., the string id
of the protocol)
* それがNAPTR記録に現れることになっている方法(すなわち、プロトコルのストリングイド)
The list of valid Resolution Services is defined by the documents
that specify individual NAPTR based applications.
有効なResolution Servicesのリストは個々のNAPTRベースのアプリケーションを指定するドキュメントによって定義されます。
It is worth noting that the interpretation of this field is
subject to being changed by new flags, and that the current
specification is oriented towards telling clients how to talk
with a URN resolver.
この分野の解釈は新しい旗で変えるのを受けることがあって、URNレゾルバと話す方法をクライアントに教えることに向かって現在の仕様が適応することに注意する価値があります。
Mealling & Daniel Standards Track [Page 6] RFC 2915 NAPTR DNS RR September 2000
食事とダニエルStandardsはNAPTR DNS RR2000年9月にRFC2915を追跡します[6ページ]。
Regexp
A STRING containing a substitution expression that is applied to
the original string held by the client in order to construct the
next domain name to lookup. The grammar of the substitution
expression is given in the next section.
オリジナルのストリングに適用される代替表現を含むRegexp A STRINGは、次のドメイン名をルックアップに構成するためにクライアントを固守しました。 次のセクションで代替表現の文法を与えます。
The regular expressions MUST NOT be used in a cumulative fashion,
that is, they should only be applied to the original string held
by the client, never to the domain name produced by a previous
NAPTR rewrite. The latter is tempting in some applications but
experience has shown such use to be extremely fault sensitive,
very error prone, and extremely difficult to debug.
累積しているファッションで正規表現を使用してはいけません、すなわち、それらはクライアントによって持たれていたオリジナルのストリングに適用されるだけであるべきです、決して前のNAPTR書き直しで生産されたいずれのドメイン名にもそうしません。 後者は使用目的によっては誘惑していますが、経験は、そのような使用は欠点非常に敏感で、誤り非常に傾向があって、デバッグするのが非常に難しいのを示しました。
Replacement
The next NAME to query for NAPTR, SRV, or address records
depending on the value of the flags field. This MUST be a fully
qualified domain-name. Unless and until permitted by future
standards action, name compression is not to be used for this
field.
NAPTR、SRV、またはアドレスのための質問への次のNAMEが記録する旗の分野の値に依存する交換。 これは完全に適切なドメイン名であるに違いありません。 今後の規格動作で受入れられるまで、名前圧縮はこの分野に使用されないことです。
3. Substitution Expression Grammar
3. 代替表現文法
The content of the regexp field is a substitution expression. True sed(1) and Perl style substitution expressions are not appropriate for use in this application for a variety of reasons stemming from internationalization requirements and backref limitations, therefore the contents of the regexp field MUST follow the grammar below:
regexp分野の内容は代替表現です。 このアプリケーションにおける、regexp分野の国際化要件としたがって、backref制限、コンテンツに由来するのが以下の文法に従わなければならないさまざまな理由の使用には、本当のsed(1)とPerlスタイル代替表現は適切ではありません:
subst_expr = delim-char ere delim-char repl delim-char *flags
delim-char = "/" / "!" / ... <Any non-digit or non-flag character
other than backslash '\'. All occurances of a delim_char
in a subst_expr must be the same character.>
ere = POSIX Extended Regular Expression
repl = 1 * ( OCTET / backref )
backref = "\" 1POS_DIGIT
flags = "i"
POS_DIGIT = %x31-39 ; 0 is not an allowed backref
「delim-炭のrepl delim-炭の*がdelim-炭に旗を揚げさせる前にsubst_expr=delim-炭は」 /と等しく」/“!" / ... '\'というバックスラッシュ以外の<のどんな非ケタの、または、非旗のキャラクタ。 subst_exprのdelim_炭のすべてのoccurancesが同じキャラクタであるに違いありません。= 1*(OCTET / backref)POSIX Extended Regular Expression repl=backrefが「\」1POS_ケタと等しい前に>は=「i」POS_ケタ=%x31-39に旗を揚げさせます。 0は許容backrefではありません。
The definition of a POSIX Extended Regular Expression can be found in [8], section 2.8.4.
[8]、セクション2.8.4でPOSIX Extended Regular Expressionの定義を見つけることができます。
The result of applying the substitution expression to the original URI MUST result in either a string that obeys the syntax for DNS domain-names [1] or a URI [9] if the Flags field contains a 'u'. Since it is possible for the regexp field to be improperly specified, such that a non-conforming domain-name can be constructed, client software SHOULD verify that the result is a legal DNS domain-name before making queries on it.
[9] Flags分野が'u'を含んでいるなら、代替表現をオリジナルのURIに適用するという結果はDNSドメイン名[1]のために構文に従うストリングかURIのどちらかをもたらさなければなりません。 regexp分野が不適切に指定されるのが、非の従うドメイン名を構成できるくらい可能であるので、クライアントソフトウェアSHOULDは、結果がそれで質問をする前の法的なDNSドメイン名であることを確かめます。
Mealling & Daniel Standards Track [Page 7] RFC 2915 NAPTR DNS RR September 2000
食事とダニエルStandardsはNAPTR DNS RR2000年9月にRFC2915を追跡します[7ページ]。
Backref expressions in the repl portion of the substitution
expression are replaced by the (possibly empty) string of characters
enclosed by '(' and ')' in the ERE portion of the substitution
expression. N is a single digit from 1 through 9, inclusive. It
specifies the N'th backref expression, the one that begins with the
N'th '(' and continues to the matching ')'. For example, the ERE
代替表現のrepl部分でのBackref表現を同封のキャラクタの(ことによると空)のストリングに取り替えます。'('EREの')'は代替表現を分配します。 Nは1〜9の一桁です。包括的。 N'th backref表現、N'thと共に始まるものを指定する、'、('')'をマッチングに続けています。 例えば、ERE
(A(B(C)DE)(F)G)
((B(C)DE)(F)G)
has backref expressions:
backref表現を持っています:
\1 = ABCDEFG
\2 = BCDE
\3 = C
\4 = F
\5..\9 = error - no matching subexpression
1円はABCDEFG2円=BCDE3円=C4円=Fと5円等しいです。9円の=誤り--合っている「副-表現」がありません。
The "i" flag indicates that the ERE matching SHALL be performed in a case-insensitive fashion. Furthermore, any backref replacements MAY be normalized to lower case when the "i" flag is given.
「i」旗は、EREの合っているSHALLが大文字と小文字を区別しないファッションで実行されるのを示します。 その上、どんなbackref交換も、「i」旗を与えるとき、ケースを下ろすために正常にされるかもしれません。
The first character in the substitution expression shall be used as the character that delimits the components of the substitution expression. There must be exactly three non-escaped occurrences of the delimiter character in a substitution expression. Since escaped occurrences of the delimiter character will be interpreted as occurrences of that character, digits MUST NOT be used as delimiters. Backrefs would be confused with literal digits were this allowed. Similarly, if flags are specified in the substitution expression, the delimiter character must not also be a flag character.
代替表現における最初のキャラクタは代替表現のコンポーネントを区切るキャラクタとして使用されるものとします。 代替表現における、デリミタキャラクタの3回の非逃げられた発生がまさにあるに違いありません。 デリミタキャラクタの逃げられた発生がそのキャラクタの発生として解釈されるので、デリミタとしてケタを使用してはいけません。 Backrefsによる文字通りのケタに混乱するのが、許容されたこれであったということでしょう。 また、同様に、旗が代替表現で指定されるなら、デリミタキャラクタは旗のキャラクタであるはずがありません。
4. The Basic NAPTR Algorithm
4. 基本的なNAPTRアルゴリズム
The behavior and meaning of the flags and services assume an algorithm where the output of one rewrite is a new key that points to another rule. This looping algorithm allows NAPTR records to incrementally specify a complete rule. These incremental rules can be delegated which allows other entities to specify rules so that one entity does not need to understand _all_ rules.
旗の、そして、サービスの振舞いと意味は1つの書き直しの出力が別の規則を示す新しいキーであるアルゴリズムを仮定します。 このループアルゴリズムで、NAPTR記録は完全な規則を増加して指定できます。 これらの増加の規則を代表として派遣することができるので、(他の実体は規則を指定できます)1つの実体が_すべての_規則を理解する必要はありません。
The algorithm starts with a string and some known key (domain). NAPTR records for this key are retrieved, those with unknown Flags or inappropriate Services are discarded and the remaining records are sorted by their Order field. Within each value of Order, the records are further sorted by the Preferences field.
アルゴリズムはストリングとある知られているキー(ドメイン)から始まります。 このキーのためのNAPTR記録は検索されます、そして、未知のFlagsか不適当なServicesがあるそれらは捨てられます、そして、残っている記録はそれらのOrder分野によって分類されます。 Orderの各値の中では、記録はPreferences分野によってさらに分類されます。
The records are examined in sorted order until a matching record is found. A record is considered a match iff:
合っている記録が見つけられるまで、記録は分類されたオーダーで調べられます。 記録はマッチiffであると考えられます:
Mealling & Daniel Standards Track [Page 8] RFC 2915 NAPTR DNS RR September 2000
食事とダニエルStandardsはNAPTR DNS RR2000年9月にRFC2915を追跡します[8ページ]。
o it has a Replacement field value instead of a Regexp field value.
o それには、Regexp分野価値の代わりにReplacement分野価値があります。
o or the Regexp field matches the string held by the client.
o または、Regexp分野はクライアントによって持たれていたストリングに合っています。
The first match MUST be the match that is used. Once a match is found, the Services field is examined for whether or not this rule advances toward the desired result. If so, the rule is applied to the target string. If not, the process halts. The domain that results from the regular expression is then used as the domain of the next loop through the NAPTR algorithm. Note that the same target string is used throughout the algorithm.
初戦は使用されたマッチであるに違いありません。 マッチがいったん見つけられると、この規則が必要な結果に向かって進むかどうかがないかどうかServices分野は調べられます。 そうだとすれば、規則は目標ストリングに適用されます。 そうでなければ、過程は停止します。 そして、正規表現から生じるドメインは次の輪のドメインとしてNAPTRアルゴリズムで使用されます。 同じ目標ストリングがアルゴリズム中で使用されることに注意してください。
This looping is extremely important since it is the method by which complex rules are broken down into manageable delegated chunks. The flags fields simply determine at which point the looping should stop (or other specialized behavior).
このループは、それが複雑な規則が処理しやすい代表として派遣された塊へ砕けている方法であることで非常に重要です。 どれがループを指すかで分野が単に決定する旗は止まるはずです(または、他の専門化している振舞い)。
Since flags are valid at any level of the algorithm, the degenerative case is to never loop but to look up the NAPTR and then stop. In many specialized cases this is all that is needed. Implementors should be aware that the degenerative case should not become the common case.
旗がアルゴリズムのどんなレベルでも有効であるので、退化的なケースはしかし、NAPTRを見上げて、次に、止まるために決して輪にしないことです。 多くの専門化している場合では、これは必要であるすべてです。 作成者は退化的なケースがよくある例になるはずがないのを意識しているべきです。
5. Concerning How NAPTR Uses SRV Records
5. NAPTRがどうSRV記録を使用するかに関して
When the SRV record type was originally specified it assumed that the client did not know the specific domain-name before hand. The client would construct a domain-name more in the form of a question than the usual case of knowing ahead of time that the domain-name should exist. I.e., if the client wants to know if there is a TCP based HTTP server running at a particular domain, the client would construct the domain-name _http._tcp.somedomain.com and ask the DNS if that records exists. The underscores are used to avoid collisions with potentially 'real' domain-names.
SRVレコード種類が元々指定されたとき、それは、クライアントが手の前で特定のドメイン名を知らなかったと仮定しました。 クライアントは早めにドメイン名が存在するべきであるのを知る普通のケースより質問の形でドメイン名を構成するでしょう。 すなわち、クライアント必需品であるなら、特定のドメインを走るTCPのベースのHTTPサーバがあれば、クライアントが_http_ドメイン名tcp.somedomain.comを組み立てて、尋ねるのを知るために、それが記録するなら、DNSは存在しています。 強調は、潜在的に'本当'のドメイン名との衝突を避けるのに使用されます。
In the case of NAPTR, the actual domain-name is specified by the various fields in the NAPTR record. In this case the client isn't asking a question but is instead attempting to get at information that it has been told exists in an SRV record at that particular domain-name. While this usage of SRV is slightly different than the SRV authors originally intended it does not break any of the assumptions concerning what SRV contains. Also, since the NAPTR explicitly spells out the domain-name for which an SRV exists, that domain-name MUST be used in SRV queries with NO transformations. Any given NAPTR record may result in a domain-name to be used for SRV queries that may or may not contain the SRV standardized underscore
NAPTRの場合では、実際のドメイン名はNAPTR記録の多岐によって指定されます。 この場合、クライアントは、質問していませんが、代わりにSRV記録にその特定のドメイン名で存在するそれが言われた情報に達するのを試みています。 SRVのこの使用法が元々意図したSRV作者とわずかに異なっている間、それはSRVが含むことに関して仮定を少しも矯正しません。 また、NAPTRが明らかに、SRVが存在するドメイン名について詳しく説明するので、どんな変化でもSRV質問にそのドメイン名を使用してはいけません。 SRVを含むかもしれないSRV質問に使用されて、与えられたNAPTR記録がドメイン名に結果として生じさせるかもしれないいずれも強調を標準化しました。
Mealling & Daniel Standards Track [Page 9] RFC 2915 NAPTR DNS RR September 2000
食事とダニエルStandardsはNAPTR DNS RR2000年9月にRFC2915を追跡します[9ページ]。
characters. NAPTR applications that make use of SRV MUST NOT attempt to understand these domains or use them according to how the SRV specification structures its query domains.
キャラクタ。 SRV MUST NOTを利用するNAPTRアプリケーションは、SRV仕様がどう質問ドメインを構造化するかに従って、これらのドメインを理解しているか、またはそれらを使用するのを試みます。
6. Application Specifications
6. アプリケーション仕様
It should be noted that the NAPTR algorithm is the basic assumption about how NAPTR works. The reasons for the rewrite and the expected output and its use are specified by documents that define what applications the NAPTR record and algorithm are used for. Any document that defines such an application must define the following:
NAPTRアルゴリズムがNAPTRがどう働くかに関する基本仮定であることに注意されるべきです。 書き直し、予想された出力、およびその使用の理由はNAPTR記録とアルゴリズムがどんなアプリケーションに使用されるかを定義するドキュメントによって指定されます。 そのようなアプリケーションを定義するどんなドキュメントも以下を定義しなければなりません:
o The first known domain-name or how to build it
o 最初の知られているドメイン名かそれを建てる方法
o The valid Services and Protocols
o 有効なServicesとプロトコル
o What the expected use is for the output of the last rewrite
o 最後の書き直しの出力のための予想された使用が何であるかということです。
o The validity and/or behavior of any 'P' flag protocols.
o どんな'P'旗のプロトコルの正当性、そして/または、振舞い。
o The general semantics surrounding why and how NAPTR and its
algorithm are being used.
o なぜ、NAPTRとそのアルゴリズムがどう存在であるかに使用される一般意味論周辺。
7. Examples
7. 例
NOTE: These are examples only. They are taken from ongoing work and may not represent the end result of that work. They are here for pedagogical reasons only.
以下に注意してください。 これらは例専用です。 彼らは、進行中の仕事から取られて、その仕事の結末を表さないかもしれません。 彼らは教育学の理由だけでここにいます。
7.1 Example 1
7.1 例1
NAPTR was originally specified for use with the a Uniform Resource Name Resolver Discovery System. This example details how a particular URN would use the NAPTR record to find a resolver service.
NAPTRは元々、a Uniform Resource Name ResolverディスカバリーSystemとの使用に指定されました。 この例は特定のURNがレゾルバサービスを見つけるのにどうNAPTR記録を使用するだろうかを詳しく述べます。
Consider a URN namespace based on MIME Content-Ids. The URN might look like this:
MIME Content-イドに基づくURN名前空間を考えてください。 URNはこれに似るかもしれません:
urn:cid:39CB83F7.A8450130@fake.gatech.edu
つぼ:Cid: 39CB83F7.A8450130@fake.gatech.edu
(Note that this example is chosen for pedagogical purposes, and does not conform to the CID URL scheme.)
(この例が教育学の目的に選ばれていて、CID URL計画に従わないことに注意してください。)
The first step in the resolution process is to find out about the CID namespace. The namespace identifier [3], 'cid', is extracted from the URN, prepended to urn.arpa. 'cid.urn.arpa' then becomes the first 'known' key in the NAPTR algorithm. The NAPTR records for cid.urn.arpa looked up and return a single record:
解決の過程による第一歩はCID名前空間を見つけることです。 名前空間識別子[3]('Cid')はurn.arpaにprependedされたURNから抜粋されます。 そして、'cid.urn.arpa'はNAPTRアルゴリズムにおける最初の'知られている'キーになります。 cid.urn.arpaのためのNAPTR記録は、ただ一つの記録を調べて、返します:
Mealling & Daniel Standards Track [Page 10] RFC 2915 NAPTR DNS RR September 2000
食事とダニエルStandardsはNAPTR DNS RR2000年9月にRFC2915を追跡します[10ページ]。
cid.urn.arpa. ;; order pref flags service regexp replacement IN NAPTR 100 10 "" "" "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i" .
cid.urn.arpa。 ;; order pref flags service regexp replacement IN NAPTR 100 10 "" "" "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i" .
There is only one NAPTR response, so ordering the responses is not a problem. The replacement field is empty, so the pattern provided in the regexp field is used. We apply that regexp to the entire URN to see if it matches, which it does. The \2 part of the substitution expression returns the string "gatech.edu". Since the flags field does not contain "s" or "a", the lookup is not terminal and our next probe to DNS is for more NAPTR records where the new domain is ' gatech.edu' and the string is the same string as before.
1つのNAPTR応答しかないので、応答を命令するのは、問題ではありません。 交換分野が人影がないので、regexp分野に提供されたパターンは使用されています。 私たちはそれが合っているかどうかを見る全体のURNにそのregexpを適用します。(それはURNをします)。 代替表現の2円の部分がストリング"gatech.edu"を返します。 分野がする旗が「s」か“a"を含んでいないので、ルックアップは端末ではありません、そして、DNSへの私たちの次の徹底的調査は、より多くのNAPTR記録のために新しいドメインが'gatech.edu'であり、ストリングが従来と同様同じストリングであるところにあります。
Note that the rule does not extract the full domain name from the CID, instead it assumes the CID comes from a host and extracts its domain. While all hosts, such as mordred, could have their very own NAPTR, maintaining those records for all the machines at a site as large as Georgia Tech would be an intolerable burden. Wildcards are not appropriate here since they only return results when there is no exactly matching names already in the system.
規則がCIDから完全なドメイン名を抜粋しないというメモ、代わりに、それはCIDがホストから来て、ドメインを抽出すると仮定します。 すべてのホストがmordredされるようにそれら自身のNAPTRを持つことができた間、サイトのすべてのマシンのためのそれらの記録をジョージア工科大と同じくらい大きく保守するのは、耐えられない重荷でしょう。 まさに既にシステムで名前を合わせてはいけないときだけ、結果を返すので、ワイルドカードはここで適切ではありません。
The record returned from the query on "gatech.edu" might look like:
"gatech.edu"における質問から返された記録に似るかもしれません:
;; order pref flags service regexp replacement IN NAPTR 100 50 "s" "z3950+I2L+I2C" "" _z3950._tcp.gatech.edu. IN NAPTR 100 50 "s" "rcds+I2C" "" _rcds._udp.gatech.edu. IN NAPTR 100 50 "s" "http+I2L+I2C+I2R" "" _http._tcp.gatech.edu.
;; オーダーprefがサービスregexp交換IN NAPTR100 50「s」「z3950+I2L+I2C」に旗を揚げさせる、「「_z3950_tcp.gatech.edu。」 NAPTR100 50「s」「rcds+I2C」、「「_rcds_udp.gatech.edu。」 NAPTR100 50「s」「http+I2L+I2C+I2R」、「「_http_tcp.gatech.edu。」
Continuing with the example, note that the values of the order and preference fields are equal in all records, so the client is free to pick any record. The flags field tells us that these are the last NAPTR patterns we should see, and after the rewrite (a simple replacement in this case) we should look up SRV records to get information on the hosts that can provide the necessary service.
例を続行して、クライアントが自由にどんな記録も選ぶことができるように、注文と選択領域の値がすべての記録において等しいことに注意してください。 旗、分野は、これらが私たちが見るべきである最後のNAPTRパターンであると私たちに言って、書き直し(この場合、簡単な交換)の後に、私たちは、必要なサービスを提供できるホストの情報を得るためにSRV記録を調べるべきです。
Assuming we prefer the Z39.50 protocol, our lookup might return:
私たちがZ39.50プロトコルを好むと仮定する場合、私たちのルックアップは戻るかもしれません:
;; Pref Weight Port Target
_z3950._tcp.gatech.edu. IN SRV 0 0 1000 z3950.gatech.edu.
IN SRV 0 0 1000 z3950.cc.gatech.edu.
IN SRV 0 0 1000 z3950.uga.edu.
;; Prefはポート目標_z3950_tcp.gatech.eduに重みを加えます。 IN SRV0 0 1000z3950.gatech.edu。 IN SRV0 0 1000z3950.cc.gatech.edu。 IN SRV0 0 1000z3950.uga.edu。
telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their Z39.50 server.
彼らのZ39.50サーバと話すように私たち実際に解決ができた3人のホストと、ポートを私たちに与えるのに私たちが使用するべきである言います。
Recall that the regular expression used \2 to extract a domain name from the CID, and \. for matching the literal '.' characters separating the domain name components. Since '\' is the escape
'正規表現がCIDからドメイン名を抜粋するのに2円使用したリコール、および\、文字通りを合わせる、'.'ドメイン名コンポーネントを切り離しているキャラクタ。 '\'がエスケープであるので
Mealling & Daniel Standards Track [Page 11] RFC 2915 NAPTR DNS RR September 2000
食事とダニエルStandardsはNAPTR DNS RR2000年9月にRFC2915を追跡します[11ページ]。
character, literal occurances of a backslash must be escaped by another backslash. For the case of the cid.urn.arpa record above, the regular expression entered into the master file should be "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i". When the client code actually receives the record, the pattern will have been converted to "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i".
キャラクタ、別のバックスラッシュでバックスラッシュの文字通りのoccurancesから逃げなければなりません。 For the case of the cid.urn.arpa record above, the regular expression entered into the master file should be "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i". When the client code actually receives the record, the pattern will have been converted to "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i".
7.2 Example 2
7.2 例2
Even if URN systems were in place now, there would still be a tremendous number of URLs. It should be possible to develop a URN resolution system that can also provide location independence for those URLs. This is related to the requirement that URNs be able to grandfather in names from other naming systems, such as ISO Formal Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs, etc.
URNシステムが今や適所にあったとしても、物凄い数のURLがまだあるでしょうに。 また、位置の独立をそれらのURLに提供できるURN解決システムを開発するのは可能であるべきです。 これは祖父にとって、URNsが他の命名システムから名前でできるという要件に関連します、ISO Formal Public Identifiers、議会図書館Call民数記、ISBNs、ISSNsなどのように
The NAPTR RR could also be used for URLs that have already been assigned. Assume we have the URL for a very popular piece of software that the publisher wishes to mirror at multiple sites around the world:
また、既に割り当てられたURLにNAPTR RRを使用できました。 私たちには出版社が世界中の複数のサイトで反映したがっている非常にポピュラーなソフトウェア一本のためのURLがあると仮定してください:
Using the rules specified for this application we extract the prefix, "http", and lookup NAPTR records for http.uri.arpa. This might return a record of the form
このアプリケーションに指定された規則を使用して、私たちはhttp.uri.arpaのために接頭語、"http"、およびルックアップNAPTR記録を抜粋します。 これはフォームに関する記録を返すかもしれません。
http.uri.arpa. IN NAPTR
;; order pref flags service regexp replacement
100 90 "" "" "!http://([^/:]+)!\1!i" .
http.uri.arpa。 NAPTRで。 オーダーprefがサービスregexp交換100 90に旗を揚げさせる、「「「「「1円!http://([^/:]+)!i」。」
This expression returns everything after the first double slash and before the next slash or colon. (We use the '!' character to delimit the parts of the substitution expression. Otherwise we would have to use backslashes to escape the forward slashes and would have a regexp in the zone file that looked like "/http:\\/\\/([^\\/:]+)/\\1/i".).
この表現は最初の二重スラッシュの後と次のスラッシュかコロン前にすべてを返します。 (私たちは、代替表現の部品を区切るのに'!'キャラクタを使用します。 「さもなければ、私たちは、前進のスラッシュから逃げるのにバックスラッシュを使用しなければならなくて、似ていたゾーンファイルのregexpを持っているだろう」/http: \\/\\/([^\\/:]+)/\\1/i」。).
Applying this pattern to the URL extracts "www.foo.com". Looking up NAPTR records for that might return:
このパターンをURLに適用すると、"www.foo.com"は抽出されます。 それのためのNAPTR記録を調べるのは戻るかもしれません:
www.foo.com.
;; order pref flags service regexp replacement
IN NAPTR 100 100 "s" "http+I2R" "" _http._tcp.foo.com.
IN NAPTR 100 100 "s" "ftp+I2R" "" _ftp._tcp.foo.com.
www.foo.com。 ;; オーダーprefがサービスregexp交換IN NAPTR100 100「s」「http+I2R」に旗を揚げさせる、「「_http_tcp.foo.com。」 NAPTR100 100「s」「ftp+I2R」、「「_ftp_tcp.foo.com。」
Looking up SRV records for http.tcp.foo.com would return information on the hosts that foo.com has designated to be its mirror sites. The client can then pick one for the user.
http.tcp.foo.comのためのSRV記録を調べると、foo.comがミラーサイトになるように任命したホストの情報は返るでしょう。 そして、クライアントはユーザのための1つを選ぶことができます。
Mealling & Daniel Standards Track [Page 12] RFC 2915 NAPTR DNS RR September 2000
食事とダニエルStandardsはNAPTR DNS RR2000年9月にRFC2915を追跡します[12ページ]。
7.3 Example 3
7.3 例3
A non-URI example is the ENUM application which uses a NAPTR record to map an e.164 telephone number to a URI. In order to convert the phone number to a domain name for the first iteration all characters other than digits are removed from the the telephone number, the entire number is inverted, periods are put between each digit and the string ".e164.arpa" is put on the left-hand side. For example, the E.164 phone number "+1-770-555-1212" converted to a domain-name it would be "2.1.2.1.5.5.5.0.7.7.1.e164.arpa."
非URIの例はe.164電話番号をURIに写像するのにNAPTR記録を使用するENUMアプリケーションです。 全体の数が逆さである、最初の繰り返しのために電話番号をドメイン名に変換するために、ケタ以外のすべてのキャラクタが電話番号から外されて、期間は各ケタとストリング".e164.arpa"の間に左側に置かれた状態で置かれます。 例えば「+1-770-555-1212」がそれがドメイン名であるだろうというのに変換したE.164電話番号、"2.1.2.1.5.5.5.0.7.7.1.e164.arpa"。
For this example telephone number we might get back the following NAPTR records:
この例の電話番号のために、私たちは以下のNAPTR記録を取り戻すかもしれません:
$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@tele2.se!" . IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:information@tele2.se!" .
$起源2.1.2.1.5.5.5.0.7.7.1.e164.arpa。 $!一口: 「IN NAPTR100 10「u」「一口+E2U!」」 ^* information@tele2.se! 、」 . 「$!mailto: NAPTR102 10「」 u「mailto+E2U!」」 ^* information@tele2.se! 」 .
This application uses the same 'u' flag as the URI Resolution application. This flag states that the Rule is terminal and that the output is a URI which contains the information needed to contact that telephone service. ENUM also uses the same format for its Service field except that it defines the 'E2U' service instead of the 'I2*' services that URI resolution uses. The example above states that the available protocols used to access that telephone's service are either the Session Initiation Protocol or SMTP mail.
このアプリケーションはURI Resolutionアプリケーションと同じ'u'旗を使用します。 この旗はRuleが端末であり、出力がその電話サービスに連絡するのに必要である情報を含むURIであると述べます。 また、URI決議が利用する'I2*'サービスの代わりに'E2U'サービスを定義するのを除いて、ENUMはService分野に同じ形式を使用します。 利用可能なプロトコルがその電話のサービスにアクセスするのに使用した州の上の例は、Session InitiationプロトコルかSMTPメールです。
8. DNS Packet Format
8. DNSパケット・フォーマット
The packet format for the NAPTR record is:
NAPTR記録のためのパケット・フォーマットは以下の通りです。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ORDER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ FLAGS /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ SERVICES /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ REGEXP /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ REPLACEMENT /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | オーダー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 好み| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / FLAGS / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / SERVICES / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / REGEXP / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / REPLACEMENT / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Mealling & Daniel Standards Track [Page 13] RFC 2915 NAPTR DNS RR September 2000
食事とダニエルStandardsはNAPTR DNS RR2000年9月にRFC2915を追跡します[13ページ]。
where:
どこ:
FLAGS A <character-string> which contains various flags.
様々な旗を含むFLAGS A<文字列>。
SERVICES A <character-string> which contains protocol and service
identifiers.
プロトコルとサービス識別子を含むSERVICES A<文字列>。
REGEXP A <character-string> which contains a regular expression.
正規表現を含むREGEXP A<文字列>。
REPLACEMENT A <domain-name> which specifies the new value in the
case where the regular expression is a simple replacement
operation.
正規表現が簡単な交換操作である場合で新しい値を指定するREPLACEMENT A<ドメイン名>。
<character-string> and <domain-name> as used here are defined in RFC1035 [1].
<文字列>とここで使用される<ドメイン名>はRFC1035[1]で定義されます。
9. Master File Format
9. 基本ファイル形式
The master file format follows the standard rules in RFC-1035 [1]. Order and preference, being 16-bit unsigned integers, shall be an integer between 0 and 65535. The Flags and Services and Regexp fields are all quoted <character-string>s. Since the Regexp field can contain numerous backslashes and thus should be treated with care. See Section 10 for how to correctly enter and escape the regular expression.
基本ファイル形式はRFC-1035[1]で標準の規則に従います。 16ビットの符号のない整数であり注文と好みは0〜65535の整数になるでしょう。 Flags、Services、およびRegexp分野はすべてが<文字列>sを引用したということです。 以来、Regexp分野は、多数のバックスラッシュを含むことができて、その結果、慎重に扱われるべきです。 正しく正規表現にセクション10を見て、入って、どう逃げてくださいか。
10. Advice for DNS Administrators
10. DNS管理者のためのアドバイス
Beware of regular expressions. Not only are they difficult to get correct on their own, but there is the previously mentioned interaction with DNS. Any backslashes in a regexp must be entered twice in a zone file in order to appear once in a query response. More seriously, the need for double backslashes has probably not been tested by all implementors of DNS servers.
正規表現に注意してください。 単に一人で正しくなるのが難しいのではなく、DNSとの以前に言及された相互作用があります。 質問応答に一度現れるように二度regexpのどんなバックスラッシュもゾーンファイルに入力しなければなりません。 より真剣に、二重バックスラッシュの必要性はたぶんDNSサーバのすべての作成者によってテストされていません。
The "a" flag allows the next lookup to be for address records (A, AAAA, A6) rather than SRV records. Since there is no place for a port specification in the NAPTR record, when the "A" flag is used the specified protocol must be running on its default port.
次のルックアップは“a"旗がSRV記録よりむしろアドレス記録(A、AAAA、A6)のためのものにさせます。 NAPTR記録にはポート仕様のための場所が全くないので、「A」旗が使用されているとき、指定されたプロトコルはデフォルトポートで走らなければなりません。
The URN Syntax draft defines a canonical form for each URN, which requires %encoding characters outside a limited repertoire. The regular expressions MUST be written to operate on that canonical form. Since international character sets will end up with extensive use of %encoded characters, regular expressions operating on them will be essentially impossible to read or write by hand.
URN Syntax草稿は各URNのために標準形を定義します。(URNは限られたレパートリーの外でキャラクタをコード化する%を必要とします)。 その標準形を作動させるために正規表現を書かなければなりません。 国際的な人物セットが%の大規模な使用でコード化されたキャラクタを終わらせるので、手で読むか、または書くのが本質的にはそれらを作動させる正規表現が不可能になるでしょう。
Mealling & Daniel Standards Track [Page 14] RFC 2915 NAPTR DNS RR September 2000
食事とダニエルStandardsはNAPTR DNS RR2000年9月にRFC2915を追跡します[14ページ]。
11. Notes
11. 注意
o A client MUST process multiple NAPTR records in the order
specified by the "order" field, it MUST NOT simply use the first
record that provides a known protocol and service combination.
o クライアントは「オーダー」分野によって指定されたオーダーにおける複数のNAPTR記録を処理しなければならなくて、それは知られているプロトコルとサービス組み合わせを提供する最初の記録を絶対に使用してはいけません。
o When multiple RRs have the same "order" and all other criteria
being equal, the client should use the value of the preference
field to select the next NAPTR to consider. However, because it
will often be the case where preferred protocols or services
exist, clients may use this additional criteria to sort
the records.
o 複数のRRsに同じ「オーダー」と他のすべての等しい評価基準があるとき、クライアントは次のNAPTRが考えるのを選択する選択領域の値を使用するべきです。 しかしながら、しばしばプロトコルかサービスが存在するのが、ところの都合のよいケースであるので、クライアントは記録を分類するのにこの追加評価基準を使用するかもしれません。
o If the lookup after a rewrite fails, clients are strongly
encouraged to report a failure, rather than backing up to pursue
other rewrite paths.
o 書き直しの後のルックアップが失敗するなら、クライアントが他の書き直し経路を追求しない裏刷よりむしろことを報告するよう強く奨励されます。
o Note that SRV RRs impose additional requirements on clients.
o SRV RRsが追加要件をクライアントに課すことに注意してください。
12. IANA Considerations
12. IANA問題
The only registration function that impacts the IANA is for the values that are standardized for the Services and Flags fields. To extend the valid values of the Flags field beyond what is specified in this document requires a published specification that is approved by the IESG.
IANAに影響を与える唯一の登録機能がServicesとFlags分野に標準化される値のためのものです。 指定されることを超えてFlags分野の有効値を広げるのは本書ではIESGによって承認される広められた仕様を必要とします。
The values for the Services field will be determined by the application that makes use of the NAPTR record. Those values must be specified in a published specification and approved by the IESG.
Services分野への値はNAPTR記録を利用するアプリケーションで決定するでしょう。 それらの値を広められた仕様で指定されて、IESGは承認しなければなりません。
13. Security Considerations
13. セキュリティ問題
The interactions with DNSSEC are currently being studied. It is expected that NAPTR records will be signed with SIG records once the DNSSEC work is deployed.
DNSSECとの相互作用は現在、研究されています。 DNSSEC仕事がいったん配備されるとNAPTR記録がSIG記録を契約されると予想されます。
The rewrite rules make identifiers from other namespaces subject to the same attacks as normal domain names. Since they have not been easily resolvable before, this may or may not be considered a problem.
書換規則は正常なドメイン名と同じ攻撃を条件として他の名前空間から識別子を作ります。 それらが以前容易に溶解性でない時から、これは問題であると考えられるかもしれません。
Regular expressions should be checked for sanity, not blindly passed to something like PERL.
正規表現は盲目的に何かPerlのようなものに通過されるのではなく、正気がないかどうかチェックされるべきです。
This document has discussed a way of locating a service, but has not discussed any detail of how the communication with that service takes place. There are significant security considerations attached to the
このドキュメントは、サービスの場所を見つける道について議論しましたが、そのサービスとのコミュニケーションがどう行われるかに関する少しの詳細も議論していません。 問題が付いた重要なセキュリティがあります。
Mealling & Daniel Standards Track [Page 15] RFC 2915 NAPTR DNS RR September 2000
食事とダニエルStandardsはNAPTR DNS RR2000年9月にRFC2915を追跡します[15ページ]。
communication with a service. Those considerations are outside the scope of this document, and must be addressed by the specifications for particular communication protocols.
サービスとのコミュニケーション。 それらの問題はこのドキュメントの範囲の外にあって、特定の通信プロトコルのための仕様で記述しなければなりません。
14. Acknowledgments
14. 承認
The editors would like to thank Keith Moore for all his consultations during the development of this memo. We would also like to thank Paul Vixie for his assistance in debugging our implementation, and his answers on our questions. Finally, we would like to acknowledge our enormous intellectual debt to the participants in the Knoxville series of meetings, as well as to the participants in the URI and URN working groups.
エディタはこのメモの開発の間、彼のすべての相談についてキース・ムーアに感謝したがっています。 また、彼の支援について私たちの質問で私たちの実現、および彼の答えをデバッグする際にポールVixieに感謝申し上げます。 最終的に、私たちの莫大な知的な負債をミーティングのノクスビルシリーズの関係者に承認したいと思います、よくURIとURNワーキンググループの関係者のように。
References
参照
[1] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[1]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[2] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[2]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[3] Moats, R., "URN Syntax", RFC 2141, May 1997.
[3]堀(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。
[4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[4]GulbrandsenとA.とVixieとP.とL.Esibov、「サービス(DNS SRV)の位置を指定するためのDNS RR」、RFC2782、2000年2月。
[5] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
RFC 2234, November 1997.
[5] クロッカー、D.、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[6] Daniel, R., "A Trivial Convention for using HTTP in URN
Resolution", RFC 2169, June 1997.
[6] ダニエル、R.、「つぼの解決にHTTPを使用するための些細なコンベンション」、RFC2169、1997年6月。
[7] Daniel, R. and M. Mealling, "Resolution of Uniform Resource
Identifiers using the Domain Name System", RFC 2168, June 1997.
[7] ダニエルとR.とM.食事、「ドメインネームシステムを使用するUniform Resource Identifierの決議」、RFC2168、1997年6月。
[8] IEEE, "IEEE Standard for Information Technology - Portable
Operating System Interface (POSIX) - Part 2: Shell and Utilities
(Vol. 1)", IEEE Std 1003.2-1992, January 1993.
[8] IEEE、「情報技術--携帯用のオペレーティングシステムインタフェース(POSIX)--第2部のIEEE規格:」 「シェルとユーティリティ(Vol.1)」、IEEE Std1003.2-1992、1月1993日
[9] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[9]バーナーズ・リー、T.、フィールディング、R.T.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、1998年8月。
Mealling & Daniel Standards Track [Page 16] RFC 2915 NAPTR DNS RR September 2000
食事とダニエルStandardsはNAPTR DNS RR2000年9月にRFC2915を追跡します[16ページ]。
Authors' Addresses
作者のアドレス
Michael Mealling Network Solutions, Inc. 505 Huntmar Park Drive Herndon, VA 22070 US
ネットワークソリューションズ社505Huntmar公園Driveヴァージニア22070ハーンドン(米国)を荒びきにするマイケル
Phone: +1 770 921 2251 EMail: michaelm@netsol.com URI: http://www.netsol.com
以下に電話をしてください。 +1 2251年の770 921メール: michaelm@netsol.com ユリ: http://www.netsol.com
Ron Daniel DATAFUSION, Inc. 139 Townsend Street, Ste. 100 San Francisco, CA 94107 US
ロンダニエルDATAFUSION, Inc.139タウンゼンド通り、Ste。 100 サンフランシスコ、カリフォルニア94107米国
Phone: +1 415 222 0100 EMail: rdaniel@datafusion.net URI: http://www.datafusion.net
以下に電話をしてください。 +1 0100年の415 222メール: rdaniel@datafusion.net ユリ: http://www.datafusion.net
Mealling & Daniel Standards Track [Page 17] RFC 2915 NAPTR DNS RR September 2000
食事とダニエルStandardsはNAPTR DNS RR2000年9月にRFC2915を追跡します[17ページ]。
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機能のための基金は現在、インターネット協会によって提供されます。
Mealling & Daniel Standards Track [Page 18]
食事とダニエル標準化過程[18ページ]
一覧
スポンサーリンク
