<html><head></head><body><div><div><div class=""><div class=""><div class=""><div class=""><br></div></div><div class=""><br></div><div class="sh-signature"><div class="gmail_signature"><br></div></div></div><div class=""><br></div><div class="sh-quoted-content"><div class=""><div class="gmail_quote"><div class="">On Wed, Aug 03, 2022 at 12:11 PM, Casey Deccio <span dir="ltr" class=""><<a href="mailto:casey@deccio.net" target="_blank" class="">casey@deccio.net</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><p class="">Dear NCAP DG members,
<br></p><p class="">
As you know, I have written two reports associated with root cause analysis for name collisions reports received by ICANN. Some time ago I distributed earlier versions of these documents to this mailing list, which resulted in feedback that I have addressed in the latest versions. Most of the changes are relatively minor. The one significant addition is the inclusion of a section on "Qname minimization considerations", which is now section 7.3 of the "Root Cause Analysis - new gTLD" report. The final version of these reports will be included as appendices in the Study 2 document, along with other reports that have been written in conjunction with Study 2.
<br></p><p class="">
I invite you to read the documents, with particular attention to the new section. I will consider this a final call for comments from the NCAP DG.<br></p></div></div></blockquote></div></div></div></div><div class=""><div class=""><br></div><div class=""><br></div><div class="">Erm, insert my disclaimer about having missed some calls here.<br></div><div class=""><br></div><div class="">Apologies if I missed this in the document, but I read it, and then also searched for terms like 'aggressive' and 'nsec' and RFC8198 similar, with no luck.<br></div><div class=""><br></div><div class="">As far as I can see, the document doesn't discuss / consider aggressive-nsec (<a href="https://datatracker.ietf.org/doc/RFC8198/" target="_blank" rel="noopener noreferrer" class="">RFC8198 - "Aggressive Use of DNSSEC-Validated Cache"</a>) at all, and this seems like it is a significant oversight. <br></div><div class=""><br></div><div class="">As an example, I configured a name-server to perform aggressive-nsec ( synth-from-dnssec yes; — Note: From <a href="https://bind9.readthedocs.io/en/latest/reference.html" class="">https://bind9.readthedocs.io/en/latest/reference.html</a> , this is the default behavior), and restarted it to ensure that the cache was clean.<br></div><div class=""><br></div><div class="">I then did:<br></div></div><div class="">$ ping -c 1 foo.corona<br></div><div class="">ping: foo.corona: Name or service not known<br></div><div class="">$ ping -c 1 foo.corp<br></div><div class="">ping: foo.corp: Name or service not known<br></div><div class="">$ ping -c 1 foo.corpulent<br></div><div class="">ping: foo.corpulent: Name or service not known<br></div><div class="">$ ping -c 1 foo.corral<br></div><div class="">ping: foo.corral: Name or service not known<br></div><div class="">$ ping -c 1 foo.correct<br></div><div class="">ping: foo.correct: Name or service not known<br></div><div class="">$ ping -c 1 foo.correlate<br></div><div class="">ping: foo.correlate: Name or service not known<br></div><div class="">$ ping -c 1 foo.correspond<br></div><div class="">ping: foo.correspond: Name or service not known<br></div><div class="">$ ping -c 1 foo.corridor<br></div><div class="">ping: foo.corridor: Name or service not known<br></div><div class=""><br></div><div class=""><div class=""><br></div><div class="">and here is the result:<br></div></div><div class="">----<br></div><div class="">18:18:06.327971 IP 204.194.23.4.57539 > 192.36.148.17.53: 6424 [1au] NS? corona. (63)<br></div><div class="">18:18:06.328429 IP 192.36.148.17.53 > 204.194.23.4.57539: 6424 NXDomain*- 0/6/1 (1055)<br></div><div class="">^C<br></div><div class="">40 packets captured<br></div><div class="">40 packets received by filter<br></div><div class="">0 packets dropped by kernel<br></div><div class="">....</div><div class=""><br></div><div class="">As expected, there is a lookup for .corona but there is no query sent to the root (or anywhere else) for anything in .corp (or corona or corpulent or corral or correct or …) — the NSEC record (coop. 10800 IN NSEC corsica. NS DS RRSIG NSEC) already proved that there is nothing alphabetically between .coop and .corsica, and that space covers all of the above names. This means that there could be names with significant use, but that are not being exposed (or, if they are, that the magnitude is hidden).<br></div><div class=""><div class=""><br></div><div class=""> I still believe that this is a significant issue, and, unless I missed something, is not accounted for or discussed in the document….<br></div><div class=""><br></div><div class="">W</div><div class=""><br></div><div class="sh-quoted-content"><div class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><p class="">
<br></p><p class="">
Root Cause Analysis - <a target="_blank" rel="noopener noreferrer" href="http://wpad.domain.name/" class="">wpad.<wbr>domain.<wbr>name</a>
<br>
<a target="_blank" rel="noopener noreferrer" href="https://docs.google.com/document/d/1y5jcWeH3gOKzxtF7_BnqNdwbbvlyqvshNVIZvJ19wDg/edit?usp=sharing">https://docs.google.com/document/d/1y5jcWeH3gOKzxtF7_BnqNdwbbvlyqvshNVIZvJ19wDg/edit?usp=sharing</a>
</p><p class="">
Root Cause Analysis - New gTLD Collisions
<br>
<a target="_blank" rel="noopener noreferrer" href="https://docs.google.com/document/d/1YSvdH9Slws0iW3e6yoS04s5zANBnyMMFn9DUNE19fkg/edit?usp=sharing" class="">https:/<wbr>/<wbr>docs.<wbr>google.<wbr>com/<wbr>document/<wbr>d/<wbr>1YSvdH9Slws0iW3e6yoS04s5zANBnyMMFn9DUNE19fkg/<wbr>edit?usp=sharing</a>
</p><p class="">
Please request access if you don't have it.
<br></p><p class="">
Cheers,
<br>
Casey
<br>
_______________________________________________
<br>
NCAP-Discuss mailing list
<br>
<a target="_blank" rel="noopener noreferrer" href="mailto:NCAP-Discuss@icann.org" class="">NCAP-Discuss@<wbr>icann.<wbr>org</a>
<br>
<a target="_blank" rel="noopener noreferrer" href="https://mm.icann.org/mailman/listinfo/ncap-discuss">https://mm.icann.org/mailman/listinfo/ncap-discuss</a>
</p><p class="">
_______________________________________________
<br>
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a target="_blank" rel="noopener noreferrer" href="https://www.icann.org/privacy/policy" class="">https:/<wbr>/<wbr>www.<wbr>icann.<wbr>org/<wbr>privacy/<wbr>policy</a>) and the website Terms of Service (<a target="_blank" rel="noopener noreferrer" href="https://www.icann.org/privacy/tos" class="">https:/<wbr>/<wbr>www.<wbr>icann.<wbr>org/<wbr>privacy/<wbr>tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.</p></div></div></blockquote></div></div></div><div class=""><br></div></div><div class=""><br></div></div><div></div></div></body></html>