Hi Christian, Thanks for the reply! We noted your approval on the AUTH48 status page for this document (https://www.rfc-editor.org/auth48/rfc9824). Thank you also for reviewing Med’s suggestions for the question about inclusive language; we updated the document accordingly.
We will now wait for Ólafur’s review and approval. He let us know that he will be traveling until mid August and will review once he returns. — 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 last round of changes (i.e., inclusive language): https://www.rfc-editor.org/authors/rfc9824-lastdiff.html https://www.rfc-editor.org/authors/rfc9824-lastrfcdiff.html (side by side) 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 Aug 13, 2025, at 2:43 AM, Christian Elmerot <elme...@cloudflare.com> wrote: > > Hi, > > On Fri, Aug 1, 2025 at 8:23 PM <mohamed.boucad...@orange.com> wrote: > Hi all, > > For the inclusive language comment, I suggest that we make these changes: > > * Replace "traditional" with "conventional" > > I like the suggestion and this would be the changes to wording in the two > sentences where it occurs: > OLD: However, an existing implementation of traditional NSEC3 online signing > migrating to Compact Denial of Existence may find it simpler to do so with > NSEC3 rather than implementing NSEC from scratch. > NEW: 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. > > OLD: 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 precomputed > signatures) and avoid imposing the challenges of NXDOMAIN visibility. > NEW: 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. > > Further, > OLD: The Compact Answers technique (then called "Black Lies") was originally > proposed in [BLACK-LIES] > NEW: The Compact Answers technique was originally proposed in [COMPACT] > > Sounds fine to me. > OLD: for NSEC3 White Lies in [RFC7129], > NEW: for NSEC3 in Appendix B of [RFC7129] > > An improvement and more direct reference. Fully agree with this change > > OLD: > [BLACK-LIES] 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>. > > NEW: > [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>. > > This change follows naturally because of the change [BLACK-LIES] to [COMPACT] > from earlier > > Best regards, > Christian > > > > -----Message d'origine----- > > De : Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org> > > Envoyé : vendredi 1 août 2025 20:08 > > À : Shumon Huque <shu...@gmail.com>; elme...@cloudflare.com; > > o...@ogud.com > > Cc : RFC Editor <rfc-edi...@rfc-editor.org>; dnsop-...@ietf.org; > > dnsop-cha...@ietf.org; suzworldw...@gmail.com; war...@kumari.net; > > auth48archive@rfc-editor.org > > Objet : Re: AUTH48: RFC-to-be 9824 <draft-ietf-dnsop-compact-denial- > > of-existence-07> for your review > > > > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw > > ww.rfc- > > editor.org%2Fauth48%2Frfc9824&data=05%7C02%7Cmohamed.boucadair%40ora > > nge.com%7Cafbd80b5eecb49c0fed008ddd12663cd%7C90c7a20af34b40bfbc48b92 > > 53b6f5d20%7C0%7C0%7C638896686200859382%7CUnknown%7CTWFpbGZsb3d8eyJFb > > XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb > > CIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=z%2Fr48oMUJ89XTRI1noHwsOz > > fweapMCsoq6JCSLOZe0Q%3D&reserved=0). > > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > w.rfc- > > editor.org%2Fauthors%2Frfc9824.xml&data=05%7C02%7Cmohamed.boucadair% > > 40orange.com%7Cafbd80b5eecb49c0fed008ddd12663cd%7C90c7a20af34b40bfbc > > 48b9253b6f5d20%7C0%7C0%7C638896686200884603%7CUnknown%7CTWFpbGZsb3d8 > > eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > > TWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=5K8nIJaHba1MgmWMCAOB > > 52B9HGba%2BrpRgBYQweLWHKY%3D&reserved=0 > > > > Updated output files: > > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > w.rfc- > > editor.org%2Fauthors%2Frfc9824.txt&data=05%7C02%7Cmohamed.boucadair% > > 40orange.com%7Cafbd80b5eecb49c0fed008ddd12663cd%7C90c7a20af34b40bfbc > > 48b9253b6f5d20%7C0%7C0%7C638896686200899563%7CUnknown%7CTWFpbGZsb3d8 > > eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > > TWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=qezi7ilBq3DacYirHpor > > iyIg%2Bn3dz2UDghnW%2B4LMwRI%3D&reserved=0 > > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > w.rfc- > > editor.org%2Fauthors%2Frfc9824.pdf&data=05%7C02%7Cmohamed.boucadair% > > 40orange.com%7Cafbd80b5eecb49c0fed008ddd12663cd%7C90c7a20af34b40bfbc > > 48b9253b6f5d20%7C0%7C0%7C638896686200913211%7CUnknown%7CTWFpbGZsb3d8 > > eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > > TWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=QnNqb39hyCyMM0KZoxbN > > rAk39Qwmw5m5fMxpXImyDKA%3D&reserved=0 > > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > w.rfc- > > editor.org%2Fauthors%2Frfc9824.html&data=05%7C02%7Cmohamed.boucadair > > %40orange.com%7Cafbd80b5eecb49c0fed008ddd12663cd%7C90c7a20af34b40bfb > > c48b9253b6f5d20%7C0%7C0%7C638896686200926368%7CUnknown%7CTWFpbGZsb3d > > 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > > iTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=6HNFe5Ub3a0KOM7PYj7 > > 9ZC0HvLAD%2FB0i7DfibsBSyZw%3D&reserved=0 > > > > Diff files showing all changes made during AUTH48: > > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > w.rfc-editor.org%2Fauthors%2Frfc9824- > > auth48diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cafbd > > 80b5eecb49c0fed008ddd12663cd%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0% > > 7C0%7C638896686200938696%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% > > 3D%3D%7C80000%7C%7C%7C&sdata=BVTT3NeyF8DcS6PjfUgDWTXPkBNS6uW%2BvdQWG > > Y3DOiE%3D&reserved=0 > > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > w.rfc-editor.org%2Fauthors%2Frfc9824- > > auth48rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca > > fbd80b5eecb49c0fed008ddd12663cd%7C90c7a20af34b40bfbc48b9253b6f5d20%7 > > C0%7C0%7C638896686200951325%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > > OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > > fQ%3D%3D%7C80000%7C%7C%7C&sdata=CyDgaGQKJWjc0UaP39f%2FqGrnSJ5eHfJba6 > > zE0yjD8TE%3D&reserved=0 (side by side) > > > > Diff files showing all changes: > > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > w.rfc-editor.org%2Fauthors%2Frfc9824- > > diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cafbd80b5ee > > cb49c0fed008ddd12663cd%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C > > 638896686200964651%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI > > lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% > > 7C80000%7C%7C%7C&sdata=CkD5vtWPp84t3Y3WYH1H%2Ffh9r9Ck385WO3qQXoPngg8 > > %3D&reserved=0 > > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > w.rfc-editor.org%2Fauthors%2Frfc9824- > > rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cafbd80b > > 5eecb49c0fed008ddd12663cd%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0 > > %7C638896686200976956%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > > 3D%7C80000%7C%7C%7C&sdata=sKd98oHFvhC0VFY0vKZVRSmQkZ92tcBcdHf0%2FaZg > > %2BGQ%3D&reserved=0 (side by side) > > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > w.rfc-editor.org%2Fauthors%2Frfc9824-alt- > > diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cafbd80b5ee > > cb49c0fed008ddd12663cd%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C > > 638896686200990089%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI > > lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% > > 7C80000%7C%7C%7C&sdata=DCiD1%2BKximzyqTkGQFP%2F4N24lprHKSrO5t54VIEdh > > eM%3D&reserved=0 (diff showing changes where text is moved or > > deleted) > > > > For the AUTH48 status of this document, please see: > > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > w.rfc- > > editor.org%2Fauth48%2Frfc9824&data=05%7C02%7Cmohamed.boucadair%40ora > > nge.com%7Cafbd80b5eecb49c0fed008ddd12663cd%7C90c7a20af34b40bfbc48b92 > > 53b6f5d20%7C0%7C0%7C638896686201003038%7CUnknown%7CTWFpbGZsb3d8eyJFb > > XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb > > CIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=BPCmSxQ5ZxsUnKD53sv4%2BRx > > dZ4Qf3pfU7quQX6jTJYQ%3D&reserved=0 > > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > w.rfc-editor.org%2Fauthors%2Frfc9824- > > rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cafbd80b > > 5eecb49c0fed008ddd12663cd%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0 > > %7C638896686201017916%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > > 3D%7C80000%7C%7C%7C&sdata=1gyasNIV9bDKHUsoFwJbJa7K1OK3%2FUZczGURK7mv > > Fas%3D&reserved=0 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > w. > > > rfc- > > editor.org%2Ferrata_search.php%3Frfc%3D4034&data=05%7C02%7Cmohamed > > > > > .boucadair%40orange.com%7Cafbd80b5eecb49c0fed008ddd12663cd%7C90c7a20 > > af > > > > > 34b40bfbc48b9253b6f5d20%7C0%7C0%7C638896686201031149%7CUnknown%7CTWF > > pb > > > > > GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI > > kF > > > > > OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=7j%2BCFz7AQ5RCA > > xt > > > JvkyFAJOP0sboZoKpcU53Obvd%2B%2FM%3D&reserved=0 > > > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > w. > > > rfc- > > editor.org%2Ferrata_search.php%3Frfc%3D4035&data=05%7C02%7Cmohamed > > > > > .boucadair%40orange.com%7Cafbd80b5eecb49c0fed008ddd12663cd%7C90c7a20 > > af > > > > > 34b40bfbc48b9253b6f5d20%7C0%7C0%7C638896686201044154%7CUnknown%7CTWF > > pb > > > > > GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI > > kF > > > > > OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=b3KeySk5FkiQikv > > rN > > > ou5ZEYRXO9ONhUeEbyfCC5tsAQ%3D&reserved=0 > > > --> > > > > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw > > ww > > > .iana.org%2Fassignments%2Fdns-parameters%2Fdns- > > parameters.xhtml%23dns- > > > parameters- > > 13&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cafbd80b5 > > > > > eecb49c0fed008ddd12663cd%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% > > 7C > > > > > 638896686201057006%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI > > lY > > > > > iOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C > > 80 > > > > > 000%7C%7C%7C&sdata=u1re6H1Q3%2FP6g9Hyjhtog9Fyc9nfBLbFK1Zx4z4L4Cw%3D& > > re > > > served=0> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw > > ww > > > .rfc-editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dsourcecode- > > types&data=0 > > > > > 5%7C02%7Cmohamed.boucadair%40orange.com%7Cafbd80b5eecb49c0fed008ddd1 > > 2663cd%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6388966862010721 > > 01%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwM > > CIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C > > &sdata=XzKb1WGz12jsA1P2w8ftVXZertKZfFHfXyjss%2FYnv6U%3D&reserved=0) > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw > > ww.merriam- > > webster.com%2Fdictionary%2Fnonexistent&data=05%7C02%7Cmohamed.boucad > > air%40orange.com%7Cafbd80b5eecb49c0fed008ddd12663cd%7C90c7a20af34b40 > > bfbc48b9253b6f5d20%7C0%7C0%7C638896686201085566%7CUnknown%7CTWFpbGZs > > b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFO > > IjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=vToGuVpKKBIgdBII > > E55U31c2MloCmh6RScHeVVFWDtA%3D&reserved=0). > > > --> > > > > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw > > ww > > > .rfc- > > editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7 > > > > > C02%7Cmohamed.boucadair%40orange.com%7Cafbd80b5eecb49c0fed008ddd1266 > > 3c > > > > > d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638896686201097833%7C > > Un > > > > > known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi > > Oi > > > > > JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=w9 > > wk > > > MIujcpBDyUqj4Tp82uDAsHB9vbOsLlvIky5nvFQ%3D&reserved=0> > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw > > eb > > > > > .archive.org%2Fweb%2F20250214092458%2Fhttps%3A%2F%2Fwww.nist.gov%2Fn > > is > > > t-research-library%2Fnist-technical-series-publications-author- > > instruc > > > > > tions%23table1&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cafbd8 > > 0b > > > > > 5eecb49c0fed008ddd12663cd%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0 > > %7 > > > > > C638896686201109695%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > > Il > > > > > YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7 > > C8 > > > > > 0000%7C%7C%7C&sdata=7H1rKkvyDJO18luItkz6wvpDjZLB6%2FrXDOuxAc8zXzI%3D > > &r > > > eserved=0> 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 > > > > > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
