[DNS-Abuse-Measurements] abuse suspension of infrastructure domain names

[Reg Levy]

Andrey—

I sympathize. As a registrar, we are running into situations where registries are discovering a domain on a blocklist and demanding that we take the domain down or they will. In some cases, the registry is amenable to conversations along the lines of "this is an infrastructure domain name" or "we have discussed it with the customer, which was hacked, and the issue has been remediated" but some registries are demanding that we (or the registrant) take it up with the blocklist and will not accept any excuses until the domain is off the list.

I understand that this is at a different level (registry vs. registrar) but I also understand that there are many reasons that a domain might get used for DNS abuse that ought not result in suspension of the domain. I do not understand how to convey this concept in a manner that trigger-happy parties understand.

/R


--
Reg Levy
Head of Compliance
Tucows

D: +1 (323) 880-0831
O: +1 (416) 535-0123 x1452

UTC -7

> On 27 Apr 2020, at 09:57, Andrey Nesterenko via DNS-Abuse-Measurements <dns-abuse-measurements at icann.org> wrote:
> 
> Dear community,
> 
> I am a representative of a hosting service company. Today one of our domain names has been suspended by domain registrar because of spam abuse. The domain name is in fact infrastructure domain name which we used since 2005 for some dns servers and in server names.  Here is what happened - spam was sent from a hacked script on one the cPanel shared hosting servers.  And this server has this naming convention - sharedserver.$suspendeddomain.com <http://suspendeddomain.com/>
> 
> Of course, this domain name has nothing to do with that spam, but this suspension resulted in a major outage (fortunately not that long) for many services and customers in our global infrastructure.
> 
> I don't think it is a good idea to post here the domain name in question and corresponding registrar because my concern here is not how their abuse team handled that, but about some feedback from community and ICANN.
> 
> Would it be a good idea to protect such kind of domain names use in infrastructure of certain businesses from being suspended immediately for such low priority cases? There are a lot of companies like us who have just a few domain names important for DNS and resolving routing infrastructure tasks and they have to be protected somehow.
> 
> This is the second time it has happened to us so far.  The first time it was with .host registry a few years ago when they suspend another domain name used in our PaaS cloud infra: each environment had a domain name set up in such a way - env-123456.mircloud.host - exactly the same way as other cloud providers. Of course, it is possible that one of the customers can host phishing tools or viruses on such subdomains, but it should never mean to block the whole domain name entirely. That time it was blocked directly by Radix btw.
> 
> Any ideas and feedback here to help us deal with such situations other than becoming a registrar ourselves?
> 
> Andrey Nesterenko
> MIRhosting
> _______________________________________________
> DNS-Abuse-Measurements mailing list
> DNS-Abuse-Measurements at icann.org <mailto:DNS-Abuse-Measurements at icann.org>
> https://mm.icann.org/mailman/listinfo/dns-abuse-measurements <https://mm.icann.org/mailman/listinfo/dns-abuse-measurements>
> 
> _______________________________________________
> 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://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos>). 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: <http://mm.icann.org/pipermail/dns-abuse-measurements/attachments/20200430/4af0218d/attachment-0001.html>