[要約] RFC 5507は、DNSの拡張時の設計選択肢についてのガイドラインです。このRFCの目的は、DNSの拡張に関する設計上の選択肢を提供し、効果的な拡張の実装を支援することです。
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
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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
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は、複数のカテゴリのデータを保存します。最も一般的に使用される2つのカテゴリは、DNSシステム自体のインフラストラクチャデータ（NSおよびSOAリソースレコード）と、ドメイン名とIPアドレス間のマッピング（A、AAAA、およびPTRリソースレコード）に関係するデータです。他のカテゴリもありますが、そのうちのいくつかは電子メール（MXリソースレコード）などの特定のアプリケーションに関連付けられていますが、複数のプロトコル（SRVおよびNAPTRリソースレコード）の情報を伝えるために使用される一般的なリソースレコードタイプです。
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 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の新しいデータが説明するものです。場合によっては、それらは完全に新しいデータかもしれません。それ以外の場合、それらはすでにDNSに存在するデータに結び付けられている可能性があります。新しいデータの例は、セキュアシェル（SSH）プロトコルの重要な情報と、電子メールメッセージの送信者を認証するために使用されるデータ（MXリソースレコードに関連付けられたメタデータ）です。新しいデータがDNSに既に存在するデータに関連付けられている場合、異なるDNSゾーンに（たとえば）アドレスレコードとSSHの重要な情報が問題であるかどうか、またはそれがボーナスであるかどうか、およびそれがボーナスであるかどうかについて分析を行う必要があります。仕様に関連するすべてのデータが同じゾーンにあることを要求する必要があるかどうかは問題です。同じゾーンにレコードを持つかどうかの1つの特定の違いは、レコードのメンテナンスに関係しています。それらが同じゾーンにいる場合、同じメンテナー（DNSの観点から）が2つのレコードを管理します。具体的には、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.
このドキュメントでは、DNSに何を保存すべきかについては説明していません。また、DNSをサービスの発見に使用する必要があるかどうか、またはDNSをサービスに固有のデータの保存に使用する必要があるかどうかも議論していません。一般に、DNSは、DNS自体を機能させるメタデータ（NS、SOA、DNSSECリソースレコードタイプなど）を保持することとは別に、サービスの場所（SRV、NAPTR、A、AAAAリソースレコードへの言及のみを保持するプロトコルです。タイプ） - MXリソースレコードなどの例外があります。
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クエリを作成する場合、プロトコルで使用されるパラメーターは{所有者、クラス、タイプ}トリプルです。このようなトリプルと一致するすべてのリソースレコードは、同じリソースレコードセット（RRSet）に属すると言われており、RRSet全体が常にクライアントに返されます。RRSTの分割は、DNSキャッシュメカニズムの一貫性の問題を引き起こす可能性があるため、プロトコル違反（DNS応答を切り捨てるのではなく、部分的なRRSetを送信します）です。詳細については、[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サイズに関するほとんどの議論は、単一のRRSetのサイズではなく、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クエリメッセージよりも大きいため、メッセージサイズの問題は、ほとんどの場合、クエリではなく応答に関するものです。ベースDNS仕様は、UDPを介したDNSメッセージを512オクテットに制限します。EDNS0 [RFC2671]は、クライアントがより大きな応答を受信する意欲を示すメカニズムを指定しますが、EDNS0の展開は普遍的ではありません。応答メッセージが単一のパケットに収まらない場合、名前サーバーは切り捨てられた応答を返します。この時点で、クライアントはTCPを使用して再試行する場合があります。TCPを介したDNSクエリは、この長さの制限の対象ではありませんが、TCPはUDPよりも名前サーバーでクエリあたりのオーバーヘッドが大幅に高くなります。また、展開されたファイアウォールのポリシーがTCPを介してDNをブロックするようなものであることが多いため、TCPを使用することは実際には選択肢ではないかもしれません。また、TCPフローが開いている間にルーティングを変更すると、DNSサーバーがAnycast環境に展開されると問題が発生するというリスクもあります（おそらく小さいものの）。
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プロトコルは、新しい種類のデータをサポートするために拡張可能であることを目的としています。このセクションでは、この種の拡張機能を達成できるさまざまな方法を検討します。
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.
特定のクエリ名に対して、複数のアプリケーションで共有された単一のRRSet（すべてのリソースレコードが同じ{所有者、クラス、タイプ}トリプルを共有するすべてのリソースレコードを持っていることを選択できます。どのレコードがどのアプリケーションを意図しているかを決定します。この種のセレクターメカニズムは、通常、単一の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キーリソースレコードタイプ[RFC2535]（後にRFC 3445 [RFC3445]によって更新され、RFC 4033 [RFC4033]、RFC 4034 [RFC4034]およびRFC 4034 [RFC4034]によって廃止されました。[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サブタイピングスキームは共通の弱点を共有しています。サブタイピングスキームでは、クライアントが必要なデータのみをクエリすることは不可能です。代わりに、クライアントはRRSET全体を取得し、関心のあるリソースレコードを選択する必要があります。さらに、DNSSEC署名は完全なRRSetsで動作するため、ITのリソースレコードが変更された場合、RRSet全体を再署名する必要があります。その結果、サブタイプのリソースレコードを使用する各アプリケーションは、サブタイピングスキームを使用していない場合、どのアプリケーションが発生したよりも高いオーバーヘッドが発生します。不可分なユニットとしてRRSetが常に渡されるという事実は、RRSETがUDPパケットに収まらないリスクを高めるため、クライアントがTCPでクエリを再試行する必要があるリスクを高め、それにより、大幅に増加します。名前サーバー。より正確に言えば、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への切り捨てとフォールバックをリスクリスクします。
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:
アプリケーション固有のプレフィックスをドメイン名に追加することにより、別の{所有者、クラス、タイプ}トリプル、したがって異なるRRSetを取得します。プレフィックスを追加することの1つの問題は、特に次のようなレコードがある場合、ワイルドカードに関係しています。
*.example.com. IN MX 1 mail.example.com.
*.example.com。mx 1 mail.example.comで。
and one wants records tied to those names. Suppose one creates the prefix "_mail". One would then have to say something like:
そして、それらの名前に結び付けられたレコードを望んでいます。プレフィックス「_mail」を作成するとします。その後、次のようなことを言わなければなりません。
_mail.*.example.com. IN X-FOO A B C D
_mail。*。example.com。x-foo a b c dで
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.
特定のプレフィックスが選択されている場合でも、データはリソースレコードタイプに保存する必要があります。このリソースレコードタイプは、データを保存するための適切な形式を持つ新しいリソースレコードタイプまたは既存のリソースレコードタイプのいずれかです。また、同じリソースレコードタイプがある場合、RRSetのレコードを区別する機能など、他の選択メカニズムが必要になる場合があります。このため、一意のプレフィックスを登録し、この特定のサービスに使用するリソースレコードタイプを定義する必要があります。
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で。_foo.example.com。X-Bar「メールサービス用メタデータ」
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つのレコードが2つの異なるゾーンにある可能性があり、その結果、2つの異なる組織によって管理され、DNSSECを使用するときに2つの異なるエンティティによって署名される可能性があります。これらの2つの理由により、プレフィックスを使用することは最近、多くのプロトコルデザイナーにとって非常に興味深いソリューションになりました。場合によっては、たとえば、ドメインキーがメール署名[RFC4871]を特定した場合、TXTレコードが使用されています。SRVなどの他のものでは、まったく新しいリソースレコードタイプが追加されました。
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.
ドメイン名に接尾辞を追加すると、{所有者、クラス、タイプ}トリプル、したがってRRSetが変更されます。この場合、クエリ名は必要なデータに正確に設定できるため、RRSetのサイズが最小化されます。接尾辞を追加することの問題は、クラス内に平行なツリーを作成することです。さらに、「Example.com」と「Example.com._bar」の代表団が同じ組織に作成されるようにするための技術的メカニズムはありません。さらに、単一のエンティティに関連付けられたデータは、「emple.com」と「embler.com._bar」などの2つの異なるゾーンに保存されます。問題。
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.
別の名前を使用する場合でも、データを保存するための適切な形式を持つリソースレコードタイプにデータを保存する必要があります。これは、プレフィックスベースの選択メカニズムを他のメカニズムと組み合わせる必要があることを意味し、適切なリソースレコードが潜在的なより大きなRRSetで多くの人から見つかります。
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]では、Infixトークンがトップレベルドメイン（TLD）の真下に挿入されていますが、結果は所有者名に接尾辞を追加することに相当します（TLDを作成する代わりに、1つは2番目のレベルドメインを作成しています）。
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レコードと同じクラスを共有しており、あるクラスにゾーンの存在が他のクラスにゾーンの存在を保証しないという意味でクラス固有です。実際には、クラス内の展開を見たことがありますが、追加のクラスの展開の管理オーバーヘッドはほぼ確実に法外にあります。
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].
それにもかかわらず、理論的には、DNSクラスのメカニズムを使用して、異なる種類のデータを区別することができます。ただし、DNS委任ツリー（NSリソースレコードで表される）は特定のクラスに結び付けられているため、クラスの境界を越えてクエリを解決しようとすると、予期しない結果が生じる可能性があります。新しいクラスは、クラスの名前サーバーと同じです。MIT HESIODシステム[DYER87]は、HSクラスにデータを保存するためにこのようなスキームを使用しましたが、非常に小規模（単一の機関内）でのみ、およびINおよびHSツリーの代表団の木を要求する管理Fiatを使用して同一である。非感受性データのそのようなストレージにHSクラスを使用することは、時間の経過とともに、Lightweight Directory Access Protocol（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.
別のクラスを使用する場合でも、データは適切な形式のあるリソースレコードタイプに保存する必要があります。
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. プライマリマスター名サーバーの新しいリソースレコードをゾーンに挿入する方法が必要です。一部のサーバーの実装では、ユーザーインターフェイスは理解しているリソースレコードタイプのみを受け入れます（おそらく、実装がデータの検証を試みることができるように）。その他の実装により、ゾーン管理者は、Resource Record Typeコードの整数と、Base64または16進コード（または生データとして）のRDATAを入力できます。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. アプリケーションは、新しいリソースレコードタイプでRRSetを取得できる必要があります。アプリケーション自体はRDATAを理解するかもしれませんが、リゾルバーライブラリはそうではないかもしれません。任意のDNSリソースレコードタイプを取得するための一般的なインターフェイスのサポートは、1989年以来要件でした（[RFC1123]のセクション6.1.4.2を参照）。一部のStub Resolver Libraryの実装は、この機能を提供することを怠り、未知のリソースレコードタイプを処理できませんが、新しいStub Resolverライブラリの実装は特に難しくなく、この機能を既に提供するオープンソースライブラリが利用可能です。
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 StandardがNAPTRリソースレコードを再利用する理由の1つであり、今日では新しいリソースレコードタイプを作成した可能性があります。
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]したがって、さまざまなリソースレコードタイプに必要な努力がより予測可能です。
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:
誤った仮定は、「ツリークライミング」と呼ばれるアプローチにつながりました。ここでは、肯定的な応答を受け取らないクエリ（要求されたRRSetが欠落しているか、名前が存在しませんでした）が左端のラベルを繰り返し剥がすことで再試行されます（登山ルート）ルートドメインに到達するまで。これらの提案は、ルートレベルまたは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レジストリは2番目のレベルから始まる名前を登録します（例：co.uk）。第三に、または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 RRSetは、その特定のTLDのサブドメインに対して有効ではありません。
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
o DNSメッセージのスペースに関する考慮事項
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クラスシステムを拡張メカニズムとして使用することは実際には選択肢ではありません。実際、システムのほとんどのユーザーは、メカニズムが存在することさえ認識していません。したがって、実際の問題として、拡張機能はクラス内にある可能性があります。
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.
したがって、アプリケーションデザイナーには、クラス内でいくつかの既存の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は、シンクリソースレコードタイプに登録されました。このリソースレコードタイプは、IETFのDNSindワーキンググループで議論され、46番目のIETFで、アプリケーションデザイナーがシンクリソースレコードタイプを使用することを奨励するリスクがあるため、I-DをRFCに移動しないことが決定されました。新しいリソースレコードタイプを登録します。これにより、確実に大きなシンクrrsetsになります。
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.
上記のすべてを排除すると、クラスのTXTリソースレコードタイプが残ります。TXT RDATA形式は無料のフォームテキストであり、邪魔する既存のセマンティクスはありません。[DNSEXT-DNS-SD]で、TXTリソースレコードタイプの構造化された形式を指定するためのいくつかの試みが行われましたが、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リソースレコードがこのような使用に適していない最初の理由は、まさにそれらを非常に魅力的にするものです。これは、事前に定義された一般的な構文または構造の欠如です。その結果、それらを使用する各アプリケーションは独自の構文/構造を作成し、1つのアプリケーションのレコードを他のアプリケーションと確実に区別し、パーサーが他のTXTレコードに遭遇したときに問題を回避することを困難にします。
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リソースレコードが人間によって、またはデータプロデューサーとデータ消費者との間の個人的な合意によって使用されている限り、これは問題ありません。ただし、データプロデューサーとデータ消費者の間に以前の関係がない標準化されたプロトコルに使用を開始すると、問題になります。先に説明した命名修正のいずれかなしでTXTレコードを使用している場合（および場合によっては、そのような命名メカニズムを使用していても）、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 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リソースレコードには、サブタイプを保存する標準化されたセレクターフィールドさえないため、これはセクション3.1で説明されている一般的なサブタイピングの問題よりもさらに悪いです。RFC 1464 [RFC1464]が試みましたが、成功しませんでした。せいぜい、サブタイプの定義は、他の誰かのサブタイピングスキームと誤って矛盾することはなく、TXTリソースレコードをデータとしてTXTリソースレコードを使用したことを誤って誤解することは不可能であることを期待することに還元されます。別のアプリケーションを目的としています。TXTリソースレコード形式内で標準化された形式を課そうとする試みは、すぐに有効にされたとしても、少なくとも15年遅すぎるでしょう。せいぜい、特定のアプリケーションが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で説明した命名修正の1つを使用すると、サブタイピングの問題に対処します（およびドメインキー識別されたメール（DKIM）のDNS/TXTルックアップメカニズムなど、TXTレコードの再利用と組み合わせて使用されています）しかし、これらのアプローチのそれぞれは、それ自体の新しい問題をもたらします。MXリソースレコードはおそらくDNSワイルドカードの最も一般的な使用であるため、プレフィックスアプローチ（たとえば、SRVリソースレコードが使用する）はワイルドカードではうまく機能しません。これは、メール関連のアプリケーションにとって特定の問題です。サフィックスアプローチにはワイルドカードの問題はありませんが、前述のように、グローバルDNSネームスペースの異なる部分に2番目のサブツリーを作成することで機能するため、同期と更新の認証の問題があります。
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クライアントが含まれます。通常のPATH MTU発見スキームは、サーバーの観点からは、1つのクライアントからのトラフィックが十分に繰り返されるため、状態を維持する価値があるため、ここではほとんどうまくいきません。UDPベースのDNSはiDempotentクエリですが、TCPベースのDNSはサーバーに（通常はサーバーのカーネル内のTCP接続状態の形で）状態を維持する必要があり、トラフィック負荷をほぼ3倍にします。したがって、DNSメッセージをUDPデータグラムに適合させるのに十分短く保つための強力なインセンティブがあります。できれば、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.
したがって、サブタイピングスキームは、必要以上に大きなリソースrrsetを生成するため問題がありますが、データの冗長なテキストエンコーディングは、通常、アプリケーションの特定のデータニーズをサポートするために特別に設計されたリソースレコードでよりコンパクトに表現できるため、データの冗長なテキストエンコーディングも無駄です。運ばれる必要があるデータが非常に大きいため、エンコーディングに関係なくDNSに快適に収まる方法がない場合は、データを他の場所に移動し、データのポインターとしてDNSを使用する方がおそらく良いことです。、naptrと同様。
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で詳述されている問題を考えると、新しいリソースレコードタイプを指定することが難しいということが多い結論を再検討する価値があります。歴史的に、これは確かに事実でしたが、最近の調査は、未知のリソースレコードタイプ[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で詳述されているすべての問題のうち、データのプロビジョニングは最も困難です。ゾーン転送を使用した調査では、データの入力（およびおそらく検証）に使用されるフロントエンドシステムよりも、権威ある名前サーバー自体にとって問題がそれほど難しくないことが示されています。ハンド編集は大規模なゾーンのメンテナンスにはうまく機能しないため、何らかのツールが必要であり、ツールがネームサーバーの実装自体にしっかりと結合されない場合があります。ただし、データ形式、リソースレコードタイプ（TXTリソースレコードタイプが使用されていても）、またはネーミングスキームに関係なく、このプロビジョニングの問題はDNSに保存される新しい形式のデータをある程度存在することに注意してください。フロントエンドシステムを適応させて新しいリソースレコードタイプをサポートすることは、既存のタイプを再利用するよりも少し難しい場合がありますが、これは種類の違いではなく、程度のわずかな違いのようです。
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リソースレコードを使用する「明白な」アプローチは、特に上記の2つの理由（セマンティクスとその実装の欠如、およびTCPを使用する必要性につながるサイズ）のために、ほぼ間違いなく最悪です。。
The process for creating a new Resource Record Type is specified in RFC 5395 [RFC5395].
新しいリソースレコードタイプを作成するプロセスは、RFC 5395 [RFC5395]で指定されています。
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 rrsetsは、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].
（セクション3.5で説明したように）新しいリソースレコードタイプを追加すると、DNSソフトウェアとアプリケーションで2つの異なる種類の問題が発生する可能性があります。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サーバーソフトウェアへのアップグレードを奨励することをお勧めします。
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.
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、Martin Duerst、ロバート・エルツ、ジム・フェントン、トニー・フィンチ、ジム・ギルロイ、オラファー・グドムンソン、エリック・ホール、フィリップ・ハラム・ベーカー、テッド・ハーディ、ボブ・ヒンデン、ポール・ホフマン、ジェフ・ヒューストン、クリスチャン・フイテマ、ヨハン・イーレン、ジョン・クレンシン、ベン・ローリー、ウィリアム・レイブゾン、ジョン・レヴァイン、エドワード・ルイス、デビッド・マッキーグ、アリソン・マンキン、ビル・マニング、デビッド・マイヤー、ペッカ・ニカンダー、マンズ・ニルソン、マサタカ・オタ、ダグラス・オティス、マイケル・パットン、ジョナサン・ローゼンバーグ、アンダース・ランドグレン、ミリアム・サピロ、カルステン・ストロットマン、ペッカ・サヴァーラシャープ、ジェームズ・スネル、マイケル・トーマス、ポール・ビクシー、サム・ワイラー、フロリアン・ワイマー、バート・ウィジネン、ダン・ウィング。
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
ロア・アンダーソン・ゴンザロ・カマリロ・スチュアート・チェシャー・ラス・ハウズリー・オラフ・コルクマン・グレゴリー・レボビッツ・バリー・レイバ・カルティス・リンドクヴィスト・アンドリュー・マリス・ダニー・マクファーソン・デイビッド・オラン・デイバー・ザン・リキシア・ザン
[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] Rosenbaum、R。、「ドメイン名システムを使用して任意の文字列属性を保存する」、RFC 1464、1993年5月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] Eastlake、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] Gustafsson、A。、「不明なDNSリソースレコード（RR）タイプの取り扱い」、RFC 3597、2003年9月。
[RFC5395] Eastlake, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 5395, November 2008.
[RFC5395] Eastlake、D。、「ドメイン名システム（DNS）IANAの考慮事項」、BCP 42、RFC 5395、2008年11月。
[DNSEXT-DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, September 2008.
[DNSEXT-DNS-SD] Cheshire、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] Dyer、S。およびF. Hsu、「Hesiod、Project Athena Technical Plan -Name Service」、バージョン1.9、1987年4月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden、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。、「インターネットDNSを使用してミキサーコンフォーマントグローバルアドレスマッピング（MCGAM）を配布する」、RFC 2163、1998年1月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「DNS仕様の説明」、RFC 2181、1997年7月。
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
[RFC2672] Crawford、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] Massey、D。およびS. Rose、「主要なリソースレコード（RR）の範囲の制限」、RFC 3445、2002年12月。
[RFC3467] Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467, February 2003.
[RFC3467]クレンシン、J。、「ドメイン名システムの役割（DNS）」、RFC 3467、2003年2月。
[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。and M. Mealling、「E.164へのユニフォームリソース識別子（URI）動的委任ディスカバリーシステム（DDDS）アプリケーション（ENUM）」、RFC 3761、2004年4月。
[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月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張のプロトコル変更」、RFC 4035、2005年3月。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J。、「Lightweight Directory Access Protocol（LDAP）：The Protocol」、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] Allman、E.、Callas、J.、Delany、M.、Libbey、M.、Fenton、J.、およびM. Thomas、「Domainkeys Idified Mail（DKIM）署名」、RFC 4871、2007年5月。
Authors' Addresses
著者のアドレス
Internet Architecture Board
インターネットアーキテクチャボード
EMail: iab@iab.org
Patrik Faltstrom (editor)
Patrik Faltstrom（編集者）
EMail: paf@cisco.com
Rob Austein (editor)
ロブ・オーストイン（編集者）
EMail: sra@isc.org
Peter Koch (editor)
ピーター・コッホ（編集者）
EMail: pk@denic.de