<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>In order to avoid reading the actual text (yes, I am lazy) what
is the definition of "DNS security abuse"?</p>
<p>The reason I ask is that I've seen the phrase "DNS abuse" (absent
the word "security") tossed about to whine (yes I am being
hyperbolic and pejorative) about things such as "this or that
practice annoys my cat" or "go to website abc.def.tld and buy
solid gold 1kg bars for $1 each." The first is simply out of
ICANN's scope and the second probably violates
fraud/misrepresentation laws in pretty much every country and
ought to be beyond ICANN's scope. I would put anything that is
covered by national and international trademark law outside the
umbra or penumbra of the word "security".<br>
</p>
<p>On the other hand it would, to my mind, be quite within ICANN's
scope to knock registr* bodies and TLD server operators if they do
bad things, like leaving logins open via telnet (clear text
passwords) or are running on easily penetrated foundations such as
(let me pick a crazy example) Windows 95.<br>
</p>
<p> --karl--<br>
</p>
<div class="moz-cite-prefix">On 9/15/23 10:58 AM, Carlton Samuels
via At-Large wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAOZQb9TjEXtfvegSo5QDnuTQoXKTupUJ9DuMm1ov-M3F6Why6g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default"
style="font-family:tahoma,sans-serif">If you missed it,
after a year in pending status, the ICANN Board just voted
to reject Recs 14 & 15 from the CCT Review. These were
offered for mitigating systemic DNS <b><u>security</u></b>
abuse. </div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"> </div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">#14 recommends
amendments offering incentives - inclusive of financial ones
- in<span style="font-family:Arial,Helvetica,sans-serif"> the
[RA/RAA] Agreements for the contracted parties adopting p</span><span
style="font-family:Arial,Helvetica,sans-serif">roactive
anti-abuse measures. Nothing too heretical. </span></div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">#15 recommends
amendments to [RA/RAA] Agreements that establish <span
style="font-family:Arial,Helvetica,sans-serif">thresholds
of abuse at which compliance inquiries are automatically </span><span
style="font-family:Arial,Helvetica,sans-serif">triggered
and a higher one at which registrars and registries are
presumed </span><span
style="font-family:Arial,Helvetica,sans-serif">to be in
default of their agreements. </span></div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><span
style="font-family:Arial,Helvetica,sans-serif"><br>
</span></div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><span
style="font-family:Arial,Helvetica,sans-serif">We went on
to recommend </span><span
style="font-family:Arial,Helvetica,sans-serif">a
community-developed DNS Abuse Dispute Resolution Policy
(DADRP) i</span><span
style="font-family:Arial,Helvetica,sans-serif">f ICANN
Compliance falls asleep on the enforcement job. [The text
delicately eased into that like only "...<i>i</i></span><i><span
style="font-family:Arial,Helvetica,sans-serif">f the
community determines that ICANN org </span><span
style="font-family:Arial,Helvetica,sans-serif">itself is
ill-suited or unable to enforce such provisions.</span></i><span
style="font-family:Arial,Helvetica,sans-serif">"]</span> </div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">In my own view #14 is
something regulators do with concessionaires time and again.
Even the "light touch and by suasion" telecoms ones I know
well in my home region. <br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">Our ICANN don't play
that!</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">Carlton </div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif;font-size:large"><span
style="font-family:Arial,Helvetica,sans-serif;font-size:small">==============================</span><br>
</div>
<div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div><i><font face="comic sans ms, sans-serif">Carlton
A Samuels</font></i><br>
<font face="comic sans ms, sans-serif"><i>Mobile:
876-818-1799<br>
<font color="#33CC00">Strategy, Process,
Governance, Assessment & Turnaround</font></i></font><br>
=============================</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, 14 Sept 2023 at
20:33, Barry Shein via At-Large <<a
href="mailto:at-large@atlarge-lists.icann.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">at-large@atlarge-lists.icann.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><br>
As a company which provides email and other internet
services maybe if<br>
the new gTLDs agreements included some serious commitment to
avoid<br>
allowing the use of these gTLDs for massive spamming and
phishing etc<br>
maybe the service providers would have been more
enthusiastic about<br>
acceptance.<br>
<br>
Unfortunately the opposite is true and many of these new
gTlDs can<br>
safely be blocked in entirety, they just spew spam etc, with
no<br>
customer complaints.<br>
<br>
I'll guess these new gTLD registrars/registries would
complain that's<br>
not equitable since it's not required of other TLDs.<br>
<br>
Which is all a very nice argument to make sitting in an
airless room<br>
somewhere.<br>
<br>
So instead they tend to get blocked and ignored, or at least
marked<br>
"suspicious" by spam filters, but equitably!<br>
<br>
If I had a nickel for every ISP who said or recommended "oh
just block<br>
all .pick-a-nGTLD, you and your customers will be
happier"...<br>
<br>
-- <br>
-Barry Shein<br>
<br>
Software Tool & Die | <a class="moz-txt-link-abbreviated" href="mailto:bzs@TheWorld.com">bzs@TheWorld.com</a> |
<a href="http://www.TheWorld.com" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://www.TheWorld.com</a><br>
Purveyors to the Trade | Voice: +1 617-STD-WRLD |
800-THE-WRLD<br>
The World: Since 1989 | A Public Information Utility | *oo*<br>
_______________________________________________<br>
At-Large mailing list<br>
<a href="mailto:At-Large@atlarge-lists.icann.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">At-Large@atlarge-lists.icann.org</a><br>
<a
href="https://atlarge-lists.icann.org/mailman/listinfo/at-large"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://atlarge-lists.icann.org/mailman/listinfo/at-large</a><br>
<br>
At-Large Official Site: <a href="http://atlarge.icann.org"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://atlarge.icann.org</a><br>
_______________________________________________<br>
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 (<a href="https://www.icann.org/privacy/policy"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.icann.org/privacy/policy</a>)
and the website Terms of Service (<a
href="https://www.icann.org/privacy/tos" rel="noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.icann.org/privacy/tos</a>).
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.<br>
</blockquote>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
At-Large mailing list
<a class="moz-txt-link-abbreviated" href="mailto:At-Large@atlarge-lists.icann.org">At-Large@atlarge-lists.icann.org</a>
<a class="moz-txt-link-freetext" href="https://atlarge-lists.icann.org/mailman/listinfo/at-large">https://atlarge-lists.icann.org/mailman/listinfo/at-large</a>
At-Large Official Site: <a class="moz-txt-link-freetext" href="http://atlarge.icann.org">http://atlarge.icann.org</a>
_______________________________________________
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 (<a class="moz-txt-link-freetext" href="https://www.icann.org/privacy/policy">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a class="moz-txt-link-freetext" href="https://www.icann.org/privacy/tos">https://www.icann.org/privacy/tos</a>). 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.</pre>
</blockquote>
</body>
</html>