Hi all...

Please note that this session is exclusively for interaction between the ICANN Board and the panel of experts.However, all participants may make comments in the chat. Please use the drop down menu in the chat pod and select "respond to all panelists and attendees." This will allow everyone to view your comment. Questions and comments placed in chat will be considered as part of the “chat” and will not be read out loud on the microphone.To listen to the interpretation, please click on the interpretation icon in the Zoom toolbar and select the language you will listen to and/or speak during this session.To view the real time transcription, click on the “closed caption” button in the Zoom toolbar.Please note that chat sessions are being archived and follow the ICANN Expected Standards of Behavior. http://www.icann.org/en/news/in-focus/accountability/expected-standards.

Greetings all

Greetings from the Office of the Ombudsman

Welcome everyone

Thanks for joining

Are GNSO Councilors Panel or Attendees?

@Mark they are attendees

@Leon Gracias

Saludos

Igualmente!

Thank you to Board for hosting this dialogue

Can’t see videos… just frozen on Martin.

Better

Would it be possible to show the speaker - we are seeing Maarten’s video feed

(It sounds like the current speaker is on phone… )

@Brian we will switch to video when starting the panel; we’re currently showing a few slides so that everyone knows the agenda and speakers.

@Mary, thanks so much!

With thanks to our distinguished panelists for joining the Board and community today, here is a list of the speakers today with brief bios for each: https://www.icann.org/en/system/files/files/biographies-informational-session-dns-abuse-panel-discussion-18oct21-en.pdf

Can you provide a definition of what constitutes a “Malicious Registration"?

Hello, just a reminder that we will not be taking questions for the panel from attendees today, as this session is part of the Board’s ICANN72 Workshop and intended to be a dialogue between the Board and the panelists. Thank you.

may we have a link to the document Cristine is referring to?

This is the document I referred to: https://community.icann.org/display/DSFI/DSFI+TSG+Final+Report

Is there a link to the report Christine mentioned? Thanks!

This is the document I referred to: https://community.icann.org/display/DSFI/DSFI+TSG+Final+Report

thank you, Cristine!

@Reg, here is a blog post about the work of the DSFI-Technical Study Group (chaired by SSAC liaison to the Board Merike Kao), with a link to the report: https://www.icann.org/en/blogs/details/hats-off-to-the-dns-security-facilitation-initiative-tsg-for-exceptional-report-15-10-2021-en

Thank you Cristine (as well as your expert review during the technical consultation period as the DSFI-TSG work was getting finalized)

Thanks Christine and Mary!

Greetings everyone

https://dnsabuseinstitute.org/dns-abuse-definition-attributes-of-mitigation/

Really interesting dialogue, so seems definition could, at least, include malicious registrations where such leads to technical or content abuse.

Or both…

how about the abuse of badly implemented standards? like a +all in a SPF record?

DGA is domain generating algorithm

DGA is domain generating algorithm

+1 to Graeme’s comments re action on phishing/malware vs. edge cases.

This is very insightful Cristine

+1

Excellent points by Cristine.

+1 Christine!

Absolutely, thanks for sharing Christine. As civil society we also have hesitations around the available mitigation measures and like Graeme said they do need to be proportional and take in consideration the place for human rights protection especially Freedom of Expression - June, ARTICLE 19

Many instances of spam, especially medical spam, is clearly abusive and a threat to Internet users. We do not do enough in the names and numbers community to mitigate this. A lot ends up done by parties around us such as Spamhaus and others.

Mark - it’s a hosting issue more than a registrar / registry issue.

+1 to Mark, a lot of action is taken outside, luckily. Obviously, names are not the only element in many schemes, as Michele underlines but they are still a necessary part in many cases. And in some cases, clearly identifiable as being part of malicious activity.

@Michele As somebody who has worked on trying to take some of these actors down, my experience is that many hosting companies are uncooperative. You could say "find ways to make them more cooperative". On the other hand, we could also mitigate from our side and generate less harm to end users.

What are the legitimate uses of DGA's?

Dean - there aren’t many tbh

Thanks Michele. That

is helpful.

CDN and click tracing definately is using DGA

Mark - so? just because they don’t co-operate doesn’t make it any less an issue at that level.

It doesn't exempt ou public interest committment either

Michele, Mark: this applies to both hosters and naming players. What can be done to force actors to react appropriately when abuse is reported?

GDPR 😖

Laurin - I wish I had a good answer for that.

I’ve lots of thoughts on reporting, but I don’t wanna get in front of later topics

Is there any hope of resolving that issue for experts to be able to use Whois data for security research, detection, and response? This has been a huge setback on the back of GDPR

😃

Well, I would argue that certain processes, requirements, “service levels” need to be created and adopted, thus made a requirement of doing business. Is that hard, yes. Will it work everywhere in the world, no. Would it help if a good number of (key) players take part, yes.

This is something for Graeme to comment upon, but I think the issues Roman just spoke to are the types of protocols and processes that the DNS Abuse Institute plans to work on as a service to the entire community: registrars and registries as well as reporters of illegal activity.

And there we go. Stew hits upon the value of accuracy and authentication of registrant data, which serves not only to provide recourse for abusive behavior, but also serves to dissuade abusive behavior before it happens.

Hi, Frank Michlick from Web Hosting Canada (WHC) here.

+1 Stewart

KYC

A big +1 to Roman’s comments on challenges of abuse notification and lack of standards of how, who, evidence standards, etc. continuing to be a major problem for both reporters and infrastructure providers. This is what the SSAC addressed in SAC115. The problem is larger than just the domain name space, but members of the ICANN community are impacted by these challenges and should be looking to be part of solving them.

Any transaction or ID can be faked by those with criminal intent. Renting cars, opening bank accounts, etc.

+1 Donna

It always interests me that those calling for all this KYC stuff + publication of more data are nearly always white CIS males

Just because it’s faked doesn’t mean it’s useless. Consistent faking, style of faking is very valuable.

KYC is a nice catch phrase, but no one is telling us how to actually achieve this (no one outside of China)

I’ve been a woman online most of my life and am perfectly happy using anonymity services or fake usernames to avoid even more vitriol

There is no evidence that increased accuracy in registration data decreases DNS Abuse

Donna seems to argue that because some people break rules that it's not useful to make it harder to prevent or detect rule breaking.

And the most recent ICANN Whois ARS showed 90%+ of domain names had contactable registration data. So not sure how much time/effort (and importantly money) should be thrown at “improving” accuracy

@Owen when .de started asking for ID for domain registrations, fraudulent domain registrations dropped by 95%

@Owen--I disagree. DK Hostmaster gave a presentation demonstrating that their efforts to increase accuracy of their registrants identification led to a significant decrease of abuse. Do you think DK Hostmaster is wrong on that?

There is no evidence? Is there evidence it stays the same or increases it? Who is forcing KYC @Owen ?

Donna it’s the way water flows… easy does it and China mitigated most by just adding procedures to it. Their abuse levels changed overnight. And we see the same when certain registry’s run ‘sales’ … abuse will shift there. We tracked abuse vs domain pricing for about a decade now

ccTLD ≠ gTLD. There is absolutely no way we’ll be able to require IDs within ICANN framework. So we should consider realistic options rather than the impossible. And, once there’s an ID requirement or more accuracy requirement, the bad guys will find a way around it.

It's pretty clear if you look at reports and scoring from Spamhaus and other expert research organizations that the levels of abuse on ccTLDs where verification of registrant data is taken up (e.g., .dk or .eu) have much lower levels of abuse.

And we also see good work done with fast action on the registry level. Then they shift to a tld that’s less likely to shut it down right away

@Owen--why can't gTLD operators do what ccTLD operators do? Isn't it just a matter of willingness and cost?

Dean: what about profits? 😊

Can we please just get our security telemetry back?

ccTLDs have the benefit of clear/local jurisdictions. GTLDs are a shared global resource.

No security telemetry till you fix privacy Juan

Raymond: fair point and I suggest ICANN look into automated tools and processes that it could license and pay for and offer to all accredited registrars so that the costs aren't all imposed on registrars.

When multiple data points indicate a strong likelihood of abuse, the excellent .EU approach is to require verification of identity. It deters abuse very effectively. Eurid can provide data on this

Thank you Nick! I think that would be helpful to the community at large.

Exactly, a lot can be done by combining automatic and human processes.

Cristine, we agree with you 100%. The steps to be taken and appeal mechanisms in the decision making steps need to be clearly elaborated on - June, ARTICLE 19

Folks - I do not know why I am showing as “Donna Austin”. This is James Bladel (GDDY). Thanks.

KYC failure right there ^^^

Well, I am always the person bringing this up but: Trusted Notifiers with community oversight would solve several issues of cost/benefit.

+1 Mark

ICANN ZOOM not checking passports, I suppose.

🤣 hi donna/james

James, that is because you got the link from her.

@Dean- it’s very easy for a registrar in a ccTLD, where registrants are primarily from one country, to review/accept IDs from that country. Registrars in gTLDs have customers in hundreds of countries, and some people might not even have IDs. It’s impossible to design a system that can accept hundreds (or perhaps thousands) of possible IDs.

+1 Mark

Indeed @Laurin , like applying different filters in manufacturing tool kit use that is best fitted for purpose.

James. did you get the link for the session from Donna. everyone who did will show that way. Just rename yourself.

On proportionality too, to your point Cristine websites with great and credible experience for 10 years plus - then an entire domain is taken down, proportional or not?

Nice to see you here Donna! lol

Can someone help me out here. I'm seeing comments in the chat that are attributed to me Donna Austin but I have not made one comment in the chat.

Hey Donna!

@Avri - no option to see attendees or rename.

Just testing if I show as Donna. :)

they need to rename themselves if they got the url for the session from you.

+1 Mark, probably we need to go beyond just that but creating a framework around trustworthy parties is definitely useful.

Ashley here.

Mark, I think more needs to be done before we run to trusted notifiers as a solution. Who is a trusted notifiers, how are they picked and selected, what credibility metrics do we look out for? In some countries for instance, government and state actors are considered trusted notifiers

There are many ways to verify ID @Owen. One way is live chat where you ask the registrant to show government approved ID. EURID does this sometimes. Every country has government approved ID.

@Owen: I agree that the challenges are much harder when dealing with registrants from multiple countries around the world. That's why I think it makes sense for ICANN Org to help with an investigation of available tools and see if they can be licensed and made available at no cost to registrars. We shouldn't let the perfect be the enemy of the good. Even if there aren't cost effective and quick ways to verify registrant data from all jurisdictions, even if could be done for a number of major jurisdictions, it seems like it might be worthwhile.

The Donnas are staging a careful play to showcase the difficulty of name abuse.

My name is actually Andrew MacPherson, I don’t know how DNS works, so happy to be here and learn.

Hello Donna and everyone - the URL you received on registration is unique to your email/registration, meaning that if you shared that link for others to join, they’ll show up as you in the attendee list.

Some of the work we did on pandemic related names https://www.icann.org/en/blogs/details/an-18-month-summary-of-icanns-dnsticr-project-2-9-2021-en

June, I am not Mark but in my eyes that would require some form of assessment / audit.

@Dean- an ID system that cannot be implemented worldwide is a non-starter. We cannot prejudice those who cannot participate. And if DNS Abuse is such a large industry, I guarantee bad actors will find excellent fake IDs.

I don’t know who that is, but *I* am Andrew MacPherson and I DO know how DNS works!

There was discussion of a threat intelligence sharing group. What mechanism is being provided for that sharing?

So James is riding on Donna's registration coat-tails? ;-)

Roman’s point is well-taken but Cristine indicated that these were validated reporters claiming that these old domains were “maliciously registered” even though they were not

@Dean: Sounds shady, af.

Thanks, Mary. I believe Donna was the first to notify our team via internal Slack channel so some of us (me, James) lazily used that link rather than registering on our own. I take full responsibility, Donna’s reputation remains unblemished.

Thanks James - definitely!

though

Some of the work we did on pandemic related names https://www.icann.org/en/blogs/details/an-18-month-summary-of-icanns-dnsticr-project-2-9-2021-en

From the anti-abuse/sec side, we’d love to see a way to try and mitigate the gaps caused from whois changes

test. 😁

Thanks John

Verification will of course disproportionately affect access to domains for those in the global south. I appreciate that is a sweeping statement, but our views from a position of relative privilege, need to be far more global in application.

Panelists - Best to mute your mic & turn off video for the break

So how many fake Donnas are now oarticipating? You can see who in the community takes ID verification seruously ;-)

Je suis Donna Austin.

“If you would like to register using your name and email, please use this link: https://icann.zoom.us/webinar/register/WN_xgIwwqJRRwiiJ1b0iMbEgw”

@Nick Wood. Yes, thank you; please circulate that data. Seems like a more useful avenue of exploration.

Could we speak some techniques to detect malware at DNS protocol?

Hi @Graeme.

Back from the break... @June's point, the debate to me is exactly that Trusted Notifiers are basically government agencies and LEAs right now. Establishing TNs outside of this governmental realm, with actual community input, could be a game-changer.

+1 on the quality of the reports

DNS Abuse Institute Education materials at - https://dnsabuseinstitute.org/education/

Many CPs seem to receive very poor reports that are hard to action upon. This means better work needs to be done on that front.

DNS Abuse Institute Education Materials - https://dnsabuseinstitute.org/education/

A lot of work is done at M3AAWG directed to abuse. Much is very specific for DNS abuse also.

https://dnsabuseinstitute.org/the-dns-abuse-institute-roadmap/

much better

@Michele--as Graeme describes, this is one of the key early projects that the DNS Abuse Institute plans to take on. Please know that plenty of folks outside the CPH appreciate the frustration that CPs experience when they get inadequate or completely off-based complaints. The hope is that CART will help with this for both CPs and abuse reporters.

don’t worry, I have zero trust of all retail blocklists

Raymond, yes. M3AAWG and APWG just sent a policy letter to the board after the survey and report on WHOIS in the summer.

I know. We (SURBL) also submitted inputs there

Cristine earlier spoke about coronavirus domains being blocklisted on the basis solely of their use of “coronavirus” in the domain, leading to blocking of valid government informational domains.

We need better education materials out there for making these distinctions on actors and who to contact.

+1 Ashley-Donna

+1 Ashely

How about a interactive portal that would do most of the suggestions there :)

@reg levy, yes, there were not only government domains, but also domains (newly registered) by insurance companies, medical associations, and others, with health information. We even had a domain used to appoint online doctors appointments for suspected covid cases included in domain blacklists.

@Maciej, when will the EC study conclude and report?

I can answer; we shoot for November, maybe a bit later December

I wish somebody would actually define “bulk”

that terms keeps being used without any definition

Well, one problem seems to be that there is little trust in the mechanisms and processes that would deny “bad” registrations. Thus, the mechanisms used by other players might be configured with the assumption that a lot of stuff is just bad, blocking more than necessary.

+1 Laurin

SSR2 spoke to automating some parts of the reporting, making sure that reports contain key data and are automatically sent to the right party.

That recommendation (13) is currently pending, if I am not mistaken.

Just because crypto is used for bad purposes, does not mean it is always used for bad purposes. There are many legitimate uses. Also, bad actors use credit cards too. Crypto did not create DNS Abuse

Laurin, I’m happy to share more details on our CART plans

Wondering what the panel thinks about so-called bulk registrations. Is that something that should be avoided? And if so, to Michele's point, how should bulk registrations be defined?

It *needs* to be defined

To Graeme's earlier point on Preventative vs Reactive measures.... I note KYC standards benefit both Preventative *and* Reactive anti-abuse contexts.

I completely agree automation is key, but as Jonathan said it needs to be responsibly implemented and there MUST be a communication channel always open with humans, for CERTs and other anti-abuse professionals to report false positives. False positives will always exist. Also, when a new attack type arises, it takes a while to update the automated tools. I have a dozen case studies of months of abuse not dealt with because organisations were not open to have a human talk to us, instead of scripts and playbooks.

Graeme, would be very interested to hear more.

+1 Cristine

there’s one charming lot who literally send us reports saying that we can’t reply

I *love* those reports

@Michele--do you have ideas as to how it should be defined? I mean that sincerely and not rhetorically. Thinking with your background you may have a smart and reasonable idea for drawing the parameters.

Dean - well a threshold of some kind would be needed

like are you talking about registering 10 domains or 10 thousand

and anything I’ve read just says “bulk” but doesn’t say why they’ve decided it is “bulk”

Is bulk registration always a problem or does it depend on the nature of the names being registered?

Cristine, +1. From a research perspective (I spent 5 years on that area), having security staff and the possibility to speak with people is key. Having these people on staff costs money though. This means that if I care more about security, I have higher costs, while my competitors do not.

Seems to me 10 is clearly too low. 10,000 seems a lot. But honestly I have no idea what makes sense in between in terms of the # of registrations done at one time by one registrant that should trigger a warning/red flag.

@Christine, Do you think CERTs collaborate the way we expect them to do across countries when it comes to mitigation of DNS Abuse? if not what should be done?

Dean - and that’s part of the problem. The term is being thrown around a lot without any thought

Many issues circles back to pricing. If a domain would be not 50 cents you might have some more bandwidth to actually check who you are selling to. For the current price points not so much

Plus, going back to my point re SSR2 13.1-2, making sure that these people get correct, applicable reports would go a long way too.

Raymond, ä

I'm hearing that the reports Roman is referring to get reported to hosts, but for malware and phishing at least, are these also reported to the registrar? It seems registrars would have a role to play for at least these forms of abuse (setting aside for now the lack of a universal definition of actionable abuse by registrars)

Raymond, +1

I think there can be multiple thresholds. Over x than increased verification, over y then manual review, over z then resolution is prevented until customer is contacted

@ Michele I'd suggest a good starting question might be: what is the average # of domains purchase by a registrant? What is the # two standard deviations above that? 90% of your registrants will fall w/in two standard deviations of your mean (if my two decade fuzzy memory of stats serves), and thus you might draw a threshold for additional validation measures at that. Or any other arbitrary line, but it's a great conversation to have :)

(apologies for joining this session late, but it was not on my calendar and I understand it was only announced days ago, and not included as part of ICANN 72 prep or meeting schedule...)

There are legitimate reasons for bulk domain registration too, e.g. a new brand or product launch could require hundreds of new domains quickly.

Gabriel - I’ve no issue with people discussing it rationally.

Agree with you Michele. That's why I am wondering if we can work on reasonable and useful parameters. Just saying "bulk registrations" without any definition or common understanding as to thresholds and parameters isn't helpful. Would love to brainstorm with you about this. Preferably over a Guiness or two.

I think, lack of threat intelligence sharing due to weak collaboration mechanisms among us makes the challenges to get out of control

@Brian - but certainly a good reason to flag by registrar for further review/verification, no? I understand this is something done by certain regitrars, perhaps mostly on the ccTLD side, such as .dk?

Gabriel, that’s an interesting way to look at it, and then perhaps manual review of orders that exceed that number—however, are we talking in a single purchase or in an account? because the first might be doable and the second is completely untenable

It would be possible that registrations over n are not denied but put in a queue for review. Like the idea of having a real world formula.

Furthermore, research could be done on what “kind” of bulk regs are high risk; if these factors are present, lower n needed for review; if other factors are present that indicate lower risk, that n could go up.

I agree it might be useful to discuss some kind of standard threshold, but ideally something uniform and mandatory across Rr

Mandatory? oh dear

I know, I know... sorry for raising the scary M word Michele

+1 Laurin

Griffin, it is likely that different registrars and TLD see different patterns.

Griffin, “uniform […] across Rr” is not tenable. Michele and I have vastly different business models and what his n is and what my n is are likely orders of magnitude different

I'd imagine bad actors don't have any huge issues with spreading their domains over various accounts. Bulk registration "blocks" will be quite upsetting for other clients.

@ Reg - that's where your Subject Matter Expertise really comes into play. If you say one method is tenable, and the other isn't, and show why, then this particular knuckle dragger would be happy to learn such lessons from you, and focus on what is doable, eh?

That would really need a little bit of research and modeling. What could be uniform would be the method to arrive at thresholds.

If it becomes well known that registrations above some threshold will be treated as problematic, the bad guys will simply clone themselves and register no more than n domains under each identity.

Point taken Reg, I guess what I mean is more that there is some harmonization of standards/criteria

Steve - also a fair point

+1 Steve.

But Reg’s 100% correct

Gabriel, I’m not sure we even have data on that and amn’t sure how to acquire it but it would be interesting to look into (in terms of what types and sizes of bulk registrations we see)

Agree that gaming will be tough to address here, bad actors will adjust practices to circumvent bulk registration flags... still worth thinking about how to make it harder for them tho, IMO

Griffin - without disrupting legitimate business

@Reg, Michele, Gabriel, Brian K: could we get a small, informal working group together to discuss this issue of bulk registrations? We could look to thresholds and parameters, deviations, how parameters can be applied (e.g., only with respect to individual purchases at a particular time or by account holder--as Reg identified). Not talking about a PDP, rather just a conversation to try to move things forward.

Yes, making things harder is key; you cannot block it all. However, making it harder for baddies, and easier for defenders will go a long way.

On the question of defining “bulk” registrations, unless a registrar (or reseller) is conspiring with or completely oblivious, malicious actors registering large numbers of domains, then the typical threat model is a new customer scenario rather than an existing customer. One caveat to that would be an account compromise scenario, but then again, tracking unusual purchase patterns by long-term customers is something I would expect registrars to track to detect account take-overs.

+1 Michele

Steve is absolutely right about gaming. I am reminded of certain limits on cash deposits which - if exceeded - elicit reporting to authorities. I'm not going to say what they are, but many criminals are bloody well aware of them. And yet.... they're still useful in combatting fraud.

Dean I’m fine with the principle but I need to do some research about data gathering to see if it’s worth me joining because if I haven’t any data it likely wouldn’t be fruitful

I agree with that - safeguards is key

E.g. if there were a method to calculate thresholds and heuristics to spot suspicious (bulk) registrations, functional tooling that aids reporters and report-receivers with issues, and 2-3 more, … the complications faced by criminals go up, while the pipelines of anti abuse become less clogged.

@Dean I’m happy to discuss legitimate bulk needs. I’d like to know more about the illegitimate bulk problem too

Just because security measures can be circumvented does not mean that you do away with the security measure or not add new ones in place. There is hardly any security measure that CANNOT be circumvented.

Agree Vivek

+1 Gabriel. These still help, and if they are “soft” locks and “unsharp”, it is harder to avoid them. Particularly if the algorithms are tuned over time.

+1 Vivek.

to Brian’s point, I’d also like to know more about the “illegitimate bulk problem”, too, as it’s something I HEAR about an awful lot but haven’t ever seen any data around it

+1 Griffin. Steve is surely right that criminals and bad actors will work to get around rules and guidelines concerning bulk registrations, just like they will use stolen IDs to try to get around KYC. But again the perfect shouldn't be the enemy of the good. If these measures help reduce abuse or put some obstacles in the ways of criminals or requires them to take more time and undertake more efforts, that seems to be a win for all.

The aim should not be to eliminate DNS Abuse, because then we will not do anything. The aim should be to keep on improving on our efforts and see a steady decline in DNS abuse over time.

Well said Dean, even if it's some kind of flag that triggers a second layer of review of the registrant/registrations by the Rr, or additional questions or something

+1 Vivek. We need to make measurable progress over time. Steadily.

we should have a goal of making DNS abuse unprofitable....

@Reg - w/o wanting to annoy you, I will note Interisle published data on "Bulk Registration and Contact Information Access" on 17 Oct 2019. I just happen to be redoing my binders of reporting right now.

As I noted earlier, I think some Rr (maybe mostly on ccTLD side) already do this, so we know some practices here are commercially feasible

Thanks for sharing, Gabriel. I need to brush up on that too.

+1 Vivek.

+1 Gabriel - I was going to mention the Interisle data on this too

+1 Vivek

Dave Piscitello, Blog Post, “Weaponizing Domain Names: how bulk registration aids global spam campaigns,” Spamhaus (March 31, 2020), https://www.spamhaus.org/news/article/795/weaponizing-domain-names-how-bulk-registration-aids-global-spam-campaigns

I’ll take a second look, Gabriel, but I noted significant concerns with their prior data compilations, making it difficult to take them seriously

The Interisle “report” doesn’t actually define bulk

On gaming in large-scale malicious registration scenarios - well, at least make them play the game. Increasing friction for bad guys that doesn’t impact legitimate customers is a win. Once you put bad actors into a position they have to work harder, that’s already a win. From there, there typically are patterns to the game being played that can be used to flag the gamers. Getting to a place where those techniques are well understood is a longer-term goal. Pretty standard stuff though in dealing with abuse and crime in any field.

Shuang Hao et. al. “Understanding the Domain Registration Behavior of Spammers” ACM (2013)

+ 1 Vivek; it seens that the argument of ‘it can be circumvented sonehow’ is an essy excuse to do norhing at all

@Michele - they may be able to clarify how they measured that

Totally agree with Stewart and Roman. If the community doesn't get involved effectively against DNS abuse, governments will be tempted to regulate more and this regulation may be harmful for DNS players.An example (probably among others to come): https://www.quad9.net/news/blog/quad9-and-sony-music-german-injunction-status

@Michele You may be correct... scanning I don't yet see it defined... yet I do see screenshots of certain registrar offerings which the registrar itself is offering "Bulk Domain Name Search" ….

Gabriel a lot us offer a bulk search

so fuzzy it may be, it is a term in use.

but if you want us to stop doing it we need to know what the hell “it” is

Olivier, if the community shows that it is doing things and doing them well, more independence will be possible over time, even if they would limit the community initially.

@MIchele - Does your registrar offer a bulk search tool? If so, presumably you could identify the parameters; if not, others who do offer one could probably identify the parameters, which I think would be very helpful

(as part of our data gathering / conversations around this)

Reseller information is generally still public in the whois.

+1 Roman - cross-domain correlation is so critical

The point that governments might start trying to have a heavier hand in these matters if we don't self-regulate better is an important one. That's how the endless WHOIS battle ended, wasn't it...

@Mark D - not sure it's ended lol...

Discussion about DGA, vetting new registrations, taking note of bulk registrations, etc. are all variations on the idea of assigning some sort of trustworthiness attribute to a domain name. I think this is a sensible idea, but I think it requires some additonal infrastructure. The existing DNS and existing system of registration via registrars and registries is not designed to do this. This is worth a discussion that looks at this from a clean sheet perspective. Once there is clarity as to what a really good solution would look like in principle, it may not be terribly hard to develop operational systems that implement the concept. But if we focus only on how to implement pieces of a solution within the existing infrastructure,. the results will continue to be weak.

But point taken

Half-ended shall we say

the Interisle report alternately calls out “hundreds”, “5000”, and “hundreds of thousands” of domains as “bulk”—and encourages defining a “bulk registrant" but doesn’t offer a definition

+1 Steve

I have to go .. thanks for the discussion

Well, can you blame the governments? If they are being told / find that abuse is a problem, their reaction will be to regulate. Not taking a side on if that is good or bad but that is what they do, what they are expected to do…

@Steve Crocker--would you be willing to join an informal group to discuss? I think that would be very helpful.

@Laurin, I think governments are actually late to the party, and I'm concerned what will happen when they really show up.

It would be good to separate “bulk search” from “bulk registration”. Lots of really useful scenarios for bulk search to find that perfect domain or small set of domains you may be interested in for branding, marketing campaigns, etc. It’s turning that into a large-scale “click to register” option where you are above a threshold level (as discussed above) that you have a tool that enables certain types of abuse.

I know we are focusing now on the bulk issue, but ultimately I think it's important not to lose the forest for the trees, which is to say, regardless of how we define abuse or bulk, we ought to agree that more should be done to mitigate and respond to abuse based on the activity itself rather than the vehicle or hitting a certain threshold etc

@Dean Marks: Yes.

I think Cristine has had her had up for a while

Many thanks Steve!

Steve, +1. These issues have to be looked at on a fundamental level and from the ground up, to some extent technology neutrally. The DNS is serving in so many ways today, many of which were not a thing just a few years back.

Ctd. As noted by your thoughtful post, slapping even more “on top” might be challenging, or it might indeed work out after a clean sheet look at the issues.

@Mark, agreed. A lot can go wrong here, including by mistake.

My hope would be that our discussion group will be a collaborative brainstorming. Not an effort to point fingers or blame, etc. at anyone. Frankly, I think Michele is spot on in being frustrated about "bulk registration" when there really isn't much of a definition of that term.

@Cristine Interesting point.

As someone who is responsible for running a ccTLD registry, please keep me in the loop re: proposed discussion group.

Good point Cristine…the usability aspects

And that Brian K is correct that legitimate actors may have a solid reason for registering dozens and perhaps hundreds of domain names at one time.

+1 Christine - CDNs/pass-through proxies are a huge hurdle in the anti-abuse workflow

@Stephen There is no general community process to discuss these matters at the moment. We have siloed smaller groups, and the CPs are, correct me if I am wrong, concentrated around the DNS Abuse Institute.

Thank you Stephen D. Sorry for being so ignorant--what ccTLD do you work for?

.AS (America Samoa)

Thanks Stephen and please excuse my ignorance.

@ICANN Staff this chat is very productive and has great insights. Zoom doesn't allow us to export it from the attendee side. Could it be provided at the end of the session?

+1 Cristine! Yes indeed current ML/AI solutions are indeed English language focused which limits addressing global issues.

+1 Mark

@Mark: NP.

+1 Cristine about the avalanche of false positives

+1

+1 Graeme

+1 Graeme. Eager for a fresh start on productive collaboration rather than slinging dirt at each other. :-)

Agree with the point that there needs to be more and better cooperation between Rr/Ry and hosting sides; while I know technical DNS operators are loathe to discuss the C word (content) the fact is that abuse like phishing and malware utilize DNS resources but also propagate content (web, email etc) to accomplish the harm, so they can't be kept siloed from an anti-abuse perspective

+1 Griffin

+1000 Stewart

how many strikes before someone gets kicked off the internet?

I get that it's not appealing to do blacklists or something like that, but surely there's a middle ground between that and the need to get 50 court orders against the same registrant

@Reg - perhaps this goes back to our discussion of risk buckets. 1 strike alone is sufficient for additional Authentication of ID.

I can get in on that argument to a certain extent Griffin, but it gets murky very quickly when you are asking registrars to take action on content located on a web site.

It would be good if we can find approaches to proactivity in the abuse mitigation approaches. Right now, it's very much whack-a-mole. This is an intelligent, cooperative community. There are paths to follow, I'm sure.

@Gabriel - Or at least a heightened abuse response where additional domains are reported for the same registrant/activity following an initial action by a registrar etc;

(quasi trusted notifier sort of thing... ish)

It’s on my list Mason, hope to get to preventative work next year

I assume he’s talking about ccTLDs

not gTLDs

the opposite of a trusted notifier: an untrusted customer?

Let's pitch in together on that, Graeme

For proactive measures on the registry side, we’ve found some real success with the Quality Performance Index program as far creating an environment where abuse is less likely to occur - www.qpi.org

@Ashley - totally hear you, I just think there needs to be better collab/coord b/w Rr and hosts so that obvious abuse doesn't slip through the cracks

+1 Maciej regarding anecdotes

@Reg - I love the idea of the untrusted customer :)

Why does that need to be the registrars responsibility? It's a problem for sure... but we aren't the problem.

Responding to Griffin. :-)

Rather than "untrusted customer", I like "Risk Based Categorization", a term stolen from .dk. Less.... derogatory? Alas.

@Brian C--does qpi deal at all with the issue of "bulk registration"?

@Ashley - in an ideal world the host would deal with it, but sadly hosts are often very unresponsive and often times may actively be aiding/abetting; while I agree it would be preferable not to have to involve the registrar at all, you are in a position to help for domains where the clear sole use is for malware, phishing or other clear-cut abuse (not wading into other forms of abuse, which I agree may be less clear-cut)

"untrusted customer" sounds like making everybody a suspect by default again.

(and I agree that registrars are not "the problem" generally but can be part of the solution)

Sure Griff... where we can and it makes sense. But I don't see why registrars would need to take responsibility in collaborating with web hosts as you indicated earlier.

@Dean only insofar as abuse rates is the #1 gating factor in QPI. So if a RR has a high abuse rate as a result of abuse associated with bulk registrations, they wouldn’t pass. But bulk registration is not a standalone factor

Unless we are the web host. :-)

+1 Graeme

@Ashley - I hear you, just mean that there may be room for more dialogue and bringing hosts into the discussion too (wasn't suggesting like case-by-case interaction b/w Rr and host)

+2 Graeme

+1 Graeme

+100 Graeme

+1 Graeme

Graeme, we have pushed and you have pushed back every time.

good insights and well said

@Mary Wong, sorry to repeat myself, but can we have access to the chat in text form after the session?

@Brian C--thanks. To the extent you or any of your colleagues at PIR have some thoughts on bulk registration, please let me know if you or colleagues would like to join an informal conversation.

Hahahaha Graeme, come respond to Goran :on pushback )

@June LOL

+1 Graeme on enforcement of contracts

@June :)

@BrianC: has PIR recently (ever) laid out in a presentation their learning points from QPI? What worked, what didn't, what impact on abusive behavior was observed?

@Goran push harder. Terminate and/or sue a registrar for breach when they don’t suspend a phishing domain.

This is not a compliance problem, I agree with the ambiguity in the contract.

Please :-)

@Gabe - haven’t presented on it recently, but keep an information page including some success metrics on www.qpi.org

@Ashley, Griffin — many actors in many industries have requirements to deal with issues such as this, where they aren’t the reason for abuse but need to address it as part of doing business. Obviously, this does not mean that one has to be perfect but that some processes need to be in place to address them. As before, perfection won’t happen obviously but things will be harder for “baddies”. Obviously, I again recognize that this will cost money, and is thus a difficult choice for actors in a space where others do not have to have similar controls.

Brian - you do know I’m just going to report youtube.com now

+1 Brian. @Goran--give it try instead of hiding behind the feared ambiguity.

@Michele- report Facebook.com too. I see a lot of phishing on that site

+1 Jonathan particularly re automation

Take the example that it took us 2 years to take cancel a contract who never paid their bills due to the way policies are set.

@Göran it would be good if staff could lay out a roadmap for the community to be able to change those policies.

+1 Laurin... and I wasn't even intended to go that far, just really wanted to agree with an earlier point (I think from Graeme) re widening the tent so we aren't having conversations in our silos, instead a broader discussion across the ecosystem that includes Ry/Rr, hosts etc

often times more important than “hosts” are the transport dispatchers (a.k.a. DDoS protection providers) who are technically real intermediaries - contrary to registries and registrars

@Goran--but you did succeed in cancelling a contract for failure to pay a bill. How about giving it a try to cancel a contract for failure to abide by other obligations set forth in the contract?

Dean, I don’t agree with that remark

Graeme, thanks for your remarks about ambiguity in contracts and the importance of vigorous compliance. Of course, ensuring contracts have clear and enforceable obligations is also important.

+1

+1 Laureen

Thanks everyone, this was great! See you in 'Seattle'

Hello everyone, we’ve noted the requests to provide the chat pod following this call. We will follow up - thank you all!

Very informative and interesting session, appreciate your professional and respectful interaction. Stay safe and be kind.

Thanks Mary

In the MS model, the community set the rules. To claim that the compliance is the problem is a way to take away the discussion from the community

@Mark, Göran — it would be helpful to figure that out. Furthermore, you often do not need to do the “thing”, the risk of it happening is enough for most.

ICANN’s primary mission is to ensure the stable and secure operation of the Internet's unique identifier systems, but as expressly stated in its bylaws, ICANN “shall not regulate (i.e., impose rules and restrictions on) services that use the Internet's unique identifiers or the content that such services carry or provide, outside the express scope of Section 1.1(a).” As such, ICANN’s role is important, but limited, when considering the full range of possible definitions of “DNS Abuse."

+1 Laureen. @Goran--I appreciate you don't agree, but it is important to hear from the community.

@Gotan Compliance tackling abuse is different to unpaid bills. But at least it would highlight which players are under scrutiny and see how they respond.

An excellent conversation - thanks panellists and all

Thank you for this panel.And now Graeme will play the guitar.

+1 Laureen, enforcement is needed and important particularly for those who want to do well.

Great comments in the chat too. thanks

Laurin and Griff... agree... but I'm also sensitive that many folks seem to think this is a Registrar's problem to solve when it is not. I'm trying to get to the bottom of why we are the goat to be whipped in all cases. :-)

@Mary Wong, tahnk you

@the Board--many thanks for putting together this excellent panel and discussion.

Thanks all

Dean, we will of course act when the community agrees

Thank you panelists and all