DAAR – ICANN’s Domain Abuse Activity Reporting Project

DAAR – ICANN’s Domain Abuse Activity Reporting Project

There was another part of ICANN I was interested in, which there was much community interest in. That was the DAAR system, which stands for Domain Abuse Activity Reporting and is currently being developed by the Office of the Chief Technology Officer (OCTO) at ICANN.

To boil it down quickly, it takes a number of the abuse lists that a lot of people use for Mal servers, etc. and combined all that information into one place for “statistical” monitoring at this stage. One of the eventual aims of this project could be to be able to enable ICANN compliance to react far more quickly to issues or to allow service providers access to these lists to help reduce the number of malware, phishing and spam operations out there.

Now that all sounds fine and dandy until you start to comprehend the issue. ICANN is combining many different lists from Spamhaus to phishing lists together to form this list. And while you might use an RBL (Real-time Black LIst) on your mail server, denying DNS to domains ultimately could become a serious nightmare.

As a web host provider in a previous life, I cannot tell you the number of times innocent customers have had their sites hacked or cracked to pieces, and then malware or phishing sites uploaded. Now they have no clue about this until somebody comes along and suspends their service and then they get told to clean shop. The real issue, in this case, is end users not understanding the significance of keeping their software up to date and then having it cracked wide open.

In the scenario above, the domain would be removed entirely from the DNS system – which is pretty extreme. Yes, people are going to be safe from phishing on this particular domain, but it does nothing for the reputation of the web host provider and their customer who are going to get into argy-bargy over it. And in my view, there is no point in trying to lay this at the feet of the service provider. Because no matter how many sophisticated systems you have installed, there will always be those who just want them turned off for the sake of convenience. It has to be a provider-wide effort to get this under control.

While I have not yet looked into every single list that is being aggregated, I hope that ICANN has NOT included anybody who makes you pay money to delist. I have always had a policy; I am not paying to delist – go fly a kite. I think once, and only once I did it – and I was not impressed with myself by the end of it. We ended up back on ye olde blacklist almost straight away because a rouge piece of spam got through or something ( a long time ago now).

And another issue with these sorts of lists, a web hosting provider or domain name registrar/registry – it is essential for us to have evidence and faith in the system before acting on it. What if their domain or hosting is suspended hours after the initial breach and the customer have already cleaned up shop? Overkill, not to mention puts a significant strain on the provider and may potentially activate legal ramifications. If I am going to suspend a domain or web hosting, you had better believe I am going to have checked it before I click the magical button to stop a customers service in its tracks. That’s just not being fair; it’s common sense!

I do think it has a great future, we just need to make sure it’s adequately thought through and implemented before unleashing upon the unsuspecting masses, and it is left up to the end service providers to mop up the mess.

If you are interested in the project, you can find more details by following the link below.


GDPR – General Data Protection Regulation – Part 1

GDPR – General Data Protection Regulation – Part 1

NOTICE: I am not a lawyer, and therefore this should not be construed as legal advice. This is how I see it, and I could be right, or I could be severely wrong. In any event, please speak with legal representation about the situation.

One of the last weeks most significant topics at the ICANN60 AGM was around the General Data Protection Regulation which comes into effect on the 25th May 2018.

This is a regulation, and not a directive as well. What’s the difference, well a directive would still need member states to pass their legislation to have it enabled. Regulation, however, does not require any of these and so is instantly in effect across all member states.

There are several terms which one should become familiar with

“Data Subjects” is a reference to individuals in the EU member states who are having their data processed/handled.

“Data Processor” is meant to cover anybody who has to process data to complete a contractual obligation to another entity. Registrars and Registries in the ICANN ecosystem are such entities which are classified as Data Processors.

“Data Controllers” is another interesting term, which covers all entities who require their subordinates to provide them with data to enable services to be provided. It has been argued that ICANN will be a Data Controller by definition. However, it still is yet to be determined if that is the case.

“Data Protection Officer” is a security leadership role, who is in charge of making sure all aspects of data processing and system processes are in line with the requirements for GDPR and any spin off’s around the globe.

“Data Protection Authority” is the entity per member state that is in charge of making sure everyone is implementing GDPR compliance correctly, as well as issuing fines, etc. for problems in their jurisdiction (i.e. country).

If you are interested in reading the regulation itself, then you can grab it from here. Warning, reading the document may cause your eyes to bleed and your soul to burn. You have been warned.


There is just so much to go through in regards to the GDPR and all the various known and unknown elements. So I will be covering this over multiple blog posts to try and make this as easy to understand. This blog post is the primer, so you at least understand the basic principles before we go into depth.

And yes, while it covers data subjects in EU member states – it does not exclude companies outside of the member states. Everybody is in the same boat. If you are selling products and services to anybody located within the EU, then you are bound by it.

To appoint or not appoint a representative to the EU GDPR?

According to the GDPR, outside organisations who process EU data subjects should appoint a representative to the EU and any allegations or issues would be referred to this rep. However, bare in mind that this representative could also become embroiled in any matters with non-compliance of the GDPR. This is in addition to the actual processor/controller themselves being involved.

And just to make it abundantly clear, just because you appoint a representative that doesn’t mean you will avoid any prosecutions, etc. for breaching the GDPR. They could still come calling to say hi regardless.

How do I know if I am bound/included by this?

There has been a discussion that if you do not directly target EU individuals, then it’s not such an issue – but from what I can see, the definition of targeting seems to be a little vague. One example is apparently if you only sell services on a very occasional basis to EU individuals, then it is claimed you are not targeting them. Or the information you are processing is not defined as “Sensitive Personal Data”.

However, one such scenario gives me the cranks and makes me wonder if there will not be a legal showdown at some time shortly is if you are a registry or registrar who provides services to end users, then you could take the example above, and it might not be a big deal. But, to me, if you offer a ccTLD or TLD that has a basis in the EU zone or could be construed that way, then too me you are targeting EU individuals. Especially if that ccTLD or TLD has registration requirements that only EU based residents can register them. So, therefore, you are bound by GDPR regardless.

I am going to go out on a limb here, and just say it. Until you have confirmation, you are not involved with GDPR, assume you are. It’s better to be safe than sorry in my books.