Network Working Group J. Rosenberg, Ed.
Request for Comments: 4367 IAB
Category: Informational February 2006
What's in a Name: False Assumptions about DNS Names
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).
著作権（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アドレスの様々な構造化された名前をマッピングし、インターネット上で不可欠なサービスを提供しています。これらの名前は、多くの場合、人間のユーザにレンダリングされている電子メールアドレス、ユニフォームリソース識別子（URI）、およびその他のアプリケーション層識別子に表示されます。このため、その上の登録商標、会社名、サービスの種類、およびに等価を通じて人々に意味を持つ名前を取得することが強く望まれています。この傾向にある危険性があります。消費し、そのような名前を使う人間とオートマトンは、いくつかの名前で特定の意味を関連付けることにより、名前に関連付けられたホストによって提供されている、またはあるべきサービスについての仮定を、行います。これらの仮定は、多くの場合、障害の様々な条件で、その結果、偽することができます。この文書では、より詳細にこの問題を議論し、それを回避することができる方法についての勧告を行います。
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
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]は、さまざまな種類のデータの様々な構造化された名前をマッピングし、インターネット上で不可欠なサービスを提供しています。ほとんどの場合、それはその名前に関連付けられたホストのIPアドレスを取得するために使用されている[2] [1]〜[3]。しかし、他の情報を取得するために使用することができ、および提案は、地理情報[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.
ドメイン名は、ほとんどの場合、アプリケーションプロトコルによって使用される識別子で使用されています。最もよく知られている電子メールアドレスとURIを、そのようなHTTP URL [5]、リアルタイムストリーミングプロトコル（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 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.
人々はしばしばあるか、彼らの期待と名前が意味するものを理解した上で、その名前に関連付けられているホストによって提供されるべきサービスの種類についての仮定を行います。これは、今度は、その推定ユーザーの期待に基づいてドメイン名を登録するための組織による試みをトリガします。この例は、アダルトコンテンツに関連付けることができトップレベルドメイン（TLD）のための様々な提案されている[8]、モバイルデバイスやサービス、さらにはフィッシング攻撃に関連付けられたTLDを作成するための要求。
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節は、その後、いくつかの提言を提供します。これらの推奨事項は何十年ものインターネットプロトコル設計のルートになっているエンジニアリング・マントラの一部をカプセル化します。これらは、次のとおりです。
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.
全体的に、オートマトンは、ドメイン名、またはそれらが通信しているホストのドメイン名の一部のコンポーネントに基づいて、プロトコル内で自分の行動を変えるべきではありません。
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.
最後に、この文書は、ドメイン名の政策立案者や管理者を対象としています。彼らにとって、それはそのドメイン内で実行中のアプリケーションの動作に成文化され得るドメインポリシーを確立する上で危険を指摘しています。
+--------+
| |
| |
| DNS |
|Service |
| |
+--------+
^ |
| |
| |
| |
/--\ | |
| | | V
| | +--------+ +--------+
\--/ | | | |
| | | | |
---+--- | Client |-------------------->| Server |
| | | | |
| | | | |
/\ +--------+ +--------+
/ \
/ \
User Figure 1
ユーザー図1
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です。ユーザーは、（例えば、WebブラウザウィンドウにURLを入力することによって）そのクライアントアプリケーションにこの識別子を入力します。クライアントは、オートマトン（ソフトウェアおよび/またはハードウェアシステム）でその連絡先のユーザーにサービスを提供するために、そのアプリケーション用のサーバー。これを行うには、その連絡先DNSサーバは、IPアドレスへの識別子で、ドメイン名を解決します。その後、連絡先、その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つのエンティティは、潜在的に、サーバが提供するサービスについての誤った前提を作ることができることは明らかです。人間のユーザは、コンテンツが発信されたホスト名の解析に基づいて、サービスの内容に関する期待を形成してもよいです。サーバーは、それに接続しているクライアントは、それが、そのことはできないコンテンツを処理することができていないプロトコルをサポートし、またはそれにはない機能を持っていることを前提とすることがあります。同様に、クライアントは、サーバがプロトコル、コンテンツ、またはそれにはない機能をサポートしていることを前提とすることがあります。さらに、アプリケーションは、潜在的に独立して、これらの誤った仮定を行うことができますすべてが人間、クライアント、およびサーバの多重度を含めることができます。
For each of the three elements, there are many types of false assumptions that can be made.
三つの要素のそれぞれについて、行うことができる誤った前提の多くの種類があります。
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での電子メールアドレスからのメールが公務員から実際にあることを前提としていかもしれません。これらは、[8]成人の材料（例えば、.sex）を含むように標識されたTLD内のWebサーバから取得したコンテンツが実際にアダルトコンテンツが含まれていると可能性があります。これらの仮定は、避けられない全て偽であってもよく、このドキュメントの焦点ではありません。
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」で始まるホスト名で任意のホストがWebサーバであることを前提としています。
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クライアントは、サーバーにオプションの認証と鍵合意（AKA）技術をダイジェスト[10をサポートしていることを前提とかもしれません]、という理由だけで、サーバーにアクセスするために使用されたドメイン名の。別の例として、Webクライアントは、名前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でメールサーバから取得したメッセージの内容は、常に実際のコンテンツ・タイプを決定するためにメッセージに代わりに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.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.
プロトコル拡張：クライアントは、オプションのプロトコル拡張をサポートするためのサーバーを必要とするサーバー上の操作を試みることができます。しかし、むしろ必要なフォールバック・ロジックを実装するよりも、クライアントが誤って拡張がサポートされていることを仮定してもよいです。例として、その要求（RFC 3262 [17]）に信頼性の高い暫定応答を必要とするSIPクライアントは、この拡張機能がドメインsip.example.telecom内のサーバーでサポートされていることを前提とすることがあります。それは、それが通信するすべてのサーバーが、このドメインにあり、それがすべてではこの拡張をサポートすることを前提としていますので、クライアントは、RFC 3262で定義されたフォールバック動作を実装していないでしょう。前提が間違っていることを証明ただし、クライアントは、任意の電話をかけることができません。
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の）内のサーバから取得したウェブページ内の任意のテキストはドイツ語であると仮定し、フィンランド語に翻訳を試みるかもしれません。テキストはフランス語で実際にした場合、これは劇的に失敗します。サーバーが正しくサーバは、そのような標識が必要とされなかったと仮定ことが多いので、最初の場所でコンテンツの言語のラベルが付いていないので、残念ながら、このクライアントの動作が時々展示されています。これは、これらの誤った前提が悪循環を作成する方法の一例です。
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:
サーバは、クライアントのように、オートマトンです。例えば、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.
認証アルゴリズム：サーバは、クライアントが特定のオプション、認証技術をサポートしていることを想定することができ、それゆえ必須1をサポートしていません。
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タイプの特定のセットをサポートしており、そのセット内のものを送信することができるだけであると仮定することができます。それはプロトコル応答してコンテンツを生成すると、その要求に存在した任意のコンテンツネゴシエーションヘッダを無視します。例えば、ウェブサーバは、受け入れHTTPヘッダフィールドを無視して、特定の画像フォーマットを送信するかもしれません。
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.
クライアントの特徴：サーバーは、そのようなので、上のメモリフットプリント、処理能力、画面サイズ、画面の色、ポインティングデバイス、およびとしてのクライアントの物理的特性に関する特定の物事を想定することがあります。リクエストを処理する際にこれらの仮定に基づいて、特定の行動を選択する場合があります。例えば、ウェブサーバは常に、クライアントが携帯電話を介して接続することを前提とし、そのための画像を欠いており、このようなデバイスのために調整されたコンテンツを返すことがあります。
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.
システム障害は：これらの例では、クライアントまたはサーバは、プロトコルの動作を誤解し、この誤解は、実装のバグを発見するのに十分な深刻でした。バグが（ユーザリセットされるまで）一時的または恒久的のいずれかのシステムクラッシュや停電のいくつかの種類を引き起こします。この障害は、サーバーで発生した場合だけでなく、接続しているクライアントは、サービスを失うが、他のクライアントは、サービスを取得することはありません接続しようとします。ウェブサーバは、コンテンツを（デジタルカメラによって、例えば、作成された）クライアントから渡されたことを前提とした場合の例として、特定のコンテンツタイプであり、それは常に、貯蔵前に減圧するためのコーデックに画像コンテンツを渡しそれが予想外に異なる形式で圧縮された画像を受信したときにコーデックがクラッシュする可能性があります。もちろん、それはコンテンツタイプが正しいだったが、圧縮されたビットストリームが無効な場合でもクラッシュする可能性があります。偽の仮定は、単に追加の失敗例を紹介します。
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上で見たときに、例えば、コンテンツはがっかりかもしれません。または、ストリーミングメディアサービスにアクセスするクライアントは、クライアントがより良いコーデックをサポートしていても、非常に低ビットレートのコンテンツを受信することができます。ユーザーが（つまり、複数のデバイス間で共有アドレス帳で）共有アドレス帳を使用して、携帯デバイスと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.
劣化セキュリティ：これらのケースでは、弱いセキュリティ機構がその使用されているべきものより使用されています。例として、ドメイン内のサーバーは、クライアントが最近強くセットをサポートするようにアップグレードされていても、それが唯一の認証アルゴリズムの限定セットとクライアントによって接触されることを前提としていかもしれません。
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.
クライアント側では、概念は、特定のドメイン内のサーバがサービスの特定のタイプを提供するという仮定に基づいている、似ています。サブ委任と進化、以下で説明するの両方が、これらの仮定が間違って作ることができます。
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 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.
彼らは変更を行うと、変更は通常、進化です。結果は、仮定がいくつかのケースではなく、他に有効なままであることです。それは、接続されたクライアントの種類を検出するためのサーバーを必要とするためには、そのようなシステムを修正することは困難であり、その機能が何でありますか。システムを構築してから始めることで構築されたこれらの能力交渉テクニックで展開されていない限り、このような検出は非常に困難な場合があります。実際には、それは、彼らが実施されてとして開始するために使用した場合、完全に問題を回避しているだろう、そのような能力交渉機能を追加する必要が頻繁になります固定。
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.
問題は、コミュニティのこの概念は、偽の1であるということです。インターネットはグローバルです。 DNSはグローバルです。これらの外部からのコミュニティの中にあるものを分ける技術的な障壁はありません。情報はインターネットを介して伝播しやすさは、このようなドメイン名は、最終的に推定コミュニティの外のクライアントに自分の道を見つけること、それは非常に可能性が高いことができます。 URIの搬送の容易さと相まって、様々なURI形式でドメイン名のユビキタス存在は、このような単なる漏れ時間の問題になります。さらに、DNS以来、世界的である、そしてそれが唯一のルート[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.
実際、この漏れは、インターネットアーキテクチャの強さ、弱さではないです。これは、インターネットに接続して任意のクライアントからサービスへのグローバルなアクセスを可能にします。これは、順番に、任意の特定のサービスの顧客数の急速な成長が可能になります。
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 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.
クライアントとユーザーがいるため、これらの前提条件を強制することができ、集中制御のいくつかの種類があるという考えのドメインについての仮定を行います。しかし、DNSは中央集権ではありません。それが配布されます。ドメインはそのサブドメインを委任し、単一ゾーン内のレコードを持っていない場合は、そのドメインの動作に関する集中管理ポリシーを維持することが可能です。ドメインは、ドメイン管理者は、他の当局にサブドメインを委任するために始めることを十分に大きくなったら、しかし、それは各サブドメインで提供されるサービスの性質上、中央制御のいずれかの種類を維持することがますます困難になります。
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.
同様に、人間の意味論的な意味合いを持つドメイン名の使用は、特定のサービスを実行することである複数のドメインの登録につながる傾向があります。例として、名前「例」で、サービスプロバイダは、登録可能性があり、「example.com」、「example.net」にそのサービスを設定し、一般的に有効なTLDである各fooの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].
サブ委任による仮定の無効化は、セクション4.1.3でさらに詳細に説明されている[8]、[20]のセクション3.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.
クライアントまたはユーザーが（例えば「.wifi」という）TLDに関連付けられたプロパティのいくつかの種類を想定した場合、サブ委任横切るポリシー連続の脆弱性の結果として、そのサブドメインの数でますますそうなりますこのプロパティは、特定の名前で識別されるサーバーに存在しません。たとえば、「store.chain.company.provider.wifi」で、プロパティはその、「.wifi」の保持者が熱心に働いている場合を除き、ということが非常に可能性の高い作り、「.wifi」からの代表団の4つのレベルがあるかもしれません「.wifi」の保持者は存在しない強制することを希望します。これらのプロパティは、それらに付着しない故意の決定によるヒューマンエラーに起因するか、存在しないかもしれません。
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を接続し、まだそのドメイン名を維持することができます。
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レコードは、現在実行中のサービスを反映するために、システム管理者によって更新されていないので、この仮定が間違っている可能性があります。別の例として、クライアントは、特定のドメインポリシーは、すべてのサブドメインに適用されることを前提としていかもしれません。しかし、システム管理者は、それらのサブドメインのいずれかで実行しているサーバーにポリシーを適用するために省略している場合があります。
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 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.
要約すると - 仮定を行う必要は決してありません。むしろそうすることよりも、仕様およびそれらが提供するネゴシエーション機能を利用し、全体的なシステムは、堅牢かつ相互運用可能になります。
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のレコードでを示唆しました。 RFC 2219 [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 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.
「ftp.example.com」ことを前提としていたクライアントは、RFC 2219で推定命名規則がで知られていない、またはdomain.comの所有者、続いていなかったため、FTPサーバーが間違っている可能性があります。 RFC 2782では、特定のサービスのSRVレコードは、明示的なドメイン管理者の選択、および対応するホストは、このサービスは唯一のための構成でヒューマンエラーの間違っているだろう提供していることを前提としていため、クライアントによって存在するであろう。この場合、仮定が間違っている可能性が低いですが、それは確かにすることができます。
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.
サービスがホスト上で実行されていることを確実に判断する唯一の方法は、そのサービスのポートへの接続を開始し、チェックすることです。実装は、障害がレコードに提供される情報は、実際に偽であるべき起こすあらゆる行動を成文化しないように注意する必要があります。これは、堅牢な実装のための常識に接し、明示的にこの点を上げるために貴重です。
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.
クライアントまたはサーバによって行うことができる仮定の一つは、特定のセキュリティプロトコルとアルゴリズムの可用性と使用（またはその欠如）です。たとえば、特定のドメイン内のサービスにアクセスするクライアントは、アプリケーションプロトコルで特定の認証アルゴリズムまたはハッシュ関数を想定することがあります。時間の経過とともに、弱点は、異なる機構の使用を必要とする、このような技術に見出される、ことが可能です。同様に、システムが不安定な機構を開始する可能性があります、その後、安全なものを使用することを後で決めます。いずれの場合も、セキュリティプロパティに作られた仮定は、クライアントはを求め、そしてそれは、安全なサービスを受けるだろうと思っていても、安全でない方法でサービスを提供し、さらに悪い相互運用性の障害が発生する、またはすることができます。仮定のこれらの種類は、レコード自体はDNSSECで保護されていても基本的に不健全です。
The IAB would like to thank John Klensin, Keith Moore and Peter Koch for their comments.
IABは、彼らのコメントのためにジョン・クレンシン、キースムーア、ピーター・コッホに感謝したいと思います。
Internet Architecture Board members at the time of writing of this document are:
このドキュメントの執筆時点ではインターネットアーキテクチャ委員会のメンバーは以下のとおりです。
Bernard Aboba
バーナードAboba
Loa Andersson
ロア・アンダーソン
Brian Carpenter
ブライアン・カーペンター
Leslie Daigle
レスリーDaigle氏
Patrik Faltstrom
Ptrik Fltstron
Bob Hinden
ボブHindenと
Kurtis Lindqvist
カーティスLindqvist
David Meyer
デビッド・マイヤー
Pekka Nikander
ペッカNikander
Eric Rescorla
エリックレスコラ
Pete Resnick
ピート・レズニック
Jonathan Rosenberg
ジョナサン・ローゼンバーグ
[1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[1] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[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のSRV）サービスの位置を特定するためのDNS RR"、RFC 2782、2000年2月。
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[3] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート3：ドメインネームシステム（DNS）データベース"、RFC 3403、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.ディキンソンを、RFC 1876 "ドメインネームシステムに位置情報を表現するための手段"、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.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[6] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[6] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[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.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[8] Eastlake, D., ".sex Considered Dangerous", RFC 3675, February 2004.
[8]イーストレイク、D.、 "危険な考慮.sex"、RFC 3675、2004年2月を。
[9] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[9] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[10] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)", RFC 3310, September 2002.
[10]ニエミ、A.、Arkko、J.、およびV. Torvinen、RFC 3310、2002年9月 "認証および鍵合意（AKA）を使用してハイパーテキスト転送プロトコル（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）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[12] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000.
[12]インターネットアーキテクチャ委員会、 "ユニークなDNS根のIAB技術コメント"、RFC 2826、2000年5月。
[13] Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000.
[13] Klyne、G.、RFC 2912、2000年9月 "MIMEコンテンツのメディアの特徴を示します"。
[14] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
[14] "メディア機能セットの記述のための構文" Klyne、G.、RFC 2533、1999年3月。
[15] Klyne, G., "Protocol-independent Content Negotiation Framework", RFC 2703, September 1999.
[15] Klyne、G.、 "プロトコルに依存しないコンテンツネゴシエーションフレームワーク"、RFC 2703、1999年9月。
[16] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[16]レスコラ、E.、 "HTTPオーバーTLS"、RFC 2818、2000年5月。
[17] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
、RFC 3262、2002年6月[17]ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[18] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[18]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[19] Hamilton, M. and R. Wright, "Use of DNS Aliases for Network Services", BCP 17, RFC 2219, October 1997.
[19]ハミルトン、M.とR.ライト、 "ネットワークサービスのためのDNS別名の使用"、BCP 17、RFC 2219、1997年10月。
[20] Faltstrom, P., "Design Choices When Expanding DNS", Work in Progress, June 2005.
[20] Faltstrom、P.、 "設計上の選択DNSの拡張"、進歩、2005年6月での作業。
Author's Address
著者のアドレス
Jonathan Rosenberg, Editor IAB 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサン・ローゼンバーグ、エディタIAB 600 Lanidexプラザパーシッパニー、NJ 07054米国
Phone: +1 973 952-5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
電話：+1 973 952-5000 Eメール：jdrosen@cisco.com URI：http://www.jdrosen.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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エディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。