[要約] このRFCは、DNSのプライバシー、認証、特殊な使用法、エンコーディング、文字、マッチング、およびルート構造に関する議論を再評価する必要性を提案しています。目的は、現在のDNSの課題や制約を解決し、より安全で効率的なDNSシステムを実現することです。
Independent Submission J. Klensin
Request for Comments: 8324 February 2018
Category: Informational
ISSN: 2070-1721
DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?
DNSのプライバシー、承認、特別な使用、エンコード、文字、マッチング、ルート構造：もう一見の時間？
Abstract
概要
The basic design of the Domain Name System was completed almost 30 years ago. The last half of that period has been characterized by significant changes in requirements and expectations, some of which either require changes to how the DNS is used or can be accommodated only poorly or not at all. This document asks the question of whether it is time to either redesign and replace the DNS to match contemporary requirements and expectations (rather than continuing to try to design and implement incremental patches that are not fully satisfactory) or draw some clear lines about functionality that is not really needed or that should be performed in some other way.
ドメインネームシステムの基本設計は、約30年前に完成しました。その期間の後半は、要件と期待の大幅な変更によって特徴付けられており、その一部は、DNSの使用方法を変更する必要があるか、不十分にしか対応できないか、まったく対応できないかのどちらかです。このドキュメントでは、（完全に満足のいくものではないインクリメンタルパッチの設計と実装を続けるのではなく）現在の要件と期待に合わせるためにDNSを再設計して置き換える時期なのか、それとも、本当に必要ないか、または他の方法で実行する必要があります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFC Editorは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8324.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8324で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background and Hypothesis . . . . . . . . . . . . . . . . . . 5
3. Warts and Tensions with the Current DNS . . . . . . . . . . . 6
3.1. Multi-type Queries . . . . . . . . . . . . . . . . . . . 6
3.2. Matching Part I: Case Sensitivity in Labels and Other
Anomalies . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Matching Part II: Non-ASCII ("Internationalized") Domain
Name Labels . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Matching Part III: Label Synonyms, Equivalent Names, and
Variants . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Query Privacy . . . . . . . . . . . . . . . . . . . . . . 10
3.6. Alternate Namespaces for Public Use in the DNS Framework:
The CLASS Problem . . . . . . . . . . . . . . . . . . . . 10
3.7. Loose Synchronization . . . . . . . . . . . . . . . . . . 10
3.8. Private Namespaces and Special Names . . . . . . . . . . 11
3.9. Alternate Query or Response Encodings . . . . . . . . . . 12
3.10. Distribution and Management of Root Servers . . . . . . . 12
3.11. Identifiers versus Brands and Other Convenience Names . . 13
3.12. A Single Hierarchy with a Centrally Controlled Root . . . 14
3.13. Newer Application Protocols, New Requirements, and DNS
Evolution . . . . . . . . . . . . . . . . . . . . . . . . 14
3.13.1. The Extensions . . . . . . . . . . . . . . . . . . . 15
3.13.2. Extensions and Deployment Pressures -- The TXT
RRTYPE . . . . . . . . . . . . . . . . . . . . . . . 15
3.13.3. Periods and Zone Cut Issues . . . . . . . . . . . . 16
3.14. Scaling of Reputation and Other Ancillary Information . . 17
3.15. Tensions among Transport, Scaling, and Content . . . . . 18
4. The Inverse Lookup Requirement . . . . . . . . . . . . . . . 19
5. Internet Scale, Function Support, and Incremental Deployment 20
6. Searching and the DNS -- An Historical Note . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
This document explores contemporary expectations of the Internet's domain system (DNS) and compares them to the assumptions and properties of the DNS design, including both those documented in the RFC Series, an important early paper by the principal author of the original RFCs [Mockapetris-1988], and a certain amount of oral tradition. It is primarily intended to ask the question of whether the differences are causing enough stresses on the system, stresses that cannot be resolved satisfactorily by further patching, that the Internet community should be considering designing a new system, one that is better adapted to current needs and expectations, and developing a deployment and transition strategy for it. For those (perhaps the majority of us) for whom actually replacing the DNS is too radical to be realistic, the document may be useful in two other ways. It may provide a foundation for discussing what functions the DNS should not be expected to support and how those functions can be supported in other ways, perhaps via an intermediate system that then calls on the DNS or by using some other type of database technology for some set of functions while leaving the basic DNS functions intact. Or it may provide a basis for "better just get used to that and the way it works" discussions to replace fantasies about what the DNS might do in some alternate reality.
このドキュメントは、インターネットのドメインシステム（DNS）に対する現代の期待を調査し、それらをDNS設計の仮定およびプロパティと比較します。これには、元のRFCの筆頭著者による重要な初期の論文であるRFCシリーズに記載されているものも含まれます[Mockapetris- 1988]、そしてある程度の口承伝統。これは主に、違いがシステムに十分なストレスをもたらしているかどうか、さらにパッチを適用しても十分に解決できないストレスがあるかどうか、インターネットコミュニティが現在のニーズにより適した新しいシステムの設計を検討する必要があるかどうかを質問することを目的としていますそして期待、そしてそれのための展開と移行戦略の開発。実際にDNSを置き換えるのが根本的すぎて現実的ではない人（おそらく私たちの大多数）にとって、このドキュメントは他の2つの点でも役立つかもしれません。これは、DNSがサポートする必要のない機能と、それらの機能を他の方法でサポートする方法を議論するための基盤を提供する可能性があります。おそらく、DNSを呼び出す中間システムを介して、または他のタイプのデータベーステクノロジーを使用して、基本的なDNS機能はそのままに、機能のセット。または、DNSが別の現実で何をするかについての空想を置き換えるために、「それとその動作方法に慣れるほうがよい」議論の基礎を提供するかもしれません。
There is a key design or philosophical question associated with the analysis in this document that the document does not address. It is whether changes to perceived requirements to DNS functionality as described here are, in most respects, evolutionary or whether many of them are instances of trying to utilize the DNS for new requirements because it exists and is already deployed independent of whether the DNS is really appropriate or not. The latter might be an instance of a problem often described in the IETF as "when all you have is a hammer, everything looks like a nail".
このドキュメントの分析に関連する重要なデザインまたは哲学的な質問があり、このドキュメントでは扱いません。ここで説明するDNS機能の認識された要件への変更がほとんどの点で進化的であるかどうか、またはDNSが存在し、実際にDNSが実際に展開されているかどうかに関係なくすでに展開されているため、それらの多くがDNSを新しい要件に利用しようとしたインスタンスであるかどうかです。適切かどうか。後者は、IETFで「あなたが持っているものがすべてハンマーである場合、すべてが釘のように見える」としばしば説明されている問題のインスタンスである可能性があります。
Other recent work, including a short article by Vint Cerf [Cerf2017], has discussed an overlapping set of considerations from a different perspective, reinforcing the view that it may be time to ask fundamental questions about the evolution and future of the DNS.
Vint Cerf [Cerf2017]による短い記事を含む他の最近の研究は、異なる視点からの検討事項の重複について論じており、DNSの進化と将来に関する根本的な質問をする時がきたという見方を強化しています。
While this document does not assume deep technical or operational knowledge of the DNS, it does assume some knowledge and at least general familiarity with the concepts of RFC 1034 [RFC1034] and RFC 1035 [RFC1035] and the terminology discussed in RFC 7719 [RFC7719] and elsewhere. Although some of the comments it contains might be taken as hints or examples of different ways to think about the design issues, it makes no attempt to explore, much less offer a tutorial on, alternate naming systems or database technologies.
このドキュメントでは、DNSの深い技術的または運用的な知識は想定していませんが、RFC 1034 [RFC1034]とRFC 1035 [RFC1035]の概念、およびRFC 7719 [RFC7719]で説明されている用語に関するある程度の知識と少なくとも一般的な知識を前提としています。と他の場所。そこに含まれているコメントの一部は、設計の問題について考えるためのさまざまな方法のヒントまたは例として取り上げられているかもしれませんが、調査する試みはなく、代替の命名システムまたはデータベーステクノロジーに関するチュートリアルを提供していません。
It is perhaps worth noting that, while the perspective is different and more than a dozen years have passed, many of the issues discussed in this document were analyzed and described (most of them with more extensive explanations) in a 2005 US National Research Council report [NRC-Signposts].
注目に値するかもしれませんが、見方は異なり、12年以上が経過しましたが、このドキュメントで説明されている問題の多くは、2005年の全米調査委員会のレポートで分析および説明されています（その多くはより広範な説明が含まれています）。 [NRC-Signposts]。
Readers should note that several references are to obsolete documents. That was done because they are intended to show the documents and dates that introduced particular features or concepts. When current versions are intended, they are referenced.
読者は、いくつかの参照が古いドキュメントを対象としていることに注意する必要があります。これは、特定の機能または概念を導入したドキュメントと日付を示すことを目的としているためです。現在のバージョンが意図されている場合、それらは参照されます。
The Domain Name System (DNS) [RFC1034] was designed starting in the early 1980s [RFC0799] [RFC0881] [RFC0882] [RFC0883] with the main goal of replacing the flat, centrally administered, host table system [RFC0810] [RFC0952] [RFC0953] with a hierarchical, administratively distributed, system. The DNS design included some features that, after initial implementation and deployment, were judged to be unworkable and either replaced (e.g., the mail destination (MD) and mail forwarder (MF) approach [RFC0882] that were replaced by the MX approach [RFC0974]), abandoned (e.g., the mechanism for using email local parts as labels described in RFC 1034, Section 3.3), or deprecated (e.g., the WKS RR TYPE [RFC1123]). Newer ideas and requirements have identified a number of other features, some of which were less developed than others. Of course the original designers could not anticipate everything that has come to be expected of the DNS in the last 30 years.
ドメインネームシステム（DNS）[RFC1034]は、1980年代初頭に設計されました[RFC0799] [RFC0881] [RFC0882] [RFC0883]主な目的は、フラットで集中管理されたホストテーブルシステム[RFC0810] [RFC0952]を置き換えることです。 [RFC0953]階層的な、管理上分散されたシステム。 DNSの設計には、初期の実装と展開の後で機能しないと判断され、置き換えられたいくつかの機能が含まれていました（たとえば、メールの宛先（MD）およびメールフォワーダー（MF）のアプローチ[RFC0882] MXのアプローチ[RFC0974] ]）、放棄（たとえば、RFC 1034、セクション3.3で説明されているラベルとしてメールのローカルパーツを使用するためのメカニズム）、または非推奨（たとえば、WKS RR TYPE [RFC1123]）。新しいアイデアと要件により、他の多くの機能が特定されましたが、その一部は他よりも開発が遅れていました。もちろん、元の設計者は、過去30年間にDNSに期待されるようになったすべてを予測することはできませんでした。
In recent years, demand for new and extended services and uses of the DNS have, in turn, led to proposals for DNS extensions or changes of various sorts. Some have been adopted, including a model for negotiating extended functionality [RFC2671] (commonly known as EDNS(0)) and to support IPv6 [RFC3596], others were found to be impracticable, and still others continue to be under consideration. Some examples of the latter two categories are discussed below. A few features of the original DNS specification, such as the CLASS property and label types, have also been suggested to be so badly specified that they should be deprecated [Sullivan-Class].
近年、DNSの新規および拡張サービスと使用の需要により、DNS拡張の提案やさまざまな種類の変更が行われています。拡張機能のネゴシエーションモデル[RFC2671]（一般的にEDNS（0）として知られています）を含むIPv6 [RFC3596]をサポートするために採用されたものもあれば、実用的でないことが判明したものや、引き続き検討中のものもあります。後者の2つのカテゴリのいくつかの例を以下で説明します。 CLASSプロパティやラベルタイプなど、元のDNS仕様のいくつかの機能も非常に不適切に指定されているため、非推奨にする必要がある[Sullivan-Class]。
Unlike earlier changes such as the Internationalized Domain Names for Applications (IDNA) mechanisms for better incorporating non-ASCII labels without modifying the DNS structure itself [RFC3490] [RFC5890], some recent proposals require or strongly suggest changes to APIs, formats, or interfaces by programs that need to retrieve information from the DNS or interpret that information. Differences between the DNS architecture and the requirements that imply those proposals suggest that it may be time to stop patching the DNS or trying to extend it in small increments. Instead, we should be considering moving some current or proposed functionality elsewhere or developing a new system that better meets today's needs and a transition strategy to it.
DNS構造自体を変更せずに非ASCIIラベルをより適切に組み込むための国際化アプリケーション名（IDNA）メカニズムなどの以前の変更とは異なり[RFC3490] [RFC5890]、いくつかの最近の提案では、API、フォーマット、またはインターフェースの変更が必要であるか、強く推奨されていますDNSから情報を取得するか、その情報を解釈する必要があるプログラムによって。 DNSアーキテクチャとそれらの提案を暗示する要件の違いは、DNSへのパッチの適用を停止するか、DNSを少しずつ拡張しようとする時が来ている可能性があることを示唆しています。代わりに、現在または提案されている機能を別の場所に移動するか、今日のニーズとその移行戦略に適切に対応できる新しいシステムを開発することを検討する必要があります。
The next section of this document discusses a number of issues with the current DNS design that could appropriately be addressed by a different and newer design model. In at least some cases, changing the model and protocols could bring significant benefits to the Internet and/or its administration.
このドキュメントの次のセクションでは、現在のDNS設計に関するいくつかの問題について説明します。これらの問題は、新しい新しい設計モデルで適切に対処できます。少なくとも一部のケースでは、モデルとプロトコルを変更すると、インターネットやその管理に大きなメリットがもたらされる可能性があります。
This document is not a proposal for a new protocol. It is intended to stimulate thought about how far we want to try to push the existing DNS, to examine whether expectations of it are already exceeding its plausible capabilities, and to start discussion of a redesign or alternatives to one if the time for that decision has come.
このドキュメントは、新しいプロトコルの提案ではありません。これは、既存のDNSをプッシュしようとする距離についての考えを刺激し、その期待がすでにその妥当な機能を超えているかどうかを調査し、その決定の時間があれば、再設計またはそれに代わる選択肢の議論を始めることを目的としています。来る。
As suggested above, there are many signs that the DNS is incapable of meeting contemporary expectations of how it should work and functionality it should support. Some of those expectations are unrealistic under any imaginable circumstances; others are impossible (or merely problematic) in the current DNS structure but could be accommodated in a redesign. These are examples, rather than a comprehensive list, and do not appear in any particular order.
上記で示唆したように、DNSがどのように機能し、サポートする必要がある機能性に関する現在の期待に応えることができないという多くの兆候があります。それらの期待のいくつかは、想像できる状況下では非現実的です。他のものは現在のDNS構造では不可能（または単に問題がある）ですが、再設計で対応できます。これらは包括的なリストではなく例であり、特定の順序で表示されることはありません。
The DNS does not gracefully support multi-type queries. The current case where this problem rears its head involves attempts at solutions that return both TYPE A (IPv4) and type AAA (IPv6) addresses collectively. The problem was originally seen with "QTYPE=MAILA" [RFC0882] for the original MA and MD RRTYPEs, an experience that strongly suggests that some very careful thinking about cache effects (and possibly additional DNS changes) would be needed. Other solutions might seem equally or more plausible. What they, including "two types of addresses", probably have in common is that they illustrate stresses on the system and that changing the DNS to deal with those stresses is not straightforward or likely to be problem-free.
DNSはマルチタイプクエリを適切にサポートしていません。この問題が後を絶たない現在のケースには、タイプA（IPv4）とタイプAAA（IPv6）の両方のアドレスをまとめて返すソリューションの試みが含まれます。この問題は当初、元のMAおよびMD RRTYPEの「QTYPE = MAILA」[RFC0882]で見られました。この経験から、キャッシュの影響（および場合によっては追加のDNS変更）について非常に注意深く考える必要があることが強く示唆されています。他の解決策は、同等またはより妥当と思われるかもしれません。 「2種類のアドレス」を含むそれらがおそらく共通しているのは、システムへのストレスを示していることと、それらのストレスに対処するためにDNSを変更することが簡単ではないか、問題がない可能性が高いことです。
The DNS specifications assume that labels are octet strings and octets with the high bit zero have seven-bit ASCII codes in the remaining bits. They require that, when a domain name used in a query is matched to one stored in the database, those ASCII characters be interpreted in a case-independent way, i.e., upper- and lower-case letters are treated as equivalent (digits and symbols are not affected) [RFC4343]. For non-ASCII octets, i.e., octets in labels with the first bit turned on, there are no assumptions about the character coding used, much less any rules about character case equivalence -- strings must be compared by matching bits in sequence. Even though the current model for handling non-ASCII (i.e., "internationalized") domain name labels (IDNs) [RFC5890] (see Section 3.3 below) encodes information so the DNS is not directly affected, the notion that some characters in labels are handled in a case-insensitive way and that others are case sensitive (or that upper case must be prohibited entirely as IDNA does) has caused a good deal of confusion and resentment. Those concerns and complaints about inconsistent behavior and mishandling (or suboptimal handling) of case relationships for some languages have not been mitigated by repeated explanations that the relationships between "decorated" lower-case characters and their upper-case equivalents are often sensitive to language and locality and therefore not deterministic with information available to DNS servers.
DNS仕様では、ラベルはオクテット文字列であり、上位ビットがゼロのオクテットには残りのビットに7ビットのASCIIコードがあると想定しています。クエリで使用されるドメイン名がデータベースに保存されているドメイン名と一致する場合、それらのASCII文字は大文字と小文字を区別しない方法で解釈される必要があります。つまり、大文字と小文字は同等に扱われます（数字と記号）。影響を受けません）[RFC4343]。非ASCIIオクテット、つまり最初のビットがオンになっているラベルのオクテットの場合、使用される文字コーディングについての仮定はなく、文字の大文字と小文字の同等性に関するルールははるかに少なくなります。文字列は、ビットを順番に照合して比較する必要があります。非ASCII（つまり「国際化された」）ドメイン名ラベル（IDN）[RFC5890]（以下のセクション3.3を参照）を処理するための現在のモデルは情報をエンコードするため、DNSは直接影響を受けませんが、ラベルの一部の文字は大文字と小文字を区別しない方法で処理され、他の大文字と小文字が区別される（またはIDNAのように大文字を完全に禁止する必要がある）ことで、かなりの混乱と憤慨を引き起こしています。一部の言語では、一貫性のない動作と大文字と小文字の関係の不適切な処理（または次善の処理）に関するこれらの懸念と不満は、「装飾された」小文字とそれに対応する大文字の関係が言語に敏感であり、局所性、したがってDNSサーバーが利用できる情報で確定的ではありません。
3.3. Matching Part II: Non-ASCII ("Internationalized") Domain Name Labels
3.3. 一致するパートII：非ASCII（「国際化」）ドメイン名ラベル
Quite independent of the case-sensitivity problem, one of the fundamental properties of Unicode [Unicode] is that some abstract characters can be represented in multiple ways, such as by a single, precomposed, code point or by a base code point followed by one or more code points that specify combining characters. While Unicode Normalization can be used to eliminate many (but not all) of those distinctions for comparison (matching) purposes, it is best applied during matching rather than by changing one string into another. The first version of IDNA ("IDNA2003") made the choice to change strings during processing for either storage or retrieval [RFC3490] [RFC3491]; the second ("IDNA2008") required that all strings be normalized and that upper-case characters are not allowed at all [RFC5891]. Neither is optimal, if only because, independent of where they are changed if they are changed at all, transforming the strings themselves implies that the input string in an application may not be the same as the string used in processing and perhaps later display.
大文字と小文字の区別の問題とはまったく関係なく、Unicode [Unicode]の基本的な特性の1つは、一部の抽象文字が、単一の事前構成されたコードポイントまたはベースコードポイントの後に1つ続くなど、複数の方法で表すことができる結合文字を指定する以上のコードポイント。 Unicode正規化は、比較（照合）の目的でこれらの区別の多く（すべてではない）を排除するために使用できますが、文字列を別の文字列に変更するのではなく、照合中に適用するのが最適です。 IDNAの最初のバージョン（ "IDNA2003"）は、保存または取得のいずれかの処理中に文字列を変更することを選択しました[RFC3490] [RFC3491]。 2番目（ "IDNA2008"）では、すべての文字列を正規化する必要があり、大文字はまったく許可されていません[RFC5891]。文字列自体を変換すると、文字列自体を変換しても、アプリケーションでの入力文字列が、処理で使用された文字列と同じでなく、後で表示される場合があるためです。
It would almost certainly be preferable, and more consistent with Unicode recommendations, to use normalization (and perhaps other techniques if they are appropriate) at matching time rather than altering the strings at all, even if there were still only a single matching algorithm, i.e., normalization were added to the existing ASCII-only case folding. However, even Unicode's discussion of normalization [Unicode-UAX15] indicates that there are special, language-dependent, cases (the most commonly cited example is the dotless "i" (U+0131)). Not only does the DNS lack any information about languages that could be used in a mapping algorithm, but, as long as there is a requirement that there be only one mapping algorithm for the entire system, that information could not be used even if it were available. One could imagine a successor system that would use information stored at nodes in the hierarchy to specify different matching rules for subsidiary nodes (or equivalent arrangements for non-hierarchical systems). It is not clear whether that would be a good idea, but it certainly is not possible with the DNS as we know it.
たとえ単一のマッチングアルゴリズムしかない場合でも、文字列をまったく変更するのではなく、マッチング時に正規化（および適切な場合はおそらく他の手法）を使用することは、ほぼ間違いなく推奨され、Unicodeの推奨事項と整合性があります。 、正規化が既存のASCIIのみのケースフォールディングに追加されました。ただし、Unicodeによる正規化の説明[Unicode-UAX15]でも、言語に依存する特殊なケースがあることが示されています（最も一般的に引用される例は、ドットのない "i"（U + 0131）です）。 DNSには、マッピングアルゴリズムで使用できる言語に関する情報が不足しているだけでなく、システム全体に対してマッピングアルゴリズムが1つだけであるという要件がある限り、その情報は使用されていません。利用可能です。階層内のノードに格納されている情報を使用して、補助ノード（または非階層システムの同等の配置）に異なるマッチングルールを指定する後続システムを想像できます。それが良い考えかどうかは明らかではありませんが、私たちが知っているDNSではそれは確かに不可能です。
As the initial phases of work on IDNs started to conclude, it became obvious that the nature and evolution of human language and writing systems required treating some names as "the same as" others. The first important example of this involved the relatively recent effort to simplify the Chinese writing system, thereby creating a distinction between "Simplified" and "Traditional" Chinese even though the meaning of the characters remained the same in almost all cases (in so-called ideographic character sets, characters have meaning rather than exclusively representing sounds). A joint effort among the relevant Country Code Top-Level Domain (ccTLD) registries and some other interested parties produced a set of recommendations for dealing with the issues with that script [RFC3743] and introduced the concept of "variant" characters and domain names.
IDNに関する作業の初期段階が終了し始めると、人間の言語とライティングシステムの性質と進化によって、一部の名前を他の名前と「同じ」として扱う必要があることが明らかになりました。これの最初の重要な例は、中国語の書記体系を簡略化する比較的最近の取り組みであり、それによって文字の意味がほとんどすべての場合に同じままであったとしても（いわゆる表意文字セット、文字は音だけを表すのではなく意味を持っています）。関連する国コードトップレベルドメイン（ccTLD）レジストリと他の一部の関係者の間の共同の取り組みにより、そのスクリプト[RFC3743]の問題に対処するための一連の推奨事項が作成され、「バリアント」文字とドメイン名の概念が導入されました。
However, when names are seen as having meanings, rather than merely being mnemonics, especially when they represent brands or the equivalent, or when spelling for a particular written language is not completely standardized, demands to treat different strings as exact equivalents are obvious and inevitable. As a trivial English-language example, it is widely understood that "colour" and "color" represent the same word, so does that imply that, if they are used as DNS labels in domain names all of whose other labels are identical, the two domain names should be treated as identical? Examples for other languages or writing systems, especially ones in which some or all markings that distinguish characters or words by sound or tone or that change the pronunciation of words are optional, are often more numerous and more problematic than national spelling differences in English, but they are harder to explain to those unfamiliar with those other languages or writing systems (and hard to illustrate in ASCII-only Internet-Drafts and RFCs). Although approximations are possible, the DNS cannot handle that requirement: not only do its aliasing mechanisms (CNAME, DNAME, and various proposals for newer and different types of aliasing [DNS-Aliases] [DNS-BNAME]) not provide a strong enough binding, but the ability to use those aliases from a subtree controlled by one administrative entity to that of another one implies that there is little or no possibility of the owner (in either the DNS sense or the registrar-registrant one) of a particular name to control the synonyms for it. Some of that issue can be dealt with at the application level, e.g., by redirects in web protocols, but taking that approach, which is the essential characteristic of "if both names belong to the same owner, everything is OK" approaches, results in names being handled in inconsistent ways in different protocols.
ただし、名前が単にニーモニックではなく意味を持つと見なされる場合、特にブランドまたは同等のものを表す場合、または特定の書かれた言語のスペルが完全に標準化されていない場合、異なる文字列を完全に同等のものとして扱う要求は明白で避けられない。ささいな英語の例として、「色」と「色」は同じ単語を表すことが広く理解されているため、他のすべてのラベルが同じドメイン名でDNSラベルとして使用されている場合、 2つのドメイン名を同一として扱う必要がありますか？他の言語や書記体系の例、特に文字や単語を音や音で区別したり、単語の発音を変更したりするマーキングの一部またはすべてがオプションである例は、英語での全国的なスペルの違いよりも多く、問題が多いですが、それらは、他の言語や書記体系に不慣れな人に説明するのが困難です（ASCIIのみのインターネットドラフトとRFCで説明するのは困難です）。近似は可能ですが、DNSはその要件を処理できません。エイリアシングメカニズム（CNAME、DNAME、およびさまざまな種類のエイリアシング[DNS-Aliases] [DNS-BNAME]のさまざまな提案）を行うだけでなく、十分に強力なバインディングを提供しません、ただし、ある管理エンティティによって制御されるサブツリーから別の管理エンティティのエイリアスにこれらのエイリアスを使用できるということは、特定の名前の所有者（DNSの意味またはレジストラ登録者のいずれか）がその同義語を制御します。その問題の一部は、アプリケーションレベルで（たとえば、Webプロトコルのリダイレクトによって）対処できますが、そのアプローチを取ることは、「両方の名前が同じ所有者に属している場合、すべてが問題ない」というアプローチの本質的な特徴であり、異なるプロトコルで一貫性のない方法で処理される名前。
A different way of looking at part of this issue (and, to some degree, of the one discussed above in Section 3.3) is that these perceived equivalences and desired transformations are context-dependent, but the DNS resolution process is not [RFC6912].
この問題の一部（および、ある程度、セクション3.3で説明した問題の一部）を見る別の方法は、これらの認識された同等性と望ましい変換はコンテキストに依存するが、DNS解決プロセスは[RFC6912]ではないということです。
Similar problems arise as people notice that some characters are easily mistaken for others and that might be an opportunity for user confusion and attacks. Commonly cited examples include the Latin and Cyrillic script "a" characters, which are identical [CACM-Homograph], the characters in many scripts that look like open circles or vertical or horizontal lines, and even the Latin script letter "l" and the European digit "1", but examples abound in other scripts and combinations of scripts as well. The most common proposed solution within the DNS context has been to treat these cases, as well as those involving orthographic variations, as "variants" (but variants different from the system for Chinese characters mentioned above) and either ban all but one (or a few) of the possible labels from the DNS (possibly on a first come, first served basis) or ensure that any collection of such strings that are delegated as assigned to the same ownership (see above). Neither solution is completely satisfactory: if all but one string is excluded, users who guess at a different form, perhaps in trying to transcribe characters from written or printed form, don't find what they are looking for and, as pointed out above, "same ownership" is sufficient only with carefully designed and administered applications protocol support, and sometimes not then.
同様の問題は、一部の文字が他の文字と間違えられやすく、ユーザーの混乱や攻撃の機会になる可能性があることに気づくと発生します。一般的に引用される例には、ラテン文字とキリル文字の "a"文字（同一の[CACM-Homograph]）、白丸または垂直線または水平線のように見える多くのスクリプトの文字、さらにはラテン文字 "l"とヨーロッパの数字「1」ですが、他のスクリプトやスクリプトの組み合わせにも例がたくさんあります。 DNSコンテキスト内で最も一般的に提案されている解決策は、これらのケースと正書法のバリエーションを含むケースを「バリアント」（ただし、上記の漢字のシステムとは異なるバリアント）として扱い、1つを除くすべて（またはDNSからの可能性のあるラベルの一部（おそらく先着順）、または同じ所有権に割り当てられたものとして委任されたそのような文字列のコレクション（上記を参照）を保証します。どちらの解決策も完全に満足できるものではありません。1つの文字列を除いてすべてが除外されている場合、別のフォームで推測したユーザーは、おそらく書面または印刷されたフォームから文字を転記しようとしても、探しているものが見つかりません。 「同じ所有権」は、注意深く設計および管理されたアプリケーションプロトコルサポートでのみ十分であり、そうでない場合もあります。
Some of these issues are discussed at more length in an ICANN report [ICANN-VIP].
これらの問題のいくつかは、ICANNレポート[ICANN-VIP]でさらに詳しく説明されています。
There has been growing concern in recent years that DNS queries occur in cleartext on the public Internet and that, if those queries can be intercepted, they can expose a good deal of information about interests and contacts that could compromise individual privacy. While a number of proposals, including query name minimization [RFC7816] and running DNS over an encrypted tunnel [RFC7858], have been made to mitigate that problem, they all appear to share the common properties of security patches rather than designed-in security or privacy mechanisms. While experience may prove otherwise once (and if) they are widely deployed, it does not appear that any of them are as satisfactory as a system with query privacy designed in might be. More general tutorials on this issue have appeared recently [Huston2017a].
DNSクエリがパブリックインターネット上でクリアテキストで発生し、それらのクエリが傍受される可能性がある場合、個人のプライバシーを危険にさらす可能性のある関心や連絡先に関する大量の情報を公開する可能性があるという懸念が近年高まっています。クエリ名の最小化[RFC7816]や暗号化されたトンネルでのDNSの実行[RFC7858]など、いくつかの提案がその問題を軽減するために行われましたが、それらはすべて、設計されたセキュリティではなく、セキュリティパッチの共通のプロパティを共有しているようですプライバシーメカニズム。経験は、そうでなければ一度（そして広く）展開されたと証明されるかもしれませんが、クエリのプライバシーが設計されたシステムほど満足できるものではないようです。この問題に関するより一般的なチュートリアルが最近登場しました[Huston2017a]。
3.6. Alternate Namespaces for Public Use in the DNS Framework: The CLASS Problem
3.6. DNSフレームワークでパブリックに使用する代替ネームスペース：CLASS問題
The DNS standards include specification of a CLASS value, which "identifies a protocol family or instance of a protocol" (RFC 1034, Section 3.6, and elsewhere). While CLASS was used effectively in the early days of the DNS to manage different protocol families within the same administrative environment, recent attempts to use it to either partition the DNS namespace in other ways such as for non-ASCII names (partially to address the issues in Sections 3.2 and 3.3) or use DNS mechanisms for entirely different namespaces have exposed fundamental problems with the mechanism [Sullivan-Class]. Perhaps the most fundamental of those problems is disagreement about whether multiple CLASSes were intended to exist within a given zone (with records within RRSETs) or whether different CLASSes implied different zones. Different implementations make different assumptions [Faltstrom-2004] [Vixie-20170704]. These problems have led to recommendations that it be dropped entirely [Sullivan-Class], but discussions on the IETF list and in WGs in mid-2017 made it clear that there is no clear consensus on that matter.
DNS標準には、「プロトコルファミリーまたはプロトコルのインスタンスを識別する」CLASS値の仕様が含まれています（RFC 1034、セクション3.6など）。 CLASSはDNSの初期の頃、同じ管理環境内でさまざまなプロトコルファミリを管理するために効果的に使用されていましたが、最近では、それを使用して非ASCII名などの他の方法でDNS名前空間をパーティション分割する試みが行われています（問題の一部を解決するため）セクション3.2および3.3）またはまったく異なる名前空間にDNSメカニズムを使用すると、メカニズム[Sullivan-Class]に根本的な問題が発生します。おそらく、これらの問題の最も基本的なものは、複数のCLASSが特定のゾーン（RRSET内のレコードを含む）内に存在することを意図していたのか、または異なるCLASSが異なるゾーンを示唆していたのかについての不一致です。実装が異なれば、想定も異なります[Faltstrom-2004] [Vixie-20170704]。これらの問題により、完全に削除することが推奨されました[Sullivan-Class]。ただし、2017年半ばのIETFリストとWGでの議論により、その問題について明確なコンセンサスがないことが明らかになりました。
The DNS model of master and slave servers, with the latter initiating updates based on expiration interval values, and local caches with updates based on TTL values, depends heavily on an approach that has come to be called "loose synchronization", i.e., that there can be no expectation that all of the servers that might reasonably answer a query will have exactly the same data unless those data have been unchanged for a rather long period. Put differently, if some or all of the records associated with a particular node in the DNS (informally, a fully qualified domain name (FQDN)) change, one cannot expect those changes to be propagated immediately.
マスターサーバーとスレーブサーバーのDNSモデルは、有効期限の間隔値に基づいて更新を開始し、TTL値に基づいて更新を行うローカルキャッシュは、 "緩い同期"と呼ばれるようになったアプローチに大きく依存します。クエリに合理的に応答する可能性のあるすべてのサーバーが、かなり長い間変更されていない限り、まったく同じデータを持っているとは期待できません。言い換えると、DNSの特定のノードに関連付けられているレコードの一部またはすべて（非公式には、完全修飾ドメイン名（FQDN））が変更された場合、それらの変更がすぐに反映されることは期待できません。
That model has worked rather well since the DNS was first deployed, protecting the system from requirements for mechanisms that are typical where a simultaneous update of multiple systems is needed. Such mechanisms include elaborate locking, complex update procedures and handshaking, or journaling. As has often been pointed out with the Internet, implementation and operational complexity are often the enemy of stability, security, and robustness. Loose synchronization has helped keep the DNS as simple and robust as possible.
DNSが最初に導入されて以来、そのモデルはかなりうまく機能しており、複数のシステムの同時更新が必要な一般的なメカニズムの要件からシステムを保護しています。このようなメカニズムには、複雑なロック、複雑な更新手順とハンドシェイク、またはジャーナリングが含まれます。インターネットでよく指摘されているように、実装と運用の複雑さは、多くの場合、安定性、セキュリティ、堅牢性の敵です。緩やかな同期は、DNSを可能な限りシンプルかつ堅牢に保つのに役立ちました。
A number of recent ideas about using the DNS to store data for which important changes occur very rapidly are, however, largely incompatible with loose synchronization. Efforts to use very short (or zero) refresh times (in SOA records for slave updates from masters) and TTLs (for caches) to simulate nearly simultaneous updating may work up to a point but appear to impose very heavy loads on servers and distribution mechanisms that were not designed to accommodate that style of working. Similar observations can be made about attempts to use the NOTIFY extension [RFC1996] or dynamic, "server-push", updating rather than the traditional DNS mechanisms. While the NOTIFY and push mechanisms normally provide refresh times and update mechanisms faster than those specified in RFCs 1034 and 1035, they imply that a "master" server must know the identities of (and have good connectivity to all of) its slaves. That defeats at least some of the advantages associated with stealth slaves, particularly those associated with reduction of query traffic across the Internet. Those mechanisms do nothing for cache updates: unless servers keep track of the source of every query for names associated with a specific zone and then somehow notify the query source systems, the only alternative to having information that might be obsolete stored in caches is to use very short or zero TTLs so the cached data time out almost immediately after being stored (or are not stored at all), requiring a new query to an authoritative server each time a resolver attempts to look up a name.
ただし、DNSを使用して重要な変更が非常に急速に発生するデータを格納することに関する最近の多くのアイデアは、緩やかな同期とはほとんど互換性がありません。非常に短い（またはゼロの）更新時間（マスターからのスレーブ更新のSOAレコード内）とTTL（キャッシュ用）を使用してほぼ同時に更新をシミュレートする試みは、ある程度までは機能するかもしれませんが、サーバーと配布メカニズムに非常に重い負荷をかけるようですそれらはその作業スタイルに対応するように設計されていません。従来のDNSメカニズムではなく、NOTIFY拡張[RFC1996]または動的な「サーバープッシュ」更新を使用する試みについても、同様の観察ができます。 NOTIFYおよびプッシュメカニズムは、通常、RFC 1034および1035で指定されているものよりも高速な更新時間と更新メカニズムを提供しますが、「マスター」サーバーはそのスレーブのIDを知っている（そしてすべてのスレーブに良好な接続を持っている）必要があることを意味します。これは、ステルススレーブに関連する利点の少なくとも一部、特にインターネット上のクエリトラフィックの削減に関連する利点を無効にします。これらのメカニズムは、キャッシュの更新には何もしません。サーバーが特定のゾーンに関連付けられた名前のすべてのクエリのソースを追跡し、何らかの方法でクエリのソースシステムに通知しない限り、古くなった情報をキャッシュに保存する唯一の方法は、キャッシュを使用することです。 TTLが非常に短いかゼロであるため、キャッシュされたデータは格納された直後（またはまったく格納されない）にタイムアウトし、リゾルバーが名前を検索しようとするたびに権限のあるサーバーに新しいクエリを要求する
Almost since the DNS was first deployed, there have been situations in which it is desirable to use DNS-like names, and often DNS resolution mechanisms or modifications of them, with namespaces for which globally available and consistent resolution using the public DNS is either unfeasible or undesirable (and for which the use of CLASS is not an appropriate mechanism). The need to isolate names and addresses on LANs from the public Internet, typically via "split horizon" approaches, is one example of this requirement although often not recognized as such. Another example that has generated a good deal of controversy involves "special names" -- labels or pseudo-labels, often in TLD positions, that signal that the full name should not be subject to normal DNS resolution or other processing [RFC6761] [RFC8244].
DNSが最初に導入されて以来、DNSのような名前を使用することが望ましい状況があり、多くの場合、DNS解決メカニズムまたはそれらの変更で、パブリックDNSを使用したグローバルに利用可能な一貫した解決が実行不可能であるネームスペースがありますまたは望ましくない（CLASSの使用が適切なメカニズムではない場合）。一般に「スプリットホライズン」アプローチを介して、LAN上の名前とアドレスを公衆インターネットから分離する必要性は、このように認識されていないことが多いですが、この要件の一例です。かなりの論争を引き起こした別の例には、「特別な名前」が含まれます。ラベルまたは疑似ラベルは、TLDの位置にあり、フルネームが通常のDNS解決やその他の処理の対象とならないことを示します[RFC6761] [RFC8244 ]。
Independent of troublesome policy questions about who should allocate such names and the procedures to be used, they almost inherently require either a syntax convention to identify them (there actually was such a convention, but it was abandoned many years ago and there is no plausible way to reinstitute it) or tables of such names that are known to, and kept updated on, every resolver on the Internet, at least if spurious queries to the root servers are to be avoided.
誰がそのような名前と使用するプロシージャを割り当てる必要があるかという面倒なポリシーの質問とは無関係に、ほとんどの場合、本質的にそれらを識別するための構文規則が必要です（実際にはそのような規則がありましたが、それは何年も前に放棄され、もっともらしい方法はありません。少なくともルートサーバーへの偽のクエリを回避する必要がある場合は、インターネット上のすべてのリゾルバに認識され、更新されている名前のテーブルまたはそれを再構築します。
If the DNS were to be redesigned and replaced, we could recognize this requirement as part of the design and handle it much better than it is possible to handle it today.
DNSを再設計して置き換えた場合、この要件を設計の一部として認識し、現在のDNSの処理能力よりもはるかに適切に処理できます。
The DNS specifies formats for queries and data responses, based on the state of the art and best practices at the time it was designed. Recent work has suggested that there would be significant advantages to supporting at least a description of the DNS messages in one or more alternate formats, such as JSON [Hoffman-DNS-JSON] [Hoffman-SimpleDNS-JSON]. While that work has been carefully done to avoid requiring changes to the DNS, much of the argument for having such a JSON-based description format could easily be turned into an argument that, if the DNS were being revised, that format might be preferable as a more direct alternative to having DNS queries and responses in the original form.
DNSは、最先端の技術と設計時のベストプラクティスに基づいて、クエリとデータ応答の形式を指定します。最近の研究では、JSON [Hoffman-DNS-JSON] [Hoffman-SimpleDNS-JSON]など、少なくとも1つ以上の代替形式でDNSメッセージの説明をサポートすることには大きな利点があることが示唆されています。その作業はDNSの変更を必要としないように注意深く行われましたが、このようなJSONベースの記述形式を持つことに関する議論の多くは、DNSが改訂されている場合、その形式が望ましいかもしれないという議論に簡単に変えることができます。 DNSクエリと応答を元の形式にするより直接的な方法。
The DNS model requires a collection of root servers that hold, at minimum, information about top-level domains. Over the years, that requirement has evolved from a technically fairly minor function, normally carried out as a service to the broader Internet community and its users and systems, to a subject that is intensely controversial with regard to control of those servers, including how they should be distributed and where they should be located. While a number of mechanisms, most recently including making the information more local [RFC7706], have been proposed and one (anycast [RFC7094]) is in very active use to mitigate some of the real and perceived problems, it seems obvious that a DNS successor, designed for today's global Internet and perceived requirements, could handle these problems in a technically more appropriate and less controversial way. Some additional discussion of the issues involved appears in a recent paper [Huston2017b].
DNSモデルでは、少なくともトップレベルドメインに関する情報を保持するルートサーバーのコレクションが必要です。長年にわたって、その要件は、より広いインターネットコミュニティとそのユーザーおよびシステムへのサービスとして通常実行される技術的にかなりマイナーな機能から、それらのサーバーの制御方法など、サーバーの制御に関して非常に物議を醸す主題に発展しました。配布する必要があり、どこに配置する必要があります。情報をよりローカルにする[RFC7706]を含む最近のいくつかのメカニズムが提案されており、1つ（エニーキャスト[RFC7094]）は、実際および認識されている問題のいくつかを軽減するために非常に積極的に使用されていますが、DNS今日のグローバルインターネットと認識された要件に合わせて設計された後継者は、技術的に適切で論争の少ない方法でこれらの問題を処理できます。関連する問題のいくつかの追加の議論は、最近の論文[Huston2017b]に掲載されています。
A key design element of the original network object naming systems for the ARPANET, largely inherited by the DNS, was that the names, while expected to be mnemonic, were identifiers and their being highly distinguishable and not prone to ambiguity was important. That led to restrictive rules about what could appear in a name. Those restrictions originated with the host table and even earlier [RFC0236] [RFC0247] and came to the DNS (largely via SMTP) as the "preferred syntax" (RFC 1034, Section 3.5) or what we now often call the letter-digit-hyphen (LDH) rule. Similar rules to make identifiers easier to use, less prone to ambiguity, or less likely to interfere with syntax occur frequently in more formal languages. For example, almost every programming language has restrictions on what can appear in an identifier, and Unicode provides general recommendations about identifier composition [Unicode-USA31]. Both are quite restrictive as compared to the number of characters and total number of strings that can be written using that character coding system.
ARPANETの元のネットワークオブジェクトネーミングシステムの主要な設計要素は、主にDNSに継承されたものでしたが、名前はニーモニックであると期待されていましたが識別子であり、非常に区別可能であり、あいまいさになりにくいことが重要でした。そのため、名前に何が表示されるかについての制限的なルールが生じました。これらの制限はホストテーブルから始まり、さらに以前の[RFC0236] [RFC0247]であり、「推奨される構文」（RFC 1034、セクション3.5）または現在は文字数字と呼ばれるものとしてDNS（主にSMTP経由）に到達しました。ハイフン（LDH）ルール。識別子を使いやすくする、あいまいさになりにくい、または構文に干渉する可能性を低くするための同様のルールは、より正式な言語で頻繁に発生します。たとえば、ほとんどすべてのプログラミング言語には識別子に表示できるものに制限があり、Unicodeは識別子の構成に関する一般的な推奨事項を提供します[Unicode-USA31]。どちらも、その文字コーディングシステムを使用して書き込むことができる文字数と文字列の総数と比較すると、かなり制限されています。
That model, which originally prohibited labels starting with digits in order to avoid any possible confusion with IP addresses, began to break down in 1987 or 1988 when a company named 3Com wanted to use its corporate name as a label within the COM TLD, and the rule was relaxed [RFC1123].
このモデルは、IPアドレスとの混乱を避けるために、最初は数字で始まるラベルを禁止していましたが、3Comという会社がCOM TLD内のラベルとして会社名を使用したいと考えた1987年または1988年に崩壊し始めました。ルールが緩和されました[RFC1123]。
In the last decade or two, the perspective that company names should be supported if possible has expanded and done so largely without its limits, if any, being explicitly understood or acknowledged. In the current form, the DNS is really (and primarily) a system for expressing thoughts and concepts. Those include free expression of ideas in as close to natural language as possible as well as representation of product names and brands. That view requires letter-like characters that might not be reasonable in identifiers along with a variety of symbols and punctuation. It may also require indicators of preferred type styles to provide information in a form that exactly matches personal or legal preferences. At least if carried to an extreme, that perspective would argue for standardizing word and sentence separators, removing the limit of 63 octets per label and probably the limit of 255 octets on the total length of a domain name, and perhaps even eliminating the hierarchy or allowing separators for labels in presentation form (now fixed at "." for the DNS) to be different according to context. It suggests that, at least, the original design was defective in not prioritizing those uses over the more restrictive approach associated with prioritizing unique and unambiguous identifiers.
過去10年または2年の間に、可能であれば会社名をサポートする必要があるという見方は、明確に理解または認められていても、その制限があったとしても、大幅に拡大および実施されました。現在の形式では、DNSは本当に（そして主に）考えや概念を表現するためのシステムです。これには、可能な限り自然言語に近いアイデアの自由な表現や、製品名やブランドの表現が含まれます。このビューには、識別子では適切でない可能性のある文字のような文字と、さまざまな記号や句読点が必要です。また、個人または法的な好みに正確に一致する形式で情報を提供するために、優先するタイプスタイルのインジケーターが必要になる場合もあります。少なくとも極端に言えば、その見方は、単語と文の区切り記号を標準化し、ラベルあたりの63オクテットの制限と、おそらくドメイン名の全長に対する255オクテットの制限を削除し、おそらく階層またはプレゼンテーション形式のラベルのセパレーター（現在はDNSの「。」に固定）をコンテキストに応じて異なるものにすることができます。少なくとも、元の設計は、一意で明確な識別子の優先順位付けに関連するより制限的なアプローチよりも、それらの使用を優先しない点で欠陥があったことを示唆しています。
So we have two or, depending on how one counts, three very different use cases. The historical one is support for unique identifiers. The other is expression of ideas and, if one considers them separate, presentation of brand and product names. Because they inherently involve different constraints, priorities, and success criteria, these perspectives are, at best, only loosely compatible.
したがって、2つ、またはその数に応じて3つの非常に異なるユースケースがあります。歴史的なものは、一意の識別子のサポートです。もう1つはアイデアの表現であり、別の考えではブランドと製品名の表現です。それらには本質的に異なる制約、優先順位、および成功基準が含まれるため、これらの視点はせいぜい、大まかにのみ互換性があります。
We cannot simultaneously optimize both the identifier perspective and either or both of the others in the same system. At best, there are some complex trade-offs involved. Even then, it is not clear that the same DNS (or other system) can accommodate all of them. Until we come to terms with that, the differences manifest themselves with friction among communities, most often with tension between "we want to do (or use or sell) these types of labels" and "not good for the operational Internet or the DNS".
同じシステムで、識別子の観点と他の一方または両方の両方を同時に最適化することはできません。せいぜい、いくつかの複雑なトレードオフが関係しています。それでも、同じDNS（または他のシステム）がそれらすべてに対応できるかどうかは明らかではありません。これに同意するまで、違いはコミュニティ間の摩擦で明らかになります。多くの場合、「これらのタイプのラベルを作成（または使用または販売）したい」と「インターネットやDNSの運用に適さない」の間の緊張が生じます。 。
A good many Internet policy discussions in the last two decades have revolved around such questions of how many top-level domains there should be, what they should be, who should control them and how, how (or if) their individual operations and policy decisions should be accountable to others, and what processes should be used (and by what entities or organizational structures) to make those decisions. Several people have pointed out that, if we were designing a next-generation DNS using today's technology, it should be possible to remove the technical requirement for a central authority over the root (some people have suggested that blockchain approaches would be helpful for this purpose; others believe they just would not scale adequately, at least at acceptable cost, but that other options are possible). Whether elimination of a single, centrally controlled, root would be desirable or not is fairly obviously a question of perspective and priorities.
過去20年間のインターネットポリシーに関する多くの議論は、トップレベルドメインがいくつあるべきか、それらが何であるべきか、誰がそれらを制御するべきか、そしてどのように（または、）個々の運用とポリシー決定についての質問を中心に展開してきました。他者に説明責任を負わせる必要があり、それらの決定を行うためにどのプロセスを（およびどのエンティティまたは組織構造によって）使用する必要があります。今日のテクノロジーを使用して次世代DNSを設計している場合、ルートに対する中央機関の技術要件を削除することができるはずであると指摘する人もいます（一部の人々は、ブロックチェーンアプローチがこの目的に役立つと示唆しています） ;他の人たちは、少なくとも許容できるコストでは適切にスケーリングしないだろうと信じていますが、他のオプションも可能であると考えています）。中央で管理されている単一のルートを削除することが望ましいかどうかは、明らかに、視点と優先順位の問題です。
New work done in other areas has led to demands for new DNS features, many of them involving data values that require recursively referencing the DNS. Early record types that did that were accompanied by restrictions that reduced the risk of looping references or other difficulties. For example, while the MX RRTYPE has a fully qualified domain name as its data, SMTP imposes "primary name" restrictions that prevent the name used from being, e.g., a CNAME. While loops with CNAMEs are possible, Section 3.6 of RFC 1034 includes a discussion about ways to avoid problems and how they should be handled. Some newer protocols and conventions can cause more stress. There are separate issues with additions and with how the DNS has been extended to try to deal with them.
他の分野で行われた新しい作業により、新しいDNS機能が必要になりました。その多くは、DNSを再帰的に参照する必要のあるデータ値に関係しています。これを行った初期のレコードタイプには、参照のループやその他の問題のリスクを軽減する制限が伴いました。たとえば、MX RRTYPEはデータとして完全修飾ドメイン名を持っていますが、SMTPは「プライマリ名」の制限を課し、使用されている名前がCNAMEなどになるのを防ぎます。 CNAMEを使用したループは可能ですが、RFC 1034のセクション3.6には、問題を回避する方法とその処理方法に関する議論が含まれています。いくつかの新しいプロトコルと規約は、より多くのストレスを引き起こす可能性があります。追加と、それらに対処するためにDNSがどのように拡張されたかには、別の問題があります。
Some examples of DNS extensions for new protocol demands that illustrate, or have led to, increased stress include:
ストレスの増大を説明する、またはその原因となった、新しいプロトコルの要求に対するDNS拡張の例には、次のものがあります。
NAPTR: Requires far more complex data in the DNS for ENUM (e.g., Voice over IP (VoIP), specifically SIP) support, including URI information and hence recursive or repeated lookups, than any of the RRTYPEs originally supported. The RRSET associated with these records can become quite large because the separator between the various records is part of the RDATA, and not the {owner, class, type} triple (a problem slightly related to the problem with overloading of TXT RRTYPE discussed in Section 3.13.2). This problem, and similar ones for some of the cases below. may suggest that any future design is in need of a different TYPE model such as systematic arrangements for subtypes or some explicit hierarchy in the TYPEs.
NAPTR：DNSでENUM（たとえば、Voice over IP（VoIP）、特にSIP）をサポートするために、URI情報、したがって再帰的または繰り返しのルックアップなど、元々サポートされているどのRRTYPEよりもはるかに複雑なデータが必要です。さまざまなレコード間のセパレーターは{所有者、クラス、タイプ}トリプルではなくRDATAの一部であるため、これらのレコードに関連付けられたRRSETは非常に大きくなる可能性があります（セクションで説明したTXT RRTYPEのオーバーロードの問題にわずかに関連する問題3.13.2）。この問題、および以下のいくつかのケースで同様の問題。今後の設計では、サブタイプの体系的な配置やTYPEの明示的な階層など、別のTYPEモデルが必要であることを示唆している場合があります。
URI: Has a URI as its data, typically also requiring recursive or repeated lookups.
URI：データとしてURIを持ち、通常は再帰的または反復的な検索も必要です。
Service location (SRV) and credential information (including Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM)): Require structured data and, especially for the latter two, significantly more data than most original RRTYPEs.
サービスの場所（SRV）と資格情報（Sender Policy Framework（SPF）とDomainKeys Identified Mail（DKIM）を含む）：構造化データが必要で、特に後者の2つは、ほとんどの元のRRTYPEよりもはるかに多くのデータが必要です。
URI/URL: The early design decision for the World Wide Web that its mechanism for identifying digital web content (now known as Uniform Resource Identifiers [RFC3986]) did so by using domain names and hence the network location of the information or other material. That, in turn, has required systems intended to improve web performance by locating and retrieving a "nearest copy" (rather than the single copy designated by the URL) to intercept DNS queries and respond with values that are not precisely those stored for the designated domain name in the DNS or to otherwise access information in a way not supported by the DNS itself.
URI / URL：デジタルWebコンテンツを識別するためのメカニズム（現在はUniform Resource Identifiers [RFC3986]として知られています）がドメイン名を使用し、それによって情報やその他の素材のネットワーク上の場所を使用することにより、World Wide Webの初期の設計決定。そのため、DNSクエリをインターセプトし、指定されたものに対して正確に保存されていない値で応答する「最も近いコピー」（URLで指定された単一のコピーではなく）を見つけて取得することにより、Webパフォーマンスを向上させることを目的としたシステムが必要でしたDNS内のドメイン名、またはDNS自体でサポートされていない方法で情報にアクセスするため。
Unfortunately (but unsurprisingly), and despite IETF efforts to make things easier [RFC6895], DNS support libraries have often been slow to add full support for new RRTYPEs. This has impeded deployment of applications that depend on those types and that must ask (query) explicitly for them. Both to get faster deployment and, at least until recently, to avoid burdensome IETF approval procedures, many application designers have chosen to push protocol-critical information into records with TXT RRTYPE, a record type that was originally intended to include only information equivalent to comments.
残念ながら（当然のことながら）、物事を容易にするためのIETFの取り組み[RFC6895]にも関わらず、DNSサポートライブラリは、新しいRRTYPEの完全なサポートを追加するのに時間がかかることがよくあります。これは、これらのタイプに依存し、それらを明示的に要求（クエリ）する必要があるアプリケーションのデプロイメントを妨げています。展開を迅速化するためと、少なくとも最近まで、厄介なIETF承認手順を回避するために、多くのアプリケーション設計者は、プロトコルに重要な情報を、もともとコメントと同等の情報のみを含めることを目的としたレコードタイプであるTXT RRTYPEを使用してレコードにプッシュすることを選択しました。 。
This causes two problems. First, TXT records used this way tend to get long and complex, which is a problem in itself if one is trying to minimize TCP connections. Second, applications that are attempting to obtain data cannot merely ask for the relevant QTYPE; they must obtain all of the records with QTYPE TXT and parse them to determine which ones are of interest. That would be easier if there was some standard for how to do that parsing, but, at least in part because the clear preference in the DNS design is for distinct RRTYPEs for different kinds of information, there is no such standard. (There was a proposal in 1993 to structure the TXT DATA in a way that would have addressed the issue [RFC1464], but it apparently never went anywhere.)
これにより2つの問題が発生します。まず、この方法で使用されるTXTレコードは長く複雑になる傾向があります。これは、TCP接続を最小化しようとする場合、それ自体が問題です。第2に、データを取得しようとしているアプリケーションは、関連するQTYPEを要求することはできません。 QTYPE TXTを使用してすべてのレコードを取得し、それらを解析して、関心のあるレコードを判別する必要があります。これは、その解析を行うための標準があればより簡単ですが、少なくとも一部には、DNS設計の明確な優先順位がさまざまな種類の情報に対する個別のRRTYPEであるため、そのような標準はありません。 （1993年に、問題[RFC1464]に対処する方法でTXT DATAを構成するという提案がありましたが、明らかにどこにも行きませんでした。）
On the other hand, this issue is somewhat different from most of the others described in this document because (as the IETF has recommended several times) the problem is easily solved within the current DNS design by allocating and supporting new RRTYPEs when needed rather than using TXT as a workaround (that does not mean that other solutions are impossible, either with the current DNS or with some other design). The problem then lies in the implementations and/or mechanisms that deter or impede rapid deployment of support for new RRTYPEs.
一方、この問題は、このドキュメントで説明されている他のほとんどの問題と多少異なります。これは、IETFが数回推奨しているため、現在のDNS設計内で、必要に応じて新しいRRTYPEを割り当ててサポートすることにより、問題を簡単に解決できるためです。回避策としてのTXT（現在のDNSまたは他の設計では他のソリューションが不可能であることを意味するものではありません）。その場合、問題は、新しいRRTYPEのサポートの迅速な展開を阻止または妨げる実装やメカニズムにあります。
One of the DNS characteristics that is poorly understood by non-experts is that the period (".", U+002E) character can be used in four different ways:
専門家以外にはあまり理解されていないDNS特性の1つは、ピリオド（ "。"、U + 002E）文字が4つの異なる方法で使用できることです。
o As a label separator in the presentation form that also designates a "zone break" (delegation boundary). For example, foo.bar.example.com indicates the owner, "foo", of records in the "bar.example.com" zone.
o 「ゾーンの区切り」（委任境界）も指定するプレゼンテーションフォームのラベルセパレーターとして。たとえば、foo.bar.example.comは、「bar.example.com」ゾーンのレコードの所有者「foo」を示します。
o As a label separator in the presentation form that does not designate a zone break. For example, foo.bar.example.com indicates the owner, "foo.bar", of records in the "example.com" zone.
o ゾーンブレークを指定しないプレゼンテーションフォームのラベルセパレータとして。たとえば、foo.bar.example.comは、「example.com」ゾーンのレコードの所有者「foo.bar」を示します。
o As a character within a label, including as a substitute for an at-sign ("@") when an email address appears in an SOA record or in a label that denotes such an address (see Section 2 above). The ability to embed periods in labels in this way has also led to attacks in which, e.g., a domain name consisting of the labels
o ラベル内の文字として、SOAレコードまたはそのようなアドレスを示すラベルに電子メールアドレスが表示される場合のアットマーク（ "@"）の代わりとして（上記のセクション2を参照）。このようにラベルにピリオドを埋め込む機能は、たとえば、ラベルで構成されるドメイン名が
"example" followed by "com" is deliberately confused with the single label "example.com" with an embedded period.
「example」の後に「com」が続くものは、ピリオドが埋め込まれた単一のラベル「example.com」と意図的に混同されています。
o At the end of a fully qualified domain name to designate the root zone, e.g., "example.com." (RFC 1034, Section 3.1).
o ルートゾーンを指定する完全修飾ドメイン名の末尾（例： "example.com"）。 （RFC 1034、セクション3.1）。
In general, these cases cannot be distinguished by looking at them. The third is problematic for non-DNS reasons, e.g., "john.doe.example.net" can be interpreted as either a simple FQDN or as a notation for john@doe.example.net, john.doe@example.net, or even (at least in principle) john.doe.example@net.
一般に、これらのケースはそれらを見ても区別できません。 3番目は、DNS以外の理由で問題があります。たとえば、「john.doe.example.net」は、単純なFQDNまたはjohn @ doe.example.net、john.doe @ example.netの表記として解釈できます。または（少なくとも原則として）john.doe.example@net。
The distinction between the FQDN interpretation and the first email-like one was probably not important as the DNS was originally intended to be used. However, as soon as RRTYPEs (other than NS records that define the zone cut) are used that are sensitive to the boundaries between zones, the distinctions become important to people other than the relevant zone administrators. DNSSEC [RFC4033] involves one such set of relationships. It increases the importance of questions about what should go in a parent zone and what should go in child zones and how much difference it makes if NS records in a parent zone for a child zone are consistent with the records and data in the child zone. This also causes application issues and may raise questions about relationships between registrars and one or more registries or, if they are separate, DNS operators.
FQDNの解釈と最初の電子メールのような解釈の違いは、DNSが本来使用されることを意図していたため、おそらく重要ではありませんでした。ただし、ゾーン間の境界に敏感なRRTYPE（ゾーンカットを定義するNSレコード以外）が使用されるとすぐに、関連するゾーン管理者以外の人々にとって区別が重要になります。 DNSSEC [RFC4033]には、そのような一連の関係が含まれます。親ゾーンに何を入れるべきか、子ゾーンに何を入れるべきか、および子ゾーンの親ゾーン内のNSレコードが子ゾーン内のレコードとデータと一致する場合にどの程度の違いがあるかについての質問の重要性が高まります。これはアプリケーションの問題も引き起こし、レジストラと1つ以上のレジストリ、またはそれらが別個の場合はDNSオペレーターの間の関係について疑問を投げかける可能性があります。
The original design for DNS administration, reflected in RFC 1591 [RFC1591] and elsewhere, assumed that all domains would exhibit a very high level of responsibility toward and for the community and that level of responsibility would be enforced if necessary.
RFC 1591 [RFC1591]などに反映されているDNS管理の元の設計では、すべてのドメインがコミュニティに対して、およびコミュニティに対して非常に高いレベルの責任を示し、必要に応じてそのレベルの責任が強制されると想定していました。
More recent decisions, many of them associated with commercialization of the DNS, have eroded those very strong assumptions of registry responsibility and accountability to the point that many consider decisions about delegation of names, identification of registrants, and relationships among names to be matters of "registrant beware" and even "user and applications beware". While some recent protocols and proposals at least partially reflect that original model of a high level of responsibility (see, e.g., IDNA [RFC5890] and a more recent discussion [Klensin-5891bis]), other decisions and actions tend to shift responsibility to the registrant or try to avoid accountability entirely. One possible approach to the problems, especially security problems, that are enabled by those new trends and the associated environment is to establish reputation systems associated with clearly defined administrative boundaries and with warnings to users, even if those reputation systems are managed by parties not directly associated with the DNS.
最近の決定は、その多くがDNSの商業化に関連しており、名前の委任、登録者の識別、および名前間の関係についての決定は「問題」であると多くの人が考えるまで、レジストリの責任と説明責任に関するこれらの非常に強力な仮定を侵食しています。登録者は注意してください」、さらには「ユーザーとアプリケーションは注意してください」。最近のプロトコルや提案の中には、高レベルの責任の元のモデルを少なくとも部分的に反映しているものがありますが（IDNA [RFC5890]および最近の議論[Klensin-5891bis]を参照）、他の決定やアクションは責任を登録者または説明責任を完全に回避しようとします。これらの新しいトレンドとそれに関連する環境によって可能になる問題、特にセキュリティの問題に対する1つの可能なアプローチは、明確に定義された管理境界とユーザーへの警告に関連付けられたレピュテーションシステムを確立することです。 DNSに関連付けられています。
The IETF DBOUND WG [IETF-DBOUND] addressed ways to establish and document boundaries more precise than simple dependencies on TLDs, but it was not successful in producing a standard.
IETF DBOUND WG [IETF-DBOUND]は、TLDへの単純な依存関係よりも正確に境界を確立して文書化する方法に取り組みましたが、標準の作成には成功しませんでした。
A TLD reputation-based approach was adopted by some web browsers after IDNs and a growing number of Generic Top-Level Domains (gTLDs) were introduced; that approach was based on a simple list and does not scale to the current size of the DNS or even the DNS root.
IDNと一般的なトップレベルドメイン（gTLD）の数が増えた後、TLDレピュテーションベースのアプローチが一部のWebブラウザーで採用されました。このアプローチは単純なリストに基づいており、DNSまたはDNSルートの現在のサイズにまでは拡大縮小されません。
The original design for the DNS envisaged a simple query and response protocol where both the command and the response could be readily mapped into a single IP packet. The host requirements specification [RFC1123] required all DNS applications to accept a UDP query or response over UDP with up to 512 octets of DNS payload. TCP was seen as a fallback when the response was greater than this 512-octet limit, and this fallback to use TCP as the transport protocol was considered to be the exception rather than the rule.
DNSの元の設計では、コマンドと応答の両方を1つのIPパケットに簡単にマッピングできる単純なクエリと応答プロトコルを想定していました。ホスト要件仕様[RFC1123]では、すべてのDNSアプリケーションが、最大512オクテットのDNSペイロードを使用して、UDPクエリまたはUDP経由の応答を受け入れる必要があります。応答がこの512オクテットの制限を超えると、TCPはフォールバックと見なされ、トランスポートプロトコルとしてTCPを使用するこのフォールバックは、ルールではなく例外と見なされました。
Over the intervening years, we have seen the rise of a common assumption of an Internet-wide Maximum Transmission Unit (MTU) size of 1,500 octets, accompanied with an assumption that UDP fragmentation is generally viable. This underpins the adoption of the Extension Mechanisms for DNS (EDNS(0)) [RFC6891] to, among other things, specify a UDP buffer size larger than 512 octets and a suggestion within that specification to use 4,096 as a suitable compromise for the UDP payload size. This has proved to be fortuitous for the DNSSEC security extensions where the addition of DNSSEC security credentials in DNS responses [RFC4034] can lead to the use of large DNS responses. However, this exposes some tensions over the handling of fragmentation in IP, where UDP fragments have been observed to be filtered by various firewalls. Additionally for IPv6, there are the factors of filtering the ICMPv6 Packet Too Big diagnostic messages and discarding the IPv6 packets that contain extension headers [RFC7872]. More generally, fragmented UDP packets appear to have a lower level of reliability than unfragmented TCP packets.
ここ数年、インターネット全体の最大伝送ユニット（MTU）サイズが1,500オクテットであるという一般的な仮定が高まり、UDPフラグメンテーションが一般的に実行可能であるという仮定が伴いました。これは、とりわけDNS（EDNS（0））[RFC6891]の拡張メカニズムの採用を支え、512オクテットより大きいUDPバッファーサイズを指定し、その仕様内でUDPの適切な妥協として4,096を使用することを提案します。ペイロードサイズ。これは、DNSSECセキュリティ拡張機能がDNS応答[RFC4034]にDNSSECセキュリティ資格情報を追加すると、大規模なDNS応答が使用される可能性があるため、偶然であることが証明されています。ただし、これにより、IPでのフラグメンテーションの処理にいくつかの緊張が生じます。UDPフラグメントは、さまざまなファイアウォールによってフィルタリングされることが確認されています。さらに、IPv6の場合、ICMPv6パケットが大きすぎるという診断メッセージをフィルタリングし、拡張ヘッダーを含むIPv6パケットを破棄する要素があります[RFC7872]。より一般的には、フラグメント化されたUDPパケットは、フラグメント化されていないTCPパケットよりも信頼性が低いように見えます。
Behind this observation about relative reliability of delivery is the tension between the lightweight load of UDP and the downside of elevated probability of discarding of packet fragments as compared to TCP, which offers increased levels of assurance of content delivery, but with the associated imposition of TCP session state and the downside of reduced DNS scalability and increased operational cost.
配信の相対的信頼性に関するこの観察の背後には、UDPの軽量の負荷と、TCPと比較してパケットフラグメントが破棄される確率が高くなるという欠点との間の緊張があります。セッション状態、およびDNSスケーラビリティの低下と運用コストの増加の欠点。
The requirement for an inverse lookup capability, i.e., the ability to find a domain name given an address and, in principle, to find the owner of a record by any of its data elements, was recognized in RFC 882. The feature was identified as optional but carried forward into RFCs 1034 and 1035 but was explicitly deprecated by RFC 1034 for address-to-hostname lookup (although RFC 1035 uses exactly that type of lookup in an example). Despite the discussion of inverted forms of the database in RFC 1035, inverse lookup has rarely, if ever, been implemented, at least in its general form. The fundamental difficulties with inverse lookup in either the form described in RFC 882 or the "in-addr.arpa" approach mentioned below are consistent with the problems described in fundamental papers on database management [Codd1970] but were not described in RFC 1035 or related contemporary IETF documents.
逆引き参照機能、つまり、アドレスを指定してドメイン名を検索し、原則として、データ要素のいずれかによってレコードの所有者を検索する機能の要件は、RFC 882で認識されていました。この機能は、オプションですが、RFC 1034と1035に持ち越されましたが、アドレスからホスト名へのルックアップのためにRFC 1034によって明示的に非推奨になりました（RFC 1035は、例ではそのタイプのルックアップを正確に使用しています）。 RFC 1035でのデータベースの反転形式の説明にもかかわらず、逆ルックアップは、少なくとも一般的な形式で実装されていることはほとんどありません。 RFC 882で説明されている形式の逆ルックアップまたは以下で説明する「in-addr.arpa」アプローチの基本的な問題は、データベース管理に関する基本的な論文[Codd1970]で説明されている問題と一致しますが、RFC 1035または関連では説明されていません最新のIETFドキュメント。
It is interesting to speculate on how many of the current requirements to treat aliases as an integrated set of synonyms (e.g., for variant handling) would have been addressed if inverse lookups could reliably produce the owners of CNAME records.
逆ルックアップがCNAMEレコードの所有者を確実に生成できる場合、エイリアスを統合された同義語のセット（たとえば、バリアント処理）として扱うための現在の要件の数を推測することは興味深いことです。
At the same time, it was obviously important to have some mechanism for address-to-name resolution. It was provided by PTR RRTYPE entries in the IN-ADDR.ARPA zone, with delegations on octet boundaries. However, that approach required that information be maintained in parallel, in separate zones, for the name-to-address and address-to-name mappings. That synchronization requirement for two copies of essentially the same data was another popular topic in the database management literature a decade or more before the DNS and, predictably, led to many inconsistencies and other failures.
同時に、アドレスから名前への解決のための何らかのメカニズムを持つことが明らかに重要でした。これは、IN-ADDR.ARPAゾーンのPTR RRTYPEエントリによって提供され、オクテット境界に委任があります。ただし、このアプローチでは、名前からアドレスへのマッピングとアドレスから名前へのマッピングのために、情報を別々のゾーンで並行して維持する必要がありました。本質的に同じデータの2つのコピーに対する同期要件は、DNSの10年以上前のデータベース管理に関する別の話題であり、予想通り、多くの不整合やその他の障害を引き起こしました。
The introduction of Classless Inter-Domain Routing (CIDR) [RFC1518] and Provider-Dependent addresses made the situation even more difficult, because it was no longer possible to delegate the administration of reverse mapping records for small networks to the actual operators of those networks. ISPs and other aggregators often had no incentive to maintain reverse mapping records consistent with network operator assignment of domain names. A proposal to use binary labels to work around that issue [RFC2673] was abandoned somewhat over three years later [RFC6891].
クラスレスドメイン間ルーティング（CIDR）[RFC1518]およびプロバイダー依存アドレスの導入により、小規模ネットワークのリバースマッピングレコードの管理をそれらのネットワークの実際のオペレーターに委任できなくなったため、状況はさらに困難になりました。 。 ISPや他のアグリゲーターは、ドメイン名のネットワークオペレーターの割り当てと一致するリバースマッピングレコードを維持するインセンティブを持たないことがよくありました。この問題を回避するためにバイナリラベルを使用する提案[RFC2673]は、3年後にやや断念されました[RFC6891]。
Independent of how much or little harm the absence of a general inverse lookup facility has caused and how effective the "in-addr.arpa" approach has been, inverse lookup remains a facility that was anticipated and known to be useful in the original DNS design but that has never been fully realized.
一般的な逆ルックアップ機能の欠如によって引き起こされた害の程度とは無関係に、「in-addr.arpa」アプローチがどれほど効果的であったかに関係なく、逆ルックアップは元のDNS設計で有用であると予想され、知られている機能のままです。しかし、それは完全には実現されていません。
In addition to the stresses caused by the new functions, including those described in Section 3.13, incremental deployment of systems that utilize them means that some functions will work in some environments and not others. This has been especially problematic with complex, multi-record, capabilities like DNSSEC that provide or require special validation mechanisms and with some EDNS(0) extensions [RFC6891] that require both the client and server to accept particular extensions. When DNS functionality is required in embedded devices, deployment of new features across the entire Internet in a reasonable period of time is nearly impossible.
セクション3.13で説明されているものを含む、新しい機能によって引き起こされるストレスに加えて、それらを利用するシステムの段階的な展開は、一部の機能が一部の環境では機能し、他の機能では機能しないことを意味します。これは、特別な検証メカニズムを提供または要求するDNSSECのような複雑なマルチレコード機能や、特定の拡張機能を受け入れるためにクライアントとサーバーの両方を必要とする一部のEDNS（0）拡張[RFC6891]で特に問題がありました。組み込みデバイスでDNS機能が必要な場合、妥当な期間内にインターネット全体に新機能を導入することはほぼ不可能です。
If one were redesigning the DNS, one could imagine ways to address these issues that would make them slightly more tractable, and, of course, the features that are known to be necessary today could become part of the baseline, "mandatory to implement", specification.
DNSを再設計する場合、これらの問題に対処する方法を想像することができます。これにより、DNSが少し扱いやすくなります。もちろん、今日必要であることがわかっている機能は、「実装が必須」のベースラインの一部になる可能性があります。仕様。
Some of the issues identified above might reasonably be addressed, not by changing the DNS itself but by changing our model of what it is about and how it is used. Specifically, one key assumption when the DNS (and the host table system before it) was designed was that it was a naming system for network resources, not, e.g., digital content. As such, exact matching was important, it was reasonable to have labels treated as mnemonics that did not necessarily have linguistic or semantic meaning except to those using them, and so on. A return to that model, presumably by having user-facing applications call on an intermediate layer to disambiguate user-friendly names and map them to DNS names (or network object locators more generally), would significantly reduce stress on the DNS and would also allow dealing with types of matching and similar or synonymous strings that cannot be handled algorithmically no matter how much DNS matching rules were altered.
上記で特定された問題のいくつかは、DNS自体を変更するのではなく、それについてのモデルとそれがどのように使用されるかのモデルを変更することによって、合理的に対処される可能性があります。具体的には、DNS（およびその前のホストテーブルシステム）が設計されたときの重要な前提の1つは、DNSがデジタルコンテンツなどではなく、ネットワークリソースの命名システムであることでした。そのため、完全一致が重要であり、ラベルを使用する場合を除いて、必ずしも言語的または意味的意味を持たないニーモニックとしてラベルを扱うことは妥当でした。そのモデルに戻ると、おそらくユーザー向けのアプリケーションが中間層を呼び出してユーザーフレンドリーな名前を明確にし、それらをDNS名（またはより一般的にはネットワークオブジェクトロケーター）にマップすることにより、DNSへの負荷が大幅に軽減され、変更されたDNSマッチングルールの量に関係なく、アルゴリズムで処理できないマッチングのタイプと類似または同義の文字列を処理する。
In some respects, search engines based on free-text analysis and linkages among information have come to serve many of the functions of such an intermediate layer. Many studies and sources have pointed out that few users actually understand, much less care about, the distinction between a DNS name and a search term. Recent versions of some web browsers have both recognized the failure of that distinction and reinforced it by eliminating the separation between "URL" and "search bar".
いくつかの点で、フリーテキスト分析と情報間のリンケージに基づく検索エンジンは、このような中間層の機能の多くを提供するようになりました。多くの調査や情報筋は、DNS名と検索用語の違いを実際に理解しているユーザーはほとんどいないと言っています。一部のWebブラウザーの最近のバージョンでは、その区別の失敗を認識し、「URL」と「検索バー」の分離をなくすことでそれを強化しています。
It is worth noting that, while that "search" approach, or some other approach that abstracted and separated several of the issues identified in Section 3 from the DNS protocol and database themselves, it does not address all of them. At least some elements of several of those issues, such as the synchronization ones described in Section 3.7 and the transport ones described in Section 3.15, are inherent in the DNS design, and, if we are not going to replace the DNS, we had best get used to them.
「検索」アプローチ、またはセクション3で特定されたいくつかの問題をDNSプロトコルおよびデータベース自体から抽象化および分離した他のアプローチは、それらすべてに対処するわけではないことに注意してください。セクション3.7で説明されている同期の問題やセクション3.15で説明されているトランスポートの問題など、これらの問題のいくつかの要素はDNS設計に固有のものであり、DNSを置き換える予定がない場合は、それらに慣れる。
In the early part of the last decade, the IETF engaged in some preliminary exploration of the intermediate-layer approach in the context of IDNs and what were then called "Internet keywords" [DNS-search]. While that exploratory effort met several times informally, it never became an organized IETF activity, largely because of the choice of what became the IDNA approach but also in part by signs that the "Internet keywords" efforts were beginning to fall apart.
この10年の初めに、IETFはIDNのコンテキストで中間層アプローチの予備調査を行い、その後「インターネットキーワード」[DNS検索]と呼ばれるものに取り組みました。その探索的取り組みは非公式に数回会合したが、主にIDNAアプローチとなるものの選択のためだけでなく、「インターネットキーワード」の取り組みがバラバラになり始めているという兆候もあり、組織的なIETF活動にはならなかった。
It may be time to reexamine intermediate-layer approaches. If so,
the effort should examine use of those approaches by appropriate
user-facing applications that might be used to address some of the
issues identified above. The Internet and the DNS have changed
considerably since the 2000-2003 period. Several of those changes
are discussed elsewhere in this document; others, including
repurposing of the DNAME RRTYPE from support for transitions
[RFC2672] to a general-purpose mechanism for aliases of subtrees
[RFC6672] and the addition of over a thousand new TLDs
[IANA-TLD-registry], are not but nonetheless are part of the context
for intermediate-layer work that did not exist in 2003.
A wide range of security issues related to both securing the DNS and also to abilities to use namespaces for nefarious purposes have arisen. Issues of securing the DNS would obviously be essential to a replacement of the DNS. Issues of preventing nefarious use of the namespace (e.g. use of the name that appears or disappears as a signal to bots) would appear to be harder to solve within the naming system.
DNSのセキュリティ保護と、悪意のある目的で名前空間を使用する機能の両方に関連する幅広いセキュリティの問題が発生しています。 DNSのセキュリティ保護の問題は、DNSの交換に不可欠であることは明らかです。名前空間の悪用を防止する問題（ボットへのシグナルとして表示または非表示になる名前の使用など）は、ネーミングシステム内で解決するのが難しいようです。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<https://www.rfc-editor.org/info/rfc1034>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https://www.rfc-editor.org/info/rfc1035>。
[CACM-Homograph] Gabrilovich, E. and A. Gontmakher, "The Homograph Attack", Communications of the ACM, Volume 45, Issue 2, pp. 128, DOI 10.1145/503124.503156, February 2002, <http://www.cs.technion.ac.il/~gabr/papers/ homograph_full.pdf>.
[CACM-ホモグラフ]ガブリロビッチ、E。、およびA.ゴントマカー、「ホモグラフ攻撃」、ACMの通信、45巻、第2号、128ページ、DOI 10.1145 / 503124.503156、2002年2月、<http：// www。 cs.technion.ac.il/~gabr/papers/homograph_full.pdf>。
[Cerf2017] Cerf, V., "Desirable Properties of Internet Identifiers", IEEE Internet Computing, Volume 21, Issue 6, pp. 63-64, DOI 10.1109/MIC.2017.4180839, November/December 2017.
[Cerf2017] Cerf、V。、「インターネット識別子の望ましいプロパティ」、IEEEインターネットコンピューティング、第21巻、第6号、63〜64ページ、DOI 10.1109 / MIC.2017.4180839、2017年11月/ 12月。
[Codd1970] Codd, E., "A Relational Model of Data for Large Shared Data Banks", Communications of the ACM, Volume 13, Issue 6, pp. 377-387, DOI 10.1145/362384.362685, June 1970, <https://dl.acm.org/citation.cfm?id=362685>.
[Codd1970] Codd、E。、「大規模な共有データバンクのデータのリレーショナルモデル」、ACMの通信、第13巻、第6号、377-387ページ、DOI 10.1145 / 362384.362685、1970年6月、<https：/ /dl.acm.org/citation.cfm?id=362685>。
[DNS-Aliases] Woolf, S., Lee, X., and J. Yao, "Problem Statement: DNS Resolution of Aliased Names", Work in Progress, draft-ietf-dnsext-aliasing-requirements-01, March 2011.
[DNSエイリアス] Woolf、S.、Lee、X。、およびJ. Yao、「問題ステートメント：エイリアス名のDNS解決」、作業中、draft-ietf-dnsext-aliasing-requirements-01、2011年3月。
[DNS-BNAME] Yao, J., Lee, X., and P. Vixie, "Bundled DNS Name Redirection", Work in Progress, draft-yao-dnsext-bname-06, May 2016.
[DNS-BNAME] Yao、J.、Lee、X。、およびP. Vixie、「Bundled DNS Name Redirection」、Work in Progress、draft-yao-dnsext-bname-06、May 2016。
[DNS-search] IETF, "Internet Resource Name Search Service (IRNSS)", 2003, <https://datatracker.ietf.org/wg/irnss/about/>.
[DNS-search] IETF、「インターネットリソース名検索サービス（IRNSS）」、2003、<https://datatracker.ietf.org/wg/irnss/about/>。
[Faltstrom-2004] Faltstrom, P. and R. Austein, "Design Choices When Expanding DNS", Work in Progress, draft-ymbk-dns-choices-00, May 2004.
[Faltstrom-2004] Faltstrom、P。およびR. Austein、「DNSを拡張する際の設計上の選択」、作業中、draft-ymbk-dns-choices-00、2004年5月。
[Hoffman-DNS-JSON] Hoffman, P., "Representing DNS Messages in JSON", Work in Progress, draft-hoffman-dns-in-json-13, October 2017.
[Hoffman-DNS-JSON] Hoffman、P。、「Representing DNS Messages in JSON」、Work in Progress、draft-hoffman-dns-in-json-13、2017年10月。
[Hoffman-SimpleDNS-JSON] Hoffman, P., "Simple DNS Queries and Responses in JSON", Work in Progress, draft-hoffman-simplednsjson-01, November 2017.
[Hoffman-SimpleDNS-JSON]ホフマン、P。、「JSONでの単純なDNSクエリと応答」、作業中、draft-hoffman-simplednsjson-01、2017年11月。
[Huston2017a] Huston, G. and J. Silva Dama, "DNS Privacy", The Internet Protocol Journal, Vol. 20, No. 1, March 2017, <http://ipj.dreamhosters.com/wp-content/uploads/ issues/2017/ipj20-1.pdf>.
[Huston2017a] Huston、G.およびJ. Silva Dama、「DNS Privacy」、The Internet Protocol Journal、Vol。 20、No。1、2017年3月、<http://ipj.dreamhosters.com/wp-content/uploads/issues/2017/ipj20-1.pdf>。
[Huston2017b] Huston, G., "The Root of the Domain Name System", The Internet Protocol Journal, Vol. 20, No. 2, pp. 15-25, June 2017, <http://ipj.dreamhosters.com/wp-content/uploads/ 2017/08/ipj20-2.pdf>.
[Huston2017b] Huston、G。、「The Root of the Domain Name System」、The Internet Protocol Journal、Vol。 20、No。2、pp。15-25、2017年6月、<http://ipj.dreamhosters.com/wp-content/uploads/ 2017/08 / ipj20-2.pdf>。
[IANA-TLD-registry] Internet Assigned Numbers Authority (IANA), "Root Zone Database", <https://www.iana.org/domains/root/db>.
[IANA-TLD-registry] Internet Assigned Numbers Authority（IANA）、「Root Zone Database」、<https://www.iana.org/domains/root/db>。
[ICANN-VIP] ICANN, "IDN Variant Issues Project: Final Integrated Issues Report Published and Proposed Project Plan for Next Steps is Now Open for Public Comment", February 2012, <https://www.icann.org/news/announcement-2012-02-20-en>.
[ICANN-VIP] ICANN、「IDN Variant Issues Project：Final Integrated Issues Report Published and Proposed Project Plan for Next Steps is now open for Public Comment」、2012年2月、<https://www.icann.org/news/announcement -2012-02-20-en>。
[IETF-DBOUND] IETF, "Domain Boundaries (dbound)", 2017, <https://datatracker.ietf.org/wg/dbound/about/>.
[IETF-DBOUND] IETF、「ドメイン境界（dbound）」、2017、<https://datatracker.ietf.org/wg/dbound/about/>。
[Klensin-5891bis] Klensin, J. and A. Freytag, "Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations", Work in Progress, draft-klensin-idna-rfc5891bis-01, September 2017.
[Klensin-5891bis] Klensin、J.およびA. Freytag、「Internationalized Domain Names in Applications（IDNA）：Registry Restrictions and Recommendations」、Work in Progress、draft-klensin-idna-rfc5891bis-01、2017年9月。
[Mockapetris-1988] Mockapetris, P. and K. Dunlap, "Development of the Domain Name System", SIGCOMM '88 Symposium, pp. 123-133, available from ISI Reprint Series, ISI/RS-88-219 <ftp://ftp.isi.edu/isi-pubs/rs-88-219.pdf>, DOI 10.1145/52324.52338, August 1988, <http://dl.acm.org/citation.cfm?id=52338>.
[Mockapetris-1988] Mockapetris、P。およびK. Dunlap、「Development of the Domain Name System」、SIGCOMM '88 Symposium、pp。123-133、ISI Reprint Series、ISI / RS-88-219 <ftp： //ftp.isi.edu/isi-pubs/rs-88-219.pdf>、DOI 10.1145 / 52324.52338、1988年8月、<http://dl.acm.org/citation.cfm?id=52338>。
[NRC-Signposts] National Research Council, Signposts in Cyberspace: The Domain Name System and Internet Navigation, ISBN 0-309-54979-5, 2005, <https://www.nap.edu/ catalog/11258/signposts-in-cyberspace-the-domain-name-system-and-internet-navigation>.
[NRC-Signposts] National Research Council、Signposts in Cyberspace：The Domain Name System and Internet Navigation、ISBN 0-309-54979-5、2005、<https://www.nap.edu/ catalog / 11258 / signposts-in -cyberspace-the-domain-name-system-and-internet-navigation>。
[RFC0236] Postel, J., "Standard host names", RFC 236, DOI 10.17487/RFC0236, September 1971, <https://www.rfc-editor.org/info/rfc236>.
[RFC0236] Postel、J。、「Standard host names」、RFC 236、DOI 10.17487 / RFC0236、1971年9月、<https://www.rfc-editor.org/info/rfc236>。
[RFC0247] Karp, P., "Proffered set of standard host names", RFC 247, DOI 10.17487/RFC0247, October 1971, <https://www.rfc-editor.org/info/rfc247>.
[RFC0247] Karp、P。、「Proffered set of standard host names」、RFC 247、DOI 10.17487 / RFC0247、1971年10月、<https://www.rfc-editor.org/info/rfc247>。
[RFC0799] Mills, D., "Internet name domains", RFC 799, DOI 10.17487/RFC0799, September 1981, <https://www.rfc-editor.org/info/rfc799>.
[RFC0799] Mills、D。、「インターネット名ドメイン」、RFC 799、DOI 10.17487 / RFC0799、1981年9月、<https://www.rfc-editor.org/info/rfc799>。
[RFC0810] Feinler, E., Harrenstien, K., Su, Z., and V. White, "DoD Internet host table specification", RFC 810, DOI 10.17487/RFC0810, March 1982, <https://www.rfc-editor.org/info/rfc810>.
[RFC0810]ファインラー、E。、ハレンスティエン、K.、Su、Z。、およびV.ホワイト、「DoDインターネットホストテーブルの仕様」、RFC 810、DOI 10.17487 / RFC0810、1982年3月、<https：//www.rfc -editor.org/info/rfc810>。
[RFC0881] Postel, J., "Domain names plan and schedule", RFC 881, DOI 10.17487/RFC0881, November 1983, <https://www.rfc-editor.org/info/rfc881>.
[RFC0881] Postel、J。、「ドメイン名の計画とスケジュール」、RFC 881、DOI 10.17487 / RFC0881、1983年11月、<https://www.rfc-editor.org/info/rfc881>。
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", RFC 882, DOI 10.17487/RFC0882, November 1983, <https://www.rfc-editor.org/info/rfc882>.
[RFC0882] Mockapetris、P。、「ドメイン名：概念と機能」、RFC 882、DOI 10.17487 / RFC0882、1983年11月、<https://www.rfc-editor.org/info/rfc882>。
[RFC0883] Mockapetris, P., "Domain names: Implementation specification", RFC 883, DOI 10.17487/RFC0883, November 1983, <https://www.rfc-editor.org/info/rfc883>.
[RFC0883] Mockapetris、P。、「ドメイン名：実装仕様」、RFC 883、DOI 10.17487 / RFC0883、1983年11月、<https://www.rfc-editor.org/info/rfc883>。
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, DOI 10.17487/RFC0952, October 1985, <https://www.rfc-editor.org/info/rfc952>.
[RFC0952] Harrenstien、K.、Stahl、M。、およびE. Feinler、「DoD Internet host table specification」、RFC 952、DOI 10.17487 / RFC0952、1985年10月、<https://www.rfc-editor.org/ info / rfc952>。
[RFC0953] Harrenstien, K., Stahl, M., and E. Feinler, "Hostname Server", RFC 953, DOI 10.17487/RFC0953, October 1985, <https://www.rfc-editor.org/info/rfc953>.
[RFC0953] Harrenstien、K.、Stahl、M。、およびE. Feinler、「Hostname Server」、RFC 953、DOI 10.17487 / RFC0953、1985年10月、<https://www.rfc-editor.org/info/rfc953 >。
[RFC0974] Partridge, C., "Mail routing and the domain system", STD 10, RFC 974, DOI 10.17487/RFC0974, January 1986, <https://www.rfc-editor.org/info/rfc974>.
[RFC0974] Partridge、C。、「Mail routing and the domain system」、STD 10、RFC 974、DOI 10.17487 / RFC0974、1986年1月、<https://www.rfc-editor.org/info/rfc974>。
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>.
[RFC1123] Braden、R。、編、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、DOI 10.17487 / RFC1123、1989年10月、<https://www.rfc-editor.org/info / rfc1123>。
[RFC1464] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary String Attributes", RFC 1464, DOI 10.17487/RFC1464, May 1993, <https://www.rfc-editor.org/info/rfc1464>.
[RFC1464] Rosenbaum、R。、「ドメインネームシステムを使用して任意の文字列属性を保存する」、RFC 1464、DOI 10.17487 / RFC1464、1993年5月、<https://www.rfc-editor.org/info/rfc1464>。
[RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, DOI 10.17487/RFC1518, September 1993, <https://www.rfc-editor.org/info/rfc1518>.
[RFC1518] Rekhter、Y。およびT. Li、「CIDRを使用したIPアドレス割り当てのアーキテクチャ」、RFC 1518、DOI 10.17487 / RFC1518、1993年9月、<https://www.rfc-editor.org/info/rfc1518 >。
[RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, DOI 10.17487/RFC1591, March 1994, <https://www.rfc-editor.org/info/rfc1591>.
[RFC1591] Postel、J。、「ドメインネームシステムの構造と委任」、RFC 1591、DOI 10.17487 / RFC1591、1994年3月、<https://www.rfc-editor.org/info/rfc1591>。
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996, <https://www.rfc-editor.org/info/rfc1996>.
[RFC1996] Vixie、P。、「ゾーン変更の迅速な通知のためのメカニズム（DNS NOTIFY）」、RFC 1996、DOI 10.17487 / RFC1996、1996年8月、<https://www.rfc-editor.org/info/rfc1996 >。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, DOI 10.17487/RFC2671, August 1999, <https://www.rfc-editor.org/info/rfc2671>.
[RFC2671] Vixie、P。、「DNS（EDNS0）の拡張メカニズム」、RFC 2671、DOI 10.17487 / RFC2671、1999年8月、<https://www.rfc-editor.org/info/rfc2671>。
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, DOI 10.17487/RFC2672, August 1999, <https://www.rfc-editor.org/info/rfc2672>.
[RFC2672]クロフォード、M。、「非ターミナルDNS名リダイレクト」、RFC 2672、DOI 10.17487 / RFC2672、1999年8月、<https://www.rfc-editor.org/info/rfc2672>。
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, DOI 10.17487/RFC2673, August 1999, <https://www.rfc-editor.org/info/rfc2673>.
[RFC2673]クロフォードM.、「ドメインネームシステムのバイナリラベル」、RFC 2673、DOI 10.17487 / RFC2673、1999年8月、<https://www.rfc-editor.org/info/rfc2673>。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, DOI 10.17487/RFC3490, March 2003, <https://www.rfc-editor.org/info/rfc3490>.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「Internationalizing Domain Names in Applications（IDNA）」、RFC 3490、DOI 10.17487 / RFC3490、2003年3月、<https：//www.rfc-editor .org / info / rfc3490>。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, DOI 10.17487/RFC3491, March 2003, <https://www.rfc-editor.org/info/rfc3491>.
[RFC3491] Hoffman、P.およびM. Blanchet、「Nameprep：国際化ドメイン名（IDN）のStringprepプロファイル」、RFC 3491、DOI 10.17487 / RFC3491、2003年3月、<https://www.rfc-editor.org / info / rfc3491>。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, October 2003, <https://www.rfc-editor.org/info/rfc3596>.
[RFC3596] Thomson、S.、Huitema、C.、Ksinant、V。、およびM. Souissi、「DNS Extensions to Support IP Version 6」、STD 88、RFC 3596、DOI 10.17487 / RFC3596、2003年10月、<https： //www.rfc-editor.org/info/rfc3596>。
[RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean", RFC 3743, DOI 10.17487/RFC3743, April 2004, <https://www.rfc-editor.org/info/rfc3743>.
[RFC3743]コニシK.、ファンK.、キアンH.、Y。コ、「中国語、日本語、韓国語向けの国際化ドメイン名（IDN）登録および管理に関する共同エンジニアリングチーム（JET）ガイドライン」、 RFC 3743、DOI 10.17487 / RFC3743、2004年4月、<https://www.rfc-editor.org/info/rfc3743>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：/ /www.rfc-editor.org/info/rfc3986>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<https： //www.rfc-editor.org/info/rfc4033>。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/info/rfc4034>.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、< https://www.rfc-editor.org/info/rfc4034>。
[RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, DOI 10.17487/RFC4343, January 2006, <https://www.rfc-editor.org/info/rfc4343>.
[RFC4343] Eastlake 3rd、D。、「ドメインネームシステム（DNS）の大文字と小文字の区別の明確化」、RFC 4343、DOI 10.17487 / RFC4343、2006年1月、<https://www.rfc-editor.org/info/rfc4343>。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.
[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、DOI 10.17487 / RFC5890、2010年8月、<https://www.rfc-editor.org/info/ rfc5890>。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-editor.org/info/rfc5891>.
[RFC5891] Klensin、J。、「Internationalized Domain Names in Applications（IDNA）：Protocol」、RFC 5891、DOI 10.17487 / RFC5891、2010年8月、<https://www.rfc-editor.org/info/rfc5891>。
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, <https://www.rfc-editor.org/info/rfc6672>.
[RFC6672] Rose、S。およびW. Wijngaards、「DNSでのDNAMEリダイレクション」、RFC 6672、DOI 10.17487 / RFC6672、2012年6月、<https://www.rfc-editor.org/info/rfc6672>。
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, <https://www.rfc-editor.org/info/rfc6761>.
[RFC6761] Cheshire、S。およびM. Krochmal、「特殊用途ドメイン名」、RFC 6761、DOI 10.17487 / RFC6761、2013年2月、<https://www.rfc-editor.org/info/rfc6761>。
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>.
[RFC6891] Damas、J.、Graff、M。、およびP. Vixie、「DNSの拡張メカニズム（EDNS（0））」、STD 75、RFC 6891、DOI 10.17487 / RFC6891、2013年4月、<https：// www.rfc-editor.org/info/rfc6891>。
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[RFC6895] Eastlake 3rd、D。、「ドメインネームシステム（DNS）IANAに関する考慮事項」、BCP 42、RFC 6895、DOI 10.17487 / RFC6895、2013年4月、<https://www.rfc-editor.org/info/rfc6895 >。
[RFC6912] Sullivan, A., Thaler, D., Klensin, J., and O. Kolkman, "Principles for Unicode Code Point Inclusion in Labels in the DNS", RFC 6912, DOI 10.17487/RFC6912, April 2013, <https://www.rfc-editor.org/info/rfc6912>.
[RFC6912]サリバン、A。、タラー、D。、クレンシン、J。、およびO.コルクマン、「DNSのラベルにUnicodeコードポイントを含めるための原則」、RFC 6912、DOI 10.17487 / RFC6912、2013年4月、<https ：//www.rfc-editor.org/info/rfc6912>。
[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, DOI 10.17487/RFC7094, January 2014, <https://www.rfc-editor.org/info/rfc7094>.
[RFC7094] McPherson、D.、Oran、D.、Thaler、D。、およびE. Osterweil、「IP Anycastのアーキテクチャに関する考慮事項」、RFC 7094、DOI 10.17487 / RFC7094、2014年1月、<https：//www.rfc -editor.org/info/rfc7094>。
[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root Servers by Running One on Loopback", RFC 7706, DOI 10.17487/RFC7706, November 2015, <https://www.rfc-editor.org/info/rfc7706>.
[RFC7706] Kumari、W.およびP. Hoffman、「Decreting Access Time to Root Servers on One on Loopback」、RFC 7706、DOI 10.17487 / RFC7706、2015年11月、<https://www.rfc-editor.org/ info / rfc7706>。
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, <https://www.rfc-editor.org/info/rfc7719>.
[RFC7719]ホフマン、P。、サリバン、A。、およびK.藤原、「DNS用語」、RFC 7719、DOI 10.17487 / RFC7719、2015年12月、<https://www.rfc-editor.org/info/rfc7719 >。
[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, <https://www.rfc-editor.org/info/rfc7816>.
[RFC7816] Bortzmeyer、S。、「プライバシーを改善するためのDNSクエリ名の最小化」、RFC 7816、DOI 10.17487 / RFC7816、2016年3月、<https://www.rfc-editor.org/info/rfc7816>。
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7858] Hu、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D。、およびP. Hoffman、「DNS over Transport Layer Security（TLS）の仕様」、RFC 7858、DOI 10.17487 / RFC7858、2016年5月、<https://www.rfc-editor.org/info/rfc7858>。
[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, <https://www.rfc-editor.org/info/rfc7872>.
[RFC7872] Gont、F.、Linkova、J.、Chown、T。、およびW. Liu、「実際のIPv6拡張ヘッダーを使用したパケットのドロップに関する観察」、RFC 7872、DOI 10.17487 / RFC7872、2016年6月、<https://www.rfc-editor.org/info/rfc7872>。
[RFC8244] Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain Names Problem Statement", RFC 8244, DOI 10.17487/RFC8244, October 2017, <https://www.rfc-editor.org/info/rfc8244>.
[RFC8244] Lemon、T.、Droms、R。、およびW. Kumari、「Special-Use Domain Names Problem Statement」、RFC 8244、DOI 10.17487 / RFC8244、2017年10月、<https：//www.rfc-editor。 org / info / rfc8244>。
[Sullivan-Class] Sullivan, A., "The DNS Is Not Classy: DNS Classes Considered Useless", Work in Progress, draft-sullivan-dns-class-useless-03, July 2016.
[Sullivan-Class] Sullivan、A。、「DNSは上品ではない：DNSクラスは役に立たないと見なされている」、進行中の作業、draft-sullivan-dns-class-useless-03、2016年7月。
[Unicode] The Unicode Consortium, The Unicode Standard, Version 9.0.0, (Mountain View, CA: The Unicode Consortium, 2016. ISBN 978-1-936213-13-9), <http://www.unicode.org/versions/Unicode9.0.0/>.
[Unicode] Unicode Consortium、The Unicode Standard、バージョン9.0.0（Mountain View、CA：The Unicode Consortium、2016。ISBN978-1-936213-13-9）、<http://www.unicode.org /versions/Unicode9.0.0/>。
[Unicode-UAX15] Davis, M. and K. Whistler, "Unicode Standard Annex #15: Unicode Normalization Forms", February 2016, <http://unicode.org/reports/tr15/>.
[Unicode-UAX15] Davis、M.およびK. Whistler、「Unicode Standard Annex＃15：Unicode Normalization Forms」、2016年2月、<http://unicode.org/reports/tr15/>。
[Unicode-USA31] Davis, M., "Unicode Standard Annex #31: Unicode Identifier and Pattern Syntax", May 2016, <http://unicode.org/reports/tr31/>.
[Unicode-USA31] Davis、M。、「Unicode Standard Annex＃31：Unicode Identifier and Pattern Syntax」、2016年5月、<http://unicode.org/reports/tr31/>。
[Vixie-20170704] Vixie, P., "Subject: Re: new DNS classes", message to the IETF dnsop mailing list, 4 July 2017, <https://www.ietf.org/mail-archive/web/ietf/current/ msg103486.html>.
[Vixie-20170704] Vixie、P。、「Subject：Re：new DNS classes」、IETF dnsopメーリングリストへのメッセージ、2017年7月4日、<https://www.ietf.org/mail-archive/web/ietf / current / msg103486.html>。
Acknowledgements
謝辞
Many of the concerns and ideas described in this document reflect conversations over a period of many years, some rooted in DNS "keyword" and "search" discussions that paralleled the development of IDNs. Conversations with, or writings of, Rob Austein, Christine Borgman, Carolina Carvalho, Vint Cerf, Lyman Chapin, Nazli Choucri, Patrik Faltstrom, Geoff Huston, Xiaodong Lee, Karen Liu, Gervase Markham, Yaqub Mueller, Andrew Sullivan, Paul Twomey, Nico Williams, Suzanne Woolf, Jiankang Yao, other participants in the circa 2003 "DNS Search" effort and in the ICANN SSAC Working Party on IDNs, and some others whose names were sadly forgotten, were particularly important to either the content of this document or the motivation for writing it even though they may not agree with the conclusions I have reached and bear no responsibility for them.
このドキュメントで説明されている懸念事項やアイデアの多くは、長年にわたる会話を反映しており、IDNの開発と並行するDNSの「キーワード」と「検索」の議論に根差したものもありました。 Rob Austein、Christine Borgman、Carolina Carvalho、Vint Cerf、Lyman Chapin、Nazli Choucri、Patrik Faltstrom、Geoff Huston、Xiaodong Lee、Karen Liu、Gervase Markham、Yaqub Mueller、Andrew Sullivan、Paul Twomey、Nicoとの会話または著作ウィリアムズ、スザンヌウルフ、ジャンカンヤオ、2003年頃の「DNS検索」の取り組み、およびIDNに関するICANN SSACワーキングパーティーの他の参加者、そして名前が忘れられていた他の人々は、このドキュメントの内容または彼らが私が到達した結論に同意せず、彼らに対して責任を負わない場合でも、それを書く動機。
Many of the subsections of Section 3 were extracted from comments first made in conjunction with recent email discussions. Comments from Suzanne Woolf about an earlier draft version were particularly important as was material developed with suggestions from Patrik Faltstrom, especially Section 3.13. Feedback and suggestions from several of the above and from Stephane Bortzmeyer, Tony Finch, Bob Harold, Warren Kumari, Craig Partridge, and George Sadowsky were extremely helpful for improving the clarity and accuracy of parts of the document, especially so for a broader audience. Craig Partridge also contributed much of the material about queries for multiple types. Geoff Huston made several useful comments and contributed most of Section 3.15, and Bill Manning pointed out some broader requirements about integrity of information and DNS management and operations.
セクション3のサブセクションの多くは、最近の電子メールディスカッションに関連して最初に行われたコメントから抽出されました。以前のドラフトバージョンに関するSuzanne Woolfからのコメントは、Patrik Faltstromの提案、特にセクション3.13の提案に基づいて開発された資料と同様に、特に重要です。上記のいくつかと、Stephane Bortzmeyer、Tony Finch、Bob Harold、Warren Kumari、Craig Partridge、およびGeorge Sadowskyからのフィードバックと提案は、ドキュメントの一部の明快さと正確さを向上させるのに非常に役立ちました。 Craig Partridgeは、複数のタイプのクエリに関する資料の多くにも貢献しました。 Geoff Hustonはいくつかの有用なコメントをし、セクション3.15の大部分に貢献し、Bill Manningは情報の整合性とDNS管理と運用に関するいくつかのより広い要件を指摘しました。
Special thanks are due to Karen Moore of the RFC Production Center for her efforts, patience, and persistence in preparing this document for publication, a process that raised far more issues that required careful discussion than usual.
このドキュメントを公開するための準備、忍耐力、粘り強く、RFC Production CenterのKaren Mooreに感謝します。このプロセスは、通常よりも慎重な議論を必要とするはるかに多くの問題を引き起こしました。
Author's Address
著者のアドレス
John C. Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 United States of America
John C. Klensin 1770 Massachusetts Ave、Ste 322 Cambridge、MA 02140アメリカ合衆国
Phone: +1 617 245 1457
Email: john-ietf@jck.com