Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
1) <!-- [rfced] This document updates RFCs 4034 and 4035. Please review the errata reported for these RFCs. We do not believe that any are relevant to the content of this document, but please confirm. https://www.rfc-editor.org/errata_search.php?rfc=4034 https://www.rfc-editor.org/errata_search.php?rfc=4035 --> 2) <!-- [rfced] Abstract: Will readers understand "Such answers" in the second sentence below? Answers are not mentioned in the first sentence (but "response" is). Original: This document describes a technique to generate a signed DNS response on demand for a non-existent name by claiming that the name exists but doesn't have any data for the queried record type. Such answers 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. Perhaps ("This technique"): This document describes a technique to generate a signed DNS response on demand for a non-existent name by claiming that the name exists but doesn't have any data for the queried record type. The technique requires only one minimally covering NSEC or NSEC3 record, allows online signing servers to minimize signing operations and response sizes, and prevents zone content disclosure. Or ("Such responses"): This document describes a technique to generate a signed DNS response on demand for a non-existent 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. --> 3) <!-- [rfced] We do not see "White Lies" mentioned in RFC 4470 (though NSEC and online signing are mentioned). Are any updates needed? Original: In the online signing model, described in NSEC and NSEC3 "White Lies" [RFC4470] [RFC7129], they are used to dynamically compute an epsilon function around the queried name. Perhaps: In the online signing model, described in [RFC4470] and [RFC7129], they are used to dynamically compute an epsilon function around the queried name. Or: In the online signing model, described for NSEC in [RFC4470] and for NSEC3 White Lies in [RFC7129], they are used to dynamically compute an epsilon function around the queried name. --> 4) <!-- [rfced] Please review "at the name" and "at the same name" in these sentences. Are these correct as it, or should these be updated to "for the name" and "for the same name" (or something else)? Original: A "Type Bit Maps" field in the data of the NSEC or NSEC3 record asserts which resource record types are present at the name. ... Tools that need to accurately identify non-existent 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. ... The Type Bit Maps field lists the available Resource Record types at the name. ... can cause such functions to issue another query at the same name for an A record. --> 5) <!-- [rfced] This text indicates that the technique described in this document has two names ("Compact Denial of Existence" or "Compact Answers"), and we see both used in the document. Would it be helpful to use one name throughout the document? It seems that "Compact Denial of Existence" is more common (and included in the document title). Let us know your thoughts. Original: This document describes an alternative technique, "Compact Denial of Existence" or "Compact Answers", to generate a signed DNS response on demand for a non-existent name by claiming that the name exists but has no resource records associated with the queried type, i.e., it returns a NODATA response rather than an NXDOMAIN response. --> 6) <!-- [rfced] The first sentence below uses "has no resource records" while the other two use "has no resource record sets" (note "sets"). Should these be consistent? Original: This document describes an alternative technique, "Compact Denial of Existence" or "Compact Answers", to generate a signed DNS response on demand for a non-existent name by claiming that the name exists but has no resource records associated with the queried type, i.e., it returns a NODATA response rather than an NXDOMAIN response. ... 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. ... An Empty Non-Terminal is a special subset of this category, where the name has no resource record sets of any type (but has descendant names that do). --> 7) <!-- [rfced] In the sentence below, is "next name field" correct? We see "Next Hashed Owner Name field" and "Next Domain Name field" elsewhere in the document. Original: Unlike Compact Denial of Existence with NSEC, no special form of the next name field for unsigned referrals is needed. --> 8) <!-- [rfced] We do not see "DNSSEC_OK" in past RFCs. The IANA registry at <https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-13> uses "DNSSEC answer OK". May we update this sentence in one of the following ways? Original: This is generally possible for non-DNSSEC enabled queries, namely those which do not set the DNSSEC_OK EDNS flag (DO bit). Perhaps: This is generally possible for non-DNSSEC enabled queries, namely those that do not set the EDNS header flag "DNSSEC answer OK" (DO bit). Or: 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. --> 9) <!-- [rfced] Will "signed NXNAME enhanced NODATA response" be clear to readers? Original: When this flag is sent in a query by a resolver, it indicates that the resolver will accept a signed NXNAME enhanced NODATA response for a non-existent name together with the response code field set to NXDOMAIN (3). Perhaps: 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 non-existent name together with the response code field set to NXDOMAIN (3). --> 10) <!-- [rfced] Please review "a Compact Denial authoritative server". Is the intended meaning "an authoritative server implementing Compact Denial of Existence"? Original: In responses to such queries, a Compact Denial authoritative server implementing this signaling scheme, will set the Compact Answers OK EDNS header flag, and for non-existent names will additionally set the response code field to NXDOMAIN. Perhaps: 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 non-existent names, will additionally set the response code field to NXDOMAIN. --> 11) <!-- [rfced] We updated the following sentences to avoid using RFC number or citation as an adjective. Specifically, we updated the following phrases: "Happy Eyeballs [RFC8305] style", "RFC 8198 style", and "RFC 8020 style". Please review to ensure that the updates accurately convey the intended meaning. Original: Note that this is less of a concern with Happy Eyeballs [RFC8305] style of connection functions that typically issue back to back DNS queries without waiting for individual responses. ... In general, no online signing scheme that employs minimally covering NSEC or NSEC3 records (including this one) permits RFC 8198 style NXDOMAIN or wildcard response synthesis. Additionally, this protocol also precludes RFC 8020 style NXDOMAIN synthesis for DNSSEC enabled responses. Updated: 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. ... 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]. --> 12) <!-- [rfced] Should the instances of "Type Bit Maps" in the following sentences be updated to "Type Bit Maps field"? Or are these correct as they are? Original: Note: as a practical matter, no known resolver insists that pseudo- types must be clear in the NSEC Type Bit Maps, so this restriction (prior to its revision) has posed no problem for the deployment of this mechanism. ... ...for responses to Empty Non- Terminals, they synthesized the NSEC Type Bit Maps to include all record types supported except for the queried type. --> 13) <!-- [rfced] We use the <blockquote> element for OLD/NEW text. We have included both the first paragraph and the note below within the <blockquote> element. Please confirm that this is correct. If the note should not be part of the updated text, we will adjust the <blockquote> element accordingly. Original: * 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 TBD), where the NXNAME pseudo-type is allowed to appear in responses to non-existent names. Note: as a practical matter, no known resolver insists that pseudo- types must be clear in the NSEC Type Bit Maps, so this restriction (prior to its revision) has posed no problem for the deployment of this mechanism. --> 14) <!-- [rfced] Table 1 and 3 are identical, as are Tables 2 and 5. We suggest removing Tables 1 and 2 (and leaving the tables in the IANA section) and updating the text in Sections 2 and 3.5 as follows. Would this be acceptable? Current (Section 2) This specification defines the use of a synthetic resource record type to signal the presence of a non-existent name. The mnemonic for this RR type is NXNAME, chosen to clearly distinguish it from the response code mnemonic NXDOMAIN. Perhaps: This specification defines the use of NXNAME (128), a synthetic resource record type to signal the presence of a non-existent name. See Section 9. The mnemonic for this RR type is NXNAME, chosen to clearly distinguish it from the response code mnemonic NXDOMAIN. Current (Section 3.5): Optionally, a DNS server MAY also include the following Extended DNS Error (EDE) code [RFC8914] in the response: Perhaps: 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. --> 15) <!-- [rfced] We updated <artwork> to <sourcecode> for the following: Original: a.example.com. 3600 IN NSEC \000.a.example.com. RRSIG NSEC NXNAME sub.example.com. 3600 IN NSEC sub\000.example.com. NS RRSIG NSEC H64KFA4P1ACER2EBPS9QSDK6DNP8B3JQ.example.com. IN NSEC3 1 0 0 - ( H64KFA4P1ACER2EBPS9QSDK6DNP8B3JR NXNAME ) Please review whether the "type" attribute should be set for sourcecode elements in the XML file. If the current list of preferred values for "type" (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) does not contain an applicable type, then feel free to suggest a new one. Also, it is acceptable to leave the "type" attribute not set. --> 16) <!-- [rfced] Terminology a) FYI - We updated the following forms to "Meta-TYPEs" per usage in RFCs 5155 and 6895 (normatively referenced in this document): meta type Meta-Type meta-type b) We see the following forms in the document. We updated to the latter. Let us know any concerns. Hashed Next Owner Name vs. Next Hashed Owner Name Note: Per RFC 5155. Owner Name vs. owner name Note: Per RFCs 4034 and 4035. c) We see the following forms in the document. Are any updates needed for consistency? Type Bit Maps field NSEC Type Bit Maps field d) If no objections, we will remove the hyphen from "non-existent" per the Merriam Webster dictionary (https://www.merriam-webster.com/dictionary/nonexistent). --> 17) <!-- [rfced] Abbreviations a) FYI - We have added expansion(s) for the following abbreviation(s) per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Delegation Signer (DS) b) The following are used throughout the document. If no objections, we will update to use the abbreviation after the expansion upon first use. Empty Non-Terminal empty non-terminal ENT c) We see instances of both "queried name" and "QNAME" in the document, with one instance of QNAME as the abbreviation of "queried name" (see below). Would it be helpful to update all instances of "queried name" to "QNAME"? We note that QNAME is defined in RFC 9499, but "queried name" is not. Original: When the authoritative server receives a query for a non-existent 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 queried name (QNAME) placed in the Authority section. --> 18) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether the following should be updated: term A, term B, term C, etc. White Lies Black Lies In addition, please consider whether the two instances of "traditional" should be updated for clarity. While the NIST website <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> indicates that this term is potentially biased, it is also ambiguous. "Traditional" is a subjective term, as it is not the same for everyone. Original: However, an existing implementation of traditional NSEC3 online signing migrating to Compact Denial of Existence may find it simpler to do so with NSEC3 than implementing NSEC from scratch. ... 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., traditional online signing or pre-computed signatures), and avoid imposing the challenges of NXDOMAIN visibility. --> Thank you. RFC Editor/rv On Jul 31, 2025, at 5:02 PM, rfc-edi...@rfc-editor.org wrote: *****IMPORTANT***** Updated 2025/07/31 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * rfc-edi...@rfc-editor.org (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * auth48archive@rfc-editor.org, which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, auth48archive@rfc-editor.org will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9824.xml https://www.rfc-editor.org/authors/rfc9824.html https://www.rfc-editor.org/authors/rfc9824.pdf https://www.rfc-editor.org/authors/rfc9824.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9824-diff.html https://www.rfc-editor.org/authors/rfc9824-rfcdiff.html (side by side) Alt-diff of the text (allows you to more easily view changes where text has been deleted or moved): https://www.rfc-editor.org/authors/rfc9824-alt-diff.html Diff of the XML: https://www.rfc-editor.org/authors/rfc9824-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9824 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9824 (draft-ietf-dnsop-compact-denial-of-existence-07) Title : Compact Denial of Existence in DNSSEC Author(s) : S. Huque, C. Elmerot, O. Gudmundsson WG Chair(s) : Benno Overeinder, Ond?ej Surý Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
