RFC4367 日本語訳
4367 What's in a Name: False Assumptions about DNS Names. J.Rosenberg, Ed., IAB. February 2006. (Format: TXT=41724 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg, Ed. Request for Comments: 4367 IAB Category: Informational February 2006
ワーキンググループのJ.ローゼンバーグ、エドをネットワークでつないでください。コメントのために以下を要求してください。 4367年のIABカテゴリ: 情報の2006年2月
What's in a Name: False Assumptions about DNS Names
名前にはあるもの: DNS名に関する誤った前提
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
The Domain Name System (DNS) provides an essential service on the Internet, mapping structured names to a variety of data, usually IP addresses. These names appear in email addresses, Uniform Resource Identifiers (URIs), and other application-layer identifiers that are often rendered to human users. Because of this, there has been a strong demand to acquire names that have significance to people, through equivalence to registered trademarks, company names, types of services, and so on. There is a danger in this trend; the humans and automata that consume and use such names will associate specific semantics with some names and thereby make assumptions about the services that are, or should be, provided by the hosts associated with the names. Those assumptions can often be false, resulting in a variety of failure conditions. This document discusses this problem in more detail and makes recommendations on how it can be avoided.
ドメインネームシステム(DNS)はインターネットで重要負荷を提供します、さまざまなデータ、通常IPアドレスに構造化された名前を写像して。 これらの名前はしばしば人間のユーザに提供されるEメールアドレス、Uniform Resource Identifier(URI)、および他の応用層識別子に現れます。 これのために、人々に意味を持っている名前を習得するという根強い需要がありました、登録商標への等価性、会社名、サービスのタイプなどを通して。 この傾向における危険があります。 そのような名前を消費して、使用する人間とオートマトンは、特定の意味論をいくつかの名前に関連づけて、その結果、サービスに関して仮定をするべきであるか、またはそうあるべきです、ホストによって名前に関連づけられるなら。 さまざまな失敗状態をもたらして、それらの仮定はしばしば誤っている場合があります。 このドキュメントは、さらに詳細にこの問題について議論して、どうそれを避けることができるかにおける推薦状をします。
Rosenberg Informational [Page 1] RFC 4367 Name Assumptions February 2006
[1ページ]RFC4367名前仮定2006年2月の情報のローゼンバーグ
Table of Contents
目次
1. Introduction ....................................................2
2. Target Audience .................................................4
3. Modeling Usage of the DNS .......................................4
4. Possible Assumptions ............................................5
4.1. By the User ................................................5
4.2. By the Client ..............................................6
4.3. By the Server ..............................................7
5. Consequences of False Assumptions ...............................8
6. Reasons Why the Assumptions Can Be False ........................9
6.1. Evolution ..................................................9
6.2. Leakage ...................................................10
6.3. Sub-Delegation ............................................10
6.4. Mobility ..................................................12
6.5. Human Error ...............................................12
7. Recommendations ................................................12
8. A Note on RFC 2219 and RFC 2782 ................................13
9. Security Considerations ........................................14
10. Acknowledgements ..............................................14
11. IAB Members ...................................................14
12. Informative References ........................................15
1. 序論…2 2. 聴衆を狙ってください…4 3. DNSのモデル使用法…4 4. 可能な仮定…5 4.1. ユーザで…5 4.2. クライアントで…6 4.3. サーバで…7 5. 誤った前提の結果…8 6. 仮定が誤っている場合がある理由…9 6.1. 発展…9 6.2. 漏出…10 6.3. 復委任…10 6.4. 移動性…12 6.5. 人間の誤り…12 7. 推薦…12 8. RFC2219とRFC2782に関する注…13 9. セキュリティ問題…14 10. 承認…14 11. IABメンバー…14 12. 有益な参照…15
1. Introduction
1. 序論
The Domain Name System (DNS) [1] provides an essential service on the Internet, mapping structured names to a variety of different types of data. Most often it is used to obtain the IP address of a host associated with that name [2] [1] [3]. However, it can be used to obtain other information, and proposals have been made for nearly everything, including geographic information [4].
ドメインネームシステム(DNS)[1]はインターネットで重要負荷を提供します、さまざまな異なったタイプに関するデータに構造化された名前を写像して。 たいていそれは、その名前[2][1][3]に関連しているホストのIPアドレスを得るのに使用されます。 しかしながら、他の情報を得るのにそれを使用できます、そして、ほとんどすべてのために提案をしました、地理情報[4]を含んでいて。
Domain names are most often used in identifiers used by application protocols. The most well known include email addresses and URIs, such as the HTTP URL [5], Real Time Streaming Protocol (RTSP) URL [6], and SIP URI [7]. These identifiers are ubiquitous, appearing on business cards, web pages, street signs, and so on. Because of this, there has been a strong demand to acquire domain names that have significance to people through equivalence to registered trademarks, company names, types of services, and so on. Such identifiers serve many business purposes, including extension of brand, advertising, and so on.
ドメイン名はアプリケーション・プロトコルによって使用される識別子でたいてい使用されます。 特に知られていて、EメールアドレスとURIを含めてください、HTTP URL[5]や、レアルTime Streamingプロトコル(RTSP)URL[6]や、SIP URI[7]などのように。 名刺、ウェブページ、道路表示などに載っていて、これらの識別子は遍在しています。 これのために、等価性を通して人々に意味を持っているドメイン名を登録商標、会社名、サービスのタイプなどに取得するという根強い需要がありました。 そのような識別子はブランド、広告などの拡大を含む多くのビジネス目的に役立ちます。
People often make assumptions about the type of service that is or should be provided by a host associated with that name, based on their expectations and understanding of what the name implies. This, in turn, triggers attempts by organizations to register domain names based on that presumed user expectation. Examples of this are the
人々は、しばしばサービスのタイプに関して仮定をするべきであるか、またはその名前に関連しているホストによって提供されるべきです、名前が含意するものが彼らの期待に基礎づけて、分かって。 これは順番にユーザ期待であると推定されたそれに基づくドメイン名を登録する組織による試みの引き金となります。 この例はそうです。
Rosenberg Informational [Page 2] RFC 4367 Name Assumptions February 2006
[2ページ]RFC4367名前仮定2006年2月の情報のローゼンバーグ
various proposals for a Top-Level Domain (TLD) that could be associated with adult content [8], the requests for creation of TLDs associated with mobile devices and services, and even phishing attacks.
アダルト向けの内容[8]に関連づけることができたTop-レベルDomain(TLD)に、様々な提案、TLDsの作成を求める要求はモバイル機器、サービス、およびフィッシング攻撃とさえ交際しました。
When these assumptions are codified into the behavior of an automaton, such as an application client or server, as a result of implementor choice, management directive, or domain owner policy, the overall system can fail in various ways. This document describes a number of typical ways in which these assumptions can be codified, how they can be wrong, the consequences of those mistakes, and the recommended ways in which they can be avoided.
これらの仮定がアプリケーションクライアントかサーバなどのオートマトンの動きに成文化されるとき、作成者選択、管理指示、またはドメイン所有者方針の結果、総合体系はいろいろ失敗できます。 このドキュメントは多くのこれらの仮定を成文化できる典型的な方法、それらがどう間違っている場合があるか、そして、それらの誤りの結果、およびそれらを避けることができるお勧めの方法を述べます。
Section 4 describes some of the possible assumptions that clients, servers, and people can make about a domain name. In this context, an "assumption" is defined as any behavior that is expected when accessing a service at a domain name, even though the behavior is not explicitly codified in protocol specifications. Frequently, these assumptions involve ignoring parts of a specification based on an assumption that the client or server is deployed in an environment that is more rigid than the specification allows. Section 5 overviews some of the consequences of these false assumptions. Generally speaking, these consequences can include a variety of different interoperability failures, user experience failures, and system failures. Section 6 discusses why these assumptions can be false from the very beginning or become false at some point in the future. Most commonly, they become false because the environment changes in unexpected ways over time, and what was a valid assumption before, no longer is. Other times, the assumptions prove wrong because they were based on the belief that a specific community of clients and servers was participating, and an element outside of that community began participating.
セクション4はクライアント、サーバ、および人々がドメイン名に関してすることができるいくつかの可能な仮定について説明します。 このような関係においては、「仮定」はドメイン名でサービスにアクセスするとき予想されるどんな振舞いとも定義されます、振舞いがプロトコル仕様で明らかに成文化されませんが。 頻繁に、これらの仮定は、クライアントかサーバが仕様が許容するより堅い環境で配布されるという仮定に基づく仕様の部分を無視することを伴います。 これらの誤った前提の結果について5つの概要をいくつか区分してください。 概して、これらの結果はさまざまな異なった相互運用性失敗、ユーザー・エクスペリエンス失敗、およびシステム障害を含むことができます。 セクション6は、これらの仮定がなぜそもそも最初から誤っているか、または将来何らかのポイントで誤るようになることができるかを論じます。 最も一般的に、時間がたつにつれての予期していなかった道における環境変化、および以前有効な仮定であったものがもうないので、それらは誤るようになります。 それらがクライアントとサーバの特定の共同体が参加と、要素であったという信念に基づいてその共同体の外部が参加し始めたということであったので、他の回であり、仮定は間違っていると判明します。
Section 7 then provides some recommendations. These recommendations encapsulate some of the engineering mantras that have been at the root of Internet protocol design for decades. These include:
そして、セクション7はいくつかの推薦を提供します。 これらの推薦は何10年間もインターネットプロトコルデザインの根にある工学マントラのいくつかをカプセル化します。 これらは:
Follow the specifications.
仕様に従ってください。
Use the capability negotiation techniques provided in the
protocols.
プロトコルに提供された能力交渉術を使用してください。
Be liberal in what you accept, and conservative in what you send.
[18]
あなたが受け入れるもので寛容であって、あなたが送るもので保守的であってください。 [18]
Overall, automata should not change their behavior within a protocol based on the domain name, or some component of the domain name, of the host they are communicating with.
全体的に見て、オートマトンはドメイン名に基づくプロトコルの中の彼らの振舞い、またはドメイン名、彼らがコミュニケートしているホストの何らかのコンポーネントを変えるべきではありません。
Rosenberg Informational [Page 3] RFC 4367 Name Assumptions February 2006
[3ページ]RFC4367名前仮定2006年2月の情報のローゼンバーグ
2. Target Audience
2. 対象者
This document has several audiences. Firstly, it is aimed at implementors who ultimately develop the software that make the false assumptions that are the subject of this document. The recommendations described here are meant to reinforce the engineering guidelines that are often understood by implementors, but frequently forgotten as deadlines near and pressures mount.
このドキュメントには、数人の聴衆がいます。 まず第一に、それは結局このドキュメントの対象である誤った前提をするソフトウェアを開発する作成者を対象にします。 説明されて、しばしば作成者に解釈される技術的ガイドラインを補強することが意味していますが、頻繁に忘れられた近い締め切りがここにあって、圧力が上がるという推薦。
The document is also aimed at technology managers, who often develop the requirements that lead to these false assumptions. For them, this document serves as a vehicle for emphasizing the importance of not taking shortcuts in the scope of applicability of a project.
また、ドキュメントは技術マネージャを対象にします。(そのマネージャは、しばしばこれらの誤った前提につながる要件を開発します)。 それらに関しては、このドキュメントはプロジェクトの適用性の範囲の近道を取らない重要性を強調するための乗り物として機能します。
Finally, this document is aimed at domain name policy makers and administrators. For them, it points out the perils in establishing domain policies that get codified into the operation of applications running within that domain.
最終的に、このドキュメントはドメイン名の政策立案者と管理者を対象にします。 それらに関しては、それはそのドメインの中で稼働するアプリケーションの操作に成文化されるドメイン方針を確立する際に危険を指摘します。
3. Modeling Usage of the DNS
3. DNSのモデル使用法
+--------+
| |
| |
| DNS |
|Service |
| |
+--------+
^ |
| |
| |
| |
/--\ | |
| | | V
| | +--------+ +--------+
\--/ | | | |
| | | | |
---+--- | Client |-------------------->| Server |
| | | | |
| | | | |
/\ +--------+ +--------+
/ \
/ \
+--------+ | | | | | DNS| |サービス| | | +--------+ ^ | | | | | | | /--\ | | | | | V| | +--------+ +--------+ \--/ | | | | | | | | | ---+--- | クライアント|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| サーバ| | | | | | | | | | | /\ +--------+ +--------+ / \ / \
User
Figure 1
ユーザ図1
Rosenberg Informational [Page 4] RFC 4367 Name Assumptions February 2006
[4ページ]RFC4367名前仮定2006年2月の情報のローゼンバーグ
Figure 1 shows a simple conceptual model of how the DNS is used by applications. A user of the application obtains an identifier for particular content or service it wishes to obtain. This identifier is often a URL or URI that contains a domain name. The user enters this identifier into its client application (for example, by typing in the URL in a web browser window). The client is the automaton (a software and/or hardware system) that contacts a server for that application in order to provide service to the user. To do that, it contacts a DNS server to resolve the domain name in the identifier to an IP address. It then contacts the server at that IP address. This simple model applies to application protocols such as HTTP [5], SIP [7], RTSP [6], and SMTP [9].
図1はDNSがアプリケーションでどう使用されるかに関する簡単な概念モデルを示しています。 アプリケーションのユーザはそれが得たがっている特定の内容かサービスのための識別子を得ます。 しばしば、この識別子は、ドメイン名を含むURLかURIです。 ユーザはクライアントアプリケーション(例えばウェブブラウザウィンドウでURLをタイプすることによって)にこの識別子を入力します。 クライアントはユーザに対するサービスを提供するためにそのアプリケーションのためのサーバに連絡するオートマトン(ソフトウェア、そして/または、ハードウェアシステム)です。 それをするなら、それは、IPアドレスに識別子のドメイン名を決議するためにDNSサーバに連絡します。 そして、それはそのIPアドレスでサーバに連絡します。 この単純モデルはHTTP[5]や、SIP[7]や、RTSP[6]や、SMTP[9]などのアプリケーション・プロトコルに当てはまります。
>From this model, it is clear that three entities in the system can potentially make false assumptions about the service provided by the server. The human user may form expectations relating to the content of the service based on a parsing of the host name from which the content originated. The server might assume that the client connecting to it supports protocols that it does not, can process content that it cannot, or has capabilities that it does not. Similarly, the client might assume that the server supports protocols, content, or capabilities that it does not. Furthermore, applications can potentially contain a multiplicity of humans, clients, and servers, all of which can independently make these false assumptions.
このモデルからの>、サーバで潜在的にサービスに関する誤った前提をシステムの3つの実体による提供できるのは明確です。人間のユーザは内容が起因したホスト名の構文解析に基づくサービスの内容に関連する期待を形成するかもしれません。 サーバは、それに接続するクライアントがそれがサポートしないプロトコルをサポートするか、それが処理できない内容を処理できるか、またはそれが持っていない能力を持っていると仮定するかもしれません。 同様に、クライアントは、サーバがそれがサポートしないプロトコル、内容、または能力をサポートすると仮定するかもしれません。 その上、アプリケーションは潜在的に人間、クライアント、およびサーバの多様性を含むことができます。そのすべてが独自にこれらの誤った前提をすることができます。
4. Possible Assumptions
4. 可能な仮定
For each of the three elements, there are many types of false assumptions that can be made.
それぞれの3つの要素のために、することができる多くのタイプの誤った前提があります。
4.1. By the User
4.1. ユーザで
The set of possible assumptions here is nearly boundless. Users might assume that an HTTP URL that looks like a company name maps to a server run by that company. They might assume that an email from a email address in the .gov TLD is actually from a government employee. They might assume that the content obtained from a web server within a TLD labeled as containing adult materials (for example, .sex) actually contains adult content [8]. These assumptions are unavoidable, may all be false, and are not the focus of this document.
ここでの可能な仮定のセットはほとんど限りないです。 ユーザは、会社に似ているHTTP URLがその会社によって実行されたサーバと地図を命名すると仮定するかもしれません。 彼らは、.gov TLDのEメールアドレスからのメールが実際に公務員からあると仮定するかもしれません。 彼らは、アダルト材料(例えば、.sex)を含むとしてラベルされたTLDの中のウェブサーバーから得られた内容が実際にアダルト向けの内容[8]を含むと仮定するかもしれません。 これらの仮定は、避けられなく、すべて誤るかもしれなくて、このドキュメントの焦点ではありません。
Rosenberg Informational [Page 5] RFC 4367 Name Assumptions February 2006
[5ページ]RFC4367名前仮定2006年2月の情報のローゼンバーグ
4.2. By the Client
4.2. クライアントで
Even though the client is an automaton, it can make some of the same assumptions that a human user might make. For example, many clients assume that any host with a hostname that begins with "www" is a web server, even though this assumption may be false.
クライアントはオートマトンですが、それは人間のユーザがするかもしれない同じいくつかの仮定を作ることができます。 例えば、多くのクライアントが、"www"で始まるホスト名をもっているどんなホストもウェブサーバーであると仮定します、この仮定は誤るかもしれませんが。
In addition, the client concerns itself with the protocols needed to communicate with the server. As a result, it might make assumptions about the operation of the protocols for communicating with the server. These assumptions manifest themselves in an implementation when a standardized protocol negotiation technique defined by the protocol is ignored, and instead, some kind of rule is coded into the software that comes to its own conclusion about what the negotiation would have determined. The result is often a loss of interoperability, degradation in reliability, and worsening of user experience.
さらに、プロトコルがサーバとコミュニケートするのに必要である状態でクライアントはタッチします。その結果、それは、サーバとコミュニケートするためにプロトコルの操作に関する仮定をするかもしれません。プロトコルによって定義された標準化されたプロトコル交渉術が無視されて、ある種の規則が代わりに交渉が決定したことに関するそれ自身の結論に来るソフトウェアにコード化されるとき、これらの仮定は実装で現れます。 結果は、しばしば相互運用性の損失と、信頼性における退行と、ユーザー・エクスペリエンスの悪化です。
Authentication Algorithm: Though a protocol might support a
multiplicity of authentication techniques, a client might assume
that a server always supports one that is only optional according
to the protocol. For example, a SIP client contacting a SIP
server in a domain that is apparently used to identify mobile
devices (for example, www.example.cellular) might assume that the
server supports the optional Authentication and Key Agreement
(AKA) digest technique [10], just because of the domain name that
was used to access the server. As another example, a web client
might assume that a server with the name https.example.com
supports HTTP over Transport Layer Security (TLS) [16].
認証アルゴリズム: プロトコルは認証のテクニックの多様性をサポートするかもしれませんが、クライアントは、サーバがいつもプロトコルによると、任意の状態で1つだけをサポートすると仮定するかもしれません。 例えば、モバイル機器(例えば、www.example.cellular)を特定するのに明らかに使用されるドメインでSIPサーバに連絡するSIPクライアントは、サーバが、任意のAuthenticationとKey Agreement(AKA)がダイジェストのテクニック[10]であるとサポートすると仮定するかもしれません、まさしくサーバにアクセスするのに使用されたドメイン名のために。別の例として、ウェブクライアントは、https.example.comという名前があるサーバがTransport Layer Security(TLS)[16]の上でHTTPをサポートすると仮定するかもしれません。
Data Formats: Though a protocol might allow a multiplicity of data
formats to be sent from the server to the client, the client might
assume a specific one, rather than using the content labeling and
negotiation capabilities of the underlying protocol. For example,
an RTSP client might assume that all audio content delivered to it
from media.example.cellular uses a low-bandwidth codec. As
another example, a mail client might assume that the contents of
messages it retrieves from a mail server at mail.example.cellular
are always text, instead of checking the MIME headers [11] in the
message in order to determine the actual content type.
データ形式: プロトコルが、データ形式の多様性がサーバからクライアントに送られるのを許容するかもしれませんが、クライアントは基本的なプロトコルの満足しているラベリングと交渉能力を使用するよりむしろ特定のものを仮定するかもしれません。 例えば、RTSPクライアントは、media.example.cellularからそれに提供されたすべてのオーディオ内容が低バンド幅コーデックを使用すると仮定するかもしれません。別の例として、メールクライアントは、それがmail.example.cellularのメールサーバから検索するメッセージの内容がいつもテキストであると仮定するかもしれません、実際のcontent typeを決定するためにメッセージでMIMEヘッダー[11]をチェックすることの代わりに。
Protocol Extensions: A client may attempt an operation on the server
that requires the server to support an optional protocol
extension. However, rather than implementing the necessary
fallback logic, the client may falsely assume that the extension
is supported. As an example, a SIP client that requires reliable
provisional responses to its request (RFC 3262 [17]) might assume
that this extension is supported on servers in the domain
拡大について議定書の中で述べてください: クライアントは任意のプロトコルが拡大であるとサポートするためにサーバを必要とするサーバで操作を試みるかもしれません。 しかしながら、必要な後退論理を実装するよりむしろ、クライアントは、拡大がサポートされると間違って仮定するかもしれません。 例、要求への信頼できる暫定的な応答を必要とするSIPクライアント、(RFC3262[17])は、この拡大がそのドメインのサーバでサポートされると仮定するかもしれません。
Rosenberg Informational [Page 6] RFC 4367 Name Assumptions February 2006
[6ページ]RFC4367名前仮定2006年2月の情報のローゼンバーグ
sip.example.telecom. Furthermore, the client would not implement
the fallback behavior defined in RFC 3262, since it would assume
that all servers it will communicate with are in this domain and
that all therefore support this extension. However, if the
assumptions prove wrong, the client is unable to make any phone
calls.
sip.example.telecom。 その上、クライアントは、後退がRFC3262で定義された振舞いであると実装しないでしょう、それが交信するすべてのサーバがこのドメインにあって、したがって、すべてがこの拡大をサポートすると仮定するでしょう、したがって。 しかしながら、仮定が間違っていると判明するなら、クライアントはどんな電話もかけることができません。
Languages: A client may support facilities for processing text
content differently depending on the language of the text. Rather
than determining the language from markers in the message from the
server, the client might assume a language based on the domain
name. This assumption can easily be wrong. For example, a client
might assume that any text in a web page retrieved from a server
within the .de country code TLD (ccTLD) is in German, and attempt
a translation to Finnish. This would fail dramatically if the
text was actually in French. Unfortunately, this client behavior
is sometimes exhibited because the server has not properly labeled
the language of the content in the first place, often because the
server assumed such a labeling was not needed. This is an example
of how these false assumptions can create vicious cycles.
言語: クライアントはテキストの言語に異なってよる処理テキスト内容のために施設をサポートするかもしれません。 サーバからのメッセージのマーカーから言語を決定するよりむしろ、クライアントはドメイン名に基づく言語を仮定するかもしれません。 この仮定は容易に間違っている場合があります。 例えば、クライアントは、.de国名略号TLD(ccTLD)の中のサーバから検索されたウェブページのどんなテキストもドイツ語、および試みでフィンランド語への翻訳であると仮定するかもしれません。 テキストが実際にフランス語であるなら、これは劇的に失敗するでしょうに。 残念ながら、サーバが第一に適切に内容の言語をラベルしていないので、このクライアントの振舞いは時々示されます、サーバが、そのようなラベリングが必要でなかったとしばしば仮定したので。 これはこれらの誤った前提がどう悪循環を作成できるかに関する例です。
4.3. By the Server
4.3. サーバで
The server, like the client, is an automaton. Let us consider one servicing a particular domain -- www.company.cellular, for example. It might assume that all clients connecting to this domain support particular capabilities, rather than using the underlying protocol to make this determination. Some examples include:
クライアントのように、サーバはオートマトンです。 特定のドメインを修理しながら、1を考えましょう--例えば、www.company.cellular。 それは、このドメインに接続するすべてのクライアントがこの決断をするのに基本的なプロトコルを使用するよりむしろ特定の能力をサポートすると仮定するかもしれません。 いくつかの例は:
Authentication Algorithm: The server can assume that a client
supports a particular, optional, authentication technique, and it
therefore does not support the mandatory one.
認証アルゴリズム: サーバは、クライアントが、特定の、そして、任意の認証がテクニックであるとサポートすると仮定できます、そして、したがって、それは義務的なものをサポートしません。
Language: The server can serve content in a particular language,
based on an assumption that clients accessing the domain speak a
particular language, or based on an assumption that clients coming
from a particular IP address speak a certain language.
言語: サーバはドメインにアクセスするクライアントが特定の言語を話すという仮定に基づく特定の言語か特定のIPアドレスから来るクライアントが、ある言語を話すという仮定に基づいて内容に役立つことができます。
Data Formats: The server can assume that the client supports a
particular set of MIME types and is only capable of sending ones
within that set. When it generates content in a protocol
response, it ignores any content negotiation headers that were
present in the request. For example, a web server might ignore
the Accept HTTP header field and send a specific image format.
データ形式: サーバは、クライアントが特定のセットのMIMEの種類をサポートして、それの中のものが設定する発信できるだけであると仮定できます。 プロトコル応答における内容を生成すると、それはどんな要求に出席している満足している交渉ヘッダーも無視します。 例えば、ウェブサーバーは、Accept HTTPヘッダ分野を無視して、特定の画像形式を送るかもしれません。
Rosenberg Informational [Page 7] RFC 4367 Name Assumptions February 2006
[7ページ]RFC4367名前仮定2006年2月の情報のローゼンバーグ
Protocol Extensions: The server might assume that the client supports
a particular optional protocol extension, and so it does not
support the fallback behavior necessary in the case where the
client does not.
拡大について議定書の中で述べてください: サーバが、クライアントが特定の任意のプロトコル拡大をサポートすると仮定するかもしれないので、それはクライアントがそうしない場合で必要な後退の振舞いをサポートしません。
Client Characteristics: The server might assume certain things about
the physical characteristics of its clients, such as memory
footprint, processing power, screen sizes, screen colors, pointing
devices, and so on. Based on these assumptions, it might choose
specific behaviors when processing a request. For example, a web
server might always assume that clients connect through cell
phones, and therefore return content that lacks images and is
tuned for such devices.
クライアントの特性: サーバはクライアントの物理的な特性に関して、あるものを仮定するかもしれません、メモリーフットプリント、処理能力、画面サイズ、スクリーン色、ポインティング・デバイスなどなどのように。 要求を処理するとき、これらの仮定に基づいて、それは特異的行動を選ぶかもしれません。 例えば、ウェブサーバーは、いつもクライアントが携帯電話を通して接続して、したがって、イメージを欠いて、そのようなデバイスのために調整される内容を返すと仮定するかもしれません。
5. Consequences of False Assumptions
5. 誤った前提の結果
There are numerous negative outcomes that can arise from the various false assumptions that users, servers, and clients can make. These include:
ユーザ、サーバ、およびクライアントがすることができる様々な誤った前提から起こることができる多数の否定的結果があります。 これらは:
Interoperability Failure: In these cases, the client or server
assumed some kind of protocol operation, and this assumption was
wrong. The result is that the two are unable to communicate, and
the user receives some kind of an error. This represents a total
interoperability failure, manifesting itself as a lack of service
to users of the system. Unfortunately, this kind of failure
persists. Repeated attempts over time by the client to access the
service will fail. Only a change in the server or client software
can fix this problem.
相互運用性失敗: これらの場合では、クライアントかサーバがある種のプロトコル操作を仮定しました、そして、この仮定は間違っていました。 結果は2が交信できないで、ユーザが誤りについてある種を受けるということです。 システムのユーザに対するサービスの不足として現れて、これは総相互運用性失敗を表します。 残念ながら、この種類の失敗は持続しています。 サービスにアクセスするクライアントによる時間がたつにつれての繰り返された試みは失敗するでしょう。 サーバかクライアントソフトウェアにおける変化だけがこの問題を修正できます。
System Failure: In these cases, the client or server misinterpreted a
protocol operation, and this misinterpretation was serious enough
to uncover a bug in the implementation. The bug causes a system
crash or some kind of outage, either transient or permanent (until
user reset). If this failure occurs in a server, not only will
the connecting client lose service, but other clients attempting
to connect will not get service. As an example, if a web server
assumes that content passed to it from a client (created, for
example, by a digital camera) is of a particular content type, and
it always passes image content to a codec for decompression prior
to storage, the codec might crash when it unexpectedly receives an
image compressed in a different format. Of course, it might crash
even if the Content-Type was correct, but the compressed bitstream
was invalid. False assumptions merely introduce additional
failure cases.
システム障害: これらの場合では、クライアントかサーバがプロトコル操作を誤解しました、そして、この誤解は実装でバグの覆いを取ることができるくらい重大でした。 バグは一時的であるか永久的な(ユーザリセットまでの)システムクラッシュかある種の供給停止を引き起こします。 この失敗が起こるなら、意志だけではなく、サーバにおける接続クライアントはサービスを失いますが、接続するのを試みる他のクライアントがサービスを得ないでしょう。 不意に異なった形式で圧縮されたイメージを受け取るとき、例として、ウェブサーバーがクライアント(例えば、デジタルカメラで、作成される)よりそれに移られた内容が特定のcontent typeのものであり、ストレージの前に減圧のためにいつもイメージ内容をコーデックに通過すると仮定するなら、コーデックはダウンするかもしれません。 もちろん、コンテントタイプが正しかったのですが、圧縮されたbitstreamが無効であったとしても、それはダウンするでしょうに。 誤った前提は単に追加失敗事件を導入します。
Rosenberg Informational [Page 8] RFC 4367 Name Assumptions February 2006
[8ページ]RFC4367名前仮定2006年2月の情報のローゼンバーグ
Poor User Experience: In these cases, the client and server
communicate, but the user receives a diminished user experience.
For example, if a client on a PC connects to a web site that
provides content for mobile devices, the content may be
underwhelming when viewed on the PC. Or, a client accessing a
streaming media service may receive content of very low bitrate,
even though the client supported better codecs. Indeed, if a user
wishes to access content from both a cellular device and a PC
using a shared address book (that is, an address book shared
across multiple devices), the user would need two entries in that
address book, and would need to use the right one from the right
device. This is a poor user experience.
不十分なユーザー・エクスペリエンス: これらの場合では、クライアントとサーバは交信しますが、ユーザは減少しているユーザー・エクスペリエンスを受けます。 例えば、PCの上のクライアントがモバイル機器のための内容を提供するウェブサイトに接続するなら、PCの上で見られる場合、内容は圧倒でないかもしれません。 または、ストリーミング・メディアサービスにアクセスするクライアントは非常に低いbitrateの内容を受け取るかもしれません、クライアントが、より良いコーデックをサポートしましたが。 本当に、共有されたアドレス帳を使用することでユーザがセルデバイスとPCの両方から内容にアクセスしたいなら(すなわち、アドレス帳は複数のデバイスの向こう側に共有されました)、ユーザは右のデバイスから正しいものを使用する必要があるでしょうそのアドレス帳の2つのエントリーが必要があって。 これは不十分なユーザー・エクスペリエンスです。
Degraded Security: In these cases, a weaker security mechanism is
used than the one that ought to have been used. As an example, a
server in a domain might assume that it is only contacted by
clients with a limited set of authentication algorithms, even
though the clients have been recently upgraded to support a
stronger set.
降格しているセキュリティ: これらの場合使用されたはずであるものより弱いセキュリティー対策は使用されています。 例として、ドメインのサーバは、限られたセットの認証アルゴリズムでそれがクライアントによって連絡されるだけであると仮定するかもしれません、クライアントが最近、より強いセットを支えるためにアップグレードしましたが。
6. Reasons Why the Assumptions Can Be False
6. 仮定が誤っている場合がある理由
Assumptions made by clients and servers about the operation of protocols when contacting a particular domain are brittle, and can be wrong for many reasons. On the server side, many of the assumptions are based on the notion that a domain name will only be given to, or used by, a restricted set of clients. If the holder of the domain name assumes something about those clients, and can assume that only those clients use the domain name, then it can configure or program the server to operate specifically for those clients. Both parts of this assumption can be wrong, as discussed in more detail below.
特定のドメインに接触するときプロトコルの操作に関するクライアントとサーバによってされた仮定は、もろく、種々の理由で間違っている場合があります。 サーバ側では、仮定の多くがドメイン名を与えるか、または使用するだけである概念に基づいています、制限されたセットのクライアント。 ドメイン名の所有者が、それらのクライアントに関して何かを仮定して、それらのクライアントだけがドメイン名を使用すると仮定できるなら、それは、特にそれらのクライアントのために作動するようにサーバに構成するか、またはプログラムできます。 この仮定の両方の部分はさらに詳細に以下で議論するように間違っている場合があります。
On the client side, the notion is similar, being based on the assumption that a server within a particular domain will provide a specific type of service. Sub-delegation and evolution, both discussed below, can make these assumptions wrong.
クライアント側では、概念が同様です、特定のドメインの中のサーバが特定のタイプのサービスを提供するという仮定に基づいて。 以下でともに議論された復委任と発展で、これらの仮定は間違うようになる場合があります。
6.1. Evolution
6.1. 発展
The Internet and the devices that access it are constantly evolving, often at a rapid pace. Unfortunately, there is a tendency to build for the here and now, and then worry about the future at a later time. Many of the assumptions above are predicated on characteristics of today's clients and servers. Support for specific protocols, authentication techniques, or content are based on today's standards and today's devices. Even though they may, for the most part, be true, they won't always be. An excellent example is mobile devices. A server servicing a domain accessed by mobile devices
それにアクセスするインターネットとデバイスはしばしば急速なペースで絶えず発展しています。 残念ながら、現世に建てて、次に後で未来を心配する傾向があります。 上の仮定の多くが今日のクライアントとサーバの特性で叙述されます。 特定のプロトコル、テクニック、または内容に基づいている認証のために、今日の規格と今日のデバイスを支えます。 それらはだいたい本当であるかもしれませんが、彼らはいつもいるというわけではないでしょう。 好例はモバイル機器です。 モバイル機器によってアクセスされたドメインを修理するサーバ
Rosenberg Informational [Page 9] RFC 4367 Name Assumptions February 2006
[9ページ]RFC4367名前仮定2006年2月の情報のローゼンバーグ
might try to make assumptions about the protocols, protocol extensions, security mechanisms, screen sizes, or processor power of such devices. However, all of these characteristics can and will change over time.
そのようなデバイスのプロトコル、プロトコル拡大、セキュリティー対策、画面サイズ、またはプロセッサパワーに関する仮定をしようとするかもしれません。 しかしながら、これらの特性のすべてが、変化できて、時間がたつにつれて、変化するでしょう。
When they do change, the change is usually evolutionary. The result is that the assumptions remain valid in some cases, but not in others. It is difficult to fix such systems, since it requires the server to detect what type of client is connecting, and what its capabilities are. Unless the system is built and deployed with these capability negotiation techniques built in to begin with, such detection can be extremely difficult. In fact, fixing it will often require the addition of such capability negotiation features that, if they had been in place and used to begin with, would have avoided the problem altogether.
彼らが変化するとき、通常、変化は進化論です。 いくつかの場合、仮定が有効なままで残っているということですが、他のもので結果はことであるというわけではありません。 そのようなシステムを修理するのは難しいです、どんなタイプのクライアントが接続しているか、そして、能力が何であるかを検出するのがサーバを必要とするので。 システムが構築されて、これらの能力交渉術が初めに築き上げられている状態で配布されない場合、そのような検出は非常に難しい場合があります。 事実上、それを修理するのはしばしば初めに適所にあって、使用されていたなら全体で問題を避けたそのような能力交渉機能の追加を必要とするでしょう。
6.2. Leakage
6.2. 漏出
Servers also make assumptions because of the belief that they will only be accessed by specific clients, and in particular, those that are configured or provisioned to use the domain name. In essence, there is an assumption of community -- that a specific community knows and uses the domain name, while others outside of the community do not.
また、サーバはそれらが特定のクライアント、および特にドメイン名を使用するために構成されるか、または食糧を供給されるものによってアクセスされるだけであるという信念のために仮定をします。 本質には、特定の共同体がドメイン名を知って、使用するという共同体の仮定があります、共同体における外部の他のものはそうしませんが。
The problem is that this notion of community is a false one. The Internet is global. The DNS is global. There is no technical barrier that separates those inside of the community from those outside. The ease with which information propagates across the Internet makes it extremely likely that such domain names will eventually find their way into clients outside of the presumed community. The ubiquitous presence of domain names in various URI formats, coupled with the ease of conveyance of URIs, makes such leakage merely a matter of time. Furthermore, since the DNS is global, and since it can only have one root [12], it becomes possible for clients outside of the community to search and find and use such "special" domain names.
問題は共同体のこの概念が誤ったものであるということです。 インターネットはグローバルです。 DNSはグローバルです。 外であるそれらと共同体の内面であるものを切り離す技術上の障害が全くありません。 情報がインターネットの向こう側に伝播される容易さで、そのようなドメイン名が結局推定された共同体の外でクライアントに届くのが非常にありそうになります。 URIの運送の容易さに結びつけられた様々なURI形式のドメイン名の遍在している存在はそのような漏出を単に時間の問題にします。 その上、DNSがグローバルであり、1つの根[12]しか持つことができないので、そのような「特別な」ドメイン名を捜して、見つけて、使用するのは共同体の外でクライアントにとって可能になります。
Indeed, this leakage is a strength of the Internet architecture, not a weakness. It enables global access to services from any client with a connection to the Internet. That, in turn, allows for rapid growth in the number of customers for any particular service.
本当に、この漏出は弱点ではなく、インターネットアーキテクチャの強さです。 それは接続のどんなクライアントからインターネットまでのサービスへのグローバルなアクセスも可能にします。 それはどんな特定のサービスに関しても順番に顧客の数における急速な成長を考慮します。
6.3. Sub-Delegation
6.3. 復委任
Clients and users make assumptions about domains because of the notion that there is some kind of centralized control that can enforce those assumptions. However, the DNS is not centralized; it
クライアントとユーザはそれらの仮定を実施できるある種の集中制御があるという概念のためにドメインに関する仮定をします。 しかしながら、DNSは集結されません。 それ
Rosenberg Informational [Page 10] RFC 4367 Name Assumptions February 2006
[10ページ]RFC4367名前仮定2006年2月の情報のローゼンバーグ
is distributed. If a domain doesn't delegate its sub-domains and has its records within a single zone, it is possible to maintain a centralized policy about operation of its domain. However, once a domain gets sufficiently large that the domain administrators begin to delegate sub-domains to other authorities, it becomes increasingly difficult to maintain any kind of central control on the nature of the service provided in each sub-domain.
分配されます。 ドメインがサブドメインを代表として派遣しないで、ただ一つのゾーンの中に記録を持っているなら、ドメインの操作に関する集結された方針を維持するのは可能です。 しかしながら、ドメインがいったん十分大きくなると、ドメイン管理者が他の当局へサブドメインを代表として派遣し始めて、どんな種類の集中管理も維持するのがますます難しくなるのはサービスの本質で各サブドメインに提供されました。
Similarly, the usage of domain names with human semantic connotation tends to lead to a registration of multiple domains in which a particular service is to run. As an example, a service provider with the name "example" might register and set up its services in "example.com", "example.net", and generally example.foo for each foo that is a valid TLD. This, like sub-delegation, results in a growth in the number of domains over which it is difficult to maintain centralized control.
同様に、人間の意味含蓄があるドメイン名の用法は、稼働する特定のサービスがことである複数のドメインの登録に通じる傾向があります。 例として、「例」という名前があるサービスプロバイダーは、有効なTLDである各fooのために"example.com"、"example.net"、および一般にexample.fooでサービスを登録して、セットアップするかもしれません。 復委任のように、これは集中制御を維持するのが難しいドメインの数における成長をもたらします。
Not that it is not possible, since there are many examples of successful administration of policies across sub-domains many levels deep. However, it takes an increasing amount of effort to ensure this result, as it requires human intervention and the creation of process and procedure. Automated validation of adherence to policies is very difficult to do, as there is no way to automatically verify many policies that might be put into place.
方針のうまくいっている管理に関する多くの例が多くが深く平らにするサブドメインのむこうにあって、それは可能でないというわけではありません。 しかしながら、この結果を確実にするのに増加する量の取り組みを要します、プロセスと手順の人間の介入と作成を必要とするとき。 方針への固守の自動化された合法化はするのが非常に難しいです、自動的に場所に入れられるかもしれない多くの方針を確かめる方法が全くないとき。
A less costly process for providing centralized management of policies is to just hope that any centralized policies are being followed, and then wait for complaints or perform random audits. Those approaches have many problems.
方針の集中的管理を提供するためのそれほど高価でないプロセスは、次に、どんな集結された方針も続かれていて、苦情を待っているか、または無作為の監査を実行することをただ望むことになっています。 それらのアプローチには、多くの問題があります。
The invalidation of assumptions due to sub-delegation is discussed in further detail in Section 4.1.3 of [8] and in Section 3.3 of [20].
[8]と[20]のセクション3.3でセクション4.1.3における詳細で復委任による仮定の無効にするのについて議論します。
As a result of the fragility of policy continuity across sub- delegations, if a client or user assumes some kind of property associated with a TLD (such as ".wifi"), it becomes increasingly more likely with the number of sub-domains that this property will not exist in a server identified by a particular name. For example, in "store.chain.company.provider.wifi", there may be four levels of delegation from ".wifi", making it quite likely that, unless the holder of ".wifi" is working diligently, the properties that the holder of ".wifi" wishes to enforce are not present. These properties may not be present due to human error or due to a willful decision not to adhere to them.
サブ委譲の向こう側の方針の連続のもろさの結果、クライアントかユーザが、ある種の特性がTLD(".wifi"などの)に関連していると仮定するなら、この特性がますますそれ以上サブドメインの数で特定の名前によって特定されたサーバで存在しそうにないようになります。 例えば、".wifi"からの4つのレベルの委譲が"store.chain.company.provider.wifi"にあるかもしれません、".wifi"の所有者がコツコツと真面目に働いていない場合".wifi"の所有者が実施したがっている特性が存在していないのをかなりありそうにして。 これらの特性は人為ミスのためかそれらを固く守らないという意図的な決定のため存在していないかもしれません。
Rosenberg Informational [Page 11] RFC 4367 Name Assumptions February 2006
[11ページ]RFC4367名前仮定2006年2月の情報のローゼンバーグ
6.4. Mobility
6.4. 移動性
One of the primary value propositions of a hostname as an identifier is its persistence. A client can change IP addresses, yet still retain a persistent identifier used by other hosts to reach it. Because their value derives from their persistence, hostnames tend to move with a host not just as it changes IP addresses, but as it changes access network providers and technologies. For this reason, assumptions made about a host based on the presumed access network corresponding to that hostname tend to be wrong over time. As an example, a PC might normally be connected to its broadband provider, and through dynamic DNS have a hostname within the domain of that provider. However, one cannot assume that any host within that network has access over a broadband link; the user could connect their PC over a low-bandwidth wireless access network and still retain its domain name.
識別子としてのホスト名のプライマリ価値命題の1つはその固執です。 クライアントは、IPアドレスを変えますが、まだそれに達するのに他のホストによって使用された永続的な識別子を保有できます。 それらの値が彼らの固執に由来しているので、アクセスネットワーク内の提供者と技術を変えるとき、IPアドレスを変えるだけであるとき傾向があるのではなく、ホスト名は、ホストと共に移行する傾向があります。 この理由で、そのホスト名に対応する推定されたアクセスネットワークに基づくホストに関してされた仮定は、時間がたつにつれて間違っている傾向があります。 例として、PCは、通常、広帯域のプロバイダーに関連づけられて、そのプロバイダーのドメインの中にダイナミックなDNSを通してホスト名を持っているかもしれません。 しかしながら、人は、そのネットワークの中のどんなホストもブロードバンドの上のアクセスをリンクさせると仮定できません。 ユーザは、低バンド幅ワイヤレス・アクセスネットワークの上にそれらのPCを接続して、まだドメイン名を保有できました。
6.5. Human Error
6.5. 人為ミス
Of course, human error can be the source of errors in any system, and the same is true here. There are many examples relevant to the problem under discussion.
もちろん、人為ミスはどんなシステムでも誤りの源であるかもしれません、そして、同じくらいはここで本当です。 問題に関連している議論で多くの例があります。
A client implementation may make the assumption that, just because a DNS SRV record exists for a particular protocol in a particular domain, indicating that the service is available on some port, that the service is, in fact, running there. This assumption could be wrong because the SRV records haven't been updated by the system administrators to reflect the services currently running. As another example, a client might assume that a particular domain policy applies to all sub-domains. However, a system administrator might have omitted to apply the policy to servers running in one of those sub-domains.
クライアント実装は仮定をそれにするかもしれません、ただDNS SRV記録が特定のプロトコルのために特定のドメインに存在しているので、サービスがいくらかのポートで利用可能であり、事実上、サービスがそこに稼働しているのを示して。 SRV記録が現在サービスを反映するために稼働しながらシステム管理者によってアップデートされていないので、この仮定は間違っているかもしれません。 別の例として、クライアントは、特定のドメイン方針がすべてのサブドメインに適用されると仮定するかもしれません。 しかしながら、システム管理者は、それらのサブドメインの1つへ駆け込むサーバに方針を適用するのを忘れたかもしれません。
7. Recommendations
7. 推薦
Based on these problems, the clear conclusion is that clients, servers, and users should not make assumptions on the nature of the service provided to, or by, a domain. More specifically, however, the following can be said:
これらの問題に基づいて、明確な結論はクライアント、サーバ、およびユーザがドメインかドメインでサービスの本質における仮定を提供させるべきでないということです。 しかしながら、より明確に、以下を言うことができます:
Follow the specifications: When specifications define mandatory
baseline procedures and formats, those should be implemented and
supported, even if the expectation is that optional procedures
will most often be used. For example, if a specification mandates
a particular baseline authentication technique, but allows others
to be negotiated and used, implementations need to implement the
baseline authentication algorithm even if the other ones are used
仕様に従ってください: 仕様が義務的な基線手順と書式を定義するとき、ものは、実装されて、サポートされるべきです、期待が任意の手順がたいてい用いられるということであっても。 例えば、仕様が、特定の基線認証のテクニックを強制しますが、他のものが交渉されて、使用されるのを許容するなら、他のものが使用されていても、実装は、基線認証アルゴリズムを実装する必要があります。
Rosenberg Informational [Page 12] RFC 4367 Name Assumptions February 2006
[12ページ]RFC4367名前仮定2006年2月の情報のローゼンバーグ
most of the time. Put more simply, the behavior of the protocol
machinery should never change based on the domain name of the
host.
たいてい。 より単に置かれて、プロトコル機械の働きはホストのドメイン名に基づいて決して変化するべきではありません。
Use capability negotiation: Many protocols are engineered with
capability negotiation mechanisms. For example, a content
negotiation framework has been defined for protocols using MIME
content [13] [14] [15]. SIP allows for clients to negotiate the
media types used in the multimedia session, as well as protocol
parameters. HTTP allows for clients to negotiate the media types
returned in requests for content. When such features are
available in a protocol, client and servers should make use of
them rather than making assumptions about supported capabilities.
A corollary is that protocol designers should include such
mechanisms when evolution is expected in the usage of the
protocol.
能力交渉を使用してください: 多くのプロトコルが能力交渉メカニズムで設計されます。例えば、満足している交渉フレームワークは、プロトコルのためにMIME内容[13][14][15]を使用することで定義されました。 SIPは、クライアントがマルチメディアセッション、およびプロトコルパラメタで使用されるメディアタイプを交渉するのを許容します。 HTTPは、クライアントがタイプが内容に関する要求で返したメディアを交渉するのを許容します。 そのような特徴がプロトコルで利用可能であるときに、クライアントとサーバはサポートしている能力に関する仮定をするよりむしろそれらを利用するべきです。 推論は発展がプロトコルの用法で予想されるとき、プロトコルデザイナーがそのようなメカニズムを入れるべきであるということです。
"Be liberal in what you accept, and conservative in what you send"
[18]: This axiom of Internet protocol design is applicable here
as well. Implementations should be prepared for the full breadth
of what a protocol allows another entity to send, rather than be
limiting in what it is willing to receive.
「あなたが受け入れるもので寛容であって、あなたが送るもので保守的であってください」という[18]: また、インターネットプロトコルデザインのこの原理はここで適切です。 実装は別の実体がプロトコルで送ることができるものに関する完全な幅のために受けても構われないそれが思っているものが制限であるよりむしろ準備されるべきです。
To summarize -- there is never a need to make assumptions. Rather than doing so, utilize the specifications and the negotiation capabilities they provide, and the overall system will be robust and interoperable.
まとめる、--仮定をする必要が決してありません。 総合体系は、そうするよりむしろ、それらが提供する仕様と交渉能力を利用してください。そうすれば、強健であって、共同利用できるようになるでしょう。
8. A Note on RFC 2219 and RFC 2782
8. RFC2219とRFC2782に関する注
Based on the definition of an assumption given here, the behavior hinted at by records in the DNS also represents an assumption. RFC 2219 [19] defines well-known aliases that can be used to construct domain names for reaching various well-known services in a domain. This approach was later followed by the definition of a new resource record, the SRV record [2], which specifies that a particular service is running on a server in a domain. Although both of these mechanisms are useful as a hint that a particular service is running in a domain, both of them represent assumptions that may be false. However, they differ in the set of reasons why those assumptions might be false.
また、ここに与えられた仮定の定義に基づいて、DNSでの記録によってほのめかされた振舞いは仮定を表します。 RFC2219[19]はドメインで様々なよく知られるサービスに達するようにドメイン名を構成するのに使用できるよく知られる別名を定義します。 新しいリソース記録、特定のサービスがドメインをサーバで動いていると指定するSRV記録[2]の定義は後でこのアプローチのあとに続きました。 これらのメカニズムの両方が特定のサービスがドメインへ駆け込んでいるというヒントとして役に立ちますが、それらの両方が誤るかもしれない仮定を表します。 しかしながら、彼らはそれらの仮定が誤るかもしれない理由のセットにおいて異なります。
A client that assumes that "ftp.example.com" is an FTP server may be wrong because the presumed naming convention in RFC 2219 was not known by, or not followed by, the owner of domain.com. With RFC 2782, an SRV record for a particular service would be present only by explicit choice of the domain administrator, and thus a client that
domain.comの所有者がRFC2219の推定された命名規則で知られていなくて、また続かなかったので、"ftp.example.com"がFTPサーバであると仮定するクライアントは間違っているかもしれません。 RFC2782と共に、特定のサービスのためのSRV記録は明白なだけでドメイン管理者の選択を提示することであるだろう、その結果、クライアントはそれです。
Rosenberg Informational [Page 13] RFC 4367 Name Assumptions February 2006
[13ページ]RFC4367名前仮定2006年2月の情報のローゼンバーグ
assumes that the corresponding host provides this service would be wrong only because of human error in configuration. In this case, the assumption is less likely to be wrong, but it certainly can be.
ホストがこのサービスを提供する対応が単に構成における人為ミスで間違っていると仮定します。 この場合、仮定はそれほど間違っている傾向がでありませんが、確かに、それは傾向があることができます。
The only way to determine with certainty that a service is running on a host is to initiate a connection to the port for that service, and check. Implementations need to be careful not to codify any behaviors that cause failures should the information provided in the record actually be false. This borders on common sense for robust implementations, but it is valuable to raise this point explicitly.
サービスが動いている確実性でホストがそのサービスのためにポートに接続を開始することになっていることを決定して、チェックする唯一の方法。 実装は、記録に提供された情報が実際に誤っているなら失敗を引き起こす少しの振舞いも成文化しないように慎重である必要があります。 これは強健な実装のための常識に近似しますが、明らかにこのポイントを上げるのは貴重です。
9. Security Considerations
9. セキュリティ問題
One of the assumptions that can be made by clients or servers is the availability and usage (or lack thereof) of certain security protocols and algorithms. For example, a client accessing a service in a particular domain might assume a specific authentication algorithm or hash function in the application protocol. It is possible that, over time, weaknesses are found in such a technique, requiring usage of a different mechanism. Similarly, a system might start with an insecure mechanism, and then decide later on to use a secure one. In either case, assumptions made on security properties can result in interoperability failures, or worse yet, providing service in an insecure way, even though the client asked for, and thought it would get, secure service. These kinds of assumptions are fundamentally unsound even if the records themselves are secured with DNSSEC.
クライアントかサーバですることができる仮定の1つは有用性であり、あるセキュリティプロトコルとアルゴリズム例えば、クライアントの使用法(または、それの不足)は特定のドメインでのサービスがアプリケーション・プロトコルの特定の認証アルゴリズムかハッシュ関数であると仮定するかもしれないアクセスです。 異なったメカニズムの使用法を必要として、弱点が時間そのようなテクニックで見つけられるのは、可能です。 同様に、システムは、不安定なメカニズムから始まって、次に、後で安全なものを使用すると決めるかもしれません。 セキュリティ所有地の上でされた仮定は相互運用性失敗、またはどちらの場合ではも、よりひどくまだ結果として生じることができます、不安定な方法でサービスを提供して、求められたクライアント、およびそれが得る考えはサービスを保証しますが。 DNSSECと共に記録自体を保証しても、これらの種類の仮定は基本的に不健全です。
10. Acknowledgements
10. 承認
The IAB would like to thank John Klensin, Keith Moore and Peter Koch for their comments.
IABは彼らのコメントについてジョンKlensin、キース・ムーア、およびピーター・コッホに感謝したがっています。
11. IAB Members
11. IABメンバー
Internet Architecture Board members at the time of writing of this document are:
このドキュメントを主題にして書く時点のインターネット・アーキテクチャ委員会のメンバーは以下の通りです。
Bernard Aboba
バーナードAboba
Loa Andersson
Loaアンデション
Brian Carpenter
ブライアン大工
Leslie Daigle
レスリーDaigle
Patrik Faltstrom
パトリクFaltstrom
Rosenberg Informational [Page 14] RFC 4367 Name Assumptions February 2006
[14ページ]RFC4367名前仮定2006年2月の情報のローゼンバーグ
Bob Hinden
ボブHinden
Kurtis Lindqvist
カーティス・リンクヴィスト
David Meyer
デヴィッド・マイヤー
Pekka Nikander
ペッカNikander
Eric Rescorla
エリック・レスコラ
Pete Resnick
ピートレズニック
Jonathan Rosenberg
ジョナサン・ローゼンバーグ
12. Informative References
12. 有益な参照
[1] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[1]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[2] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[2]Gulbrandsen、A.、Vixie、P.、およびL.Esibov、「サービスの位置を指定するためのDNS RR(DNS SRV)」、RFC2782(2000年2月)。
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403,
October 2002.
[3] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(DNS)データベース」、RFC3403、2002年10月。
[4] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means
for Expressing Location Information in the Domain Name System",
RFC 1876, January 1996.
[4] デイヴィス、C.、Vixie、P.、グッドウィン、T.、およびI.ディキンソン、「ドメインネームシステムにおける位置情報を言い表すための手段」、RFC1876(1996年1月)。
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[5] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[6] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
1998年4月の[6]SchulzrinneとH.とラオ、A.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」RFC2326。
[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[7] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[8] Eastlake, D., ".sex Considered Dangerous", RFC 3675,
February 2004.
[8] イーストレーク、D.、「危険であると考えられた.sex」、RFC3675、2004年2月。
[9] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[9]Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
Rosenberg Informational [Page 15] RFC 4367 Name Assumptions February 2006
[15ページ]RFC4367名前仮定2006年2月の情報のローゼンバーグ
[10] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
Protocol (HTTP) Digest Authentication Using Authentication and
Key Agreement (AKA)", RFC 3310, September 2002.
Torvinenと、[10]Niemi、A.、Arkko、J.、およびRFC3310、2002年9月対「認証を使用するハイパーテキスト転送プロトコル(HTTP)ダイジェスト認証と主要な協定(別名)」
[11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
解放された[11]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[12] Internet Architecture Board, "IAB Technical Comment on the
Unique DNS Root", RFC 2826, May 2000.
[12] インターネット・アーキテクチャ委員会(「ユニークなDNS根のIABの技術的なコメント」、RFC2826)は2000がそうするかもしれません。
[13] Klyne, G., "Indicating Media Features for MIME Content",
RFC 2912, September 2000.
[13]Klyne、G.、「MIME内容のためのメディア機能を示します」、RFC2912、2000年9月。
[14] Klyne, G., "A Syntax for Describing Media Feature Sets",
RFC 2533, March 1999.
[14]Klyne、G.、「特徴が設定するメディアを説明するための構文」、RFC2533、1999年3月。
[15] Klyne, G., "Protocol-independent Content Negotiation
Framework", RFC 2703, September 1999.
[15]Klyne、G.、「プロトコルから独立している満足している交渉フレームワーク」、RFC2703、1999年9月。
[16] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[16] レスコラ(E.、「TLSの上のHTTP」、RFC2818)は2000がそうするかもしれません。
[17] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262,
June 2002.
[17] ローゼンバーグとJ.とH.Schulzrinne、「セッション開始プロトコル(一口)の暫定的な応答の信頼性」、RFC3262、2002年6月。
[18] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[18] ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[19] Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
Services", BCP 17, RFC 2219, October 1997.
[19] ハミルトンとM.とR.ライト、「DNS別名のネットワーク・サービスの使用」、BCP17、RFC2219、1997年10月。
[20] Faltstrom, P., "Design Choices When Expanding DNS", Work in
Progress, June 2005.
[20] P.、「DNSを広げるときのデザイン選択」というFaltstromは進歩、2005年6月に働いています。
Author's Address
作者のアドレス
Jonathan Rosenberg, Editor IAB 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサン・ローゼンバーグ、ニュージャージー07054米国のエディタIAB600Lanidex Plazaパーシッパニー
Phone: +1 973 952-5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
以下に電話をしてください。 +1 973 952-5000 メールしてください: jdrosen@cisco.com ユリ: http://www.jdrosen.net
Rosenberg Informational [Page 16] RFC 4367 Name Assumptions February 2006
[16ページ]RFC4367名前仮定2006年2月の情報のローゼンバーグ
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)によって提供されます。
Rosenberg Informational [Page 17]
ローゼンバーグInformationalです。[17ページ]
一覧
スポンサーリンク
