[NCAP-Discuss] Root Cause Analysis Reports - Final Call for Comments

Mon Aug 8 23:23:09 UTC 2022

Dear all,

I have taken some time to review the additional section added to the Root Cause Study that looks at the impact of Qname Minimization (QNM).  I have some fundamental concerns about the analysis and do not agree with the conclusion stated in this new section. Here is a summary of my non-editorial concerns:

Section 7.3.1

  1.  The criteria for classifying IPs to be qname minimizing is not motivated and supported by any data or evidence. Why is the five-query threshold appropriate? Why is the 100% single label query restriction appropriate? Given what we know about recursive resolvers it seems the former is too little, and the latter is too much.
  2.  There is no ground truth knowledge of what a QNM resolver should look like. To determine qname minimizing behavior, a baseline needs to be established. Profiling known implementations of qname minimizing resolvers would provide an appropriate set of heuristics (Per Warren’s comments). Currently, the heuristics used provide no assurance this is an accurate selection of QNM resolvers. This newly selection criteria should be clearly stated why it doesn’t rely on existing knowledge [1], which already shows a variety of differences in QNM behavior from recursive resolvers that are not captured in this measurement.
  3.  The selection criteria ignores a more selective QNM criteria defined in the RFC such as the Qtype (e.g., A and NS) and excludes multiple implementations of QNM techniques (e.g., nonce second level labels, underscore labels, asterisk labels, etc.).
  4.  Qname minimization measurements that are broadened to the ASN are overly vague and do not reflect an accurate portrayal. A single IP that exhibits this five-query selection criteria could potentially include thousands of other querying sources that are not QNM adherent within that ASN. Furthermore, measurements at the IP level are from a name collision perspective measurement, are also misrepresented. Rapid expansion at the root via IPv6 via a few ISPs shows why such a measurement is biased and non-representative. What matters is the total leakage rate.
  5.  The percentage of queries increasing then subsequently decreasing during the span of 2018-2021 needs to take into consideration exogenous factors.  Things such as the impacts of Chromium queries and their subsequent reduction. Especially given the selection criteria used and the properties of Chromium queries.
  6.  The drop in collisions in 2015 should be expected due to caching behavior and it is an unfair to compare NXD query rates to positive referral query rates.
  7.  A large public recursive resolver that implemented QNM, which would not be captured via the “no query with a qname having more than one label” criteria, is excluded from this analysis and represents upwards of nearly 7% of all A root traffic – which is a significant gap when the 7.3.1 figure shows only 14% of total queries are QNM in 2021 (e.g., a 50% measurement gap based on the selection criteria used).

Section 7.3.2

  1.  This section makes a measurement that is not motivated by any data or evidence that an IP address will persist at the RSS over multiple years.  While the assumptions made in this section might “greatly simplify the data and the analysis”, it does not provide any reasoning or rationale as to why it is appropriate to do so.

Conclusion

I believe my concerns here are substantial enough that the conclusion cannot be supported by the data. The current analysis is biased based on an unmotivated set of heuristics to determine QNM deployment and that IP persistence within the RSS can be measured accurately longitudinally.

Matt Thomas
Verisign

[1] https://www.nlnetlabs.nl/downloads/publications/devries2019.pdf

From: NCAP-Discuss <ncap-discuss-bounces at icann.org> on behalf of Warren Kumari <warren at kumari.net>
Date: Monday, August 8, 2022 at 6:32 PM
To: Casey Deccio <casey at deccio.net>
Cc: NCAP Discussion Group <ncap-discuss at icann.org>
Subject: [EXTERNAL] Re: [NCAP-Discuss] Root Cause Analysis Reports - Final Call for Comments

Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

On Wed, Aug 03, 2022 at 12:11 PM, Casey Deccio <casey at deccio.net<mailto:casey at deccio.net>> wrote:
Dear NCAP DG members,
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.
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.

Erm, insert my disclaimer about having missed some calls here.

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.

As far as I can see, the document doesn't discuss / consider aggressive-nsec (RFC8198 - "Aggressive Use of DNSSEC-Validated Cache"<https://secure-web.cisco.com/1qBFF_Mi3IqPqJ9grl4QJg0zsbX49GIpvzSDIoi6VTvRSSP7kRmTWkLSuxiIK1cGY7ge-aJ9k76Q_FfK9NCOHXcKSz2rJsf4AlCQTfiAiAOCSIR46ijbzAp1Q1svUrqCbIHyislERAqfUhXvk8y-9Gu5tzvZ74uoLYvJ1yiERh4Bpbo1lv-L-fk3T70ioC-5f3XnberIVIEfXR5oZ8J-zRVV6Js9B5boO4BfOqNI4jH5zG1rDhC0oAALnewj88jYu/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2FRFC8198%2F>) at all, and this seems like it is a significant oversight.

As an example, I configured a name-server to perform aggressive-nsec (  synth-from-dnssec yes;  — Note: From https://bind9.readthedocs.io/en/latest/reference.html<https://secure-web.cisco.com/1krdORAk0ucfMyAnMJkEZ_ZcogZtXgJbjGXrVXGoTNP23enHQ2ZANHS796X4YARw_qzzGQI_dooVqIXtPB3DNIUqOK4814VRCfuAo6uUUxNzWM4xx7Gfe2B_AXldM10hn3Z5w26KN1b_8pRWyegx8a5dowhoCy349asY6PbJaxI9CS9Zf8dECR8y18NbK3e2ABqENgYlGDrvXVHbUzY6FNqf99_HzKv8Yto2fhzYn_6QS8N6RzZ-cNPmGeF2Nf_w5/https%3A%2F%2Fbind9.readthedocs.io%2Fen%2Flatest%2Freference.html> , this is the default behavior), and restarted it to ensure that the cache was clean.

I then did:
$ ping -c 1 foo.corona
ping: foo.corona: Name or service not known
$  ping -c 1 foo.corp
ping: foo.corp: Name or service not known
$ ping -c 1 foo.corpulent
ping: foo.corpulent: Name or service not known
$  ping -c 1 foo.corral
ping: foo.corral: Name or service not known
$ ping -c 1 foo.correct
ping: foo.correct: Name or service not known
$ ping -c 1 foo.correlate
ping: foo.correlate: Name or service not known
$  ping -c 1 foo.correspond
ping: foo.correspond: Name or service not known
$ ping -c 1 foo.corridor
ping: foo.corridor: Name or service not known

and here is the result:
----
18:18:06.327971 IP 204.194.23.4.57539 > 192.36.148.17.53: 6424 [1au] NS? corona. (63)
18:18:06.328429 IP 192.36.148.17.53 > 204.194.23.4.57539: 6424 NXDomain*- 0/6/1 (1055)
^C
40 packets captured
40 packets received by filter
0 packets dropped by kernel
....

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).

 I still believe that this is a significant issue, and, unless I missed something, is not accounted for or discussed in the document….

W

Root Cause Analysis - wpad.domain.name<http://secure-web.cisco.com/1A96g89V90y_bxMrHeUpK3_gF26JWie5RWR0vH2hlIDSnnzKphqVHjfTCJZ40MynWvUVvqNUdGrKrthvFt09_XkoKnPh4fwOOzLULcrE1b9q67SwrsQWC5CjCjzL0LCuiaZ1ggXLNFvOSocLN_cqgq3bQ-7JWeTUNv-xmeRkHky5L3GM_aqogPmZdMW-Y9eTLZXv4DBdJib3LiMwGs-DxHaK28SwQLBqTjv2bmWlAnx1Yz1PLV70uK65lGdS-gufj/http%3A%2F%2Fwpad.domain.name%2F>
https://docs.google.com/document/d/1y5jcWeH3gOKzxtF7_BnqNdwbbvlyqvshNVIZvJ19wDg/edit?usp=sharing
Root Cause Analysis - New gTLD Collisions
https://docs.google.com/document/d/1YSvdH9Slws0iW3e6yoS04s5zANBnyMMFn9DUNE19fkg/edit?usp=sharing
Please request access if you don't have it.
Cheers,
Casey
_______________________________________________
NCAP-Discuss mailing list
NCAP-Discuss at icann.org<mailto:NCAP-Discuss at icann.org>
https://mm.icann.org/mailman/listinfo/ncap-discuss<https://secure-web.cisco.com/1y139_aJSlBYZwpxg-T0JfrpLZRHBKkWnleiCftMCIrS1l-VRRnjyNNAhq0MN7b-Tb2gM-xswdXJOARS86CT-s8obi-YJ7oCvN0Sg3zOPXUmSRADtBQMgJ3I16Rn9zlTEVbX3IHJdb5gzD4BgtItcjyPVPWT3d0C-hX46aXRAA6dFziHusHnRr8ga3oAc7kGrIgCxBbg9EO_2kvttLpt0LI4E5B2ZPbxLJ8ImB3aw0B-yhUArYOk0pyY0Jogt2W5h/https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fncap-discuss>
_______________________________________________
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 (https://www.icann.org/privacy/policy<https://secure-web.cisco.com/1QtlUyQF3H3CsD61tMRkgsXXNGU4res8YdaXQS3h1nCbTnYNzEZSU5ySJ_cQwptClv8V3BTL6BTz3l5ZDKHyf0IO0hMp_q0pbFDaMzJM-YlfjzuPoqT5n1N5wgbvK8WD2es9yF4IegbVnXOGMpM_5_igNHkkLRzADKStE20dpVeYQnoV8xXFw4kIbyU7USBMY_7tt-2V4AxVkgnNrDv4YLtQ5CLWTvEwign32A9DhikA11StK24tY_z5-n6MX5GzT/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://secure-web.cisco.com/1stPjJf8u8_wG2sYeHh-mJbVX5giU10Kl5NYDFO8RuUR3lDxE0rPPJxx0-bnPExolL7v_9yYgp1A2eRBZdhHcIUiulYdV7lEOkcWVmDSD6M_CZ-8fY1saOip8cI6tCVpXE1teFo3qsNnAdSwpuGFTptGfzRJCrsOE_4Hw0jA_6xA7oJkUbWi2Y3r5lzXqBegUdIeTfeVCsdyERbBm5DE2h0fC1Uve8Cax5gZ8glqkNcpFtNFtyqd7MUO4lwh8jVEj/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos>). 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220808/13ff552e/attachment-0001.html>