[dns-operations] ICANN ITHI issues

[Rubens Kuhl]

Hi there.

Due to time limitations during the OARC talk on ITHI this afternoon, I am writing the issues I see with ITHI in more detail here.

First, the theme more close to DNS-OARC are the M3 and M4 class of metrics on name collisions. The problem there is that while the top strings are listed, they are not qualified as being dotless (like "MAIL" has an almost absolute prevalence), being concentrated on few strings (like "broadcom.home" if those routers were the only ones contributing collisions to .home) or being dispersed like acme.corp, umbrella.corp etc. For instance, if one compares M3 and M4 they would see MAIL leading M4 (DNS resolver view) but nowhere to see in M3; that has a reason, which is the mainly dotless characteristics of those that enable caching of the NXDOMAIN response, but the data fails to give enough detail to reach that conclusion.

Next I will mention DAAR-related stuff. First on naming & shaming; while ITHI hasn't resorted it to yet, ICANN did it in DAAR, which provides some of the ITHI metrics. And they did in the worst possible manner, by aggregating TLD contract dates (2012+, <2012), so instead of mentioning that TLDs X, Y and Z are bad (like many IDS/OARC presentations), they clustered it. So those operators that are doing good in that regard will be seen as bad due to being in that cluster, not on merits. This strongly undermines the community confidence in providing more data for ICANN to handle like this.

Other DAAR problems include:
- Spam is included in abuse metrics, while spam is not usually banned in registry/registrar AUPs and is also not illegal in most jurisdictions. ICANN's reasoning to keep this there is repetitive but flawed, like mentioning spamvertised malware.
- Most data sources ICANN is using for DAAR don't make a difference between maliciously registered domains and compromised domains. So, joesbakery.com/wp_include/bankname <http://joesbakery.com/wp_include/bankname> gives a contribution to the index same as bank name-support-account-frozen.com, which is not helpful since it would be just adding more collateral damage to the compromise if domain delegations were actually suspended for that. When I question those data sources directly about that problem, they say they need more money to handle making such differentiation... so if ICANN stopped subscribing for data that has that low quality, that would provide a financial incentive for them to handle things differently.

So I am on the record for encouraging people not to contribute data to ICANN, considering their handling of it. But keep providing them to OARC were I see a healthy data sharing environment.


Rubens


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190513/11862565/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190513/11862565/attachment.sig>