Network Working Group J. Rosenberg
Request for Comments: 3263 dynamicsoft
Obsoletes: 2543 H. Schulzrinne
Category: Standards Track Columbia U.
June 2002
Session Initiation Protocol (SIP): Locating SIP Servers
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail.
セッション開始プロトコル（SIP）は、クライアントが連絡するネクストホップのIPアドレス、ポート、およびトランスポートプロトコルにSIP URI（Uniform Resource Identifier）を解決できるようにDNSの手順を使用しています。また、プライマリクライアントが失敗した場合、サーバーは、バックアップクライアントに応答を送信できるようにDNSを使用しています。この文書は詳細にこれらのDNS手順を説明します。
Table of Contents
目次
1 Introduction ........................................ 2
2 Problems DNS is Needed to Solve ..................... 2
3 Terminology ......................................... 5
4 Client Usage ........................................ 5
4.1 Selecting a Transport Protocol ...................... 6
4.2 Determining Port and IP Address ..................... 8
4.3 Details of RFC 2782 Process ......................... 9
4.4 Consideration for Stateless Proxies ................. 10
5 Server Usage ........................................ 11
6 Constructing SIP URIs ............................... 12
7 Security Considerations ............................. 12
8 The Transport Determination Application ............. 13
9 IANA Considerations ................................. 14
10 Acknowledgements .................................... 14
11 Normative References ................................ 15
12 Informative References .............................. 15
13 Authors' Addresses .................................. 16
14 Full Copyright Statement ............................ 17
1 Introduction
1はじめに
The Session Initiation Protocol (SIP) (RFC 3261 [1]) is a client-server protocol used for the initiation and management of communications sessions between users. SIP end systems are called user agents, and intermediate elements are known as proxy servers. A typical SIP configuration, referred to as the SIP "trapezoid", is shown in Figure 1. In this diagram, a caller in domain A (UA1) wishes to call Joe in domain B (joe@B). To do so, it communicates with proxy 1 in its domain (domain A). Proxy 1 forwards the request to the proxy for the domain of the called party (domain B), which is proxy 2. Proxy 2 forwards the call to the called party, UA 2.
セッション開始プロトコル（SIP）（RFC 3261 [1]）は、ユーザ間の通信セッションの開始および管理に使用されるクライアント・サーバ・プロトコルです。 SIPエンドシステムは、ユーザエージェントと呼ばれ、中間の要素は、プロキシサーバとして知られています。典型的なSIP構成は、SIP「台形」と呼ばれる、ドメインA（UA1）に発信者がドメインB（ジョーする@ B）にジョーを呼び出すことを望む、この図では図1に示されています。そのためには、そのドメイン（ドメインA）でプロキシ1と通信します。プロキシ1つの転送2.プロキシ2転送呼者、UA 2まで呼プロキシである被呼者のドメイン（ドメインB）のプロキシに要求。
As part of this call flow, proxy 1 needs to determine a SIP server for domain B. To do this, proxy 1 makes use of DNS procedures, using both SRV [2] and NAPTR [3] records. This document describes the specific problems that SIP uses DNS to help solve, and provides a solution.
これを行うには、ドメインBのSIPサーバを決定するために、このコールフロー、プロキシ1つのニーズの一部として、プロキシ1は、両方のSRVを使用して、DNS手順を利用する[2]とNAPTR [3]のレコード。この文書では、SIPを解決するためにDNSを使用して、特定の問題について説明し、解決策を提供します。
2 Problems DNS is Needed to Solve
2問題DNSを解決するために必要とされます
DNS is needed to help solve two aspects of the general call flow described in the Introduction. The first is for proxy 1 to discover the SIP server in domain B, in order to forward the call for joe@B. The second is for proxy 2 to identify a backup for proxy 1 in the event it fails after forwarding the request.
DNSは、はじめに記載されている一般的なコールフローの二つの側面を解決するために必要とされます。最初はジョー@ Bのためのコールを転送するためには、ドメインBにおけるSIPサーバを発見するためのプロキシ1のためです。第二は、それが要求を転送した後に失敗した場合に、プロキシ1のバックアップを識別するために、プロキシ2のためのものです。
For the first aspect, proxy 1 specifically needs to determine the IP address, port, and transport protocol for the server in domain B. The choice of transport protocol is particularly noteworthy. Unlike many other protocols, SIP can run over a variety of transport protocols, including TCP, UDP, and SCTP. SIP can also use TLS. Currently, use of TLS is defined for TCP only. Thus, clients need to be able to automatically determine which transport protocols are available. The proxy sending the request has a particular set of transport protocols it supports and a preference for using those transport protocols. Proxy 2 has its own set of transport protocols it supports, and relative preferences for those transport protocols. All proxies must implement both UDP and TCP, along with TLS over TCP, so that there is always an intersection of capabilities. Some form of DNS procedures are needed for proxy 1 to discover the available transport protocols for SIP services at domain B, and the relative preferences of those transport protocols. Proxy 1 intersects its list of supported transport protocols with those of proxy 2 and then chooses the protocol preferred by proxy 2.
第一の態様のために、プロキシ1は、具体的には、トランスポートプロトコルの選択は、特に注目すべきであるドメインBのサーバのIPアドレス、ポート、およびトランスポートプロトコルを決定する必要があります。多くの他のプロトコルとは異なり、SIPは、TCP、UDP、およびSCTPなどのトランスポートプロトコルの様々な、上で実行することができます。 SIPはまた、TLSを使用することができます。現在、TLSの使用はTCPだけのために定義されています。したがって、クライアントは自動的にプロトコルが利用可能な交通機関を決定できるようにする必要があります。要求を送信するプロキシは、それがサポートするトランスポートプロトコルの特定のセットとそれらのトランスポートプロトコルを使用するための優先順位を有します。プロキシ2は、トランスポート、それがサポートするプロトコル、およびそれらのトランスポートプロトコルのための相対的な好みの独自のセットを持っています。能力の交点が常に存在するように、すべてのプロキシは、TCP上のTLSと一緒に、UDPとTCPの両方を実装する必要があります。 DNS手順のいくつかのフォームは、ドメインBのSIPサービスのために利用できるトランスポートプロトコル、およびそれらのトランスポートプロトコルの相対的な好みを発見するために、プロキシ1のために必要とされます。プロキシ1は、プロキシ2のものとサポートされているトランスポートプロトコルのリストを交差した後、プロキシ2が好ましいプロトコルを選択します。
............................ ..............................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | Proxy |------------- | Proxy | .
. | 1 | . . | 2 | .
. | | . . | | .
. / +-------+ . . +-------+ \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | | . . | | .
. | UA 1 | . . | UA 2 | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
............................ ..............................
Figure 1: The SIP trapezoid
図1：SIP台形
It is important to note that DNS lookups can be used multiple times throughout the processing of a call. In general, an element that wishes to send a request (called a client) may need to perform DNS processing to determine the IP address, port, and transport protocol of a next hop element, called a server (it can be a proxy or a user agent). Such processing could, in principle, occur at every hop between elements.
DNSルックアップがコールの処理を通じて複数回使用できることに注目することが重要です。一般的に、（クライアントと呼ばれる）要求を送信したい要素と呼ばれる、次のホップ素子のIPアドレス、ポート、およびトランスポートプロトコルを決定するために、DNS処理を実行するサーバを必要とするかもしれない（それがプロキシまたはすることができユーザーエージェント）。このような処理は、原則的には、要素間のすべてのホップで発生する可能性があります。
Since SIP is used for the establishment of interactive communications services, the time it takes to complete a transaction between a caller and called party is important. Typically, the time from when the caller initiates a call until the time the called party is alerted should be no more than a few seconds. Given that there can be multiple hops, each of which is doing DNS lookups in addition to other potentially time-intensive operations, the amount of time available for DNS lookups at each hop is limited.
SIPは、インタラクティブ通信サービスの確立のために使用されているので、それは発信者および受信者の間でトランザクションを完了するのにかかる時間は重要です。一般的に、呼び出し側が被呼加入者が警告されるまで通話を開始してからの時間は数秒以下でなければなりません。他の潜在的に時間のかかる操作に加えて、DNSルックアップを行っているそれぞれが複数のホップが存在することができることを考えると、各ホップでDNSルックアップのために利用可能な時間の量は限られています。
Scalability and high availability are important in SIP. SIP services scale up through clustering techniques. Typically, in a realistic version of the network in Figure 1, proxy 2 would be a cluster of homogeneously configured proxies. DNS needs to provide the ability for domain B to configure a set of servers, along with prioritization and weights, in order to provide a crude level of capacity-based load balancing.
スケーラビリティと高可用性は、SIPにおいて重要です。 SIPサービスは、クラスタリング技術によってスケールアップ。典型的には、図1のネットワークの現実的なバージョンでは、プロキシ2は、均一に構成プロキシのクラスタであろう。 DNSは、キャパシティ・ベースのロード・バランシングの粗レベルを提供するために、優先順位と重みと共に、サーバのセットを構成するため、ドメインBのための能力を提供する必要があります。
SIP assures high availability by having upstream elements detect failures. For example, assume that proxy 2 is implemented as a cluster of two proxies, proxy 2.1 and proxy 2.2. If proxy 1 sends a request to proxy 2.1 and the request fails, it retries the request by sending it to proxy 2.2. In many cases, proxy 1 will not know which domains it will ultimately communicate with. That information would be known when a user actually makes a call to another user in that domain. Proxy 1 may never communicate with that domain again after the call completes. Proxy 1 may communicate with thousands of different domains within a few minutes, and proxy 2 could receive requests from thousands of different domains within a few minutes. Because of this "many-to-many" relationship, and the possibly long intervals between communications between a pair of domains, it is not generally possible for an element to maintain dynamic availability state for the proxies it will communicate with. When a proxy gets its first call with a particular domain, it will try the servers in that domain in some order until it finds one that is available. The identity of the available server would ideally be cached for some amount of time in order to reduce call setup delays of subsequent calls. The client cannot query a failed server continuously to determine when it becomes available again, since this does not scale. Furthermore, the availability state must eventually be flushed in order to redistribute load to recovered elements when they come back online.
SIPは、上流要素が障害を検出有することにより高可用性を保証します。例えば、想定そのプロキシ2は、2つのプロキシ、プロキシ2.1プロキシ2.2のクラスタとして実装されます。プロキシ1がプロキシ2.1にリクエストを送信し、要求が失敗した場合は、プロキシ2.2にそれを送信することにより、要求を再試行します。多くの場合、プロキシ1は、それが最終的に通信するドメインどの知ることができません。この情報は、ユーザーが実際にそのドメイン内の別のユーザーに呼び出しを行う際に知られているであろう。呼び出しが完了した後、プロキシ1は、再びそのドメインと通信しないことがあります。プロキシ1は、数分以内に、異なるドメインの数千と通信することができる、およびプロキシ2は、数分以内に、異なるドメインの数千からの要求を受信することができます。要素は、それが通信するプロキシの動的可用性状態を維持するために、この「多対多」の関係、及びドメインの対の間の通信の間に、おそらく長い間隔、それは一般的に不可能です。プロキシが特定のドメインとの最初の呼び出しを受け取ると、それが利用可能であるものを見つけるまで、それはいくつかのために、そのドメイン内のサーバーをしようとします。利用可能なサーバのアイデンティティは、理想的に後続の呼び出しのコールセットアップの遅延を低減するために、時間のいくつかの量のためにキャッシュされるだろう。これはスケールしないので、クライアントは、それが再び使用可能になったときに決定するために連続して失敗したサーバーを照会することはできません。さらに、可用性の状態は、最終的には、彼らがオンラインに戻ってきたときに回復要素に負荷を再分配するためにフラッシュする必要があります。
It is possible for elements to fail in the middle of a transaction. For example, after proxy 2 forwards the request to UA 2, proxy 1 fails. UA 2 sends its response to proxy 2, which tries to forward it to proxy 1, which is no longer available. The second aspect of the flow in the introduction for which DNS is needed, is for proxy 2 to identify a backup for proxy 1 that it can send the response to. This problem is more realistic in SIP than it is in other transactional protocols. The reason is that some SIP responses can take a long time to be generated, because a human user frequently needs to be consulted in order to generate that response. As such, it is not uncommon for tens of seconds to elapse between a call request and its acceptance.
要素は、トランザクションの途中で失敗することが可能です。例えば、プロキシ2つの転送UA 2に要求した後、プロキシ1は失敗します。 UA 2は使用できなくなったプロキシ1、にそれを転送しようとプロキシ2、にその応答を送信します。 DNSが必要とされる導入における流れの第2の態様は、それが応答を送信することができるプロキシ1のバックアップを識別するために、プロキシ2のためのものです。この問題は、それが他のトランザクションプロトコルであるSIPよりも、より現実的です。その理由は、人間のユーザが頻繁にその応答を生成するために相談する必要があるため、いくつかのSIP応答は、生成されるまでに長い時間がかかることができるということです。数十秒がコール要求とその受け入れの間に経過するためにこのように、それは珍しいことではありません。
3 Terminology
3用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and indicate requirement levels for compliant SIP implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" RFC 2119に記載されるように解釈されるべきである[4]及び対応SIP実装の要求レベルを示します。
4 Client Usage
4クライアントの使用
Usage of DNS differs for clients and for servers. This section discusses client usage. We assume that the client is stateful (either a User Agent Client (UAC) or a stateful proxy). Stateless proxies are discussed in Section 4.4.
DNSの使用方法は、クライアント用とサーバー用に異なります。このセクションでは、クライアントの使用方法について説明します。私たちは、（ユーザエージェントクライアント（UAC）またはステートフルプロキシのいずれか）、クライアントがステートフルであることを前提としています。ステートレスプロキシはセクション4.4で説明されています。
The procedures here are invoked when a client needs to send a request to a resource identified by a SIP or SIPS (secure SIP) URI. This URI can identify the desired resource to which the request is targeted (in which case, the URI is found in the Request-URI), or it can identify an intermediate hop towards that resource (in which case, the URI is found in the Route header). The procedures defined here in no way affect this URI (i.e., the URI is not rewritten with the result of the DNS lookup), they only result in an IP address, port and transport protocol where the request can be sent. RFC 3261 [1] provides guidelines on determining which URI needs to be resolved in DNS to determine the host that the request needs to be sent to. In some cases, also documented in [1], the request can be sent to a specific intermediate proxy not identified by a SIP URI, but rather, by a hostname or numeric IP address. In that case, a temporary URI, used for purposes of this specification, is constructed. That URI is of the form sip:<proxy>, where <proxy> is the FQDN or numeric IP address of the next-hop proxy. As a result, in all cases, the problem boils down to resolution of a SIP or SIPS URI in DNS to determine the IP address, port, and transport of the host to which the request is to be sent.
ここでの手順は、クライアントがSIPまたはSIPS（セキュアSIP）URIで識別されるリソースに要求を送信する必要があるときに呼び出されます。このURIは、要求が（この場合、URIはリクエストURIに見出される）標的とする所望のリソースを識別することができ、またはそれは（その場合には、URIがで発見されたリソースに向かって中間ホップを識別することができますルートヘッダ）。決してここで定義された手順は、このURIに影響を与える（すなわち、URIは、DNSルックアップの結果に書き換えされていない）、彼らは唯一の要求を送信することができますIPアドレス、ポート、およびトランスポートプロトコルにつながります。 RFC 3261 [1] URIが要求に送信する必要があるホストを決定するために、DNSで解決される必要があるかを決定する上での指針を提供します。いくつかの場合において、さらに[1]、要求がSIP URIによって識別されない特定の中間プロキシに送信された、むしろ、ホスト名または数字のIPアドレスによってすることができるで文書。その場合、本明細書の目的のために使用される一時的なURIは、構成されています。 <プロキシ>、<プロキシが>ネクストホッププロキシのFQDNまたは数値IPアドレスです：URIが、フォームの一口であること。その結果、全ての場合において、問題は、SIPの解像度にダウン沸騰またはリクエストが送信されるホストのIPアドレス、ポート、およびトランスポートを決定するために、DNSにURIをSIPS。
The procedures here MUST be done exactly once per transaction, where transaction is as defined in [1]. That is, once a SIP server has successfully been contacted (success is defined below), all retransmissions of the SIP request and the ACK for non-2xx SIP responses to INVITE MUST be sent to the same host. Furthermore, a CANCEL for a particular SIP request MUST be sent to the same SIP server that the SIP request was delivered to.
ここでの手順は、トランザクションが[1]で定義される通りであり、トランザクションごとに一度だけ行われなければなりません。 SIPサーバが正常に接触させた後、それは（成功は以下に定義される）、である、INVITEに対する非2xxのSIP応答のためのSIPリクエストとACKのすべての再送が同じホストに送らなければなりません。また、SIP要求はに配信された同じSIPサーバに送信する必要があり、特定のSIP要求をキャンセルします。
Because the ACK request for 2xx responses to INVITE constitutes a different transaction, there is no requirement that it be delivered to the same server that received the original request (indeed, if that server did not record-route, it will not get the ACK).
INVITEに対する2xxの応答のためのACK要求が異なるトランザクションを構成しているので、それが元のリクエスト受け付け同じサーバーに配信される必要はない（実際には、そのサーバがルートを記録していなかった場合、それはACKを取得することはできません） 。
We define TARGET as the value of the maddr parameter of the URI, if present, otherwise, the host value of the hostport component of the URI. It identifies the domain to be contacted. A description of the SIP and SIPS URIs and a definition of these parameters can be found in [1].
存在する場合、我々は、そうでなければ、URIのMADDRパラメータの値としてURIのホスト側コンポーネントのホスト値をTARGETを画定します。これは、接触するドメインを識別します。 SIPとSIPS URIの説明およびこれらのパラメータの定義は、[1]に見出すことができます。
We determine the transport protocol, port and IP address of a suitable instance of TARGET in Sections 4.1 and 4.2.
我々は、セクション4.1および4.2でTARGETの適切なインスタンスのトランスポート・プロトコル、ポートおよびIPアドレスを決定します。
First, the client selects a transport protocol.
まず、クライアントは、トランスポートプロトコルを選択します。
If the URI specifies a transport protocol in the transport parameter, that transport protocol SHOULD be used.
URIは、トランスポート・パラメータにトランスポートプロトコルを指定した場合、そのトランスポートプロトコルを使用する必要があります。
Otherwise, if no transport protocol is specified, but the TARGET is a numeric IP address, the client SHOULD use UDP for a SIP URI, and TCP for a SIPS URI. Similarly, if no transport protocol is specified, and the TARGET is not numeric, but an explicit port is provided, the client SHOULD use UDP for a SIP URI, and TCP for a SIPS URI. This is because UDP is the only mandatory transport in RFC 2543 [6], and thus the only one guaranteed to be interoperable for a SIP URI. It was also specified as the default transport in RFC 2543 when no transport was present in the SIP URI. However, another transport, such as TCP, MAY be used if the guidelines of SIP mandate it for this particular request. That is the case, for example, for requests that exceed the path MTU.
そうでない場合は、トランスポートプロトコルが指定されていないが、TARGETが数値のIPアドレスであるされている場合、クライアントは、SIP URIのためにUDPを使用し、SIPS URIのためのTCPべきです。何のトランスポートプロトコルが指定されていない、とTARGETが数値ではなく、明示的にポートが提供されている場合は同様に、クライアントは、SIPS URIのためのSIP URIのためのUDP、およびTCPを使用すべきです。 UDPは、RFC 2543にのみ必須の輸送[6]であるため、一方のみがSIP URIのための相互運用可能であることを保証するためです。何の輸送は、SIP URIに存在しなかったときにも、RFC 2543でデフォルトのトランスポートとして指定されました。しかし、TCPのような別の輸送は、この特定の要求のためのSIPの使命、それのガイドライン場合は使用されるかもしれません。すなわち、パスMTUを超えた要求に対して、例えば、場合です。
Otherwise, if no transport protocol or port is specified, and the target is not a numeric IP address, the client SHOULD perform a NAPTR query for the domain in the URI. The services relevant for the task of transport protocol selection are those with NAPTR service fields with values "SIP+D2X" and "SIPS+D2X", where X is a letter that corresponds to a transport protocol supported by the domain. This specification defines D2U for UDP, D2T for TCP, and D2S for SCTP. We also establish an IANA registry for NAPTR service name to transport protocol mappings.
何のトランスポートプロトコルやポートが指定されていない、との目標が数値のIPアドレスではありませんそれ以外の場合、クライアントは、URI内のドメインのためのNAPTRクエリを実行する必要があります。トランスポートプロトコルの選択のタスクに関連するサービスは、値「SIP + D2X」及びXは、ドメインによってサポートされるトランスポートプロトコルに対応する文字である「SIPS + D2X」とNAPTRサービスフィールドを持つものです。この仕様は、SCTPのためにUDP、TCPのためのD2T、およびD2SのためD2Uを定義します。我々はまた、トランスポートプロトコルへのマッピングNAPTRサービス名のIANAレジストリを確立します。
These NAPTR records provide a mapping from a domain to the SRV record for contacting a server with the specific transport protocol in the NAPTR services field. The resource record will contain an empty regular expression and a replacement value, which is the SRV record for that particular transport protocol. If the server supports multiple transport protocols, there will be multiple NAPTR records, each with a different service value. As per RFC 2915 [3], the client discards any records whose services fields are not applicable. For the purposes of this specification, several rules are defined.
これらのNAPTRレコードは、NAPTRサービスフィールドに特定のトランスポートプロトコルを使用してサーバに接触するためのSRVレコードのドメインからのマッピングを提供します。リソースレコードは、その特定のトランスポートプロトコルのためのSRVレコードである空の正規表現と置換値を含むであろう。サーバが複数のトランスポートプロトコルをサポートしている場合は、それぞれ異なるサービス値で、複数のNAPTRレコードが存在します。 RFC 2915 [3]に従って、クライアントは、そのサービスのフィールドが適用されないすべてのレコードを破棄します。本明細書の目的のために、いくつかのルールが定義されています。
First, a client resolving a SIPS URI MUST discard any services that do not contain "SIPS" as the protocol in the service field. The converse is not true, however. A client resolving a SIP URI SHOULD retain records with "SIPS" as the protocol, if the client supports TLS. Second, a client MUST discard any service fields that identify a resolution service whose value is not "D2X", for values of X that indicate transport protocols supported by the client. The NAPTR processing as described in RFC 2915 will result in the discovery of the most preferred transport protocol of the server that is supported by the client, as well as an SRV record for the server. It will also allow the client to discover if TLS is available and its preference for its usage.
まず、SIPS URIを解決するクライアントは、サービス分野におけるプロトコルとして「SIPS」を含まないすべてのサービスを捨てなければなりません。逆はしかし、真実ではありません。クライアントがTLSをサポートしている場合、SIP URIを解決するクライアントは、プロトコルとして「SIPS」のレコードを保持しなければなりません。第二に、クライアントは値クライアントでサポートされているトランスポートプロトコルを示すXの値については、「D2X」、ではない解決サービスを識別する任意のサービスフィールドを捨てなければなりません。 NAPTR処理RFC 2915に記載されているように、クライアントによってサポートされているサーバの最も好適なトランスポートプロトコル、ならびにサーバのSRVレコードの発見をもたらすであろう。また、TLSが利用可能であり、その使用のためにその優先場合、クライアントは発見することができます。
As an example, consider a client that wishes to resolve sip:user@example.com. The client performs a NAPTR query for that domain, and the following NAPTR records are returned:
user@example.com：例として、SIPを解決することを希望するクライアントを考えてみましょう。クライアントは、そのドメインのNAPTRクエリを実行し、以下のNAPTRレコードが返されます。
; order pref flags service regexp replacement IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.com. IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.com IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com.
;県旗にNAPTR 50 50「秒」「SIPS + D2T」「」_sips._tcp.example.comでサービス正規表現の置換を注文します。 NAPTR 90 50 "S" "SIP + D2T" "" NAPTR 100では_sip._tcp.example.com 50 "S" "SIP + D2U" "" _sip._udp.example.com。
This indicates that the server supports TLS over TCP, TCP, and UDP, in that order of preference. Since the client supports TCP and UDP, TCP will be used, targeted to a host determined by an SRV lookup of _sip._tcp.example.com. That lookup would return:
これは、サーバーが好みの順番で、TCP、TCP、およびUDP上でTLSをサポートしていることを示しています。クライアントは、TCPとUDPをサポートしているため、TCPは_sip._tcp.example.comのSRVルックアップによって決定されたホストをターゲットに、使用されます。そのルックアップが返されます：
;; Priority Weight Port Target IN SRV 0 1 5060 server1.example.com IN SRV 0 2 5060 server2.example.com
;; SRV 0 2 5060、IN SRV 0 1 5060 server1.example.com優先重ポートターゲットserver2.example.com
If a SIP proxy, redirect server, or registrar is to be contacted through the lookup of NAPTR records, there MUST be at least three records - one with a "SIP+D2T" service field, one with a "SIP+D2U" service field, and one with a "SIPS+D2T" service field. The records with SIPS as the protocol in the service field SHOULD be preferred (i.e., have a lower value of the order field) above records with SIP as the protocol in the service field. A record with a "SIPS+D2U" service field SHOULD NOT be placed into the DNS, since it is not possible to use TLS over UDP.
SIPプロキシは、サーバーにリダイレクト、またはレジストラは、少なくとも3つのレコードが存在しなければならず、NAPTRレコードの検索を介して連絡する場合 - 「SIP + D2T」サービスフィールドを持つ1、「SIP + D2U」サービスフィールドを持つ1 、および「SIPS + D2T」サービスフィールドを持つ1。サービスフィールドのプロトコルとしてSIPSを持つレコードは、サービスフィールドのプロトコルとしてSIPを持つレコードの上方（すなわち、順序フィールドの低い値を有する）が好ましいことべきです。 UDP上でTLSを使用することはできませんので、「SIPS + D2U」サービスフィールドを持つレコードは、DNSに収納しないでください。
It is not necessary for the domain suffixes in the NAPTR replacement field to match the domain of the original query (i.e., example.com above). However, for backwards compatibility with RFC 2543, a domain MUST maintain SRV records for the domain of the original query, even if the NAPTR record is in a different domain. As an example, even though the SRV record for TCP is _sip._tcp.school.edu, there MUST also be an SRV record at _sip._tcp.example.com.
NAPTR置換フィールドのドメインサフィックスは、元のクエリのドメインと一致する必要はない（すなわち、example.com上記）。しかし、RFC 2543との下位互換性のために、ドメインは、NAPTRレコードが異なるドメインにある場合でも、元のクエリーのドメインについてSRVレコードを維持しなければなりません。例として、TCP用SRVレコードが_sip._tcp.school.eduをされていても、また_sip._tcp.example.comでSRVレコードがあるに違いありません。
RFC 2543 will look up the SRV records for the domain directly. If these do not exist because the NAPTR replacement points to a different domain, the client will fail.
RFC 2543は、直接ドメインのSRVレコードを検索します。これらは別のドメインにNAPTR交換ポイントので、存在しない場合、クライアントは失敗します。
For NAPTR records with SIPS protocol fields, (if the server is using a site certificate), the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior or the result of an attack.
両方のサイトの証明書に基づいて有効でなければならない置換フィールドで、クエリ内のドメイン名とドメイン名（サーバーがサイト証明書を使用している場合）、SIPSプロトコルフィールドを持つNAPTRレコードの場合、TLSにおけるサーバによって配ら交換。同様に、SRVレコードでのターゲットでSRVクエリとドメイン名のドメイン名は、どちらも同じサイトの証明書に基づいて有効でなければなりません。そうしないと、攻撃者は、別のドメインの置換値を含むようにDNSレコードを変更することができ、クライアントは、これが目的の動作や攻撃の結果であったことを確認できませんでした。
If no NAPTR records are found, the client constructs SRV queries for those transport protocols it supports, and does a query for each. Queries are done using the service identifier "_sip" for SIP URIs and "_sips" for SIPS URIs. A particular transport is supported if the query is successful. The client MAY use any transport protocol it desires which is supported by the server.
何のNAPTRレコードが見つからない場合、クライアントはそれをサポートし、これらのトランスポートプロトコルのためのSRVクエリーを構築し、それぞれのクエリを行います。クエリは、SIP URIとSIPS URIの「_sips」のためのサービス識別子「_sip」を使用して行われます。クエリが成功した場合、特定のトランスポートがサポートされています。クライアントは、サーバによってサポートされている、それが希望する任意のトランスポートプロトコルを使用してもよいです。
This is a change from RFC 2543. It specified that a client would lookup SRV records for all transports it supported, and merge the priority values across those records. Then, it would choose the most preferred record.
これはサポートされており、それらのレコードを越え優先順位の値をマージ輸送それは、クライアントはすべてのためにSRVレコードを検索することを指定されたRFC 2543からの変更点です。その後、それが最も好ましいレコードを選ぶだろう。
If no SRV records are found, the client SHOULD use TCP for a SIPS URI, and UDP for a SIP URI. However, another transport protocol, such as TCP, MAY be used if the guidelines of SIP mandate it for this particular request. That is the case, for example, for requests that exceed the path MTU.
何のSRVレコードが見つからない場合、クライアントは、SIP URIのためのSIPS URIのためのTCP、およびUDPを使用すべきです。しかし、TCPのような別のトランスポートプロトコルを使用することができる場合は、この特定の要求のためのSIPの使命、それのガイドライン。すなわち、パスMTUを超えた要求に対して、例えば、場合です。
Once the transport protocol has been determined, the next step is to determine the IP address and port.
トランスポートプロトコルが決定されたら、次のステップは、IPアドレスとポートを決定することです。
If TARGET is a numeric IP address, the client uses that address. If the URI also contains a port, it uses that port. If no port is specified, it uses the default port for the particular transport protocol.
TARGETが数値のIPアドレスである場合、クライアントはそのアドレスを使用しています。 URIはまた、ポートが含まれている場合は、そのポートを使用しています。ポートが指定されていない場合は、特定のトランスポートプロトコルのデフォルトポートを使用しています。
If the TARGET was not a numeric IP address, but a port is present in the URI, the client performs an A or AAAA record lookup of the domain name. The result will be a list of IP addresses, each of which can be contacted at the specific port from the URI and transport protocol determined previously. The client SHOULD try the first record. If an attempt should fail, based on the definition of failure in Section 4.3, the next SHOULD be tried, and if that should fail, the next SHOULD be tried, and so on.
TARGETが数値のIPアドレスはありませんでしたが、ポートがURIに存在する場合、クライアントは、ドメイン名のAまたはAAAAレコードのルックアップを実行します。結果は、URIから特定のポートで接触し、トランスポートプロトコルは、以前に決定され得るそれらの各々は、IPアドレスのリストであろう。クライアントは、最初のレコードを試してみてください。試みが失敗した場合、4.3節では、障害の定義に基づいて、次の試行すべきである、それが失敗した場合、次のように試みたが、すべきである（SHOULD）。
This is a change from RFC 2543. Previously, if the port was explicit, but with a value of 5060, SRV records were used. Now, A or AAAA records will be used.
これは、ポートが明示した場合、以前はRFC 2543からの変更ですが、5060の値で、SRVレコードが使用されました。さて、AまたはAAAAレコードが使用されます。
If the TARGET was not a numeric IP address, and no port was present in the URI, the client performs an SRV query on the record returned from the NAPTR processing of Section 4.1, if such processing was performed. If it was not, because a transport was specified explicitly, the client performs an SRV query for that specific transport, using the service identifier "_sips" for SIPS URIs. For a SIP URI, if the client wishes to use TLS, it also uses the service identifier "_sips" for that specific transport, otherwise, it uses "_sip". If the NAPTR processing was not done because no NAPTR records were found, but an SRV query for a supported transport protocol was successful, those SRV records are selected. Irregardless of how the SRV records were determined, the procedures of RFC 2782, as described in the section titled "Usage rules" are followed, augmented by the additional procedures of Section 4.3 of this document.
TARGETが数値のIPアドレスではなかった、と何のポートがURIに存在しなかった場合、クライアントは、このような処理が実行された場合、レコードのSRVクエリは、セクション4.1のNAPTR処理から返された実行します。トランスポートが明示的に指定されたため、それは、なかった場合、クライアントは、SIPS URIのサービス識別子「_sips」を使用して、その具体的な輸送のためのSRVクエリを実行します。 SIP URIの場合、クライアントはTLSを使用したい場合、それはまた、それ以外の場合は「_sip」を使用し、その具体的な輸送のためのサービス識別子「_sips」を使用しています。 NAPTR処理は一切NAPTRレコードが見つからなかったため行われますが、サポートされるトランスポートプロトコルのためのSRVクエリが成功したされなかった場合は、それらのSRVレコードが選択されています。 「使用規則」は、続いて、この文書のセクション4.3の追加の手順によって増強されるというタイトルのセクションで説明したようにSRVレコードは、RFC 2782の手順を決定した方法に関わらず。
If no SRV records were found, the client performs an A or AAAA record lookup of the domain name. The result will be a list of IP addresses, each of which can be contacted using the transport protocol determined previously, at the default port for that transport. Processing then proceeds as described above for an explicit port once the A or AAAA records have been looked up.
何のSRVレコードが見つからなかった場合、クライアントは、ドメイン名のAまたはAAAAレコードのルックアップを実行します。結果は、そのトランスポートのデフォルトポートで、以前に決定されたトランスポートプロトコルを使用して接触させることができるそれぞれのIPアドレスのリストになります。 AまたはAAAAレコードが見上げてきた後に、明示的なポートについて上述したように処理は次に進みます。
RFC 2782 spells out the details of how a set of SRV records are sorted and then tried. However, it only states that the client should "try to connect to the (protocol, address, service)" without giving any details on what happens in the event of failure. Those details are described here for SIP.
RFC 2782は、SRVレコードのセットをソートし、次に試される方法の詳細を綴ります。しかし、それだけで、クライアントは、障害が発生した場合に何が起こるか上の任意の詳細を与えることなく「（プロトコル、アドレス、サービス）に接続しよう」すべきであると述べています。これらの詳細については、SIPのためにここで説明されています。
For SIP requests, failure occurs if the transaction layer reports a 503 error response or a transport failure of some sort (generally, due to fatal ICMP errors in UDP or connection failures in TCP). Failure also occurs if the transaction layer times out without ever having received any response, provisional or final (i.e., timer B or timer F in RFC 3261 [1] fires). If a failure occurs, the client SHOULD create a new request, which is identical to the previous, but has a different value of the Via branch ID than the previous (and therefore constitutes a new SIP transaction). That request is sent to the next element in the list as specified by RFC 2782.
トランザクション層は、（原因TCPでUDPまたは接続障害で致命的なICMPエラーのために、一般）503エラー応答やある種の輸送に障害を報告した場合、SIP要求の場合、障害が発生しました。なしでトランザクションレイヤ時間が今まで（RFC 3261 [1]発射で、すなわち、タイマBまたはタイマーF）の応答、仮または最終を受信した場合、障害が発生します。障害が発生した場合、クライアントは以前と同じですが、以前よりも経由の分岐IDの値が異なる（したがって、新しいSIPトランザクションを構成する）新しい要求を、作成する必要があります。その要求は、RFC 2782で指定されたリスト内の次の要素に送信されます。
The process of the previous sections is highly stateful. When a server is contacted successfully, all retransmissions of the request for the transaction, as well as ACK for a non-2xx final response, and CANCEL requests for that transaction, MUST go to the same server.
前節のプロセスは非常にステートフルです。サーバーが正常に接触させると、そのトランザクションのすべての非2xxの最終応答のトランザクションの要求だけでなく、ACKの再送信、およびCANCELリクエストは、同じサーバーに移動する必要があります。
The identity of the successfully contacted server is a form of transaction state. This presents a challenge for stateless proxies, which still need to meet the requirement for sending all requests in the transaction to the same server.
うまくコンタクトサーバーの身元は、トランザクション状態の一形態です。これはまだ、同じサーバにトランザクション内のすべての要求を送信するための要件を満たす必要があるステートレスプロキシ、のための課題を提示しています。
The problem is similar, but different, to the problem of HTTP transactions within a cookie session getting routed to different servers based on DNS randomization. There, such distribution is not a problem. Farms of servers generally have common back-end data stores, where the session data is stored. Whenever a server in the farm receives an HTTP request, it takes the session identifier, if present, and extracts the needed state to process the request. A request without a session identifier creates a new one. The problem with stateless proxies is at a lower layer; it is retransmitted requests within a transaction that are being potentially spread across servers. Since none of these retransmissions carries a "session identifier" (a complete dialog identifier in SIP terms), a new dialog would be created identically at each server. This could, for example result in multiple phone calls to be made to the same phone. Therefore, it is critical to prevent such a thing from happening in the first place.
問題は、DNSのランダム化に基づいて、別のサーバーにルーティングされたばかりのクッキーセッション内のHTTPトランザクションの問題に、似ているが、異なっています。このような分布は問題がありません。サーバの農場は、一般セッションデータが保存されている一般的なバックエンドのデータストアを、持っています。ファーム内のサーバがHTTP要求を受信するたびに、それが存在する場合、セッション識別子を受け取り、要求を処理するために必要な状態を抽出します。セッション識別子のない要求は、新しいものを作成します。ステートレスプロキシの問題点は、下層にあります。それは潜在的にサーバに分散されているトランザクション内の再転送要求です。これらの再送信のいずれも、「セッション識別子」（SIP用語で、完全なダイアログ識別子）を運ばないので、新しいダイアログは、各サーバーで同じように作成されます。これは、例えば同じ電話に行われるために、複数の電話につながる可能性があります。したがって、最初の場所で起こってからそのようなことを防ぐことが重要です。
The requirement is not difficult to meet in the simple case where there were no failures when attempting to contact a server. Whenever the stateless proxy receives the request, it performs the appropriate DNS queries as described above. However, the procedures of RFC 2782 are not guaranteed to be deterministic. This is because records that contain the same priority have no specified order. The stateless proxy MUST define a deterministic order to the records in that case, using any algorithm at its disposal. One suggestion is to alphabetize them, or, more generally, sort them by ASCII-compatible encoding. To make processing easier for stateless proxies, it is RECOMMENDED that domain administrators make the weights of SRV records with equal priority different (for example, using weights of 1000 and 1001 if two servers are equivalent, rather than assigning both a weight of 1000), and similarly for NAPTR records. If the first server is contacted successfully, the proxy can remain stateless. However, if the first server is not contacted successfully, and a subsequent server is, the proxy cannot remain stateless for this transaction. If it were stateless, a retransmission could very well go to a different server if the failed one recovers between retransmissions. As such, whenever a proxy does not successfully contact the first server, it SHOULD act as a stateful proxy.
要件は、サーバーに連絡しようとしたときに何の障害がなかった単純なケースで満たすことは困難ではありません。ステートレスプロキシは、要求を受信するたびに上記のように、それは適切なDNSクエリを実行します。しかし、RFC 2782の手順は決定論的であることが保証されていません。同じ優先順位を含むレコードが何も指定された順序を持っていないためです。ステートレスプロキシは、その処分で任意のアルゴリズムを使用して、その場合には、レコードに決定論的順序を定義しなければなりません。 1つの提案は、それらをアルファベット順に、または、より一般的には、ASCII互換エンコーディングによってそれらを並べ替えることです。ステートレスプロキシのために容易に処理するために、ドメイン管理者は、異なる（例えば、2台のサーバが同等であれば1000及び1001の重みを使用してではなく、1000の重量の両方を割り当てる）同じ優先度でSRVレコードの重みを作ることが推奨され、同様にNAPTRレコードの。最初のサーバーが正常に接触させた場合、プロキシはステートレスままにすることができます。最初のサーバが正常に接触しない、そしてその後のサーバがある場合は、プロキシは、このトランザクションのステートレス残ることはできません。それはステートレスであれば失敗した1が再送信の間で回復した場合、再送信は非常によく別のサーバーに行くことができます。そのため、プロキシが正常に最初のサーバーに接触していない時はいつでも、それはステートフルプロキシとして行動しなければなりません。
Unfortunately, it is still possible for a stateless proxy to deliver retransmissions to different servers, even if it follows the recommendations above. This can happen if the DNS TTLs expire in the middle of a transaction, and the entries had changed. This is unavoidable. Network implementors should be aware of this limitation, and not use stateless proxies that access DNS if this error is deemed critical.
ステートレスプロキシは、それが上記の推奨事項に従っていても、別のサーバーへの再送信を提供するために残念ながら、それはまだ可能です。 DNSのTTLのは、トランザクションの途中で有効期限が切れる場合に発生する可能性があり、かつエントリが変更されていました。これは避けられません。ネットワークの実装者は、この制限を認識して、このエラーが重大であると考えられる場合は、DNSにアクセスするステートレスプロキシを使用しないでください。
5 Server Usage
5サーバーの使用法
RFC 3261 [1] defines procedures for sending responses from a server back to the client. Typically, for unicast UDP requests, the response is sent back to the source IP address where the request came from, using the port contained in the Via header. For reliable transport protocols, the response is sent over the connection the request arrived on. However, it is important to provide failover support when the client element fails between sending the request and receiving the response.
RFC 3261 [1]バックサーバからクライアントへの応答を送信するための手順を定義します。典型的には、ユニキャストUDP要求に対して、応答は、Viaヘッダに含まれるポートを使用して、バック要求が来た送信元IPアドレスに送信されます。信頼性のあるトランスポートプロトコルでは、応答は、要求が到着した接続を介して送信されます。しかし、クライアントの要素が要求を送信し、応答を受信する間に失敗したときにフェイルオーバー・サポートを提供することが重要です。
A server, according to RFC 3261 [1], will send a response on the connection it arrived on (in the case of reliable transport protocols), and for unreliable transport protocols, to the source address of the request, and the port in the Via header field. The procedures here are invoked when a server attempts to send to that location and that response fails (the specific conditions are detailed in RFC 3261). "Fails" is defined as any closure of the transport connection the request came in on before the response can be sent, or communication of a fatal error from the transport layer.
サーバは、RFC 3261によれば、[1]、それは（信頼性のあるトランスポートプロトコルの場合）、および信頼性の低いトランスポートプロトコルのために、リクエストの送信元アドレスと、ポートへ到着した接続に応答を送信しますViaヘッダーフィールド。サーバがその場所に送信しようとし、その応答が（特定の条件は、RFC 3261に詳述されている）が失敗した場合、ここでの手順が呼び出されます。要求が応答を送信、またはトランスポート層からの致命的なエラーを通信することができる前に入ってきたトランスポート接続の任意の閉鎖として定義される「失敗します」。
In these cases, the server examines the value of the sent-by construction in the topmost Via header. If it contains a numeric IP address, the server attempts to send the response to that address, using the transport protocol from the Via header, and the port from sent-by, if present, else the default for that transport protocol. The transport protocol in the Via header can indicate "TLS", which refers to TLS over TCP. When this value is present, the server MUST use TLS over TCP to send the response.
これらのケースでは、サーバは、送信されたバイ建設最上位Viaヘッダー内の値を調べます。それは数字のIPアドレスが含まれている場合、サーバはViaヘッダーからトランスポートプロトコル、およびそのトランスポートプロトコルのために送られた-によって、存在する場合、他のデフォルトのポートを使用して、そのアドレスへの応答を送信しようとします。 Viaヘッダ内のトランスポートプロトコルは、TCP上のTLSを指す「TLS」を示すことができます。この値が存在する場合、サーバが応答を送信するためにTCP上のTLSを使用しなければなりません。
If, however, the sent-by field contained a domain name and a port number, the server queries for A or AAAA records with that name. It tries to send the response to each element on the resulting list of IP addresses, using the port from the Via, and the transport protocol from the Via (again, a value of TLS refers to TLS over TCP). As in the client processing, the next entry in the list is tried if the one before it results in a failure.
しかし、送信されたバイフィールドは、ドメイン名とポート番号は、その名前のAまたはAAAAレコードのサーバーのクエリが含まれていた場合。これは、ビアからポートを使用して、IPアドレスの得られたリストの各要素に応答を送信しようとし、およびVIAからトランスポート・プロトコルが（再び、TLSの値は、TCP上のTLSを指します）。それが失敗につながる前に、クライアントの処理と同様に、リスト内の次のエントリがあれば1を試しています。
If, however, the sent-by field contained a domain name and no port, the server queries for SRV records at that domain name using the service identifier "_sips" if the Via transport is "TLS", "_sip" otherwise, and the transport from the topmost Via header ("TLS" implies that the transport protocol in the SRV query is TCP). The resulting list is sorted as described in [2], and the response is sent to the topmost element on the new list described there. If that results in a failure, the next entry on the list is tried.
しかし、送信されたバイフィールドにドメイン名なしポートが含まれていた場合、サービスの識別子を使用して、そのドメイン名でのSRVレコードのサーバへの問い合わせは、経由輸送は、そうでない場合は、「TLS」、「_sip」であれば「_sips」、および一番上のViaヘッダから輸送（「TLS」はSRVクエリでトランスポートプロトコルがTCPであることを意味します）。 [2]に記載のように得られたリストがソートされ、応答がそこに記載新しいリストの最上位要素に送信されます。それが失敗につながる場合は、リストの次のエントリが試されます。
6 Constructing SIP URIs
6 SIP URIを構築
In many cases, an element needs to construct a SIP URI for inclusion in a Contact header in a REGISTER, or in a Record-Route header in an INVITE. According to RFC 3261 [1], these URIs have to have the property that they resolve to the specific element that inserted them. However, if they are constructed with just an IP address, for example:
多くの場合、要素は、レジスタのContactヘッダに、またはINVITEにRecord-Routeヘッダに含めるためのSIP URIを構築する必要があります。 RFC 3261 [1]によれば、これらのURIは、彼らがそれらを挿入し、特定の要素に解決性質を持っている必要があります。しかし、それらは例えば、単にIPアドレスで構成されている場合：
sip:1.2.3.4
SIP：1.2.3.4
then should the element fail, there is no way to route the request or response through a backup.
その要素が故障した場合に、バックアップを通るルート要求または応答をする方法はありません。
SRV provides a way to fix this. Instead of using an IP address, a domain name that resolves to an SRV record can be used:
SRVは、この問題を解決する方法を提供します。代わりにIPアドレスを使用しての、SRVレコードに解決ドメイン名を使用することができます。
sip:server23.provider.com
SIP：server23.provider.com
The SRV records for a particular target can be set up so that there is a single record with a low value for the priority field (indicating the preferred choice), and this record points to the specific element that constructed the URI. However, there are additional records with higher values of the priority field that point to backup elements that would be used in the event of failure. This allows the constraint of RFC 3261 [1] to be met while allowing for robust operation.
URIを構築し、特定の要素に優先フィールドの低い値を持つ単一のレコード（好ましい選択を示す）、このレコードポイントが存在するように、特定の標的のためのSRVレコードを設定することができます。しかし、障害発生時に使用されるバックアップの要素を指して優先順位フィールドのより高い値を持つ追加のレコードがあります。これは、堅牢な操作を可能にしながら、RFC 3261の制約[1]満たされることを可能にします。
7 Security Considerations
7つのセキュリティの考慮事項
DNS NAPTR records are used to allow a client to discover that the server supports TLS. An attacker could potentially modify these records, resulting in a client using a non-secure transport when TLS is in fact available and preferred.
DNS NAPTRレコードは、クライアントは、サーバがTLSをサポートしていることを発見できるようにするために使用されています。攻撃者はTLSが実際に利用可能であり、好ましいとき非セキュアトランスポートを使用しているクライアントで、その結果、これらのレコードを変更することができます。
This is partially mitigated by the presence of the sips URI scheme, which is always sent only over TLS. An attacker cannot force a bid down through deletion or modification of DNS records. In the worst case, they can prevent communication from occurring by deleting all records. A sips URI itself is generally exchanged within a secure context, frequently on a business card or secure web page, or within a SIP message which has already been secured with TLS. See RFC 3261 [1] for details. The sips URI is therefore preferred when security is truly needed, but we allow TLS to be used for requests resolved by a SIP URI to allow security that is better than no TLS at all.
これは、部分的に常にのみTLS経由で送信されるSIPS URIスキームの存在によって軽減されます。攻撃者は、DNSレコードの削除や改変により入札を下に強制することはできません。最悪の場合、彼らはすべてのレコードを削除することによって発生からの通信を防ぐことができます。 SIPS URI自体は一般的に頻繁に名刺やセキュアなWebページ、または既にTLSで保護されたSIPメッセージ内に、安全なコンテキスト内で交換されます。詳細については、RFC 3261 [1]を参照してください。セキュリティが真に必要な場合にSIPS URIは、そのため好ましいが、私たちは、TLSがまったくTLSよりも優れているセキュリティを許可するようにSIP URIによって解決要求に使用することができます。
The bid down attack can also be mitigated through caching. A client which frequently contacts the same domain SHOULD cache whether or not its NAPTR records contain SIPS in the services field. If such records were present, but in later queries cease to appear, it is a sign of a potential attack. In this case, the client SHOULD generate some kind of alert or alarm, and MAY reject the request.
攻撃ダウン入札はまた、キャッシングによって軽減することができます。同じドメインがそのNAPTRレコードはサービス分野にSIPSを含んでいるかどうかをキャッシュすべき頻繁に連絡先のクライアント。そのようなレコードが存在していたが、後のクエリに表示されるのをやめる場合は、それが潜在的な攻撃のサインです。この場合、クライアントは、アラートまたはアラームのいくつかの種類を生成する必要がありますし、要求を拒否することがあります。
An additional problem is that proxies, which are intermediaries between the users of the system, are frequently the clients that perform the NAPTR queries. It is therefore possible for a proxy to ignore SIPS entries even though they are present, resulting in downgraded security. There is very little that can be done to prevent such attacks. Clients are simply dependent on proxy servers for call completion, and must trust that they implement the protocol properly in order for security to be provided. Falsifying DNS records can be done by tampering with wire traffic (in the absence of DNSSEC), whereas compromising and commandeering a proxy server requires a break-in, and is seen as the considerably less likely downgrade threat.
追加の問題は、システムのユーザ間で仲介しているプロキシが、頻繁にNAPTRクエリを実行するクライアントであるということです。プロキシが格下げセキュリティが得られ、それらが存在するにもかかわらず、SIPSのエントリーを無視することがことが可能です。このような攻撃を防ぐためにできることはほとんどありません。クライアントは、コールの完了をプロキシサーバに単純に依存している、と彼らは提供されるセキュリティのために適切にプロトコルを実装することを信頼しなければなりません。偽造DNSレコードは妥協すると、プロキシサーバーをcommandeeringのに対し、ブレークインが必要ですし、かなり少ない格下げの脅威として見られている、（DNSSECの不存在下で）ワイヤートラフィックを改ざんすることによって行うことができます。
8 The Transport Determination Application
8トランスポート決意アプリケーション
This section more formally defines the NAPTR usage of this specification, using the Dynamic Delegation Discovery System (DDDS) framework as a guide [7]. DDDS represents the evolution of the NAPTR resource record. DDDS defines applications, which can make use of the NAPTR record for specific resolution services. This application is called the Transport Determination Application, and its goal is to map an incoming SIP or SIPS URI to a set of SRV records for the various servers that can handle the URI.
このセクションでは、より正式ガイド[7]のようにダイナミックな委譲発見システム（DDDS）フレームワークを使用して、本明細書のNAPTRの使用を定義します。 DDDSは、NAPTRリソースレコードの進化を表しています。 DDDSは、特定の解決サービスのためのNAPTRレコードを利用することができるアプリケーションを定義します。このアプリケーションは、トランスポート決意アプリケーションと呼ばれ、その目標は、URIを処理できる各種サーバーのSRVレコードのセットに入ってくるSIPまたはSIPS URIをマップすることです。
The following is the information that DDDS requests an application to provide:
次DDDSが提供するアプリケーションを要求した情報は次のとおりです。
Application Unique String: The Application Unique String (AUS) is the input to the resolution service. For this application, it is the URI to resolve.
アプリケーション固有の文字列：アプリケーション固有の文字列（AUS）は解決サービスに入力されます。このアプリケーションでは、解決するURIです。
First Well Known Rule: The first well known rule extracts a key from the AUS. For this application, the first well known rule extracts the host portion of the SIP or SIPS URI.
まずよく知られているルール：最初のよく知られたルールは、AUSからキーを抽出します。この用途のために、最初の周知の規則は、SIPのホスト部分を抽出またはURIをSIPS。
Valid Databases: The key resulting from the first well known rule is looked up in a single database, the DNS [8].
有効データベース：最初の周知の規則に起因するキーは、単一のデータベース内で検索され、DNS [8]。
Expected Output: The result of the application is an SRV record for the server to contact.
予想される出力：アプリケーションの結果を連絡するサーバーのSRVレコードです。
9 IANA Considerations
9つのIANAの考慮事項
The usage of NAPTR records described here requires well known values for the service fields for each transport supported by SIP. The table of mappings from service field values to transport protocols is to be maintained by IANA. New entries in the table MAY be added through the publication of standards track RFCs, as described in RFC 2434 [5].
ここで説明したNAPTRレコードの使用は、SIPでサポートされている各輸送のためのサービス分野のためのよく知られた値が必要です。プロトコルを輸送するサービスフィールド値からマッピングテーブルはIANAによって維持されるべきです。 RFC 2434に記載されているように、テーブルに新しいエントリが[5]、標準トラックRFCの出版を通じて追加されるかもしれません。
The registration in the RFC MUST include the following information:
RFCでの登録は、以下の情報を含める必要があります。
Service Field: The service field being registered. An example for a new fictitious transport protocol called NCTP might be "SIP+D2N".
サービスフィールド：サービスフィールドが登録されています。 NCTPと呼ばれる新しい架空のトランスポートプロトコルのための例は、「SIP + D2N」かもしれません。
Protocol: The specific transport protocol associated with that service field. This MUST include the name and acronym for the protocol, along with reference to a document that describes the transport protocol. For example - "New Connectionless Transport Protocol (NCTP), RFC 5766".
プロトコル：そのサービスの分野に関連する特定のトランスポートプロトコル。これは、トランスポート・プロトコルを記述した文書を参照するとともに、プロトコルの名前および頭字語を含まなければなりません。例えば - "新しいコネクションレス・トランスポート・プロトコル（NCTP）、RFC 5766"。
Name and Contact Information: The name, address, email address and telephone number for the person performing the registration.
名前と連絡先情報：登録を行う人の名前、住所、電子メールアドレスと電話番号。
The following values have been placed into the registry:
次の値がレジストリに配置されています：
Services Field Protocol SIP+D2T TCP SIPS+D2T TCP SIP+D2U UDP SIP+D2S SCTP (RFC 2960)
サービス分野プロトコルSIP + D2T TCP SIPS + D2T TCP SIP + D2U UDP SIP + D2S SCTP（RFC 2960）
10 Acknowledgements
10の謝辞
The authors would like to thank Randy Bush, Leslie Daigle, Patrik Faltstrom, Jo Hornsby, Rohan Mahy, Allison Mankin, Michael Mealling, Thomas Narten, and Jon Peterson for their useful comments.
作者は彼らの役に立つコメントをランディブッシュ、レスリーDaigle氏、パトリックFaltstrom、ジョー・ホーンズビー、ロハンマーイ、アリソンマンキン、マイケル・メオーリング、トーマスNarten氏、およびジョンピーターソンに感謝したいと思います。
11 Normative References
11の引用規格
[1] 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.
[1]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[2] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for Specifying the Location of Services (DNS SRV)", RFC 2782, February 2000.
[2] Gulbrandsenの、A.、いるVixie、P.及びL. Esibov、 "（DNSのSRV）サービスの場所を特定するためのDNS RR"、RFC 2782、2000年2月。
[3] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000.
[3] Mealling、M.およびR.ダニエル、 "命名権限ポインタ（NAPTR）DNSリソースレコード"、RFC 2915、2000年9月。
[4] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
12 Informative References
12件の参考文献
[6] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[6]ハンドレー、M.、Schulzrinneと、H.、学生はE.およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 2543、1999年3月。
[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS Standard", Work in Progress.
[7] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第一部：総合DDDS標準"、ProgressのWork。
[8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database", Work in Progress.
[8] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート3：DNSデータベース" が進行中で働いています。
13 Authors' Addresses
13本の著者のアドレス
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
72イーグルロックアベニューまず階イーストハノーバー、NJ 07936 dynamicsoftジョナサン・ローゼンバーグ
EMail: jdrosen@dynamicsoft.com
メールアドレス：jdrosen@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
ヘニングSchulzrinneとコロンビア大学のM / S 0401 1214アムステルダムアベニュー。ニューヨーク、NY 10027-7003
EMail: schulzrinne@cs.columbia.edu
メールアドレス：schulzrinne@cs.columbia.edu
14 Full Copyright Statement
14完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。