Internet Engineering Task Force (IETF) S. Huque
Request for Comments: 9824 Salesforce
Updates: 4034, 4035 C. Elmerot
Category: Standards Track Cloudflare
ISSN: 2070-1721 O. Gudmundsson
September 2025
This document describes a technique to generate a signed DNS response on demand for a nonexistent name by claiming that the name exists but doesn't have any data for the queried record type. Such responses require only one minimally covering NSEC or NSEC3 record, allow online signing servers to minimize signing operations and response sizes, and prevent zone content disclosure.
このドキュメントでは、名前が存在するが、クエリのレコードタイプのデータがないと主張することにより、存在しない名前の需要に応じて署名されたDNS応答を生成する手法について説明します。このような応答では、NSECまたはNSEC3レコードを最小限に抑える必要があり、オンライン署名サーバーが署名操作と応答サイズを最小限に抑え、ゾーンコンテンツの開示を防ぐことができます。
This document updates RFCs 4034 and 4035.
このドキュメントは、RFCS 4034および4035を更新します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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 Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、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/rfc9824.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9824で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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 and Motivation
1.1. Requirements Language
2. Distinguishing Nonexistent Names
3. Generating Responses with NSEC
3.1. Responses for Nonexistent Names
3.2. Responses for Nonexistent Types
3.3. Responses for Wildcard Matches
3.4. Responses for Unsigned Referrals
3.5. Responses to Explicit Queries for NXNAME
4. Generating Responses with NSEC3
5. Response Code Restoration
5.1. Signaled Response Code Restoration
6. Operational Implications
7. Updates to RFCs
7.1. Updates to RFC 4034
7.2. Updates to RFC 4035
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Other Approaches
Appendix B. Historical Implementation Notes
Acknowledgements
Authors' Addresses
One of the functions of DNS Security Extensions (DNSSEC) [RFC9364] is "authenticated denial of existence", i.e., proving that a DNS name or record type does not exist. Normally, this is done by means of signed NSEC or NSEC3 records. In the precomputed signature model, these records chain together existing names, or cryptographic hashes of them, in the zone. In the online signing model, described for NSEC in [RFC4470] and for NSEC3 in Appendix B of [RFC7129], they are used to dynamically compute an epsilon function around the QNAME. The Type Bit Maps field in the data of the NSEC or NSEC3 record asserts which resource record (RR) types are present at the name.
DNSセキュリティエクステンション（DNSSEC）[RFC9364]の関数の1つは、「認証された存在の拒否」です。つまり、DNS名またはレコードタイプが存在しないことを証明しています。通常、これは署名されたNSECまたはNSEC3レコードによって行われます。事前に計算された署名モデルでは、これらの記録は、ゾーン内の既存の名前、またはそれらの暗号化のハッシュを一緒にチェーンします。[RFC4470]のNSECおよび[RFC7129]の付録BのNSEC3について説明されているオンライン署名モデルでは、QNAMEの周りにエプシロン関数を動的に計算するために使用されます。NSECまたはNSEC3レコードのデータのタイプビットマップフィールドは、どのリソースレコード（RR）タイプが名前に存在するかを主張します。
The response for a nonexistent name requires up to two signed NSEC records or up to three signed NSEC3 records (and for online signers, the associated cryptographic computation) to prove that (1) the name did not explicitly exist in the zone and (2) it could not have been synthesized by a wildcard.
存在しない名前の応答には、最大2つの署名されたNSECレコードまたは最大3つの署名されたNSEC3レコード（およびオンライン署名者の場合、関連する暗号計算）が必要です。
This document describes an alternative technique, "Compact Denial of Existence" or "Compact Answers", to generate a signed DNS response on demand for a nonexistent name by claiming that the name exists but has no resource record sets associated with the queried type, i.e., it returns a NODATA response rather than an NXDOMAIN response. A NODATA response, which has a response code (RCODE) of NOERROR and an empty ANSWER section, requires only one NSEC or NSEC3 record matching the QNAME. This has two advantages: The DNS response size is smaller, and it reduces the online cryptographic work involved in generating the response.
このドキュメントでは、名前が存在するが、クエリタイプに関連付けられたリソースレコードセットがないと主張することにより、存在しない名前の需要のある署名されたDNS応答を生成するための代替手法「コンパクトな存在の拒否」または「コンパクトな回答」について説明します。NoErrorの応答コード（Rcode）と空の回答セクションを備えたNodata応答には、QNAMEに一致するNSECまたはNSEC3レコードのみが必要です。これには2つの利点があります。DNS応答サイズは小さく、応答の生成に伴うオンライン暗号化作業を減らします。
The use of minimally covering NSEC or NSEC3 records also prevents adversaries from enumerating the entire contents of DNS zones by walking the NSEC chain or performing an offline dictionary attack on the hashes in the NSEC3 chain.
NSECまたはNSEC3レコードを最小限に抑えることで、NSECチェーンを歩いたり、NSEC3チェーンのハッシュでオフライン辞書攻撃を行ったりすることにより、敵がDNSゾーンの内容物全体を列挙することも妨げられます。
This document assumes a reasonable level of familiarity with DNS operations and protocol terms. Much of the terminology is explained in further detail in "DNS Terminology" [RFC9499].
このドキュメントでは、DNSの操作とプロトコル用語に合理的なレベルの精通度を想定しています。用語の多くは、「DNS用語」[RFC9499]でさらに詳細に説明されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This method generates NODATA responses for nonexistent names that don't match a DNS wildcard. Since there are clearly no record types for such names, the NSEC Type Bit Maps field in the response will only contain the NSEC and RRSIG types (and in the case of NSEC3, the Type Bit Maps field will be empty). Tools that need to accurately identify nonexistent names in responses cannot rely on this specific type bitmap because Empty Non-Terminal (ENT) names (which positively exist) also have no record types at the name and will return exactly the same Type Bit Maps field.
この方法は、DNSワイルドカードと一致しない存在しない名前のNodata応答を生成します。そのような名前のレコードタイプは明らかにないため、応答のNSECタイプビットマップフィールドにはNSECおよびRRSIGタイプのみが含まれます（NSEC3の場合、タイプビットマップフィールドは空になります）。応答で存在しない名前を正確に識別する必要があるツールは、空の非ターミナル（ent）名（積極的に存在する）も名前にレコードタイプがなく、まったく同じタイプビットマップフィールドを返すため、この特定のタイプビットマップに依存することはできません。
This specification defines the use of NXNAME (128), a synthetic RR type to signal the presence of a nonexistent name. See Section 9. The mnemonic for this RR type is NXNAME, chosen to clearly distinguish it from the response code mnemonic NXDOMAIN.
この仕様は、存在しない名前の存在を示す合成RRタイプであるNXNAME（128）の使用を定義します。セクション9を参照してください。このRRタイプのニーモニックはNXNAMEであり、応答コードのMnemonic NxDomainと明確に区別するために選択されます。
This RR type is added to the NSEC Type Bit Maps field for responses to nonexistent names, in addition to the mandated RRSIG and NSEC types. If NSEC3 is being used, this RR type is the sole entry in the Type Bit Maps field. It is a "Meta-TYPE", as defined in [RFC6895], and it stores no data in a DNS zone and cannot be usefully queried. Section 3.5 describes what a DNS resolver or authoritative server should do if it receives an explicit query for NXNAME.
このRRタイプは、義務付けられたRRSIGおよびNSECタイプに加えて、存在しない名前に対する応答のために、NSECタイプビットマップフィールドに追加されます。NSEC3が使用されている場合、このRRタイプは、タイプビットマップフィールドの唯一のエントリです。[RFC6895]で定義されているように、これは「メタタイプ」であり、DNSゾーンにデータを保存せず、有用に照会することはできません。セクション3.5では、NXNAMEの明示的なクエリを受信した場合、DNSリゾルバーまたは権威あるサーバーが何をすべきかについて説明します。
No special handling of this RR type is required on the part of DNS resolvers. However, resolvers may optionally implement the behavior described in Section 5.1 ("Signaled Response Code Restoration") to better restore NXDOMAIN visibility to various applications that may remain oblivious to the new NXNAME signal.
DNSリゾルバーの側では、このRRタイプの特別な取り扱いは必要ありません。ただし、リゾルバーはオプションで、セクション5.1（「信号応答コードの復元」）で説明されている動作を実装して、新しいNXNAME信号を忘れている可能性のあるさまざまなアプリケーションへのnxDomainの可視性をより適切に復元する場合があります。
This section describes various types of answers generated by authoritative servers implementing Compact Denial of Existence using NSEC. Section 4 describes changes needed to support NSEC3.
このセクションでは、NSECを使用して存在のコンパクトな拒否を実装する権威あるサーバーによって生成されるさまざまなタイプの回答について説明します。セクション4では、NSEC3をサポートするために必要な変更について説明します。
When the authoritative server receives a query for a nonexistent name in a zone that it serves, a NODATA response (response code NOERROR, empty Answer section) is generated with a dynamically constructed NSEC record with the owner name matching the QNAME placed in the Authority section.
権威あるサーバーが提供するゾーン内の存在しない名前のクエリを受信すると、ノーダタ応答（応答コードnoerror、空の回答セクション）が生成されます。
The Next Domain Name field SHOULD be set to the immediate lexicographic successor of the QNAME. This is accomplished by adding a leading label with a single null (zero-value) octet. The Type Bit Maps field MUST only have the bits set for the following RR Types: RRSIG, NSEC, and NXNAME.
次のドメイン名フィールドは、QNAMEの即時の辞書編集の後継者に設定する必要があります。これは、単一のnull（ゼロ値）Octetを備えた主要なラベルを追加することで実現されます。タイプビットマップフィールドには、RRSIG、NSEC、およびNXNAMEのRRタイプのビットのみが設定されている必要があります。
For example, a request for the nonexistent name "a.example.com." would result in the generation of the following NSEC record (in DNS presentation format):
たとえば、存在しない名前「a.example.com」のリクエスト。次のNSECレコードの生成（DNSプレゼンテーション形式）が生成されます。
a.example.com. 300 IN NSEC \000.a.example.com. RRSIG NSEC NXNAME
The NSEC record MUST have corresponding RRSIGs generated.
NSECレコードには、生成された対応するRRSIGが必要です。
When the authoritative server receives a query for a name that exists but has no resource record sets associated with the queried type, it generates a NODATA response with a dynamically constructed signed NSEC record in the Authority section. The owner name of the NSEC record matches the QNAME. The Next Domain Name field is set to the immediate lexicographic successor of the QNAME. The Type Bit Maps field lists the available RR types at the name.
権威あるサーバーが、存在するが、クエリタイプに関連付けられたリソースレコードセットがない名前のクエリを受信すると、権限セクションで動的に構築された署名されたNSECレコードを使用してノーダタ応答を生成します。NSECレコードの所有者名はQNameと一致します。次のドメイン名フィールドは、QNAMEの即時の辞書的後継者に設定されています。タイプビットマップフィールドには、名前の使用可能なRRタイプがリストされています。
An ENT is a special subset of this category, where the name has no resource record sets of any type (but has descendant names that do). For a query for an ENT, the NSEC Type Bit Maps field will only contain RRSIG and NSEC. (Note that this is substantially different than the ENT response in precomputed NSEC, where the NSEC record has the same type bitmap but "covers" rather than matches the ENT and has the Next Domain Name field set to the next lexicographic descendant of the ENT in the zone.)
entは、このカテゴリの特別なサブセットであり、名前には任意のタイプのリソースレコードセットがありません（ただし、子孫の名前があります）。ENTのクエリの場合、NSECタイプビットマップフィールドにはRRSIGとNSECのみが含まれます。（これは、NSECレコードが同じタイプのビットマップを持っているが、entと一致するのではなく「カバー」し、ゾーン内のentの次の辞書登録者に設定された次のドメイン名フィールドを持っている、事前計算されたNSECのENT応答とは大幅に異なることに注意してください。）
For wildcard matches, the authoritative server will provide a dynamically signed response that claims that the QNAME exists explicitly. Specifically, the answer RRset will have an RRSIG record demonstrating an exact match (i.e., the label count in the RRSIG RDATA will be equal to the number of labels in the query name minus the root label). This obviates the need to include an NSEC record in the Authority section of the response that shows that no closer match than the wildcard was possible.
ワイルドカードの一致の場合、権威あるサーバーは、QNameが明示的に存在すると主張する動的に署名された応答を提供します。具体的には、回答rrsetには正確な一致を示すRRSIGレコードがあります（つまり、rrsig rdataのラベルカウントは、クエリ名のラベルの数値からルートラベルを差し引いたラベルの数に等しくなります）。これにより、WildCardよりも緊密な一致がないことを示す応答の権限セクションにNSECレコードを含める必要性がなくなります。
For a wildcard NODATA match (where the QNAME matches a wildcard but no data for the queried type exists), a response akin to a non-wildcard NODATA is returned. The Answer section is empty, and the Authority section contains a single NSEC record that matches the query name with a Type Bit Maps field representing the list of types available at the wildcard.
ワイルドカードNodataマッチ（QNameがワイルドカードと一致しますが、クエリタイプのデータは存在しません）の場合、ワイルドカード以外のノダタに似た応答が返されます。回答セクションは空で、authorityセクションには、クエリ名と一致する単一のNSECレコードが含まれています。
Per the DNSSEC protocol, a referral to an unsigned subzone includes an NSEC record whose owner name matches the subzone and proves the delegation is unsigned by the absence of the Delegation Signer (DS) RR type bit in the Type Bit Maps field.
DNSSECプロトコルによると、署名されていないサブゾーンへの紹介には、所有者の名前がサブゾーンと一致し、委任がタイプビットマップフィールドに委任署名者（DS）RRタイプビットがないことで署名されていないことが証明されているNSECレコードが含まれます。
With Compact Denial of Existence, the Next Domain Name field for this NSEC record is computed with a slightly different epsilon function than the immediate lexicographic successor of the owner name, as that name would then fall under the delegated subzone. Instead, the Next Domain Name field is formed by appending a zero octet to the first label of the owner name.
コンパクトな存在の拒否により、このNSECレコードの次のドメイン名フィールドは、所有者名の即時の辞書的後継者とはわずかに異なるエプシロン関数で計算されます。代わりに、次のドメイン名フィールドは、所有者名の最初のラベルにゼロオクテットを追加することにより形成されます。
For example, a referral response for the subzone sub.example.com would include an NSEC record like the following:
たとえば、subzone sub.example.comの紹介応答には、次のようなNSECレコードが含まれます。
sub.example.com. 300 IN NSEC sub\000.example.com. NS RRSIG NSEC
NXNAME is a Meta-TYPE that SHOULD NOT appear anywhere in a DNS message apart from the NSEC type bitmap of a Compact Answer response for a nonexistent name. However, if a DNS server implementing this specification receives an explicit query for the NXNAME RR type, this section describes what the response ought to be.
NXNameは、存在しない名前のコンパクトな回答応答のNSECタイプビットマップとは別に、DNSメッセージのどこにも表示されないメタタイプです。ただし、この仕様を実装するDNSサーバーがNXNAME RRタイプの明示的なクエリを受信した場合、このセクションでは応答がどうあるべきかについて説明します。
If an explicit query for the NXNAME RR type is received, the DNS server MUST return a Format Error (response code FORMERR). A resolver MUST NOT forward these queries upstream or attempt iterative resolution. Many DNS server implementations already return errors for all types in the range for Meta-TYPEs and QTYPEs, except those types that are already defined to support queries.
NXNAME RRタイプの明示的なクエリが受信された場合、DNSサーバーはフォーマットエラー（応答コードFORMERR）を返す必要があります。リゾルバーは、これらのクエリを上流に転送したり、反復解像度を試みてはなりません。多くのDNSサーバーの実装は、クエリをサポートするために既に定義されているタイプを除き、メタタイプとQTypesの範囲内のすべてのタイプのエラーをすでに返しています。
Optionally, a DNS server MAY also include the following Extended DNS Error (EDE) code [RFC8914] in the response: 30 (Invalid Query Type). See Section 9.
オプションで、DNSサーバーには、応答に次の拡張DNSエラー（EDE）コード[RFC8914]を含めることもできます：30（無効なクエリタイプ）。セクション9を参照してください。
Note that this EDE code is generally applicable to any RR type that ought not appear in DNS queries.
このEDEコードは、一般にDNSクエリに表示されないRRタイプに適用できることに注意してください。
NSEC3 [RFC5155] uses hashed names to provide zone enumeration defense. This protection is better provided by minimally covering NSEC records. NSEC3's Opt-Out feature also provides no specific benefit for online signing implementations (minimally covering NSEC3 records provide no useful Opt-Out span). Hence, there is no known advantage to implementing Compact Denial of Existence with NSEC3. However, an existing implementation of conventional NSEC3 online signing migrating to Compact Denial of Existence may find it simpler to do so with NSEC3 rather than implementing NSEC from scratch.
NSEC3 [RFC5155]は、ハッシュした名前を使用してゾーン列挙防御を提供します。この保護は、NSECレコードを最小限に抑えることにより、より適切に提供されます。NSEC3のオプトアウト機能は、オンライン署名の実装に特別な利点も提供しません（NSEC3レコードを最小限に抑えることは、有用なオプトアウトスパンを提供しません）。したがって、NSEC3で存在のコンパクトな拒否を実装することには既知の利点はありません。ただし、コンパクトな存在の否定に移行する従来のNSEC3オンライン署名の既存の実装は、NSECをゼロから実装するのではなく、NSEC3でそれを行う方が簡単になる場合があります。
For NSEC3, the functional details of the protocol remain as described in Section 3, with the following changes.
NSEC3の場合、プロトコルの機能の詳細は、セクション3で説明されているとおり、次の変更があります。
NSEC3 records and their signatures are dynamically generated instead of NSEC.
NSEC3レコードとその署名は、NSECの代わりに動的に生成されます。
The NSEC3 parameters SHOULD be set to algorithm 1, a flags field of 0, an additional hash iteration count of 0, and an empty salt. In DNS presentation format, this is "1 0 0 -".
NSEC3パラメーターは、アルゴリズム1、0のフラグフィールド、追加のハッシュ反復カウント0、および空の塩に設定する必要があります。DNSプレゼンテーション形式では、これは「1 0 0-」です。
The owner name of the NSEC3 resource record is the NSEC3 hash of the relevant domain name, encoded in Base32 with Extended Hex Alphabet ([RFC4648], Section 7), prepended as a single label to the name of the zone. The Next Hashed Owner Name is the immediate name successor of the unencoded binary form of the previous hash, which can be computed by adding one to the binary hash value.
NSEC3リソースレコードの所有者名は、関連するドメイン名のNSEC3ハッシュです。Base32にエンコードされた拡張ヘックスアルファベット（[RFC4648]、セクション7）は、ゾーンの名前の単一ラベルとして準備されています。次のハッシュされた所有者名は、前のハッシュのエンコードされていないバイナリ形式の即時名の後継者です。これは、バイナリハッシュ値に追加することで計算できます。
In responses for nonexistent names, the Type Bit Maps field will contain only the NXNAME Meta-TYPE. In responses to ENT names, the Type Bit Maps field will be empty.
存在しない名前の応答では、型ビットマップフィールドにはNXNAMEメタタイプのみが含まれます。ENT名への応答では、タイプビットマップフィールドが空になります。
For example, a request for the nonexistent name "a.example.com." would result in the generation of the following NSEC3 record:
たとえば、存在しない名前「a.example.com」のリクエスト。次のNSEC3レコードが生成されます。
H64KFA4P1ACER2EBPS9QSDK6DNP8B3JQ.example.com. IN NSEC3 1 0 0 - (
H64KFA4P1ACER2EBPS9QSDK6DNP8B3JR NXNAME )
Unlike Compact Denial of Existence with NSEC, no special form of the Next Hashed Owner Name field for unsigned referrals is needed. The Next Hashed Owner Name field remains the NSEC3 hash of original owner name plus one.
NSECを使用したコンパクトな存在の否定とは異なり、署名されていない紹介のために次のハッシュされた所有者名フィールドの特別な形式は必要ありません。次のハッシュされた所有者名フィールドは、元の所有者名と1のNSEC3ハッシュのままです。
For nonexistent names, implementations should try to preserve the response code value of 3 (NXDOMAIN) whenever possible. This is generally possible for non-DNSSEC-enabled queries, namely those that do not set the DO bit ("DNSSEC answer OK") in the EDNS0 OPT header. For such queries, authoritative servers implementing Compact Denial of Existence could return a normal NXDOMAIN response. However, there may be limited benefit to doing this since most modern DNS resolvers are DNSSEC aware, and per Section 3 of [RFC3225], DNSSEC-aware recursive servers are required to set the DO bit on outbound queries, regardless of the status of the DO bit on incoming requests.
存在しない名前の場合、実装は、可能な限り3（nxDomain）の応答コード値を保持しようとする必要があります。これは一般に、EDNS0 OPTヘッダーでDOビット（「DNSSEC Answer OK "）を設定しない非DNSEC対応クエリで可能です。このようなクエリの場合、存在のコンパクトな拒否を実装する権威あるサーバーは、通常のNxDomain応答を返す可能性があります。ただし、ほとんどの最新のDNSリゾルバーはDNSSECが認識しており、[RFC3225]のセクション3によると、DNSSECに認識された再帰サーバーによると、DUSビットのステータスに関係なくAutboundクエリにDOビットを設定するために、これを行うことに限られた利点があるかもしれません。
A validating resolver that understands the NXNAME signal from an authoritative server could modify the response code from NOERROR to NXDOMAIN in responses they return to downstream queriers that have not set the DO bit in their requests.
権威あるサーバーからNXNAME信号を理解している検証リゾルバーは、リクエストに少しdoを設定していない下流のクエリエに戻る応答で、NoerrorからNXDomainに応答コードを変更できます。
This section describes an optional but recommended scheme to permit signaled restoration of the NXDOMAIN RCODE for DNSSEC-enabled responses. A new EDNS0 [RFC6891] header flag is defined in the second most significant bit of the flags field in the EDNS0 OPT header. This flag is referred to as the Compact Answers OK (CO) flag.
このセクションでは、DNSSEC対応応答のNXDomain RCodeのシグナル付き修復を許可するオプションであるが推奨されるスキームについて説明します。新しいEDNS0 [RFC6891]ヘッダーフラグは、EDNS0 OPTヘッダーの2番目に重要なフラグフィールドで定義されています。このフラグは、Compact Answers OK（CO）フラグと呼ばれます。
+0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO|CO| Z |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
When this flag is sent in a query by a resolver, it indicates that the resolver will accept a NODATA response with a signed NXNAME for a nonexistent name, together with the response code field set to NXDOMAIN (3).
このフラグがリゾルバーによってクエリで送信されると、リゾルバーがNXDomain（3）に設定された応答コードフィールドとともに、存在しない名前の署名付きNXNameを使用したNodata応答を受け入れることを示します。
In responses to such queries, an authoritative server implementing both Compact Denial of Existence and this signaling scheme will set the Compact Answers OK EDNS header flag and, for nonexistent names, will additionally set the response code field to NXDOMAIN.
このようなクエリへの応答では、コンパクトな存在の拒否とこのシグナリングスキームの両方を実装する権威あるサーバーが、コンパクトな回答を設定し、存在するヘッダーフラグを設定し、存在しない名前では、応答コードフィールドをNXDomainにさらに設定します。
EDNS is a hop-by-hop signal, so resolvers will need to record the presence of this flag in associated cache data and respond to downstream DNSSEC-enabled queriers appropriately. If the querier does not set the Compact Answers OK flag, the resolver will need to reset the response code back to NOERROR (0) for an NXNAME response.
EDNSはホップバイホップ信号であるため、リゾルバーは、関連するキャッシュデータにこのフラグの存在を記録し、下流のDNSEC対応クエリエに適切に応答する必要があります。QuerierがCompact Answers OKフラグを設定しない場合、ResolverはNXNAME応答のために応答コードをNOERROR（0）に戻す必要があります。
For DNSSEC-enabled queries, a signed zone at an authoritative server implementing Compact Answers will never return a response with a response code of NXDOMAIN, unless they have implemented the optional response code restoration feature described in Section 5.1. Similarly, resolvers not implementing this feature will also not be able to return NXDOMAIN. In the absence of this, tools that rely on accurately determining nonexistent names will need to infer them from the presence of the NXNAME RR type in the Type Bit Maps field of the NSEC record in NODATA responses from these servers.
DNSSEC対応クエリの場合、コンパクトな回答を実装する権威あるサーバーの署名ゾーンは、セクション5.1で説明されているオプションの応答コード復元機能を実装していない限り、NXDomainの応答コードで応答を返すことはありません。同様に、この機能を実装していないリゾルバーは、NXDomainを返すこともできません。これがない場合、存在しない名前を正確に決定することに依存するツールは、これらのサーバーからNodata応答のNSECレコードのタイプビットマップフィールドにnxName RRタイプの存在から推測する必要があります。
Address lookup functions typically invoked by applications may need to do more work when dealing with implementations of Compact Answers. For example, a NODATA response to the lookup of a AAAA record for a nonexistent name can cause such functions to issue another query at the same name for an A record, whereas an NXDOMAIN response to the first query could suppress additional queries for other types at that name. Address lookup functions could be enhanced to issue DNSSEC-enabled queries and to examine the NSEC Type Bit Maps field in responses to accurately determine nonexistent names. Note that this is less of a concern with connection functions like Happy Eyeballs [RFC8305] that typically issue back-to-back DNS queries without waiting for individual responses.
通常、アプリケーションによって呼び出されるアドレスルックアップ関数は、コンパクトな回答の実装を扱う際にさらに作業を行う必要がある場合があります。たとえば、存在しない名前のAAAAレコードのルックアップに対するNodata応答は、そのような関数がAレコードの同じ名前で別のクエリを発行する可能性がありますが、最初のクエリに対するNXDomain応答は、その名前の他のタイプの追加クエリを抑制することができます。アドレスルックアップ関数を強化して、DNSSEC対応クエリを発行し、存在しない名前を正確に決定するための応答でNSECタイプビットマップフィールドを調べることができます。これは、通常、個々の応答を待たずに連続したDNSクエリを発行するHappy Eyeballs [RFC8305]のような接続関数の懸念ではないことに注意してください。
Protocol optimizations that enable DNS resolvers to synthesize NXDOMAIN or wildcard responses, like those described in [RFC8020] and [RFC8198], cannot be realized from responses that use Compact Denial of Existence. In general, no online signing scheme that employs minimally covering NSEC or NSEC3 records (including this one) permits NXDOMAIN or wildcard response synthesis in the style described in [RFC8198]. Additionally, this protocol also precludes NXDOMAIN synthesis for DNSSEC-enabled responses in the style described in [RFC8020].
[RFC8020]や[RFC8198]に記載されているように、DNSリゾルバーがNxDomainまたはWildCard応答を合成できるようにするプロトコル最適化は、コンパクトな存在の拒否を使用する応答からは実現できません。一般に、[RFC8198]に記載されているスタイルで、NSECまたはNSEC3レコード（これを含む）を最小限に採用するオンライン署名スキームでは、NXDomainまたはWildCard応答合成を許可することはありません。さらに、このプロトコルは、[RFC8020]で説明されているスタイルのDNSSEC対応応答のNxDomain合成も排除します。
Section 4.1.2 of [RFC4034] ("The Type Bit Maps Field") states the following:
[RFC4034]のセクション4.1.2（ "タイプビットマップフィールド"）は次のとおりです。
Bits representing pseudo-types MUST be clear, as they do not appear in zone data. If encountered, they MUST be ignored upon being read.
擬似タイプを表すビットは、ゾーンデータに表示されないため、明確でなければなりません。遭遇した場合、読まれると無視する必要があります。
This paragraph is updated to the following:
この段落は次のように更新されます。
Bits representing pseudo-types MUST be clear, as they do not appear in zone data. If encountered, they MUST be ignored upon being read. There is one exception to this rule for Compact Denial of Existence (RFC 9824), where the NXNAME pseudo-type is allowed to appear in responses to nonexistent names.
擬似タイプを表すビットは、ゾーンデータに表示されないため、明確でなければなりません。遭遇した場合、読まれると無視する必要があります。この規則には、コンパクトな存在拒否（RFC 9824）の1つの例外があり、nxname pseudo-typeは存在しない名前への応答に表示されます。
Note: As a practical matter, no known resolver insists that pseudo-types not be set in the NSEC Type Bit Maps field, so this restriction (prior to its revision) has posed no problem for the deployment of this mechanism.
注：実際の問題として、擬似タイプがNSECタイプビットマップフィールドに設定されていないと主張する既知のリゾルバーは、この制限（その改訂前）がこのメカニズムの展開に問題はありませんでした。
Section 2.3 of [RFC4035] ("Including NSEC RRs in a Zone") states the following:
[RFC4035]（ "ゾーン内のNSEC RRSを含む"）のセクション2.3は次のとおりです。
An NSEC record (and its associated RRSIG RRset) MUST NOT be the only RRset at any particular owner name. That is, the signing process MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not the owner name of any RRset before the zone was signed. The main reasons for this are a desire for namespace consistency between signed and unsigned versions of the same zone and a desire to reduce the risk of response inconsistency in security oblivious recursive name servers.
NSECレコード（および関連するRRSIG RRSet）は、特定の所有者名で唯一のRRSetであってはなりません。つまり、署名プロセスは、ゾーンが署名される前のrrsetの所有者名ではなかった所有者名ノードのNSECまたはRRSIG RRSを作成してはなりません。これの主な理由は、同じゾーンの署名されたバージョンと署名されていないバージョンとの間の名前空間の一貫性と、セキュリティ忘却の再帰名サーバーの応答の矛盾を減らすことを望んでいることです。
This paragraph is updated to the following:
この段落は次のように更新されます。
An NSEC record (and its associated RRSIG RRset) MUST NOT be the only RRset at any particular owner name. That is, the signing process MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not the owner name of any RRset before the zone was signed. The main reasons for this are a desire for namespace consistency between signed and unsigned versions of the same zone and a desire to reduce the risk of response inconsistency in security oblivious recursive name servers. This concern only applies to implementations of DNSSEC that employ precomputed signatures. There is an exception to this rule for online signing implementations of DNSSEC (e.g., minimally covering NSEC and Compact Denial of Existence), where dynamically generated NSEC records can be produced for owner names that don't exist or are ENTs.
NSECレコード（および関連するRRSIG RRSet）は、特定の所有者名で唯一のRRSetであってはなりません。つまり、署名プロセスは、ゾーンが署名される前のrrsetの所有者名ではなかった所有者名ノードのNSECまたはRRSIG RRSを作成してはなりません。これの主な理由は、同じゾーンの署名されたバージョンと署名されていないバージョンとの間の名前空間の一貫性と、セキュリティ忘却の再帰名サーバーの応答の矛盾を減らすことを望んでいることです。この懸念は、事前計算された署名を使用するDNSSECの実装にのみ適用されます。この規則には、DNSSECのオンライン署名実装（たとえば、NSECやコンパクトな存在の拒否を最小限に抑える）には例外があります。ここでは、存在しない、または存在しない所有者名に対して動的に生成されたNSECレコードを作成できます。
Online signing of DNS records requires authoritative servers for the DNS zone to have access to the private signing keys. Exposing signing keys on Internet-reachable servers makes them more vulnerable to attack.
DNSレコードのオンライン署名には、DNSゾーンの権威あるサーバーがプライベート署名キーにアクセスする必要があります。インターネットに到達可能なサーバーで署名キーを公開すると、攻撃に対してより脆弱になります。
Additionally, generating signatures on demand is more computationally intensive than returning precomputed signatures. Although the Compact Answers scheme reduces the number of online signing operations compared to previous techniques like White Lies, it still may make authoritative servers more vulnerable to computational denial-of-service attacks than precomputed signatures. The use of signature algorithms (like those based on elliptic curves) that have a comparatively low cost for signing is recommended.
さらに、オンデマンドで署名を生成することは、事前計算された署名を返すよりも計算集中です。Compact Answersスキームは、White Liesのような以前の手法と比較してオンライン署名操作の数を減らしますが、事前に計算された署名よりも信頼できるサーバーが計算拒否攻撃に対してより脆弱になる可能性があります。署名の比較的低コストの署名アルゴリズム（楕円曲線に基づくものと同様）の使用が推奨されます。
Some security tools rely on detection of nonexistent domain names by examining the response code field of DNS response messages. A NOERROR (rather than NXDOMAIN) code in that field will impact such tools. Implementation of the optional response code restoration scheme will help recover NXDOMAIN visibility for these tools. Note that the DNS header is not cryptographically protected, so the response code field cannot be authenticated. Thus, inferring the status of a response from signed data in the body of the DNS message is actually more secure. These tools could be enhanced to recognize the (signed) NXNAME signal.
一部のセキュリティツールは、DNS応答メッセージの応答コードフィールドを調べることにより、存在しないドメイン名の検出に依存しています。そのフィールドのノーエラー（nxdomainではなく）コードは、そのようなツールに影響を与えます。オプションの応答コード復元スキームの実装は、これらのツールのnxDomainの可視性を回復するのに役立ちます。DNSヘッダーは暗号化されていないため、応答コードフィールドを認証できないことに注意してください。したがって、DNSメッセージの本文で署名されたデータからの応答のステータスを推測することは、実際にはより安全です。これらのツールは、（署名された）NXNAME信号を認識するために強化できます。
Because this method does not allow for aggressive negative caching among resolvers, it allows for certain types of denial-of-service attacks to be more effective. This includes so-called Pseudorandom Subdomain Attacks [PRSD-ATTACK], where random names are queried, either directly via botnets or across a wide range of public resolver services, in order to intentionally generate nonexistent responses from the authoritative servers for a domain. If the resolver cannot synthesize NXDOMAIN responses from NSEC records, it must pass all queries on to the domain's authority servers, making resource exhaustion more likely at those latter servers if they do not have the capacity to absorb those additional queries.
この方法では、リゾルバー間の積極的なネガティブキャッシングは許可されていないため、特定の種類のサービス拒否攻撃をより効果的にすることができます。これには、ドメインの権威あるサーバーから意図的に存在しない応答を生成するために、ボットネットまたは幅広いパブリックリゾルバーサービスを介して直接ランダム名が照会されている、いわゆる擬似ランダムサブドメイン攻撃[PRSD-attack]が含まれます。ResolverがNSECレコードからNXDomain応答を合成できない場合、すべてのクエリをドメインの権限サーバーに渡す必要があり、それらの追加クエリを吸収する能力がない場合、リソースの疲労がこれらの後者のサーバーでより可能性が高くなります。
If the motivating aspects of this specification (minimizing response size and computational costs) are not a concern, DNSSEC deployments can opt for a different method (e.g., conventional online signing or precomputed signatures) and avoid imposing the challenges of NXDOMAIN visibility.
この仕様の動機付けの側面（応答サイズと計算コストの最小化）が懸念事項ではない場合、DNSSECの展開は別の方法（たとえば、従来のオンライン署名または事前計算された署名）を選択し、NXDomainの可視性の課題を課すことを避けます。
IANA has allocated the following in the "Resource Record (RR) TYPEs" registry in the "Domain Name System (DNS) Parameters" registry group, from the range for Meta-TYPEs. A lower number in this range lowers the size of the Type Bit Maps field, which reduces the overall size of the DNS response message.
IANAは、メタタイプの範囲から「ドメイン名システム（DNS）パラメーター」レジストリグループの「リソースレコード（RR）タイプ」レジストリで以下を割り当てました。この範囲の数が少ないと、タイプビットマップフィールドのサイズが低くなり、DNS応答メッセージの全体的なサイズが削減されます。
+========+=======+=============================+===========+
| Type | Value | Meaning | Reference |
+========+=======+=============================+===========+
| NXNAME | 128 | NXDOMAIN indicator for | RFC 9824 |
| | | Compact Denial of Existence | |
+--------+-------+-----------------------------+-----------+
Table 1
IANA has also allocated the following flag in the "EDNS Header Flags (16 bits)" registry in the "Domain Name System (DNS) Parameters" registry group. This flag is described in Section 5.1.
IANAは、「Domain Name System（DNS）パラメーター」レジストリグループの「EDNSヘッダーフラグ（16ビット）」レジストリに次のフラグを割り当てました。このフラグについては、セクション5.1で説明しています。
+=======+======+====================+===========+
| Bit | Flag | Description | Reference |
+=======+======+====================+===========+
| Bit 1 | CO | Compact Answers OK | RFC 9824 |
+-------+------+--------------------+-----------+
Table 2
Last, IANA has allocated the following code point in the "Extended DNS Error Codes" registry in the "Domain Name System (DNS) Parameters" registry group. This code point is described in Section 3.5.
最後に、IANAは、「ドメイン名システム（DNS）パラメーター」レジストリグループの「拡張DNSエラーコード」レジストリに次のコードポイントを割り当てました。このコードポイントは、セクション3.5で説明されています。
+===========+====================+===========+
| INFO-CODE | Purpose | Reference |
+===========+====================+===========+
| 30 | Invalid Query Type | RFC 9824 |
+-----------+--------------------+-----------+
Table 3
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
RFC 3225, DOI 10.17487/RFC3225, December 2001,
<https://www.rfc-editor.org/info/rfc3225>.
[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>.
[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>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[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>.
[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>.
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
Lawrence, "Extended DNS Errors", RFC 8914,
DOI 10.17487/RFC8914, October 2020,
<https://www.rfc-editor.org/info/rfc8914>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>.
[COMPACT] Valsorda, F. and O. Gudmundsson, "Compact DNSSEC Denial of
Existence or Black Lies", Work in Progress, Internet-
Draft, draft-valsorda-dnsop-black-lies-00, 21 March 2016,
<https://datatracker.ietf.org/doc/html/draft-valsorda-
dnsop-black-lies-00>.
[ENT-SENTINEL]
Huque, S., "Empty Non-Terminal Sentinel for Black Lies",
Work in Progress, Internet-Draft, draft-huque-dnsop-
blacklies-ent-01, 27 July 2021,
<https://datatracker.ietf.org/doc/html/draft-huque-dnsop-
blacklies-ent-01>.
[NXDOMAIN-TYPE]
Gudmundsson, O. and F. Valsorda, "Signaling NSEC record
owner name nonexistence", Work in Progress, Internet-
Draft, draft-ogud-fake-nxdomain-type-00, 7 May 2015,
<https://datatracker.ietf.org/doc/html/draft-ogud-fake-
nxdomain-type-00>.
[PRSD-ATTACK]
Nishida, K., "Water Torture: A Slow Drip DNS DDoS Attack
on QTNet", <https://conference.apnic.net/data/39/
dnswatertortureonqtnet_1425130417_1425507043.pptx>.
[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>.
[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
November 2016, <https://www.rfc-editor.org/info/rfc8020>.
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
July 2017, <https://www.rfc-editor.org/info/rfc8198>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
In the past, some implementations of Compact Denial of Existence have used other means to differentiate NXDOMAIN from ENTs.
過去には、コンパクトな存在の否定のいくつかの実装は、他の手段を使用してNxDomainをENTと区別してきました。
One method employed by both Cloudflare and Amazon Route53 for a period of time was the following: For responses to ENTs, they synthesized the NSEC Type Bit Maps field to include all record types supported except for the queried type. This method has the undesirable effect of no longer being able to reliably determine the existence of ENTs and of making the Type Bit Maps field larger than it needs to be. It also has the potential to confuse validators and others tools that infer type existence from the NSEC record.
CloudFlareとAmazon Route53の両方で一定期間採用されている1つの方法は次のとおりでした。ENTへの応答については、NSECタイプビットマップフィールドを合成して、クエリ型を除いてサポートされているすべてのレコードタイプを含めました。この方法は、ENTの存在を確実に決定できなく、タイプビットマップを必要以上に大きくすることができなくなるという望ましくない効果があります。また、NSECレコードからタイプの存在を推測するバリデーターやその他のツールを混同する可能性があります。
Another way to distinguish NXDOMAIN from ENT is to define the synthetic RR type for ENTs instead, as specified in [ENT-SENTINEL]. This method was successfully deployed in the field by NS1 for a period of time. This typically imposes less work on the server since NXDOMAIN responses are a lot more common than ENTs. At the time it was deployed, it also allowed a common bitmap pattern ("NSEC RRSIG") to identify NXDOMAIN across this and other implementations that returned a broad bitmap pattern for ENTs. However, the advantage of the NXNAME RR type is that it explicitly identifies NXDOMAIN responses and allows them to be distinguished conclusively from potential ENT responses in other online signing NSEC implementations.
nxDomainとentを区別する別の方法は、[ent-sentinel]で指定されているように、代わりにエントの合成RRタイプを定義することです。この方法は、一定期間NS1によってフィールドに正常に展開されました。これは通常、NXDomainの応答がENTよりもはるかに一般的であるため、サーバー上の作業を課すことが少なくなります。展開された時点で、一般的なビットマップパターン（「nsec rrsig」）が、これや他の実装でnxdomainを識別することができました。ただし、NXNAME RRタイプの利点は、NXDomain応答を明示的に識別し、他のオンライン署名NSEC実装における潜在的なENT応答と最終的に区別できることです。
At the time of publication, the basic Compact Denial of Existence method using NSEC is implemented by Cloudflare, NS1, Amazon Route53, and Knot DNS's optional online signing module. From early 2021 until November 2023, NS1 had deployed the ENT distinguisher [ENT-SENTINEL] using the private RR type code 65281. A version of the NXNAME distinguisher using the private RR type code 65238 was deployed by both Cloudflare (from July 2023) and NS1 (from November 2023) until roughly September 2024. Since September 2024, both Cloudflare and NS1 have deployed NXNAME using the officially allocated code point of 128. Oracle Cloud Initiative implemented Compact Denial of Existence using NSEC3 in October 2024.
公開時点では、NSECを使用した基本的なコンパクトな存在拒否法は、CloudFlare、NS1、Amazon Route53、およびKnot DNSのオプションのオンライン署名モジュールによって実装されています。2021年初頭から2023年11月まで、NS1はプライベートRRタイプコード65281を使用してEnt distumenter [ent-Sentinel]を展開していました。NS1は、128の公式に割り当てられたコードポイントを使用してNXNAMEを展開しました。OracleCloudイニシアチブは、2024年10月にNSEC3を使用してコンパクトな存在拒否を実装しました。
The Compact Answers technique was originally proposed in [COMPACT] by Filippo Valsorda and Olafur Gudmundsson and implemented by Cloudflare. The ENT distinguisher RR type was originally proposed in [ENT-SENTINEL] by Shumon Huque and deployed by NS1. The NXNAME type is based on the FDOM type proposed in [NXDOMAIN-TYPE] by Gudmundsson and Valsorda.
Compact Answersテクニックは、もともとFilippo ValsordaとOlafur Gudmundssonによって[コンパクト]で提案され、CloudFlareによって実装されました。ENT distinger RRタイプは、もともとShumon Huqueによって[Ent-Sentinel]で提案され、NS1によって展開されました。NXNAMEタイプは、GudmundssonとValsordaによって[NxDomain-Type]で提案されているFDOMタイプに基づいています。
Especially detailed discussions on many technical aspects of this document were conducted with Paul Vixie, Jan Včelák, Viktor Dukhovni, Ed Lewis, and John Levine. The authors would also like to thank the many other members of the IETF DNS Operations Working Group for helpful comments and discussions.
この文書の多くの技術的側面に関する特に詳細な議論は、Paul Vixie、JanVčelák、Viktor Dukhovni、Ed Lewis、およびJohn Levineで実施されました。著者はまた、IETF DNS Operations Working Groupの他の多くのメンバーに、有益なコメントとディスカッションについて感謝したいと思います。
Shumon Huque
Salesforce
415 Mission Street, 3rd Floor
San Francisco, CA 94105
United States of America
Email: shuque@gmail.com
Christian Elmerot
Cloudflare
101 Townsend St.
San Francisco, CA 94107
United States of America
Email: elmerot@cloudflare.com
Olafur Gudmundsson
Email: ogud@ogud.com