[要約] RFC 4367は、DNS名に関する誤った仮定についての要約と目的を提供しています。このRFCの目的は、DNS名に関する一般的な誤解を明らかにし、正確な理解を促進することです。
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
名前の中にあるもの：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）The Internet Society（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]は、インターネット上の重要なサービスを提供し、構造化された名前をさまざまな種類のデータにマッピングします。ほとんどの場合、その名前[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.
ドメイン名は、アプリケーションプロトコルで使用される識別子で最も頻繁に使用されます。最もよく知られているのは、HTTP URL [5]、リアルタイムストリーミングプロトコル（RTSP）URL [6]、SIP URI [7]などのメールアドレスやURIなどです。これらの識別子はユビキタスで、名刺、Webページ、ストリートサインなどに表示されます。このため、登録商標、会社名、サービスの種類などと同等の人々にとって重要なドメイン名を取得するという強い需要がありました。このような識別子は、ブランド、広告などの拡張など、多くのビジネス目的に役立ちます。
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.
3つの要素のそれぞれについて、作成できる誤った仮定には多くの種類があります。
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の電子メールアドレスからの電子メールが実際には政府職員からのものであると仮定するかもしれません。彼らは、成人材料（.sexなど）を含むとラベル付けされたTLD内のWebサーバーから取得したコンテンツに実際に成体の内容が含まれていると仮定するかもしれません[8]。これらの仮定は避けられず、すべて偽りであり、このドキュメントの焦点ではありません。
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].
認証アルゴリズム：プロトコルは多数の認証手法をサポートする可能性がありますが、クライアントは、サーバーが常にプロトコルに従ってオプションのみをサポートすると仮定する場合があります。たとえば、モバイルデバイス（たとえば、www.example.cellular）を識別するために明らかに使用されているドメイン内のSIPサーバーに連絡するSIPクライアントは、サーバーがオプションの認証とキー契約（別名）ダイジェストテクニックをサポートしていると仮定する場合があります[10]、サーバーへのアクセスに使用されたドメイン名のためだけです。別の例として、Webクライアントは、名前https.example.comという名前のサーバーが輸送層セキュリティ（TLS）よりもHTTPをサポートしていると仮定する場合があります[16]。
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.cample.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.
プロトコル拡張：クライアントは、サーバーでオプションのプロトコル拡張をサポートする必要があるサーバー上の操作を試みることができます。ただし、必要なフォールバックロジックを実装するのではなく、クライアントは拡張機能がサポートされていると誤って想定する場合があります。例として、その要求に対する信頼できる暫定的な応答を必要とするSIPクライアント（RFC 3262 [17]）は、この拡張機能がドメイン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）内のサーバーから取得されたWebページ内のテキストがドイツ語であると想定し、フィンランド語への翻訳を試みる場合があります。テキストが実際にフランス語であれば、これは劇的に失敗します。残念ながら、サーバーがそもそもコンテンツの言語に適切にラベル付けされていないため、このクライアントの動作は時々展示されます。多くの場合、サーバーはそのようなラベル付けが必要ないと仮定したためです。これは、これらの誤った仮定が悪質なサイクルを作成する方法の例です。
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タイプの特定のセットをサポートし、そのセット内でのみ送信できると想定できます。プロトコル応答でコンテンツを生成すると、リクエストに存在するコンテンツネゴシエーションヘッダーは無視します。たとえば、Webサーバーは、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.
クライアントの特性：サーバーは、メモリフットプリント、処理能力、画面サイズ、画面色、ポインティングデバイスなど、クライアントの物理的特性に関する特定のことを想定する場合があります。これらの仮定に基づいて、リクエストを処理するときに特定の動作を選択する場合があります。たとえば、Webサーバーは常にクライアントが携帯電話を介して接続していると想定する場合があり、したがって、画像がなく、そのようなデバイス用に調整されるコンテンツを返します。
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.
システムの障害：これらの場合、クライアントまたはサーバーはプロトコル操作を誤って解釈しました。この誤解は、実装のバグを発見するのに十分深刻でした。バグは、システムクラッシュまたは一時的または永続的な（ユーザーリセットまで）何らかの停止を引き起こします。この失敗がサーバーで発生した場合、接続するクライアントがサービスを失うだけでなく、接続しようとする他のクライアントはサービスを受けません。例として、Webサーバーがクライアント（たとえば、デジタルカメラによって作成された）からコンテンツが特定のコンテンツタイプであると想定している場合、保存前に減圧のために画像コンテンツを常にコーデックに渡します。コーデックは、別の形式で圧縮された画像を予期せず受信するとクラッシュする可能性があります。もちろん、コンテンツタイプが正しかったとしてもクラッシュする可能性がありますが、圧縮されたビットストリームは無効でした。誤った仮定は、単に追加の障害ケースを導入するだけです。
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のクライアントがモバイルデバイス用のコンテンツを提供するWebサイトに接続している場合、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.
問題は、このコミュニティの概念が誤ったものであるということです。インターネットはグローバルです。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.
実際、この漏れはインターネットアーキテクチャの強さであり、弱点ではありません。インターネットに接続しているクライアントからのサービスへのグローバルなアクセスを可能にします。これにより、特定のサービスの顧客数が急速に成長することができます。
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」という名前のサービスプロバイダーは、「Example.com」、「Example.net」、および一般的に有効なTLDである各fooの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]のセクション4.1.3および[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.
サブディレジョン全体のポリシーの継続性の脆弱性の結果として、クライアントまたはユーザーがTLD（「.wifi」など）に関連する何らかのプロパティを想定している場合、サブドメインの数が増えるとますます高くなります。このプロパティは、特定の名前で識別されたサーバーには存在しません。たとえば、「store.chain.company.provider.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」がFTPサーバーであると仮定するクライアントは、RFC 2219で命名条約がdomain.comの所有者に知られていないか、続いていないため、間違っている可能性があります。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.
クライアントまたはサーバーが作成できる仮定の1つは、特定のセキュリティプロトコルとアルゴリズムの可用性と使用（またはその欠如）です。たとえば、特定のドメインでサービスにアクセスするクライアントは、アプリケーションプロトコルで特定の認証アルゴリズムまたはハッシュ関数を想定する場合があります。時間の経過とともに、このような手法で弱点が見られる可能性があり、異なるメカニズムの使用が必要です。同様に、システムは不安定なメカニズムから始まり、後で安全なメカニズムを使用することを決定する場合があります。どちらの場合でも、セキュリティプロパティで行われた仮定は、相互運用性の障害をもたらす可能性があります。さらに悪いことに、クライアントがサービスを確保することを求めて、それが取得すると考えていたとしても、サービスを安全でない方法で提供することができます。これらの種類の仮定は、レコード自体が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
バーナード・アボバ
Loa Andersson
ロア・アンダーソン
Brian Carpenter
ブライアンカーペンター
Leslie Daigle
レスリー・ダイグル
Patrik Faltstrom Bob Hinden
パトリック・ファルトストロム・ボブ・ヒンデン
Kurtis Lindqvist
Kurtis lindqvist
David Meyer
デビッド・マイヤー
Pekka 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 RR（DNS SRV）」、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。、「Dynamic Delogation Discovery System（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] Davis、C.、Vixie、P.、Goodwin、T。、およびI. Dickinson、「ドメイン名システムで位置情報を表現するための手段」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-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.、Rao、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[8] Eastlake, D., ".sex Considered Dangerous", RFC 3675, February 2004.
[8] イーストレイク、D。、「セックスは危険と見なされる」、RFC 3675、2004年2月。
[9] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[9] Klensin、J。、「Simple Mail Transfer Protocol」、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] Niemi、A.、Arkko、J。、およびV. Torvinen、「HyperText Transfer Protocol（HTTP）認証とキー契約（AKA）を使用した消化認証」、RFC 3310、2002年9月。
[11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[11] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[12] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000.
[12] インターネットアーキテクチャボード、「IABの独自のDNSルートに関する技術的なコメント」、RFC 2826、2000年5月。
[13] Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000.
[13] Klyne、G。、「MIMEコンテンツのメディア機能を示す」、RFC 2912、2000年9月。
[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] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。
[17] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[17] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定的な応答の信頼性」、RFC 3262、2002年6月。
[18] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[18] Braden、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
Jonathan Rosenberg、編集者IAB 600 Lanidex Plaza Parsippany、NJ 07054 US
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。