Dear RFC Editor, I have reviewed the latest diff and approve this RFC for publication with potential updates with regards to using inclusive language.
Best regards, Christian Elmerot On Fri, Aug 1, 2025 at 8:08 PM Rebecca VanRheenen < rvanrhee...@staff.rfc-editor.org> wrote: > 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
