Hi Shumon, Christian, and Olafur, Shumon - Thank you for the quick reply and for addressing all of our questions. We have updated the document accordingly and noted your approval on the AUTH48 status page for this document (https://www.rfc-editor.org/auth48/rfc9824).
Christian and Olafur - Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. Contact us with any further updates or with your approval of the document in its current form. We will await approvals from each author prior to moving forward in the publication process. — FILES (please refresh) — Updated XML file: https://www.rfc-editor.org/authors/rfc9824.xml Updated output files: https://www.rfc-editor.org/authors/rfc9824.txt https://www.rfc-editor.org/authors/rfc9824.pdf https://www.rfc-editor.org/authors/rfc9824.html Diff files showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9824-auth48diff.html https://www.rfc-editor.org/authors/rfc9824-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9824-diff.html https://www.rfc-editor.org/authors/rfc9824-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9824-alt-diff.html (diff showing changes where text is moved or deleted) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9824 Thank you, RFC Editor/rv > On Jul 31, 2025, at 7:53 PM, Shumon Huque <shu...@gmail.com> wrote: > > Dear RFC Editor, > > I approve this RFC for publication. > > I have reviewed the side by side diff at > https://www.rfc-editor.org/authors/rfc9824-rfcdiff.html and your proposed > edits look good to me. > > My responses to your questions are provided inline below. > (I trust that my co-authors will chime in on any of these as they see fit). > > On Thu, Jul 31, 2025 at 8:10 PM <rfc-edi...@rfc-editor.org> wrote: > 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 > --> > > Reviewed and confirmed. > 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. > --> > > "Answers" and "responses" are synonymous - I think most readers will > understand. > > But to keep things consistent, let's go with your last suggested edit "Such > responses". > > 3) <!-- [rfced] We do not see "White Lies" mentioned in RFC 4470 (though NSEC > and > online signing are mentioned). Are any updates needed? > > "White Lies" (or NSEC White Lies) is colloquially what everyone calls the > technique referred to in RFC4470 - though you are correct that it is not > mentioned in RFC4470. > > 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. > --> > > This last suggestion sounds good to me. > 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)? > > This is correct, and I don't think any changes are needed. > 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. > > I think this is fine as is. > > "Compact Answers" is a shorter way to refer to the technique. The complete > name, "Compact Denial of Existence" has many more syllables, and is a bit of > a mouthful. Also we refer to the EDNS header flag as "Compact Answers OK". > > 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? > > Those phrases are equivalent in this context. > But yes, we can use "resource record sets" for consistency. > > 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. > --> > > I used the phrase "next name" field as a generic name to contrast the > differences in how the actual fields in NSEC (Next Domain Name") and NSEC3 > (Next Hashed Owner Name) were treated. > > Let's change this to "Next Hashed Owner Name" field (the protocol element > used in NSEC3 that we are referring to in this section). > (Specifically "no special form of the Next Hashed Owner Name field for ...") > > 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. > --> > > The last suggestion sounds good to me. > > > 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). > --> > > Your suggested edit sounds good. > > 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. > --> > > Yes, your suggested edit looks good. > 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]. > --> > > Ok. > 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. > --> > > We can update them to "Type Bit Maps field". > > 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. > --> > > The last paragraph "Note: as a practical matter" should not be in the block > quote. > It is an additional explanatory comment for this document, and not part of > the updates to the other RFCs. > > > 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. > --> > > Yes, that looks good. > 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. > --> > > This is not actually the source code of a programming language, but the > presentation format of DNS resource records. > > Though, I suppose they could be treated as source code in an RFC document. > So, I think I'm okay with that, and we can leave the type attribute unset. > > 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 > > Ok. > > > 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. > > Ok. > > > c) We see the following forms in the document. Are any updates needed for > consistency? > > Type Bit Maps field > NSEC Type Bit Maps field > > This is fine. > The latter refers to the Type Bitmaps field as seen in the NSEC record (as > opposed to the NSEC3 record). > > d) If no objections, we will remove the hyphen from "non-existent" per the > Merriam Webster dictionary > (https://www.merriam-webster.com/dictionary/nonexistent). > --> > > Ok. > 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) > > Ok. > > > 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 > > Ok. > 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. > --> > > Yes, that sounds fine. > > > 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 > > No need. Black Lies (the one with the pejorative connotation) was the > original name of this technique, now renamed, and is only mentioned in the > Acks section as a historical reference. > > 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. > --> > > I was not aware that "traditional" was a biased term. But I'm not sure I have > a better suggestion. > The NIST document suggests "agreed upon", which does not quite fit the > meaning of the text. > Perhaps "normal"? Or leave it alone if that is permitted. > > > Thank you. > > RFC Editor/rv > > Thank you! > > Shumon Huque > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
