Network Working Group                                                IAB
Request for Comments: 5507                             P. Faltstrom, Ed.
Category: Informational                                  R. Austein, Ed.
                                                            P. Koch, Ed.
                                                              April 2009
        
                 Design Choices When Expanding the DNS
        

Status of This Memo

このメモのステータス

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書では、BCP 78と、この文書(http://trustee.ietf.org/license-info)の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。

Abstract

抽象

This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution.

このノートは、新しいアプリケーションのための新しいデータでDNSを拡張する方法について説明します。 DNS拡張の議論は、あまりにも頻繁にTXTリソースレコードタイプの再利用に焦点を当てます。この文書では、DNSを拡張するために異なるメカニズムを一覧表示し、新しいDNSリソースレコードの種類を使用することが最善の解決策であると結論づけています。

Table of Contents

目次

   1. Introduction ....................................................3
   2. Background ......................................................4
   3. Extension Mechanisms ............................................5
      3.1. Place Selectors inside the RDATA of Existing
           Resource Record Types ......................................5
      3.2. Add a Prefix to the Owner Name .............................6
      3.3. Add a Suffix to the Owner Name .............................7
      3.4. Add a New Class ............................................8
      3.5. Add a New Resource Record Type .............................8
   4. Zone Boundaries are Invisible to Applications ...................9
   5. Why Adding a New Resource Record Type Is the Preferred
      Solution .......................................................10
   6. Conclusion and Recommendation ..................................14
   7. Creating a New Resource Record Type ............................14
   8. Security Considerations ........................................15
   9. Acknowledgements ...............................................15
   10. IAB Members at the Time of This Writing .......................16
   11. References ....................................................16
      11.1. Normative References .....................................16
      11.2. Informative References ...................................16
        
1. Introduction
1. はじめに

The DNS stores multiple categories of data. The two most commonly used categories are infrastructure data for the DNS system itself (NS and SOA Resource Records) and data that have to do with mappings between domain names and IP addresses (A, AAAA, and PTR Resource Records). There are other categories as well, some of which are tied to specific applications like email (MX Resource Records), while others are generic Resource Record Types used to convey information for multiple protocols (SRV and NAPTR Resource Records).

DNSは、データの複数のカテゴリを格納します。二つの最も一般的に使用されるカテゴリは、ドメイン名とIPアドレス(A、AAAA、およびPTRリソースレコード)の間のマッピングを行う必要があるDNSシステム自体(NSおよびSOAリソースレコード)およびデータのためのインフラデータです。他の人が複数のプロトコル(SRVとNAPTRリソースレコード)のための情報を伝えるために使用される一般的なリソースレコードのタイプしている間、他のカテゴリでは、電子メール(MXリソースレコード)のような特定のアプリケーションに関連付けられているそのうちのいくつかに、同様にあります。

When storing data in the DNS for a new application, the goal must be to store data in such a way that the application can query for the data it wants, while minimizing both the impact on existing applications and the amount of extra data transferred to the client. This implies that a number of design choices have to be made, where the most important is to ensure that a precise selection of what data to return must be made already in the query. A query consists of a triple: {Owner (or name), Resource Record Class, Resource Record Type}.

新しいアプリケーションのためのDNSにデータを格納する場合、既存のアプリケーションへの影響に移し、余分なデータの量の両方を最小限に抑えながら、ゴールは、アプリケーションが望んでいるデータを照会できるようにデータを格納することでなければなりませんクライアント。これは、最も重要なのは、データが返すものの正確な選択は、クエリですでに行われなければならないことを保証するために、ここでの設計の選択肢の数は、行わなければならないことを意味します。クエリは、三重からなる:{所有者(または名前)、リソースレコードクラス、リソースレコードタイプ}。

Historically, extending the DNS to store application data tied to a domain name has been done in different ways at different times. MX Resource Records were created as a new Resource Record Type specifically designed to support electronic mail. SRV records are a generic type that use a prefixing scheme in combination with a base domain name. NAPTR records add selection data inside the RDATA. It is clear that the methods used to add new data types to the DNS have been inconsistent, and the purpose of this document is to attempt to clarify the implications of each of these methods, both for the applications that use them and for the rest of the DNS.

歴史的には、ドメイン名に関連付けられたアプリケーションデータを格納するためにDNSを拡張することは、異なる時間に異なる方法で行われてきました。 MXリソースレコードは、具体的には、電子メールをサポートするために設計された新しいリソースレコードの種類として作成されました。 SRVレコードは、基本ドメイン名との組み合わせでプレフィックススキームを使用する一般的なタイプです。 NAPTRレコードはRDATA内部の選択データを追加します。それらを使用するアプリケーションのための残りのための両方、DNSに新しいデータ型を追加するために使用される方法は、一貫していない、と本書の目的は、これらの方法のそれぞれの意味を明確にしようと試みることであることは明らかですDNS。

This document talks extensively about use of DNS wildcards. Many people might think use of wildcards is not something that happens today. In reality though, wildcards are in use, especially for certain application-specific data such as MX Resource Records. Because of this, the choice has to be made with the existence of wildcards in mind.

この文書では、DNSのワイルドカードの使用について幅広く語っています。多くの人々は、ワイルドカードの使用が今日起こるものではありませんと思うかもしれません。現実にかかわらず、ワイルドカードは、特に、MXリソースレコードなど、特定のアプリケーション固有のデータのために、使用されています。このため、選択は心の中でワイルドカードの存在で行うことがあります。

Another overall issue that must be taken into account is what the new data in the DNS are to describe. In some cases, they might be completely new data. In other cases, they might be metadata tied to data that already exist in the DNS. Examples of new data are key information for the Secure SHell (SSH) Protocol and data used for authenticating the sender of email messages (metadata tied to MX Resource Records). If the new data are tied to data that already exist in the DNS, an analysis should be made as to whether having (for example) address records and SSH key information in different

考慮に入れなければならないもう一つの全体的な問題は、DNSで新しいデータが記述しているものです。いくつかのケースでは、彼らは完全に新しいデータであるかもしれません。他の例では、彼らはすでにDNSに存在するデータに関連付けられたメタデータであるかもしれません。新しいデータの例としては、(MXリソースレコードに結びついたメタデータ)の電子メールメッセージの送信者を認証するために使用されるセキュアシェル(SSH)プロトコルおよびデータのための重要な情報です。新しいデータが既にDNSに存在するデータに関連付けられている場合、分析は、様々に(例えば)アドレスレコードとSSHキー情報を有するか否かが判断されるべきです

DNS zones is a problem or if it is a bonus, and if it is a problem, whether the specification must require all of the related data to be in the same zone. One specific difference between having the records in the same zone or not has to do with maintenance of the records. If they are in the same zone, the same maintainer (from a DNS perspective) manages the two records. Specifically, they must be signed with the same DNSSEC keys if DNSSEC is in use.

DNSゾーン仕様が同じゾーンにあるように関連するすべてのデータを必要としなければならないかどうか、問題があるか、それはボーナスであれば、それは問題である場合。同じゾーン内のレコードを持つかどうかとの間の1つの具体的な違いは、記録の維持に関係しています。彼らは同じゾーンにある場合、(DNSの観点から)同じメンテナは二つのレコードを管理します。 DNSSECが使用されている場合は特に、彼らは同じDNSSECキーで署名されなければなりません。

This document does not talk about what one should store in the DNS. It also doesn't discuss whether the DNS should be used for service discovery, or whether the DNS should be used for storage of data specific to the service. In general, the DNS is a protocol that, apart from holding metadata that makes the DNS itself function (NS, SOA, DNSSEC Resource Record Types, etc.), only holds references to service locations (SRV, NAPTR, A, AAAA Resource Record Types) -- though there are exceptions, such as MX Resource Records.

この文書では、1つのDNSに格納すべきかについて話しません。また、DNSはサービス検出のために使用すべきかどうか議論していない、またはDNSかのサービスに固有のデータを格納するために使用すべきです。一般に、DNSは離れDNS自体の機能(NS、SOA、DNSSECリソースレコードタイプ、等)を行うメタデータを保持してから、唯一のサービスロケーション(SRV、NAPTR、A、AAAAリソースレコードへの参照を保持し、プロトコルでありますタイプ) - などMXリソースレコードなどの例外が、ありますが。

2. Background
2.背景

See RFC 5395 [RFC5395] for a brief summary of the DNS query structure. Readers interested in the full story should start with the base DNS specification in RFC 1035 [RFC1035] and continue with the various documents that update, clarify, and extend the base specification.

DNSクエリの構造の概要については、RFC 5395 [RFC5395]を参照してください。完全な話に興味のある読者は、RFC 1035 [RFC1035]で基本DNS仕様に開始し、更新は、明確に様々な文書を継続し、基本仕様を拡張する必要があります。

When composing a DNS query, the parameters used by the protocol are a {owner, class, type} triple. Every Resource Record matching such a triple is said to belong to the same Resource Record Set (RRSet), and the whole RRSet is always returned to the client that queries for it. Splitting an RRSet is a protocol violation (sending a partial RRSet, not truncating the DNS response), because it can result in coherency problems with the DNS caching mechanism. See Section 5 of [RFC2181] for more information.

DNSクエリを作成するとき、プロトコルによって使用されるパラメータは、トリプル{所有者、クラス、タイプ}です。すべてのリソースレコードは、そのようなトリプルは同じリソースレコードセット(資源レコード集合)に属していると言われているマッチング、全体の資源レコード集合は常にそれのために照会し、クライアントに返されます。それはDNSキャッシング機構とコヒーレンシ問題をもたらすことができるので、資源レコード集合を分割することは、プロトコル違反(DNS応答を切り捨てていない、部分的な資源レコード集合を送信する)です。詳細については、[RFC2181]のセクション5を参照してください。

Some discussions around extensions to the DNS include arguments around MTU size. Note that most discussions about DNS and MTU size are about the size of the whole DNS packet, not about the size of a single RRSet.

DNSへの拡張の周りのいくつかの議論がMTUサイズの周りの引数を含めます。 DNSおよびMTUサイズに関するほとんどの議論がない、単一の資源レコード集合の大きさについては、全体のDNSパケットのサイズであることに注意してください。

Almost all DNS query traffic is carried over UDP, where a DNS message must fit within a single UDP packet. DNS response messages are almost always larger than DNS query messages, so message size issues are almost always about responses, not queries. The base DNS specification limits DNS messages over UDP to 512 octets; EDNS0 [RFC2671] specifies a mechanism by which a client can signal its willingness to receive larger responses, but deployment of EDNS0 is not universal, in part because of firewalls that block fragmented UDP packets or EDNS0. If a response message won't fit in a single packet, the name server returns a truncated response, at which point the client may retry using TCP. DNS queries over TCP are not subject to this length limitation, but TCP imposes significantly higher per-query overhead on name servers than UDP. It is also the case that the policies in deployed firewalls far too often are such that they block DNS over TCP, so using TCP might not in reality be an option. There are also risks (although possibly small) that a change of routing while a TCP flow is open creates problems when the DNS servers are deployed in an anycast environment.

ほとんどすべてのDNSクエリトラフィックは、DNSメッセージは、単一のUDPパケット内に収まらなければならないUDP上で実行されます。 DNS応答メッセージは、ほとんどの場合、DNSクエリーメッセージよりも大きくなっているので、メッセージのサイズの問題は応答ではなく、クエリについて、ほとんど常にあります。 512個のオクテットにUDPを介して基地DNS仕様限界のDNSメッセージ。 EDNS0 [RFC2671]は、クライアントがより大きな応答を受信するために、その意欲を合図できるメカニズムを指定しますが、EDNS0の展開があるため、断片化UDPパケットまたはEDNS0をブロックするファイアウォールの一部では、普遍的ではありません。応答メッセージは、単一のパケットに収まらない場合は、ネームサーバは、クライアントがTCPを使用して再試行することがあり、その時点で切り捨て応答を返します。 TCP上のDNSクエリは、この長さの制限の対象ではありませんが、TCPはUDPよりもネームサーバ上の有意に高かっあたりのクエリのオーバーヘッドを課します。また、展開のファイアウォール内のポリシーは、あまりにも多くの場合、彼らはTCPが、現実にはオプションではないかもしれません使用して、TCP上のDNSをブロックするようになっている場合です。 DNSサーバは、エニーキャスト環境に配備されたときにTCPフローが開いている間のルーティングの変更が問題を作成すること(おそらく小さなが)リスクもあります。

3. Extension Mechanisms
3.拡張メカニズム

The DNS protocol is intended to be extensible to support new kinds of data. This section examines the various ways in which this sort of extension can be accomplished.

DNSプロトコルは、データの新しい種類をサポートするために拡張可能であることを意図しています。このセクションでは、拡張機能のこの種を達成することができるさまざまな方法を検討します。

3.1. Place Selectors inside the RDATA of Existing Resource Record Types
3.1. 既存のリソースレコードのタイプのRDATA内部置きセレクタ

For a given query name, one might choose to have a single RRSet (all Resource Records sharing the same {owner, class, type} triple) shared by multiple applications, and have the different applications use selectors within the Resource Record data (RDATA) to determine which records are intended for which applications. This sort of selector mechanism is usually referred to "subtyping", because it is in effect creating an additional type subsystem within a single DNS Resource Record Type.

指定されたクエリ名、一つは、複数のアプリケーションによって共有される単一の資源レコード集合(同じ{所有者、クラス、タイプ}三重を共有するすべてのリソースレコード)を有するように選択し、異なるアプリケーションがリソースレコードデータ(RDATA)内のセレクタを使用している場合がありますその用途のために意図されているレコードを決定します。それは、単一のDNSリソースレコードの種類内の追加の型サブシステムを作成する効果であるため、セレクタ機構のこの種は通常、「サブタイプ」と呼ばれます。

Examples of subtyping include NAPTR Resource Records [RFC3761] and the original DNSSEC KEY Resource Record Type [RFC2535] (which was later updated by RFC 3445 [RFC3445], and obsoleted by RFC 4033 [RFC4033], RFC 4034 [RFC4034] and RFC 4035 [RFC4035]).

サブタイプの例は、NAPTRリソースレコード[RFC3761]と元のDNSSEC KEYリソースレコードタイプ[RFC2535](後RFC 3445 [RFC3445]で更新され、RFC 4033によって廃止された[RFC4033]、RFC 4034 [RFC4034]及びRFC 4035を含みます[RFC4035])。

All DNS subtyping schemes share a common weakness: with subtyping schemes, it is impossible for a client to query for just the data it wants. Instead, the client must fetch the entire RRSet, then select the Resource Records in which it is interested. Furthermore, since DNSSEC signatures operate on complete RRSets, the entire RRSet must be re-signed if any Resource Record in it changes. As a result, each application that uses a subtyped Resource Record incurs higher overhead than any of the applications would have incurred had they not been using a subtyping scheme. The fact the RRSet is always passed around as an indivisible unit increases the risk the RRSet will not fit in a UDP packet, which in turn increases the risk that the client will have to retry the query with TCP, which substantially increases the load on the name server. More precisely: having one query fail over to TCP is not a big deal, but since the typical ratio of clients to servers in today's deployed DNS is very high, having a substantial number of DNS messages fail over to TCP may cause the queried name servers to be overloaded by TCP overhead.

すべてのDNSのサブタイピング方式は、共通の弱点を共有:クライアントは、それが望んでいるだけでデータを照会するためにサブタイピングスキームで、それは不可能です。代わりに、クライアントは、それが興味を持っているリソースレコードを選択し、全体の資源レコード集合をフェッチする必要があります。 DNSSEC署名が完了RRセットで動作するので、その中の任意のリソースレコードを変更した場合さらに、全体の資源レコード集合は再署名しなければなりません。その結果、サブタイプリソースレコードを使用する各アプリケーションは、アプリケーションのいずれかが、彼らはサブタイピング方式を使用していなかった被っていたよりも高いオーバーヘッドが発生します。資源レコード集合は常に不可分の単位として周りに渡された事実は、資源レコード集合が順番にクライアントが、実質的に負荷が増大TCP、とのクエリを再試行しなければならないことのリスクを増大させ、UDPパケットに収まらないリスクを高めますサーバーに名前を付けます。より正確には:1つのクエリはTCPにフェールオーバーしたことは大したことではありませんが、今日の展開DNS内のサーバーへのクライアントの典型的な比率が非常に高いため、DNSメッセージのかなりの数はTCPにフェールオーバーしたことは、照会のネームサーバーを引き起こす可能性がありTCPのオーバーヘッドによって過負荷にします。

Because of the size limitations, using a subtyping scheme to list a large number of services for a single domain name risks triggering truncation and fallback to TCP, which may in turn force the zone administrator to announce only a subset of available services.

サイズ制限のため、切り捨てをトリガする単一のドメイン名のリスクのために多数のサービスを一覧表示し、TCPにフォールバック、順番に利用可能なサービスのサブセットだけを発表するゾーン管理者を強制する可能性があるためにサブタイピング方式を使用。

3.2. Add a Prefix to the Owner Name
3.2. 所有者名にプレフィックスを追加

By adding an application-specific prefix to a domain name, we get a different {owner, class, type} triple, and therefore a different RRSet. One problem with adding prefixes has to do with wildcards, especially if one has records like:

ドメイン名に、アプリケーション固有のプレフィックスを追加することによって、我々は、三重異なる{所有者、クラス、タイプ}、したがって異なる資源レコード集合を得ます。接頭辞を追加することの一つの問題は、1つのようなレコードを持っている場合は特に、ワイルドカードに関係しています。

*.example.com. IN MX 1 mail.example.com.

* .example.comと。 MX 1 mail.example.com、IN。

and one wants records tied to those names. Suppose one creates the prefix "_mail". One would then have to say something like:

一つは、それらの名前に関連付けられたレコードを望んでいます。 1は、接頭辞「_mail」を作成したとします。一つは、その後のようなものを言わなければならないでしょう。

_mail.*.example.com. IN X-FOO A B C D

_mail。*。example.com。 X-FOO A B C D IN

but DNS wildcards only work with the "*" as the leftmost token in the domain name (see also RFC 4592 [RFC4592]).

しかし、DNSのワイルドカードは、ドメイン名のみの左端のトークン(また、RFC 4592 [RFC4592]を参照)として「*」と連携します。

There have been proposals to deal with the problem that DNS wildcards are always terminal records. These proposals introduce an additional set of trade-offs that would need to be taken into account when assessing which extension mechanism to choose. Aspects of extra response time needed to perform the extra queries, costs of pre-calculation of possible answers, or the costs induced to the system as a whole come to mind. At the time of writing, none of these proposals has been published as Standards Track RFCs.

ワイルドカードは、常にターミナル記録であるDNSの問題に対処するための提案がなされてきました。これらの提案は、選択するどの拡張メカニズムを評価する際に考慮される必要があろうトレードオフの追加セットをご紹介します。余分なクエリを実行するために必要な余分な応答時間の態様は、可能な答え、またはシステムに誘導し、コストの事前計算のコストは全体が頭に浮かぶよう。執筆時点では、これらの提案はいずれも標準化過程のRFCとして公開されていません。

Even when a specific prefix is chosen, the data will still have to be stored in some Resource Record Type. This Resource Record Type can be either a new Resource Record Type or an existing Resource Record Type that has an appropriate format to store the data. One also might need some other selection mechanism, such as the ability to distinguish between the records in an RRSet, given they have the same Resource Record Type. Because of this, one needs to both register a unique prefix and define what Resource Record Type is to be used for this specific service.

特定の接頭辞を選択した場合でも、データがまだいくつかのリソースレコードの種類に格納する必要があります。このリソースレコードの種類は、新しいリソースレコードの種類やデータを格納するための適切な形式を持っている既存のリソースレコードの種類のいずれかになります。一つは、また、彼らは同じリソースレコードの種類を持っている与えられた、など資源レコード集合内のレコードを区別する機能など、いくつかの他の選択機構が必要になる場合があります。このため、一つはユニークなプレフィックスを登録し、リソースレコードの種類は、この特定のサービスに使用するかを定義することの両方が必要です。

If the record has some relationship with another record in the zone, the fact that the two records can be in different zones might have implications on the trust the application has in the records. For example:

レコードは、ゾーン内の他のレコードとの何らかの関係を持っている場合は、2つのレコードが異なるゾーンにあることができるという事実は、アプリケーションがレコードに持っている信頼に影響を与える可能性があります。例えば:

example.com. IN MX 10 mail.example.com. _foo.example.com. IN X-BAR "metadata for the mail service"

example.com。 MX 10 mail.example.com、IN。 _foo.example.com。 X-BAR「メールサービスのメタデータ」IN

In this example, the two records might be in two different zones, and as a result might be administered by two different organizations, and signed by two different entities when using DNSSEC. For these two reasons, using a prefix has recently become a very interesting solution for many protocol designers. In some cases, e.g., DomainKeys Identified Mail Signatures [RFC4871], TXT records have been used. In others, such as SRV, entirely new Resource Record Types have been added.

この例では、2つのレコードは、二つの異なるゾーンにあるかもしれない、その結果、二つの異なる組織によって管理される場合がある、とDNSSECを使用するときに二つの異なるエンティティによって署名されました。これらの二つの理由から、接頭辞を使用すると、最近の多くのプロトコルの設計者にとって非常に興味深いソリューションとなっています。いくつかの場合において、例えば、ドメインキーが特定のメール署名[RFC4871]は、TXTレコードが使用されてきました。このようSRVなど他では、完全に新しいリソースレコードのタイプが追加されました。

3.3. Add a Suffix to the Owner Name
3.3. 所有者名にサフィックスを追加

Adding a suffix to a domain name changes the {owner, class, type} triple, and therefore the RRSet. In this case, since the query name can be set to exactly the data one wants, the size of the RRSet is minimized. The problem with adding a suffix is that it creates a parallel tree within the IN class. Further, there is no technical mechanism to ensure that the delegation for "example.com" and "example.com._bar" are made to the same organization. Furthermore, data associated with a single entity will now be stored in two different zones, such as "example.com" and "example.com._bar", which, depending on who controls "_bar", can create new synchronization and update authorization issues.

ドメイン名にサフィックスを追加すると、トリプル{所有者、クラス、タイプ}、したがって資源レコード集合を変更します。この場合、クエリ名いるので、正確にデータ1が資源レコード集合のサイズが最小化され、望んでいるように設定することができます。サフィックスを追加することに伴う問題は、それがINクラス内のパラレルツリーを作成することです。さらに、「example.com」のための代表団と「example.com._bar」が同じ組織に行われていることを確実にするために技術的なメカニズムはありません。さらに、単一のエンティティに関連付けられたデータは、現在、「_bar」を制御する人に応じて、新しい同期および更新権限を作成することができ、「example.com」と「example.com._bar」として、二つの異なる領域に格納されます問題。

One way of solving the administrative issues is by using the DNAME Resource Record Type specified in RFC 2672 [RFC2672].

管理上の問題を解決する1つの方法は、RFC 2672 [RFC2672]で指定されたDNAMEリソースレコードタイプを使用することです。

Even when using a different name, the data will still have to be stored in some Resource Record Type that has an appropriate format to store the data. This implies that one might have to mix the prefix based selection mechanism with some other mechanism so that the right Resource Record can be found out of many in a potential larger RRSet.

別の名前を使用する場合でも、データがまだデータを格納するための適切な形式を持っているいくつかのリソースレコードの種類に格納する必要があります。これは、1つは、右のリソースレコードは、潜在的に大きい資源レコード集合に多くの外に見つけることができるように、いくつかの他の機構をプレフィックスに基づく選択機構を混在させる必要がある場合がありますことを意味します。

In RFC 2163 [RFC2163] an infix token is inserted directly below the Top-Level Domain (TLD), but the result is equivalent to adding a suffix to the owner name (instead of creating a TLD, one is creating a second level domain).

RFC 2163に[RFC2163]インフィックストークンは直接トップレベルドメイン(TLD)の下に挿入されているが、結果は、所有者名にサフィックスを付加することと等価である(代わりにTLDを作成する、一つは第二レベルのドメインを作成しています) 。

3.4. Add a New Class
3.4. 新しいクラスを追加します。

DNS zones are class-specific in the sense that all the records in that zone share the same class as the zone's SOA record and the existence of a zone in one class does not guarantee the existence of the zone in any other class. In practice, only the IN class has ever seen widespread deployment, and the administrative overhead of deploying an additional class would almost certainly be prohibitive.

DNSゾーンは、そのゾーンを共有内のすべてのレコードは、ゾーンのSOAレコードと1クラスのゾーンの存在と同じクラスは他のクラスのゾーンが存在することを保証するものではないという意味で、クラス固有のものです。実際には、唯一のINクラスは、これまで広範囲の展開を見ていると、追加のクラスを展開する管理オーバーヘッドは、ほぼ確実に法外になります。

Nevertheless, one could, in theory, use the DNS class mechanism to distinguish between different kinds of data. However, since the DNS delegation tree (represented by NS Resource Records) is itself tied to a specific class, attempting to resolve a query by crossing a class boundary may produce unexpected results because there is no guarantee that the name servers for the zone in the new class will be the same as the name servers in the IN class. The MIT Hesiod system [Dyer87] used a scheme like this for storing data in the HS class, but only on a very small scale (within a single institution), and with an administrative fiat requiring that the delegation trees for the IN and HS trees be identical. The use of the HS class for such storage of non-sensitive data was, over time, replaced by use of the Lightweight Directory Access Protocol (LDAP) [RFC4511].

それにもかかわらず、1は、理論的には、異なる種類のデータを区別するためにDNSクラスメカニズムを使用することができます。しかし、(NSリソースレコードによって表される)DNS委任ツリー自体は保証がないため、予期しない結果が生じることがあり、クラスの境界を横断することによって、クエリを解決しようとすると、特定のクラスに関連付けられていますので、その中にゾーンのネームサーバ新しいクラスは、INクラスのネームサーバと同じになります。 MITヘシオドスシステムは[Dyer87]だけ非常に小規模で(単一施設内)、HSクラスのデータを格納するため、このようなスキームを使用し、管理フィアットで必要という点で、及びHSツリーの委任木同一です。非機密データのような貯蔵のためのHSクラスの使用は、時間をかけて、ライトウェイトディレクトリアクセスプロトコル(LDAP)[RFC4511]を使用することによって置き換えられました。

Even when using a different class, the data will still have to be stored in some Resource Record Type that has an appropriate format.

別のクラスを使用する場合でも、データがまだ適切な形式を持っているいくつかのリソースレコードの種類に格納する必要があります。

3.5. Add a New Resource Record Type
3.5. 新しいリソースレコードタイプを追加

When adding a new Resource Record Type to the system, entities in four different roles have to be able to handle the new Type:

システムに新しいリソースレコードの種類を追加する場合は、4つの異なる役割のエンティティは、新しいタイプを処理できる必要があります:

1. There must be a way to insert the new Resource Records into the zone at the Primary Master name server. For some server implementations, the user interface only accepts Resource Record Types that it understands (perhaps so that the implementation can attempt to validate the data). Other implementations allow the zone administrator to enter an integer for the Resource Record Type code and the RDATA in Base64 or hexadecimal encoding (or even as raw data). RFC 3597 [RFC3597] specifies a standard generic encoding for this purpose.

1.プライマリマスタネームサーバのゾーンに新しいリソースレコードを挿入する方法があるに違いありません。いくつかのサーバの実装では、ユーザーインターフェイスがのみ(実装はデータを検証しようとすることができるように、おそらく)それは理解できるリソースレコードのタイプを受け入れます。他の実装では、ゾーン管理者は、リソースレコードタイプコードとはBase64でRDATAまたは16進符号化(あるいは生データなど)のための整数を入力することを可能にします。 RFC 3597 [RFC3597]は、この目的のための標準的な一般的なエンコーディングを指定します。

2. A slave authoritative name server must be able to do a zone transfer, receive the data from some other authoritative name server, and serve data from the zone even though the zone includes records of unknown Resource Record Types. Historically, some implementations have had problems parsing stored copies of the zone file after restarting, but those problems have not been seen for a few years. Some implementations use an alternate mechanism (e.g., LDAP) to transfer Resource Records in a zone, and are primarily used within corporate environments; in this case, name servers must be able to transfer new Resource Record Types using whatever mechanism is used. However, today this alternative mechanism may not support unknown Resource Record Types. Hence, in Internet environments, unknown Resource Record Types are supported, but in corporate environments they are problematic.

2.スレーブ権威ネームサーバは、ゾーン転送を行うことができるいくつかの他の権威ネームサーバからデータを受信し、ゾーンが不明なリソースレコードのタイプのレコードが含まれていても、ゾーンからのデータを提供しなければなりません。歴史的に、いくつかの実装は、問題の解析には、再起動後に、ゾーンファイルのコピーを保存していたしましたが、これらの問題は、数年前から見られていません。いくつかの実装は、ゾーン内のリソースレコードを転送するための代替機構(例えば、LDAP)を使用し、主に企業環境内で使用されます。この場合には、ネームサーバは、メカニズムが使用されているものは何でも使用して、新しいリソースレコードのタイプを転送することができなければなりません。しかし、今日この代替メカニズムは不明なリソースレコードのタイプをサポートしていないかもしれません。そのため、インターネット環境では、未知のリソースレコードのタイプがサポートされていますが、企業環境では、彼らは問題があります。

3. A caching resolver (most commonly a recursive name server) will cache the records that are responses to queries. As mentioned in RFC 3597 [RFC3597], there are various pitfalls where a recursive name server might end up having problems.

3.キャッシュリゾルバ(最も一般的に再帰ネームサーバー)がクエリへの応答であるレコードをキャッシュします。 RFC 3597 [RFC3597]で述べたように、再帰ネームサーバに問題が終わるかもしれないさまざまな落とし穴があります。

4. The application must be able to get the RRSet with a new Resource Record Type. The application itself may understand the RDATA, but the resolver library might not. Support for a generic interface for retrieving arbitrary DNS Resource Record Types has been a requirement since 1989 (see Section 6.1.4.2 of [RFC1123]). Some stub resolver library implementations neglect to provide this functionality and cannot handle unknown Resource Record Types, but implementation of a new stub resolver library is not particularly difficult, and open source libraries that already provide this functionality are available.

4.アプリケーションが新しいリソースレコードの種類と資源レコード集合を取得することができなければなりません。アプリケーション自体はRDATAを理解するかもしれないが、リゾルバライブラリがない場合があります。任意のDNSリソースレコードのタイプを取得するための汎用インタフェースのサポートは([RFC1123]のセクション6.1.4.2を参照)を1989年以来の要件となっています。いくつかのスタブリゾルバライブラリの実装の怠慢は、この機能を提供するために、未知のリソースレコードのタイプを扱うことはできませんが、新しいスタブリゾルバライブラリの実装は、特に難しいことではない、とすでにこの機能を提供するオープンソースのライブラリが用意されています。

Historically, adding a new Resource Record Type has been very problematic. The review process has been cumbersome, DNS servers have not been able to handle new Resource Record Types, and firewalls have dropped queries or responses with Resource Record Types that are unknown to the firewall. This is, for example, one of the reasons the ENUM standard reuses the NAPTR Resource Record, a decision that today might have gone to creating a new Resource Record Type instead.

歴史的に、新しいリソースレコードの種類を追加することは非常に問題がありました。レビュープロセスが煩雑になっている、DNSサーバは、新しいリソースレコードのタイプを処理することができていない、とファイアウォールは、ファイアウォールに知られていないリソースレコードのタイプを使用してクエリまたは応答を落としています。これは、例えば、ENUM規格はNAPTRリソースレコード、今日は代わりに新しいリソースレコードの種類を作成してしまったかもしれないという決定を再利用する理由の一つです。

Today, there is a requirement that DNS software handle unknown Resource Record Types, and investigations have shown that software that is deployed, in general, does support it, except in some alternate mechanisms for transferring Resource Records such as LDAP, as noted above. Also, the approval process for new Resource Record Types has been updated [RFC5395] so the effort that is needed for various Resource Record Types is more predictable.

今日では、DNSソフトウェアハンドル不明なリソースレコードのタイプ、および調査は、一般的には、展開されているソフトウェアを示している要件があり、上述のように、LDAPなどのリソースレコードを転送するためのいくつかの代替機構を除いて、それをサポートしています。また、新しいリソースレコードのタイプのための承認プロセスは、[RFC5395]に更新されていますので、様々なリソースレコードのタイプのために必要とされる努力は、より予測可能です。

4. Zone Boundaries are Invisible to Applications
4.ゾーン境界は、アプリケーションには見えません

Regardless of the possible choices above, we have seen a number of cases where the application made assumptions about the structure of the namespace and the location where specific information resides. We take a small sidestep to argue against such approaches.

上記にかかわらず、可能な選択肢の、我々は、アプリケーションは、名前空間の構造と具体的な情報が存在する位置に関する仮定した場合の数を見ています。私たちは、このようなアプローチに反論するために、小さなサイドステップを取ります。

The DNS namespace is a hierarchy, technically speaking. However, this only refers to the way names are built from multiple labels. DNS hierarchy neither follows nor implies administrative hierarchy. Because of that, it cannot be assumed that data attached to a node in the DNS tree is valid for the whole subtree. Technically, there are zone boundaries partitioning the namespace, and administrative boundaries (or policy boundaries) may even exist elsewhere.

DNS名前空間は、技術的に言えば、階層です。しかし、これが唯一の名前が複数のラベルから構築されている方法を指します。 DNSの階層構造は、どちらも次のことも、管理階層を意味します。そのため、DNSツリー内のノードに接続されているデータは、サブツリー全体に対して有効であると仮定することはできません。技術的に、ゾーンの名前空間を区画する境界、および管理境界(またはポリシーの境界)があっても他の場所に存在してもよいです。

The false assumption has lead to an approach called "tree climbing", where a query that does not receive a positive response (either the requested RRSet was missing or the name did not exist) is retried by repeatedly stripping off the leftmost label (climbing towards the root) until the root domain is reached. Sometimes these proposals try to avoid the query for the root or the TLD level, but still this approach has severe drawbacks:

偽の仮定は(どちらかの要求資源レコード集合が欠落していたか、名前が存在しなかった)繰り返しに向けて登山(一番左のラベルを剥がしによって再試行される肯定応答を受信しない「木登り」と呼ばれるアプローチ、クエリにつながりましたルート)ルートドメインが到達するまで。時には、これらの提案は、ルートまたはTLDレベルのクエリを回避しようが、それでもこのアプローチは深刻な欠点があります。

o Technically, the DNS was built as a query-response tool without any search capability [RFC3467]. Adding the search mechanism imposes additional burden on the technical infrastructure, in the worst case on TLD and root name servers.

O技術的には、DNSは、任意の検索機能[RFC3467]なしクエリ応答ツールとして建設されました。検索メカニズムを追加すると、TLDおよびルートネームサーバ上の最悪の場合には、技術インフラに追加の負担を課します。

o For reasons similar to those outlined in RFC 1535 [RFC1535], querying for information in a domain outside the control of the intended entity may lead to incorrect results and may also put security at risk. Finding the exact policy boundary is impossible without an explicit marker, which does not exist at present. At best, software can detect zone boundaries (e.g., by looking for SOA Resource Records), but some TLD registries register names starting at the second level (e.g., CO.UK), and there are various other "registry" types at second, third, or other level domains that cannot be identified as such without policy knowledge external to the DNS.

O意図エンティティの制御外ドメインの情報を照会RFC 1535 [RFC1535]に概説されたものと同様の理由で、誤った結果を導くことができ、また危険にセキュリティを置いてもよいです。正確な政策の境界を見つけることは現時点では存在しない、明示的なマーカー、なしには不可能です。せいぜい、ソフトウェア(例えば、SOAリソースレコードを探すことにより)ゾーン境界を検出することができますが、一部のTLDレジストリは、(例えば、CO.UK)は、第2のレベルで始まる名前を登録し、第二に、様々な他の「レジストリ」のタイプがあり、 DNSに外部ポリシーに関する知識なしにそのように識別することができない第三の、または他のレベルドメイン。

To restate, the zone boundary is purely a boundary that exists in the DNS for administrative purposes, and applications should be careful not to draw unwarranted conclusions from zone boundaries. A different way of stating this is that the DNS does not support inheritance, e.g., an MX RRSet for a TLD will not be valid for any subdomain of that particular TLD.

言い換えるするには、ゾーンの境界は、純粋に管理上の目的のためにDNSに存在する境界である、およびアプリケーションは、ゾーン境界から不当な結論を引き出すしないように注意する必要があります。これを述べるの別の方法は、DNSの継承をサポートしていないということである、例えば、TLDのためのMX資源レコード集合は、その特定のTLDの任意のサブドメインに対して有効ではありません。

5. Why Adding a New Resource Record Type Is the Preferred Solution
5.新しいリソースレコードタイプを追加すると、優先ソリューションである理由

By now, the astute reader might be wondering what conclusions to draw from the issues presented so far. We will now attempt to clear up the reader's confusion by following the thought processes of a typical application designer who wishes to store data in the DNS. We'll show how such a designer almost inevitably hits upon the idea of just using a TXT Resource Record, why this is a bad thing, and why a new Resource Record Type should be allocated instead. We'll also explain how the reuse of an existing Resource Record, including TXT, can be made less harmful.

今では、賢明な読者は、これまでに提示問題から引くためにどのような結論を疑問に思われるかもしれません。私たちは今、DNSにデータを格納することを希望する典型的なアプリケーション設計者の思考プロセスに従うことで、読者の混乱を解消しようとします。私たちは、このような設計者は、ほぼ必然的にだけ、これは悪いことである理由TXTリソースレコードを使用して、なぜ新しいリソースレコードの種類ではなく、割り当てられるべきであるの考えに当たる方法を紹介します。また、TXTなどの既存のリソースレコードの再利用は、以下の有害行うことができる方法を説明します。

The overall problem with most solutions has to do with two main issues:

ほとんどのソリューションとの全体的な問題は、主に2つの問題と関係があります。

o No semantics to prevent collision with other use

他の用途との衝突を防止するためのセマンティクスがo

o Space considerations in the DNS message

DNSメッセージにO空間の考慮事項

A typical application designer is not interested in the DNS for its own sake, but rather regards it as a distributed database in which application data can be stored. As a result, the designer of a new application is usually looking for the easiest way to add whatever new data the application needs to the DNS in a way that naturally associates the data with a DNS name and does not require major changes to DNS servers.

典型的なアプリケーションの設計者は、自身のためにDNSに興味を持ってではなく、アプリケーションデータを格納することが可能な分散データベースとしてそれをみなします。その結果、新しいアプリケーションの設計者は通常、アプリケーションが自然にDNS名を使用してデータを関連付けし、DNSサーバに大きな変更を必要としない方法で、DNSに必要と新しいものは何でもデータを追加する最も簡単な方法を探しています。

As explained in Section 3.4, using the DNS class system as an extension mechanism is not really an option, and in fact, most users of the system don't even realize that the mechanism exists. As a practical matter, therefore any extension is likely to be within the IN class.

3.4節で説明したように、拡張メカニズムとして、DNSクラスシステムを使用することは本当にオプションではありませんし、実際には、システムのほとんどのユーザーがさえメカニズムが存在することを認識していません。実際問題として、したがって、任意の拡張子は、INクラス内である可能性が高いです。

Adding a new Resource Record Type is the technically correct answer from the DNS protocol standpoint (more on this below), but doing so requires some DNS expertise, due to the issues listed in Section 3.5. Consequently, this option is often rejected. Note that according to RFC 5395 [RFC5395], some Types require IETF Consensus, while others only require a specification.

新しいリソースレコードの種類を追加すると、DNSプロトコルの観点(以下この上より)から、技術的に正しい答えですが、これは、3.5節に記載された問題のため、いくつかのDNSの専門知識が必要です。そのため、このオプションは、多くの場合、拒否されます。他は唯一の仕様を必要としながら、RFC 5395 [RFC5395]によれば、いくつかのタイプは、IETFコンセンサスを必要とすることに留意されたいです。

There is a drawback to defining new RR types that is worth mentioning. The Resource Record Type (RRTYPE) is a 16-bit value and hence is a limited resource. In order to prevent hoarding the registry has a review-based allocation policy [RFC5395]; however, this may not be sufficient if extension of the DNS by addition of new RR types takes up significantly and the registry starts nearing completion. In that case, the trade-offs with respect to choosing an extension mechanism may need to change.

言及する価値がある新しいRRタイプを定義するには欠点があります。リソースレコードタイプ(RRTYPE)は、16ビット値であり、したがって、限られた資源です。レジストリを買いだめ防止するために、レビューに基づく割り当てポリシー[RFC5395]を有します。新しいRRタイプの添加によるDNSの拡張機能が大幅にアップかかり、レジストリが完成に近づいて開始した場合しかし、これは十分ではないかもしれません。その場合には、拡張機構を選択に対するトレードオフは、変更する必要があるかもしれません。

The application designer is thus left with the prospect of reusing some existing DNS Types within the IN class, but when the designer looks at the existing Types, almost all of them have well-defined semantics, none of which quite match the needs of the new application. This has not completely prevented proposals from reusing existing Resource Record Types in ways incompatible with their defined semantics, but it does tend to steer application designers away from this approach.

アプリケーション設計者は、このように、INクラス内のいくつかの既存のDNSタイプを再利用の見通しが残されているが、設計者は、既存のタイプを見ると、ほとんどすべてのはかなり新しいのニーズにマッチどれも意味を、明確に定義されています応用。これは完全に彼らの意味が定義された互換性のない方法で、既存のリソースレコードのタイプを再利用からの提案を妨げていないが、それは離れて、このアプローチからアプリケーション設計を操縦する傾向ありません。

For example, Resource Record Type 40 was registered for the SINK Resource Record Type. This Resource Record Type was discussed in the DNSIND working group of the IETF, and it was decided at the 46th IETF to not move the I-D forward to become an RFC because of the risk of encouraging application designers to use the SINK Resource Record Type instead of registering a new Resource Record Type, which would result in infeasibly large SINK RRsets.

たとえば、リソースレコードタイプ40はSINKリソースレコードの種類のために登録されました。このリソースレコードの種類は、IETFのDNSINDワーキンググループで議論し、それが原因SINKリソースレコードの種類を使用するようにアプリケーションの設計者を奨励する代わりに、リスクのRFCになるために前方にIDを移動しないために第46回IETFで決定されましたinfeasibly大SINKのRRセットにつながる新しいリソースレコードの種類を、登録します。

Eliminating all of the above leaves the TXT Resource Record Type in the IN class. The TXT RDATA format is free form text, and there are no existing semantics to get in the way. Some attempts have been made, for example, in [DNSEXT-DNS-SD], to specify a structured format for TXT Resource Record Types, but no such attempt has reached RFC status. Furthermore, the TXT Resource Record can obviously just be used as a bucket in which to carry around data to be used by some higher-level parser, perhaps in some human-readable programming or markup language. Thus, for many applications, TXT Resource Records are the "obvious" choice. Unfortunately, this conclusion, while understandable, is also problematic, for several reasons.

上記のすべてを排除することのINクラスにTXTリソースレコードの種類を残します。 TXT RDATAフォーマットは自由形式のテキストで、邪魔になるために既存のセマンティクスはありません。いくつかの試みは、TXTリソースレコードのタイプのための構造化されたフォーマットを指定するには、[DNSEXT-DNS-SD]で、例えば、行われているが、そのような試みは、RFCの状態に達していません。また、TXTリソースレコードは明らかにだけおそらくいくつかの人間が読み取り可能なプログラムまたはマークアップ言語では、いくつかのより高いレベルのパーサによって使用されるデータを持ち歩くにバケットとして使用することができます。このように、多くのアプリケーションのために、TXTリソースレコードは、「明白な」選択です。残念ながら、この結論は、理解しながら、いくつかの理由のために、また問題があります。

The first reason why TXT Resource Records are not well suited to such use is precisely what makes them so attractive: the lack of pre-defined common syntax or structure. As a result, each application that uses them creates its own syntax/structure, and that makes it difficult to reliably distinguish one application's record from others, and for its parser to avoid problems when it encounters other TXT records.

TXTリソースレコードは、そのような使用にはあまり適していない理由は第一の理由は、彼らはとても魅力的にするもの正確です:事前に定義された共通の構文や構造の欠如。その結果、それらを使用する各アプリケーションは、独自の構文/構造を作成し、それはそれは難しい確実に他の人から、それは他のTXTレコードに遭遇したときの問題を回避するために、そのパーサーの1つのアプリケーションのレコードを区別することができます。

Arguably, the TXT Resource Record is misnamed, and should have been called the Local Container record, because a TXT Resource Record means only what the data producer says it means. This is fine, so long as TXT Resource Records are being used by human beings or by private agreement between data producer and data consumer. However, it becomes a problem once one starts using them for standardized protocols in which there is no prior relationship between data producer and data consumer. If TXT records are used without one of the naming modifications discussed earlier (and in some cases even if one uses such naming mechanisms), there is nothing to prevent collisions with some other incompatible use of TXT Resource Records.

おそらく、TXTリソースレコードの名前は間違っている、とTXTリソースレコードは、データプロデューサは、それが意味言うだけで何を意味するので、ローカルコンテナレコードと呼ばれている必要があります。これは、TXTリソースレコードは、人間によって、データのプロデューサーとデータ・消費者間のプライベート合意によって使用されている限り、罰金です。 1は、データ・プロデューサーとデータ消費者の間には以前の関係はありませんここで標準化されたプロトコルのためにそれらを使用し始めるとしかし、それが問題となります。 TXTレコードは(1がこのような命名メカニズムを使用している場合でも、いくつかのケースで)先に述べた命名修正の一つせずに使用している場合は、TXTリソースレコードのいくつかの他の互換性のない使用との衝突を防ぐためには何もありません。

This is even worse than the general subtyping problem described in Section 3.1 because TXT Resource Records don't even have a standardized selector field in which to store the subtype. RFC 1464 [RFC1464] tried, but it was not a success. At best, a definition of

TXTリソースレコードもサブタイプを格納するための標準化されたセレクター・フィールドを持っていないので、これは3.1節で説明した一般的なサブタイピングの問題よりもさらに悪くなります。 RFC 1464 [RFC1464]は試してみましたが、それは成功ではなかったです。の最高の状態で、定義

a subtype is reduced to hoping that whatever scheme one has come up with will not accidently conflict with somebody else's subtyping scheme, and that it will not be possible to mis-parse one application's use of TXT Resource Records as data intended for a different application. Any attempt to impose a standardized format within the TXT Resource Record format would be at least fifteen years too late, even if it were put into effect immediately; at best, one can restrict the syntax that a particular application uses within a TXT Resource Record and accept the risk that unrelated TXT Resource Record uses will collide with it.

サブタイプはいない誤っだろう誰かの他の亜型のスキームと競合し、異なるアプリケーションのために意図されたデータとして、TXTリソースレコードの1つのアプリケーションの使用を誤って解析することが可能とされないことに1が来たものは何でもスキームことを期待してまで低減されます。 TXTリソースレコードフォーマット内標準化された形式を課すしようとすると、それはすぐに有効に入れたとしても、遅すぎる少なくとも15年以上になります。せいぜい、1は、特定のアプリケーションがTXTリソースレコードの中に使用する構文を制限し、無関係なTXTリソースレコードの用途はそれと衝突するリスクを受け入れることができます。

Using one of the naming modifications discussed in Section 3.2 and Section 3.3 would address the subtyping problem, (and have been used in combinations with reuse of TXT record, such as for the dns/txt lookup mechanism in Domain Keys Identified Mail (DKIM)) but each of these approaches brings in new problems of its own. The prefix approach (that for example SRV Resource Records use) does not work well with wildcards, which is a particular problem for mail-related applications, since MX Resource Records are probably the most common use of DNS wildcards. The suffix approach doesn't have wildcard issues, but, as noted previously, it does have synchronization and update authorization issues, since it works by creating a second subtree in a different part of the global DNS namespace.

3.2節および3.3節で議論命名修飾のいずれかを使用して、サブタイプの問題に対処することになる(このようなメール(DKIM)同定されたドメインキーでDNS / TXTルックアップメカニズムについては、TXTレコードの再利用と組み合わせて使用​​されています)しかし、これらのアプローチのそれぞれが独自の新たな問題をもたらします。プレフィックスアプローチは、(例えばSRVリソースレコードを使用すること)MXリソースレコードは、おそらくDNSワイルドカードの中で最も一般的に使用されていることから、メール関連のアプリケーションに特有の問題であるワイルドカード、とうまく動作しません。サフィックスのアプローチは、それがグローバルなDNS名前空間の別の部分に第二のサブツリーを作成することで動作するので、それは、同期および更新の権限の問題を持っている、前述のように、ワイルドカードの問題を持っていますが、しません。

The next reason why TXT Resource Records are not well suited to protocol use has to do with the limited data space available in a DNS message. As alluded to briefly in Section 3.1, typical DNS query traffic patterns involve a very large number of DNS clients sending queries to a relatively small number of DNS servers. Normal path MTU discovery schemes do little good here because, from the server's perspective, there isn't enough repeat traffic from any one client for it to be worth retaining state. UDP-based DNS is an idempotent query, whereas TCP-based DNS requires the server to keep state (in the form of TCP connection state, usually in the server's kernel) and roughly triples the traffic load. Thus, 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.

TXTリソースレコードは、プロトコルの使用にはあまり適していない理由は次の理由は、DNSメッセージで利用可能な限られたデータ空間に関係しています。 3.1節で簡単に触れたように、一般的なDNSクエリトラフィックパターンは、DNSサーバの比較的少数にクエリーを送信するDNSクライアントの非常に多くを必要とします。それは状態を保持する価値であるためには、サーバの観点から、十分なリピートトラフィックがいずれかのクライアントから存在していない、ので、通常のパスMTUディスカバリ方式は、ここで少し良いこと。 TCPベースのDNS(通常、サーバのカーネルでは、TCP接続状態の形で)状態を維持するためにサーバを必要とし、おおよそトラフィック負荷を3倍のに対し、UDPベースのDNSは、冪等クエリです。このように、UDPデータグラムに収まるほど短いDNSメッセージ、IPフラグメンテーションを必要としない程度に短い好ましくはUDPデータグラムを維持する強いインセンティブがあります。

Subtyping schemes are therefore again problematic because they produce larger Resource RRSets than necessary, but verbose text encodings of data are also wasteful since the data they hold can usually be represented more compactly in a Resource Record designed specifically to support the application's particular data needs. If the data that need to be carried are so large that there is no way to make them fit comfortably into the DNS regardless of encoding, it is probably better to move the data somewhere else, and just use the DNS as a pointer to the data, as with NAPTR.

彼らは必要以上に大きなリソースRRセットを生成し、彼らが保持するデータは通常、特に、アプリケーションの特定のデータニーズをサポートするように設計されたリソースレコードに、よりコンパクトに表現することができるので、データの冗長テキストエンコーディングも無駄であるため、サブタイピング方式は、したがって、再び問題があります。実施する必要のあるデータは、彼らがエンコーディングに関係なく、どこかにデータを移動するために、おそらく優れている、とだけデータへのポインタとしてDNSを使用するDNSに快適に収まるようにする方法がないほど大きい場合、NAPTRのように。

6. Conclusion and Recommendation
6.結論と提言

Given the problems detailed in Section 5, it is worth reexamining the oft-jumped-to conclusion that specifying a new Resource Record Type is hard. Historically, this was indeed the case, but recent surveys suggest that support for unknown Resource Record Types [RFC3597] is now widespread in the public Internet, and because of that, the DNS infrastructure can handle new Resource Record Types. The lack of support for unknown Types remains an issue for relatively old provisioning software and in corporate environments.

第5節で詳述問題を考えると、それは再検討の価値があるOFT-飛び降り-に新しいリソースレコードの種類を指定することは困難であるという結論。歴史的に、これは確かにそうであったが、最近の調査では、未知のリソースレコードのタイプ[RFC3597]のサポートは、公衆インターネットで広く普及しており、そのため、DNSインフラストラクチャは、新しいリソースレコードのタイプを扱うことができることを示唆しています。未知のタイプのためのサポートの欠如は、比較的古いプロビジョニングソフトウェア用と企業環境では問題に残ります。

Of all the issues detailed in Section 3.5, provisioning the data is in some respects the most difficult. Investigations with zone transfers show that the problem is less difficult for the authoritative name servers themselves than the front-end systems used to enter (and perhaps validate) the data. Hand editing does not work well for maintenance of large zones, so some sort of tool is necessary, and the tool may not be tightly coupled to the name server implementation itself. Note, however, that this provisioning problem exists to some degree with any new form of data to be stored in the DNS, regardless of data format, Resource Record type (even if TXT Resource Record Types are in use), or naming scheme. Adapting front-end systems to support a new Resource Record Type may be a bit more difficult than reusing an existing type, but this appears to be a minor difference in degree rather than a difference in kind.

データをプロビジョニングセクション3.5で説明するすべての問題は、いくつかの点で最も困難です。ゾーン転送での調査は、問題がデータを入力する(そしておそらく検証)に使用されるフロントエンドシステムよりも自分自身の権威ネームサーバにはあまり難しいことを示しています。手の編集は、大ゾーンのメンテナンスのためにうまく動作しませんので、ツールのいくつかの並べ替えが必要であり、このツールは、しっかりとネームサーバの実装自体に結合することはできません。ただし、このプロビジョニング問題がDNSに格納されるデータの新しい形式にかかわらず、データフォーマット、リソースレコードタイプ(TXTリソースレコードタイプが使用されている場合でも)、または命名方式にある程度存在すること。新しいリソースレコードの種類をサポートするために、フロントエンドシステムを適応させることは少し難しい既存の型を再利用するよりも、これは程度の軽微な違いではなく、一種の違いのように見えることがあります。

Given the various issues described in this note, we believe that:

このノートに記載されている種々の問題を考えると、我々はそれを信じています:

o there is no magic solution that allows a completely painless addition of new data to the DNS, but

OがDNSへの新たなデータの完全無痛追加することができます魔法の解決策はありませんが、

o on the whole, the best solution is still to use the DNS Resource Record Type mechanism designed for precisely this purpose, whenever possible, and

O全体的に、最善の解決策は、可能な限り、まさにこの目的のために設計されたDNSリソースレコードタイプのメカニズムを使用することがあり、そして

o of all the alternate solutions, the "obvious" approach of using TXT Resource Records for arbitrary names is almost certainly the worst, especially for the two reasons outlined above (lack of semantics and its implementations, and size leading to the need to use TCP).

すべての代替ソリューションのO、任意の名前のTXTリソースレコードを使用しての「明白な」アプローチは、特にTCPを使用する必要性につながる(意味論の欠如とその実装、およびサイズ上に概説二つの理由から、ほぼ確実に最悪です)。

7. Creating a New Resource Record Type
7.新しいリソースレコードタイプの作成

The process for creating a new Resource Record Type is specified in RFC 5395 [RFC5395].

新しいリソースレコードの種類を作成するためのプロセスは、RFC 5395 [RFC5395]で指定されています。

8. Security Considerations
8.セキュリティの考慮事項

DNS RRSets can be signed using DNSSEC. DNSSEC is almost certainly necessary for any application mechanism that stores authorization data in the DNS. DNSSEC signatures significantly increase the size of the messages transported, and because of this, the DNS message size issues discussed in Sections 3.1 and 5 are more serious than they might at first appear.

DNSのRRセットは、DNSSECを使用して署名することができます。 DNSSECは、ほぼ確実にDNSに認証データを保存する任意のアプリケーションのメカニズムのために必要です。 DNSSECの署名が大幅に運ばれたメッセージのサイズを大きくし、このために、セクション3.1および5で説明したDNSメッセージサイズの問題は、彼らが最初に表示される場合がありますよりも深刻です。

Adding new Resource Record Types (as discussed in Section 3.5) can create two different kinds of problems: in the DNS software and in applications. In the DNS software, it might conceivably trigger bugs and other bad behavior in software that is not compliant with RFC 3597 [RFC3597], but most such DNS software is old enough and insecure enough that it should be updated for other reasons in any case. In applications and provisioning software, the changes for the new features that need the new data in the DNS can be updated to understand the structure of the new data format (regardless of whether a new Resource Record Type is used or some other mechanism is chosen). Basic API support for retrieving arbitrary Resource Record Types has been a requirement since 1989 [RFC1123].

DNSソフトウェアのアプリケーションで:問題の2種類を作成することができます(セクション3.5で説明したように)新しいリソースレコードのタイプを追加します。 DNSソフトウェアでは、それはおそらくバグやRFC 3597 [RFC3597]に準拠していないが、ほとんどのようにDNSソフトウェアは、それがどのような場合でも、他の理由のために更新する必要があることを十分に十分に古いものと安全ではないソフトウェアで他の悪い行動を誘発する可能性があります。アプリケーションおよびプロビジョニングソフトウェアでは、DNSに新しいデータを必要とする新機能の変更は、新しいデータフォーマットの構造を理解するために更新することができます(関係なく、新しいリソースレコードの種類が使用されているか、他のいくつかのメカニズムが選択されているかどうか) 。任意のリソースレコードのタイプを取得するための基本的なAPIのサポートは1989 [RFC1123]以来の要件となっています。

Any new protocol that proposes to use the DNS to store data used to make authorization decisions would be well advised not only to use DNSSEC but also to encourage upgrades to DNS server software recent enough not to be riddled with well-known exploitable bugs.

承認決定を行うために使用されるデータを格納するためにDNSを使用することを提案した新しいプロトコルがうまくDNSSECを使用することもよく知られている攻撃可能なバグだらけではないことが十分に最近のDNSサーバソフトウェアのアップグレードを奨励するだけでなく、賢明でしょう。

9. Acknowledgements
9.謝辞

This document has been created over a number of years, with input from many people. The question on how to expand and use the DNS is sensitive, and a document like this can not please everyone. The goal is instead to describe the architecture and tradeoffs, and make some recommendations about best practices.

この文書では、多くの人々からの入力で、数年かけて作成されています。 DNSを拡張し、使用方法についての質問は敏感であり、このような文書は皆を喜ばせることができません。目標は、アーキテクチャとのトレードオフを説明し、ベストプラクティスについていくつかの提言を行う代わりにあります。

People that have helped include: Dean Anderson, Mark Andrews, John Angelmo, Roy Badami, Dan Bernstein, Alex Bligh, Nathaniel Borenstein, Stephane Bortzmeyer, Brian Carpenter, Leslie Daigle, Elwyn Davies, Mark Delany, Richard Draves, Martin Duerst, Donald Eastlake, Robert Elz, Jim Fenton, Tony Finch, Jim Gilroy, Olafur Gudmundsson, Eric Hall, Phillip Hallam-Baker, Ted Hardie, Bob Hinden, Paul Hoffman, Geoff Houston, Christian Huitema, Johan Ihren, John Klensin, Ben Laurie, William Leibzon, John Levine, Edward Lewis, David MacQuigg, Allison Mankin, Bill Manning, David Meyer, Pekka Nikander, Mans Nilsson, Masataka Ohta, Douglas Otis, Michael Patton, Jonathan Rosenberg, Anders Rundgren, Miriam Sapiro, Carsten Strotmann, Pekka Savola, Chip Sharp, James Snell, Michael Thomas, Paul Vixie, Sam Weiler, Florian Weimer, Bert Wijnen, and Dan Wing.

助けた人々が含まれます:ディーン・アンダーソン、マーク・アンドリュース、ジョンAngelmo、ロイBadami、ダン・バーンスタイン、アレックス・ブライ、ナサニエル・ボレンスタイン、ステファンBortzmeyer、ブライアン・カーペンター、レスリーDaigle氏、エルウィン・デイヴィス、マーク・ディレイニー、リチャードDraves、マーティンDuerst、ドナルドイーストレイクを、ロバート・エルツ、ジム・フェントン、トニー・フィンチ、ジム・ギルロイ、オラフルグドムンソン、エリック・ホール、フィリップハラム - ベイカー、テッドハーディー、ボブHindenとポール・ホフマン、ジェフ・ヒューストン、クリスチャンのHuitema、ヨハンIhren、ジョン・クレンシン、ベン・ローリー、ウィリアムLeibzon 、ジョン・レヴァイン、エドワード・ルイス、デヴィッドMacQuigg、アリソンマンキン、ビル・マニング、デビッド・マイヤー、ペッカNikander、マン・ニルソン、正隆太田、ダグラスオーティス、マイケル・パットン、ジョナサン・ローゼンバーグ、アンダース・ラングレン、ミリアム・サピロ、カールステンStrotmann、ペッカSavola、チップシャープ、ジェームズ・スネル、マイケル・トーマス、ポール・ヴィクシー、サム・ワイラー、フロリアンWeimerさん、バートWijnen、およびダン・ウィング。

10. IAB Members at the Time of This Writing
この記事の執筆時点では10 IABメンバー

Loa Andersson Gonzalo Camarillo Stuart Cheshire Russ Housley Olaf Kolkman Gregory Lebovitz Barry Leiba Kurtis Lindqvist Andrew Malis Danny McPherson David Oran Dave Thaler Lixia Zhang

ロア・アンダーソンゴンサロ・カマリロスチュアートチェシャーラスHousleyオラフKolkmanグレゴリーLebovitzバリー・レイバカーティスLindqvistアンドリューMalisダニー・マクファーソンデヴィッドオランデーブターラーLixiaチャン

11. References
11.参考文献
11.1. Normative References
11.1. 引用規格

[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月。

[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.

[RFC2535]イーストレイク、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。

[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.

[RFC2671]いるVixie、P.、 "DNS用拡張メカニズム(EDNS0)"、RFC 2671、1999年8月。

[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.

[RFC3597]グスタフソン、A.、 "未知のDNSリソースレコード(RR)の取扱いタイプ"、RFC 3597、2003年9月。

[RFC5395] Eastlake, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 5395, November 2008.

[RFC5395]イーストレイク、D.、 "ドメインネームシステム(DNS)IANAの考慮事項"、BCP 42、RFC 5395、2008年11月。

11.2. Informative References
11.2. 参考文献

[DNSEXT-DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, September 2008.

[DNSEXT-DNS-SD]チェシャー、S.とM. Krochmal、 "DNSベースのサービス発見"、進歩、2008年9月の作業。

[Dyer87] Dyer, S. and F. Hsu, "Hesiod, Project Athena Technical Plan - Name Service", Version 1.9, April 1987.

[Dyer87]ダイアー、S.およびF.スー、 "ヘシオドス、Athenaプロジェクトのテクニカルプラン - ネームサービス"、バージョン1.9、1987年4月。

[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.

[RFC1123]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。

[RFC1535] Gavron, E., "A Security Problem and Proposed Correction With Widely Deployed DNS Software", RFC 1535, October 1993.

[RFC1535] Gavron、E.、 "セキュリティ課題と広く配​​布しているDNSソフトウェアと提案さ補正"、RFC 1535、1993年10月。

[RFC2163] Allocchio, C., "Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM)", RFC 2163, January 1998.

[RFC2163] Allocchio、C.、RFC 2163 "MIXER適合のグローバルアドレスマッピング(MCGAM)を配布するには、インターネットDNSを使用する"、1998年1月。

[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.

"DNS仕様の明確化" [RFC2181]エルツ、R.とR.ブッシュ、RFC 2181、1997年7月。

[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.

[RFC2672]クロフォード、M.、 "非ターミナルDNS名リダイレクション"、RFC 2672、1999年8月。

[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002.

[RFC3445]マッセイ、D.とS.ローズ、RFC 3445 "KEYリソースレコード(RR)の範囲を制限"、2002年12月。

[RFC3467] Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467, February 2003.

[RFC3467] Klensin、J.、RFC 3467、2003年2月 "ドメインネームシステム(DNS)の役割"。

[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.

[RFC3761] Faltstrom、P.とM. Mealling、RFC 3761、2004年4月 "統一資源識別子(URI)ダイナミックな委譲発見システム(DDDS)アプリケーション(ENUM)へのE.164"。

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.

[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.

[RFC4034]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張機能のためのリソースレコード"、RFC 4034、2005年3月。

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.

[RFC4035]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。

[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.

[RFC4511] Sermersheim、J.、 "ライトウェイトディレクトリアクセスプロトコル(LDAP):プロトコル"、RFC 4511、2006年6月。

[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, July 2006.

[RFC4592]ルイス、E.、 "ドメインネームシステムにおけるワイルドカードの役割"、RFC 4592、2006年7月。

[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.

[RFC4871]オールマン、E.、カラス、J.、デラニー、M.、リビー、M.、フェントン、J.、およびM.トーマス、 "ドメインキーを識別メール(DKIM)署名"、RFC 4871、2007年5月。

Authors' Addresses

著者のアドレス

Internet Architecture Board

インターネットアーキテクチャ委員会

EMail: iab@iab.org

メールアドレス:iab@iab.org

Patrik Faltstrom (editor)

パトリックFaltstrom(編集者)

EMail: paf@cisco.com

メールアドレス:paf@cisco.com

Rob Austein (editor)

ロブAusteinと(編集者)

EMail: sra@isc.org

メールアドレス:sra@isc.org

Peter Koch (editor)

ピーター・コッホ(編集者)

EMail: pk@denic.de

メールアドレス:pk@denic.de