この文書はRFC 4367の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


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).

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
   1.  はじめに
   2.  Target Audience
   2.  対象読者
   3.  Modeling Usage of the DNS
   3.  DNS使用法のモデリング
   4.  Possible Assumptions
   4.  可能な仮定
      4.1.  By the User
      4.1.  ユーザによる
      4.2.  By the Client
      4.2.  クライアントによる
      4.3.  By the Server
      4.3.  サーバによる
   5.  Consequences of False Assumptions
   5.  誤った仮定の結果
   6.  Reasons Why the Assumptions Can Be False
   6.  仮定がなぜ誤り得るかという理由
      6.1.  Evolution
      6.1.  進展
      6.2.  Leakage
      6.2.  漏洩
      6.3.  Sub-Delegation
      6.3.  副委任
      6.4.  Mobility
      6.4.  移動性
      6.5.  Human Error
      6.5.  人的誤り
   7.  Recommendations
   7.  推薦
   8.  A Note on RFC 2219 and RFC 2782
   8.  RFC2219とRFC2782の注釈
   9.  Security Considerations
   9.  セキュリティの考察
   10. Acknowledgements
   10. 謝辞
   11. IAB Members
   11. IABメンバ
   12. Informative References
   12. 有益な参考文献


1.  Introduction
1.  はじめに

   The Domain Name System (DNS) [1] provides an essential service on the
   Internet, mapping structured names to a variety of different types of
   data.  Most often it is used to obtain the IP address of a host
   associated with that name [2] [1] [3].  However, it can be used to
   obtain other information, and proposals have been made for nearly
   everything, including geographic information [4].
   ドメイン名システム(DNS)[1]は、構造化された名前をいろいろな異なっ
   た種類のデータに対応させる、インターネット上の基本機能を供給します。
   特にこれはホストの名前からそれと結び付けられたホストの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.
   ドメイン名は最もしばしばアプリケーションプロトコルで識別子に使われま
   す。最もよく知られているのは電子メールアドレスと、HTTP URL[5]やリアル
   タイムストリーミングプロトコル(RTSP) URL[6]やSIP URI[7]のよう
   なURIです。これらの識別子は名刺やウェブページや道路標識などに現わ
   れ遍在します。このため、登録商標、会社名、サービス種別など多くの人々
   に重要なドメイン名を獲得する強い要求がありました。このような識別子は、
   商標や広告の拡張を含め、多くのビジネス目的を果たします。

   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.
   人々は名前と結び付けられたホストの供給するあるいはすべきサービスの種
   類について、名前が暗示することの期待と理解に基づいて、しばしば仮定を
   します。これは、ユーザー期待と仮定した基づいて、組織によるドメイン名
   を登録する試みを引き起こします。これの例は、成人向け内容[8]と結び付け
   される最上位ドメイン(TLD)に対する様々な提案や、移動装置やサービスと結
   び付けられた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.
   全体的に自動装置がドメイン名やドメイン名の一部や通信相手のホストに基
   づいてプロトコルの行動を変えないべきです。

2.  Target Audience
2.  対象読者

   This document has several audiences.  Firstly, it is aimed at
   implementors who ultimately develop the software that make the false
   assumptions that are the subject of this document.  The
   recommendations described here are meant to reinforce the engineering
   guidelines that are often understood by implementors, but frequently
   forgotten as deadlines near and pressures mount.
   この文書はいくつかの読者がいます。第一に、この文書の主題である究極的
   に誤った仮定をするソフトウェア開発実装者に向けられます。ここで記述さ
   れた推薦は、しばしば実装者が理解するが期限が近付いてプレッシャーが増
   すときにしばしば忘れら去られる工学的ガイドラインを強化することを意図
   します。

   The document is also aimed at technology managers, who often develop
   the requirements that lead to these false assumptions.  For them,
   this document serves as a vehicle for emphasizing the importance of
   not taking shortcuts in the scope of applicability of a project.
   文書はしばしばこれらの誤った仮定を導く要求条件を策定する技術管理者に
   向けられます。彼らに、プロジェクトの適用性の範囲で近道をとらないこと
   についての重要性を強調することについて、この文書は伝達手段の役をしま
   す。

   Finally, this document is aimed at domain name policy makers and
   administrators.  For them, it points out the perils in establishing
   domain policies that get codified into the operation of applications
   running within that domain.
   最終的に、この文書はドメイン名ポリシ当局と管理者に向けられます。彼ら
   に、そのドメインで動作するアプリケーションの運用で成文化されるドメイ
   ンポリシを確立することの危険を指摘します。

3.  Modeling Usage of the DNS
3.  DNS使用法のモデリング

                       +--------+
                       |        |
                       |        |
                       |  DNS   |
                       |Service |
                       |        |
                       +--------+
                         ^   |
                         |   |
                         |   |
                         |   |
          /--\           |   |
         |    |          |   V
         |    |        +--------+                     +--------+
          \--/         |        |                     |        |
            |          |        |                     |        |
         ---+---       | Client |-------------------->| Server |
            |          |        |                     |        |
            |          |        |                     |        |
           /\          +--------+                     +--------+
          /  \
         /    \

         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です。ユーザは(例えば、ウェブブラウザウインドウでURLを入
   力することで)この識別子をクライアントアプリケーションに入力します。
   クライアントはユーザにそのアプリケーションのサービスを提供するために
   ためにサーバに連絡する自動装置(ソフトウェアやハードウェアシステム)
   です。これを実行するために、クライアントは識別子のドメイン名をIPア
   ドレスに変換するためにDNSサーバと接触します。それからそのIPアド
   レスでサーバと接触します。  この単純なモデルはHTTP[5]やSIP[7]
   やRTSP[6]やSMTP[9]のようなアプリケーションプロトコルに当ては
   まります。

   From this model, it is clear that three entities in the system can
   potentially make false assumptions about the service provided by the
   server.  The human user may form expectations relating to the content
   of the service based on a parsing of the host name from which the
   content originated.  The server might assume that the client
   connecting to it supports protocols that it does not, can process
   content that it cannot, or has capabilities that it does not.
   Similarly, the client might assume that the server supports
   protocols, content, or capabilities that it does not.  Furthermore,
   applications can potentially contain a multiplicity of humans,
   clients, and servers, all of which can independently make these false
   assumptions.
   このモデルから、システムの3つのエンティティがサーバによって提供され
   たサービスについて誤った仮定をする可能性があることは明確です。人間の
   ユーザは情報源のホスト名を解析することでサービスの内容に関する期待を
   するかもしれません。サーバは接続してくるクライアントが、実際には持っ
   ていないあるプロトコルをサポートしているか、ある情報を処理できるか、
   ある能力を持つと想定するかもしれません。同様に、クライアントはサーバ
   が実際には持っていないあるあるプロトコルや情報や能力を持つと想定する
   かもしれません。さらに、アプリケーションは複数の人とクライアントとサー
   バからなるかもしれず、全てが独立に誤った仮定をする事がありえます。

4.  Possible Assumptions
4.  可能な仮定

   For each of the three elements, there are many types of false
   assumptions that can be made.
   3要素のそれぞれで、多くの種類の誤った仮定があります。

4.1.  By the User
4.1.  ユーザによる

   The set of possible assumptions here is nearly boundless.  Users
   might assume that an HTTP URL that looks like a company name maps to
   a server run by that company.  They might assume that an email from a
   email address in the .gov TLD is actually from a government employee.
   They might assume that the content obtained from a web server within
   a TLD labeled as containing adult materials (for example, .sex)
   actually contains adult content [8].  These assumptions are
   unavoidable, may all be false, and are not the focus of this
   document.
   ここで可能な仮定はほとんど無制限です。ユーザは会社名のように見える
   HTTP URLがその会社のサーバに対応する想定するかもしれません。
   .gov TLDの電子メールアドレスからの電子メールが実際に公務員からの物
   と想定するかもしれません。成人の要素(例えば、.sex)を含むと記され
   たTLDのウェブサーバから得られた内容は実際に成人の内容[8]を含んでい
   ると想定するかもしれません。これらの仮定は避けられなくて、すべて誤っ
   ているかもしれませんが、この文書の対象ではありません。

4.2.  By the Client
4.2.  クライアントによる

   Even though the client is an automaton, it can make some of the same
   assumptions that a human user might make.  For example, many clients
   assume that any host with a hostname that begins with "www" is a web
   server, even though this assumption may be false.
   クライアントは自動装置ですが、人間のユーザがするのと同じ仮定をする
   ことがあります。例えば、多くのクライアントは、この仮定が誤っている
   かもしれないが、"www"から始めるホスト名を持つホストはウェブサーバで
   あると想定します。

   In addition, the client concerns itself with the protocols needed to
   communicate with the server.  As a result, it might make assumptions
   about the operation of the protocols for communicating with the
   server.  These assumptions manifest themselves in an implementation
   when a standardized protocol negotiation technique defined by the
   protocol is ignored, and instead, some kind of rule is coded into the
   software that comes to its own conclusion about what the negotiation
   would have determined.  The result is often a loss of
   interoperability, degradation in reliability, and worsening of user
   experience.
   加えて、クライアントはサーバと通信するために必要なプロトコルについ
   て関心があります。  結果的に、クライアントはサーバと通信するプロト
   コルの運用について仮定をするかもしれません。プロトコルの定義した標
   準化されたプロトコル交渉技術が無視されるとき、実装でこれらの仮定が
   あらわれます、そして交渉が何を決定したかについての何らかの種類の規
   則がソフトウェアにコード化されます。この結果は互換性の欠如、信頼性
   の低下、ユーザの体感の悪化です。

   Authentication Algorithm: Though a protocol might support a
      multiplicity of authentication techniques, a client might assume
      that a server always supports one that is only optional according
      to the protocol.  For example, a SIP client contacting a SIP
      server in a domain that is apparently used to identify mobile
      devices (for example, www.example.cellular) might assume that the
      server supports the optional Authentication and Key Agreement
      (AKA) digest technique [10], just because of the domain name that
      was used to access the server.  As another example, a web client
      might assume that a server with the name https.example.com
      supports HTTP over Transport Layer Security (TLS) [16].
   認証アルゴリズム:プロトコルが多様な認証技術をサポートするかもしれ
      ませんが、クライアントはサーバが常にプロトコルの任意実装のある1
      つをサポートすると想定するかもしれません。例えば、外見上はモバイ
      ル機器を識別するために使われるドメイン(例えば、www.example.cellular)
      のSIPサーバと通信するSIPクライアントは、サーバにアクセスす
      るために使われたドメイン名を基に、サーバが任意実装の認証と鍵合意
      (AKA)ダイジェスト技術[10]をサポートすると想定するかもしれません。
      もう1つの例として、ウェブクライアントはhttps.example.comという
      名前のサーバが輸送層セキュリティ(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.
   プロトコル拡張:クライアントがサーバに対し、任意実装のプロトコル拡張
      の操作を試みるかもしれません。そしてクライアントは、必要な後退論
      理を実装するより、間違って拡張がサポートされると想定するかもしれ
      ません。例えば、要求に対する信頼できる暫定的な応答を必要とするS
      IPクライアント(RFC3262[17])がドメインsip.example.telecom
      のサーバがこの拡張をサポートすると想定するかもしれません。さらに、
      自分が通信するすべてのサーバがこのドメインにあり、従ってすべてが
      この拡張をサポートすると想定するから、クライアントはRFC326
      2で定義された後退行動を実装しないでしょう。しかしながら、もし仮
      定が間違っているなら、クライアントは全ての電話が不可能です。

   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国コードTLC(ccTLD)のサーバからのウェ
      ブページの全てのテキストはドイツ語と想定し、フィンランド語に翻訳
      を試みるかもしれません。もしテキストが実際にはフランス語にあった
      なら、これは劇的に失敗するでしょう。不幸にも、しばしばサーバはこ
      のような印を付ける事が必要と想定せず、適切に内容の言語の印を付け
      ないので、このクライアント行動は時々存在します。これは誤った仮定
      が悪性の循環を作る例です。

4.3.  By the Server
4.3.  サーバによる

   The server, like the client, is an automaton.  Let us consider one
   servicing a particular domain -- www.company.cellular, for example.
   It might assume that all clients connecting to this domain support
   particular capabilities, rather than using the underlying protocol to
   make this determination.  Some examples include:
   サーバは、クライアント同様に、自動装置です。1つの特定のドメイン−
   例えばwww.company.cellular−でサービスを提供するとしましょう。サー
   バは、基盤プロトコルを能力サポートの判断に使うことなしに、このドメ
   インに接続しているすべてのクライアントが特定の能力をサポートすると
   想定するかもしれません。例として以下を含みます:

   Authentication Algorithm: The server can assume that a client
      supports a particular, optional, authentication technique, and it
      therefore does not support the mandatory one.
   認証アルゴリズム:サーバはクライアントが任意実装の特定の認証技術を
      サポートすると想定するでき、従って必須の技術をサポートしません。

   Language: The server can serve content in a particular language,
      based on an assumption that clients accessing the domain speak a
      particular language, or based on an assumption that clients coming
      from a particular IP address speak a certain language.
   言語:サーバは、ドメインにアクセスしているクライアントが特定の言語
      を話すと仮定する、あるいは特定のIPアドレスから来ているクライア
      ントがある言語を話すという仮定に基づいて、特定の言語内容をサポー
      トすることができます。

   Data Formats: The server can assume that the client supports a
      particular set of MIME types and is only capable of sending ones
      within that set.  When it generates content in a protocol
      response, it ignores any content negotiation headers that were
      present in the request.  For example, a web server might ignore
      the Accept HTTP header field and send a specific image format.
   データフォーマット:サーバはクライアントが特定のMIME種別をサポー
      トすると想定し、その特定のものだけを送ることができます。サーバは
      プロトコル応答でコンテンツを生成するとき、要求に存在しているコン
      テンツ交渉ヘッダを無視します。例えば、ウェブサーバがAccept HTTP
      ヘッダフィールドを無視し、特定のイメージ形式を送るかもしれません。

   Protocol Extensions: The server might assume that the client supports
      a particular optional protocol extension, and so it does not
      support the fallback behavior necessary in the case where the
      client does not.
   プロトコル拡張:サーバはクライアントが特定の任意実装のプロトコル拡
      張をサポートする想定するかもしれません、それでクライアントが実装
      しない時に必要な後退行動をサポートしません。

   Client Characteristics: The server might assume certain things about
      the physical characteristics of its clients, such as memory
      footprint, processing power, screen sizes, screen colors, pointing
      devices, and so on.  Based on these assumptions, it might choose
      specific behaviors when processing a request.  For example, a web
      server might always assume that clients connect through cell
      phones, and therefore return content that lacks images and is
      tuned for such devices.
   クライアント特性:サーバはメモリ量や処理能力やスクリーンの大きさや
      スクリーンの色やポインティングデバイスなどのクライアントの物理特
      性についてのある特定のことを想定するかもしれません。これらの仮定
      に基づいて、要求を処理するとき、サーバは特定の行動を選択するかも
      しれません。例えば、ウェブサーバが常にクライアントが携帯電話を通
      して接続すると想定し、イメージを除き、このような装置のために調整
      されるコンテンツを返すかもしれません。

5.  Consequences of False Assumptions
5.  誤った仮定の結果

   There are numerous negative outcomes that can arise from the various
   false assumptions that users, servers, and clients can make.  These
   include:
   ユーザやサーバやクライアントの起こす種々な誤った仮定から生じる多数
   の負の結果があります。これらは以下を含みます:

   Interoperability Failure: In these cases, the client or server
      assumed some kind of protocol operation, and this assumption was
      wrong.  The result is that the two are unable to communicate, and
      the user receives some kind of an error.  This represents a total
      interoperability failure, manifesting itself as a lack of service
      to users of the system.  Unfortunately, this kind of failure
      persists.  Repeated attempts over time by the client to access the
      service will fail.  Only a change in the server or client software
      can fix this problem.
   互換性失敗:これの場合、クライアントあるいはサーバは何らかの種類のプ
      ロトコルオペレーションを仮定し、そしてこの仮定は間違っていました。
      結果は2者が通信不可能になり、ユーザがある種のエラーを受けるという
      ことです。これは、システムのユーザにサービスをしない形で表れ、完全
      な互換性失敗を表します。不幸にも、この種の失敗は持続します。サービ
      スにアクセスするクライアントからの長期間の繰り返された試みが失敗す
      るでしょう。サーバあるいはクライアントソフトウェアの変更でのみこの
      問題を直すことができます。

   System Failure: In these cases, the client or server misinterpreted a
      protocol operation, and this misinterpretation was serious enough
      to uncover a bug in the implementation.  The bug causes a system
      crash or some kind of outage, either transient or permanent (until
      user reset).  If this failure occurs in a server, not only will
      the connecting client lose service, but other clients attempting
      to connect will not get service.  As an example, if a web server
      assumes that content passed to it from a client (created, for
      example, by a digital camera) is of a particular content type, and
      it always passes image content to a codec for decompression prior
      to storage, the codec might crash when it unexpectedly receives an
      image compressed in a different format.  Of course, it might crash
      even if the Content-Type was correct, but the compressed bitstream
      was invalid.  False assumptions merely introduce additional
      failure cases.
   システム失敗:この場合、クライアントあるいはサーバがプロトコルオペ
      レーションを誤解します、そしてこの誤解は実装のバグを暴露するのに
      十分なほど深刻です。バグはシステム故障あるいは何らかの種類の短期
      または(ユーザがリセットするまでの)永久の機能停止を起こします。
      もしこの失敗がサーバで起こるなら、単に接続しているクライアントが
      サービスを失うであろうだけではなく、接続しようと試みている他のク
      ライアントもサービスを受けないでしょう。例えば、ウェブサーバがク
      ライアントから渡されたコンテンツ(例えば、デジタルカメラによって
      作られたもの)が特定のコンテンツ種別と想定します、そして常に保存
      する前に圧縮解除のためのコーデックにイメージ内容を渡します、もし
      異なるフォーマットで圧縮されたイメージを受け取るとき、コーデック
      は停止するかもしれません。もちろん、圧縮されたビットストリームが
      無効なら、たとえコンテンツ種別が正しかったとしても停止するかもし
      れません。誤った仮定がただ追加の失敗の場合を導入します。

   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.
   セキュリティ低下:この場合、使われるべきであったものより弱いセキュリ
      ティメカニズムが使われます。例えば、クライアントが強い認証アルゴ
      リズムをサポートするために最近アップグレードされても、ドメインサー
      バは限定された1つの認証アルゴリズムでクライアントが通信を行うと
      想定するかもしれません。

6.  Reasons Why the Assumptions Can Be False
6.  仮定がなぜ誤り得るかという理由

   Assumptions made by clients and servers about the operation of
   protocols when contacting a particular domain are brittle, and can be
   wrong for many reasons.  On the server side, many of the assumptions
   are based on the notion that a domain name will only be given to, or
   used by, a restricted set of clients.  If the holder of the domain
   name assumes something about those clients, and can assume that only
   those clients use the domain name, then it can configure or program
   the server to operate specifically for those clients.  Both parts of
   this assumption can be wrong, as discussed in more detail below.
   プロトコルオペレーションについてクライアントとサーバによってされた仮
   定は特定のドメインと接触するとき不安定で、多くの理由で不適当であり得
   ます。サーバ側で、仮定の多くはドメイン名が限定されたクライアントのみ
   に与えられるか、あるいは使われるであろうという概念に基づいています。
   もしドメイン名の保有者がそれらのクライアントについて何かを仮定して、
   そしてただそれらのクライアントだけがドメイン名を使うと想定することが
   できるなら、特にそれらのクライアントのために稼働するサーバを設置する
   か、あるいはプログラムすることができます。下で多く論じられるように、
   この仮定の両方の部分が間違い得ます。

   On the client side, the notion is similar, being based on the
   assumption that a server within a particular domain will provide a
   specific type of service.  Sub-delegation and evolution, both
   discussed below, can make these assumptions wrong.
   クライアント側での概念は、特定のドメインのサーバが特定のタイプのサー
   ビスを提供するであろうという仮定に基づいていて、類似です。下記で論じ
   る副委任と進化はこれらの仮定を誤らせ得ます。

6.1.  Evolution
6.1.  進展

   The Internet and the devices that access it are constantly evolving,
   often at a rapid pace.  Unfortunately, there is a tendency to build
   for the here and now, and then worry about the future at a later
   time.  Many of the assumptions above are predicated on
   characteristics of today's clients and servers.  Support for specific
   protocols, authentication techniques, or content are based on today's
   standards and today's devices.  Even though they may, for the most
   part, be true, they won't always be.  An excellent example is mobile
   devices.  A server servicing a domain accessed by mobile devices
   might try to make assumptions about the protocols, protocol
   extensions, security mechanisms, screen sizes, or processor power of
   such devices.  However, all of these characteristics can and will
   change over time.
   インターネットとそれにアクセスする装置は、しばしば速いペースで、常に
   進展しています。不幸にも、将来のことは後で考え、今ここでの考えで構築
   する傾向があります。上記の仮定の多くが今日のクライアントとサーバの特
   性に基づきます。特定のプロトコルに対するサポートと認証技術と内容がそ
   の時点の標準とその時点の装置に基づいています。それらは、たいていは正
   しいかもしれませんが、常に正しいとは限りません。  優れた例はモバイル
   機器です。モバイル装置によってアクセスされるドメインにサービスを提供
   しているサーバが、プロトコルやプロトコル拡張やセキュリティメカニズム
   やスクリーンの大きさやこのような装置の処理能力についての仮定をするか
   もしれません。しかしながら、これらすべての特性は時間が経つと変化する
   でしょう。

   When they do change, the change is usually evolutionary.  The result
   is that the assumptions remain valid in some cases, but not in
   others.  It is difficult to fix such systems, since it requires the
   server to detect what type of client is connecting, and what its
   capabilities are.  Unless the system is built and deployed with these
   capability negotiation techniques built in to begin with, such
   detection can be extremely difficult.  In fact, fixing it will often
   require the addition of such capability negotiation features that, if
   they had been in place and used to begin with, would have avoided the
   problem altogether.
   変更をするとき、変化は通常進化です。その結果、ある場合は仮定は正し
   いままですが、他の場合は違います。このようなシステムを直すことは、
   サーバがどの種類のクライアントが接続しているか検出し、その能力が何
   であるか検出することを必要としますから、難しいです。システムが作ら
   れて、初めから組み込みの能力交渉技術が実行されないなら、このような
   発見は極めて難しくなり得ます。実際、これを直すことはしばしば、もし
   初めからあって使われたなら問題を避けたであろう、能力交渉機能の追加
   を必要とするでしょう。

6.2.  Leakage
6.2.  漏洩

   Servers also make assumptions because of the belief that they will
   only be accessed by specific clients, and in particular, those that
   are configured or provisioned to use the domain name.  In essence,
   there is an assumption of community -- that a specific community
   knows and uses the domain name, while others outside of the community
   do not.
   サーバは特定のクライアントのみからアクセスされるだけであるであろう
   という信念のために仮定をします、特にドメイン名を使うための設定や供
   給される人たちによって仮定されます。本質的に、特定の共同体がドメイ
   ン名を知り使うのに対し、共同体外のものがそうしないという、共同体の
   仮定があります。

   The problem is that this notion of community is a false one.  The
   Internet is global.  The DNS is global.  There is no technical
   barrier that separates those inside of the community from those
   outside.  The ease with which information propagates across the
   Internet makes it extremely likely that such domain names will
   eventually find their way into clients outside of the presumed
   community.  The ubiquitous presence of domain names in various URI
   formats, coupled with the ease of conveyance of URIs, makes such
   leakage merely a matter of time.  Furthermore, since the DNS is
   global, and since it can only have one root [12], it becomes possible
   for clients outside of the community to search and find and use such
   "special" domain names.
   問題は共同体のこの概念が誤ったものであるということです。インターネッ
   トはグローバルです。DNSはグローバルです。 共同体の内部を外部から
   分離する技術的な障壁がありません。情報がインターネットの向こう側に
   伝える容易さにより、結局は予想される共同体の外のクライアントがこの
   ようなドメイン名を見いだすことは極めてありそうです。種々なURIフォー
   マット内のドメイン名の存在は、URIの譲渡の容易さにより、このよう
   な漏れをただ時間の問題にします。さらに、DNSがグローバルで、そし
   てただ1本の根[12]を持つことだけができるので、共同体の外のクライア
   ントがこのような「特別」なドメイン名を検索し、見いだして、使うこと
   は可能になります。

   Indeed, this leakage is a strength of the Internet architecture, not
   a weakness.  It enables global access to services from any client
   with a connection to the Internet.  That, in turn, allows for rapid
   growth in the number of customers for any particular service.
   実際、この漏洩は、弱点ではなく、インターネット体系の強さです。これ
   は接点を持っている全てのクライアントからインターネットサービスへの
   世界的なアクセスを可能にします。これは任意の特別なサービスの顧客数
   の速い増大を可能にします。

6.3.  Sub-Delegation
6.3.  副委任

   Clients and users make assumptions about domains because of the
   notion that there is some kind of centralized control that can
   enforce those assumptions.  However, the DNS is not centralized; it
   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は中央集権化されません;分散されています。
   もしドメインがそのサブドメインへ委任をせず、そして1つのゾーンの中に
   そのレコードの全てを持っているなら、そのドメインの運用について中央集
   権化されたポリシーを維持することは可能です。しかしながら、ドメインが
   十分に大きくなり、ドメイン管理者が他の権威にサブドメインの委任を始め
   るなら、それぞれのサブドメインで提供されたサービスの性質に対して中央
   集権的制御でも維持することはますます難しくなります。

   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に対しexample.foo、を登録してそのサービス
   を準備するかもしれません。これは、副委任のように、その上で中央集権化
   された管理を維持することが難しいドメインの数の増大をもたらします。

   Not that it is not possible, since there are many examples of
   successful administration of policies across sub-domains many levels
   deep.  However, it takes an increasing amount of effort to ensure
   this result, as it requires human intervention and the creation of
   process and procedure.  Automated validation of adherence to policies
   is very difficult to do, as there is no way to automatically verify
   many policies that might be put into place.
   多くのレベル深いサブドメインでポリシーの成功した運用の多くの例がある
   ので、それができないと言うわけではありません。しかしながら、これが人
   間の介入と工程と手順の創造を必要とするので、この結果を保証する多大な
   努力を必要とします。あるべき多くのポリシを自動検証する方法がないので、
   ポリシ厳守の自動化された検査は非常に難しいです。

   A less costly process for providing centralized management of
   policies is to just hope that any centralized policies are being
   followed, and then wait for complaints or perform random audits.
   Those approaches have many problems.
   ポリシの中央集権化された管理を提供するそれほど高価でない工程は、ただ
   中央集権化されたポリシに従うことを希望し、次に苦情を待つか、あるいは
   無作為の監査を行なうことです。これらの方法は多くの問題を持っています。

   The invalidation of assumptions due to sub-delegation is discussed in
   further detail in Section 4.1.3 of [8] and in Section 3.3 of [20].
   副委任による仮定の未確認は、[8]の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.
   副委任を超えたポリシ連続性の弱さの結果として、もしクライアントある
   いはユーザが(「.wifi」のような)TLDと何らかの種類の特性が結び付
   いていると思っても、特定の名前で識別されたサーバでこの特性が存在し
   ないサブドメインの数が多数ありそうです。例えば、
   「store.chain.company.provider.wifi」で、4つの委任レベルがあるかも
   しれず、「.wifi」の保有者が勤勉に働いていないなら、「.wifi」の保有
   者が強いることを望む特性が存在していないことを非常にありそうです。
   これらの特性は人的ミスのためにあるいは特性を忠実に支持しないという
   故意の決定のために存在していないかもしれません。

6.4.  Mobility
6.4.  移動性

   One of the primary value propositions of a hostname as an identifier
   is its persistence.  A client can change IP addresses, yet still
   retain a persistent identifier used by other hosts to reach it.
   Because their value derives from their persistence, hostnames tend to
   move with a host not just as it changes IP addresses, but as it
   changes access network providers and technologies.  For this reason,
   assumptions made about a host based on the presumed access network
   corresponding to that hostname tend to be wrong over time.  As an
   example, a PC might normally be connected to its broadband provider,
   and through dynamic DNS have a hostname within the domain of that
   provider.  However, one cannot assume that any host within that
   network has access over a broadband link; the user could connect
   their PC over a low-bandwidth wireless access network and still
   retain its domain name.
   識別子としてのホスト名に関しての主要な価値のある提言は、その持続で
   す。クライアントがIPアドレスを変えも、他のホストからの接続のため
   に使われる持続的な識別子を維持することができます。それらの値がそれ
   らの持続によって生じるので、IPアドレスが変わるときときだけでなく、
   アクセスネットワークプロバイダと技術を変えるときでも、ホスト名がホ
   ストと一緒に動く傾向があります。この理由のため、ホスト名に対応して
   いる予想されるアクセスネットワークに基づくホストについての仮定が時
   間が経つと間違っている傾向があります。  例えば、PCが通常そのブロー
   ドバンドプロバイダに接続し、動的DNSを通してそのプロバイダのドメ
   イン内のホスト名を持っているかもしれません。しかしながら、そのネッ
   トワーク内のホストが広帯域リンクのアクセスを持つと想定はできません;
   ユーザが、ドメイン名を維持したまま、低帯域幅のワイヤレスアクセスネッ
   トワークにPCを接続できます。

6.5.  Human Error
6.5.  人的誤り

   Of course, human error can be the source of errors in any system, and
   the same is true here.  There are many examples relevant to the
   problem under discussion.
   もちろん、人的誤りはどんなシステムででもエラーの発生源であり得て、
   同じことがここでも言えます。議論中の問題に重要な多くの例があります。

   A client implementation may make the assumption that, just because a
   DNS SRV record exists for a particular protocol in a particular
   domain, indicating that the service is available on some port, that
   the service is, in fact, running there.  This assumption could be
   wrong because the SRV records haven't been updated by the system
   administrators to reflect the services currently running.  As another
   example, a client might assume that a particular domain policy
   applies to all sub-domains.  However, a system administrator might
   have omitted to apply the policy to servers running in one of those
   sub-domains.
   DNSサービス資源レコードが特定のドメインの特定のプロトコルのため
   存在し、サービスがあるポートで利用可能と示されているため、サービス
   が実際にそこで動いていると、クライアント実装が仮定するかもしれませ
   ん。現在動いているサービスを反映するように、サービス資源レコードが
   システム管理者によって更新されていなければ、この仮定は間違いです。
   他の例として、クライアントが特定のドメインポリシがすべてのサブドメ
   インに当てはまると想定するかもしれません。しかしながら、システム管
   理者がサブドメインの1つで動作しているサーバにポリシを適用すること
   を省略したかもしれません。

7.  Recommendations
7.  推薦

   Based on these problems, the clear conclusion is that clients,
   servers, and users should not make assumptions on the nature of the
   service provided to, or by, a domain.  More specifically, however,
   the following can be said:
   これらの問題に基づく明確な結論は、クライアントとサーバとユーザが、
   ドメインに、あるいはドメインによって提供されたサービスの性質に仮定
   をするべきではないということです。さらに言うと、しかしながら、次の
   ことを言うことができます:

   Follow the specifications: When specifications define mandatory
      baseline procedures and formats, those should be implemented and
      supported, even if the expectation is that optional procedures
      will most often be used.  For example, if a specification mandates
      a particular baseline authentication technique, but allows others
      to be negotiated and used, implementations need to implement the
      baseline authentication algorithm even if the other ones are used
      most of the time.  Put more simply, the behavior of the protocol
      machinery should never change based on the domain name of the
      host.
   仕様に従う:仕様が必須の基本手順とフォーマットを定義するとき、たと
      えオプションの手続きが最もしばしば使われると期待されていても、そ
      れらは実装されサポートされるべきです。例えば、もし仕様が特定の基
      本認証技術を要請するが、交渉で他のものを使うことが可能なら、たと
      え他のものがほとんどいつも使われるとしても、実装が基本認証アルゴ
      リズムを実装する必要があります。より簡単に言うと、プロトコル機械
      の行動は決してホストのドメイン名に基づいて変化するべきではありま
      せん。

   Use capability negotiation: Many protocols are engineered with
      capability negotiation mechanisms.  For example, a content
      negotiation framework has been defined for protocols using MIME
      content [13] [14] [15].  SIP allows for clients to negotiate the
      media types used in the multimedia session, as well as protocol
      parameters.  HTTP allows for clients to negotiate the media types
      returned in requests for content.  When such features are
      available in a protocol, client and servers should make use of
      them rather than making assumptions about supported capabilities.
      A corollary is that protocol designers should include such
      mechanisms when evolution is expected in the usage of the
      protocol.
   能力交渉の使用:多くのプロトコルが能力交渉メカニズムが設計されます。
      例えば、MIMEコンテンツを使うプロトコル[13][14][15]でコンテン
      ツ内容交渉枠組みが定義されました。SIPはクライアントにマルチメ
      ディアのセッションで使われたメディア種別の交渉を許し、プロトコル
      パラメータも同様です。HTTPはクライアントにコンテンツ要求で返
      されたメディア種別の交渉を許します。このような機能がプロトコルで
      利用可能であるとき、クライアントとサーバがサポートされた能力につ
      いて仮定をするよりそれらを利用するべきです。結論は、プロトコルの
      使用法に進化が見込まれるとき、プロトコル設計者はこのようなメカニ
      ズムを含めるべきということです。

   "Be liberal in what you accept, and conservative in what you send"
      [18]:  This axiom of Internet protocol design is applicable here
      as well.  Implementations should be prepared for the full breadth
      of what a protocol allows another entity to send, rather than be
      limiting in what it is willing to receive.
   「受信するものに寛大で、送信するものは伝統的であってください」[18]:
      インターネットプロトコル設計のこの公理は同様にここでも適用可能
      です。プロトコルが他の相手が送ることを許している全てのものにに
      対し、実装は受信できるものを制限するのではなく、鷹揚さの準備を
      すべきです。

   To summarize -- there is never a need to make assumptions.  Rather
   than doing so, utilize the specifications and the negotiation
   capabilities they provide, and the overall system will be robust and
   interoperable.
   要約すると−決して仮定をする必要がありません。そうするより、仕様を
   利用してください、そうすればそれらが提供する交渉能力と全体的なシス
   テムは強靭で、そして協同使用可能であるでしょう。

8.  A Note on RFC 2219 and RFC 2782
8.  RFC2219とRFC2782の注釈

   Based on the definition of an assumption given here, the behavior
   hinted at by records in the DNS also represents an assumption.  RFC
   2219 [19] defines well-known aliases that can be used to construct
   domain names for reaching various well-known services in a domain.
   This approach was later followed by the definition of a new resource
   record, the SRV record [2], which specifies that a particular service
   is running on a server in a domain.  Although both of these
   mechanisms are useful as a hint that a particular service is running
   in a domain, both of them represent assumptions that may be false.
   However, they differ in the set of reasons why those assumptions
   might be false.
   ここでされた仮定の定義に基づいて、DNSでレコードによってほのめか
   された行動も仮定を表します。RFC2219[19]はドメインの種々なよ
   く知られているサービスに到達するために、ドメイン名を作るために使う
   ことができる既知の別名を定義します。この方法は後に特別のサービスが
   ドメインのサーバ上で走っていることを明示する新しい資源レコード、S
   RVレコード[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.
   domain.comドメインの所有者がRFC2219の命名慣習を知らないか従
   わなければ、「ftp.example.com」がFTPサーバであると想定するクライ
   アントが間違うかもしれません。RFC2782で、特別のサービスのS
   RVレコードはただドメイン管理者の明示的な選択によってのみ存在する
   でしょう、そのためそのホストがこのサービスを提供すると想定するクラ
   イアントは、設定の人的誤りでのみ間違うでしょう。この場合、仮定は間
   違っている可能性がそれほど高くありませんが、しかし確かにあり得ます。

   The only way to determine with certainty that a service is running on
   a host is to initiate a connection to the port for that service, and
   check.  Implementations need to be careful not to codify any
   behaviors that cause failures should the information provided in the
   record actually be false.  This borders on common sense for robust
   implementations, but it is valuable to raise this point explicitly.
   確実にサービスがホスト上で動作していると決定する唯一の方法は、その
   サービスのポートに接続を行って調べることです。もしレコードで提供さ
   れた情報が実際には誤っていたなら、実装が故障を起こす行動を起こさな
   いように気を使う必要があります。これは強靭な実装の常識に類似します
   が、明示的にこの点を取り上げることは大切です。

9.  Security Considerations
9.  セキュリティの考察

   One of the assumptions that can be made by clients or servers is the
   availability and usage (or lack thereof) of certain security
   protocols and algorithms.  For example, a client accessing a service
   in a particular domain might assume a specific authentication
   algorithm or hash function in the application protocol.  It is
   possible that, over time, weaknesses are found in such a technique,
   requiring usage of a different mechanism.  Similarly, a system might
   start with an insecure mechanism, and then decide later on to use a
   secure one.  In either case, assumptions made on security properties
   can result in interoperability failures, or worse yet, providing
   service in an insecure way, even though the client asked for, and
   thought it would get, secure service.  These kinds of assumptions are
   fundamentally unsound even if the records themselves are secured with
   DNSSEC.
   クライアントあるいはサーバができる仮定の1つは、ある特定のセキュリ
   ティプロトコルとアルゴリズムの有効性と使用法(あるいはその欠如)で
   す。例えば、特定のドメインでサービスにアクセスしているクライアント
   がアプリケーションプロトコルで特定の認証アルゴリズムあるいはハッシュ
   関数を仮定するかもしれません。長期的にみてこのような技術で弱点が見
   いだされる事がありえて、異なるメカニズムの使用を必要としますす。同
   様に、システムが不安定なメカニズムから始まり、後で安全なメカニズム
   を使うと決定するかもしれません。どちらの場合も、セキュリティ特性に
   対する仮定が互換性障害をもたらすことがあり、さらに悪い場合、クライ
   アントが安全なサービスを元名それが可能でも、不安定な方法でサービス
   を提供することがあります。たとえレコード自身がDNSSECによって
   安全に保たれるとしても、これらの種類の仮定は基本的に不合理です。

10.  Acknowledgements
10. 謝辞

   The IAB would like to thank John Klensin, Keith Moore and Peter Koch
   for their comments.
   IBAはコメントに対してJohn KlensinとKeith MooreとPeter Kochに
   感謝します。

11.  IAB Members
11.  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

      David Meyer

      Pekka Nikander

      Eric Rescorla

      Pete Resnick

      Jonathan Rosenberg

12.  Informative References
12.  有益な参考文献

   [1]   Mockapetris, P., "Domain names - concepts and facilities",
         STD 13, RFC 1034, November 1987.

   [2]   Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
         specifying the location of services (DNS SRV)", RFC 2782,
         February 2000.

   [3]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         Three: The Domain Name System (DNS) Database", RFC 3403,
         October 2002.

   [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.

   [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.

   [6]   Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
         Protocol (RTSP)", RFC 2326, April 1998.

   [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.

   [8]   Eastlake, D., ".sex Considered Dangerous", RFC 3675,
         February 2004.

   [9]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
         April 2001.

   [10]  Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
         Protocol (HTTP) Digest Authentication Using Authentication and
         Key Agreement (AKA)", RFC 3310, September 2002.

   [11]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part One: Format of Internet Message Bodies",
         RFC 2045, November 1996.

   [12]  Internet Architecture Board, "IAB Technical Comment on the
         Unique DNS Root", RFC 2826, May 2000.

   [13]  Klyne, G., "Indicating Media Features for MIME Content",
         RFC 2912, September 2000.

   [14]  Klyne, G., "A Syntax for Describing Media Feature Sets",
         RFC 2533, March 1999.

   [15]  Klyne, G., "Protocol-independent Content Negotiation
         Framework", RFC 2703, September 1999.

   [16]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [17]  Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
         Responses in Session Initiation Protocol (SIP)", RFC 3262,
         June 2002.

   [18]  Braden, R., "Requirements for Internet Hosts - Communication
         Layers", STD 3, RFC 1122, October 1989.

   [19]  Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
         Services", BCP 17, RFC 2219, October 1997.

   [20]  Faltstrom, P., "Design Choices When Expanding DNS", Work in
         Progress, June 2005.

Author's Address
著者のアドレス

   Jonathan Rosenberg, Editor
   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).
   著作権(C)インターネット社会(2006)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.
   この文書はBCP78に含まれる権利と許可と制限の適用を受け、そして
   この中に明らかにされる以外は著者がすべての権利を維持します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
   者が代表するか貢献者を後援する組織(もしあれば)とインターネット学会
   とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
   報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
   ある事の保障を含め、全ての保証を拒否します。

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文書の権利に関する手続
   きの情報はBCP78とBCP79を見てください。

   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エディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So