<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1">
<TITLE>RE: [registrars] WG: [council] Fast Flux DNS</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText60247 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>You know, I have to say that
I am always surprised when Registrars within a country want their governments to
legislate something that puts them at a competitive disadvantage.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>I won't comment on the specifics of this
new legislation, but Registrants will quckly figure out which jurisdictions and
countries do not have crazy laws, and use Registrars in those
jurisdictions. </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>It baffles me that Registrars in any
country want laws that would apply to them, and not their competitors. We
operate in a global worldwide market. </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>I have often said that it is entirely
possible for a government to pass legislation that would make it impossible to
be a Registrar within their jurisdiction. Given that all Registrars
abide by the same contract with ICANN, I can certainly see a government passing
legislation that makes it impossible to abide by that contract, and as such,
would have the effect of putting the Registrar out of business. I know
that this has been a concern shared by Registrars in places that have a
restrictive privacy legislation that could effect their ability to meet whois
requirements in the future.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>To simply say that a Registrar can ignore
parts of their ICANN contract where a local law supersedes them is also not a
good idea. </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>We must be mindful of our governments
passing legislation and ensure they realize that ultimately they may be
jeopardizing an entire industry in their country. It is our job to ensure
they are educated as such. </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Rob.</FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> owner-registrars@gnso.icann.org on behalf
of Margie Milam<BR><B>Sent:</B> Thu 06/03/2008 1:19 PM<BR><B>To:</B>
john@johnberryhill.com<BR><B>Cc:</B>
registrars@gnso.icann.org<BR><B>Subject:</B> RE: [registrars] WG: [council] Fast
Flux DNS<BR></FONT><BR></DIV>
<DIV><BR>
<P><FONT size=2>John,<BR><BR>I don't know what "shenanigans" you refer to
because I recall the APWG<BR>was pretty helpful in the domain tasting working
group in issuing a<BR>report that stated that they generally did not see
phishers using domain<BR>tasting in domain based phishes. I can send you a
link to that report<BR>if you would like to see it.<BR><BR>The APWG is not
comprised of lawyers setting policy. The participants<BR>tend to be
technology types who deal with online fraud. For example,<BR>we are
a member and participate through our product managers and<BR>engineers that
design and operate our anti-phishing detection and take<BR>down solutions.
GoDaddy is also a member of the APWG. If registrars have<BR>technical objections
to their recommendations, I think ICANN is the<BR>right place to have this
discussion to make recommendations that help<BR>solve the problem and minimize
the impact to registrar operations. We<BR>have more control over the
solution if the policy comes out of the ICANN<BR>structure as opposed to another
forum.<BR> <BR>With respect to the Anti-Phishing Bill, currently it does
not deal with<BR>fast-flux issues, but it certainly could be amended to address
this<BR>problem. It includes WHOIS requirements, presumably because
of the<BR>problems and roadblocks imposed by registrars in accessing this data
in<BR>the past. If registrars continue to fight proposals to address
domain<BR>based phishes and continue to allow phishers to use their
registration<BR>systems as a means of accomplishing their activities, we should
expect<BR>that another solution, perhaps a legislative one, would be
pursued. I<BR>would think it is better for registrars to come up
with a solution<BR>through ICANN than to try to revise legislative initiatives
written by<BR>people that don't understand the registrar business.<BR><BR>I
disagree with you that the issue does not affect or involve the
domain<BR>business. The issue is a problem that can be addressed by
registrars<BR>because (i) preventing the domain name from resolving altogether
will<BR>effectively stop the phish, and (ii) for those registrars that
provide<BR>name server services, limiting the number of updates could reduce
the<BR>number of IP addresses that are utilized in a phish attack. I
would<BR>like to understand why this is so objectionable-- and what
registrars<BR>think would be a reasonable solution to this
problem. <BR><BR>Margie<BR><BR><BR><BR>-----Original
Message-----<BR>From: John Berryhill [<A
href="mailto:john@johnberryhill.com">mailto:john@johnberryhill.com</A>]<BR>Sent:
Wednesday, March 05, 2008 9:35 PM<BR>To: Margie Milam; 'Thomas Keller'; 'Ross
Rader'<BR>Cc: registrars@gnso.icann.org<BR>Subject: RE: [registrars] WG:
[council] Fast Flux DNS<BR><BR><BR><BR>>The Anti-Phishing Working Group has
been trying for years<BR>>to get registrars to conform to their best practice
approach. <BR><BR>Did you actually *read* the last report?<BR><BR>I sure
did. If recent comments about the AGP are any indication,
there<BR>are<BR>a whole lot of people who didn't.<BR><BR>While we were sitting
in the room in Delhi, and Paul Stahura was<BR>explaining<BR>how the AGP can be
used to run fraud profile tests and delete names that<BR>meet fraud profiles, I
was actually reading the APWG recommendation that<BR>registrars do precisely
that.<BR><BR>Now, over in the BCISPIP cross-constituency meeting, they
were<BR>discussing<BR>how use of the AGP for DOING just what the APWG was
recommending, was a<BR>"phony excuse" for keeping the AGP.<BR><BR>Sorry, but I
call shenanigans here.<BR><BR>Let's have a rational explanation as to why
elements of the GNSO are<BR>hell-bent on ELIMINATING use of one of the
mechanisms recommended by the<BR>Anti-Phishing working group.<BR><BR>Is there a
"ten words or less" explanation that anyone has, as to WHY<BR>the<BR>BCISPIP
folks DON'T want registrars to be able to implement the fraud<BR>profile and
domain deletion recommendations of the most recent
APWG<BR>report.<BR><BR>Because if there isn't, this is the wrong place to come
crying about<BR>just<BR>who is not interested in implementing the APWG
recommendations.<BR><BR>> As many of you may know, there is an anti-phishing
bill introduced by<BR>> Senator Snowe in the U.S. senate that, if enacted as
currently<BR>written,<BR>> would impose requirements on
registrars. <BR><BR>And the provisions of that bill relating to Fast Flux
DNS are where,<BR>exactly? The argument that an ineffective solution from
the GNSO will<BR>forestall an ineffective solution from elsewhere is simply
posturing.<BR><BR>I am convinced that too few people are capable of reading
and<BR>understanding<BR>either the SSAC or APWG reports.<BR><BR>The issue is not
"changing name servers" rapidly. The issue is changing<BR>IP<BR>resource
records and DNS records *IN* the nameservers rapidly. It is a<BR>DNS<BR>and
hosting issue, NOT a domain name registration issue.<BR><BR>Where this whole
discussion goes into stupid overdrive is that if you<BR>want<BR>to put a choke
on nameserver changes, then the choke point is at the<BR>REGISTRY. If you
believe that this issue relates to how quickly the<BR>designated nameservers are
changed, then you simply roll back to what we<BR>had<BR>a few years ago when you
had to wait a few hours for batch updates to<BR>the<BR>.com (or other TLD) zone
file.<BR><BR>I don't know if you know how any of this stuff works, but it is the
data<BR>in<BR>the TLD zone file that identifies the IP addresses of the name
servers<BR>in<BR>which DNS records can be found.<BR><BR>REGISTRARS DON'T RUN THE
ZONE SERVERS. Let those six words sink in for<BR>a<BR>few moments.
Anyone who does not understand the implications of those<BR>six<BR>words to this
issue is simply not qualified to participate.<BR><BR>Catering to a group of
lawyers who don't know how the internet works<BR>doesn't<BR>make sense.
People can have wonderful and interesting opinions about<BR>lots<BR>of
things. But if they want to participate in technical
coordinating<BR>tasks<BR>relevant to a global computer network, then having a
clue how that<BR>network<BR>actually works would be a great idea.<BR><BR>So,
let's re-cap the agenda:<BR><BR>1. The APWG wants registrars to be able to
delete domain names rapidly<BR>soon<BR>after registration if fraud is
detected. Much of the GNSO would like to<BR>eliminate that
capability.<BR><BR>2. There is a security issue arising, in part, from too
many changes<BR>being<BR>permitted to records in the TLD zone files maintained
by the REGISTRIES.<BR>Solving this problem is the responsibility of the
REGISTRARS.<BR><BR>3. Agreeing to an irrelevant and ineffective ICANN GNSO
proposal will<BR>prevent the US Government from doing silly things.<BR><BR>Hey,
here's a "best practice" - how about if the Telco's and ISP's quit<BR>shipping
everyone's phone and internet traffic to the US Government<BR>without<BR>a
warrant (even a retroactive warrant). Boy, it's a good thing we
don't<BR>have outfits like that proposing ICANN policy.<BR><BR>Oh, wait a
minute. We do!<BR><BR>We obviously need better lobbyists. ICANN
participants in the other<BR>constituencies can get their very own law that
permits them to engage in<BR>criminal activity with immunity, but we have to
pretend to be solving a<BR>problem by agreeing to a solution that won't solve
the problem, or we'll<BR>be<BR>in big
trouble.<BR><BR><BR><BR><BR></FONT></P></DIV>
</BODY>
</HTML>