[要約] RFC 6950は、DNSにおけるアプリケーション機能のアーキテクチャ上の考慮事項についての要約です。このRFCの目的は、DNSにおけるアプリケーション機能の設計と実装に関するガイドラインを提供することです。
Internet Architecture Board (IAB) J. Peterson
Request for Comments: 6950 NeuStar, Inc.
Category: Informational O. Kolkman
ISSN: 2070-1721 NLnet Labs
H. Tschofenig
Nokia Siemens Networks
B. Aboba
Skype
October 2013
Architectural Considerations on Application Features in the DNS
DNSのアプリケーション機能に関するアーキテクチャ上の考慮事項
Abstract
概要
A number of Internet applications rely on the Domain Name System (DNS) to support their operations. Many applications use the DNS to locate services for a domain; some, for example, transform identifiers other than domain names into formats that the DNS can process, and then fetch application data or service location data from the DNS. Proposals incorporating sophisticated application behavior using DNS as a substrate have raised questions about the role of the DNS as an application platform. This document explores the architectural consequences of using the DNS to implement certain application features, and it provides guidance to future application designers as to the limitations of the DNS as a substrate and the situations in which alternative designs should be considered.
多くのインターネットアプリケーションは、ドメインネームシステム（DNS）に依存してそれらの操作をサポートしています。多くのアプリケーションはDNSを使用してドメインのサービスを見つけます。たとえば、ドメイン名以外の識別子をDNSが処理できる形式に変換してから、DNSからアプリケーションデータまたはサービスロケーションデータをフェッチします。 DNSを基質として使用する高度なアプリケーション動作を組み込んだ提案は、アプリケーションプラットフォームとしてのDNSの役割について疑問を投げかけています。このドキュメントは、特定のアプリケーション機能を実装するためにDNSを使用することのアーキテクチャ上の結果を探り、基板としてのDNSの制限と代替設計を検討する必要がある状況について、将来のアプリケーション設計者にガイダンスを提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6950.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6950で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Motivation ......................................................2
2. Overview of DNS Application Usages ..............................4
2.1. Locating Services in a Domain ..............................5
2.2. NAPTR and DDDS .............................................6
2.3. Arbitrary Data in the DNS ..................................8
3. Challenges for the DNS .........................................10
3.1. Compound Queries ..........................................10
3.1.1. Responses Tailored to the Originator ...............12
3.2. Using DNS as a Generic Database ...........................14
3.2.1. Large Data in the DNS ..............................14
3.3. Administrative Structures Misaligned with the DNS .........16
3.3.1. Metadata about Tree Structure ......................18
3.4. Domain Redirection ........................................20
4. Private DNS and Split Horizon ..................................21
5. Principles and Guidance ........................................23
6. Security Considerations ........................................25
7. IAB Members at the Time of Approval ............................26
8. Acknowledgements ...............................................26
9. Informative References .........................................27
The Domain Name System (DNS) has long provided a general means of translating domain names into Internet Protocol addresses, which makes the Internet easier to use by providing a valuable layer of indirection between names and lower-layer protocol elements. [RFC0974] documented a further use of the DNS: to locate an application service operating in a domain, via the Mail Exchange (MX) Resource Record; these records help email addressed to the domain to find a mail service for the domain sanctioned by the zone administrator.
ドメインネームシステム（DNS）は、長い間、ドメイン名をインターネットプロトコルアドレスに変換する一般的な手段を提供してきました。これにより、名前と下位層のプロトコル要素との間の間接的な貴重な層が提供され、インターネットが使いやすくなります。 [RFC0974]は、DNSのさらなる使用を文書化しました。ドメイン内で動作しているアプリケーションサービスを見つけるために、Mail Exchange（MX）リソースレコードを介して。これらのレコードは、ドメイン宛の電子メールがゾーン管理者によって認可されたドメインのメールサービスを見つけるのに役立ちます。
The seminal MX record served as a prototype for other DNS resource records that supported applications associated with a domain name. The SRV Resource Record [RFC2052] provided a more general mechanism for locating services in a domain, complete with a weighting system and selection among transports. The Naming Authority Pointer (NAPTR) Resource Record (originally described in [RFC2168]), especially as it evolved into the more general Dynamic Delegation Discovery System (DDDS) [RFC3401] framework, added a generic mechanism for storing application data in the DNS. Primarily, this involved a client-side algorithm for transforming a string into a domain name, which might then be resolved by the DNS to find NAPTR records. This enabled the resolution of identifiers that do not have traditional host components through the DNS; the best-known examples of this are telephone numbers, as resolved by the DDDS application ENUM. Recent work, such as DomainKeys Identified Mail (DKIM) [RFC6376], has enabled security features of applications to be advertised through the DNS, via the TXT Resource Record.
精巧なMXレコードは、ドメイン名に関連付けられたアプリケーションをサポートする他のDNSリソースレコードのプロトタイプとして機能しました。 SRVリソースレコード[RFC2052]は、ドメイン内のサービスを検索するためのより一般的なメカニズムを提供し、重み付けシステムとトランスポート間の選択を備えています。 Naming Authority Pointer（NAPTR）リソースレコード（元は[RFC2168]で説明）は、特により一般的な動的委任発見システム（DDDS）[RFC3401]フレームワークに発展したため、DNSにアプリケーションデータを格納するための一般的なメカニズムを追加しました。これには主に、文字列をドメイン名に変換するクライアント側のアルゴリズムが含まれ、DNSによって解決されてNAPTRレコードが検索される場合があります。これにより、従来のホストコンポーネントを持たない識別子をDNSで解決できるようになりました。この最もよく知られた例は、DDDSアプリケーションENUMによって解決される電話番号です。 DomainKeys Identified Mail（DKIM）[RFC6376]などの最近の作業により、アプリケーションのセキュリティ機能を、TXTリソースレコードを介してDNS経由でアドバタイズできるようになりました。
The scope of application usage of the DNS has thus increased over time. Applications in many environments require features such as confidentiality, and as the contexts in which applications rely on the DNS have increased, some application protocols have looked to extend the DNS to include these sorts of capabilities. However, some proposed usages of, and extensions to, the DNS have become misaligned with both the DNS architecture and the DNS protocol. If we take the example of confidentiality, we see that in the global public DNS, the resolution of domain names to IP addresses is an exchange of public information with no expectation of confidentiality. Thus, the underlying query/response protocol has no encryption mechanism; typically, any security required by an application or service is invoked after the DNS query, when the resolved service has been contacted. Only in private DNS environments (including split-horizon DNS) where the identity of the querier is assured through some external policy can the DNS maintain confidential records, by providing distinct answers to the private and public users of the DNS. In support of load-balancing or other optimizations, a DNS server may return different addresses in response to queries from different sources, or even no response at all; see Section 3.1.1 for details.
したがって、DNSのアプリケーション使用の範囲は、時間の経過とともに拡大しています。多くの環境のアプリケーションは機密性などの機能を必要とし、アプリケーションがDNSに依存するコンテキストが増加するにつれて、一部のアプリケーションプロトコルはDNSを拡張してこれらの種類の機能を含めるようにしています。ただし、DNSの提案された使用法および拡張機能の一部は、DNSアーキテクチャとDNSプロトコルの両方と整合していません。機密性を例にとると、グローバルなパブリックDNSでは、ドメイン名のIPアドレスへの解決は、機密性を期待せずに公開情報を交換することです。したがって、基になるクエリ/応答プロトコルには暗号化メカニズムがありません。通常、アプリケーションまたはサービスに必要なセキュリティは、解決されたサービスにアクセスしたときに、DNSクエリの後に呼び出されます。 DNSのプライベートユーザーとパブリックユーザーに明確な回答を提供することにより、DNSは、外部ポリシーを通じてクエリアのIDが保証されるプライベートDNS環境（スプリットホライズンDNSを含む）でのみ機密レコードを維持できます。負荷分散やその他の最適化をサポートするために、DNSサーバーは、さまざまなソースからのクエリに応答してさまざまなアドレスを返すか、まったく応答しないこともあります。詳細については、セクション3.1.1を参照してください。
This document provides guidance to application designers and application protocol designers looking to use the DNS to support features in their applications. It provides an overview of past application usage of the DNS as well as a review of proposed new usages. It identifies concerns and trade-offs and provides guidance on the question, "Should I store this information in the DNS, or use some other means?" when that question arises during protocol development. These guidelines remind application protocol designers of the strengths and weaknesses of the DNS in order to make it easier for designers to decide what features the DNS should provide for their application.
このドキュメントは、DNSを使用してアプリケーションの機能をサポートすることを検討しているアプリケーション設計者およびアプリケーションプロトコル設計者にガイダンスを提供します。 DNSの過去のアプリケーションの使用法の概要と、提案された新しい使用法のレビューを提供します。懸念事項とトレードオフを識別し、「この情報をDNSに保存する必要があるか、それとも他の手段を使用する必要があるか」という質問に対するガイダンスを提供します。プロトコルの開発中にその問題が発生した場合。これらのガイドラインは、アプリケーションプロトコルの設計者にDNSの長所と短所を思い出させ、設計者がDNSがアプリケーションに提供する機能を簡単に決定できるようにします。
The guidance in this document complements the guidance on extending the DNS given in [RFC5507]. Whereas [RFC5507] considers the preferred ways to add new information to the underlying syntax of the DNS (such as defining new resource records or adding prefixes or suffixes to labels), the current document considers broader implications of applications that rely on the DNS for the implementation of certain features, be it through extending the DNS or simply reusing existing protocol capabilities -- implications that may concern the invocation of the resolver by applications; the behavior of name servers, resolvers, or caches; extensions to the underlying DNS protocol; the operational responsibilities of zone administrators; security; or the overall architecture of names. When existing DNS protocol fields are used in ways that their designers did not intend to handle new applications, those applications may demand further changes and extensions that are fundamentally at odds with the strengths of the DNS.
このドキュメントのガイダンスは、[RFC5507]で提供されているDNSの拡張に関するガイダンスを補足します。 [RFC5507]は、DNSの基礎となる構文に新しい情報を追加する好ましい方法（新しいリソースレコードの定義やラベルへの接頭辞または接尾辞の追加など）を検討しているのに対し、現在のドキュメントでは、DNSに依存するアプリケーションの広範な影響を考慮しています。 DNSの拡張によるものであれ、既存のプロトコル機能の再利用によるものであれ、特定の機能の実装-アプリケーションによるリゾルバーの呼び出しに関係する可能性のある影響。ネームサーバー、リゾルバー、またはキャッシュの動作。基礎となるDNSプロトコルの拡張。ゾーン管理者の運用責任。セキュリティ;または名前の全体的なアーキテクチャ。既存のDNSプロトコルフィールドが、設計者が新しいアプリケーションを処理するつもりでなかった方法で使用された場合、それらのアプリケーションは、DNSの長所と根本的に矛盾するさらなる変更と拡張を要求する場合があります。
[RFC0882] identifies the original and fundamental connection between the DNS and applications. It begins by describing how the interdomain scope of applications creates "formidable problems when we wish to create consistent methods for referencing particular resources that are similar but scattered throughout the environment". This motivated transitioning the "mapping between host names... and ARPA Internet addresses" from a global table (the original "hosts" file) to a "distributed database that performs the same function". [RFC0882] also envisioned some ways to find the resources associated with mailboxes in a domain: without these extensions, a user trying to send mail to a foreign domain lacked a discovery mechanism to locate the right host in the remote domain to which to connect.
[RFC0882]は、DNSとアプリケーション間の元の基本的な接続を識別します。最初に、アプリケーションのドメイン間スコープが「類似しているが環境全体に散在する特定のリソースを参照するための一貫したメソッドを作成したい場合に、明白な問題」がどのように作成されるかを説明します。これにより、「ホスト名とARPAインターネットアドレス間のマッピング」がグローバルテーブル（元の「hosts」ファイル）から「同じ機能を実行する分散データベース」に移行しました。 [RFC0882]は、ドメイン内のメールボックスに関連付けられたリソースを見つける方法もいくつか想定していました。これらの拡張機能がないと、外部ドメインにメールを送信しようとするユーザーは、接続先のリモートドメインで適切なホストを見つけるための検出メカニズムがありませんでした。
While a special-purpose service discovery mechanism could be built for each such application protocol that needed this functionality, the universal support for the DNS encourages installing these features into its public tree rather than inventing something new. Thus, over time, several other applications leveraged DNS resource records for locating services in a domain or for storing application data associated with a domain in the DNS. This section gives examples of various types of DNS usage by applications to date.
この機能を必要とするアプリケーションプロトコルごとに専用のサービスディスカバリメカニズムを構築できますが、DNSのユニバーサルサポートにより、新しい機能を開発するのではなく、これらの機能をパブリックツリーにインストールすることが推奨されます。したがって、時間の経過とともに、他のいくつかのアプリケーションはDNSリソースレコードを利用して、ドメイン内のサービスを検索したり、ドメインに関連付けられたアプリケーションデータをDNSに格納したりしました。このセクションでは、これまでのアプリケーションによるさまざまなタイプのDNSの使用例を示します。
The MX Resource Record provides the simplest example of an application advertising its domain-level resources in the Domain Name System. The MX Resource Record contains the domain name of a server that receives mail on behalf of the administrative domain in question; that domain name must itself be resolved to one or more IP addresses through the DNS in order to reach the mail server. While naming conventions for applications might serve a similar purpose (a host might be named "mail.example.com", for example), approaching service location through the creation of a new resource record yields important benefits. For example, one can put multiple MX records under the same name, in order to designate backup resources or to load-balance across several such servers (see [RFC1794]); these properties could not easily be captured by naming conventions (see [RFC4367], though more recently DNS-based Service Discovery (DNS-SD) [RFC6763] codifies service instance naming conventions for use across applications to locate services in a domain).
MXリソースレコードは、ドメインネームシステムでドメインレベルのリソースをアドバタイズするアプリケーションの最も簡単な例を提供します。 MXリソースレコードには、問題の管理ドメインに代わってメールを受信するサーバーのドメイン名が含まれています。メールサーバーに到達するには、そのドメイン名自体がDNSを通じて1つ以上のIPアドレスに解決される必要があります。アプリケーションの命名規則は同様の目的（ホストの名前は「mail.example.com」など）に役立つ場合がありますが、新しいリソースレコードの作成を通じてサービスの場所にアクセスすることには重要な利点があります。たとえば、バックアップリソースを指定したり、複数のサーバー間で負荷を分散したりするために、複数のMXレコードを同じ名前で置くことができます（[RFC1794]を参照）。これらのプロパティは、命名規則では簡単にキャプチャできませんでした（[RFC4367]を参照してください。最近では、DNSベースのサービスディスカバリー（DNS-SD）[RFC6763]が、アプリケーション全体でドメイン内のサービスを検索するために使用するサービスインスタンスの命名規則を体系化しています）。
While the MX record represents a substantial improvement over naming conventions as a means of service location, it remains specific to a single application. Thus, the general approach of the MX record was adapted to fit a broader class of applications through the Service (SRV) Resource Record (originally described in [RFC2052]). The SRV record allows DNS resolvers to query for particular services and underlying transports (for example, HTTP running over Transport Layer Security (TLS) [RFC2818]) and to learn a host name and port where that service resides in a given domain. It also provides a weighting mechanism to allow load-balancing across several instances of a service.
MXレコードは、サービスの場所の手段としての命名規則を大幅に改善していますが、単一のアプリケーションに固有のものです。したがって、MXレコードの一般的なアプローチは、サービス（SRV）リソースレコード（元々は[RFC2052]で説明されていました）を通じて、より広範なクラスのアプリケーションに適合するように適合されました。 SRVレコードを使用すると、DNSリゾルバーは特定のサービスと基になるトランスポート（たとえば、トランスポート層セキュリティ（TLS）[RFC2818]を介して実行されるHTTP）を照会し、そのサービスが特定のドメインに存在するホスト名とポートを知ることができます。また、サービスの複数のインスタンス間で負荷分散を可能にする重み付けメカニズムも提供します。
The reliance of applications on the existence of MX and SRV records has important implications for the way that applications manage identifiers and the way that applications pass domain names to resolvers. Email identifiers of the form "user@domain" rely on MX records to provide the convenience of simply specifying a "domain" component rather than requiring an application to guess which particular host handles mail on behalf of the domain. While naming conventions continue to abound ("www.example.com") for applications like web browsing, SRV records allow applications to query for an application-specific protocol and transport in the domain. For the Lightweight Directory Access Protocol (LDAP), the SRV service name corresponds to the URL scheme of the identifier invoked by the application (e.g., when "ldap://example.com" is the identifier, the SRV query passed to the resolver is for "_ldap._tcp.example.com"); for other applications, the SRV service name that the application passes to the resolver may be implicit in the identifier rather than explicit. In either case, the application delivers the service name to the DNS to find the location of the host of that service for the domain, the port where the service resides on that host, additional locations or ports for load-balancing and fault tolerance, and related application features.
アプリケーションがMXレコードとSRVレコードの存在に依存していることは、アプリケーションが識別子を管理する方法と、アプリケーションがドメイン名をリゾルバーに渡す方法に重要な影響を及ぼします。 「user @ domain」形式のメール識別子はMXレコードに依存しており、アプリケーションがドメインに代わってメールを処理する特定のホストを推測するのではなく、「ドメイン」コンポーネントを指定するだけの利便性を提供します。命名規則は引き続きWebブラウジングなどのアプリケーションに対応しますが（ "www.example.com"）、SRVレコードにより、アプリケーションはドメイン内のアプリケーション固有のプロトコルとトランスポートを照会できます。ライトウェイトディレクトリアクセスプロトコル（LDAP）の場合、SRVサービス名はアプリケーションによって呼び出された識別子のURLスキームに対応します（たとえば、「ldap：//example.com」が識別子の場合、SRVクエリはリゾルバーに渡されます） 「_ldap._tcp.example.com」用です）;他のアプリケーションの場合、アプリケーションがリゾルバーに渡すSRVサービス名は、明示的ではなく暗黙的に識別子に含まれる場合があります。どちらの場合も、アプリケーションはDNSにサービス名を配信して、ドメインのそのサービスのホストの場所、サービスがそのホストに存在するポート、ロードバランシングとフォールトトレランスのための追加の場所またはポート、および関連するアプリケーション機能。
Locating specific services for a domain was the first major function for which applications started using the DNS beyond simple name resolution. SRV broadened and generalized the precedent of MX to make service location available to any application, rather than just to mail. As applications that acquire MX (or SRV) records might need to perform further queries or transformations in order to arrive at an eventual domain name that will resolve to the IP addresses for the service, [RFC1034] allowed that the Additional (data) section of DNS responses may contain the corresponding address records for the names of services designated by the MX record; this optimization, which requires support in the authoritative server and the resolver, is an initial example of how support for application features requires changes to DNS operation. At the same time, this is an example of an extension of the DNS that cannot be universally relied on: many DNS resolver implementations will ignore the addresses in the additional section of the DNS answers because of the trustworthiness issues described in [RFC2181].
ドメインの特定のサービスを見つけることは、アプリケーションが単純な名前解決を超えてDNSの使用を開始した最初の主要な機能でした。 SRVは、MXの前例を広げて一般化し、サービスロケーションをメールだけでなく、あらゆるアプリケーションで利用できるようにしました。 MX（またはSRV）レコードを取得するアプリケーションは、サービスのIPアドレスに解決される最終的なドメイン名に到達するために、さらにクエリまたは変換を実行する必要がある可能性があるため、[RFC1034]では、 DNS応答には、MXレコードで指定されたサービスの名前に対応するアドレスレコードが含まれる場合があります。権限のあるサーバーとリゾルバーでのサポートが必要なこの最適化は、アプリケーション機能のサポートでDNS操作の変更が必要になる方法の最初の例です。同時に、これは普遍的に信頼できないDNSの拡張機能の例です。多くのDNSリゾルバー実装は、[RFC2181]で説明されている信頼性の問題のため、DNS回答の追加セクションのアドレスを無視します。
The NAPTR Resource Record evolved to fulfill a need in the transition from Uniform Resource Locators (URLs) to the more mature Uniform Resource Identifier (URI) [RFC3986] framework, which incorporated Uniform Resource Names (URNs). Unlike URLs, URNs typically do not convey enough semantics internally to resolve them through the DNS, and consequently a separate URI-transformation mechanism is required to convert these types of URIs into domain names. This allows identifiers with no recognizable domain component to be treated as domain names for the purpose of name resolution. Once these transformations result in a domain name, applications can retrieve NAPTR records under that name in the DNS. NAPTR records contain a far more rich and complex structure than MX or SRV Resource Records. A NAPTR record contains two different weighting mechanisms ("order" and "preference"), a "service" field to designate the application that the NAPTR record describes, and then two fields that can contain translations: a "replacement" field or a "regexp" (regular expression) field, only one of which appears in a given NAPTR record (see [RFC2168]). A "replacement", like NAPTR's ancestor the PTR record, simply designates another domain name where one would look for records associated with this service in the domain. The
NAPTRリソースレコードは、Uniform Resource Locators（URL）から、Uniform Resource Names（URN）を組み込んだより成熟したUniform Resource Identifier（URI）[RFC3986]フレームワークへの移行のニーズを満たすために進化しました。 URLとは異なり、URNは通常、DNSを通じてURLを解決するのに十分なセマンティクスを内部で伝達しないため、これらのタイプのURIをドメイン名に変換するには、別のURI変換メカニズムが必要です。これにより、認識可能なドメインコンポーネントを持たない識別子を名前解決の目的でドメイン名として扱うことができます。これらの変換によってドメイン名が生成されると、アプリケーションはDNSでその名前のNAPTRレコードを取得できます。 NAPTRレコードには、MXまたはSRVリソースレコードよりもはるかに豊富で複雑な構造が含まれています。 NAPTRレコードには、2つの異なる重み付けメカニズム（「順序」と「設定」）、NAPTRレコードが記述するアプリケーションを指定する「サービス」フィールド、および翻訳を含むことができる2つのフィールドが含まれます：「置換」フィールドまたは「 regexp "（正規表現）フィールド。その1つだけが特定のNAPTRレコードに表示されます（[RFC2168]を参照）。 NAPTRの祖先であるPTRレコードのような「置換」は、ドメイン内でこのサービスに関連付けられているレコードを探す別のドメイン名を指定するだけです。の
"regexp", on the other hand, allows regular expression transformations on the original URI intended to turn it into an identifier that the DNS can resolve.
一方、「regexp」は、DNSが解決できる識別子に変換することを目的とした、元のURIでの正規表現変換を許可します。
As the abstract of [RFC2915] says, "This allows the DNS to be used to lookup services for a wide variety of resource names (including URIs) which are not in domain name syntax". Any sort of hierarchical identifier can potentially be encoded as a domain name, and thus historically the DNS has often been used to resolve identifiers that were never devised as a name for an Internet host. A prominent early example is found in the in-addr domain [RFC0883], in which IPv4 addresses are encoded as domain names by applying a string preparation algorithm that required reversing the octets and treating each individual octet as a label in a domain name -- thus, for example, the address 192.0.2.1 became 1.2.0.192.in-addr.arpa. This allowed resolvers to query the DNS to learn name(s) associated with an IPv4 address. The same mechanism has been applied to IPv6 addresses [RFC3596] and other sorts of identifiers that lack a domain component. Eventually, this idea connected with activities to create a system for resolving telephone numbers on the Internet, which became known as ENUM (originally described in [RFC2916]). ENUM borrowed from an earlier proposal, the "tpc.int" domain [RFC1530], which provided a means for encoding telephone numbers as domain names by applying a string preparation algorithm that required reversing the digits and treating each individual digit as a label in a domain name -- thus, for example, the number +15714345400 became 0.0.4.5.4.3.4.1.7.5.1.tpc.int. In the ENUM system, in place of "tpc.int" the special domain "e164.arpa" was reserved for use.
[RFC2915]の要約にあるように、「これにより、DNSを使用して、ドメイン名構文にないさまざまなリソース名（URIを含む）のサービスを検索できます」。あらゆる種類の階層識別子はドメイン名としてエンコードされる可能性があるため、これまでDNSは、インターネットホストの名前として考案されなかった識別子を解決するためによく使用されてきました。初期の著名な例はin-addrドメイン[RFC0883]にあります。IPv4アドレスは、オクテットを逆にし、各オクテットをドメイン名のラベルとして扱う必要のある文字列準備アルゴリズムを適用することにより、ドメイン名としてエンコードされます-したがって、たとえば、アドレス192.0.2.1は1.2.0.192.in-addr.arpaになります。これにより、リゾルバーはDNSに照会して、IPv4アドレスに関連付けられた名前を学習できました。同じメカニズムがIPv6アドレス[RFC3596]およびドメインコンポーネントを欠く他の種類の識別子に適用されました。最終的に、このアイデアはENUMとして知られるようになったインターネット上の電話番号を解決するためのシステムを作成するための活動と結びつきました（元々は[RFC2916]で説明されていました）。 ENUMは以前の提案である「tpc.int」ドメイン[RFC1530]を借用しました。これは、数字を逆にする必要がある文字列準備アルゴリズムを適用し、個々の数字をラベルとして扱うことにより、電話番号をドメイン名としてエンコードする手段を提供しました。ドメイン名-したがって、たとえば、番号+15714345400は0.0.4.5.4.3.4.1.7.5.1.tpc.intになります。 ENUMシステムでは、「tpc.int」の代わりに、特別なドメイン「e164.arpa」が使用のために予約されていました。
In the more mature form of the NAPTR standard, in the Dynamic Delegation Discovery System (DDDS) [RFC3401] framework, the initial transformation of an identifier (such as a telephone number) to a domain name was called the "First Well Known Rule". The address-reversing mechanism, whereby a query name is formed by reversing an IPv4 address and prepending it to the in-addr.arpa domain, is generalized for the use of NAPTR: each application defines a "First Well Known Rule" that translates a specific resource into a query name. Its flexibility has inspired a number of proposals beyond ENUM to encode and resolve unorthodox identifiers in the DNS. Provided that the identifiers transformed by the "First Well Known Rule" have some meaningful structure and are not overly lengthy, virtually anything can serve as an input for the DDDS structure: for example, civic addresses. Though [RFC3402] stipulates regarding the identifier that "The lexical structure of this string must imply a unique delegation path", there is no requirement that the identifier be hierarchical nor that the points of delegation in the domain name created by the "First Well Known Rule" correspond to any points of administrative delegation inherent in the structure of the identifier.
NAPTR標準のより成熟した形式では、Dynamic Delegation Discovery System（DDDS）[RFC3401]フレームワークで、識別子（電話番号など）からドメイン名への最初の変換は「First Well Knownルール」と呼ばれていました。 IPv4アドレスを逆にしてin-addr.arpaドメインの前に付けることでクエリ名が形成されるアドレス逆転メカニズムは、NAPTRを使用するために一般化されています。各アプリケーションは、「最初の既知のルール」を定義してクエリ名に特定のリソース。その柔軟性は、DNSの非正統的な識別子をエンコードして解決するためのENUM以外の多くの提案に影響を与えています。 「First Well Knownルール」によって変換された識別子が意味のある構造を持ち、過度に長くはない場合、事実上、DDDS構造の入力として機能できるものはすべて、たとえば、市民の住所です。 [RFC3402]は、「この文字列の字句構造は一意の委任パスを意味する必要がある」という識別子について規定していますが、識別子が階層的である必要も、「First Well Knownによって作成されたドメイン名の委任ポイントがルール」は、識別子の構造に固有の管理委任の任意のポイントに対応します。
While this ability to look up names "which are not in domain name syntax" does not change the underlying DNS protocol -- the names generated by the DDDS algorithm are still just domain names -- it does change the context in which applications pass name to resolvers and can potentially require very different operational practices of zone administrators (see Section 3.3). In terms of the results of a DNS query, the presence of the "regexp" field of NAPTR records enabled unprecedented flexibility in the types of identifiers that applications could resolve with the DNS. Since the output of the regular expression frequently took the form of a URI (in ENUM resolution, for example, a telephone number might be converted into a SIP URI [RFC3261]), anything that could be encoded as a URI might be the result of resolving a NAPTR record -- which, as the next section explores, essentially means arbitrary data.
「ドメイン名構文にない」名前を検索するこの機能は、基礎となるDNSプロトコルを変更しません-DDDSアルゴリズムによって生成された名前は、まだドメイン名です-アプリケーションが名前を渡すコンテキストを変更しますリゾルバであり、ゾーン管理者の非常に異なる運用方法が必要になる可能性があります（セクション3.3を参照）。 DNSクエリの結果に関しては、NAPTRレコードの「regexp」フィールドの存在により、アプリケーションがDNSで解決できる識別子のタイプに、これまでにない柔軟性がもたらされました。正規表現の出力は頻繁にURIの形式を取ったため（ENUM解決では、電話番号はSIP URI [RFC3261]に変換される場合があります）、URIとしてエンコードできるものはすべて、 NAPTRレコードの解決-次のセクションで説明するように、これは本質的に任意のデータを意味します。
URI encoding has ways of encapsulating basically arbitrary data: the most extreme example is a data URL [RFC2397]. Thus, the returned NAPTR record might be interpreted to produce output other than a domain name that would subsequently be resolved to IP addresses and contacted for a particular application -- it could give a literal result that would be consumed by the application. Originally, as discussed in [RFC2168], the intended applicability of the regular expression field in NAPTR was narrower: the "regexp" field contained a "substitution expression that is applied to the original URI in order to construct the next domain name to lookup", in order to "change the host that is contacted to resolve a URI" or as a way of "changing the path or host once the URL has been assigned". The regular expression tools available to NAPTR record authors, however, grant much broader powers to alter the input string, and thus applications began to rely on NAPTR to perform more radical transformations that did not serve any of those aforementioned needs. According to [RFC3402], the output of DDDS is wholly application-specific: "the Application must define what the expected output of the Terminal Rule should be", and the example given in the document is one of identifying automobile parts by inputting a part number and receiving at the end of the process information about the manufacturer.
URIエンコーディングには、基本的に任意のデータをカプセル化する方法があります。最も極端な例は、データURL [RFC2397]です。したがって、返されたNAPTRレコードは、ドメイン名以外の出力を生成するように解釈され、その後IPアドレスに解決され、特定のアプリケーションに接続されます。これにより、アプリケーションによって消費される文字どおりの結果が得られます。元々、[RFC2168]で説明されているように、NAPTRの正規表現フィールドの適用範囲は狭く、「regexp」フィールドには、「ルックアップする次のドメイン名を構築するために元のURIに適用される置換式」が含まれていました、「URIを解決するために接続するホストを変更する」ため、または「URLが割り当てられたらパスまたはホストを変更する」方法として。ただし、NAPTRレコードの作成者が使用できる正規表現ツールは、入力文字列を変更するためのはるかに広範な権限を付与するため、アプリケーションはNAPTRに依存して、前述のニーズのいずれも果たさない、より根本的な変換を実行し始めました。 [RFC3402]によると、DDDSの出力は完全にアプリケーション固有です。「アプリケーションは、ターミナルルールの予想される出力を定義する必要があります」。ドキュメントに記載されている例は、パーツを入力して自動車のパーツを識別するものです。製造元に関する情報をプロセスの最後に受け取ります。
Historically speaking, NAPTR did not pioneer the storage of arbitrary data in the DNS. At the start, [RFC0882] observed that "it is unlikely that all users of domain names will be able to agree on the set of resources or resource information that names will be used to retrieve", and consequently places little restriction on the information that DNS records might carry: it might be "host addresses, mailbox data, and other as yet undetermined information". [RFC1035] defined the TXT record, a means to store arbitrary strings in the DNS; [RFC1035] also specifically stipulates that a TXT contains "descriptive text" and that "the semantics of the text depends on the domain where it is found". The existence of TXT records has long provided new applications with a rapid way of storing data associated with a domain name in the DNS, as adding data in this fashion requires no registration process. [RFC1464] experimented with a means of incorporating name/value pairs to the TXT record structure, which allowed applications to distinguish different chunks of data stored in a TXT record -- surely not just "descriptive text" as the TXT originally specified. In this fashion, an application that wants to store additional data in the DNS can do so without registering a new resource record type, though [RFC5507] points out that it is "difficult to reliably distinguish one application's record from others, and for its parser to avoid problems when it encounters other TXT records".
歴史的に言えば、NAPTRはDNSに任意のデータを格納する先駆者ではありませんでした。 [RFC0882]は最初に、「ドメイン名のすべてのユーザーが、名前の取得に使用される一連のリソースまたはリソース情報に同意できる可能性は低い」と観察し、その結果、 DNSレコードは、「ホストアドレス、メールボックスデータ、およびその他のまだ不明な情報」である可能性があります。 [RFC1035]は、DNSに任意の文字列を格納する手段であるTXTレコードを定義しました。 [RFC1035]は、TXTに「説明テキスト」が含まれ、「テキストのセマンティクスは、それが見つかるドメインに依存する」ことも明確に規定しています。 TXTレコードの存在は、ドメイン名に関連付けられたデータをDNSに迅速に格納する方法を新しいアプリケーションに提供してきました。この方法でデータを追加することは、登録プロセスを必要としないからです。 [RFC1464]名前/値のペアをTXTレコード構造に組み込む方法を実験しました。これにより、アプリケーションはTXTレコードに格納されたさまざまなデータチャンクを区別できます。確かに、TXTが最初に指定した「説明テキスト」だけではありません。このようにして、追加のデータをDNSに格納したいアプリケーションは、新しいリソースレコードタイプを登録せずにそれを行うことができますが、[RFC5507]は、「1つのアプリケーションのレコードを他のアプリケーションのレコードから確実に区別すること、およびそのパーサーのために他のTXTレコードに遭遇したときの問題を避けるために」
While open policies surrounding the use of the TXT record have resulted in a checkered past for standardizing application usage of TXT, TXT has been used as a technical solution for many applications. Recently, DKIM [RFC6376] sidestepped the problem of TXT ambiguity by storing keys under a specialized DNS naming structure that includes the component "_domainkeys", which serves to restrict the scope of that TXT solely to DKIM use. Storing keys in the DNS became the preferred solution for DKIM for several reasons: notably, because email applications already queried the DNS in their ordinary operations, because the public keys associated with email required wide public distribution, and because email identifiers contain a domain component that applications can easily use to consult the DNS. If the application had to negotiate support for the DKIM mechanism with mail servers, it would give rise to bid-down attacks (where attackers misrepresent that DKIM is unsupported on the originating side) that are not possible if the DNS delivers the keys (provided that DNSSEC [RFC4033] guarantees authenticity of the data). However, there are potential issues with storing large data in the DNS, as discussed in Section 3.2.1, as well as with the DKIM namespace conventions that complicate the use of DNS wildcards (as discussed in Section 6.1.2 of [RFC6376] and in more general terms in [RFC5507]). If prefixes are used to identify TXT records used by an application, potentially the use of wildcards may furthermore cause leakages that other applications will need to detect.
TXTレコードの使用を取り巻くオープンポリシーにより、TXTのアプリケーション使用を標準化するための過去が確認されましたが、TXTは多くのアプリケーションの技術的ソリューションとして使用されています。最近、DKIM [RFC6376]は、TXTのスコープをDKIMの使用のみに制限する「_domainkeys」コンポーネントを含む特殊なDNS命名構造の下にキーを格納することにより、TXTのあいまいさの問題を回避しました。キーをDNSに保存することは、いくつかの理由でDKIMの推奨ソリューションになりました。特に、電子メールアプリケーションは通常の操作でDNSに既にクエリを送信したため、電子メールに関連付けられた公開キーは広範囲にわたる公開配布を必要としたため、電子メール識別子には次のドメインコンポーネントが含まれているためです。アプリケーションはDNSを参照するために簡単に使用できます。アプリケーションがメールサーバーとのDKIMメカニズムのサポートについてネゴシエートする必要がある場合、DNSがキーを提供する場合（ただし、 DNSSEC [RFC4033]は、データの信頼性を保証します）。ただし、セクション3.2.1で説明されているように、DNSに大きなデータを格納すること、およびDNSワイルドカードの使用を複雑にするDKIM名前空間の規則（[RFC6376]のセクション6.1.2で説明されているように）に潜在的な問題があります。 [RFC5507]のより一般的な用語で）。アプリケーションで使用されるTXTレコードを識別するために接頭辞が使用されている場合、ワイルドカードの使用により、他のアプリケーションが検出する必要のあるリークがさらに発生する可能性があります。
The methods discussed in the previous section for transforming arbitrary identifiers into domain names and returning arbitrary data in response to DNS queries both represent significant departures from the basic function of translating host names to IP addresses, yet neither fundamentally alters the underlying semantics of the DNS. When we consider, however, that the URIs returned by DDDS might be base-64-encoded binary data in a data URL, the DNS could effectively implement the entire application feature set of any simple query-response protocol. Effectively, the DDDS framework considers the DNS a generic database -- indeed, the DDDS framework was designed to work with any sort of underlying database; as [RFC3403] says, the DNS is only one potential database for DDDS to use. Whether the DNS as an underlying database can support the features that some applications of DDDS require, however, is a more complicated question.
前のセクションで説明した、任意の識別子をドメイン名に変換し、DNSクエリに応じて任意のデータを返す方法は、どちらもホスト名をIPアドレスに変換する基本機能から大きく逸脱していますが、DNSの基本的なセマンティクスを根本的に変更するものでもありません。ただし、DDDSによって返されるURIがデータURLのbase-64エンコードされたバイナリデータである可能性があることを考慮すると、DNSは、単純なクエリ応答プロトコルのアプリケーション機能セット全体を効果的に実装できます。実際、DDDSフレームワークはDNSを汎用データベースと見なします。実際、DDDSフレームワークは、あらゆる種類の基礎となるデータベースと連携するように設計されています。 [RFC3403]が言うように、DNSはDDDSが使用する潜在的なデータベースの1つにすぎません。ただし、基盤となるデータベースとしてのDNSが、DDDSの一部のアプリケーションに必要な機能をサポートできるかどうかは、より複雑な問題です。
As the following subsections will show, the potential for applications to rely on the DNS as a generic database gives rise to additional requirements that one might expect to find in a database access protocol: authentication of the source of queries for comparison to access control lists, formulating complex relational queries, and asking questions about the structure of the database itself. The global public DNS was not designed to provide these sorts of properties, and extending the DNS protocols to encompass them could result in a fundamental alteration to its model. Ultimately, this document concludes that efforts to retrofit these capabilities into the DNS would be better invested in selecting, or if necessary inventing, other Internet services with broader powers than the DNS. If an application protocol designer wants these properties from a database, in general this is a good indication that the DNS cannot, or can only partly, meet the needs of the application in question.
次のサブセクションが示すように、汎用データベースとしてDNSに依存するアプリケーションの可能性は、データベースアクセスプロトコルで見つかると思われる追加の要件を生じさせます：アクセス制御リストと比較するためのクエリのソースの認証、複雑なリレーショナルクエリを作成し、データベース自体の構造について質問します。グローバルパブリックDNSは、このような種類のプロパティを提供するようには設計されておらず、それらを包含するようにDNSプロトコルを拡張すると、モデルに根本的な変更が生じる可能性があります。最終的に、このドキュメントでは、これらの機能をDNSに組み込む取り組みは、DNSよりも幅広い能力を持つ他のインターネットサービスを選択するか、必要に応じて発明することに投資するほうがよいと結論付けています。アプリケーションプロトコルの設計者がデータベースからこれらのプロパティを必要とする場合、これは一般に、DNSが問題のアプリケーションのニーズを満たすことができない、または部分的にしか満たすことができないことを示す良い兆候です。
Since many of these new requirements have emerged from the ENUM space, the following sections use ENUM as an illustrative example; however, any application using the DNS as a feature-rich database could easily end up with similar requirements.
これらの新しい要件の多くはENUMスペースから出てきたため、以降のセクションではENUMを例として使用します。ただし、機能豊富なデータベースとしてDNSを使用するアプリケーションは、簡単に同様の要件に終わる可能性があります。
Traditionally, DNS RRsets are uniquely identified by domain name, resource record type, and class. DNS queries are based on this 3-tuple, and the replies are resource record sets that are to be treated as atomic data elements (see [RFC2181]); to applications, the behavior of the DNS has traditionally been that of an exact-match query-response lookup mechanism. Outside of the DNS space, however, there are plenty of query-response applications that require a compound or relational search, one taking into account more than one factor in formulating a response or one that uses no single factor as a key to the database. For example, in the telephony space, telephone call routing often takes into account numerous factors aside from the dialed number, including originating trunk groups, interexchange carrier selection, number portability data, time of day, and so on. All are considered simultaneously in generating a route. While in its original conception ENUM hoped to circumvent the traditional Public Switched Telephone Network (PSTN) and route directly to Internet-enabled devices, the infrastructure ENUM effort to support the migration of traditional carrier routing functions to the Internet aspires to achieve feature parity with traditional number routing. However, [RFC3402] explicitly states that "it is an assumption of the DDDS that the lexical element used to make a delegation decision is simple enough to be contained within the Application Unique String itself. The DDDS does not solve the case where a delegation decision is made using knowledge contained outside the AUS and the Rule (time of day, financial transactions, rights management, etc.)". Consequently, some consideration has been given to ways to append additional data to ENUM queries to give the DNS server sufficient information to return a suitable URI (see Section 3.1.1).
従来、DNS RRsetは、ドメイン名、リソースレコードタイプ、およびクラスによって一意に識別されていました。 DNSクエリはこの3タプルに基づいており、応答はアトミックデータ要素として扱われるリソースレコードセットです（[RFC2181]を参照）。アプリケーションにとって、DNSの動作は従来、完全一致クエリ応答ルックアップメカニズムの動作でした。ただし、DNSスペースの外には、複合検索またはリレーショナル検索を必要とするクエリ応答アプリケーションがたくさんあります。1つは、応答の定式化で複数の要素を考慮するか、データベースのキーとして単一の要素を使用しないものです。たとえば、テレフォニースペースでは、発信コールグループは、発信元のトランクグループ、交換機のキャリアの選択、番号のポータビリティデータ、時刻など、ダイヤルされた番号以外の多くの要因を考慮に入れることがよくあります。ルートの生成では、すべてが同時に考慮されます。 ENUMは当初の構想において、従来の公衆交換電話網（PSTN）を回避してインターネット対応デバイスに直接ルーティングすることを望んでいましたが、従来のキャリアルーティング機能のインターネットへの移行をサポートするインフラストラクチャENUMの取り組みは、従来と同等の機能を実現することを目指しています番号ルーティング。ただし、[RFC3402]は、「委任の決定に使用される字句要素は、アプリケーションの一意の文字列自体に含まれるほど単純であることがDDDSの前提であることを明示しています。DDDSは、委任の決定のケースを解決しません。 AUSおよび規則の外に含まれている知識（時刻、金融取引、権利管理など）を使用して作成されています。」その結果、適切なURIを返すのに十分な情報をDNSサーバーに提供するために、ENUMクエリに追加データを追加する方法が検討されました（セクション3.1.1を参照）。
From a sheer syntactical perspective, however, domain names do not admit of this sort of rich structure. Several workarounds have attempted to instantiate these sorts of features in DNS queries. For example, the domain name itself could be compounded with the additional parameters: one could take a name like 0.0.4.5.4.3.4.1.7.5.1.e164.arpa and append a trunk group identifier to it, for example, of the form tg011.0.0.4.5.4.3.4.1.7.5.1.e164.arpa. While in this particular case a DNS server can adhere to its traditional behavior in locating resource records, the syntactical viability of encoding additional parameters in this fashion is dubious, especially if more than one additional parameter is required and the presence of parameters is optional so that the application needs multiple queries to assess the completeness of the information it needs to perform its function.
しかし、純粋な構文の観点から見ると、ドメイン名はこの種の豊富な構造を認めていません。いくつかの回避策は、DNSクエリでこれらの種類の機能をインスタンス化しようとしました。たとえば、ドメイン名自体を追加のパラメーターと組み合わせることができます。たとえば、0.0.4.5.4.3.4.1.7.5.1.e164.arpaのような名前を取り、それにトランクグループ識別子を追加できます。フォームtg011.0.0.4.5.4.3.4.1.7.5.1.e164.arpa。この特定のケースでは、DNSサーバーはリソースレコードの検索における従来の動作に準拠できますが、特に複数の追加パラメーターが必要であり、パラメーターの存在がオプションであるため、この方法で追加パラメーターをエンコードする構文の実現可能性は疑わしいです。アプリケーションは、機能を実行するために必要な情報の完全性を評価するために、複数のクエリを必要とします。
As an alternative, it has been proposed that we piggyback additional query parameters as Extension Mechanisms for DNS (EDNS(0)) extensions (see [RFC6891]). This might be problematic for three reasons. First, supporting EDNS(0) extensions requires significant changes to name server behavior; these changes need to be supported by the authoritative and recursive name servers on which the application relies and might be very hard to realize on a global scale. In addition, the original stated applicability of the EDSN(0) mechanism, as [RFC2671] states, was to "a particular transport level message and not to any actual DNS data", and consequently the OPT Resource Records it specifies are never to be forwarded. The use of EDNS(0) for compound queries, however, clearly is intended to discriminate actual DNS data rather than to facilitate transport-layer handling. Finally, [RFC6891] also specifies that "OPT RRs MUST NOT be cached, forwarded, or stored" (see the next paragraph). For these reasons, this memo recommends against crafting compound DNS queries by using EDNS(0).
別の方法として、DNSの拡張メカニズム（EDNS（0））拡張として追加のクエリパラメータを便乗させることが提案されています（[RFC6891]を参照）。これは、3つの理由で問題になる可能性があります。まず、EDNS（0）拡張をサポートするには、ネームサーバーの動作に大幅な変更が必要です。これらの変更は、アプリケーションが依存する信頼できる再帰的なネームサーバーによってサポートされる必要があり、グローバルな規模での実現は非常に困難な場合があります。さらに、[RFC2671]が述べているように、EDSN（0）メカニズムの最初に述べられた適用可能性は「特定のトランスポートレベルメッセージであり、実際のDNSデータではない」であり、その結果、それが指定するOPTリソースレコードは決して転送されました。ただし、複合クエリにEDNS（0）を使用することは、トランスポート層の処理を容易にするのではなく、実際のDNSデータを区別することを目的としています。最後に、[RFC6891]は、「OPT RRをキャッシュ、転送、または保存してはならない」と規定しています（次の段落を参照）。これらの理由から、このメモはEDNS（0）を使用して複合DNSクエリを作成することを推奨しません。
The implications of these sorts of compound queries for recursion and caching are potentially serious. The logic used by the authoritative server to respond to a compound query may not be understood by any recursive servers or caches; intermediaries that naively assume that the response was selected based on the domain name, type, and class alone might serve responses to queries in a different way than the authoritative server intends. Therefore, were EDNS(0) to be employed this way, its attributes would not be transitive, and if this were not considered where intermediaries are employed, as is normally the case in the global DNS, brokenness might occur.
再帰およびキャッシングに対するこれらの種類の複合クエリの影響は、潜在的に深刻です。信頼できるサーバーが複合クエリに応答するために使用するロジックは、再帰的なサーバーやキャッシュでは理解されない場合があります。応答がドメイン名、タイプ、およびクラスのみに基づいて選択されたと単純に仮定する仲介者は、権限のあるサーバーが意図するものとは異なる方法でクエリへの応答を提供する可能性があります。したがって、この方法でEDNS（0）を使用すると、その属性は推移的ではなくなり、グローバルDNSで通常そうであるように、仲介者が使用される場所でこれが考慮されなかった場合、破損が発生する可能性があります。
DNS responses tailored to the identity of their originator, where some sort of administrative identity of the originator must be conveyed to the DNS, constitute the most important subcase of these compound queries. We must first distinguish this from cases where the originating IP address or a similar indication is used to serve a location-specific name. For those sorts of applications, which generally lack security implications, relying on factors like the source IP address introduces little harm; for example, when providing a web portal customized to the region of the client, it would not be a security breach if the client saw the localized portal of the wrong country. Because recursive resolvers may obscure the origination network of the DNS client, a recent proposal suggested introducing a new DNS query parameter to be populated by DNS recursive resolvers in order to preserve the originating IP address (see [EDNS-CLIENT-IP]). However, aside from purely cosmetic uses, these approaches have known limitations due to the prevalence of private IP addresses, VPNs, and so on, which obscure the source IP address and instead supply the IP address of an intermediary that may be very distant from the originating endpoint. Implementing technology such as the one described by [EDNS-CLIENT-IP] would require significant changes in the operation of recursive resolvers and the authoritative servers that would rely on the original source IP address to select resource records, and moreover a fundamental change to caching behavior as well. As a result, such technology cannot be rolled out in an incremental, unilateral fashion but could only be successful when implemented bilaterally (by authoritative server and recursive resolver); this is a significant bar to deployment.
発信者のIDに合わせて調整されたDNS応答（発信者の何らかの管理IDをDNSに伝達する必要がある）は、これらの複合クエリの最も重要なサブケースを構成します。まず、これを、発信元のIPアドレスまたは同様の指標を使用して、ロケーション固有の名前を提供する場合と区別する必要があります。一般にセキュリティへの影響を欠くこれらの種類のアプリケーションでは、送信元IPアドレスなどの要素に依存しても害はほとんどありません。たとえば、クライアントの地域に合わせてカスタマイズされたWebポータルを提供する場合、クライアントが間違った国のローカライズされたポータルを見たとしても、セキュリティ違反にはなりません。再帰リゾルバはDNSクライアントの元のネットワークを不明瞭にする可能性があるため、最近の提案では、元のIPアドレスを維持するために、DNS再帰リゾルバによって入力される新しいDNSクエリパラメータを導入することを提案しました（[EDNS-CLIENT-IP]を参照）。ただし、純粋に表面的な使用を除いて、これらのアプローチにはプライベートIPアドレス、VPNなどの普及により既知の制限があり、ソースIPアドレスを覆い隠し、代わりに仲介者のIPアドレスから非常に離れている可能性があります。元のエンドポイント。 [EDNS-CLIENT-IP]で説明されているようなテクノロジーを実装するには、リソースレコードを選択するために元のソースIPアドレスに依存する再帰リゾルバと権限のあるサーバーの操作に大幅な変更が必要であり、さらにキャッシングに根本的な変更が必要です。行動も。その結果、そのようなテクノロジは、段階的かつ一方的に展開することはできず、（信頼できるサーバーと再帰リゾルバによって）双方向で実装した場合にのみ成功する可能性があります。これは展開の重要な障害です。
In other deployments in use today, including those based on the BIND "views" feature, the source IP address is used to grant access to a selected, and potentially sensitive, set of resource records. The security implications of trusting the source IP address of a DNS query have prevented most solutions along these lines from being standardized (see [RFC6269]), though the practice remains widespread in "split horizon" private DNS deployments (see Section 4), which typically rely on an underlying security layer, such as a physical network, a clear perimeter demarcation at a network perimeter point (with network-layer anti-spoofing countermeasures), or an IPsec VPN, to prevent spoofing of the source IP address. These deployments do have a confidentiality requirement to prevent information intended for a constrained audience (internal to an enterprise, for example) from leaking to the public Internet -- while these internal network resources may use private IP addresses that should not be useful on the public Internet anyway, in some cases this leakage would reveal topology or other information that the name server administrator hopes to keep private. More recently, TSIG [RFC2845] has been employed as a way of selecting among "views" in BIND; this provides a stronger level of security than merely relying on the source IP address, but typically many users share the same secret to access a given view, and moreover TSIG does not provide confidentiality properties to DNS messages -- without network-layer separation between users of different views, eavesdroppers might capture the DNS queries and responses.
BINDの「ビュー」機能に基づくものを含め、現在使用されている他のデプロイメントでは、ソースIPアドレスを使用して、選択された、機密性の高いリソースレコードのセットへのアクセスを許可します。 DNSスプリットの送信元IPアドレスを信頼することによるセキュリティへの影響により、これらの行に沿ったほとんどのソリューションは標準化されませんでした（[RFC6269]を参照）。ただし、「スプリットホライズン」プライベートDNS展開（セクション4を参照）送信元IPアドレスのスプーフィングを防止するには、通常、物理ネットワーク、ネットワーク境界ポイントでの明確な境界境界（ネットワークレイヤーのスプーフィング対策を使用）、またはIPsec VPNなどの基盤となるセキュリティレイヤーに依存します。これらの展開には、制約された対象者（企業の内部など）を対象とした情報がパブリックインターネットに漏洩するのを防ぐための機密性要件があります-これらの内部ネットワークリソースは、パブリックには役に立たないはずのプライベートIPアドレスを使用する可能性がありますいずれにせよインターネットでは、場合によっては、この漏えいにより、ネームサーバー管理者が非公開にしたいと考えているトポロジやその他の情報が明らかになります。最近では、BIGの「ビュー」から選択する方法としてTSIG [RFC2845]が採用されています。これにより、単にソースIPアドレスに依存するよりも強力なセキュリティレベルが提供されますが、通常、多くのユーザーが同じシークレットを共有して特定のビューにアクセスします。さらに、TSIGはユーザー間でネットワーク層を分離せずに、DNSメッセージに機密性プロパティを提供しません。異なるビューの場合、盗聴者はDNSクエリと応答をキャプチャする可能性があります。
The use of source IP addresses as a discriminator to select DNS resource records, regardless of its lack of acceptance by the standards community, has widespread acceptance in the field. Some applications, however, go even further and propose extending the DNS to add an application-layer identifier of the originator; for example, [EDNS-OPT-CODE] provides a SIP URI in an EDNS(0) parameter. Effectively, this conveyance of application-layer information about the administrative identity of the originator through the DNS is a weak authentication mechanism, on the basis of which the DNS server makes an authorization decision before sharing resource records. This can approximate a confidentiality mechanism per resource record, where only a specific set of originators is permitted to see resource records, or a case where a query for the same name by different entities results in completely different resource record sets. However, without any underlying cryptographic security, this mechanism must rely on external layers for security (such as VPNs) rather than any direct assurance. Again, caching, forwarding, and recursion introduce significant challenges for applications that attempt to offload this responsibility to the DNS. Achieving feature parity with even the simplest authentication mechanisms available at the application layer would likely require significant rearchitecture of the DNS.
標準コミュニティによる受け入れの欠如に関係なく、DNSリソースレコードを選択するための弁別子としてのソースIPアドレスの使用は、フィールドで広く受け入れられています。ただし、さらに進んで、DNSを拡張して発信者のアプリケーション層識別子を追加することを提案するアプリケーションもあります。たとえば、[EDNS-OPT-CODE]は、EDNS（0）パラメータでSIP URIを提供します。事実上、DNSを介した発信者の管理IDに関するアプリケーション層情報のこの伝達は、DNSサーバーがリソースレコードを共有する前に承認決定を行うことに基づく、弱い認証メカニズムです。これにより、リソースレコードごとの機密性メカニズムを概算できます。この場合、特定の発信者のセットのみがリソースレコードの表示を許可されます。または、異なるエンティティによる同じ名前のクエリの結果、完全に異なるリソースレコードセットになる場合もあります。ただし、基盤となる暗号化セキュリティがない場合、このメカニズムは、直接の保証ではなく、セキュリティ（VPNなど）の外部レイヤーに依存する必要があります。この場合も、キャッシング、転送、および再帰は、この責任をDNSにオフロードしようとするアプリケーションに重大な課題をもたらします。アプリケーション層で利用できる最も単純な認証メカニズムでさえ機能の同等性を達成するには、DNSの大幅な再設計が必要になる可能性があります。
As previously noted, applications can use a method like the "First Well Known Rule" of DDDS to transform an arbitrary string into a domain name and then receive from the DNS arbitrary data stored in TXT RRs, in the "regexp" of NAPTRs, or even in custom records. Some query-response applications, however, require queries and responses that simply fall outside the syntactic capabilities of the DNS. For example, domain names themselves must consist of labels that do not exceed 63 octets, while the total length of the encoded name may not exceed 255 octets, and applications that use label characters outside the traditional ASCII set may run into problems (however, see the discussion in [RFC6055], Section 3 for definitive guidance on the use of non-ASCII in the DNS). The DNS therefore cannot be a completely generic database. Similar concerns apply to the size of DNS responses.
前述のように、アプリケーションはDDDSの「First Well Knownルール」のような方法を使用して、任意の文字列をドメイン名に変換し、NAPTRの「正規表現」でTXT RRに格納されている任意のデータをDNSから受信できます。カスタムレコードでも。ただし、一部のクエリ応答アプリケーションは、DNSの構文機能の範囲外にあるクエリと応答を必要とします。たとえば、ドメイン名自体は63オクテットを超えないラベルで構成する必要がありますが、エンコードされた名前の全長は255オクテットを超えてはならず、従来のASCIIセット以外のラベル文字を使用するアプリケーションでは問題が発生する可能性があります（ただし、 [RFC6055]、セクション3の議論、DNSでの非ASCIIの使用に関する明確なガイダンス）したがって、DNSを完全に汎用的なデータベースにすることはできません。同様の懸念がDNS応答のサイズにも当てはまります。
While the "data" URL specification [RFC2397] notes that it is "only useful for short values", unfortunately it gives no particular guidance about what "short" might mean. Some applications today use quite large data URLs (containing a megabyte or more of data) as workarounds in environments where only URIs can syntactically appear (for example, in Apple iOS, to pass objects between applications). The meaning of "short" in an application context is probably very different from how we should understand it in a DNS message. Referring to a typical public DNS deployment, [RFC5507] observes that "there's a strong incentive to keep DNS messages short enough to fit in a UDP datagram, preferably a UDP datagram short enough not to require IP fragmentation". And while EDNS(0) allows for mechanisms to negotiate DNS message sizes larger than the traditional 512 octets, there is a high risk that a long payload will cause UDP fragmentation, in particular when the DNS message already carries DNSSEC information. If EDNS(0) is not available, or the negotiated EDNS(0) packet size is too small to fit the data, or UDP fragments are dropped, the DNS may (eventually) resort to using TCP. While TCP allows DNS responses to be quite long, this requires stateful operation of servers, which can be costly in deployments where servers have only fleeting connections to many clients. Ultimately, there are forms of data that an application might store in the DNS that exceed reasonable limits: in the ENUM context, for example, something like storing base-64-encoded mp3 files of custom ringtones.
「データ」URL仕様[RFC2397]は、「短い値に対してのみ有用」であると述べていますが、残念ながら、「短い」が何を意味するかについて特定のガイダンスを提供していません。今日の一部のアプリケーションは、URIのみが構文的に表示できる環境（たとえば、Apple iOSでは、アプリケーション間でオブジェクトを渡すため）での回避策として、非常に大きなデータURL（メガバイト以上のデータを含む）を使用しています。アプリケーションコンテキストでの「短い」の意味は、DNSメッセージでそれを理解する方法とはかなり異なるでしょう。 [RFC5507]は、一般的なパブリックDNS配備について、「DNSメッセージをUDPデータグラムに収めるのに十分短く、できればIPフラグメンテーションを必要としないほど短くする強い動機がある」と述べています。また、EDNS（0）では、従来の512オクテットより大きいDNSメッセージサイズをネゴシエートするメカニズムが許可されていますが、特にDNSメッセージがすでにDNSSEC情報を含んでいる場合は、長いペイロードがUDPフラグメンテーションを引き起こすリスクが高くなります。 EDNS（0）が使用できない場合、またはネゴシエートされたEDNS（0）パケットサイズが小さすぎてデータに収まらない場合、またはUDPフラグメントがドロップされる場合、DNSは（最終的に）TCPの使用に頼ることがあります。 TCPではDNS応答をかなり長くすることができますが、これにはサーバーのステートフルな操作が必要であり、サーバーが多くのクライアントへの一時的な接続しか持たない展開ではコストがかかる可能性があります。最終的に、アプリケーションがDNSに保存する可能性のあるデータの形式が合理的な制限を超えます。たとえば、ENUMコンテキストでは、カスタム着信音のbase-64エンコードmp3ファイルを保存するようなものです。
Designs relying on storage of large amounts of data within DNS RRs furthermore need to minimize the potential damage achievable in a reflection attack (see [RFC4732], Section 3), in which the attacker sends UDP-only DNS queries with a forged source address, and the victim receives the response. The attacker relies on amplification, where a small query generates a large response directed at the victim. Where the responder supports EDNS(0), an attacker may set the requester maximum payload size to a larger value while querying for a large resource record, such as a certificate [RFC4398]. Thus, the combination of large data stored in DNS RRs and responders supporting large payload sizes has the potential to increase the potential damage achievable in a reflection attack.
さらに、DNS RR内に大量のデータを保存する設計では、攻撃者が偽造された送信元アドレスでUDPのみのDNSクエリを送信するリフレクション攻撃（[RFC4732]、セクション3を参照）で発生する可能性のある損傷を最小限に抑える必要があります。被害者は応答を受け取ります。攻撃者は増幅に依存し、小さなクエリが被害者に向けられた大きな応答を生成します。レスポンダがEDNS（0）をサポートしている場合、攻撃者は、証明書[RFC4398]などの大きなリソースレコードを照会する際に、リクエスタの最大ペイロードサイズをより大きな値に設定できます。したがって、DNS RRに格納された大きなデータと大きなペイロードサイズをサポートするレスポンダの組み合わせは、リフレクション攻撃で発生する可能性のある損害を増大させる可能性があります。
Since a reflection attack can be launched from any network that does not implement source address validation, these attacks are difficult to eliminate absent the ubiquitous deployment of source address validation or "heavier" transport protocols such as TCP. The bandwidth that can be mustered in a reflective amplification attack directed by a botnet reflecting off a recursive name server on a high-bandwidth network is sobering. For example, if the responding resolver could be directed to generate a 10KB response in reply to a 50-octet query, then magnification of 200:1 would be attainable. This would enable a botnet controlling 10000 hosts with 1 Mbps of bandwidth to focus 200 Gbps of traffic on the victim, more than sufficient to congest any site on today's Internet.
リフレクション攻撃は、送信元アドレス検証を実装していない任意のネットワークから起動できるため、これらの攻撃は、送信元アドレス検証またはTCPなどの「より重い」トランスポートプロトコルのユビキタスな展開を排除することは困難です。高帯域幅ネットワーク上の再帰的なネームサーバーを反射するボットネットによって指示される反射型増幅攻撃で獲得できる帯域幅は、地味です。たとえば、応答するリゾルバーが50オクテットのクエリに応答して10KBの応答を生成するように指示された場合、200：1の拡大率が達成されます。これにより、1 Mbpsの帯域幅を持つ10000台のホストを制御するボットネットが、被害者に200 Gbpsのトラフィックを集中させることができます。これは、今日のインターネット上のどのサイトでも輻輳するのに十分です。
DNS reflection attacks typically utilize UDP queries; it is prohibitively difficult to complete a TCP three-way handshake begun from a forged source address for DNS reflection attacks. Unless the attacker uses EDNS(0) [RFC6891] to enlarge the requester's maximum payload size, a response can only reach 576 octets before the truncate bit is set in the response. This limits the maximum magnification achievable from a DNS query that does not utilize EDNS(0). As the large disparity between the size of a query and size of the response creates this amplification, techniques for mitigating this disparity should be further studied, though this is beyond the scope of this memo (for an analysis of the effects of limiting EDNS(0) responses while still accommodating DNSSEC, see [Lindsay]). For example, some implementations could limit EDNS(0) responses to a specific ratio compared to the request size, where the precise ratio can be configured on a per-deployment basis (taking into account DNSSEC response sizes). Without some means of mitigating the potential for amplification, EDNS(0) could cause significant harm.
DNSリフレクション攻撃は通常、UDPクエリを利用します。 DNSリフレクション攻撃のために、偽造された送信元アドレスから始まるTCP 3ウェイハンドシェイクを完了することは非常に困難です。攻撃者がEDNS（0）[RFC6891]を使用してリクエスターの最大ペイロードサイズを拡大しない限り、応答は切り捨てビットが応答に設定される前に576オクテットにしか到達できません。これにより、EDNS（0）を使用しないDNSクエリから取得できる最大倍率が制限されます。クエリのサイズと応答のサイズの間の大きな不一致がこの増幅を生み出すので、この不一致を軽減するためのテクニックをさらに研究する必要がありますが、これはこのメモの範囲を超えています（EDNSの制限の影響を分析するため（0 ）DNSSECに対応しながらの応答。[Lindsay]を参照）。たとえば、一部の実装では、EDNS（0）応答を要求サイズと比較して特定の比率に制限できます。正確な比率は、デプロイメントごとに構成できます（DNSSEC応答サイズを考慮に入れて）。増幅の可能性を軽減する手段がなければ、EDNS（0）は重大な害を引き起こす可能性があります。
In summary, there are two operational forces that tend to drive the practically available EDNS(0) sizes down: possible UDP fragmentation and minimizing amplification in case of reflection attacks. DNSSEC data will use a significant fraction of the available space in a DNS packet. Therefore -- appreciating that given the current DNSSEC and EDNS(0) deployment experience, precise numbers are impossible to give -- the generic payload available to other DNS data, given the premise that TCP fallback is to be minimized, is likely to be closer to several hundred octets than a few thousand octets.
要約すると、実際に利用可能なEDNS（0）サイズを削減する傾向がある2つの運用上の力があります：可能なUDPフラグメンテーションと反射攻撃の場合の増幅の最小化。 DNSSECデータは、DNSパケットで使用可能なスペースのかなりの部分を使用します。したがって、-現在のDNSSECおよびEDNS（0）の展開経験を考えると、正確な数値を与えることは不可能であることを認める-TCPフォールバックが最小化されるという前提で、他のDNSデータが利用できる一般的なペイロードはより近い可能性が高い数千オクテットよりも数百オクテットまで。
While the DDDS framework enables any sort of alphanumeric data to serve as a domain name through the application of the "First Well Known Rule", the delegative structure of the resulting domain name may not reflect any administrative division of responsibilities inherent in the original data. While [RFC3402] requires only that the "Application Unique String has some kind of regular, lexical structure that the rules can be applied to", DDDS is first and foremost a delegation system: its abstract stipulates that "Well-formed transformation rules will reflect the delegation of management of information associated with the string". Telephone numbers in the United States, for example, are assigned and delegated in a relatively complex manner. Historically, the first six digits of a nationally specific number (called the "NPA/NXX") reflected a point of administrative delegation from the number assignment agency to a carrier; from these blocks of ten thousand numbers, the carrier would in turn delegate individual assignments of the last four digits (the "XXXX" portion) to particular customers. However, after the rise of North American telephone number portability in the 1990s, the first point of delegation went away: the delegation is effectively from the number authority to the carrier for each complete ten-digit number (NPA/NXX-XXXX). While technical implementation details differ from nation to nation, number portability systems with similar administrative delegations now exist worldwide.
DDDSフレームワークでは、「First Well Knownルール」を適用することにより、あらゆる種類の英数字データをドメイン名として機能させることができますが、結果のドメイン名の委任構造は、元のデータに固有の責任の管理部門を反映していない場合があります。 [RFC3402]は、「アプリケーション固有の文字列が、規則を適用できるある種の規則的で字句構造を持っている」ことのみを要求しますが、DDDSは何よりもまず委任システムです。その抽象は、「整形式の変換規則が反映される」と規定しています文字列に関連付けられた情報の管理の委任」。たとえば、米国の電話番号は、比較的複雑な方法で割り当てられ、委任されます。歴史的に、全国的に特定された番号の最初の6桁（「NPA / NXX」と呼ばれる）は、番号割り当て機関から運送業者への管理委任のポイントを反映していました。運送業者は、これらの1万の数字のブロックから、最後の4桁（「XXXX」の部分）の個々の割り当てを特定の顧客に委任します。ただし、1990年代に北米の電話番号の移植性が高まった後、委任の最初のポイントは廃止されました。委任は、完全な10桁の番号（NPA / NXX-XXXX）ごとに、実質的に番号当局からキャリアまでです。技術的な実装の詳細は国ごとに異なりますが、現在、同様の管理委任を持つ多数のポータビリティシステムが世界中に存在しています。
To render these identifiers as domain names in accordance with the DDDS Rule for ENUM yields a large flat administrative domain with no points of administrative delegation from the country-code administrator, e.g., 1.e164.arpa, down to the ultimate assignee of a number. Under the assumption that one administrative domain is maintained within one DNS zone containing potentially over five billion names, scalability difficulties manifest in a number of areas: the scalability that results from caching depends on these points of delegation, so that cached results for intermediate servers take the load off higher-tier servers. If there are no such delegations, then as in the telephone number example the zone apex server must bear the entire load for queries. Worse still, number portability also introduces far more dynamism in number assignment, where in some regions updated assignees for ported numbers must propagate within fifteen minutes of a change in administration. Jointly, these two problems make caching the zone extremely problematic. Moreover, traditional tools for DNS replication, such as the zone transfer protocols AXFR [RFC1034] and IXFR [RFC1995], might not scale to accommodate zones with these dimensions and properties.
ENUMのDDDS規則に従ってこれらの識別子をドメイン名としてレンダリングすると、国コード管理者（1.e164.arpaなど）からの管理委任のポイントがなく、番号の最終的な譲受人に至るまで、大規模でフラットな管理ドメインが生成されます。 。 50億を超える名前を含む可能性のある1つのDNSゾーン内に1つの管理ドメインが維持されているという仮定の下で、スケーラビリティの問題は多くの領域で現れます。キャッシュから生じるスケーラビリティはこれらの委任ポイントに依存するため、中間サーバーのキャッシュ結果は上位層サーバーの負荷。そのような委任がない場合は、電話番号の例のように、ゾーンの頂点サーバーがクエリの全負荷を負担する必要があります。さらに悪いことに、番号の移植性は、番号の割り当てにはるかに大きなダイナミズムをもたらします。一部の地域では、移植された番号の更新された譲受人は、管理の変更から15分以内に伝播する必要があります。これらの2つの問題により、ゾーンのキャッシュが非常に問題になります。さらに、ゾーン転送プロトコルAXFR [RFC1034]やIXFR [RFC1995]などのDNSレプリケーションの従来のツールは、これらのディメンションとプロパティを持つゾーンに対応するようにスケーリングされない場合があります。
In practice, the maximum sizes of telephone number administrative domains are closer to 300M (the current amount of allocated telephone numbers in the United States today -- still more than three times the number of .com domain names), and one can alleviate some of the scalability issues mentioned above by artificially dividing the administrative domain into a hierarchy of DNS zones. Still, the fact that traditional DNS management tools no longer apply to the structures that an application tries to provision in the DNS is a clue that the DNS might not be the right place for an application to store its data.
実際には、電話番号の管理ドメインの最大サイズは300M（現在の米国で割り当てられている電話番号の現在の量-.comドメイン名の数の3倍以上）に近く、いくつかの問題を緩和できます。管理ドメインをDNSゾーンの階層に人為的に分割することにより、上記のスケーラビリティの問題。それでも、アプリケーションがDNSでプロビジョニングしようとする構造に従来のDNS管理ツールが適用されなくなったという事実は、DNSがアプリケーションがデータを格納するのに適切な場所ではない可能性があるという手がかりです。
While DDDS is the most obvious example of these concerns, the point is more generic: for example, were address portability to be implemented for IP addresses and their administration thus to become non-hierarchical, the same concerns would apply to in-addr.arpa names. The difficulty of mapping the DNS to administrative structures can even occur with traditional domain names, where applications expect clients to infer or locate zone cuts. In the web context, for example, it can be difficult for applications to determine whether two domains represent the same "site" when comparing security credentials with URLs (see Section 3.4 below for more on this). This has also caused known problems in determining the scope of web cookies, in contexts where applications must infer where administrative domains end in order to grant cookies that are as narrowly scoped as possible.
DDDSはこれらの懸念の最も明白な例ですが、要点はより一般的です。たとえば、IPアドレスとその管理に実装されたアドレスの移植性が非階層化されると、同じ懸念がin-addr.arpaに適用されます。名前。 DNSを管理構造にマッピングすることの困難さは、アプリケーションがクライアントがゾーンカットを推測または特定することを期待する従来のドメイン名でも発生する可能性があります。たとえば、Webコンテキストでは、セキュリティ認証情報をURLと比較するときに、2つのドメインが同じ「サイト」を表すかどうかをアプリケーションが判断するのが難しい場合があります（詳細については、以下のセクション3.4を参照）。これにより、アプリケーションの管理ドメインがどこにあるかを推測して、可能な限り範囲が限定されたCookieを付与する必要があるコンテキストで、Web Cookieのスコープを決定する際に既知の問題が発生しました。
In summary, the "First Well Known Rule" of DDDS provides a capability that transforms arbitrary strings into domain names, but those names play well with the DNS only when the input strings have an administrative structure that maps to DNS delegations. In the first place, delegation implies some sort of hierarchical structure. Any mechanism to map a hierarchical identifier into a domain name should be constructed such that the resulting domain name does match the natural hierarchy of the original identifier. Although telephone numbers, even in North America, have some hierarchical qualities (like the geographical areas corresponding to their first three digits), after the implementation of number portability these points no longer mapped onto an administrative delegation. If the input string to the DDDS does not have a hierarchical structure representing administrative delegations that can map onto the DNS distribution system, then that string probably is not a good candidate for translating into a domain name.
要約すると、DDDSの「First Well Knownルール」は、任意の文字列をドメイン名に変換する機能を提供しますが、これらの名前は、入力文字列がDNS委任にマップする管理構造を持つ場合にのみ、DNSで適切に機能します。そもそも、委任はある種の階層構造を意味します。階層識別子をドメイン名にマップするメカニズムは、結果のドメイン名が元の識別子の自然な階層と一致するように構築する必要があります。電話番号は、北米でも、最初の3桁に対応する地理的領域のようにいくつかの階層的な性質を持っていますが、番号の移植性の実装後、これらのポイントは管理委任にマッピングされなくなりました。 DDDSへの入力文字列に、DNS配布システムにマップできる管理委任を表す階層構造がない場合、その文字列はおそらくドメイン名に変換するのに適した候補ではありません。
There are also other ways in which the delegative structure of an identifier may not map well onto the DNS. Traditionally, DNS resolvers assume that when they receive a domain name from an application the name is complete -- that it is not a fragment of a domain name that a user is still in the middle of typing. For some communications systems, however, this assumption does not apply. ENUM use cases have surfaced a couple of optimization requirements to reduce unnecessary calls and queries; proposed solutions include metadata in the DNS that describes the contents and structure of ENUM DNS trees to help applications handle incomplete queries or queries for domains not in use.
識別子の委任構造がDNSにうまくマッピングできない他の方法もあります。従来、DNSリゾルバーは、アプリケーションからドメイン名を受け取ったとき、その名前は完全であると想定しています。これは、ユーザーが入力中のドメイン名のフラグメントではないことを前提としています。ただし、一部の通信システムでは、この仮定は適用されません。 ENUMの使用例では、不要な呼び出しとクエリを削減するためのいくつかの最適化要件が明らかになっています。提案されたソリューションには、ENUM DNSツリーの内容と構造を記述するメタデータがDNSに含まれ、アプリケーションが不完全なクエリや使用されていないドメインのクエリを処理できるようにします。
In particular, the "send-n" proposal [ENUM-Send-N] hoped to reduce the number of DNS queries sent in regions with variable-length numbering plans. When a dialed number potentially has a variable length, a telephone switch ordinarily cannot anticipate when a dialed number is complete, as only the numbering plan administrator (who may be a national regulator, or even in open number plans a private branch exchange) knows how long a telephone number needs to be. Consequently, a switch trying to resolve such a number through a system like ENUM might send a query for a telephone number that has only partially been dialed in order to test its completeness. The send-n proposal installs in the DNS a hint informing the telephone switch of the minimum number of digits that must be collected by placing in zones corresponding to incomplete telephone numbers some resource records that state how many more digits are required -- effectively how many steps down the DNS tree one must take before querying the DNS again. Unsurprisingly, those boundaries reflect points of administrative delegation, where the parent in a number plan yields authority to a child. With this information, the application is not required to query the DNS every time a new digit is dialed but can wait to collect sufficient digits to receive a response. As an optimization, this practice thus saves the resources of the DNS server, though the call cannot complete until all digits are collected, so this mechanism simply reduces the time the system will wait before sending an ENUM query after collecting the final dialed digit. A tangentially related proposal, [ENUM-UNUSED], similarly places resource records in the DNS that tell the application that it need not attempt to reach a number on the telephone network, as the number is unassigned -- a comparable general DNS mechanism would identify, for a domain name with no records available in the DNS, whether or not the domain had been allocated by a registry to a registrant (which is a different condition than a name merely being unresolvable, per the semantics of NXDOMAIN).
特に、「send-n」の提案[ENUM-Send-N]は、可変長の番号付けプランのあるリージョンで送信されるDNSクエリの数を減らすことを望んでいました。ダイヤルされた番号が可変長になる可能性がある場合、通常、電話交換機はダイヤルされた番号がいつ完成するかを予測できません。番号計画の管理者（国の規制当局、またはオープンナンバープランの場合でも構内交換機）だけがその方法を知っているためです。電話番号は長くする必要があります。その結果、ENUMなどのシステムを介してこのような番号を解決しようとするスイッチは、完全性をテストするために部分的にしかダイヤルされていない電話番号のクエリを送信する場合があります。 send-nプロポーザルは、不完全な電話番号に対応するゾーンに収集する必要がある最小桁数を電話交換機に通知するヒントをDNSにインストールします。ゾーンには、必要な桁数を示すリソースレコードがいくつかあります。 DNSを再度クエリする前に、DNSツリーをステップダウンする必要があります。当然のことながら、これらの境界は管理委任のポイントを反映しており、番号計画の親は子に権限を与えます。この情報を使用すると、アプリケーションは新しい数字がダイヤルされるたびにDNSをクエリする必要はありませんが、応答を受信するために十分な数字を収集するのを待つことができます。したがって、最適化として、この方法はDNSサーバーのリソースを節約しますが、すべての数字が収集されるまで呼び出しを完了できないため、このメカニズムは、最終的にダイヤルされた数字を収集した後にENUMクエリを送信する前にシステムが待機する時間を単に短縮します。接線に関連する提案[ENUM-UNUSED]は、番号が割り当てられていないため、電話ネットワーク上の番号に到達する必要がないことをアプリケーションに通知するリソースレコードをDNSに同様に配置します-同等の一般的なDNSメカニズムで識別されます、DNSで使用可能なレコードがないドメイン名の場合、レジストリによってドメインが登録者に割り当てられたかどうか（NXDOMAINのセマンティクスにより、名前が単に解決できないこととは異なる条件です）。
Both proposals optimize application behavior by placing metadata in the DNS that predicts the success of future queries or application invocation by identifying points of administrative delegation or assignment in the tree. In some respects, marking a point in the tree where a zone begins or ends has some features in common with the traditional parent zone use of the NS record type, except that instead of pointing to a child zone these metadata proposals point to distant grandchildren. While this does not change resolver behavior as such (instead, it changes the way that applications invoke the resolver), it does have implications for the practices for zone administrators. Metadata in one administrative domain would need to remain synchronized with the state of the resources it predicts in another administrative domain in the DNS namespace, in a case like overlap dialing where the carrier delegates to a zone controlled by an enterprise. When dealing with external resources associated with other namespaces, like number assignments in the PSTN or the databases of a registry operator, other synchronization requirements arise; maintaining that synchronization requires that the DNS have "semi-real time" updates that may conflict with scale and caching mechanisms of the DNS.
どちらの提案も、DNSにメタデータを配置することでアプリケーションの動作を最適化し、ツリー内の管理の委任または割り当てのポイントを特定することにより、将来のクエリまたはアプリケーションの呼び出しの成功を予測します。いくつかの点で、ゾーンが開始または終了するツリー内のポイントをマークすることには、NSレコードタイプの従来の親ゾーンの使用と共通するいくつかの機能がありますが、子ゾーンを指す代わりに、これらのメタデータ提案は遠方の孫を指す点が異なります。これにより、リゾルバーの動作自体は変更されません（代わりに、アプリケーションがリゾルバーを呼び出す方法が変更されます）が、ゾーン管理者のプラクティスに影響します。キャリアが企業が管理するゾーンに委任するオーバーラップダイヤリングなどの場合、1つの管理ドメインのメタデータは、DNSネームスペースの別の管理ドメインで予測されるリソースの状態と常に同期している必要があります。 PSTNやレジストリオペレーターのデータベースでの番号割り当てなど、他の名前空間に関連付けられた外部リソースを処理する場合、他の同期要件が発生します。この同期を維持するには、DNSに "準リアルタイム"の更新が必要であり、DNSのスケールとキャッシュメカニズムと競合する可能性があります。
Placing metadata in the DNS may also raise questions about the authority and delegation model. Who gets to supply records for unassigned names? While in the original but little-used e164.arpa root of ENUM this would almost certainly be a numbering plan administrator, it is far less clear who that would be in the more common and successful "infrastructure" ENUM models (see Section 4). Ultimately, these metadata proposals share some qualities with DNS redirection services offered by ISPs (for example, [DNS-REDIRECT]) that "help" web users who try to browse to sites that do not exist. Similarly, metadata proposals like [ENUM-UNUSED] create DNS records for unallocated zones that redirect to a service provider's web page. However, in the [DNS-REDIRECT] cases, at least the existence or non-existence of a domain name is a fact about the Internet namespace, rather than about an external namespace like the telephony E.164 namespace (which must be synchronized with the DNS tree in the metadata proposals). In send-n, different leaf zones that administer telephone numbers of different lengths can only provision their hints at their own apex, which provides an imperfect optimization: they cannot install it themselves in a parent, both because they lack the authority and because different zones would want to provision contradictory data. The later the hint appears in the tree, however, the less optimization will result. An application protocol designer managing identifiers whose administrative model does not map well onto the DNS namespace and delegations structure would be better served to implement such features outside the DNS.
DNSにメタデータを配置すると、権限と委任モデルに関する疑問も生じる可能性があります。誰が未割り当ての名前のレコードを提供するのですか？ ENUMの元の、あまり使用されていないe164.arpaルートでは、これはほぼ間違いなく番号計画の管理者ですが、より一般的で成功した「インフラストラクチャ」ENUMモデルに誰が含まれるかはあまり明確ではありません（セクション4を参照）。最終的に、これらのメタデータの提案は、ISPが提供するDNSリダイレクトサービス（[DNS-REDIRECT]など）といくつかの品質を共有し、存在しないサイトにアクセスしようとするWebユーザーを「助け」ます。同様に、[ENUM-UNUSED]などのメタデータ提案は、サービスプロバイダーのWebページにリダイレクトする未割り当てゾーンのDNSレコードを作成します。ただし、[DNS-REDIRECT]の場合、ドメイン名の存在または非存在は、テレフォニーE.164名前空間などの外部の名前空間（と同期する必要がある）ではなく、インターネットの名前空間に関する事実です。メタデータ提案のDNSツリー）。 send-nでは、異なる長さの電話番号を管理する異なるリーフゾーンは、独自の頂点でのみヒントをプロビジョニングできます。これは不完全な最適化を提供します。権限を持たないため、および異なるゾーンのため、親にそれをインストールできません。矛盾するデータをプロビジョニングする必要がある。ヒントはツリーに後で表示されますが、最適化は少なくなります。管理モデルがDNS名前空間と委任構造にうまくマッピングされない識別子を管理するアプリケーションプロトコルデザイナーは、DNSの外部にそのような機能を実装するのに適しています。
Most Internet application services provide a redirection feature -- when one attempts to contact a service, the service may refer the person to a different service instance, potentially in another domain, that is for whatever reason better suited to service a request. In HTTP and SIP, for example, this feature is implemented by the 300 class responses containing one or more URIs, which may indicate that a resource has moved temporarily or permanently to another service. Several tools in the DNS, including the SRV record, can provide a similar feature at a DNS level, and consequently some applications as an optimization offload the responsibility for redirection to the DNS; NAPTR can also provide this capability on a per-application basis, and numerous DNS resource records can provide redirection on a per-domain basis. This can prevent the unnecessary expenditure of application resources on a function that could be performed as a component of a DNS lookup that is already a prerequisite for contacting the service. Consequently, in some deployment architectures this DNS-layer redirection is used for virtual hosting services.
ほとんどのインターネットアプリケーションサービスはリダイレクト機能を提供します。サービスに接続しようとすると、サービスは、別のドメインにある別のサービスインスタンスをユーザーに紹介する可能性があります。たとえば、HTTPおよびSIPでは、この機能は、リソースが一時的または永続的に別のサービスに移動したことを示す1つ以上のURIを含む300クラスの応答によって実装されます。 SRVレコードを含むDNSのいくつかのツールは、DNSレベルで同様の機能を提供でき、その結果、最適化としての一部のアプリケーションは、DNSへのリダイレクトの責任を軽減します。 NAPTRはアプリケーションごとにこの機能を提供することもでき、多数のDNSリソースレコードがドメインごとにリダイレクトを提供できます。これにより、すでにサービスに接続するための前提条件であるDNSルックアップのコンポーネントとして実行される可能性がある機能へのアプリケーションリソースの不要な支出を防ぐことができます。その結果、一部の展開アーキテクチャでは、このDNS層のリダイレクトが仮想ホスティングサービスに使用されます。
Implementing domain redirection in the DNS, however, has important consequences for application security. In the absence of universal DNSSEC, applications must blindly trust that their request has not been hijacked at the DNS layer and redirected to a potentially malicious domain, unless some subsequent application mechanism can provide the necessary assurance. By way of contrast, application-layer protocols supporting redirection, such as HTTP and SIP, have available security mechanisms, including TLS, that can use certificates to attest that a 300 response came from the domain that the originator initially hoped to contact.
ただし、DNSにドメインリダイレクトを実装すると、アプリケーションのセキュリティに重要な影響があります。ユニバーサルDNSSECがない場合、後続のアプリケーションメカニズムが必要な保証を提供できない限り、アプリケーションは要求がDNS層でハイジャックされず、潜在的に悪意のあるドメインにリダイレクトされていないことを盲目的に信頼する必要があります。対照的に、HTTPやSIPなどのリダイレクトをサポートするアプリケーション層プロトコルは、TLSを含む利用可能なセキュリティメカニズムを備えており、証明書を使用して、発信者が最初に連絡したいドメインからの応答が300であることを証明できます。
A number of applications have attempted to provide an after-the-fact
security mechanism that verifies the authority of a DNS delegation in
the absence of DNSSEC. The specification for dereferencing SIP URIs
([RFC3263], reaffirmed in [RFC5922]), requires that during TLS
establishment the site eventually reached by a SIP request present a
certificate corresponding to the original URI expected by the user;
this requires a virtual hosting service to possess a certificate
corresponding to the hosted domain. (In other words, if example.com
redirects to example.net in the DNS, this mechanism expects that
example.net will supply a certificate for example.com in TLS, per the
HTTP precedent in [RFC2818]). This restriction rules out many styles
of hosting deployments common in the web world today, however.
[HARD-PROBLEM] explores this problem space. [RFC6125] proposes a
solution for all applications that use TLS, which relies on new
application-specific identifiers in certificates, as does [RFC4985]);
note, however, that support for such certificates would require
changes to existing certificate authority practices as well as
application behavior. With DNSSEC in place, DNS-based Authentication
of Named Entities (DANE) [RFC6394] offers another way to bind
certificates to particular applications and services.
All of these application-layer measures attempt to mirror the delegation of administrative authority in the DNS, when the DNS itself serves as the ultimate authority on how domains are delegated. (Note: changing the technical delegation structure by changing NS records in the DNS is not the same as administrative delegation, e.g., when a domain changes ownership.) Synchronizing a static instrument like a certificate with a delegation in the DNS, however, is problematic because delegations are not static: revoking and reissuing a certificate every time an administrative delegation changes is cumbersome operationally. In environments where DNSSEC is not available, the problems with securing DNS-layer redirections would be avoided by performing redirections in the application layer. This inevitably gives rise to various design trade-offs involving performance, load, and related factors, but in these application environments, the security properties typically take priority.
DNS自体がドメインの委任方法の最終的な権限として機能する場合、これらのアプリケーション層の手段はすべて、DNSにおける管理権限の委任を反映しようとします。 （注：DNSのNSレコードを変更して技術的な委任構造を変更することは、管理の委任と同じではありません。たとえば、ドメインの所有権が変更された場合などです。）証明書などの静的な手段をDNSの委任と同期させることは問題があります委任は静的ではないため、管理の委任が変更されるたびに証明書を取り消して再発行するのは、運用上厄介です。 DNSSECを利用できない環境では、アプリケーションレイヤーでリダイレクトを実行することにより、DNSレイヤーリダイレクトの保護に関する問題を回避できます。これは必然的に、パフォーマンス、負荷、および関連要素を含むさまざまな設計上のトレードオフを引き起こしますが、これらのアプリケーション環境では、通常、セキュリティプロパティが優先されます。
The classic view of the uniqueness of domain names in the DNS is given in [RFC2826]:
DNSにおけるドメイン名の一意性の古典的な見方は、[RFC2826]で与えられています：
DNS names are designed to be globally unique, that is, for any one DNS name at any one time there must be a single set of DNS records uniquely describing protocol addresses, network resources and services associated with that DNS name. All of the applications deployed on the Internet which use the DNS assume this, and Internet users expect such behavior from DNS names.
DNS名はグローバルに一意になるように設計されています。つまり、一度に1つのDNS名に対して、そのDNS名に関連付けられたプロトコルアドレス、ネットワークリソース、およびサービスを一意に記述する単一のDNSレコードのセットが必要です。 DNSを使用するインターネット上に展開されたすべてのアプリケーションはこれを前提としており、インターネットユーザーはDNS名からそのような動作を期待しています。
[RFC2826] "does not preclude private networks from operating their own private name spaces" but notes that if private networks "wish to make use of names uniquely defined for the global Internet, they have to fetch that information from the global DNS naming hierarchy". There are various DNS deployments outside of the global public DNS, including "split horizon" deployments and DNS usages on private (or virtual private) networks. In a split horizon, an authoritative server gives different responses to queries from the public Internet than they do to internal resolvers; while some deployments differentiate internal queries from public queries by the source IP address, the concerns in Section 3.1.1 relating to trusting source IP addresses apply to such deployments. When the internal address space range is private [RFC1918], this makes it both easier for the server to discriminate public from private and harder for public entities to impersonate nodes in the private network. Networks that are made private physically, or logically by cryptographic tunnels, make these private deployments more secure. The most complex deployments along these lines use multiple virtual private networks to serve different answers for the same name to many distinct networks.
[RFC2826]「プライベートネットワークが独自のプライベートネームスペースを操作することを妨げない」が、プライベートネットワークが「グローバルインターネットに対して一意に定義された名前を使用したい場合、グローバルDNSネーミング階層からその情報をフェッチする必要がある」と述べている。グローバルスプリットホライズンデプロイメントやプライベート（または仮想プライベート）ネットワークでのDNSの使用など、グローバルパブリックDNS以外にもさまざまなDNSデプロイメントがあります。スプリットホライズンでは、権限のあるサーバーは、パブリックインターネットからのクエリに対して、内部リゾルバーに対するものとは異なる応答を提供します。一部の展開では、送信元IPアドレスによって内部クエリとパブリッククエリが区別されますが、送信元IPアドレスの信頼に関するセクション3.1.1の懸念がそのような展開に適用されます。内部アドレススペースの範囲がプライベート[RFC1918]の場合、これにより、サーバーはパブリックとプライベートを簡単に区別できるようになり、パブリックエンティティがプライベートネットワークのノードになりすますことが困難になります。物理的または論理的に暗号化トンネルによってプライベートにされるネットワークは、これらのプライベートな展開をより安全にします。これらの線に沿った最も複雑な展開では、複数の仮想プライベートネットワークを使用して、同じ名前のさまざまな回答を多くの異なるネットワークに提供します。
The use cases that motivate split-horizon DNS typically involve restricting access to some network services -- intranet resources such as internal web sites, development servers, or directories, for example -- while preserving the ease of use offered by domain names for internal users. While for many of these resources the split horizon would not return answers to public resolvers for those internal resources (those records are kept confidential from the public), in some cases the same name (e.g., "mail.example.com") might resolve to one host internally but another externally. The requirements for multiple-VPN private deployments, however, are different: in this case the authoritative server gives different, and confidential, answers to a set of resolvers querying for the same name. While these sorts of use cases rarely arise for traditional domain names, where, as [RFC2826] says, users and applications expect a unique resolution for a name, they can easily arise when other sorts of identifiers have been translated by a mechanism such as the "First Well Known Rule" of DDDS into "domain name syntax". Telephone calls, for example, are traditionally routed through highly mediated networks, in which an attempt to find a route for a call often requires finding an appropriate intermediary based on the source network and location rather than finding an endpoint (see the distinction between the Look-Up Function and Location Routing Function in [RFC5486]). Moreover, the need for responses tailored to the originator, and for confidentiality, is easily motivated when the data returned by the DNS is no longer "describing protocol addresses, network resources and services" [RFC2826] but instead is arbitrary data. Although, for example, ENUM was originally intended for deployment in the global public root of the DNS (under e164.arpa), the requirements of maintaining telephone identifiers in the DNS quickly steered operators into private deployments.
通常、スプリットホライズンDNSの動機となるユースケースには、一部のネットワークサービス（たとえば、内部Webサイト、開発サーバー、ディレクトリなどのイントラネットリソース）へのアクセスを制限しながら、内部ユーザー向けのドメイン名によって提供される使いやすさを維持することが含まれます。 。これらのリソースの多くでは、スプリットホライズンはこれらの内部リソースのパブリックリゾルバーに回答を返しません（これらのレコードはパブリックから機密に保たれます）が、同じ名前（たとえば、「mail.example.com」）で解決される場合があります1つのホストに内部的に、別のホストに外部的に。ただし、複数のVPNプライベート展開の要件は異なります。この場合、権限のあるサーバーは、同じ名前を照会するリゾルバーのセットに対して異なる機密の応答を提供します。 [RFC2826]が言うように、ユーザーとアプリケーションが名前の一意の解決を期待している従来のドメイン名では、このような種類の使用例はめったに発生しませんが、他の種類の識別子が次のようなメカニズムによって変換された場合、簡単に発生する可能性があります。 DDDSの「First Well Knownルール」を「ドメイン名構文」に。たとえば、電話の通話は伝統的に高度に仲介されたネットワークを介してルーティングされます。そのため、通話のルートを見つけるには、エンドポイントを見つけるのではなく、ソースネットワークと場所に基づいて適切な仲介者を見つける必要があります（Lookの違いを参照）。 [RFC5486]のアップ機能とロケーションルーティング機能。さらに、DNSから返されたデータが「プロトコルアドレス、ネットワークリソース、サービスを記述している」[RFC2826]ではなく任意のデータである場合、発信者に合わせた応答と機密保持の必要性は容易に動機付けられます。たとえば、ENUMはもともとDNSのグローバルパブリックルート（e164.arpaの下）での展開を目的としていましたが、DNSで電話識別子を維持する要件により、オペレーターはすぐにプライベートな展開に移行しました。
In private environments, it is also easier to deploy any necessary extensions than it is in the public DNS: in the first place, proprietary non-standard extensions and parameters can more easily be integrated into DNS queries or responses, as the implementations of resolvers and servers can likely be controlled; secondly, confidentiality and custom responses can be provided by deploying, respectively, underlying physical or virtual private networks to shield the private tree from public queries, and effectively different virtual DNS trees for each administrative entity that might launch a query; thirdly, in these constrained environments, caching and recursive resolvers can be managed or eliminated in order to prevent any unexpected intermediary behavior. While these private deployments serve an important role in the marketplace, there are risks in using techniques intended only for deployment in private and constrained environments as the basis of a standard solution. When proprietary parameters or extensions are deployed in private environments, experience teaches us that these implementations will begin to interact with the public DNS and that the private practices will leak.
プライベート環境では、パブリックDNSよりも必要な拡張機能を展開する方が簡単です。そもそも、独自の非標準の拡張機能とパラメーターを、リゾルバーと実装の実装として、DNSクエリまたは応答に簡単に統合できます。サーバーを制御できる可能性があります。第2に、プライベートツリーをパブリッククエリから保護するための基盤となる物理または仮想プライベートネットワークをそれぞれ展開することにより、機密性とカスタム応答を提供できます。第3に、これらの制約された環境では、予期しない中間動作を防ぐために、キャッシングと再帰リゾルバーを管理または削除できます。これらのプライベートな展開は市場で重要な役割を果たしますが、プライベートおよび制約された環境での展開のみを目的とした手法を標準ソリューションの基礎として使用することにはリスクがあります。独自のパラメータまたは拡張機能がプライベート環境にデプロイされると、経験から、これらの実装はパブリックDNSとの相互作用を開始し、プライベートプラクティスが漏洩することがわかります。
While such leakage is not a problem when using the mechanisms described in Sections 3.1, 3.2, and 3.5 (with private RR types) of [RFC5507], other extension mechanisms might cause confusion or harm if leaked. The use of a dedicated suffix (Section 3.3 of [RFC5507]) in a private environment might cause confusion if leaked to the public Internet, for example.
[RFC5507]のセクション3.1、3.2、3.5で説明されているメカニズム（プライベートRRタイプを使用）を使用する場合、このようなリークは問題になりませんが、他の拡張メカニズムは、リークすると混乱や害を引き起こす可能性があります。たとえば、プライベート環境で専用のサフィックス（[RFC5507]のセクション3.3）を使用すると、公衆インターネットに漏洩した場合に混乱が生じる可能性があります。
That this kind of leakage of protocol elements from private deployments to public deployments does happen has been demonstrated, for example, with SIP: SIP implemented a category of supposedly private extensions ( the "P-" headers) that saw widespread success and use outside of the constrained environments for which they were specifically designed. There is no reason to think that implementations with similar "private" extensions to the DNS protocols would not similarly end up in use in public environments.
この種のプロトコル要素のプライベートデプロイメントからパブリックデプロイメントへの漏洩が発生することは、たとえばSIPで実証されています。具体的に設計された制約付き環境。 DNSプロトコルに対する同様の「プライベート」拡張機能を持つ実装が、同様にパブリック環境で使用されるとは限らないと考える理由はありません。
The success of the global public DNS relies on the fact that it is a distributed database, one that has the property that it is loosely coherent and offers lookup instead of search functionality. Loose coherency means that answers to queries are coherent within the bounds of data replication between authoritative servers (as controlled by the administrator of the zone) and caching behavior by recursive name servers. Today, this term increasingly must also include load-balancing or related features that rely on the source IP address of the resolver. It is critical that application designers who intend to use the DNS to support their applications consider the implications that their uses have for the behavior of resolvers; intermediaries, including caches and recursive resolvers; and authoritative servers.
グローバルパブリックDNSの成功は、それが分散データベースであるという事実に依存しています。これは、緩やかに一貫性があり、検索機能の代わりにルックアップを提供するという特性を持っているものです。緩やかなコヒーレンシーとは、クエリへの応答が、権限のあるサーバー（ゾーンの管理者によって制御される）間のデータ複製と再帰的なネームサーバーによるキャッシュ動作の範囲内でコヒーレントであることを意味します。今日、この用語には、リゾルバーのソースIPアドレスに依存するロードバランシングまたは関連機能もますます含まれる必要があります。 DNSを使用してアプリケーションをサポートしようとするアプリケーション設計者は、その使用がリゾルバーの動作に与える影響を考慮することが重要です。キャッシュと再帰リゾルバを含む仲介者;権威サーバー。
It is likely that the DNS provides a good match whenever the needs of applications are aligned with the following properties:
アプリケーションのニーズが次のプロパティと整合している場合は常に、DNSが適切に一致する可能性があります。
o Data stored in the DNS can be propagated and cached using conventional DNS mechanisms, without intermediaries needing to understand exceptional logic (considerations beyond the name, type, and class of the query) used by the authoritative server to formulate responses
o DNSに格納されたデータは、従来のDNSメカニズムを使用して伝達およびキャッシュできます。仲介者は、権限のあるサーバーが応答を定式化するために使用する例外ロジック（クエリの名前、タイプ、およびクラス以外の考慮事項）を理解する必要はありません。
o Data stored in the DNS is indexed by keys that do not violate the syntax or semantics of domain names
o DNSに格納されたデータは、ドメイン名の構文またはセマンティクスに違反しないキーによってインデックスが作成されます
o Applications invoke the DNS to resolve complete names, not fragments
o アプリケーションはDNSを呼び出して、フラグメントではなく完全な名前を解決します
o Answers do not depend on an application-layer identity of the entity doing the query
o 回答は、クエリを実行するエンティティのアプリケーション層IDに依存しません
o Ultimately, applications invoke the DNS to assist in communicating with a service whose name is resolved through the DNS
o 最終的に、アプリケーションはDNSを呼び出して、DNSを介して名前が解決されるサービスとの通信を支援します
Whenever one of the five properties above does not apply to one's data, one should seriously consider whether the DNS is the best place to store actual data. On the other hand, if one has to worry about the following items, then these items are good indicators that the DNS is not the appropriate tool for solving problems:
上記の5つのプロパティのいずれかが自分のデータに適用されない場合は、DNSが実際のデータを格納するのに最適な場所であるかどうかを真剣に検討する必要があります。一方、次の項目について心配する必要がある場合、これらの項目はDNSが問題を解決するための適切なツールではないことを示す良い指標です。
o Populating metadata about domain boundaries within the tree -- the points of administrative delegation in the DNS are something that applications are not in general aware of
o ツリー内のドメイン境界に関するメタデータの入力-DNSでの管理委任のポイントは、アプリケーションが一般に認識していないものです
o Domain names derived from identifiers that do not share a semantic or administrative model compatible with the DNS
o DNSと互換性のあるセマンティックモデルまたは管理モデルを共有しない識別子から派生したドメイン名
o Selective disclosure of data stored in and provided by the DNS
o DNSに格納され、DNSによって提供されるデータの選択的な開示
o DNS responses not fitting into UDP packets, unless EDNS(0) is available, and only then with the caveats discussed in Section 3.2.1
o EDNS（0）が利用可能でない限り、UDPパケットに適合しないDNS応答であり、その場合のみ、セクション3.2.1で説明した警告が発生します。
In cases where applications require these sorts of features, they are likely better instantiated by independent application-layer protocols than the DNS. For example, the objects that HTTP can carry in both queries and responses can easily contain the necessary structure to manage compound queries. Many applications already use HTTP because of widespread support for it in middleboxes. Similarly, HTTP has numerous ways to provide the necessary authentication, authorization, and confidentiality properties that some features require, as well as the redirection properties discussed in Section 3.4. These differences highlight the fact that the DNS and HTTP offer very different services and have different applicabilities; while both are query-response protocols, HTTP should not be doing the job of DNS, and DNS should not be doing the job of HTTP. Similarly, DNS should not be doing the job of Diameter, LDAP, or other application-layer protocols. The overhead of using any application-layer protocol may not be appropriate for all environments, of course, but even in environments where a more lightweight protocol is appropriate, DNS is usually not the only alternative.
アプリケーションがこのような種類の機能を必要とする場合、DNSよりも独立したアプリケーション層プロトコルによってインスタンス化するほうが適切です。たとえば、HTTPがクエリと応答の両方で運ぶことができるオブジェクトには、複合クエリを管理するために必要な構造を簡単に含めることができます。ミドルボックスでの幅広いサポートにより、多くのアプリケーションはすでにHTTPを使用しています。同様に、HTTPには、一部の機能に必要な認証、承認、機密性のプロパティ、およびセクション3.4で説明したリダイレクトプロパティを提供する多数の方法があります。これらの違いは、DNSとHTTPが非常に異なるサービスを提供し、異なる適用性を持っているという事実を強調しています。どちらもクエリ応答プロトコルですが、HTTPはDNSの機能を実行してはならず、DNSはHTTPの機能を実行してはなりません。同様に、DNSは、Diameter、LDAP、またはその他のアプリケーション層プロトコルの機能を実行するべきではありません。もちろん、アプリケーション層プロトコルを使用するオーバーヘッドは、すべての環境に適しているわけではありませんが、より軽量なプロトコルが適切な環境であっても、通常はDNSが唯一の選択肢ではありません。
Where the administrative delegations of the DNS form a necessary component in the instantiation of an application feature, there are various ways that the DNS can bootstrap access to an independent application-layer protocol better suited to field the queries in question. For example, since NAPTR or URI [URI-RR] Resource Records can contain URIs, those URIs can in turn point to an external query-response service such as an HTTP service where more syntactically and semantically rich queries and answers might be exchanged. Any protocol designer considering where to implement features must perform their own gap analysis and determine whether or not implementing some features is worth the potential cost in increased network state, latency, and so on, but implementing some features simply requires heavier structures than others.
DNSの管理委任がアプリケーション機能のインスタンス化に必要なコンポーネントを形成する場合、DNSが問題のクエリをフィールドするのにより適した独立したアプリケーション層プロトコルへのアクセスをブートストラップできるさまざまな方法があります。たとえば、NAPTRまたはURI [URI-RR]リソースレコードにはURIを含めることができるため、これらのURIは、HTTPサービスなどの外部のクエリ応答サービスを指すことができ、より構文的および意味的に豊富なクエリと回答を交換できます。機能の実装場所を検討しているプロトコル設計者は、独自のギャップ分析を実行し、一部の機能の実装がネットワーク状態や遅延などの潜在的なコストに見合うかどうかを判断する必要がありますが、一部の機能を実装するには、他の機能よりも重い構造が必要です。
Many of the concerns about how applications use the DNS discussed in this document involve security. The perceived need to authenticate the source of DNS queries (see Section 3.1.1) and authorize access to particular resource records also illustrates the fundamental security principles that arise from offloading certain application features to the DNS. As Section 3.2.1 observes, large data in the DNS can provide a means of generating reflection attacks, and without the remedies discussed in that section (regarding the use of EDNS(0) and TCP) the presence of large sets of records (e.g., ANY queries) is not recommended. Section 3.4 discusses a security problem concerning redirection that has surfaced in a number of protocols (see [HARD-PROBLEM]).
アプリケーションがこのドキュメントで説明されているDNSをどのように使用するかに関する懸念の多くは、セキュリティに関係しています。 DNSクエリのソースを認証し（セクション3.1.1を参照）、特定のリソースレコードへのアクセスを承認する必要性は、特定のアプリケーション機能をDNSにオフロードすることから生じる基本的なセキュリティ原則も示しています。セクション3.2.1が観察するように、DNSの大きなデータはリフレクション攻撃を生成する手段を提供する可能性があり、そのセクションで説明されている対策（EDNS（0）とTCPの使用に関して）がなければ、レコードの大きなセット（たとえば、任意のクエリ）は推奨されません。セクション3.4では、多くのプロトコルで表面化したリダイレクトに関するセキュリティ問題について説明します（[ハード問題]を参照）。
While DNSSEC, were it deployed universally, can play an important part in securing application redirection in the DNS, DNSSEC does not provide a means for a resolver to authenticate itself to a server, nor a framework for servers to return selective answers based on the authenticated identity of resolvers, nor a confidential mechanism. Some implementations may support authenticating users through TSIG, provided that the security association with a compliant server has been pre-established, though authentication is typically not needed for queries in the global public DNS. The existing feature set of DNSSEC is, however, sufficient for providing security for most of the ways that applications traditionally have used the DNS. The deployment of DNSSEC ([RFC4033] and related specifications) is heartily encouraged. Nothing in this document is intended to discourage the implementation, deployment, or use of Secure DNS Dynamic Updates [RFC3007], though this document does recommend that large data in the DNS be treated in accordance with the guidance in Section 3.2.1.
DNSSECは、それが普遍的に展開されていても、DNSでアプリケーションのリダイレクトを保護する上で重要な役割を果たすことができますが、DNSSECは、リゾルバーがサーバーに対して自身を認証する手段も提供しません。リゾルバーのID、または機密メカニズム。一部の実装では、準拠サーバーとのセキュリティアソシエーションが事前に確立されていれば、TSIGによるユーザー認証をサポートできますが、認証は通常、グローバルパブリックDNSでのクエリには必要ありません。ただし、DNSSECの既存の機能セットは、アプリケーションが従来DNSを使用していた方法のほとんどにセキュリティを提供するには十分です。 DNSSEC（[RFC4033]および関連する仕様）の導入は心から奨励されています。このドキュメントでは、セキュリティで保護されたDNS動的更新[RFC3007]の実装、展開、または使用を妨げることを意図したものはありませんが、このドキュメントでは、DNS内の大きなデータをセクション3.2.1のガイダンスに従って処理することを推奨しています。
Internet Architecture Board Members at the time this document was approved were:
このドキュメントが承認された時点のインターネットアーキテクチャボードメンバーは次のとおりです。
Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Spencer Dawkins Joel Halpern Russ Housley David Kessens Danny McPherson Jon Peterson Dave Thaler Hannes Tschofenig
バーナードアボバジャリアルコマルクブランシェロスカロンアリッサクーパースペンサードーキンスジョエルハルパーンラスハウズリーデビッドケセンスダニーマクファーソンジョンピーターソンデイブターラーハネスチョーフェニグ
The IAB appreciates the comments and often spirited disagreements of Eric Osterweil, John Levine, Stephane Bortzmeyer, Ed Lewis, Dave Crocker, Ray Bellis, Lawrence Conroy, Ran Atkinson, Patrik Faltstrom, and Eliot Lear.
IABは、Eric Osterweil、John Levine、Stephane Bortzmeyer、Ed Lewis、Dave Crocker、Ray Bellis、Lawrence Conroy、Ran Atkinson、Patrik Faltstrom、およびEliot Learのコメントとしばしば明るい意見の相違を高く評価しています。
[DNS-REDIRECT] Creighton, T., Griffiths, C., Livingood, J., and R. Weber, "DNS Redirect Use by Service Providers", Work in Progress, October 2010.
[DNS-REDIRECT] Creighton、T.、Griffiths、C.、Livingood、J.、and R. Weber、 "DNS Redirect Use by Service Providers"、Work in Progress、2010年10月。
[EDNS-CLIENT-IP] Contavalli, C., van der Gaast, W., Leach, S., and D. Rodden, "Client IP information in DNS requests", Work in Progress, May 2010.
[EDNS-CLIENT-IP] Contavalli、C.、van der Gaast、W.、Leach、S。、およびD. Rodden、「DNS要求のクライアントIP情報」、Work in Progress、2010年5月。
[EDNS-OPT-CODE] Kaplan, H., Walter, R., Gorman, P., and M. Maharishi, "EDNS Option Code for SIP and PSTN Source Reference Info", Work in Progress, October 2011.
[EDNS-OPT-CODE] Kaplan、H.、Walter、R.、Gorman、P。、およびM. Maharishi、「SIPおよびPSTNソース参照情報のEDNSオプションコード」、作業中、2011年10月。
[ENUM-Send-N] Bellis, R., "IANA Registrations for the 'Send-N' Enumservice", Work in Progress, June 2008.
[ENUM-Send-N] Bellis、R。、「「Send-N」EnumserviceのIANA登録」、作業中、2008年6月。
[ENUM-UNUSED] Stastny, R., Conroy, L., and J. Reid, "IANA Registration for Enumservice UNUSED", Work in Progress, March 2008.
[ENUM-UNUSED] Stastny、R.、Conroy、L。、およびJ. Reid、「IANA Registration for Enumservice UNUSED」、作業中、2008年3月。
[HARD-PROBLEM] Barnes, R. and P. Saint-Andre, "High Assurance Re-Direction (HARD) Problem Statement", Work in Progress, July 2010.
[ハード問題]バーンズ、R。およびP.サンタンドレ、「高保証再方向付け（HARD）問題ステートメント」、進行中の作業、2010年7月。
[Lindsay] Lindsay, G., "DNSSEC and DNS Amplification Attacks", April 2012.
[Lindsay] Lindsay、G。、「DNSSEC and DNS Amplification Attacks」、2012年4月。
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", RFC 882, November 1983.
[RFC0882] Mockapetris、P。、「ドメイン名：概念と機能」、RFC 882、1983年11月。
[RFC0883] Mockapetris, P., "Domain names: Implementation specification", RFC 883, November 1983.
[RFC0883] Mockapetris、P。、「ドメイン名：実装仕様」、RFC 883、1983年11月。
[RFC0974] Partridge, C., "Mail routing and the domain system", STD 10, RFC 974, January 1986.
[RFC0974]パートリッジ、C。、「メールルーティングとドメインシステム」、STD 10、RFC 974、1986年1月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC1464] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary String Attributes", RFC 1464, May 1993.
[RFC1464]ローゼンバウム、R。、「ドメインネームシステムを使用して任意の文字列属性を格納する」、RFC 1464、1993年5月。
[RFC1530] Malamud, C. and M. Rose, "Principles of Operation for the TPC.INT Subdomain: General Principles and Policy", RFC 1530, October 1993.
[RFC1530] Malamud、C。およびM. Rose、「TPC.INTサブドメインの運用原則：一般原則およびポリシー」、RFC 1530、1993年10月。
[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995.
[RFC1794] Brisco、T。、「DNS Support for Load Balancing」、RFC 1794、1995年4月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[RFC1995]太田雅明、「DNSの増分ゾーン転送」、RFC 1995、1996年8月。
[RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.
[RFC2052] Gulbrandsen、A。およびP. Vixie、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2052、1996年10月。
[RFC2168] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997.
[RFC2168] Daniel、R。およびM. Mealling、「ドメインネームシステムを使用したUniform Resource Identifiersの解決」、RFC 2168、1997年6月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「Clarifications to the DNS Specification」、RFC 2181、1997年7月。
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, August 1998.
[RFC2397] Masinter、L。、「「データ」URLスキーム」、RFC 2397、1998年8月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671] Vixie、P。、「DNSの拡張メカニズム（EDNS0）」、RFC 2671、1999年8月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「HTTP over TLS」、RFC 2818、2000年5月。
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000.
[RFC2826] Internet Architecture Board、「IAB Technical Comment on the Unique DNS Root」、RFC 2826、2000年5月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845] Vixie、P.、Gudmundsson、O.、Eastlake 3rd、D。、およびB. Wellington、「DNSの秘密鍵トランザクション認証（TSIG）」、RFC 2845、2000年5月。
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000.
[RFC2915] Mealling、M。およびR. Daniel、「The Naming Authority Pointer（NAPTR）DNS Resource Record」、RFC 2915、2000年9月。
[RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[RFC2916] Faltstrom、P。、「E.164番号とDNS」、RFC 2916、2000年9月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B。、「Secure Domain Name System（DNS）Dynamic Update」、RFC 3007、2000年11月。
[RFC3261] 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.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263] Rosenberg、J。およびH. Schulzrinne、「Session Initiation Protocol（SIP）：Locating SIP Servers」、RFC 3263、2002年6月。
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3401] Mealling、M。、「Dynamic Delegation Discovery System（DDDS）Part One：The Comprehensive DDDS」、RFC 3401、2002年10月。
[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[RFC3402] Mealling、M。、「Dynamic Delegation Discovery System（DDDS）Part Two：The Algorithm」、RFC 3402、2002年10月。
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[RFC3403] Mealling、M。、「Dynamic Delegation Discovery System（DDDS）Part Three：The Domain Name System（DNS）Database」、RFC 3403、2002年10月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596] Thomson、S.、Huitema、C.、Ksinant、V.、およびM. Souissi、「DNS Extensions to Support IP Version 6」、RFC 3596、2003年10月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、2005年3月。
[RFC4367] Rosenberg, J., Ed., and IAB, "What's in a Name: False Assumptions about DNS Names", RFC 4367, February 2006.
[RFC4367] Rosenberg、J.、Ed。、およびIAB、「What's in a Name：False Assumptions about DNS Names」、RFC 4367、2006年2月。
[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name System (DNS)", RFC 4398, March 2006.
[RFC4398] Josefsson、S.、「証明書のドメインネームシステム（DNS）への保存」、RFC 4398、2006年3月。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732] Handley、M.、Ed。、Rescorla、E.、Ed。、およびIAB、「インターネットサービス拒否の考慮事項」、RFC 4732、2006年12月。
[RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", RFC 4985, August 2007.
[RFC4985] Santesson、S。、「Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name」、RFC 4985、2007年8月。
[RFC5486] Malas, D., Ed., and D. Meyer, Ed., "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009.
[RFC5486] Malas、D。、編、およびD. Meyer、編、「マルチメディア相互接続（SPEERMINT）用語のセッションピアリング」、RFC 5486、2009年3月。
[RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch, Ed., "Design Choices When Expanding the DNS", RFC 5507, April 2009.
[RFC5507] IAB、Faltstrom、P。、編、Austein、R。、編、およびP. Koch、編、「DNSを拡張するときの設計の選択」、RFC 5507、2009年4月。
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010.
[RFC5922] Gurbani、V.、Lawrence、S。、およびA. Jeffrey、「Session Initiation Protocol（SIP）のドメイン証明書」、RFC 5922、2010年6月。
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011.
[RFC6055] Thaler、D.、Klensin、J。、およびS. Cheshire、「IAB Thoughts on Encodings for Internationalized Domain Names」、RFC 6055、2011年2月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、2011年3月。
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269] Ford、M.、Ed。、Boucadair、M.、Durand、A.、Levis、P.、and P. Roberts、 "Issues with IP Address Sharing"、RFC 6269、June 2011。
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[RFC6376] Crocker、D。、編、Hansen、T。、編、およびM. Kucherawy、編、「DomainKeys Identified Mail（DKIM）Signatures」、RFC 6376、2011年9月。
[RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)", RFC 6394, October 2011.
[RFC6394] Barnes、R。、「名前付きエンティティのDNSベースの認証（DANE）の使用例と要件」、RFC 6394、2011年10月。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013.
[RFC6763] Cheshire、S。およびM. Krochmal、「DNSベースのサービスディスカバリ」、RFC 6763、2013年2月。
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
[RFC6891] Damas、J.、Graff、M。、およびP. Vixie、「DNSの拡張メカニズム（EDNS（0））」、STD 75、RFC 6891、2013年4月。
[URI-RR] Faltstrom, P. and O. Kolkman, "The Uniform Resource Identifier (URI) DNS Resource Record", Work in Progress, July 2013.
[URI-RR] Faltstrom、P。およびO. Kolkman、「The Uniform Resource Identifier（URI）DNS Resource Record」、Work in Progress、2013年7月。
Authors' Addresses
著者のアドレス
Jon Peterson NeuStar, Inc.
Jon Peterson NeuStar、Inc.
EMail: jon.peterson@neustar.biz
Olaf Kolkman NLnet Labs
Olaf Kolkman NLnet Labs
EMail: olaf@nlnetlabs.nl
Hannes Tschofenig Nokia Siemens Networks
Hannes Tschofenig Nokia Siemens Networks
EMail: Hannes.Tschofenig@gmx.net
Bernard Aboba Skype
バーナードアボバスカイプ
EMail: Bernard_aboba@hotmail.com