Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 9499 ICANN
BCP: 219 K. Fujiwara
Obsoletes: 8499 JPRS
Updates: 2308 March 2024
Category: Best Current Practice
ISSN: 2070-1721
The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.
ドメイン名システム（DNS）は、文字通り数十の異なるRFCで定義されています。DNSプロトコルの実装者と開発者、およびDNSシステムのオペレーターが使用する用語は、DNSが最初に定義されてから数十年で変化しました。このドキュメントは、単一のドキュメントでDNSで使用されている多くの用語の現在の定義を提供します。
This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B.
このドキュメントは、「フォワーダー」と「QName」の定義を明確にすることにより、RFC 2308を更新します。複数の用語と明確化を追加することにより、RFC 8499を廃止します。変更された変更と新しい定義の包括的なリストは、付録AおよびBにあります。
This memo documents an Internet Best Current Practice.
このメモは、インターネットの最高の現在の練習を文書化しています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。BCPSの詳細については、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/rfc9499.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9499で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Names
3. DNS Response Codes
4. DNS Transactions
5. Resource Records
6. DNS Servers and Clients
7. Zones
8. Wildcards
9. Registration Model
10. General DNSSEC
11. DNSSEC States
12. Security Considerations
13. IANA Considerations
14. References
14.1. Normative References
14.2. Informative References
Appendix A. Definitions Updated by This Document
Appendix B. Definitions First Defined in This Document
Acknowledgements
Index
Authors' Addresses
The Domain Name System (DNS) is a simple query-response protocol whose messages in both directions have the same format. (Section 2 gives a definition of "global DNS", which is often what people mean when they say "the DNS".) The protocol and message format are defined in [RFC1034] and [RFC1035]. These RFCs defined some terms, and later documents defined others. Some of the terms from [RFC1034] and [RFC1035] have somewhat different meanings now than they did in 1987.
ドメイン名システム（DNS）は、両方向のメッセージが同じ形式を持っている単純なクエリ応答プロトコルです。（セクション2では、「グローバルDNS」の定義を示します。これは、多くの場合、「DNS」と言うときに人々が意味するものです。）プロトコルとメッセージ形式は[RFC1034]および[RFC1035]で定義されています。これらのRFCはいくつかの用語を定義し、後のドキュメントで他の文書を定義しました。[RFC1034]および[RFC1035]の用語の一部は、1987年とは多少異なる意味を持っています。
This document contains a collection of a wide variety of DNS-related terms, organized loosely by topic. Some of them have been precisely defined in earlier RFCs, some have been loosely defined in earlier RFCs, and some are not defined in an earlier RFC at all.
このドキュメントには、トピックごとにゆるく整理されたさまざまなDNS関連用語のコレクションが含まれています。それらのいくつかは以前のRFCで正確に定義されており、一部は以前のRFCでゆるく定義されており、一部は以前のRFCではまったく定義されていません。
Other organizations sometimes define DNS-related terms in their own way. For example, the WHATWG defines "domain" at <https://url.spec.whatwg.org/>. The Root Server System Advisory Committee (RSSAC) has a good lexicon [RSSAC026].
他の組織は、DNS関連の用語を独自の方法で定義することがあります。たとえば、whatwgは<https://url.spec.whatwg.org/>で「ドメイン」を定義します。ルートサーバーシステムアドバイザリー委員会（RSSAC）には、優れたレキシコンがあります[RSSAC026]。
Most of the definitions listed here represent the consensus definition of the DNS community -- both protocol developers and operators. Some of the definitions differ from earlier RFCs, and those differences are noted. In this document, where the consensus definition is the same as the one in an RFC, that RFC is quoted. Where the consensus definition has changed somewhat, the RFC is mentioned but the new stand-alone definition is given. See Appendix A for a list of the definitions that this document updates.
ここにリストされている定義のほとんどは、DNSコミュニティのコンセンサス定義（プロトコル開発者とオペレーターの両方）を表しています。定義のいくつかは以前のRFCとは異なり、それらの違いが認められています。このドキュメントでは、コンセンサス定義がRFCの定義と同じで、RFCが引用されています。コンセンサス定義が多少変更された場合、RFCが言及されていますが、新しいスタンドアロン定義が示されています。このドキュメントが更新される定義のリストについては、付録Aを参照してください。
It is important to note that, during the development of this document, it became clear that some DNS-related terms are interpreted quite differently by different DNS experts. Further, some terms that are defined in early DNS RFCs now have definitions that are generally agreed to, but that are different from the original definitions. This document is a small revision to [RFC8499]; that document was a substantial revision to [RFC7719].
このドキュメントの開発中に、DNS関連の用語の一部は、DNSの専門家によって非常に異なって解釈されることが明らかになったことに注意することが重要です。さらに、初期のDNS RFCで定義されているいくつかの用語には、一般的に合意されているが、元の定義とは異なる定義があります。このドキュメントは、[RFC8499]の小さな改訂です。その文書は[RFC7719]の大幅な改訂でした。
Note that there is no single consistent definition of "the DNS". It can be considered to be some combination of the following: a commonly used naming scheme for objects on the Internet; a distributed database representing the names and certain properties of these objects; an architecture providing distributed maintenance, resilience, and loose coherency for this database; and a simple query-response protocol (as mentioned below) implementing this architecture. Section 2 defines "global DNS" and "private DNS" as a way to deal with these differing definitions.
「DNS」の一貫した定義は1つないことに注意してください。これは、以下の何らかの組み合わせと見なすことができます。インターネット上のオブジェクトに一般的に使用される命名スキーム。これらのオブジェクトの名前と特定のプロパティを表す分散データベース。このデータベースの分散メンテナンス、回復力、およびゆるい一貫性を提供するアーキテクチャ。このアーキテクチャを実装する簡単なクエリ応答プロトコル（以下に言及）。セクション2では、これらの異なる定義に対処する方法として「グローバルDNS」と「プライベートDNS」を定義します。
Capitalization in DNS terms is often inconsistent among RFCs and various DNS practitioners. The capitalization used in this document is a best guess at current practices, and is not meant to indicate that other capitalization styles are wrong or archaic. In some cases, multiple styles of capitalization are used for the same term due to quoting from different RFCs.
DNS用語での資本化は、RFCとさまざまなDNS実践者の間で一貫性がないことがよくあります。このドキュメントで使用されている大文字は、現在のプラクティスの最良の推測であり、他の大文字のスタイルが間違っている、または古風なことを示すことを意図したものではありません。場合によっては、異なるRFCから引用しているため、同じ用語で複数のスタイルの大文字化が使用されます。
In this document, the words "byte" and "octet" are used interchangeably. They appear here because they both appear in the earlier RFCs that defined terms in the DNS.
このドキュメントでは、「バイト」と「オクテット」という言葉が同じ意味で使用されます。彼らは両方ともDNSで用語を定義した以前のRFCに登場するため、ここに登場します。
Readers should note that the terms in this document are grouped by topic. Someone who is not already familiar with the DNS probably cannot learn about the DNS from scratch by reading this document from front to back. Instead, skipping around may be the only way to get enough context to understand some of the definitions. This document has an index that might be useful for readers who are attempting to learn the DNS by reading this document.
読者は、このドキュメントの用語はトピックごとにグループ化されていることに注意する必要があります。DNSにまだ精通していない人は、このドキュメントを正面から後ろに読んで、DNSについてゼロから学ぶことができないでしょう。代わりに、いくつかの定義を理解するのに十分なコンテキストを取得するための唯一の方法かもしれません。このドキュメントには、このドキュメントを読んでDNSを学習しようとしている読者に役立つ可能性のあるインデックスがあります。
Naming system:
命名システム：
A naming system associates names with data. Naming systems have many significant facets that help differentiate them from each other. Some commonly identified facets include:
ネーミングシステムは、名前をデータに関連付けます。ネーミングシステムには、それらを互いに区別するのに役立つ多くの重要なファセットがあります。一般的に特定されたファセットには次のものがあります。
* Composition of names
* 名前の構成
* Format of names
* 名前の形式
* Administration of names
* 名前の管理
* Types of data that can be associated with names
* 名前に関連付けられる可能性のあるデータの種類
* Types of metadata for names
* 名前のメタデータの種類
* Protocol for getting data from a name
* 名前からデータを取得するためのプロトコル
* Context for resolving a name
* 名前を解決するためのコンテキスト
Note that this list is a small subset of facets that people have identified over time for naming systems, and the IETF has yet to agree on a good set of facets that can be used to compare naming systems. For example, other facets might include "protocol to update data in a name", "privacy of names", and "privacy of data associated with names", but those are not as well defined as the ones listed above. The list here is chosen because it helps describe the DNS and naming systems similar to the DNS.
このリストは、命名システムのために人々が時間の経過とともに特定したファセットの小さなサブセットであり、IETFは命名システムを比較するために使用できる良いファセットのセットにまだ同意していないことに注意してください。たとえば、他のファセットには、「名前でデータを更新するためのプロトコル」、「名前のプライバシー」、「名前に関連付けられたデータのプライバシー」が含まれる場合がありますが、それらは上記のものとはあまり定義されていません。ここのリストは、DNSと同様のDNSと命名システムを記述するのに役立つため、選択されています。
Domain name:
ドメイン名：
An ordered list of one or more labels.
1つ以上のラベルの順序付けられたリスト。
Note that this is a definition independent of the DNS RFCs ([RFC1034] and [RFC1035]), and the definition here also applies to systems other than the DNS. [RFC1034] defines the "domain name space" using mathematical trees and their nodes in graph theory, and that definition has the same practical result as the definition here. Any path of a directed acyclic graph can be represented by a domain name consisting of the labels of its nodes, ordered by decreasing distance from the root(s) (which is the normal convention within the DNS, including this document). A domain name whose last label identifies a root of the graph is fully qualified; other domain names whose labels form a strict prefix of a fully qualified domain name are relative to its first omitted node.
これは、DNS RFCS（[RFC1034]および[RFC1035]）に依存しない定義であり、ここでの定義はDNS以外のシステムにも適用されることに注意してください。[RFC1034]は、数学的なツリーとグラフ理論のノードを使用して「ドメイン名スペース」を定義し、その定義はここで定義と同じ実用的な結果を持っています。指示された非環式グラフの任意のパスは、ルート（S）からの距離を減らすことで順序付けられるノードのラベルで構成されるドメイン名で表すことができます（このドキュメントを含むDNS内の通常の規則です）。最後のラベルがグラフのルートを識別するドメイン名は完全に適格です。ラベルが完全に適格なドメイン名の厳格な接頭辞を形成する他のドメイン名は、最初に省略されたノードに関連しています。
Also note that different IETF and non-IETF documents have used the term "domain name" in many different ways. It is common for earlier documents to use "domain name" to mean "names that match the syntax in [RFC1035]", but possibly with additional rules such as "and are, or will be, resolvable in the global DNS" or "but only using the presentation format".
また、さまざまなIETFドキュメントと非IITFドキュメントが「ドメイン名」という用語をさまざまな方法で使用していることに注意してください。以前のドキュメントは「ドメイン名」を使用して「[RFC1035]の構文に一致する名前」を意味するが、「グローバルDNSでは解決可能」または「しかし」などの追加のルールがある場合は、「ドメイン名」を意味するのが一般的です。プレゼンテーション形式のみを使用してください」。
Label:
ラベル：
An ordered list of zero or more octets that makes up a portion of a domain name. Using graph theory, a label identifies one node in a portion of the graph of all possible domain names.
ドメイン名の一部を構成するゼロ以上のオクテットの順序付けられたリスト。グラフ理論を使用して、ラベルは、すべての可能なドメイン名のグラフの一部に1つのノードを識別します。
Global DNS:
グローバルDNS：
Using the short set of facets listed in "Naming system", the global DNS can be defined as follows. Most of the rules here come from [RFC1034] and [RFC1035], although the term "global DNS" has not been defined before now.
「ネーミングシステム」にリストされているファセットの短いセットを使用して、グローバルDNSは次のように定義できます。ここでのルールのほとんどは[RFC1034]および[RFC1035]からのものですが、「グローバルDNS」という用語は今まで定義されていません。
Composition of names:
名前の構成：
A name in the global DNS has one or more labels. The length of each label is between 0 and 63 octets inclusive. In a fully qualified domain name, the last label in the ordered list is 0 octets long; it is the only label whose length may be 0 octets, and it is called the "root" or "root label". A domain name in the global DNS has a maximum total length of 255 octets in the wire format; the root represents one octet for this calculation. (Multicast DNS [RFC6762] allows names up to 255 bytes plus a terminating zero byte based on a different interpretation of RFC 1035 and what is included in the 255 octets.)
グローバルDNSの名前には、1つ以上のラベルがあります。各ラベルの長さは、0〜63オクテットの包括的です。完全に資格のあるドメイン名では、順序付けられたリストの最後のラベルは0オクテットの長さです。長さが0オクテットである可能性がある唯一のラベルであり、「ルート」または「ルートラベル」と呼ばれます。グローバルDNSのドメイン名は、ワイヤ形式で最大合計255オクテットです。ルートは、この計算の1つのオクテットを表します。（マルチキャストDNS [RFC6762]は、RFC 1035の異なる解釈と255オクテットに含まれるものに基づいて、最大255バイトの名前と終了ゼロバイトを許可します。）
Format of names:
名前の形式：
Names in the global DNS are domain names. There are three formats: wire format, presentation format, and common display.
グローバルDNSの名前はドメイン名です。ワイヤー形式、プレゼンテーション形式、および共通ディスプレイの3つの形式があります。
Wire format:
ワイヤー形式：
The basic wire format for names in the global DNS is a list of labels ordered by decreasing distance from the root, with the root label last. Each label is preceded by a length octet. [RFC1035] also defines a compression scheme that modifies this format.
グローバルDNSの名前の基本的なワイヤ形式は、ルートラベルが最後に続くルートからの距離を減らすことで順序付けられるラベルのリストです。各ラベルの前には、長さのオクテットがあります。[RFC1035]は、この形式を変更する圧縮スキームも定義します。
Presentation format:
プレゼンテーション形式：
The presentation format for names in the global DNS is a list of labels ordered by decreasing distance from the root, encoded as ASCII, with a "." character between each label. In presentation format, a fully qualified domain name includes the root label and the associated separator dot. For example, in presentation format, a fully qualified domain name with two non-root labels is always shown as "example.tld." instead of "example.tld". [RFC1035] defines a method for showing octets that do not display in ASCII.
グローバルDNSの名前のプレゼンテーション形式は、asciiとしてエンコードされたルートからの距離を減少させ、「各ラベル間の文字。プレゼンテーション形式では、完全に認定されたドメイン名には、ルートラベルと関連するセパレータードットが含まれます。たとえば、プレゼンテーション形式では、2つの非ルートラベルを備えた完全に資格のあるドメイン名が常に「example.tld」として表示されます。「embles.tld」の代わりに。[RFC1035]は、ASCIIで表示されないオクテットを表示する方法を定義します。
Common display format:
一般的なディスプレイ形式：
The common display format is used in applications and free text. It is the same as the presentation format, but showing the root label and the "." before it is optional and is rarely done. For example, in common display format, a fully qualified domain name with two non-root labels is usually shown as "example.tld" instead of "example.tld.". Names in the common display format are normally written such that the directionality of the writing system presents labels by decreasing distance from the root (so, in both English and the C programming language, the root or Top-Level Domain (TLD) label in the ordered list is rightmost; but in Arabic, it may be leftmost, depending on local conventions).
一般的なディスプレイ形式は、アプリケーションと無料テキストで使用されます。プレゼンテーション形式と同じですが、ルートラベルと「。」を表示します。それがオプションであり、めったに行われることはありません。たとえば、一般的なディスプレイ形式では、2つの非ルートラベルを備えた完全に適格なドメイン名は、通常、「example.tld」の代わりに「example.tld」として表示されます。一般的なディスプレイ形式の名前は、通常、ライティングシステムの方向性がルートからの距離を減らすことによりラベルを提示するように記述されています（したがって、英語とCプログラミング言語の両方で、ルートまたはトップレベルドメイン（TLD）ラベルの両方で、注文リストは右端です。しかし、アラビア語では、地元の慣習に応じて左端になる可能性があります）。
Administration of names:
名前の管理：
Administration is specified by delegation (see the definition of "delegation" in Section 7). Policies for administration of the root zone in the global DNS are determined by the names operational community, which convenes itself in the Internet Corporation for Assigned Names and Numbers (ICANN). The names operational community selects the IANA Functions Operator for the global DNS root zone. The name servers that serve the root zone are provided by independent root operators. Other zones in the global DNS have their own policies for administration.
管理は委任によって指定されています（セクション7の「委任」の定義を参照）。グローバルDNSのルートゾーンの管理のためのポリシーは、割り当てられた名前と数字（ICANN）のためにインターネット企業に招集する名前の運用コミュニティによって決定されます。Names Operational Communityは、グローバルDNSルートゾーンのIANA関数演算子を選択します。ルートゾーンにサービスを提供する名前サーバーは、独立したルート演算子によって提供されます。グローバルDNSの他のゾーンには、管理に関する独自のポリシーがあります。
Types of data that can be associated with names:
名前に関連付けられるデータの種類：
A name can have zero or more resource records associated with it. There are numerous types of resource records with unique data structures defined in many different RFCs and in the IANA registry at [IANA_Resource_Registry].
名前には、ゼロ以上のリソースレコードが関連付けられます。多くの異なるRFCおよび[iana_resource_registry]のIANAレジストリで定義された一意のデータ構造を備えたリソースレコードには多数あります。
Types of metadata for names:
名前のメタデータの種類：
Any name that is published in the DNS appears as a set of resource records (see the definition of "RRset" in Section 5). Some names do not, themselves, have data associated with them in the DNS, but they "appear" in the DNS anyway because they form part of a longer name that does have data associated with it (see the definition of "empty non-terminals" in Section 7).
DNSで公開されている名前はすべて、リソースレコードのセットとして表示されます（セクション5の「RRSet」の定義を参照）。一部の名前は、それ自体ではDNSに関連するデータを持っていませんが、それに関連するデータを持つ長い名前の一部を形成するため、DNSに「表示」されます（空の非末端の定義を参照してください「セクション7で）。
Protocol for getting data from a name:
名前からデータを取得するためのプロトコル：
The protocol described in [RFC1035].
[RFC1035]で説明されているプロトコル。
Context for resolving a name:
名前を解決するためのコンテキスト：
The global DNS root zone distributed by Public Technical Identifiers (PTI).
パブリックテクニカル識別子（PTI）によって分布するグローバルDNSルートゾーン。
Private DNS:
プライベートDNS：
Names that use the protocol described in [RFC1035] but do not rely on the global DNS root zone or names that are otherwise not generally available on the Internet but are using the protocol described in [RFC1035]. A system can use both the global DNS and one or more private DNS systems; for example, see "Split DNS" in Section 6.
[RFC1035]で説明されているプロトコルを使用する名前は、インターネット上で一般的に利用できないが[RFC1035]で説明されているプロトコルを使用しているグローバルDNSルートゾーンまたは名前に依存していません。システムは、グローバルDNSと1つ以上のプライベートDNSシステムの両方を使用できます。たとえば、セクション6の「分割DNS」を参照してください。
Note that domain names that do not appear in the DNS and that are intended never to be looked up using the DNS protocol are not part of the global DNS or a private DNS, even though they are domain names.
DNSには表示されず、DNSプロトコルを使用して検索されないことを意図していないドメイン名は、ドメイン名であるにもかかわらず、グローバルDNSまたはプライベートDNSの一部ではないことに注意してください。
Multicast DNS (mDNS):
マルチキャストDNS（MDNS）：
"Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names." (Quoted from [RFC6762], Abstract) Although it uses a compatible wire format, mDNS is, strictly speaking, a different protocol than DNS. Also, where the above quote says "a portion of the DNS namespace", it would be clearer to say "a portion of the domain name space". The names in mDNS are not intended to be looked up in the DNS.
「マルチキャストDNS（MDNS）は、従来のユニキャストDNSサーバーがない場合にローカルリンクでDNS様操作を実行する機能を提供します。さらに、マルチキャストDNSは、DNSネームスペースの一部をローカルで使用するために無料であると指定します。年会費を支払う必要があり、代表団をセットアップする必要がなく、そうでなければそれらの名前に答えるために従来のDNSサーバーを構成する必要があります。」（[RFC6762]、要約から引用）互換性のあるワイヤ形式を使用していますが、MDNSは厳密に言えば、DNSとは異なるプロトコルです。また、上記の引用で「DNSネームスペースの一部」と書かれている場合、「ドメイン名スペースの一部」と言うのは明確です。MDNの名前は、DNSで検索することを意図していません。
Locally served DNS zone:
地元で提供されるDNSゾーン：
A locally served DNS zone is a special case of private DNS. Names are resolved using the DNS protocol in a local context. [RFC6303] defines subdomains of IN-ADDR.ARPA that are locally served zones. Resolution of names through locally served zones may result in ambiguous results. For example, the same name may resolve to different results in different locally served DNS zone contexts. The context for a locally served DNS zone may be explicit, such as those that are listed in [RFC6303] and [RFC7793], or implicit, such as those defined by local DNS administration and not known to the resolution client.
ローカルで提供されるDNSゾーンは、プライベートDNSの特別なケースです。名前は、ローカルコンテキストでDNSプロトコルを使用して解決されます。[RFC6303]は、ローカルで提供されるゾーンであるIn-ADDR.ARPAのサブドメインを定義します。ローカルで提供されるゾーンを介した名前の解像度は、曖昧な結果をもたらす可能性があります。たとえば、同じ名前は、異なるローカルで提供されるDNSゾーンコンテキストで異なる結果に解決する場合があります。ローカルで提供されるDNSゾーンのコンテキストは、[RFC6303]および[RFC7793]にリストされているものなど、ローカルDNS管理によって定義され、解像度クライアントに知られていないような暗黙のコンテキストである場合があります。
Fully Qualified Domain Name (FQDN):
完全資格のドメイン名（FQDN）：
This is often just a clear way of saying the same thing as "domain name of a node", as outlined above. However, the term is ambiguous. Strictly speaking, a fully qualified domain name would include every label, including the zero-length label of the root; such a name would be written "www.example.net." (note the terminating dot). But, because every name eventually shares the common root, names are often written relative to the root (such as "www.example.net") and are still called "fully qualified". This term first appeared in [RFC819]. In this document, names are often written relative to the root.
多くの場合、これは、上記のように、「ノードのドメイン名」と同じことを言う明確な方法です。ただし、この用語はあいまいです。厳密に言えば、完全に認定されたドメイン名には、ルートのゼロレングスラベルを含むすべてのラベルが含まれます。このような名前は「www.example.net」と書かれています。（終了ドットに注意してください）。ただし、すべての名前が最終的に共通のルートを共有するため、名前はルート（「www.example.net」など）に関連して書かれていることが多く、「完全資格」と呼ばれます。この用語は、[RFC819]に最初に登場しました。このドキュメントでは、名前はルートに対してしばしば書かれています。
The need for the term "fully qualified domain name" comes from the existence of partially qualified domain names, which are names where one or more of the last labels in the ordered list are omitted (for example, a domain name of "www" relative to "example.net" identifies "www.example.net"). Such relative names are understood only by context.
「完全資格のあるドメイン名」という用語の必要性は、順序付けられたリストの最後のラベルの1つ以上が省略されている部分的に適格なドメイン名の存在に由来しています（たとえば、「www」相対的なドメイン名です「example.net」に「www.example.net」を識別します。このような相対的な名前は、文脈によってのみ理解されます。
Host name:
ホスト名：
This term and its equivalent, "hostname", have been widely used but are not defined in [RFC1034], [RFC1035], [RFC1123], or [RFC2181]. The DNS was originally deployed into the Host Tables environment as outlined in [RFC952], and it is likely that the term followed informally from the definition there. Over time, the definition seems to have shifted. "Host name" is often meant to be a domain name that follows the rules in Section 3.5 of [RFC1034], which is also called the "preferred name syntax". (In that syntax, every character in each label is a letter, a digit, or a hyphen). Note that any label in a domain name can contain any octet value; hostnames are generally considered to be domain names where every label follows the rules in the "preferred name syntax", with the amendment that labels can start with ASCII digits (this amendment comes from Section 2.1 of [RFC1123]).
この用語とその同等の「ホスト名」は広く使用されていますが、[RFC1034]、[RFC1035]、[RFC1123]、または[RFC2181]では定義されていません。DNSはもともと[RFC952]で概説されているように、ホストテーブル環境に展開されており、その用語はそこの定義から非公式に続いている可能性があります。時間が経つにつれて、定義は変化したようです。「ホスト名」は、[RFC1034]のセクション3.5のルールに従うドメイン名であることがよくあります。これは、「優先名の構文」とも呼ばれます。（その構文では、各ラベルのすべての文字は文字、数字、またはハイフンです）。ドメイン名のラベルには、任意のオクテット値が含まれることに注意してください。ホスト名は一般に、すべてのラベルが「優先名の構文」のルールに従うドメイン名と見なされます。これは、ラベルがASCII桁から始まる可能性があるという修正（この修正は[RFC1123]のセクション2.1から来ています）。
People also sometimes use the term "hostname" to refer to just the first label of an FQDN, such as "printer" in "printer.admin.example.com". (Sometimes this is formalized in configuration in operating systems.) In addition, people sometimes use this term to describe any name that refers to a machine, and those might include labels that do not conform to the "preferred name syntax".
また、「Hostname」という用語を使用して、「Printer.admin.example.com」の「プリンター」など、FQDNの最初のラベルのみを参照することがあります。（これはオペレーティングシステムの構成で形式化される場合があります。）さらに、人々はこの用語を使用してマシンを参照する名前を記述することがあり、それらには「優先名の構文」に準拠していないラベルが含まれる場合があります。
Top-Level Domain (TLD):
トップレベルドメイン（TLD）：
A Top-Level Domain is a zone that is one layer below the root, such as "com" or "jp". There is nothing special, from the point of view of the DNS, about TLDs. Most of them are also delegation-centric zones (defined in Section 7), and there are significant policy issues around their operation. TLDs are often divided into sub-groups such as Country Code Top-Level Domains (ccTLDs), Generic Top-Level Domains (gTLDs), and others; the division is a matter of policy and beyond the scope of this document.
トップレベルのドメインは、「com」や「jp」など、ルートの下の1層のゾーンです。DNSの観点から、TLDについて特別なものはありません。それらのほとんどは、委任中心のゾーン（セクション7で定義）であり、その運用には重要な政策の問題があります。TLDは、多くの場合、カントリーコードのトップレベルドメイン（CCTLD）、汎用トップレベルドメイン（GTLD）などのサブグループに分割されます。部門は政策の問題であり、この文書の範囲を超えています。
Internationalized Domain Name (IDN):
国際化されたドメイン名（IDN）：
The Internationalized Domain Names for Applications (IDNA) protocol is the standard mechanism for handling domain names with non-ASCII characters in applications in the DNS. The current standard at the time of this writing, normally called "IDNA2008", is defined in [RFC5890], [RFC5891], [RFC5892], [RFC5893], and [RFC5894]. These documents define many IDN-specific terms such as "LDH label", "A-label", and "U-label". [RFC6365] defines more terms that relate to internationalization (some of which relate to IDNs); [RFC6055] has a much more extensive discussion of IDNs, including some new terminology.
アプリケーションの国際化ドメイン名（IDNA）プロトコルは、DNSのアプリケーションで非ASCII文字を持つドメイン名を処理するための標準メカニズムです。通常「IDNA2008」と呼ばれるこの執筆時点での現在の標準は、[RFC5890]、[RFC5891]、[RFC5892]、[RFC5893]、および[RFC5894]で定義されています。これらのドキュメントは、「LDHラベル」、「A-Label」、「U-Label」などの多くのIDN固有の用語を定義しています。[RFC6365]は、国際化に関連するより多くの用語を定義します（その一部はIDNSに関連しています）。[RFC6055]は、いくつかの新しい用語を含むIDNについて、はるかに広範な議論があります。
Subdomain:
サブドメイン：
"A domain is a subdomain of another domain if it is contained within that domain. This relationship can be tested by seeing if the subdomain's name ends with the containing domain's name." (Quoted from [RFC1034], Section 3.1) For example, in the host name "nnn.mmm.example.com", both "mmm.example.com" and "nnn.mmm.example.com" are subdomains of "example.com". Note that the comparisons here are done on whole labels; that is, "ooo.example.com" is not a subdomain of "oo.example.com".
「ドメインは、そのドメイン内に含まれている場合、別のドメインのサブドメインです。この関係は、サブドメインの名前が含まれるドメインの名前で終わるかどうかを確認することでテストできます。」（[rfc1034]、セクション3.1から引用）たとえば、ホスト名「nnn.mmm.example.com」、「mmmm.example.com」と「nnn.mmm.example.com」の両方のサブドメインは「例のサブドメインです。.com "。ここでの比較は、ラベル全体で行われていることに注意してください。つまり、「Ooo.example.com」は「oo.example.com」のサブドメインではありません。
Alias:
エイリアス：
The owner of a CNAME resource record, or a subdomain of the owner of a DNAME resource record (DNAME records are defined in [RFC6672]). See also "canonical name".
CNAMEリソースレコードの所有者、またはDNAMEリソースレコードの所有者のサブドメイン（DNAMEレコードは[RFC6672]で定義されています）。「Canonical Name」も参照してください。
Canonical name:
標準名：
A CNAME resource record "identifies its owner name as an alias, and specifies the corresponding canonical name in the RDATA section of the RR." (Quoted from [RFC1034], Section 3.6.2) This usage of the word "canonical" is related to the mathematical concept of "canonical form".
CNameリソースレコード「所有者名をエイリアスとして識別し、RRのRDATAセクションで対応する正規名を指定します。」（[RFC1034]、セクション3.6.2から引用）「標準」という単語のこの使用法は、「標準形」の数学的概念に関連しています。
CNAME:
cname：
"It has been traditional to refer to the [owner] of a CNAME record as 'a CNAME'. This is unfortunate, as 'CNAME' is an abbreviation of 'canonical name', and the [owner] of a CNAME record is most certainly not a canonical name." (Quoted from [RFC2181], Section 10.1.1. The quoted text has been changed from "label" to "owner".)
「cnameレコードの[所有者]を「cname」と呼ぶのは伝統的でした。これは残念です。「cname」は「標準名」の略語であり、cnameレコードの[所有者]が最も確かに標準的な名前ではありません。」（[RFC2181]、セクション10.1.1から引用。見積テキストは「ラベル」から「所有者」に変更されました。）
Some of the response codes (RCODEs) that are defined in [RFC1035] have acquired their own shorthand names. All of the RCODEs are listed at [IANA_Resource_Registry], although that list uses mixed-case capitalization, while most documents use all caps. Some of the common names for values defined in [RFC1035] are described in this section. This section also includes an additional RCODE and a general definition. The official list of all RCODEs is in the IANA registry.
[RFC1035]で定義されている応答コード（RCODE）の一部は、独自の速記名を取得しています。すべてのrcodesは[iana_resource_registry]にリストされていますが、そのリストは混合ケースの大文字化を使用しますが、ほとんどのドキュメントはすべてのキャップを使用しています。[RFC1035]で定義されている値の共通名の一部については、このセクションで説明します。このセクションには、追加のrcodeと一般的な定義も含まれています。すべてのRCODEの公式リストはIANAレジストリにあります。
NOERROR:
ノエラー：
This RCODE appears as "No error condition" in Section 4.1.1 of [RFC1035].
このRcodeは、[RFC1035]のセクション4.1.1に「エラー条件なし」として表示されます。
FORMERR:
Formerr：
This RCODE appears as "Format error - The name server was unable to interpret the query" in Section 4.1.1 of [RFC1035].
このRcodeは、[RFC1035]のセクション4.1.1の「フォーマットエラー - 名前サーバーがクエリを解釈できなかった」として表示されます。
SERVFAIL:
サーブファイル：
This RCODE appears as "Server failure - The name server was unable to process this query due to a problem with the name server" in Section 4.1.1 of [RFC1035].
このRcodeは、[RFC1035]のセクション4.1.1の「サーバー障害 - 名前サーバーの問題のためにこのクエリを処理できなかった」として表示されます。
NXDOMAIN:
nxdomain：
This RCODE appears as "Name Error [...] this code signifies that the domain name referenced in the query does not exist." in Section 4.1.1 of [RFC1035]. [RFC2308] established NXDOMAIN as a synonym for Name Error.
このRcodeは、「名前エラー[...]このコードは、クエリで参照されているドメイン名が存在しないことを意味します。」[RFC1035]のセクション4.1.1。[RFC2308]は、NxDomainを名前のエラーの同義語として確立しました。
NOTIMP:
notimp：
This RCODE appears as "Not Implemented - The name server does not support the requested kind of query" in Section 4.1.1 of [RFC1035].
このRcodeは、[RFC1035]のセクション4.1.1で「実装されていない - 名前サーバーは要求された種類のクエリをサポートしていない」と表示されます。
REFUSED:
拒否した：
This RCODE appears as "Refused - The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data." in Section 4.1.1 of [RFC1035].
このrcodeは「拒否された - 名前サーバーは、ポリシーの理由で指定された操作の実行を拒否します。たとえば、名前サーバーは特定の要求者に情報を提供することを希望しない場合や、名前サーバーが特定の操作を実行することを希望する場合があります。（例えば、ゾーン転送）特定のデータの。」[RFC1035]のセクション4.1.1。
NODATA:
データなし：
"A pseudo RCODE which indicates that the name is valid, for the given class, but [there] are no records of the given type. A NODATA response has to be inferred from the answer." (Quoted from [RFC2308], Section 1) "NODATA is indicated by an answer with the RCODE set to NOERROR and no relevant answers in the Answer section. The Authority section will contain an SOA record, or there will be no NS records there." (Quoted from [RFC2308], Section 2.2) Note that referrals have a similar format to NODATA replies; [RFC2308] explains how to distinguish them.
「指定されたクラスでは、名前が有効であることを示す擬似コードですが、与えられたタイプの記録はありません。答えからノーダタ応答を推測する必要があります。」（[RFC2308]、セクション1から引用）「Nodataは、回答セクションにrcodeセットを使用した回答と関連する回答が示されています。当局セクションにはSOAレコードが含まれているか、そこにNSレコードがありません。「（[RFC2308]、セクション2.2から引用）は、紹介にはNodataの応答と同様の形式があることに注意してください。[RFC2308]は、それらを区別する方法を説明します。
The term "NXRRSET" is sometimes used as a synonym for NODATA. However, this is a mistake, given that NXRRSET is a specific error code defined in [RFC2136].
「nxrrset」という用語は、nodataの同義語として使用される場合があります。ただし、NXRRSETは[RFC2136]で定義されている特定のエラーコードであるため、これは間違いです。
Negative response:
否定的な反応：
A response that indicates that a particular RRset does not exist or whose RCODE indicates that the nameserver cannot answer. Sections 2 and 7 of [RFC2308] describe the types of negative responses in detail.
特定のRRSetが存在しないことを示す応答、またはそのrcodeが名前サーバーが回答できないことを示します。[RFC2308]のセクション2および7は、負の応答のタイプを詳細に説明します。
The header of a DNS message is its first 12 octets. Many of the fields and flags in the diagrams in Sections 4.1.1 through 4.1.3 of [RFC1035] are referred to by their names in each diagram. For example, the response codes are called "RCODEs", the data for a record is called the "RDATA", and the authoritative answer bit is often called "the AA flag" or "the AA bit".
DNSメッセージのヘッダーは、最初の12オクテットです。[RFC1035]のセクション4.1.1から4.1.3の図の図のフィールドとフラグの多くは、各図の名前で言及されています。たとえば、応答コードは「rcodes」と呼ばれ、レコードのデータは「rdata」と呼ばれ、権威ある回答ビットはしばしば「aaフラグ」または「aaビット」と呼ばれます。
Class:
クラス：
A class "identifies a protocol family or instance of a protocol". (Quoted from [RFC1034], Section 3.6) "The DNS tags all data with a class as well as the type, so that we can allow parallel use of different formats for data of type address." (Quoted from [RFC1034], Section 2.2) In practice, the class for nearly every query is "IN" (the Internet). There are some queries for "CH" (the Chaos class), but they are usually for the purposes of information about the server itself rather than for a different type of address.
クラス「プロトコルファミリーまたはプロトコルのインスタンスを識別する」。（[RFC1034]、セクション3.6から引用）「DNSは、クラスとタイプのすべてのデータにタグを付けているため、タイプアドレスのデータに対して異なる形式を並行して使用できるようにします。」（[RFC1034]、セクション2.2から引用）実際には、ほぼすべてのクエリのクラスは「in」（インターネット）です。「Ch」（Chaosクラス）のクエリはいくつかありますが、通常、異なるタイプのアドレスではなく、サーバー自体に関する情報の目的のためです。
QNAME:
QNAME：
The most commonly used rough definition is that the QNAME is a field in the Question section of a query. "A standard query specifies a target domain name (QNAME), query type (QTYPE), and query class (QCLASS) and asks for RRs which match." (Quoted from [RFC1034], Section 3.7.1) Strictly speaking, the definition comes from [RFC1035], Section 4.1.2, where the QNAME is defined in respect of the Question section. This definition appears to be applied consistently, as the discussion of inverse queries in Section 6.4.1 of [RFC1035] refers to the "owner name of the query RR and its TTL" because inverse queries populate the Answer section and leave the Question section empty. (Inverse queries are deprecated in [RFC3425]; thus, relevant definitions do not appear in this document.)
最も一般的に使用されるラフな定義は、QNameがクエリの質問セクションのフィールドであることです。「標準クエリは、ターゲットドメイン名（QNAME）、クエリタイプ（QTYPE）、クエリクラス（QCLASS）を指定し、一致するRRSを求めます。」（[RFC1034]、セクション3.7.1から引用）厳密に言えば、定義は[RFC1035]、セクション4.1.2からのもので、QNAMEは質問セクションに関して定義されています。[RFC1035]のセクション6.4.1の逆クエリの議論は、逆クエリが回答セクションに入力し、質問セクションを空にしたままにしているため、[RFC1035]のセクション6.4.1の逆クエリの議論は一貫して適用されているように見えます。。（逆クエリは[RFC3425]で非推奨されています。したがって、関連する定義はこのドキュメントには表示されません。）
However, [RFC2308] has an alternate definition that puts the QNAME in the answer (or series of answers) instead of the query. It defines QNAME as "...the name in the query section of an answer, or where this resolves to a CNAME, or CNAME chain, the data field of the last CNAME. The last CNAME in this sense is that which contains a value which does not resolve to another CNAME." This definition has a certain internal logic, because of the way CNAME substitution works and the definition of CNAME. If a name server does not find an RRset that matches a query, but does find the same name in the same class with a CNAME record, then the name server "includes the CNAME record in the response and restarts the query at the domain name specified in the data field of the CNAME record." (Quoted from [RFC1034], Section 3.6.2) This is made explicit in the resolution algorithm outlined in Section 4.3.2 of [RFC1034], which says to "change QNAME to the canonical name in the CNAME RR, and go back to step 1" in the case of a CNAME RR. Since a CNAME record explicitly declares that the owner name is canonically named what is in the RDATA, then there is a way to view the new name (i.e., the name that was in the RDATA of the CNAME RR) as also being the QNAME.
ただし、[RFC2308]には、クエリの代わりにQNAME（または一連の回答）にQNAMEを配置する別の定義があります。QNameを「...回答のクエリセクションの名前、またはこれが最後のCNAMEのデータフィールドであるCNAMEまたはCNAMEチェーンに解決する場所です。この意味での最後のcnameは値を含むものです。別のcnameには解決しません。」この定義には、CNAMEの代替が機能する方法とCNAMEの定義があるため、特定の内部ロジックがあります。名前サーバーがクエリに一致するRRSetを見つけられず、同じクラスでCNAMEレコードを持つ同じ名前を見つけた場合、名前サーバーは「応答にCNAMEレコードを含み、指定されたドメイン名でクエリを再起動しますCNAMEレコードのデータフィールド。」（[RFC1034]、セクション3.6.2から引用）これは、[RFC1034]のセクション4.3.2で概説されている解像度アルゴリズムで明示的にされています。ステップ1 "cname rrの場合。CNAMEレコードは、所有者名がrdataにあるものが正体的に名前が付けられていることを明示的に宣言しているため、新しい名前（つまり、cname rrのrdataにあった名前）をqnameとして表示する方法があります。
However, this creates confusion because the response to a query that results in CNAME processing contains in the echoed Question section one QNAME (the name in the original query) and a second QNAME that is in the data field of the last CNAME. The confusion comes from the iterative/recursive mode of resolution, which finally returns an answer that need not actually have the same owner name as the QNAME contained in the original query.
ただし、これは混乱を引き起こします。これは、CNAME処理に至るクエリへの応答に、エコーされた質問セクション1 QName（元のクエリの名前）と最後のCNAMEのデータフィールドにある2番目のQNameに含まれるためです。混乱は、解像度の反復/再帰モードから生じます。これにより、実際には元のクエリに含まれるQNameと同じ所有者名が必要ではない答えが最終的に返されます。
To address this potential confusion, it is helpful to distinguish between three meanings:
この潜在的な混乱に対処するために、3つの意味を区別することが役立ちます。
QNAME (original):
QName（オリジナル）：
The name actually sent in the Question section in the original query, which is always echoed in the (final) reply in the Question section when the QR bit is set to 1.
QRビットが1に設定されている場合、質問セクションの（最終）回答（最終）の回答に常に反映される元のクエリの質問セクションで実際に送信されました。
QNAME (effective):
QName（Execument）：
A name actually resolved, which is either the name originally queried or a name received in a CNAME chain response.
実際に解決された名前は、元々照会された名前またはCNAMEチェーン応答で受信された名前のいずれかです。
QNAME (final):
qname（final）：
The name actually resolved, which is either the name actually queried or else the last name in a CNAME chain response.
名前は実際に解決されました。これは、実際に照会された名前か、CNAMEチェーン応答の姓です。
Note that, because the definition in [RFC2308] is actually for a different concept than what was in [RFC1034], it would have been better if [RFC2308] had used a different name for that concept. In general use today, QNAME almost always means what is defined above as "QNAME (original)".
[RFC2308]の定義は、実際には[RFC1034]にあったものとは異なる概念用であるため、[RFC2308]がその概念に別の名前を使用していれば、より良くなることに注意してください。一般的に今日使用すると、QNameはほとんどの場合、上記の「QName（Original）」として定義されているものを意味します。
Referrals:
紹介：
A type of response in which a server, signaling that it is not (completely) authoritative for an answer, provides the querying resolver with an alternative place to send its query. Referrals can be partial.
回答に対して（完全に）権威あるものではないことをサーバーが合図するタイプの応答は、クエリリゾルバーにクエリを送信する代替場所を提供します。紹介は部分的なものです。
A referral arises when a server is not performing recursive service while answering a query. It appears in step 3(b) of the algorithm in [RFC1034], Section 4.3.2.
サーバーがクエリに応答している間に再帰サービスを実行していない場合に紹介が発生します。[RFC1034]、セクション4.3.2のアルゴリズムのステップ3（b）に表示されます。
There are two types of referral response. The first is a downward referral (sometimes described as "delegation response"), where the server is authoritative for some portion of the QNAME. The Authority section RRset's RDATA contains the name servers specified at the referred-to zone cut. In normal DNS operation, this kind of response is required in order to find names beneath a delegation. The bare use of "referral" means this kind of referral, and many people believe that this is the only legitimate kind of referral in the DNS.
紹介応答には2つのタイプがあります。1つ目は、下向きの紹介（「委任応答」と呼ばれることもあります）で、サーバーはQNAMEの一部の権威があります。Authority Section RRSetのRDATAには、紹介されたゾーンカットで指定された名前サーバーが含まれています。通常のDNS操作では、代表団の下に名前を見つけるためにこの種の応答が必要です。「紹介」の裸の使用はこの種の紹介を意味し、多くの人々はこれがDNSで唯一の正当な種類の紹介であると信じています。
The second is an upward referral (sometimes described as "root referral"), where the server is not authoritative for any portion of the QNAME. When this happens, the referred-to zone in the Authority section is usually the root zone ("."). In normal DNS operation, this kind of response is not required for resolution or for correctly answering any query. There is no requirement that any server send upward referrals. Some people regard upward referrals as a sign of a misconfiguration or error. Upward referrals always need some sort of qualifier (such as "upward" or "root") and are never identified simply by the word "referral".
2つ目は、上向きの紹介（「ルート紹介」と呼ばれることもあります）で、サーバーはQNameのどの部分でも権威がありません。これが発生すると、当局セクションの参照ゾーンは通常、ルートゾーン（ "。"）です。通常のDNS操作では、この種の応答は、解決またはクエリへの正確な応答には必要ありません。サーバーが上向きの紹介を送信するという要件はありません。一部の人々は、上向きの紹介を誤解またはエラーの兆候と見なしています。上向きの紹介には、常にある種の修飾子（「上向き」や「ルート」など）が必要であり、「紹介」という単語によって単純に識別されることはありません。
A response that has only a referral contains an empty Answer section. It contains the NS RRset for the referred-to zone in the Authority section. It may contain RRs that provide addresses in the Additional section. The AA bit is clear.
紹介のみがある応答には、空の回答セクションが含まれています。当局セクションの紹介されたゾーンのNS RRSETが含まれています。追加セクションでアドレスを提供するRRSが含まれている場合があります。AAビットは明らかです。
In the case where the query matches an alias, and the server is not authoritative for the target of the alias but is authoritative for some name above the target of the alias, the resolution algorithm will produce a response that contains both the authoritative answer for the alias and a referral. Such a partial answer and referral response has data in the Answer section. It has the NS RRset for the referred-to zone in the Authority section. It may contain RRs that provide addresses in the Additional section. The AA bit is set because the first name in the Answer section matches the QNAME and the server is authoritative for that answer (see [RFC1035], Section 4.1.1).
クエリがエイリアスと一致し、サーバーはエイリアスのターゲットに対して権威がないが、エイリアスのターゲットを超える名前を信頼できる場合、解像度アルゴリズムは、エイリアスと紹介。このような部分的な回答と紹介応答には、回答セクションにデータがあります。当局セクションの紹介されたゾーンのNS RRSETがあります。追加セクションでアドレスを提供するRRSが含まれている場合があります。AAビットは、回答セクションの最初の名前がQNAMEと一致し、サーバーがその回答に対して権威あるために設定されています（[RFC1035]、セクション4.1.1を参照）。
RR:
RR:
An acronym for resource record. (See [RFC1034], Section 3.6.)
リソースレコードの頭字語。（[RFC1034]、セクション3.6を参照してください。）
RRset:
rrset：
A set of resource records "with the same label, class and type, but with different data" (according to [RFC2181], Section 5). Also written as "RRSet" in some documents. As a clarification, "same label" in this definition means "same owner name". In addition, [RFC2181] states that "the TTLs of all RRs in an RRSet must be the same".
「同じラベル、クラス、タイプ、しかし異なるデータを使用して」のリソースレコードのセット（[RFC2181]、セクション5による）。また、一部のドキュメントで「RRSet」として書かれています。明確化として、この定義の「同じラベル」は「同じ所有者名」を意味します。さらに、[RFC2181]は、「RRSetのすべてのRRのTTLは同じでなければならない」と述べています。
Note that RRSIG resource records do not match this definition. [RFC4035] says:
RRSIGリソースレコードはこの定義と一致しないことに注意してください。[RFC4035]と言う
An RRset MAY have multiple RRSIG RRs associated with it. Note that as RRSIG RRs are closely tied to the RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS RR types, do not form RRsets. In particular, the TTL values among RRSIG RRs with a common owner name do not follow the RRset rules described in [RFC2181].
RRSetには、複数のRRSIG RRが関連付けられている場合があります。RRSIG RRSは、署名に含まれるRRSetsに密接に結びついているため、RRSIG RRSは、他のすべてのDNS RRタイプとは異なり、RRSetを形成しないことに注意してください。特に、共通の所有者名を持つRRSIG RRSのTTL値は、[RFC2181]で説明されているRRSETルールに従っていません。
Master file:
マスターファイル：
"Master files are text files that contain RRs in text form. Since the contents of a zone can be expressed in the form of a list of RRs a master file is most often used to define a zone, though it can be used to list a cache's contents." (Quoted from [RFC1035], Section 5) Master files are sometimes called "zone files".
「マスターファイルは、テキスト形式のRRSを含むテキストファイルです。ゾーンの内容はRRSのリストで表現できるため、マスターファイルはゾーンを定義するために最も頻繁に使用されますが、Aをリストするために使用できます。キャッシュの内容。」（[RFC1035]から引用されている、セクション5）マスターファイルは「ゾーンファイル」と呼ばれることもあります。
Presentation format:
プレゼンテーション形式：
The text format used in master files. This format is shown but not formally defined in [RFC1034] or [RFC1035]. The term "presentation format" first appears in [RFC4034].
マスターファイルで使用されるテキスト形式。この形式は表示されますが、[RFC1034]または[RFC1035]で正式に定義されていません。「プレゼンテーション形式」という用語は、[RFC4034]に最初に表示されます。
EDNS:
edns：
The extension mechanisms for DNS, defined in [RFC6891]. Sometimes called "EDNS0" or "EDNS(0)" to indicate the version number. EDNS allows DNS clients and servers to specify message sizes larger than the original 512-octet limit, to expand the response code space, and to carry additional options that affect the handling of a DNS query.
[RFC6891]で定義されているDNSの拡張メカニズム。バージョン番号を示すために「EDNS0」または「EDNS（0）」と呼ばれることもあります。EDNSを使用すると、DNSクライアントとサーバーが元の512-OCTET制限よりも大きいメッセージサイズを指定して、応答コードスペースを拡張し、DNSクエリの処理に影響を与える追加のオプションを実施できます。
OPT:
OPT:
A pseudo-RR (sometimes called a "meta-RR") that is used only to contain control information pertaining to the question-and-answer sequence of a specific transaction. (Definition paraphrased from [RFC6891], Section 6.1.1.) It is used by EDNS.
特定のトランザクションの質疑応答シーケンスに関連する制御情報を含むためにのみ使用される擬似RR（「メタRR」と呼ばれることもあります）。（[RFC6891]、セクション6.1.1からの言い換えれ。）EDNSが使用しています。
Owner:
所有者：
"The domain name where the RR is found." (Quoted from [RFC1034], Section 3.6) Often appears in the term "owner name".
「RRが見つかったドメイン名。」（[RFC1034]から引用されている、セクション3.6）は、「所有者名」という用語にしばしば表示されます。
SOA field names:
SOAフィールド名：
DNS documents, including the definitions here, often refer to the fields in the RDATA of an SOA resource record by field name. "SOA" stands for "start of a zone of authority". Those fields are defined in Section 3.3.13 of [RFC1035]. The names (in the order they appear in the SOA RDATA) are MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM. Note that the meaning of the MINIMUM field is updated in Section 4 of [RFC2308]; the new definition is that the MINIMUM field is only "the TTL to be used for negative responses". This document tends to use field names instead of terms that describe the fields.
ここでの定義を含むDNSドキュメントは、多くの場合、フィールド名でSOAリソースレコードのRDATAのフィールドを指します。「SOA」は「権威のゾーンの開始」を表しています。これらのフィールドは、[RFC1035]のセクション3.3.13で定義されています。名前（soa rdataに表示される順序で）は、mname、rname、serial、refresh、retry、expire、およびminimutです。最小フィールドの意味は[RFC2308]のセクション4で更新されていることに注意してください。新しい定義は、最小フィールドは「負の応答に使用されるTTL」のみであるということです。このドキュメントは、フィールドを記述する用語ではなく、フィールド名を使用する傾向があります。
TTL:
TTL:
The maximum "time to live" of a resource record. "A TTL value is an unsigned number, with a minimum value of 0, and a maximum value of 2147483647. That is, a maximum of 2^31 - 1. When transmitted, this value shall be encoded in the less significant 31 bits of the 32 bit TTL field, with the most significant, or sign, bit set to zero." (Quoted from [RFC2181], Section 8) Note that [RFC1035] erroneously stated that this is a signed integer; that was fixed by [RFC2181].
リソースレコードの最大「生きる時間」。「TTL値は署名されていない数値であり、最小値は0、最大値は2147483647です。つまり、最大2^31-1。32ビットTTLフィールド、最も重要な、または標識がゼロに設定されています。」（[RFC2181]、セクション8から引用）[RFC1035]は、これが署名された整数であると誤って述べたことに注意してください。それは[RFC2181]によって修正されました。
The TTL "specifies the time interval that the resource record may be cached before the source of the information should again be consulted." (Quoted from [RFC1035], Section 3.2.1) Section 4.1.3 of [RFC1035] states "the time interval (in seconds) that the resource record may be cached before it should be discarded". Despite being defined for a resource record, the TTL of every resource record in an RRset is required to be the same ([RFC2181], Section 5.2).
TTLは、「情報のソースが再び相談する前に、リソースレコードがキャッシュされる可能性がある時間間隔を指定します。」（[RFC1035]、セクション3.2.1から引用）[RFC1035]のセクション4.1.3は、「廃棄する前にリソースレコードがキャッシュされる可能性がある」と述べています。リソースレコードに対して定義されているにもかかわらず、RRSetのすべてのリソースレコードのTTLは同じである必要があります（[RFC2181]、セクション5.2）。
The reason that the TTL is the maximum time to live is that a cache operator might decide to shorten the time to live for operational purposes, for example, if there is a policy to disallow TTL values over a certain number. Some servers are known to ignore the TTL on some RRsets (such as when the authoritative data has a very short TTL) even though this is against the advice in [RFC1035]. An RRset can be flushed from the cache before the end of the TTL interval, at which point, the value of the TTL becomes unknown because the RRset with which it was associated no longer exists.
TTLが生きる最大時間である理由は、キャッシュオペレーターが運用目的のために生きる時間を短縮することを決定する可能性があるためです。一部のサーバーは、[RFC1035]のアドバイスに反しているにもかかわらず、一部のRRSet（権威あるデータが非常に短いTTLを持っている場合など）でTTLを無視することが知られています。TTL間隔が終了する前に、RRSETをキャッシュからフラッシュできます。その時点で、関連付けられたRRSetが存在しなくなったため、TTLの値は不明になります。
There is also the concept of a "default TTL" for a zone, which can be a configuration parameter in the server software. This is often expressed by a default for the entire server, and a default for a zone using the $TTL directive in a zone file. The $TTL directive was added to the master file format by [RFC2308].
ゾーンの「デフォルトTTL」の概念もあります。これは、サーバーソフトウェアの構成パラメーターにすることができます。これは、多くの場合、サーバー全体のデフォルトで表現され、ゾーンファイル内の$ TTLディレクティブを使用するゾーンのデフォルトです。$ TTL指令は、[RFC2308]によってマスターファイル形式に追加されました。
Class independent:
クラス独立：
A resource record type whose syntax and semantics are the same for every DNS class. A resource record type that is not class independent has different meanings, depending on the DNS class of the record or if the meaning is undefined for some classes. Most resource record types are defined for class 1 (IN, the Internet), but many are undefined for other classes.
構文とセマンティクスがすべてのDNSクラスで同じであるリソースレコードタイプ。クラス独立ではないリソースレコードタイプには、レコードのDNSクラスに応じて、または一部のクラスで意味が未定義の場合に異なります。ほとんどのリソースレコードタイプは、クラス1（インターネット）で定義されていますが、多くは他のクラスでは未定義です。
Address records:
住所記録：
Records whose type is either A or AAAA. [RFC2181] informally defines these as "(A, AAAA, etc)". Note that new types of address records could be defined in the future.
タイプがAまたはAAAAのいずれかのレコード。[RFC2181]これらを非公式に「（A、AAAAなど）」と定義しています。将来、新しいタイプのアドレスレコードを定義できることに注意してください。
This section defines the terms used for the systems that act as DNS clients, DNS servers, or both. In past RFCs, DNS servers are sometimes called "name servers", "nameservers", or just "servers". There is no formal definition of "DNS server", but RFCs generally assume that it is an Internet server that listens for queries and sends responses using the DNS protocol defined in [RFC1035] and its successors.
このセクションでは、DNSクライアント、DNSサーバー、またはその両方として機能するシステムに使用される用語を定義します。過去のRFCでは、DNSサーバーは「名前サーバー」、「名前サーバー」、または「サーバー」と呼ばれることもあります。「DNSサーバー」の正式な定義はありませんが、RFCは一般に、[RFC1035]とその後継者で定義されたDNSプロトコルを使用してクエリをリッスンし、応答を送信するインターネットサーバーであると想定しています。
It is important to note that the terms "DNS server" and "name server" require context in order to understand the services being provided. Both authoritative servers and recursive resolvers are often called "DNS servers" and "name servers" even though they serve different roles (but may be part of the same software package).
「DNSサーバー」と「名前サーバー」という用語には、提供されているサービスを理解するためにコンテキストが必要であることに注意することが重要です。権威あるサーバーと再帰リゾルバーの両方は、異なる役割を提供している場合でも、「DNSサーバー」と「名前サーバー」と呼ばれることがよくあります（ただし、同じソフトウェアパッケージの一部である可能性があります）。
For terminology specific to the global DNS root server system, see [RSSAC026]. That document defines terms such as "root server", "root server operator", and terms that are specific to the way that the root zone of the global DNS is served.
グローバルDNSルートサーバーシステムに固有の用語については、[RSSAC026]を参照してください。そのドキュメントは、「ルートサーバー」、「ルートサーバー演算子」、グローバルDNSのルートゾーンの提供方法に固有の用語などの用語を定義します。
Resolver:
リゾルバ：
A program "that extract[s] information from name servers in response to client requests." (Quoted from [RFC1034], Section 2.4) A resolver performs queries for a name, type, and class, and receives responses. The logical function is called "resolution". In practice, the term is usually referring to some specific type of resolver (some of which are defined below), and understanding the use of the term depends on understanding the context.
「クライアントリクエストに応じて、名前サーバーから情報を抽出する」プログラム。（[RFC1034]、セクション2.4から引用）リゾルバーは、名前、タイプ、クラスのクエリを実行し、回答を受信します。論理関数は「解像度」と呼ばれます。実際には、この用語は通常、特定のタイプのリゾルバー（以下に定義されているものもあります）を参照しており、用語の使用を理解することは、コンテキストの理解に依存します。
A related term is "resolve", which is not formally defined in [RFC1034] or [RFC1035]. An imputed definition might be "asking a question that consists of a domain name, class, and type, and receiving some sort of response". Similarly, an imputed definition of "resolution" might be "the response received from resolving".
関連する用語は「Resolve」であり、これは[RFC1034]または[RFC1035]で正式に定義されていません。帰属定義は、「ドメイン名、クラス、タイプで構成される質問をし、何らかの応答を受信する」ことです。同様に、「解決」の帰属された定義は、「解決から受け取った応答」である可能性があります。
Stub resolver:
スタブリゾルバー：
A resolver that cannot perform all resolution itself. Stub resolvers generally depend on a recursive resolver to undertake the actual resolution function. Stub resolvers are discussed but never fully defined in Section 5.3.1 of [RFC1034]. They are fully defined in Section 6.1.3.1 of [RFC1123].
すべての解像度自体を実行できないリゾルバー。スタブリゾルバーは、一般に、実際の解像度関数を引き受けるための再帰的なリゾルバーに依存します。スタブリゾルバーについて説明しますが、[RFC1034]のセクション5.3.1で完全に定義されることはありません。それらは[RFC1123]のセクション6.1.3.1で完全に定義されています。
Iterative mode:
反復モード：
A resolution mode of a server that receives DNS queries and responds with a referral to another server. Section 2.3 of [RFC1034] describes this as "The server refers the client to another server and lets the client pursue the query." A resolver that works in iterative mode is sometimes called an "iterative resolver". See also "iterative resolution" later in this section.
DNSクエリを受信し、別のサーバーへの紹介で応答するサーバーの解像度モード。[RFC1034]のセクション2.3は、これを「サーバーはクライアントを別のサーバーに参照し、クライアントにクエリを追求できるようにする」と説明しています。反復モードで動作するリゾルバーは、「反復リゾルバー」と呼ばれることもあります。このセクションの後半の「反復解像度」も参照してください。
Recursive mode:
再帰モード：
A resolution mode of a server that receives DNS queries and either responds to those queries from a local cache or sends queries to other servers in order to get the final answers to the original queries. Section 2.3 of [RFC1034] describes this as "the first server pursues the query for the client at another server". Section 4.3.1 of [RFC1034] says: "in [recursive] mode the name server acts in the role of a resolver and returns either an error or the answer, but never referrals." That same section also says:
DNSクエリを受信し、ローカルキャッシュからこれらのクエリに応答するサーバーの解像度モード、または他のサーバーにクエリを送信して、元のクエリに対する最終的な回答を取得します。[RFC1034]のセクション2.3は、これを「最初のサーバーは別のサーバーでクライアントのクエリを追求する」と説明しています。[RFC1034]のセクション4.3.1は次のように述べています。「[再帰]モードでは、名前サーバーはリゾルバーの役割で動作し、エラーまたは回答のいずれかを返しますが、紹介しません。」その同じセクションはまた次のように述べています。
The recursive mode occurs when a query with RD set arrives at a server which is willing to provide recursive service; the client can verify that recursive mode was used by checking that both RA and RD are set in the reply.
再帰モードは、RDセットのクエリが再帰サービスを提供する意思のあるサーバーに到着するときに発生します。クライアントは、RAとRDの両方が返信に設定されていることを確認することにより、再帰モードが使用されたことを確認できます。
A server operating in recursive mode may be thought of as having a name server side (which is what answers the query) and a resolver side (which performs the resolution function). Systems operating in this mode are commonly called "recursive servers". Sometimes they are called "recursive resolvers". In practice, it is not possible to know in advance whether the server that one is querying will also perform recursion; both terms can be observed in use interchangeably.
再帰モードで動作するサーバーは、名前サーバー側（クエリに応答するもの）とリゾルバー側（解像度関数を実行する）を持っていると考えることができます。このモードで動作するシステムは、一般に「再帰サーバー」と呼ばれます。時々、それらは「再帰的なリゾルバー」と呼ばれます。実際には、サーバーがクエリをしているサーバーも再帰を実行するかどうかを事前に知ることはできません。どちらの用語も同じ意味で使用される場合に観察できます。
Recursive resolver:
再帰リゾルバー：
A resolver that acts in recursive mode. In general, a recursive resolver is expected to cache the answers it receives (which would make it a full-service resolver), but some recursive resolvers might not cache.
一般に、再帰的なリゾルバーは、受信する回答をキャッシュすることが期待されます（これにより、フルサービスのリゾルバーになります）が、一部の再帰的リゾルバーはキャッシュしない場合があります。
[RFC4697] tried to differentiate between a recursive resolver and an iterative resolver.
[RFC4697]は、再帰リゾルバーと反復リゾルバーを区別しようとしました。
Recursive query:
再帰クエリ：
A query with the Recursion Desired (RD) bit set to 1 in the header. (See Section 4.1.1 of [RFC1035].) If recursive service is available and is requested by the RD bit in the query, the server uses its resolver to answer the query. (See Section 4.3.2 of [RFC1034].)
ヘッダーの再帰（RD）ビットが1に設定されたクエリ。（[RFC1035]のセクション4.1.1を参照してください。）再帰サービスが利用可能で、クエリのRDビットによって要求されている場合、サーバーはリゾルバーを使用してクエリに回答します。（[RFC1034]のセクション4.3.2を参照してください。）
Non-recursive query:
非回復的クエリ：
A query with the Recursion Desired (RD) bit set to 0 in the header. A server can answer non-recursive queries using only local information: the response contains either an error, the answer, or a referral to some other server "closer" to the answer. (See Section 4.3.1 of [RFC1034].)
ヘッダーの再帰（RD）ビットが0に設定されたクエリ。サーバーは、ローカル情報のみを使用して非再帰的クエリに答えることができます。応答には、エラー、回答、または回答に「近い」他のサーバーへの紹介が含まれます。（[RFC1034]のセクション4.3.1を参照してください。）
Iterative resolution:
反復解像度：
A name server may be presented with a query that can only be answered by some other server. The two general approaches to dealing with this problem are "recursive", in which the first server pursues the query on behalf of the client at another server, and "iterative", in which the server refers the client to another server and lets the client pursue the query there. (See Section 2.3 of [RFC1034].)
名前サーバーには、他のサーバーでのみ回答できるクエリが表示される場合があります。この問題に対処するための2つの一般的なアプローチは「再帰的」であり、最初のサーバーが別のサーバーのクライアントに代わってクエリを追求することと、サーバーがクライアントを別のサーバーに参照し、クライアントを許可する「反復」そこでクエリを追求します。（[RFC1034]のセクション2.3を参照してください。）
In iterative resolution, the client repeatedly makes non-recursive queries and follows referrals and/or aliases. The iterative resolution algorithm is described in Section 5.3.3 of [RFC1034].
反復解像度では、クライアントは繰り返し非再帰的クエリを行い、紹介やエイリアスに従います。反復解像度アルゴリズムは、[RFC1034]のセクション5.3.3で説明されています。
Full resolver:
完全なリゾルバー：
This term is used in [RFC1035], but it is not defined there. RFC 1123 defines a "full-service resolver" that may or may not be what was intended by "full resolver" in [RFC1035]. This term is not properly defined in any RFC, and there is no consensus on what the term means. The use of this term without proper context is discouraged.
この用語は[RFC1035]で使用されていますが、そこで定義されていません。RFC 1123は、[RFC1035]の「フルリゾルバー」によって意図されているものである場合とそうでない場合がある「フルサービスのリゾルバー」を定義しています。この用語はどのRFCでも適切に定義されておらず、用語の意味についてコンセンサスはありません。適切な文脈のないこの用語の使用は落胆します。
Full-service resolver:
フルサービスリゾルバー：
Section 6.1.3.1 of [RFC1123] defines this term as a resolver that acts in recursive mode with a cache (and meets other requirements).
[RFC1123]のセクション6.1.3.1は、この用語を、キャッシュを使用して再帰モードで作用する（および他の要件を満たす）リゾルバーとして定義しています。
Priming:
プライミング：
"The act of finding the list of root servers from a configuration that lists some or all of the purported IP addresses of some or all of those root servers." (Quoted from [RFC8109], Section 2) In order to operate in recursive mode, a resolver needs to know the address of at least one root server. Priming is most often done from a configuration setting that contains a list of authoritative servers for the root zone.
「これらのルートサーバーの一部またはすべてのいくつかまたはすべてのIPアドレスの一部またはすべてをリストする構成からルートサーバーのリストを見つける行為。」（[RFC8109]、セクション2から引用）再帰モードで動作するには、リゾルバーは少なくとも1つのルートサーバーのアドレスを知る必要があります。プライミングは、ほとんどの場合、ルートゾーンの権威あるサーバーのリストを含む構成設定から行われます。
Root hints:
ルートヒント：
"Operators who manage a DNS recursive resolver typically need to configure a 'root hints file'. This file contains the names and IP addresses of the authoritative name servers for the root zone, so the software can bootstrap the DNS resolution process. For many pieces of software, this list comes built into the software." (Quoted from [IANA_RootFiles]) This file is often used in priming.
「DNSを管理するオペレーターは通常、「ルートヒントファイル」を構成する必要があります。このファイルには、ルートゾーンの権威ある名前サーバーの名前とIPアドレスが含まれているため、ソフトウェアはDNS解像度プロセスをブートストラップできます。ソフトウェアの場合、このリストはソフトウェアに組み込まれています。」（[IANA_ROOTFILES]から引用）このファイルは、プライミングでよく使用されます。
Negative caching:
ネガティブキャッシング：
"The storage of knowledge that something does not exist, cannot or does not give an answer." (Quoted from [RFC2308], Section 1)
「何かが存在しないという知識の保存は、答えを与えることはできません。」（[RFC2308]、セクション1から引用）
Authoritative server:
権威あるサーバー：
"A server that knows the content of a DNS zone from local knowledge, and thus can answer queries about that zone without needing to query other servers." (Quoted from [RFC2182], Section 2) An authoritative server is named in the NS ("name server") record in a zone. It is a system that responds to DNS queries with information about zones for which it has been configured to answer with the AA flag in the response header set to 1. It is a server that has authority over one or more DNS zones. Note that it is possible for an authoritative server to respond to a query without the parent zone delegating authority to that server. Authoritative servers also provide "referrals", usually to child zones delegated from them; these referrals have the AA bit set to 0 and come with referral data in the Authority and (if needed) the Additional sections.
「ローカルナレッジからDNSゾーンのコンテンツを知っているサーバー。したがって、他のサーバーを照会する必要なく、そのゾーンに関するクエリに答えることができます。」（[RFC2182]、セクション2から引用）権威あるサーバーは、ゾーン内のNS（ "Name Server"）レコードで名前が付けられています。これは、DNSクエリに応答するシステムであり、1に設定された応答ヘッダーのAAフラグで回答するように構成されているゾーンに関する情報を使用しています。1つ以上のDNSゾーンに対して権限を持つサーバーです。権威あるサーバーが、そのサーバーに権限を委任する親ゾーンなしでクエリに応答することが可能であることに注意してください。権威あるサーバーは、通常、それらから委任される子ゾーンに「紹介」も提供します。これらの紹介には、AAビットが0に設定されており、当局に紹介データが付属しており、（必要に応じて）追加セクションが付属しています。
Authoritative-only server:
権威ある専用サーバー：
A name server that only serves authoritative data and ignores requests for recursion. It will "not normally generate any queries of its own. Instead it answers non-recursive queries from iterative resolvers looking for information in zones it serves." (Quoted from [RFC4697], Section 2.4) In this case, "ignores requests for recursion" means "responds to requests for recursion with responses indicating that recursion was not performed".
権威あるデータのみを提供し、再帰のリクエストを無視する名前サーバー。「通常、独自のクエリを生成するものではありません。代わりに、提供するゾーンの情報を探している反復リゾルバーからの非再帰的クエリに答えます。」（[RFC4697]、セクション2.4から引用）この場合、「再帰のリクエストを無視する」は、「再帰が実行されなかったことを示す回答の再帰の要求に応答する」という意味です。
Zone transfer:
ゾーン転送：
The act of a client requesting a copy of a zone and an authoritative server sending the needed information. (See Section 7 for a description of zones.) There are two common standard ways to do zone transfers: the AXFR ("Authoritative Transfer") mechanism to copy the full zone (described in [RFC5936], and the IXFR ("Incremental Transfer") mechanism to copy only parts of the zone that have changed (described in [RFC1995]). Many systems use non-standard methods for zone transfers outside the DNS protocol.
ゾーンのコピーと必要な情報を送信する権威あるサーバーを要求するクライアントの行為。（ゾーンの説明についてはセクション7を参照してください。）ゾーン転送を行うには、AXFR（「権威ある転送」）メカニズム（[RFC5936]に記載されているAXFR（「権威ある転送」）メカニズムとIXFR（ "増分転送）の2つの一般的な標準的な方法があります。"）変更されたゾーンの部分のみをコピーするメカニズム（[RFC1995]で説明）。多くのシステムは、DNSプロトコル外のゾーン転送に非標準的な方法を使用しています。
Slave server:
スレーブサーバー：
See "Secondary server".
「セカンダリサーバー」を参照してください。
Secondary server:
セカンダリサーバー：
"An authoritative server which uses zone transfer to retrieve the zone." (Quoted from [RFC1996], Section 2.1) Secondary servers are also discussed in [RFC1034]. [RFC2182] describes secondary servers in more detail. Although early DNS RFCs such as [RFC1996] referred to this as a "slave", the current common usage has shifted to calling it a "secondary".
「ゾーン転送を使用してゾーンを取得する権威あるサーバー。」（[RFC1996]、セクション2.1から引用）セカンダリサーバーについても[RFC1034]で説明します。[RFC2182]は、セカンダリサーバーをより詳細に説明しています。[RFC1996]などの初期のDNS RFCはこれを「スレーブ」と呼んでいましたが、現在の一般的な使用法は「二次」と呼ぶことにシフトしています。
Master server:
マスターサーバー：
See "Primary server".
「プライマリサーバー」を参照してください。
Primary server:
プライマリサーバー：
"Any authoritative server configured to be the source of zone transfer for one or more [secondary] servers." (Quoted from [RFC1996], Section 2.1) Or, more specifically, [RFC2136] calls it "an authoritative server configured to be the source of AXFR or IXFR data for one or more [secondary] servers". Primary servers are also discussed in [RFC1034]. Although early DNS RFCs such as [RFC1996] referred to this as a "master", the current common usage has shifted to "primary".
「1つ以上の[セカンダリ]サーバーのゾーン転送のソースとして構成された権威あるサーバー。」（[RFC1996]、セクション2.1から引用）またはより具体的には[RFC2136]は、「1つ以上の[セカンダリ]サーバーのAXFRまたはIXFRデータのソースとして構成された権威あるサーバー」と呼びます。主要なサーバーについては、[RFC1034]で説明されています。[RFC1996]などの初期のDNS RFCはこれを「マスター」と呼んでいましたが、現在の一般的な使用法は「プライマリ」にシフトしています。
Primary master:
プライマリーマスター：
"The primary master is named in the zone's SOA MNAME field and optionally by an NS RR." (Quoted from [RFC1996], Section 2.1) [RFC2136] defines "primary master" as "Master server at the root of the AXFR/IXFR dependency graph. The primary master is named in the zone's SOA MNAME field and optionally by an NS RR. There is by definition only one primary master server per zone."
「プライマリマスターは、ゾーンのSOA MNAMEフィールドで、オプションでNS RRによって名前が付けられています。」（[RFC1996]、セクション2.1から引用）[RFC2136]は、「プライマリマスター」を「AXFR/IXFR依存性グラフのルートにあるマスターサーバー」と定義しています。プライマリマスターは、ゾーンのSOA MNAMEフィールドで、オプションでNS RRによって名前が付けられています。。定義上、ゾーンごとに1つの主要なマスターサーバーのみがあります。」
The idea of a primary master is only used in [RFC1996] and [RFC2136]. A modern interpretation of the term "primary master" is a server that is both authoritative for a zone and that gets its updates to the zone from configuration (such as a master file) or from UPDATE transactions.
プライマリマスターのアイデアは、[RFC1996]および[RFC2136]でのみ使用されます。「プライマリマスター」という用語の最新の解釈は、ゾーンに対して権威あるサーバーであり、構成（マスターファイルなど）または更新トランザクションからゾーンの更新を取得します。
Stealth server:
ステルスサーバー：
This is "like a slave server except not listed in an NS RR for the zone." (Quoted from [RFC1996], Section 2.1)
これは「ゾーンのNS RRにリストされていないことを除いて、スレーブサーバーのようなものです」。（[RFC1996]、セクション2.1から引用）
Hidden master:
隠されたマスター：
A stealth server that is a primary server for zone transfers. "In this arrangement, the master name server that processes the updates is unavailable to general hosts on the Internet; it is not listed in the NS RRset." (Quoted from [RFC6781], Section 3.4.3) [RFC4641] said that the hidden master's name "appears in the SOA RRs MNAME field"; however, the name does not appear at all in the global DNS in some setups. A hidden master can also be a secondary server for the zone itself.
ゾーン転送の主要サーバーであるステルスサーバー。「この配置では、更新を処理するマスター名サーバーは、インターネット上の一般ホストには利用できません。NSRRSetにはリストされていません。」（[RFC6781]、セクション3.4.3から引用）[RFC4641]は、隠されたマスターの名前は「SOA RRS MNAMEフィールドに表示される」と述べた。ただし、一部のセットアップでは、グローバルDNSでは名前がまったく表示されません。隠されたマスターは、ゾーン自体のセカンダリサーバーでもあります。
Forwarding:
転送：
The process of one server sending a DNS query with the RD bit set to 1 to another server to resolve that query. Forwarding is a function of a DNS resolver; it is different than simply blindly relaying queries.
RDビットを1に設定してDNSクエリを送信する1つのサーバーのプロセスは、そのクエリを解決するために別のサーバーに1に設定されています。転送は、DNSリゾルバーの関数です。それは、単に盲目的にリレーするクエリとは異なります。
[RFC5625] does not give a specific definition for forwarding, but describes in detail what features a system that forwards needs to support. Systems that forward are sometimes called "DNS proxies", but that term has not yet been defined (even in [RFC5625]).
[RFC5625]は、転送に特定の定義を提供するものではありませんが、転送がサポートする必要があるシステムを詳細に説明しています。フォワードのシステムは「DNSプロキシ」と呼ばれることもありますが、その用語はまだ定義されていません（[RFC5625]でも）。
Forwarder:
フォワーダー：
Section 1 of [RFC2308] describes a forwarder as "a nameserver used to resolve queries instead of directly using the authoritative nameserver chain". [RFC2308] further says "The forwarder typically either has better access to the internet, or maintains a bigger cache which may be shared amongst many resolvers." That definition appears to suggest that forwarders normally only query authoritative servers. In current use, however, forwarders often stand between stub resolvers and recursive servers. [RFC2308] is silent on whether a forwarder is iterative-only or can be a full-service resolver.
[RFC2308]のセクション1では、フォワーダーは「権威ある名前サーバーチェーンを直接使用するのではなく、クエリを解決するために使用される名前サーバー」と説明しています。[RFC2308]はさらに、「転送者は通常、インターネットへのアクセスが良いか、多くのリゾルバーの間で共有される可能性のあるより大きなキャッシュを維持するかのいずれかです」と述べています。その定義は、転送業者が通常権威あるサーバーのみを照会することを示唆しているようです。ただし、現在の使用では、フォワーダーは多くの場合、スタブリソースと再帰サーバーの間に立っています。[RFC2308]は、フォワーダーが反復専用であるか、フルサービスのリゾルバーであるかについて沈黙しています。
Policy-implementing resolver:
ポリシー - 実装リゾルバー：
A resolver acting in recursive mode that changes some of the answers that it returns based on policy criteria, such as to prevent access to malware sites or objectionable content. In general, a stub resolver has no idea whether upstream resolvers implement such policy or, if they do, the exact policy about what changes will be made. In some cases, the user of the stub resolver has selected the policy-implementing resolver with the explicit intention of using it to implement the policies. In other cases, policies are imposed without the user of the stub resolver being informed.
マルウェアサイトへのアクセスや好ましくないコンテンツへのアクセスを防ぐなど、ポリシー基準に基づいて返される回答の一部を変更する再帰モードで動作するリゾルバー。一般に、スタブリゾルバーは、上流のリゾルバーがそのようなポリシーを実装するかどうか、または、どのような変更が行われるかについての正確なポリシーを実装するかどうかを知りません。場合によっては、Stub Resolverのユーザーがポリシーを使用してポリシーを実装するという明示的な意図で、ポリシーを実施するリゾルバーを選択しました。それ以外の場合、スタブリゾルバーのユーザーが通知されずにポリシーが課されます。
Open resolver:
オープンリゾルバー：
A full-service resolver that accepts and processes queries from any (or nearly any) client. This is sometimes also called a "public resolver", although the term "public resolver" is used more with open resolvers that are meant to be open, as compared to the vast majority of open resolvers that are probably misconfigured to be open. Open resolvers are discussed in [RFC5358].
任意の（またはほぼすべての）クライアントからクエリを受け入れて処理するフルサービスのリゾルバー。これは「パブリックリゾルバー」とも呼ばれることもありますが、「パブリックリゾルバー」という用語は、おそらく開いていると誤解されているオープンリゾルバーの大部分と比較して、開いていることを意図したオープンリゾルバーでより使用されます。[RFC5358]で開いたリゾルバーについて説明します。
Split DNS:
DNSを分割：
The terms "split DNS" and "split-horizon DNS" have long been used in the DNS community without formal definition. In general, they refer to situations in which DNS servers that are authoritative for a particular set of domains provide partly or completely different answers in those domains depending on the source of the query. Nevertheless, the effect of this is that a domain name that is notionally globally unique has different meanings for different network users. This can sometimes be the result of a "view" configuration, as described below.
「分割DNS」と「スプリットホリゾンDNS」という用語は、正式な定義なしにDNSコミュニティで長い間使用されてきました。一般に、特定のドメインセットに対して権威あるDNSサーバーが、クエリのソースに応じてそれらのドメインで部分的または完全に異なる回答を提供する状況を指します。それにもかかわらず、これの効果は、概念的にグローバルに一意のドメイン名が、異なるネットワークユーザーにとって異なる意味を持っていることです。これは、以下で説明するように、「ビュー」構成の結果になる場合があります。
Section 3.8 of [RFC2775] gives a related definition that is too specific to be generally useful.
[RFC2775]のセクション3.8は、一般的に有用ではないほど具体的な関連する定義を示しています。
View:
ビュー：
A configuration for a DNS server that allows it to provide different responses depending on attributes of the query, such as for "split DNS". Typically, views differ by the source IP address of a query, but can also be based on the destination IP address, the type of query (such as AXFR), whether it is recursive, and so on. Views are often used to provide more names or different addresses to queries from "inside" a protected network than to those "outside" that network. Views are not a standardized part of the DNS, but they are widely implemented in server software.
「分割DNS」などのクエリの属性に応じて異なる応答を提供できるDNSサーバーの構成。通常、ビューはクエリのソースIPアドレスによって異なりますが、宛先IPアドレス、クエリのタイプ（AXFRなど）、再帰的かどうかなどにも基づいています。ビューは、多くの場合、そのネットワークの「外部」よりも「内部」から「内部」から「内部」からクエリに異なるアドレスを提供するために使用されます。ビューはDNSの標準化された部分ではありませんが、サーバーソフトウェアで広く実装されています。
Passive DNS:
パッシブDNS：
A mechanism to collect DNS data by storing DNS responses from name servers. Some of these systems also collect the DNS queries associated with the responses, although doing so raises some privacy concerns. Passive DNS databases can be used to answer historical questions about DNS zones, such as which values were present at a given time in the past, or when a name was spotted first. Passive DNS databases allow searching of the stored records on keys other than just the name and type, such as "find all names which have A records of a particular value".
名前サーバーからDNS応答を保存してDNSデータを収集するメカニズム。これらのシステムの一部は、応答に関連するDNSクエリも収集しますが、そうすることでプライバシーの懸念が高まります。パッシブDNSデータベースを使用して、過去の特定の時間にどの値が存在するか、または名前が最初に発見された場合など、DNSゾーンに関する歴史的な質問に答えることができます。パッシブDNSデータベースでは、「特定の値のレコードがあるすべての名前を見つける」など、名前とタイプ以外のキーに保存されたレコードを検索することができます。
Anycast:
Anycast：
"The practice of making a particular service address available in multiple, discrete, autonomous locations, such that datagrams sent are routed to one of several available locations." (Quoted from [RFC4786], Section 2) See [RFC4786] for more detail on Anycast and other terms that are specific to its use.
「特定のサービスアドレスを、複数の個別の、自律的な場所で利用できるようにする慣行。（[RFC4786]、セクション2から引用）[RFC4786]を参照してください。Anycastおよびその使用に固有のその他の用語の詳細については。
Instance:
実例：
"When anycast routing is used to allow more than one server to have the same IP address, each one of those servers is commonly referred to as an 'instance'." It goes on to say: "An instance of a server, such as a root server, is often referred to as an 'Anycast instance'." (Quoted from [RSSAC026])
「Anycastルーティングを使用して複数のサーバーが同じIPアドレスを持つことを許可する場合、これらのサーバーのそれぞれが一般的に「インスタンス」と呼ばれます。」「ルートサーバーなどのサーバーのインスタンスは、しばしば「Anycastインスタンス」と呼ばれます。」（[rssac026]から引用）
Privacy-enabling DNS server:
プライバシーを有するDNSサーバー：
"A DNS server that implements DNS over TLS [RFC7858] and may optionally implement DNS over DTLS [RFC8094]." (Quoted from [RFC8310], Section 2) Other types of DNS servers might also be considered privacy-enabling, such as those running DNS-over-HTTPS [RFC8484] or DNS-over-QUIC [RFC9250].
「TLS [RFC7858]を介してDNSを実装し、オプションでDTLS [RFC8094]にDNSを実装するDNSサーバー。」（[RFC8310]、セクション2から引用）他のタイプのDNSサーバーは、DNS-Over-HTTPS [RFC8484]またはDNS-Over-Quic [RFC9250]を実行しているものなど、プライバシーを有効にすると見なされる場合があります。
DNS-over-TLS (DoT):
dns-over-tls（dot）：
DNS over TLS as defined in [RFC7858] and its successors.
[RFC7858]およびその後継者で定義されているTLSを超えるDNS。
DNS-over-HTTPS (DoH):
dns-over-https（doh）：
DNS over HTTPS as defined in [RFC8484] and its successors.
[RFC8484]およびその後継者で定義されているHTTPS上のDNS。
DNS-over-QUIC (DoQ):
dns-over-quic（doq）：
DNS over QUIC as defined in [RFC9250] and its successors. [RFC9250] specifically defines DoQ as general-purpose transport for DNS that can be used in stub to recursive, recursive to authoritative, and zone transfer scenarios.
[RFC9250]およびその後継者で定義されているQUICを超えるDNS。[RFC9250]は、DOQを、スタブで使用して再帰的、権威ある、ゾーン転送シナリオに使用できるDNSの汎用輸送として特に定義しています。
Classic DNS:
クラシックDNS：
DNS over UDP or DNS over TCP as defined in [RFC1035] and its successors. Classic DNS applies to DNS communication between stub resolvers and recursive resolvers, and between recursive resolvers and authoritative servers. This has sometimes been called "Do53". Classic DNS is not encrypted.
[RFC1035]およびその後継者で定義されているように、TCPを超えるUDPまたはDNSを超えるDNS。クラシックDNSは、スタブリゾルバーと再帰リゾルバーの間のDNS通信に適用され、再帰リゾルバーと権威あるサーバーの間で適用されます。これは時々「do53」と呼ばれています。クラシックDNSは暗号化されていません。
Recursive DoT (RDoT):
再帰ドット（RDOT）：
RDoT specifically means DNS-over-TLS for transport between a stub resolver and a recursive resolver, or between a recursive resolver and another recursive resolver. This term is necessary because it is expected that DNS-over-TLS will later be defined as a transport between recursive resolvers and authoritative servers.
RDOTは、特に、スタブリゾルバーと再帰リゾルバー間の輸送のためのDNS-Over-TLS、または再帰リゾルバーと別の再帰リゾルバー間の間のDNS-Over-TLSを意味します。この用語は、DNS-over-TLSが後で再帰的なリゾルバーと権威あるサーバーの間の輸送として定義されることが予想されるため、必要です。
Authoritative DoT (ADoT):
権威あるドット（Adot）：
If DNS-over-TLS is later defined as a transport between recursive resolvers and authoritative servers, ADoT specifically means DNS-over-TLS for transport between recursive resolvers and authoritative servers.
DNS-Over-TLSが後で再帰的なリゾルバーと権威あるサーバー間の輸送として定義されている場合、Adotは、特に再帰的なリゾルバーと権威あるサーバー間の輸送のためのDNS-Over-TLSを意味します。
XFR-over-TLS (XoT):
xfr-over-tls（xot）：
DNS zone transfer over TLS, as specified in [RFC9103]. This term applies to both AXFR over TLS (AXoT) and IXFR over TLS (IXoT).
[RFC9103]で指定されているように、TLSを介したDNSゾーン転送。この用語は、TLS（AXOT）を介してAXFR（AXOT）とIXFRを超えるTLS（IXOT）の両方に適用されます。
This section defines terms that are used when discussing zones that are being served or retrieved.
このセクションでは、提供または取得されているゾーンについて議論するときに使用される用語を定義します。
Zone:
ゾーン：
"Authoritative information is organized into units called ZONEs, and these zones can be automatically distributed to the name servers which provide redundant service for the data in a zone." (Quoted from [RFC1034], Section 2.4)
「権威ある情報はゾーンと呼ばれるユニットに編成されており、これらのゾーンは、ゾーン内のデータに冗長サービスを提供する名前サーバーに自動的に配布できます。」（[RFC1034]、セクション2.4から引用）
Child:
子供：
"The entity on record that has the delegation of the domain from the Parent." (Quoted from [RFC7344], Section 1.1)
「親からドメインの代表団を持っている記録上のエンティティ。」（[RFC7344]、セクション1.1から引用）
Parent:
親：
"The domain in which the Child is registered." (Quoted from [RFC7344], Section 1.1) Earlier, "parent name server" was defined in [RFC0882] as "the name server that has authority over the place in the domain name space that will hold the new domain". (Note that [RFC0882] was obsoleted by [RFC1034] and [RFC1035].) [RFC819] also has some description of the relationship between parents and children.
「子供が登録されているドメイン。」（[RFC7344]、セクション1.1から引用）以前に、「親名サーバー」は[RFC0882]で「新しいドメインを保持するドメイン名スペースの場所に権限を持つ名前サーバー」として定義されていました。（[RFC0882]は[RFC1034]と[RFC1035]によって廃止されたことに注意してください。）[RFC819]には、親と子供の関係についても説明があります。
Origin:
起源：
There are two different uses for this term:
この用語には2つの異なる用途があります。
(a) "The domain name that appears at the top of a zone (just below the cut that separates the zone from its parent)... The name of the zone is the same as the name of the domain at the zone's origin." (Quoted from [RFC2181], Section 6) These days, this sense of "origin" and "apex" (defined below) are often used interchangeably.
(a) 「ゾーンの上部に表示されるドメイン名（ゾーンを親から分離するカットのすぐ下）...ゾーンの名前は、ゾーンの起源のドメインの名前と同じです。」（[RFC2181]、セクション6から引用）最近、この「起源」と「頂点」（以下に定義）の感覚は、しばしば同じ意味で使用されます。
(b) The domain name within which a given relative domain name appears in zone files. Generally seen in the context of "$ORIGIN", which is a control entry defined in [RFC1035], Section 5.1, as part of the master file format. For example, if the $ORIGIN is set to "example.org.", then a master file line for "www" is in fact an entry for "www.example.org.".
(b) 特定の相対ドメイン名がゾーンファイルに表示されるドメイン名。一般的に、[$ origin]のコンテキストで見られます。これは、[RFC1035]で定義されているコントロールエントリ、セクション5.1、マスターファイル形式の一部として。たとえば、$ oringが「example.org」に設定されている場合、「www」のマスターファイル行は、実際には「www.example.org」のエントリです。
Apex:
頂点：
The point in the tree at an owner of an SOA and corresponding authoritative NS RRset. This is also called the "zone apex". [RFC4033] defines it as "the name at the child's side of a zone cut". The "apex" can usefully be thought of as a data-theoretic description of a tree structure, and "origin" is the name of the same concept when it is implemented in zone files. The distinction is not always maintained in use, however, and one can find uses that conflict subtly with this definition. [RFC1034] uses the term "top node of the zone" as a synonym of "apex", but that term is not widely used. These days, the first sense of "origin" (above) and "apex" are often used interchangeably.
SOAの所有者と対応する権威あるNS RRSetの木のポイント。これは「ゾーンアペックス」とも呼ばれます。[RFC4033]は、「ゾーンカットの子供側の名前」と定義しています。「頂点」は、ツリー構造のデータ理論的記述と有用に考えることができ、「起源」はゾーンファイルに実装されている場合、同じ概念の名前です。ただし、この区別は常に使用されているわけではなく、この定義と微妙に矛盾する使用を見つけることができます。[RFC1034]は、「ゾーンのトップノード」という用語を「頂点」の同義語として使用しますが、その用語は広く使用されていません。最近では、「起源」（上記）と「頂点」の最初の感覚は、しばしば同じ意味で使用されています。
Zone cut:
ゾーンカット：
The delimitation point between two zones where the origin of one of the zones is the child of the other zone.
ゾーンの1つの起源が他のゾーンの子である2つのゾーンの間の境界ポイント。
"Zones are delimited by 'zone cuts'. Each zone cut separates a 'child' zone (below the cut) from a 'parent' zone (above the cut)." (Quoted from [RFC2181], Section 6; note that this is barely an ostensive definition.) Section 4.2 of [RFC1034] uses "cuts" instead of "zone cut".
「ゾーンは「ゾーンカット」によって区切られています。各ゾーンカットは、「子」ゾーン（カットの下）（カットの上）から「子」ゾーン（カットの下）を分離します。」（[RFC2181]、セクション6から引用されています。これはほとんど存在する定義ではないことに注意してください。）[RFC1034]のセクション4.2は、「ゾーンカット」の代わりに「カット」を使用します。
Delegation:
代表団：
The process by which a separate zone is created in the name space beneath the apex of a given domain. Delegation happens when an NS RRset is added in the parent zone for the child origin. Delegation inherently happens at a zone cut. The term is also commonly a noun: the new zone that is created by the act of delegating.
特定のドメインの頂点の下の名前空間に別のゾーンが作成されるプロセス。委任は、子どもの起源の親ゾーンにNS RRSetが追加されたときに発生します。代表団は本質的にゾーンカットで発生します。この用語は、一般に名詞です。委任行為によって作成される新しいゾーンです。
Authoritative data:
権威あるデータ：
"All of the RRs attached to all of the nodes from the top node of the zone down to leaf nodes or nodes above cuts around the bottom edge of the zone." (Quoted from [RFC1034], Section 4.2.1) Note that this definition might inadvertently also cause any NS records that appear in the zone to be included, even those that might not truly be authoritative, because there are identical NS RRs below the zone cut. This reveals the ambiguity in the notion of authoritative data, because the parent-side NS records authoritatively indicate the delegation, even though they are not themselves authoritative data.
「ゾーンの上部ノードからすべてのノードに接続されているすべてのRRは、ゾーンの上端の上の葉のノードまたはノードまでの葉のノードまたはノードまでのすべてのノードです。」（[RFC1034]、セクション4.2.1から引用）この定義は、ゾーンに含まれるゾーンに表示されるNSレコードを不注意に引き起こす可能性があることに注意してください。カット。これは、親側のNSレコードが権威あるデータではないにもかかわらず、委任を権威あるものに示しているため、権威あるデータの概念の曖昧さを明らかにします。
[RFC4033], Section 2, defines "Authoritative RRset", which is related to authoritative data but has a more precise definition.
[RFC4033]、セクション2は、「権威あるRRST」を定義します。これは、権威あるデータに関連していますが、より正確な定義があります。
Lame delegation:
ラメ代表団：
"A lame delegations exists [sic] when a nameserver is delegated responsibility for providing nameservice for a zone (via NS records) but is not performing nameservice for that zone (usually because it is not set up as a primary or secondary for the zone)." (Quoted from [RFC1912], Section 2.8) Another definition is that a lame delegation "...happens when a name server is listed in the NS records for some domain and in fact it is not a server for that domain. Queries are thus sent to the wrong servers, who don't know nothing [sic] (at least not as expected) about the queried domain. Furthermore, sometimes these hosts (if they exist!) don't even run name servers." (Quoted from [RFC1713], Section 2.3)
「名前サーバーが（NSレコードを介して）ゾーンの名前サービスを提供する責任を委任されているが、そのゾーンの名前サービスを実行していない場合（通常、ゾーンのプライマリまたはセカンダリとしてセットアップされていないため）。。」（[RFC1912]、セクション2.8から引用）別の定義は、ラメ代表団「...名前サーバーが一部のドメインのNSレコードにリストされている場合に発生することです。実際、それはそのドメインのサーバーではありません。間違ったサーバーに送られましたが、クエリドメインについては何も知らない（少なくとも予想どおりではありません）。さらに、これらのホスト（存在する場合！）は、名前サーバーを実行しないことがあります。」（[RFC1713]、セクション2.3から引用）
These early definitions do not match the current use of the term "lame delegation", but there is no consensus on what a lame delegation is. The term is used not only for the specific case described above, but for a variety of other flaws in delegations that lead to non-authoritative answers or no answers at all, such as:
これらの初期の定義は、「ラメ代表団」という用語の現在の使用と一致しませんが、ラメの代表団とは何かについてのコンセンサスはありません。この用語は、上記の特定のケースだけでなく、代表団の他のさまざまな欠陥に使用されます。
* a nameserver with an NS record for a zone that does not answer DNS queries;
* DNSクエリに応答しないゾーンのNSレコードを持つ名前サーバー。
* a nameserver with an IP address that is not reachable by the resolver; and
* リゾルバーが到達できないIPアドレスを持つ名前サーバー。そして
* a nameserver that responds to a query for a specific name with an error or without the authoritative bit set.
* エラーがある、または権威あるビットセットなしの特定の名前のクエリに応答する名前サーバー。
Because the term in current usage has drifted from the original definition, and now is not specific or clear as to the intended meaning, it should be considered historic and avoided in favor of terms that are specific and clear.
現在の使用法の用語は元の定義から漂流しており、現在では意図された意味について具体的または明確ではないため、具体的で明確な用語を支持して歴史的で回避する必要があります。
Glue records:
Glue Records：
"...[Resource records] which are not part of the authoritative data [of the zone], and are address RRs for the [name] servers [in subzones]. These RRs are only necessary if the name server's name is 'below' the cut, and are only used as part of a referral response." Without glue "we could be faced with the situation where the NS RRs tell us that in order to learn a name server's address, we should contact the server using the address we wish to learn." (Quoted from [RFC1034], Section 4.2.1)
"... [ゾーンの]権威あるデータの一部ではなく、[name]サーバーの[subzones]のrrsをアドレスしている[リソースレコード]。これらのRRは、名前サーバーの名前が「以下」である場合にのみ必要です。「カット、および紹介対応の一部としてのみ使用されます。」接着剤がなければ、「NS RRSが名前サーバーのアドレスを学習するために、学習したいアドレスを使用してサーバーに連絡する必要があることを教えてくれる状況に直面する可能性があります。」（[RFC1034]、セクション4.2.1から引用）
A later definition is that glue "includes any record in a zone file that is not properly part of that zone, including nameserver records of delegated sub-zones (NS records), address records that accompany those NS records (A, AAAA, etc), and any other stray data that might appear." (Quoted from [RFC2181], Section 5.4.1) Although glue is sometimes used today with this wider definition in mind, the context surrounding the definition in [RFC2181] suggests it is intended to apply to the use of glue within the document itself and not necessarily beyond.
後の定義では、接着剤は「そのゾーンの一部ではないゾーンファイルに、委任されたサブゾーン（NSレコード）の名前サーバーレコードが含まれ、それらのNSレコード（A、AAAAなど）に付随するレコードを扱うことです。、および表示される可能性のある他の迷走データ。」（[RFC2181]、セクション5.4.1から引用）このより広い定義を念頭に置いて、接着剤は今日使用されることがありますが、[RFC2181]の定義を取り巻くコンテキストは、ドキュメント自体内の接着剤の使用に適用することを目的としていることを示唆しています。必ずしもそれを超えているわけではありません。
In an NS record, there are three types of relationships between the owner name of the record, the name in the NS RDATA, and the zone origin: unrelated, in-domain, and sibling domain. The application of these three types of relationships to glue records is defined in [RFC9471].
NSレコードでは、レコードの所有者名、NS RDATAの名前とゾーンの原点の3つのタイプの関係があります：無関係、ドメイン、および兄弟ドメイン。Glue Recordsへのこれらの3種類の関係を適用することは、[RFC9471]で定義されています。
An unrelated relationship is one where the NS RDATA contains a name server that is not subordinate to the zone origin and therefore is not part of the same zone.
無関係な関係とは、ns rdataにゾーン起源に従属していないため、同じゾーンの一部ではない名前のサーバーを含む関係です。
An in-domain relationship is one where the NS RDATA contains a name server whose name is either subordinate to or (rarely) the same as the owner name of the NS resource records. For example, a delegation for "child.example.com" might have an in-domain name server called "ns.child.example.com".
ドメイン内の関係とは、NS RDATAに、NSリソースレコードの所有者名と同じか（まれに）名前のいずれかである名前の名前サーバーを含むものです。たとえば、「child.example.com」の代表団には、「ns.child.example.com」と呼ばれるドメイン内の名前サーバーがある場合があります。
A sibling domain relationship is one where the NS RDATA contains a name server whose name is either subordinate to or (rarely) the same as the zone origin of the parent and not subordinate to or the same as the owner name of the NS resource records. For example, a delegation for "child.example.com" in "example.com" zone might have a sibling domain name server called "ns.another.example.com".
兄弟ドメインの関係とは、NS rdataに、親のゾーン起点と同じか（まれに）名前のいずれかであり、NSリソースレコードの所有者名と同じか、または同じ名前が（まれに）名前の名前サーバーを含むものです。たとえば、「child.example.com」の代表団は、「example.com」ゾーンに「ns.another.example.com」と呼ばれる兄弟ドメイン名サーバーがある場合があります。
The following table shows examples of delegation types:
次の表は、委任タイプの例を示しています。
+=============+========+====================+================+
| Delegation | Parent | Name Server Name | Type |
+=============+========+====================+================+
| com | . | a.gtld-servers.net | sibling domain |
+-------------+--------+--------------------+----------------+
| net | . | a.gtld-servers.net | in-domain |
+-------------+--------+--------------------+----------------+
| example.org | org | ns.example.org | in-domain |
+-------------+--------+--------------------+----------------+
| example.org | org | ns.ietf.org | sibling domain |
+-------------+--------+--------------------+----------------+
| example.org | org | ns.example.com | unrelated |
+-------------+--------+--------------------+----------------+
| example.jp | jp | ns.example.jp | in-domain |
+-------------+--------+--------------------+----------------+
| example.jp | jp | ns.example.ne.jp | sibling domain |
+-------------+--------+--------------------+----------------+
| example.jp | jp | ns.example.com | unrelated |
+-------------+--------+--------------------+----------------+
Table 1
Bailiwick:
バイウィック：
"In-bailiwick" and "Out-of-bailiwick" are modifiers used to describe the relationship between a zone and the name servers for that zone. The dictionary definition of bailiwick has been observed to cause more confusion than meaning for this use. These terms should be considered historic in nature.
「In-Bailiwick」と「Bailiwick」は、そのゾーンのゾーンと名前サーバーの関係を記述するために使用される修飾子です。Bailiwickの辞書の定義は、この使用の意味よりも多くの混乱を引き起こすことが観察されています。これらの用語は、本質的に歴史的なものと見なされるべきです。
Root zone:
ルートゾーン：
The zone of a DNS-based tree whose apex is the zero-length label. Also sometimes called "the DNS root".
頂点がゼロ長さのラベルであるDNSベースのツリーのゾーン。「DNSルート」とも呼ばれることもあります。
Empty non-terminals (ENTs):
空の非ターミナル（ENTS）：
"Domain names that own no resource records but have subdomains that do." (Quoted from [RFC4592], Section 2.2.2) A typical example is in SRV records: in the name "_sip._tcp.example.com", it is likely that "_tcp.example.com" has no RRsets, but that "_sip._tcp.example.com" has (at least) an SRV RRset.
「リソースレコードを所有していないが、サブドメインを持っているドメイン名。」（[rfc4592]、セクション2.2.2から引用）典型的な例はsrvレコードにあります：「_sip._tcp.example.com」という名前では、「_tcp.example.com」にはrrsetsがありませんが、「_sip._tcp.example.com」には（少なくとも）srv rrsetがあります。
Delegation-centric zone:
委任中心のゾーン：
A zone that consists mostly of delegations to child zones. This term is used in contrast to a zone that might have some delegations to child zones but also has many data resource records for the zone itself and/or for child zones. The term is used in [RFC4956] and [RFC5155], but it is not defined in either document.
主に子供ゾーンへの代表団で構成されるゾーン。この用語は、子ゾーンにいくつかの代表団があるかもしれないゾーンとは対照的に使用されますが、ゾーン自体や子ゾーンの多くのデータリソースレコードもあります。この用語は[RFC4956]および[RFC5155]で使用されますが、どちらのドキュメントでも定義されていません。
Occluded name:
閉塞名：
"The addition of a delegation point via dynamic update will render all subordinate domain names to be in a limbo, still part of the zone but not available to the lookup process. The addition of a DNAME resource record has the same impact. The subordinate names are said to be 'occluded'." (Quoted from [RFC5936], Section 3.5)
「ダイナミックアップデートによる委任ポイントを追加すると、すべての下位ドメイン名が範囲内にあり、ゾーンの一部ではありませんが、ルックアッププロセスでは利用できません。DNAMEリソースレコードの追加には同じ影響があります。「閉塞」と言われています。」（[RFC5936]、セクション3.5から引用）
Fast flux DNS:
高速フラックスDNS：
This "occurs when a domain is [found] in DNS using A records to multiple IP addresses, each of which has a very short Time-to-Live (TTL) value associated with it. This means that the domain resolves to varying IP addresses over a short period of time." (Quoted from [RFC6561], Section 1.1.5, with a typo corrected) In addition to having legitimate uses, fast flux DNS can be used to deliver malware. Because the addresses change so rapidly, it is difficult to ascertain all the hosts. It should be noted that the technique also works with AAAA records, but such use is not frequently observed on the Internet as of this writing.
これは、複数のIPアドレスにレコードを使用してDNSでドメインが[見つかった]で発生します。それぞれがそれに関連付けられた非常に短い時間（TTL）値を持っています。これは、ドメインが変化するIPアドレスに解決することを意味します。短期間にわたって。」（[RFC6561]、セクション1.1.5から引用され、タイプミスの修正されたもの）正当な用途に加えて、マルウェアを配信するために高速フラックスDNSを使用できます。アドレスは急速に変化するため、すべてのホストを確認することは困難です。この手法はAAAAレコードでも動作することに注意する必要がありますが、この記事の執筆時点では、そのような使用はインターネットで頻繁に観察されていません。
Reverse DNS, reverse lookup:
逆DNS、リバースルックアップ：
"The process of mapping an address to a name is generally known as a 'reverse lookup', and the IN-ADDR.ARPA and IP6.ARPA zones are said to support the 'reverse DNS'." (Quoted from [RFC5855], Section 1)
「アドレスを名前にマッピングするプロセスは、一般に「逆ルックアップ」として知られており、In-Addr.ArpaおよびIP6.ARPAゾーンは「逆DNS」をサポートすると言われています。」（[RFC5855]から引用、セクション1）
Forward lookup:
フォワードルックアップ：
"Hostname-to-address translation". (Quoted from [RFC3493], Section 6)
「ホスト名からアドレスへの翻訳」。（[RFC3493]、セクション6から引用）
arpa (Address and Routing Parameter Area Domain):
ARPA（アドレスおよびルーティングパラメーターエリアドメイン）：
"The 'arpa' domain was originally established as part of the initial deployment of the DNS to provide a transition mechanism from the Host Tables that were common in the ARPANET, as well as a home for the IPv4 reverse mapping domain. During 2000, the abbreviation was redesignated to 'Address and Routing Parameter Area' in the hope of reducing confusion with the earlier network name." (Quoted from [RFC3172], Section 2) .arpa is an "infrastructure domain", a domain whose "role is to support the operating infrastructure of the Internet". (Quoted from [RFC3172], Section 2) See [RFC3172] for more history of this name.
「「ARPA」ドメインは、もともとDNSの初期展開の一部として確立され、ARPANETで一般的なホストテーブルからの遷移メカニズム、およびIPv4逆マッピングドメインのホームと同様に、遷移メカニズムを提供しました。略語は、以前のネットワーク名との混乱を減らすことを期待して、「パラメーター領域のアドレスとルーティングの領域」に再指定されました。」（[RFC3172]、セクション2から引用）.ARPAは「インフラストラクチャドメイン」であり、「インターネットの運用インフラストラクチャをサポートする役割」です。（[RFC3172]、セクション2から引用）この名前の履歴については、[RFC3172]を参照してください。
Service name:
サービス名：
"Service names are the unique key in the Service Name and Transport Protocol Port Number registry. This unique symbolic name for a service may also be used for other purposes, such as in DNS SRV records." (Quoted from [RFC6335], Section 5)
「サービス名は、サービス名とトランスポートプロトコルポート番号レジストリのユニークなキーです。このサービスのこのユニークなシンボリック名は、DNS SRVレコードなどの他の目的にも使用できます。」（[RFC6335]、セクション5から引用）
Wildcard:
ワイルドカード：
[RFC1034] defined "wildcard", but in a way that turned out to be confusing to implementers. For an extended discussion of wildcards, including clearer definitions, see [RFC4592]. Special treatment is given to RRs with owner names starting with the label "*". "Such RRs are called 'wildcards'. Wildcard RRs can be thought of as instructions for synthesizing RRs." (Quoted from [RFC1034], Section 4.3.3)
[RFC1034]は「ワイルドカード」を定義しましたが、実装者に混乱することが判明した方法で。明確な定義を含むワイルドカードの拡張された議論については、[RFC4592]を参照してください。ラベル「*」から始まる所有者名でRRSに特別な治療が与えられます。「このようなRRは「ワイルドカード」と呼ばれます。ワイルドカードRRは、RRを合成するための指示と考えることができます。」（[RFC1034]、セクション4.3.3から引用）
Asterisk label:
アスタリスクラベル：
"The first octet is the normal label type and length for a 1-octet-long label, and the second octet is the ASCII representation [RFC20] for the '*' character. A descriptive name of a label equaling that value is an 'asterisk label'." (Quoted from [RFC4592], Section 2.1.1)
「最初のオクテットは、1オクテット長のラベルの通常のラベルタイプと長さであり、2番目のオクテットは「*」文字のASCII表現[RFC20]です。その値に等しいラベルの記述名は、アスタリスクラベル '。」（[RFC4592]、セクション2.1.1から引用）
Wildcard domain name:
ワイルドカードドメイン名：
"A 'wildcard domain name' is defined by having its initial (i.e., leftmost or least significant) label, in binary format: 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)". (Quoted from [RFC4592], Section 2.1.1) The second octet in this label is the ASCII representation for the "*" character.
「「ワイルドカードドメイン名」は、バイナリ形式の初期（つまり、左端または最も重要ではない）ラベルを持つことによって定義されます：0000 0001 0010 1010（バイナリ）= 0x01 0x2a（hexadecimal）」。（[RFC4592]、セクション2.1.1から引用）このラベルの2番目のオクテットは、「*」文字のASCII表現です。
Closest encloser:
最も近いエンクロージャー：
"The longest existing ancestor of a name." (Quoted from [RFC5155], Section 1.3) An earlier definition is "The node in the zone's tree of existing domain names that has the most labels matching the query name (consecutively, counting from the root label downward). Each match is a 'label match' and the order of the labels is the same." (Quoted from [RFC4592], Section 3.3.1)
「名前の最も長く既存の祖先」（[RFC5155]、セクション1.3から引用）以前の定義は、「クエリ名と一致するラベルが最も多い既存のドメイン名のゾーンのツリーのノード（連続して、ルートラベルから下向きにカウントされる）です。ラベルマッチ」とラベルの順序は同じです。」（[RFC4592]、セクション3.3.1から引用）
Closest provable encloser:
最も近い証明可能なエンクロージャー：
"The longest ancestor of a name that can be proven to exist. Note that this is only different from the closest encloser in an Opt-Out zone." (Quoted from [RFC5155], Section 1.3) See Section 10 for more on "opt-out".
「存在することが証明できる名前の最長の祖先。これは、オプトアウトゾーンで最も近い封筒とは異なることに注意してください。」（[RFC5155]、セクション1.3から引用）「オプトアウト」の詳細については、セクション10を参照してください。
Next closer name:
次の近くの名前：
"The name one label longer than the closest provable encloser of a name." (Quoted from [RFC5155], Section 1.3)
「名前の1つのラベルは、最も近い証明可能な名前の封筒よりも長いラベルです。」（[RFC5155]から引用、セクション1.3）
Source of Synthesis:
合成のソース：
"The source of synthesis is defined in the context of a query process as that wildcard domain name immediately descending from the closest encloser, provided that this wildcard domain name exists. 'Immediately descending' means that the source of synthesis has a name of the form:
「このワイルドカードドメイン名が存在する場合、合成のソースはクエリプロセスのコンテキストで定義されています。このワイルドカードドメイン名が存在する場合、そのワイルドカードドメイン名は最近のエンコーザーからすぐに降ります。：
<asterisk label>.<closest encloser>."
<アスタリスクラベル>。<最も近いエンクロージャー>。 "
(Quoted from [RFC4592], Section 3.3.1)
（[RFC4592]、セクション3.3.1から引用）
Registry:
レジストリ：
The administrative operation of a zone that allows registration of names within that zone. People often use this term to refer only to those organizations that perform registration in large delegation-centric zones (such as TLDs); but formally, whoever decides what data goes into a zone is the registry for that zone. This definition of "registry" is from a DNS point of view; for some zones, the policies that determine what can go in the zone are decided by zones that are superordinate and not the registry operator.
そのゾーン内の名前の登録を許可するゾーンの管理操作。多くの場合、この用語を使用して、大規模な代表団中心のゾーン（TLDなど）で登録を実行する組織のみを参照します。しかし、正式には、どのデータがゾーンに入るかを決定した人は、そのゾーンのレジストリです。「レジストリ」のこの定義は、DNSの観点からのものです。一部のゾーンでは、ゾーン内で何ができるかを決定するポリシーは、レジストリオペレーターではなく上位であるゾーンによって決定されます。
Registrant:
登録者：
An individual or organization on whose behalf a name in a zone is registered by the registry. In many zones, the registry and the registrant may be the same entity, but in TLDs they often are not.
ゾーン内の名前を代表する個人または組織は、レジストリによって登録されています。多くのゾーンでは、レジストリと登録者は同じエンティティである可能性がありますが、TLDではそうではありません。
Registrar:
レジストラ：
A service provider that acts as a go-between for registrants and registries. Not all registrations require a registrar, though it is common to have registrars involved in registrations in TLDs.
登録者とレジストリの仲介として機能するサービスプロバイダー。すべての登録がレジストラを必要とするわけではありませんが、TLDSの登録にレジストラを関与させることは一般的です。
EPP:
EPP:
The Extensible Provisioning Protocol (EPP), which is commonly used for communication of registration information between registries and registrars. EPP is defined in [RFC5730].
拡張可能なプロビジョニングプロトコル（EPP）。これは、レジストリとレジストラ間の登録情報の通信に一般的に使用されています。EPPは[RFC5730]で定義されています。
WHOIS:
誰が：
A protocol specified in [RFC3912], often used for querying registry databases. WHOIS data is frequently used to associate registration data (such as zone management contacts) with domain names. The term "WHOIS data" is often used as a synonym for the registry database, even though that database may be served by different protocols, particularly RDAP. The WHOIS protocol is also used with IP address registry data.
[RFC3912]で指定されたプロトコルは、レジストリデータベースのクエリによく使用されます。WHOISデータは、登録データ（ゾーン管理の連絡先など）をドメイン名に関連付けるために頻繁に使用されます。「WHOISデータ」という用語は、そのデータベースが異なるプロトコル、特にRDAPによって提供される場合でも、レジストリデータベースの同義語としてよく使用されます。WHOISプロトコルは、IPアドレスレジストリデータでも使用されます。
RDAP:
RDAP：
The Registration Data Access Protocol, defined in [RFC7480], [RFC7481], [RFC7485], [RFC9082], [RFC9083], and [RFC9224]. The RDAP protocol and data format are meant as a replacement for WHOIS.
[RFC7480]、[RFC7481]、[RFC7485]、[RFC9082]、[RFC9083]、および[RFC9224]で定義されている登録データアクセスプロトコル。RDAPプロトコルとデータ形式は、WHOISの代替として意図されています。
DNS operator:
DNSオペレーター：
An entity responsible for running DNS servers. For a zone's authoritative servers, the registrant may act as their own DNS operator, their registrar may do it on their behalf, or they may use a third-party operator. For some zones, the registry function is performed by the DNS operator plus other entities who decide about the allowed contents of the zone.
DNSサーバーの実行を担当するエンティティ。ゾーンの権威あるサーバーの場合、登録者は独自のDNSオペレーターとして行動する場合があり、レジストラはそれを代表して行うか、サードパーティのオペレーターを使用する場合があります。一部のゾーンでは、レジストリ関数は、ゾーンの許可された内容を決定するDNSオペレーターと他のエンティティによって実行されます。
Public suffix:
パブリックサフィックス：
"A domain that is controlled by a public registry." (Quoted from [RFC6265], Section 5.3) A common definition for this term is a domain under which subdomains can be registered by third parties and on which HTTP cookies (which are described in detail in [RFC6265]) should not be set. There is no indication in a domain name whether it is a public suffix; that can only be determined by outside means. In fact, both a domain and a subdomain of that domain can be public suffixes.
「パブリックレジストリによって制御されるドメイン。」（[RFC6265]、セクション5.3から引用）この用語の共通の定義は、サブドメインを第三者が登録できるドメインであり、HTTP Cookie（[RFC6265]で詳細に説明されている）を設定しないでください。ドメイン名に、それがパブリックサフィックスであるかどうかは兆候はありません。それは外部の手段によってのみ決定できます。実際、そのドメインとそのドメインのサブドメインの両方は、パブリックサフィックスにすることができます。
There is nothing inherent in a domain name to indicate whether it is a public suffix. One resource for identifying public suffixes is the Public Suffix List (PSL) maintained by Mozilla <https://publicsuffix.org/>.
ドメイン名に固有のものはありません。これがパブリックサフィックスであるかどうかを示します。パブリックサフィックスを識別するための1つのリソースは、Mozilla <https://publicsuffix.org/>によって維持されているパブリックサフィックスリスト（PSL）です。
For example, at the time this document is published, the "com.au" domain is listed as a public suffix in the PSL. (Note that this example might change in the future.)
たとえば、このドキュメントが公開された時点で、「com.au」ドメインはPSLのパブリックサフィックスとしてリストされています。（この例は将来変化する可能性があることに注意してください。）
Note that the term "public suffix" is controversial in the DNS community for many reasons, and it may be significantly changed in the future. One example of the difficulty of calling a domain a public suffix is that designation can change over time as the registration policy for the zone changes, such as was the case with the "uk" TLD in 2014.
「パブリックサフィックス」という用語は、多くの理由でDNSコミュニティでは議論の余地があり、将来的には大幅に変更される可能性があることに注意してください。ドメインをパブリックサフィックスと呼ぶことの難しさの1つの例は、2014年の「英国」TLDの場合のようなゾーンの登録ポリシーが変更されると、指定が時間とともに変化する可能性があることです。
Subordinate and Superordinate:
下位および上位：
These terms are introduced in [RFC5731] for use in the registration model, but not defined there. Instead, they are given in examples. "For example, domain name 'example.com' has a superordinate relationship to host name ns1.example.com'... For example, host ns1.example1.com is a subordinate host of domain example1.com, but it is a not a subordinate host of domain example2.com." (Quoted from [RFC5731], Section 1.1) These terms are strictly ways of referring to the relationship standing of two domains where one is a subdomain of the other.
これらの用語は、登録モデルで使用するために[RFC5731]で導入されていますが、そこで定義されていません。代わりに、それらは例で与えられます。「たとえば、ドメイン名「example.com」はホスト名ns1.example.com 'との上位の関係があります。domain emply2.comの下位ホストではありません。」（[RFC5731]、セクション1.1から引用）これらの用語は、一方が他方のサブドメインである2つのドメインの関係に立つことを厳密に言及する方法です。
Most DNSSEC terms are defined in [RFC4033], [RFC4034], [RFC4035], and [RFC5155]. The terms that have caused confusion in the DNS community are highlighted here.
ほとんどのDNSSEC用語は、[RFC4033]、[RFC4034]、[RFC4035]、および[RFC5155]で定義されています。DNSコミュニティで混乱を引き起こした用語は、ここで強調されています。
DNSSEC-aware and DNSSEC-unaware:
dnssec-awareおよびdnssec-unaware：
These two terms, which are used in some RFCs, have not been formally defined. However, Section 2 of [RFC4033] defines many types of resolvers and validators, including "non-validating security-aware stub resolver", "non-validating stub resolver", "security-aware name server", "security-aware recursive name server", "security-aware resolver", "security-aware stub resolver", and "security-oblivious 'anything'". (Note that the term "validating resolver", which is used in some places in DNSSEC-related documents, is also not defined in those RFCs, but is defined below.)
一部のRFCで使用されるこれら2つの用語は、正式に定義されていません。ただし、[RFC4033]のセクション2では、「非検証セキュリティ認識スタブリゾルバー」、「非検証スタブリゾルバー」、「セキュリティ対応名サーバー」、「セキュリティ認識の再帰名など、多くの種類のリゾルバーとバリデーターを定義しています。サーバー "、"セキュリティ対応のリゾルバー "、「セキュリティ対応のスタブリゾルバー」、および「セキュリティを認識している「Anything」」。（DNSSEC関連のドキュメントの一部の場所で使用されている「Resolverの検証」という用語も、これらのRFCでは定義されていませんが、以下に定義されていることに注意してください。）
Signed zone:
署名ゾーン：
"A zone whose RRsets are signed and that contains properly constructed DNSKEY, Resource Record Signature (RRSIG), Next Secure (NSEC), and (optionally) DS records." (Quoted from [RFC4033], Section 2) It has been noted in other contexts that the zone itself is not really signed, but all the relevant RRsets in the zone are signed. Nevertheless, if a zone that should be signed contains any RRsets that are not signed (or opted out), those RRsets will be treated as bogus, so the whole zone needs to be handled in some way.
「rrsetsが署名され、適切に構築されたDNSKEY、リソースレコード署名（RRSIG）、次のセキュア（NSEC）、および（オプションで）DSレコードが含まれるゾーン。」（[RFC4033]、セクション2から引用）他のコンテキストでは、ゾーン自体が実際に署名されていないが、ゾーン内のすべての関連するrrsetが署名されていることが指摘されています。それにもかかわらず、署名する必要のあるゾーンに署名されていない（またはオプトアウト）rrsetsが含まれている場合、それらのrrsetsは偽物として扱われるため、ゾーン全体を何らかの方法で処理する必要があります。
It should also be noted that, since the publication of [RFC6840], NSEC records are no longer required for signed zones: a signed zone might include NSEC3 records instead. [RFC7129] provides additional background commentary and some context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide authenticated denial-of-existence responses. NSEC and NSEC3 are described below.
また、[RFC6840]が公開されて以来、署名ゾーンにはNSECレコードが不要になったことにも注意してください。[RFC7129]は、DNSSECが使用するNSECおよびNSEC3メカニズムの追加の背景解説といくつかのコンテキストを提供し、認証された存在拒否応答を提供します。NSECとNSEC3を以下に説明します。
Online signing:
オンライン署名：
[RFC4470] defines "on-line signing" (note the hyphen) as "generating and signing these records on demand", where "these" was defined as NSEC records. The current definition expands that to generating and signing RRSIG, NSEC, and NSEC3 records on demand.
[RFC4470]は、「オンライン署名」（ハイフンに注意）を「これらのレコードをデマンドで生成および署名する」と定義し、「これら」はNSECレコードとして定義されています。現在の定義では、RRSIG、NSEC、およびNSEC3レコードをオンデマンドで生成および署名することを拡大しています。
Unsigned zone:
署名ゾーン：
Section 2 of [RFC4033] defines this as "a zone that is not signed". Section 2 of [RFC4035] defines this as a "zone that does not include these records [properly constructed DNSKEY, Resource Record Signature (RRSIG), Next Secure (NSEC), and (optionally) DS records] according to the rules in this section..." There is an important note at the end of Section 5.2 of [RFC4035] that defines an additional situation in which a zone is considered unsigned: "If the resolver does not support any of the algorithms listed in an authenticated DS RRset, then the resolver will not be able to verify the authentication path to the child zone. In this case, the resolver SHOULD treat the child zone as if it were unsigned."
[RFC4033]のセクション2では、これを「署名されていないゾーン」と定義しています。[RFC4035]のセクション2では、これを「適切に構築されたDNSKEY、リソースレコード署名（RRSIG）、次のセキュア（NSEC）、および（オプションで）DSレコード）をこのセクションの規則に従って含めないゾーンとして定義しています。...「[RFC4035]のセクション5.2の最後に、ゾーンが署名されていないと見なされる追加の状況を定義する重要なメモがあります。その後、リゾルバーは子ゾーンへの認証パスを確認できません。この場合、リゾルバーは子ゾーンをまるで署名しているかのように扱う必要があります。」
NSEC:
NSEC：
"The NSEC record allows a security-aware resolver to authenticate a negative reply for either name or type non-existence with the same mechanisms used to authenticate other DNS replies." (Quoted from [RFC4033], Section 3.2) In short, an NSEC record provides authenticated denial of existence.
「NSECレコードにより、セキュリティ対応のリゾルバーは、他のDNS応答を認証するために使用される同じメカニズムで、名前またはタイプの非存在のいずれかの否定的な応答を認証することができます。」（[RFC4033]、セクション3.2から引用）要するに、NSECレコードは、認証された存在拒否を提供します。
"The NSEC resource record lists two separate things: the next owner name (in the canonical ordering of the zone) that contains authoritative data or a delegation point NS RRset, and the set of RR types present at the NSEC RR's owner name." (Quoted from [RFC4034], Section 4)
「NSECリソースレコードには、2つの別個のものがリストされています。次の所有者名（ゾーンの標準的な順序付け）には、権威あるデータまたは委任ポイントNS RRSet、およびNSEC RRの所有者名に存在するRRタイプのセットが含まれています。」（[RFC4034]、セクション4から引用）
NSEC3:
NSEC3：
Like the NSEC record, the NSEC3 record also provides authenticated denial of existence; however, NSEC3 records mitigate zone enumeration and support Opt-Out. NSEC3 resource records require associated NSEC3PARAM resource records. NSEC3 and NSEC3PARAM resource records are defined in [RFC5155].
NSECレコードと同様に、NSEC3レコードは認証された存在の拒否も提供します。ただし、NSEC3はゾーンの列挙を緩和し、オプトアウトをサポートします。NSEC3リソースレコードには、関連するNSEC3PARAMリソースレコードが必要です。NSEC3およびNSEC3PARAMリソースレコードは[RFC5155]で定義されています。
Note that [RFC6840] says that [RFC5155] "is now considered part of the DNS Security Document Family as described by Section 10 of [RFC4033]". This means that some of the definitions from earlier RFCs that only talk about NSEC records should probably be considered to be talking about both NSEC and NSEC3.
[RFC6840]は、[RFC5155]が[RFC4033]セクション10で説明されているように、DNSセキュリティドキュメントファミリの一部と見なされていると述べていることに注意してください。これは、NSECレコードについてのみ話す以前のRFCの定義の一部が、おそらくNSECとNSEC3の両方について話していると見なされるべきであることを意味します。
Opt-out:
身を引く：
"The Opt-Out Flag indicates whether this NSEC3 RR may cover unsigned delegations." (Quoted from [RFC5155], Section 3.1.2.1) Opt-out tackles the high costs of securing a delegation to an insecure zone. When using Opt-Out, names that are an insecure delegation (and empty non-terminals that are only derived from insecure delegations) don't require an NSEC3 record or its corresponding RRSIG records. Opt-Out NSEC3 records are not able to prove or deny the existence of the insecure delegations. (Adapted from [RFC7129], Section 5.1)
「オプトアウトフラグは、このNSEC3 RRが署名されていない代表団をカバーする可能性があるかどうかを示します。」（[RFC5155]から引用、セクション3.1.2.1）オプトアウトは、代表団を安全でないゾーンに確保するための高いコストに取り組んでいます。オプトアウトを使用する場合、不安定な代表団（および不安定な代表団からのみ派生した空の非ターミナル）である名前は、NSEC3レコードまたは対応するRRSIGレコードを必要としません。オプトアウトNSEC3レコードは、不安定な代表団の存在を証明または否定することができません。（[RFC7129]、セクション5.1からの適応）
Insecure delegation:
不安定な代表団：
"A signed name containing a delegation (NS RRset), but lacking a DS RRset, signifying a delegation to an unsigned subzone." (Quoted from [RFC4956], Section 2)
「代表団（NS RRSet）を含む署名済みの名前ですが、DS RRSetがなく、署名されていないサブゾーンへの代表団を意味します。」（[RFC4956]、セクション2から引用）
Zone enumeration:
ゾーン列挙：
"The practice of discovering the full content of a zone via successive queries." (Quoted from [RFC5155], Section 1.3) This is also sometimes called "zone walking". Zone enumeration is different from zone content guessing where the guesser uses a large dictionary of possible labels and sends successive queries for them, or matches the contents of NSEC3 records against such a dictionary.
「連続したクエリを介してゾーンの完全なコンテンツを発見する慣行。」（[RFC5155]、セクション1.3から引用）これは「ゾーンウォーキング」とも呼ばれることもあります。ゾーンの列挙は、ゾーンコンテンツの推測とは異なり、推測者が可能なラベルの大きな辞書を使用し、それらに連続したクエリを送信するか、そのような辞書に対してNSEC3レコードの内容を一致させます。
Validation:
検証：
Validation, in the context of DNSSEC, refers to one of the following:
検証は、DNSSECのコンテキストで、次のいずれかを指します。
* Checking the validity of DNSSEC signatures,
* DNSSEC署名の有効性を確認する、
* Checking the validity of DNS responses, such as those including authenticated denial of existence, or
* 認証された存在の拒否を含むなどのDNS応答の妥当性を確認する、または
* Building an authentication chain from a trust anchor to a DNS response or individual DNS RRsets in a response.
* 信頼のアンカーからDNS応答または個々のDNS rrsetsに応答で認証チェーンを構築します。
The first two definitions above consider only the validity of individual DNSSEC components, such as the RRSIG validity or NSEC proof validity. The third definition considers the components of the entire DNSSEC authentication chain; thus, it requires "configured knowledge of at least one authenticated DNSKEY or DS RR" (as described in [RFC4035], Section 5).
上記の最初の2つの定義では、RRSIGの有効性やNSEC証明の有効性など、個々のDNSSECコンポーネントの有効性のみを考慮しています。3番目の定義では、DNSSEC認証チェーン全体のコンポーネントを考慮します。したがって、「[RFC4035]、セクション5で説明されているように、少なくとも1つの認証されたDNSKEYまたはDS RRの構成された知識」が必要です。
[RFC4033], Section 2, says that a "Validating Security-Aware Stub Resolver... performs signature validation" and uses a trust anchor "as a starting point for building the authentication chain to a signed DNS response"; thus, it uses the first and third definitions above. The process of validating an RRSIG resource record is described in [RFC4035], Section 5.3.
[RFC4033]、セクション2は、「セキュリティ認識スタブリゾルバーの検証...署名検証を実行する」と、「署名されたDNS応答に認証チェーンを構築するための出発点」として信頼アンカーを使用すると述べています。したがって、上記の最初と3番目の定義を使用します。RRSIGリソースレコードを検証するプロセスは、[RFC4035]、セクション5.3で説明されています。
[RFC5155] refers to validating responses throughout the document in the context of hashed authenticated denial of existence; this uses the second definition above.
[RFC5155]は、認証された存在の拒否の文脈で、ドキュメント全体で応答を検証することを指します。これは、上記の2番目の定義を使用します。
The term "authentication" is used interchangeably with "validation", in the sense of the third definition above. [RFC4033], Section 2, describes the chain linking trust anchor to DNS data as the "authentication chain". A response is considered to be authentic if "all RRsets in the Answer and Authority sections of the response [are considered] to be authentic" (Quoted from [RFC4035]) DNS data or responses deemed to be authentic or validated have a security status of "secure" ([RFC4035], Section 4.3; [RFC4033], Section 5). "Authenticating both DNS keys and data is a matter of local policy, which may extend or even override the [DNSSEC] protocol extensions..." (Quoted from [RFC4033], Section 3.1)
「認証」という用語は、上記の3番目の定義の意味で、「検証」と同じ意味で使用されます。[RFC4033]、セクション2は、「認証チェーン」としてDNSデータに信頼アンカーをリンクするチェーンについて説明しています。「応答の回答と権限セクションのすべてのrrsets [REが考慮されている]（[RFC4035]から引用）DNSデータまたは本物または検証されているとみなされる応答がある場合、応答は本物であると見なされます。「セキュア」（[RFC4035]、セクション4.3; [RFC4033]、セクション5）。「DNSキーとデータの両方を認証することはローカルポリシーの問題であり、[DNSSEC]プロトコル拡張を拡張またはオーバーライドする可能性があります...」（[RFC4033]、セクション3.1から引用）
The term "verification", when used, is usually a synonym for "validation".
「検証」という用語は、使用する場合、通常「検証」の同義語です。
Validating resolver:
リゾルバーの検証：
A security-aware recursive name server, security-aware resolver, or security-aware stub resolver that is applying at least one of the definitions of validation (above) as appropriate to the resolution context. For the same reason that the generic term "resolver" is sometimes ambiguous and needs to be evaluated in context (see Section 6), "validating resolver" is a context-sensitive term.
セキュリティ対応の再帰名サーバー、セキュリティ対応のリゾルバー、または解像度のコンテキストに適切な検証の定義（上記）の少なくとも1つを適用しているセキュリティ対応のスタブリゾルバー。一般的な用語「リゾルバー」が曖昧であり、コンテキストで評価する必要があるという同じ理由で（セクション6を参照）、「リゾルバーの検証」はコンテキストに敏感な用語です。
Key signing key (KSK):
キー署名キー（KSK）：
DNSSEC keys that "only sign the apex DNSKEY RRset in a zone." (Quoted from [RFC6781], Section 3.1)
「ゾーン内のapex dnskey rrsetにのみ署名する」dnssecキー。（[RFC6781]から引用、セクション3.1）
Zone signing key (ZSK):
ゾーン署名キー（ZSK）：
"DNSSEC keys that can be used to sign all the RRsets in a zone that require signatures, other than the apex DNSKEY RRset." (Quoted from [RFC6781], Section 3.1) Also note that a ZSK is sometimes used to sign the apex DNSKEY RRset.
「Apex DNSKEY RRSET以外の署名を必要とするゾーン内のすべてのRRSetsに署名するために使用できるDNSSECキー。」（[RFC6781]、セクション3.1から引用）も、ZSKがApex DNSKEY RRSetに署名するために使用されることがあることにも注意してください。
Combined signing key (CSK):
結合署名キー（CSK）：
"In cases where the differentiation between the KSK and ZSK is not made, i.e., where keys have the role of both KSK and ZSK, we talk about a Single-Type Signing Scheme." (Quoted from [RFC6781], Section 3.1) This is sometimes called a "combined signing key" or "CSK". It is operational practice, not protocol, that determines whether a particular key is a ZSK, a KSK, or a CSK.
「KSKとZSKの区別が作成されていない場合、つまりキーがKSKとZSKの両方の役割を持っている場合、単一タイプの署名スキームについて説明します。」（[RFC6781]、セクション3.1から引用）これは、「署名キーを組み合わせた」または「CSK」と呼ばれることもあります。特定のキーがZSK、KSK、またはCSKであるかどうかを決定するのは、プロトコルではなく運用的な慣行です。
Secure Entry Point (SEP):
セキュアエントリポイント（SEP）：
A flag in the DNSKEY RDATA that "can be used to distinguish between keys that are intended to be used as the secure entry point into the zone when building chains of trust, i.e., they are (to be) pointed to by parental DS RRs or configured as a trust anchor.... Therefore, it is suggested that the SEP flag be set on keys that are used as KSKs and not on keys that are used as ZSKs, while in those cases where a distinction between a KSK and ZSK is not made (i.e., for a Single-Type Signing Scheme), it is suggested that the SEP flag be set on all keys." (Quoted from [RFC6781], Section 3.2.3) Note that the SEP flag is only a hint, and its presence or absence may not be used to disqualify a given DNSKEY RR from use as a KSK or ZSK during validation.
dnskey rdataのフラグは、「信頼の鎖を構築する際にゾーンへの安全なエントリポイントとして使用することを目的としたキーを区別するために使用できます。信頼アンカーとして構成されている....したがって、SEPフラグは、ZSKとして使用されるキーではなくKSKとして使用されるキーに設定することをお勧めしますが、KSKとZSKの区別がある場合には作られていない（つまり、単一タイプの署名スキームの場合）、SEPフラグをすべてのキーに設定することをお勧めします。」（[RFC6781]、セクション3.2.3から引用）SEPフラグはヒントのみであり、その有無は、検証中に特定のDNSKEY RRをKSKまたはZSKとして使用することからの資格を失格にするために使用されない場合があります。
The original definition of SEPs was in [RFC3757]. That definition clearly indicated that the SEP was a key, not just a bit in the key. The abstract of [RFC3757] says: "With the Delegation Signer (DS) resource record (RR), the concept of a public key acting as a secure entry point (SEP) has been introduced. During exchanges of public keys with the parent there is a need to differentiate SEP keys from other public keys in the Domain Name System KEY (DNSKEY) resource record set. A flag bit in the DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP." That definition of the SEP as a key was made obsolete by [RFC4034], and the definition from [RFC6781] is consistent with [RFC4034].
SEPの元の定義は[RFC3757]にありました。その定義は、SEPがキーだけでなく鍵であることを明確に示していました。[RFC3757]の要約は、「代表団の署名者（DS）リソースレコード（RR）により、安全なエントリポイント（SEP）として機能する公開鍵の概念が導入されました。SEPキーをドメイン名システムキー（DNSKEY）リソースレコードセットの他のパブリックキーと区別する必要があります。DNSKEYRRのフラグビットは、DNSKEYがSEPとして使用されることを示すために定義されています。鍵としてのSEPの定義は[RFC4034]によって時代遅れになり、[RFC6781]の定義は[RFC4034]と一致しています。
Trust anchor:
アンカーを信頼する：
"A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A validating security-aware resolver uses this public key or hash as a starting point for building the authentication chain to a signed DNS response. In general, a validating resolver will have to obtain the initial values of its trust anchors via some secure or trusted means outside the DNS protocol." (Quoted from [RFC4033], Section 2)
「設定されたDNSKEY RRまたはDS RRハッシュDNSKEY RR。DNSプロトコルの外側の安全な手段または信頼できる手段を介して、その信頼アンカーの初期値を取得します。」（[RFC4033]、セクション2から引用）
DNSSEC Policy (DP):
DNSSECポリシー（DP）：
A statement that "sets forth the security requirements and standards to be implemented for a DNSSEC-signed zone." (Quoted from [RFC6841], Section 2)
「DNSSECに署名したゾーンのために実装されるセキュリティ要件と標準を定めている」という声明。（[RFC6841]、セクション2から引用）
DNSSEC Practice Statement (DPS):
DNSSEC実践ステートメント（DPS）：
"A practices disclosure document that may support and be a supplemental document to the DNSSEC Policy (if such exists), and it states how the management of a given zone implements procedures and controls at a high level." (Quoted from [RFC6841], Section 2)
「DNSSECポリシーのサポートおよび補足文書になる可能性のある実践開示文書（そのような場合）は、特定のゾーンの管理が手順と制御を高レベルでどのように実装するかを述べています。」（[RFC6841]、セクション2から引用）
Hardware security module (HSM):
ハードウェアセキュリティモジュール（HSM）：
A specialized piece of hardware that is used to create keys for signatures and to sign messages without ever disclosing the private key. In DNSSEC, HSMs are often used to hold the private keys for KSKs and ZSKs and to create the signatures used in RRSIG records at periodic intervals.
署名のキーを作成し、秘密鍵を開示せずにメッセージに署名するために使用される特殊なハードウェア。DNSSECでは、HSMがKSKとZSKのプライベートキーを保持し、定期的な間隔でRRSIGレコードで使用される署名を作成するためによく使用されます。
Signing software:
署名ソフトウェア：
Authoritative DNS servers that support DNSSEC often contain software that facilitates the creation and maintenance of DNSSEC signatures in zones. There is also stand-alone software that can be used to sign a zone regardless of whether the authoritative server itself supports signing. Sometimes signing software can support particular HSMs as part of the signing process.
DNSSECをサポートする権威あるDNSサーバーには、多くの場合、ゾーン内のDNSSEC署名の作成とメンテナンスを促進するソフトウェアが含まれています。また、権威あるサーバー自体が署名をサポートするかどうかに関係なく、ゾーンに署名するために使用できるスタンドアロンソフトウェアもあります。署名ソフトウェアは、署名プロセスの一部として特定のHSMをサポートできる場合があります。
A validating resolver can determine that a response is in one of four states: secure, insecure, bogus, or indeterminate. These states are defined in [RFC4033] and [RFC4035], although the definitions in the two documents differ a bit. This document makes no effort to reconcile the definitions in the two documents and takes no position as to whether they need to be reconciled.
検証するリゾルバーは、応答が安全、不安、偽、または不確定の4つの状態のいずれかにあることを判断できます。これらの状態は[RFC4033]および[RFC4035]で定義されていますが、2つのドキュメントの定義は少し異なります。このドキュメントは、2つのドキュメントの定義を調整する努力をしておらず、それらを調整する必要があるかどうかについての立場を取得しません。
Section 5 of [RFC4033] says:
[RFC4033]のセクション5は次のように述べています。
A validating resolver can determine the following 4 states:
検証するリゾルバーは、次の4つの状態を決定できます。
Secure:
安全な：
The validating resolver has a trust anchor, has a chain of trust, and is able to verify all the signatures in the response.
検証リゾルバーには信頼のアンカーがあり、信頼のチェーンがあり、応答のすべての署名を検証することができます。
Insecure:
不安：
The validating resolver has a trust anchor, a chain of trust, and, at some delegation point, signed proof of the non-existence of a DS record. This indicates that subsequent branches in the tree are provably insecure. A validating resolver may have a local policy to mark parts of the domain space as insecure.
検証型リゾルバーには、信頼のアンカー、信頼のチェーンがあり、ある委任ポイントでは、DSレコードの存在しないことの証拠に署名しました。これは、ツリー内の後続の枝が確実に不安定であることを示しています。検証型のリゾルバーには、ドメイン空間の一部を不安定であるとマークするためのローカルポリシーがある場合があります。
Bogus:
偽：
The validating resolver has a trust anchor and a secure delegation indicating that subsidiary data is signed, but the response fails to validate for some reason: missing signatures, expired signatures, signatures with unsupported algorithms, data missing that the relevant NSEC RR says should be present, and so forth.
検証リゾルバーには、子会社のデータが署名されていることを示す信頼アンカーと安全な代表団がありますが、何らかの理由で応答が検証できません。、など。
Indeterminate:
不確定：
There is no trust anchor that would indicate that a specific portion of the tree is secure. This is the default operation mode.
ツリーの特定の部分が安全であることを示す信頼できるアンカーはありません。これはデフォルトの操作モードです。
Section 4.3 of [RFC4035] says:
[RFC4035]のセクション4.3は次のように述べています。
A security-aware resolver must be able to distinguish between four cases:
セキュリティ対応のリゾルバーは、4つのケースを区別できる必要があります。
Secure:
安全な：
An RRset for which the resolver is able to build a chain of signed DNSKEY and DS RRs from a trusted security anchor to the RRset. In this case, the RRset should be signed and is subject to signature validation, as described above.
リゾルバーが署名されたDNSKEYおよびDS RRSのチェーンを信頼できるセキュリティアンカーからRRSETまで構築できるRRSet。この場合、上記のように、RRSetに署名し、署名検証の対象となります。
Insecure:
不安：
An RRset for which the resolver knows that it has no chain of signed DNSKEY and DS RRs from any trusted starting point to the RRset. This can occur when the target RRset lies in an unsigned zone or in a descendent [sic] of an unsigned zone. In this case, the RRset may or may not be signed, but the resolver will not be able to verify the signature.
リゾルバーが、信頼できる出発点からRRSetまでの署名付きDNSKEYおよびDS RRのチェーンがないことを知っているRRSet。これは、ターゲットRRSETが署名されていないゾーンまたは署名されていないゾーンの子孫[sic]にある場合に発生する可能性があります。この場合、RRSetに署名されている場合とそうでない場合がありますが、リゾルバーは署名を確認できません。
Bogus:
偽：
An RRset for which the resolver believes that it ought to be able to establish a chain of trust but for which it is unable to do so, either due to signatures that for some reason fail to validate or due to missing data that the relevant DNSSEC RRs indicate should be present. This case may indicate an attack but may also indicate a configuration error or some form of data corruption.
リゾルバーは、何らかの理由で検証に失敗した署名のために、または関連するDNSSEC RRSのデータが欠落しているため、信頼のチェーンを確立できるはずだと信じているRRSETがそうすることができないと信じています。存在する必要があることを示します。このケースは攻撃を示している可能性がありますが、構成エラーまたは何らかの形式のデータ腐敗を示している場合があります。
Indeterminate:
不確定：
An RRset for which the resolver is not able to determine whether the RRset should be signed, as the resolver is not able to obtain the necessary DNSSEC RRs. This can occur when the security-aware resolver is not able to contact security-aware name servers for the relevant zones.
リゾルバが必要なDNSSEC RRを取得できないため、RELSTがRRSetに署名するかどうかを判断できないRRSET。これは、セキュリティ対応のリゾルバーが関連するゾーンのセキュリティ対応の名前サーバーに連絡できない場合に発生する可能性があります。
These definitions do not change any security considerations for either the global DNS or private DNS.
これらの定義では、グローバルDNSまたはプライベートDNSのセキュリティ上の考慮事項は変更されません。
References to RFC 8499 in the IANA registries have been replaced with references to this document.
IANAレジストリのRFC 8499への参照は、このドキュメントへの参照に置き換えられています。
[IANA_RootFiles]
IANA, "Root Files",
<https://www.iana.org/domains/root/files>.
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities",
RFC 882, DOI 10.17487/RFC0882, November 1983,
<https://www.rfc-editor.org/info/rfc882>.
[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>.
[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>.
[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>.
[RFC1912] Barr, D., "Common DNS Operational and Configuration
Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996,
<https://www.rfc-editor.org/info/rfc1912>.
[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>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>.
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
DOI 10.17487/RFC2182, July 1997,
<https://www.rfc-editor.org/info/rfc2182>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<https://www.rfc-editor.org/info/rfc2308>.
[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>.
[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>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
<https://www.rfc-editor.org/info/rfc4592>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<https://www.rfc-editor.org/info/rfc5155>.
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
Nameservers in Reflector Attacks", BCP 140, RFC 5358,
DOI 10.17487/RFC5358, October 2008,
<https://www.rfc-editor.org/info/rfc5358>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>.
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", STD 69, RFC 5731,
DOI 10.17487/RFC5731, August 2009,
<https://www.rfc-editor.org/info/rfc5731>.
[RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6
Reverse Zones", BCP 155, RFC 5855, DOI 10.17487/RFC5855,
May 2010, <https://www.rfc-editor.org/info/rfc5855>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>.
[RFC6561] Livingood, J., Mody, N., and M. O'Reirdan,
"Recommendations for the Remediation of Bots in ISP
Networks", RFC 6561, DOI 10.17487/RFC6561, March 2012,
<https://www.rfc-editor.org/info/rfc6561>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781,
DOI 10.17487/RFC6781, December 2012,
<https://www.rfc-editor.org/info/rfc6781>.
[RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
DOI 10.17487/RFC6840, February 2013,
<https://www.rfc-editor.org/info/rfc6840>.
[RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A
Framework for DNSSEC Policies and DNSSEC Practice
Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013,
<https://www.rfc-editor.org/info/rfc6841>.
[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>.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344,
DOI 10.17487/RFC7344, September 2014,
<https://www.rfc-editor.org/info/rfc7344>.
[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>.
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018,
<https://www.rfc-editor.org/info/rfc8310>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/info/rfc9250>.
[RFC9471] Andrews, M., Huque, S., Wouters, P., and D. Wessels, "DNS
Glue Requirements in Referral Responses", RFC 9471,
DOI 10.17487/RFC9471, September 2023,
<https://www.rfc-editor.org/info/rfc9471>.
[IANA_Resource_Registry]
IANA, "Resource Record (RR) TYPEs",
<https://www.iana.org/assignments/dns-parameters/>.
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>.
[RFC819] Su, Z. and J. Postel, "The Domain Naming Convention for
Internet User Applications", RFC 819,
DOI 10.17487/RFC0819, August 1982,
<https://www.rfc-editor.org/info/rfc819>.
[RFC952] 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>.
[RFC1713] Romao, A., "Tools for DNS debugging", FYI 27, RFC 1713,
DOI 10.17487/RFC1713, November 1994,
<https://www.rfc-editor.org/info/rfc1713>.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
DOI 10.17487/RFC1995, August 1996,
<https://www.rfc-editor.org/info/rfc1995>.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
DOI 10.17487/RFC2775, February 2000,
<https://www.rfc-editor.org/info/rfc2775>.
[RFC3172] Huston, G., Ed., "Management Guidelines & Operational
Requirements for the Address and Routing Parameter Area
Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
September 2001, <https://www.rfc-editor.org/info/rfc3172>.
[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425,
DOI 10.17487/RFC3425, November 2002,
<https://www.rfc-editor.org/info/rfc3425>.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, DOI 10.17487/RFC3493, February 2003,
<https://www.rfc-editor.org/info/rfc3493>.
[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
System KEY (DNSKEY) Resource Record (RR) Secure Entry
Point (SEP) Flag", RFC 3757, DOI 10.17487/RFC3757, April
2004, <https://www.rfc-editor.org/info/rfc3757>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004,
<https://www.rfc-editor.org/info/rfc3912>.
[RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records
and DNSSEC On-line Signing", RFC 4470,
DOI 10.17487/RFC4470, April 2006,
<https://www.rfc-editor.org/info/rfc4470>.
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
RFC 4641, DOI 10.17487/RFC4641, September 2006,
<https://www.rfc-editor.org/info/rfc4641>.
[RFC4697] Larson, M. and P. Barber, "Observed DNS Resolution
Misbehavior", BCP 123, RFC 4697, DOI 10.17487/RFC4697,
October 2006, <https://www.rfc-editor.org/info/rfc4697>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <https://www.rfc-editor.org/info/rfc4786>.
[RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security
(DNSSEC) Opt-In", RFC 4956, DOI 10.17487/RFC4956, July
2007, <https://www.rfc-editor.org/info/rfc4956>.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
<https://www.rfc-editor.org/info/rfc5625>.
[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>.
[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>.
[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and
Internationalized Domain Names for Applications (IDNA)",
RFC 5892, DOI 10.17487/RFC5892, August 2010,
<https://www.rfc-editor.org/info/rfc5892>.
[RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts
for Internationalized Domain Names for Applications
(IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010,
<https://www.rfc-editor.org/info/rfc5893>.
[RFC5894] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Background, Explanation, and
Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010,
<https://www.rfc-editor.org/info/rfc5894>.
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on
Encodings for Internationalized Domain Names", RFC 6055,
DOI 10.17487/RFC6055, February 2011,
<https://www.rfc-editor.org/info/rfc6055>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
RFC 6303, DOI 10.17487/RFC6303, July 2011,
<https://www.rfc-editor.org/info/rfc6303>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365,
DOI 10.17487/RFC6365, September 2011,
<https://www.rfc-editor.org/info/rfc6365>.
[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>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.
[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
February 2014, <https://www.rfc-editor.org/info/rfc7129>.
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7480, DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/info/rfc7480>.
[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7481, DOI 10.17487/RFC7481, March 2015,
<https://www.rfc-editor.org/info/rfc7481>.
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/info/rfc9082>.
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>.
[RFC9224] Blanchet, M., "Finding the Authoritative Registration Data
Access Protocol (RDAP) Service", STD 95, RFC 9224,
DOI 10.17487/RFC9224, March 2022,
<https://www.rfc-editor.org/info/rfc9224>.
[RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin,
"Inventory and Analysis of WHOIS Registration Objects",
RFC 7485, DOI 10.17487/RFC7485, March 2015,
<https://www.rfc-editor.org/info/rfc7485>.
[RFC7793] Andrews, M., "Adding 100.64.0.0/10 Prefixes to the IPv4
Locally-Served DNS Zones Registry", BCP 163, RFC 7793,
DOI 10.17487/RFC7793, May 2016,
<https://www.rfc-editor.org/info/rfc7793>.
[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>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017,
<https://www.rfc-editor.org/info/rfc8094>.
[RFC8109] Koch, P., Larson, M., and P. Hoffman, "Initializing a DNS
Resolver with Priming Queries", BCP 209, RFC 8109,
DOI 10.17487/RFC8109, March 2017,
<https://www.rfc-editor.org/info/rfc8109>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A.
Mankin, "DNS Zone Transfer over TLS", RFC 9103,
DOI 10.17487/RFC9103, August 2021,
<https://www.rfc-editor.org/info/rfc9103>.
[RSSAC026] Root Server System Advisory Committee (RSSAC), "RSSAC0226
RSSAC Lexicon", 2017,
<https://www.icann.org/en/system/files/files/rssac-
026-14mar17-en.pdf>.
The following definitions from RFCs are updated by this document:
RFCSの次の定義は、このドキュメントで更新されます。
* Forwarder in [RFC2308]
* [RFC2308]のフォワーダー
* QNAME in [RFC2308]
* [rfc2308]のqname
* Secure Entry Point (SEP) in [RFC3757]; note, however, that this RFC is already obsolete (see [RFC4033], [RFC4034], [RFC4035]).
* [RFC3757]のセキュアエントリポイント（SEP）;ただし、このRFCはすでに時代遅れであることに注意してください（[RFC4033]、[RFC4034]、[RFC4035]を参照）。
The following definitions are first defined in this document:
次の定義は、このドキュメントで最初に定義されています。
* "Alias" in Section 2
* セクション2の「エイリアス」
* "Apex" in Section 7
* セクション7の「頂点」
* "arpa" in Section 7
* セクション7の「ARPA」
* "Authoritative DoT (ADot)" in Section 6
* セクション6の「権威あるドット（Adot）」
* "Bailiwick" in Section 7
* セクション7の「Bailiwick」
* "Class independent" in Section 5
* セクション5の「クラス独立」
* "Classic DNS" in Section 6
* セクション6の「クラシックDNS」
* "Delegation-centric zone" in Section 7
* セクション7の「委任中心ゾーン」
* "Delegation" in Section 7
* セクション7の「委任」
* "DNS operator" in Section 9
* セクション9の「DNSオペレーター」
* "DNSSEC-aware" in Section 10
* セクション10の「DNSSEC-AWARE」
* "DNSSEC-unaware" in Section 10
* セクション10の「DNSSEC-UNAWARE」
* "Forwarding" in Section 6
* セクション6の「転送」
* "Full resolver" in Section 6
* セクション6の「完全なリゾルバー」
* "Fully Qualified Domain Name" in Section 2
* セクション2の「完全な資格のあるドメイン名」
* "Global DNS" in Section 2
* セクション2の「グローバルDNS」
* "Hardware Security Module (HSM)" in Section 10
* セクション10の「ハードウェアセキュリティモジュール（HSM）」
* "Host name" in Section 2
* セクション2の「ホスト名」
* "IDN" in Section 2
* セクション2の「IDN」
* "In-domain" in Section 7
* セクション7の「ドメイン」
* "Iterative resolution" in Section 6
* セクション6の「反復解像度」
* "Label" in Section 2
* セクション2の「ラベル」
* "Locally served DNS zone" in Section 2
* セクション2の「DNSゾーン」「DNSゾーン」
* "Naming system" in Section 2
* セクション2の「命名システム」
* "Negative response" in Section 3
* セクション3の「否定的な応答」
* "Non-recursive query" in Section 6
* セクション6の「非再帰クエリ」
* "Open resolver" in Section 6
* セクション6の「オープンリゾルバー」
* "Passive DNS" in Section 6
* セクション6の「パッシブDNS」
* "Policy-implementing resolver" in Section 6
* セクション6の「ポリシー実装リゾルバー」
* "Presentation format" in Section 5
* セクション5の「プレゼンテーション形式」
* "Priming" in Section 6
* セクション6の「プライミング」
* "Private DNS" in Section 2
* セクション2の「プライベートDNS」
* "Recursive DoT (RDot)" in Section 6
* セクション6の「再帰ドット（RDOT）」
* "Recursive resolver" in Section 6
* セクション6の「再帰リゾルバー」
* "Referrals" in Section 4
* セクション4の「紹介」
* "Registrant" in Section 9
* セクション9の「登録者」
* "Registrar" in Section 9
* セクション9の「レジストラ」
* "Registry" in Section 9
* セクション9の「レジストリ」
* "Root zone" in Section 7
* セクション7の「ルートゾーン」
* "Secure Entry Point (SEP)" in Section 10
* セクション10の「セキュアエントリポイント（SEP）」
* "Sibling domain" in Section 7
* セクション7の「兄弟ドメイン」
* "Signing software" in Section 10
* セクション10の「署名ソフトウェア」
* "Split DNS" in Section 6
* セクション6の「DNSの分割」
* "Stub resolver" in Section 6
* セクション6の「スタブリゾルバー」
* "Subordinate" in Section 8
* セクション8の「下位」
* "Superordinate" in Section 8
* セクション8の「超段階」
* "TLD" in Section 2
* セクション2の「TLD」
* "Validating resolver" in Section 10
* セクション10の「リゾルバーの検証」
* "Validation" in Section 10
* セクション10の「検証」
* "View" in Section 6
* セクション6の「表示」
* "Zone transfer" in Section 6
* セクション6の「ゾーン転送」
[RFC8499] and its predecessor, [RFC7719], were co-authored by Andrew Sullivan. The current document, which is a small update to [RFC8499], has just two authors. Andrew's work on the earlier documents is greatly appreciated.
[RFC8499]とその前身である[RFC7719]は、Andrew Sullivanによって共著されました。[RFC8499]の小さなアップデートである現在のドキュメントには、2人の著者しかいません。以前の文書に関するアンドリューの作業は大歓迎です。
Numerous people made significant contributions to [RFC8499] and [RFC7719]. Please see the acknowledgements sections in those two documents for the extensive list of contributors.
[RFC8499]および[RFC7719]に多大な貢献をしました。貢献者の広範なリストについては、これら2つのドキュメントの謝辞セクションをご覧ください。
Even though the current document is a small revision, many people in the DNSOP Working Group have contributed to it, and their work is greatly appreciated.
現在の文書は小さな改訂ですが、DNSOPワーキンググループの多くの人々がそれに貢献しており、彼らの仕事は大歓迎です。
A B C D E F G H I K L M N O P Q R S T U V W X Z
a b c d e f g h i k l m n o p q r s t u v w x z
A
a
Address and Routing Parameter Area Domain (arpa)
アドレスおよびルーティングパラメーターエリアドメイン（ARPA）
Section 7
セクション7
Address records
アドレスレコード
Section 5
セクション5
ADoT
点
Section 6
セクション6
Alias
エイリアス
Section 2
第2節
Anycast
Anycast
Section 6
セクション6
Apex
頂点
Section 7
セクション7
Asterisk label
アスタリスクラベル
Section 8
セクション8
Authoritative data
権威あるデータ
Section 7
セクション7
Authoritative server
権威あるサーバー
Section 6
セクション6
Authoritative-only server
権威ある専用サーバー
Section 6
セクション6
AXoT
axot
Section 6
セクション6
B
b
Bailiwick
バイウィック
Section 7
セクション7
C
c
Canonical name
標準名
Section 2
第2節
Child
子供
Section 7
セクション7
Class
クラス
Section 4
セクション4
Class independent
クラス独立
Section 5
セクション5
Classic DNS
クラシックDNS
Section 6
セクション6
Closest encloser
最も近いエンクロージャー
Section 8
セクション8
Closest provable encloser
最も近い証明可能なエンクロージャー
Section 8
セクション8
CNAME
cname
Section 2
第2節
Combined signing key (CSK)
結合署名キー（CSK）
Section 10
セクション10
D
d
Delegation
代表団
Section 7
セクション7
Delegation-centric zone
委任中心のゾーン
Section 7
セクション7
DNS operator
DNSオペレーター
Section 9
セクション9
DNS-over-HTTPS
dns-over-https
Section 6
セクション6
DNS-over-QUIC
dns-over-quic
Section 6
セクション6
DNS-over-TLS
dns-over-tls
Section 6
セクション6
DNSSEC Policy (DP)
DNSSECポリシー（DP）
Section 10
セクション10
DNSSEC Practice Statement (DPS)
DNSSEC実践ステートメント（DPS）
Section 10
セクション10
DNSSEC-aware and DNSSEC-unaware
DNSSEC-AWAREおよびDNSSEC-UNAWARE
Section 10
セクション10
DoH
ああ
Section 6
セクション6
Domain name
ドメイン名
Section 2
第2節
DoQ
doq
Section 6
セクション6
DoT
ドット
Section 6
セクション6
E
e
EDNS
edns
Section 5
セクション5
Empty non-terminals (ENTs)
空の非ターミナル（エント）
Section 7
セクション7
EPP
エップ
Section 9
セクション9
F
f
Fast flux DNS
高速フラックスDNS
Section 7
セクション7
FORMERR
フォーマー
Section 3
セクション3
Forward lookup
フォワードルックアップ
Section 7
セクション7
Forwarder
フォワーダー
Section 6
セクション6
Forwarding
転送
Section 6
セクション6
Full resolver
完全なリゾルバー
Section 6
セクション6
Full-service resolver
フルサービスリゾルバー
Section 6
セクション6
Fully Qualified Domain Name (FQDN)
完全資格のドメイン名（FQDN）
Section 2
第2節
G
g
Global DNS
グローバルDNS
Section 2
第2節
Glue records
グルーレコード
Section 7
セクション7
H
h
Hardware security module (HSM)
ハードウェアセキュリティモジュール（HSM）
Section 10
セクション10
Hidden master
隠されたマスター
Section 6
セクション6
Host name
ホスト名
Section 2
第2節
I
私僕俺我あたし小生拙者吾輩我輩私儀乃公愚生手前本員
IDN
idn
Section 2
第2節
In-bailiwick
インバイウィック
Section 7
セクション7
In-domain
ドメイン内
Section 7
セクション7
Insecure delegation
不安定な代表団
Section 10
セクション10
Instance
実例
Section 6
セクション6
Internationalized Domain Name
国際化されたドメイン名
Section 2
第2節
Iterative mode
反復モード
Section 6
セクション6
Iterative resolution
反復解像度
Section 6
セクション6
IXoT
ixot
Section 6
セクション6
K
k
Key signing key (KSK)
キー署名キー（KSK）
Section 10
セクション10
L
l大
Label
ラベル
Section 2
第2節
Lame delegation
ラメ代表団
Section 7
セクション7
Locally served DNS zone
DNSゾーンを局所的に提供しています
Section 2
第2節
M
m中
Master file
マスターファイル
Section 5
セクション5
Master server
マスターサーバー
Section 6
セクション6
mDNS
MDNS
Section 2
第2節
Multicast DNS
マルチキャストDNS
Section 2
第2節
N
n
Naming system
ネーミングシステム
Section 2, Paragraph 1.2.1
セクション2、パラグラフ1.2.1
Negative caching
ネガティブキャッシング
Section 6
セクション6
Negative response
否定的な応答
Section 3
セクション3
Next closer name
次の近くの名前
Section 8
セクション8
NODATA
データなし
Section 3
セクション3
NOERROR
ノーラー
Section 3
セクション3
Non-recursive query
非回復的クエリ
Section 6
セクション6
NOTIMP
notimp
Section 3
セクション3
NS
ns
Section 6
セクション6
NSEC
NSEC
Section 10
セクション10
NSEC3
NSEC3
Section 10
セクション10
NXDOMAIN
nxdomain
Section 3
セクション3
O
o
Occluded name
閉塞名
Section 7
セクション7
on-line signing
オンライン署名
Section 10
セクション10
online signing
オンライン署名
Section 10
セクション10
Open resolver
リゾルバーを開きます
Section 6
セクション6
OPT
Opt
Section 5
セクション5
Opt-out
身を引く
Section 10
セクション10
Origin
起源
Section 7
セクション7
Out-of-bailiwick
バイリウィック外
Section 7
セクション7
Owner
所有者
Section 5
セクション5
P
p
Parent
親
Section 7
セクション7
Passive DNS
パッシブDNS
Section 6
セクション6
Policy-implementing resolver
ポリシーを実装するリゾルバー
Section 6
セクション6
Presentation format
プレゼンテーション形式
Section 5
セクション5
Primary master
プライマリマスター
Section 6
セクション6
Primary server
プライマリサーバー
Section 6
セクション6
Priming
プライミング
Section 6
セクション6
Privacy-enabling DNS server
プライバシーを有効にするDNSサーバー
Section 6
セクション6
Private DNS
プライベートDNS
Section 2
第2節
Public suffix
パブリックサフィックス
Section 9
セクション9
Q
Q
QNAME
QName
Section 4
セクション4
R
r
RDAP
rdap
Section 9
セクション9
RDoT
rdot
Section 6
セクション6
Recursive DoT
再帰ドット
Section 6
セクション6
Recursive mode
再帰モード
Section 6, Paragraph 4.10.1
セクション6、パラグラフ4.10.1
Recursive query
再帰クエリ
Section 6
セクション6
Recursive resolver
再帰リゾルバー
Section 6
セクション6
Referrals
紹介
Section 4
セクション4
REFUSED
拒否した
Section 3
セクション3
Registrant
登録者
Section 9
セクション9
Registrar
レジストラ
Section 9
セクション9
Registry
レジストリ
Section 9
セクション9
Resolver
リゾルバ
Section 6
セクション6
Reverse DNS, reverse lookup
逆DNS、リバースルックアップ
Section 7
セクション7
Root hints
ルートヒント
Section 6
セクション6
Root zone
ルートゾーン
Section 7
セクション7
RR
RR
Section 5
セクション5
RRset
rrset
Section 5
セクション5
S
s小
Secondary server
セカンダリサーバー
Section 6
セクション6
Secure Entry Point (SEP)
セキュアエントリポイント（SEP）
Section 10
セクション10
SERVFAIL
サーブファイル
Section 3
セクション3
Service name
サービス名
Section 7
セクション7
Sibling domain
兄弟ドメイン
Section 7
セクション7
Signed zone
署名ゾーン
Section 10
セクション10
Signing software
署名ソフトウェア
Section 10
セクション10
Slave server
スレーブサーバー
Section 6
セクション6
SOA
SOA
Section 5
セクション5
SOA field names
SOAフィールド名
Section 5
セクション5
Source of Synthesis
合成のソース
Section 8, Paragraph 1.14.1
セクション8、パラグラフ1.14.1
Split DNS
DNSを分割します
Section 6
セクション6
Split-horizon DNS
スプリットホリゾンDNS
Section 6
セクション6
Stealth server
ステルスサーバー
Section 6
セクション6
Stub resolver
スタブリゾルバー
Section 6
セクション6
Subdomain
サブドメイン
Section 2
第2節
Subordinate
下位
Section 9
セクション9
Superordinate
上位
Section 9
セクション9
T
t
TLD
tld
Section 2
第2節
Trust anchor
アンカーを信頼します
Section 10
セクション10
TTL
TTL
Section 5
セクション5
U
u
Unsigned zone
署名されていないゾーン
Section 10
セクション10
V
v
Validating resolver
リゾルバーの検証
Section 10
セクション10
Validation
検証
Section 10, Paragraph 2.26.1
セクション10、パラグラフ2.26.1
View
ビュー
Section 6
セクション6
W
w
WHOIS
誰が
Section 9
セクション9
Wildcard
ワイルドカード
Section 8
セクション8
Wildcard domain name
ワイルドカードドメイン名
Section 8
セクション8
X
バツ
XoT
xot
Section 6
セクション6
Z
z
Zone
ゾーン
Section 7
セクション7
Zone cut
ゾーンカット
Section 7
セクション7
Zone enumeration
ゾーン列挙
Section 10
セクション10
Zone signing key (ZSK)
ゾーン署名キー（ZSK）
Section 10
セクション10
Zone transfer
ゾーン転送
Section 6
セクション6
Paul Hoffman
ICANN
Email: paul.hoffman@icann.org
Kazunori Fujiwara
Japan Registry Services Co., Ltd.
Email: fujiwara@jprs.co.jp