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
