[gnso-rds-pdp-wg] Contactability

Wed Nov 29 16:23:13 UTC 2017

Hi Bastiaan,

>>A question though. I understand how ’TLD blocking’ would work as an
effective albeit sledge hammer way of mitigating certain forms of spam. And
I get the concept of blocking all traffic coming from particular
hosting-providers, ignoring cases where spoofing of prefixes is involved.
But what exactly is ‘registrar level blocking’?

>>The example you refer to is (also) a hosting/cloud-provider - but if that
were not the case, what can ‘blocked’ purely looking at the registrar
service provided?

"registrar level blocking" isn't a feature that's available to most e-mail
inbox owners because it is a lot more complicated than writing a wildcard
for example *.xyz for an entire TLD. It would probably require a multi step
process of WHOIS querying the domain -> parse for registrar -> check block
lists. I'm unsure how the large operators do it exactly.

But if you look at this page:

https://www.spamhaus.org/statistics/registrars/

you can see a list of which registrars feature most prominently in spam.
Registrars that get to the point have a business model where they profit
from these types of customers. Alpnames in particular was in the news
because leaked communications revealed they were aware of the spamming and
offered to not suspend the domains for abuse. A bulletproof registrar, if
you will. Despite this incident, and despite being on the Spamhaus list of
"worst registrars" months later, they are still an actual registrar
accredited by ICANN. An equally valid participant in the DNS as any of you
here.

And that is barely scratching the surface.

So you can also see how the desire to block an entire registrar's
customerbase is directly linked to ICANN's failure to decertify the
registrar.

Compare this "not my problem" attitude to the attitude that the Google
Chrome team has towards its list of trusted certificate providers. They
have no qualms about giving the death penalty to abusers. Google is also
requiring companies to produce "certificate transparency" logs, a real time
feed of all the certs they sign, and who they are for. Instead of wringing
their hands about privacy solely on the website owner's side, they
understand that these are tools massively used for abuse and actually take
into account the rights of people being abused by these tools.

As a result of these differing attitudes, the Chrome browser enjoys a lot
of public trust, with almost no demand for custom trust lists, and ICANN's
naming system loses legitimacy every day as the collective masses of the
Internet increasingly turn their backs on them.

On Wed, Nov 29, 2017 at 2:36 AM, Bastiaan Goslings <
bastiaan.goslings at ams-ix.net> wrote:

> Thanks, Allison:
>
> > On 28 Nov 2017, at 22:30, allison nixon <elsakoo at gmail.com> wrote:
> >
> > I do not believe it is off topic to consider the downstream implications
> of the actions we take. It is of critical importance!
> >
> > When the WHOIS for .amsterdam and .frl became largely obfuscated, I was
> not worried much about it, because the extremely high cost of those domains
> precluded abuse from them in the first place. For that reason, nothing
> happened.
> >
> > In the defender world, if we lose WHOIS as a reputation factor, other
> reputation factors become much more prominent. TLD blocking is very easy
> with the tools we already have, but with the loss of WHOIS we are going to
> see a strong upsurge in the demand for registrar level blocking. So, say
> Alpnames is spamming a lot of people, and as an owner of an e-mail inbox, I
> don't want to get any more e-mails from Alpnames customers. Multiple of my
> colleagues at large networks have revealed to me that in the past, they
> have done a registrar level block, and the economic pressure on the
> registrars caused them to clean up their act with an impressive amount of
> motivation. It's something that most tools don't currently support, but
> likely will in the future.
> >
> > If the registrars will be the only people who have any clue who their
> customers are, I think we will see a strong shift towards forcing those
> registrars to take more responsibility for their pollution. This is
> something I am seeing increasingly advocated in defender circles, so
> outsiders are likely going to see the results of this in upcoming years.
> >
> > With the direction I see things going, I believe that anti-abuse will
> involve imposing economic pressure on registrars. It's not unlike how
> notorious hosting providers have been de-peered in the past due to abuse,
> and there is a lot of legal precedent to support the legitimacy of this
> strategy.
> >
> > Also, many of us outside the ICANN community don't see the death of the
> new TLDs as a bad thing. More people are interested in blocking them than
> supporting them. Companies are also realizing that it isn't a good idea to
> run their businesses on new TLDs.  Some of us will cheer when they finally
> go away.
>
>
> Without any specific knowledge of the industry, your line of reasoning
> makes sense to me, i.e. ‘If the registrars will be the only people who have
> any clue who their customers are, I think we will see a strong shift
> towards forcing those registrars to take more responsibility’ as well as
> the ‘anti-abuse will involve imposing economic pressure on registrars’.
>
> (Fyi I will not comment on the ’their pollution’)
>
> A question though. I understand how ’TLD blocking’ would work as an
> effective albeit sledge hammer way of mitigating certain forms of spam. And
> I get the concept of blocking all traffic coming from particular
> hosting-providers, ignoring cases where spoofing of prefixes is involved.
> But what exactly is ‘registrar level blocking’?
>
> The example you refer to is (also) a hosting/cloud-provider - but if that
> were not the case, what can ‘blocked’ purely looking at the registrar
> service provided?
>
> -Bastiaan
>
>
>
> >
> >
> > On Tue, Nov 28, 2017 at 3:11 PM, theo geurts <gtheo at xs4all.nl> wrote:
> > Agreed Kris,
> >
> > Thanks, Allison, though this is, I guess, the cold hard truth, selling
> domains dirt cheap or giving them away is a sure method to poison a TLD, I
> think it is a separate issue when discussing RDS.
> >
> > And the examples are clear, and at a point, such TLD operators need to
> re-think their business model and act accordingly to keep their TLD alive.
> >
> > So in May 2018, we will see a lot of use of the privacy services due to
> the GDPR, I guess mostly at a Registrar level, but let's not rule out that
> it might be on a Registry level, the dynamics here are shifting day by day.
> > So my question here, and I hope we can discuss this in good faith, but
> it seems to me that the WHOIS will be an irrelevant factor when it comes to
> the risk/reputation score?
> > How does/will that play out?
> > And yes, this is not exactly related to our work when it comes to RDS,
> but since we have the expertise here, I think it would be useful to explore
> this a little more even though off topic. I hope the leadership team allows
> this to get a better understanding, for the community on what is going down
> and might happen in a just a few months here.
> > And if we need to do this offlist, sure, no problem. I am just trying to
> get a sense to here to comply with the law and keep a business running.
> >
> >
> > Thanks
> >
> > Theo
> >
> >
> > On 28-11-2017 20:57, John Bambenek via gnso-rds-pdp-wg wrote:
> >> Full agreement on this point
> >>
> >> On 11/28/2017 01:30 PM, Kris Seeburn wrote:
> >>> As we move on …one way or the other the GDPR and other aligned privacy
> laws will catch up eventually. We will need to find levels and technical
> ways and reasons to get things to work. We move to RDAPis fine as we look
> ahead but we should be able to not only look at the laws that we need to
> respect but also to find technical ways to get and make sure things still
> continue towork. As this stage personally both are as important.
> >>>
> >>>> On Nov 28, 2017, at 23:15, allison nixon <elsakoo at gmail.com> wrote:
> >>>>
> >>>> Most systems operators are not afraid to block entire TLDs. While
> there are no scientific studies out on this matter AFAIK, the help forums
> are littered with people asking how to block entire TLDs, and also
> registrants on those TLDs asking why everyone is blocking them. It's enough
> to conclusively say this is already an issue, and we can thank abuse for
> this.
> >>>>
> >>>> In this Reddit post, a user learns the hard truth about his brand new
> XYZ domain:
> >>>> https://www.reddit.com/r/webdev/comments/6jq6f5/
> getting_blocked_should_i_abandon_my_xyz_domain/
> >>>>
> >>>> This article discusses Facebook's block of all XYZ domains:
> >>>> http://adamyamada.com/facebook-blocks-xyz-domains-new-domains-pages/
> >>>>
> >>>> This Malwarebytes staff member explains to a legitimate registrant
> that all .SCIENCE TLDs are blocked and he gets no exception:
> >>>> https://forums.malwarebytes.com/topic/173535-all-my-
> science-domains-blocked/
> >>>>
> >>>> In fact, the Malwarebytes "false positive" forum is littered with
> owners of hacked domains that discovered their problem because of a block,
> not because of a notification:
> >>>> https://forums.malwarebytes.com/forum/123-website-blocking/
> >>>>
> >>>> This user asks for an 'Existing list of garbage "new" TLDs' to block
> >>>> https://vamsoft.com/forum/topic/597/existing-list-of-garbage-new-tlds
> >>>>
> >>>> There are 179 Google search results for people asking Microsoft's
> help service for ways to block entire TLDs:
> >>>> https://www.google.com/search?q=how+do+i+block+TLD+site:
> answers.microsoft.com
> >>>>
> >>>> There are 72,500 Google search results for "how to block" "tld":
> >>>> https://www.google.com/search?q=%22how+to+block%22+%22tld%22
> >>>>
> >>>> The Internet is effectively "broken" for any legitimate registrants
> on these TLDs.
> >>>>
> >>>> As a seller of some of those same TLDs, should you be concerned if
> your customers purchase domains rendered useless due to blocking?
> >>>> Would you actually refund a customer if they told you they couldn't
> use the domain for e-mail due to the TLD?
> >>>> Would you warn your prospective .XYZ, .STUDY, .PRESS, .PARTY, etc,
> customers that they should not use the domains for e-mail?
> >>>> When ICANN releases new gTLDs in the future, do you think that those
> domains will ever be able to send e-mail?
> >>>>
> >>>> Truly, the rest of the world will be fine. The more that ICANN has
> the "not my problem" attitude, the more the rest of the world is going to
> push back. ICANN seems to have lost the ability to release new gTLDs
> without severe connectivity issues, so we also need to ask the question:
> "why are these guys selling the digital equivalent of the scarlet letter
> and not warning their customers beforehand?"
> >>>>
> >>>> I think the question of selling defective products is one that needs
> to be addressed more seriously by regulators and outside parties.
> >>>>
> >>>> I can also tell you that security vendors are already looking into
> other anti-abuse techniques for domains post-WHOIS, and I can also tell you
> that they will result in an increase in the percentage of legitimate
> domains that are blocked. This is your problem now.
> >>>>
> >>>>
> >>>> On Tue, Nov 28, 2017 at 12:43 PM, Volker Greimann <
> vgreimann at key-systems.net> wrote:
> >>>> Hi Andrew,
> >>>>
> >>>> re:hotbed I was rather intending to ask whether there is a direct
> correllation between TLDs with redacted whois and issues that go
> unresolved. So do you have more unresolved issues in .co.uk than in .com
> (if numbers are normalized for registered domain names).
> >>>>
> >>>> I am sure no one would consider blocking the entire mail traffic
> originating from the United Kingdom Top Level Domain just because you
> cannot resolve some issues in a few domains, correct?
> >>>>
> >>>> So if everyone followed their (or a similar) model, the internet
> would not break. Some issues would get harder to solve (or take longer). I
> am asking because that is what most likely will happen on May 25 or sooner.
> >>>>
> >>>> Volker
> >>>>
> >>>>
> >>>>
> >>>> Am 28.11.2017 um 18:27 schrieb Andrew Sullivan:
> >>>> On Tue, Nov 28, 2017 at 04:31:56PM +0100, Volker Greimann wrote:
> >>>> case of internet operability issues. While I appreciate that there
> can be
> >>>> issues that would necessitate the ability to quickly contact whoever
> can fix
> >>>> the issue, I wonder how this problem is solved in TLDs where whois is
> >>>> already redacted.
> >>>> It's not.  In that case, if I am the one who has this experience and I
> >>>> can't reach the target, then the problem goes unresolved.  In mail
> >>>> cases, as John suggests elsewhere in this thread, the answer is very
> >>>> likely that mail is blocked.  People seem surprised these days that
> >>>> mail is so fragile, but this sort of thing is part of the reason.
> >>>>
> >>>> So how does it work there? Are these TLDs hotbeds of DNS issues and
> >>>> unresolved problems?
> >>>> I don't know what you mean by "hotbed", or whether that is intended to
> >>>> be dismissive.  Some TLDs defintely have more DNS problems than
> >>>> others.  Given how hard the DNS works to make connections happen even
> >>>> when things are badly misconfigured, lots of stuff will work to some
> >>>> extent even when it is badly configured.  But DNS operations people
> >>>> trade stories about problems amongst themselves, after giving up on
> >>>> sites because whois can't help and the mname in the SOA record is
> >>>> broken.  I find this happens more often than you might expect.
> >>>>
> >>>> But yes, there are broken domains on the Internet.  I find it hard to
> >>>> believe that would be even slightly remarkable.
> >>>>
> >>>> Best regards,
> >>>>
> >>>> A
> >>>>
> >>>>
> >>>> --
> >>>> Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
> >>>>
> >>>> Mit freundlichen Grüßen,
> >>>>
> >>>> Volker A. Greimann
> >>>> - Rechtsabteilung -
> >>>>
> >>>> Key-Systems GmbH
> >>>> Im Oberen Werk 1
> >>>> 66386 St. Ingbert
> >>>> Tel.: +49 (0) 6894 - 9396 901
> >>>> Fax.: +49 (0) 6894 - 9396 851
> >>>> Email: vgreimann at key-systems.net
> >>>>
> >>>> Web: www.key-systems.net / www.RRPproxy.net
> >>>> www.domaindiscount24.com / www.BrandShelter.com
> >>>>
> >>>> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
> >>>> www.facebook.com/KeySystems
> >>>> www.twitter.com/key_systems
> >>>>
> >>>> Geschäftsführer: Alexander Siffrin
> >>>> Handelsregister Nr.: HR B 18835 - Saarbruecken
> >>>> Umsatzsteuer ID.: DE211006534
> >>>>
> >>>> Member of the KEYDRIVE GROUP
> >>>> www.keydrive.lu
> >>>>
> >>>> Der Inhalt dieser Nachricht ist vertraulich und nur für den
> angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe,
> Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist
> unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten
> wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
> >>>>
> >>>> --------------------------------------------
> >>>>
> >>>> Should you have any further questions, please do not hesitate to
> contact us.
> >>>>
> >>>> Best regards,
> >>>>
> >>>> Volker A. Greimann
> >>>> - legal department -
> >>>>
> >>>> Key-Systems GmbH
> >>>> Im Oberen Werk 1
> >>>> 66386 St. Ingbert
> >>>> Tel.: +49 (0) 6894 - 9396 901
> >>>> Fax.: +49 (0) 6894 - 9396 851
> >>>> Email: vgreimann at key-systems.net
> >>>>
> >>>> Web: www.key-systems.net / www.RRPproxy.net
> >>>> www.domaindiscount24.com / www.BrandShelter.com
> >>>>
> >>>> Follow us on Twitter or join our fan community on Facebook and stay
> updated:
> >>>> www.facebook.com/KeySystems
> >>>> www.twitter.com/key_systems
> >>>>
> >>>> CEO: Alexander Siffrin
> >>>> Registration No.: HR B 18835 - Saarbruecken
> >>>> V.A.T. ID.: DE211006534
> >>>>
> >>>> Member of the KEYDRIVE GROUP
> >>>> www.keydrive.lu
> >>>>
> >>>> This e-mail and its attachments is intended only for the person to
> whom it is addressed. Furthermore it is not permitted to publish any
> content of this email. You must not use, disclose, copy, print or rely on
> this e-mail. If an addressing or transmission error has misdirected this
> e-mail, kindly notify the author by replying to this e-mail or contacting
> us by telephone.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> gnso-rds-pdp-wg mailing list
> >>>> gnso-rds-pdp-wg at icann.org
> >>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> _________________________________
> >>>> Note to self: Pillage BEFORE burning.
> >>>> _______________________________________________
> >>>> gnso-rds-pdp-wg mailing list
> >>>> gnso-rds-pdp-wg at icann.org
> >>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Kris Seeburn
> >>> seeburn.k at gmail.com
> >>>     • www.linkedin.com/in/kseeburn/
> >>>
> >>> <KeepItOn_Social_animated.gif>
> >>>
> >>>
> >>>
> >>> ______________________________
> >>> _________________
> >>> gnso-rds-pdp-wg mailing list
> >>>
> >>> gnso-rds-pdp-wg at icann.org
> >>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
> >>
> >>
> >>
> >> ______________________________
> >> _________________
> >> gnso-rds-pdp-wg mailing list
> >>
> >> gnso-rds-pdp-wg at icann.org
> >> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
> >
> >
> > _______________________________________________
> > gnso-rds-pdp-wg mailing list
> > gnso-rds-pdp-wg at icann.org
> > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
> >
> >
> >
> > --
> > _________________________________
> > Note to self: Pillage BEFORE burning.
> > _______________________________________________
> > gnso-rds-pdp-wg mailing list
> > gnso-rds-pdp-wg at icann.org
> > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
>

-- 
_________________________________
Note to self: Pillage BEFORE burning.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20171129/5e0448d7/attachment-0001.html>