ICANN/GNSO GNSO Email List Archives

[registrars]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [registrars] WG: [council] Fast Flux DNS

  • To: Rob Hall <rob@xxxxxxxxxxxxx>
  • Subject: RE: [registrars] WG: [council] Fast Flux DNS
  • From: Tim Ruiz <tim@xxxxxxxxxxx>
  • Date: Thu, 06 Mar 2008 16:09:55 -0700
  • Cc: registrars@xxxxxxxxxxxxxx, Margie Milam <Margie.Milam@xxxxxxxxxxxxxxx>, john@xxxxxxxxxxxxxxxxx
  • List-id: registrars@xxxxxxxxxxxxxx
  • Reply-to: Tim Ruiz <tim@xxxxxxxxxxx>
  • Sender: owner-registrars@xxxxxxxxxxxxxx
  • User-agent: Web-Based Email 4.12.23

Rob, couldn't agree more. Unfortunately, there was enough support on the
Council (even though both registries and registrars argued against it
and voted against it) to call for an Issues Report from ICANN.
Hopefully, the Staff seeks appropriate technical input and ultimately
sees that any policy from ICANN imposed on registrars just won't solve
the problem. 

For example, 38% of all domain name registrations in the world are with
ccTLDs and any GNSO policy won't touch them, and the ccNSO doesn't have
the authority to create consensus policy for ccTLDs. So I just don't see
the point. Ross is probably right, this needs to go down a standards
path. Ultimately we can't solve every problem through policy and
legislation. We also need to focus on consumer education. Buyer: beware;
be informed; and here are some tools to help you.


Tim 


-------- Original Message --------
Subject: RE: [registrars] WG: [council] Fast Flux DNS
From: "Rob Hall" <rob@xxxxxxxxxxxxx>
Date: Thu, March 06, 2008 4:12 pm
To: "Margie Milam" <Margie.Milam@xxxxxxxxxxxxxxx>,
<john@xxxxxxxxxxxxxxxxx>
Cc: <registrars@xxxxxxxxxxxxxx>

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.
 
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.  
 
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.  
 
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.
 
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.  
 
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.  
 
Rob.


From: owner-registrars@xxxxxxxxxxxxxx on behalf of Margie Milam
Sent: Thu 06/03/2008 1:19 PM
To: john@xxxxxxxxxxxxxxxxx
Cc: registrars@xxxxxxxxxxxxxx
Subject: RE: [registrars] WG: [council] Fast Flux DNS




John,

I don't know what "shenanigans" you refer to because I recall the APWG
was pretty helpful in the domain tasting working group in issuing a
report that stated that they generally did not see phishers using domain
tasting in domain based phishes.  I can send you a link to that report
if you would like to see it.

The APWG is not comprised of lawyers setting policy.   The participants
tend to be technology types who deal with online fraud.   For example,
we are a member and participate through our product managers and
engineers that design and operate our anti-phishing detection and take
down solutions. GoDaddy is also a member of the APWG. If registrars have
technical objections to their recommendations, I think ICANN is the
right place to have this discussion to make recommendations that help
solve the problem and minimize the impact to registrar operations.  We
have more control over the solution if the policy comes out of the ICANN
structure as opposed to another forum.
 
With respect to the Anti-Phishing Bill, currently it does not deal with
fast-flux issues, but it certainly could be amended to address this
problem.   It includes WHOIS requirements, presumably because of the
problems and roadblocks imposed by registrars in accessing this data in
the past.   If registrars continue to fight proposals to address domain
based phishes and continue to allow phishers to use their registration
systems as a means of accomplishing their activities, we should expect
that another solution, perhaps a legislative one, would be pursued.   I
would think it is better for registrars to come up with a solution
through ICANN than to try to revise legislative initiatives written by
people that don't understand the registrar business.

I disagree with you that the issue does not affect or involve the domain
business.  The issue is a problem that can be addressed by registrars
because (i) preventing the domain name from resolving altogether will
effectively stop the phish, and (ii) for those registrars that provide
name server services, limiting the number of updates could reduce the
number of IP addresses that are utilized in a phish attack.  I would
like to understand why this is so objectionable-- and what registrars
think would be a reasonable solution to this problem.  

Margie



-----Original Message-----
From: John Berryhill [mailto:john@xxxxxxxxxxxxxxxxx]
Sent: Wednesday, March 05, 2008 9:35 PM
To: Margie Milam; 'Thomas Keller'; 'Ross Rader'
Cc: registrars@xxxxxxxxxxxxxx
Subject: RE: [registrars] WG: [council] Fast Flux DNS



>The Anti-Phishing Working Group has been trying for years
>to get registrars to conform to their best practice approach. 

Did you actually *read* the last report?

I sure did.  If recent comments about the AGP are any indication, there
are
a whole lot of people who didn't.

While we were sitting in the room in Delhi, and Paul Stahura was
explaining
how the AGP can be used to run fraud profile tests and delete names that
meet fraud profiles, I was actually reading the APWG recommendation that
registrars do precisely that.

Now, over in the BCISPIP cross-constituency meeting, they were
discussing
how use of the AGP for DOING just what the APWG was recommending, was a
"phony excuse" for keeping the AGP.

Sorry, but I call shenanigans here.

Let's have a rational explanation as to why elements of the GNSO are
hell-bent on ELIMINATING use of one of the mechanisms recommended by the
Anti-Phishing working group.

Is there a "ten words or less" explanation that anyone has, as to WHY
the
BCISPIP folks DON'T want registrars to be able to implement the fraud
profile and domain deletion recommendations of the most recent APWG
report.

Because if there isn't, this is the wrong place to come crying about
just
who is not interested in implementing the APWG recommendations.

> As many of you may know, there is an anti-phishing bill introduced by
> Senator Snowe in the U.S. senate that, if enacted as currently
written,
> would impose requirements on registrars. 

And the provisions of that bill relating to Fast Flux DNS are where,
exactly?  The argument that an ineffective solution from the GNSO will
forestall an ineffective solution from elsewhere is simply posturing.

I am convinced that too few people are capable of reading and
understanding
either the SSAC or APWG reports.

The issue is not "changing name servers" rapidly.  The issue is changing
IP
resource records and DNS records *IN* the nameservers rapidly. It is a
DNS
and hosting issue, NOT a domain name registration issue.

Where this whole discussion goes into stupid overdrive is that if you
want
to put a choke on nameserver changes, then the choke point is at the
REGISTRY.  If you believe that this issue relates to how quickly the
designated nameservers are changed, then you simply roll back to what we
had
a few years ago when you had to wait a few hours for batch updates to
the
.com (or other TLD) zone file.

I don't know if you know how any of this stuff works, but it is the data
in
the TLD zone file that identifies the IP addresses of the name servers
in
which DNS records can be found.

REGISTRARS DON'T RUN THE ZONE SERVERS.  Let those six words sink in for
a
few moments.  Anyone who does not understand the implications of those
six
words to this issue is simply not qualified to participate.

Catering to a group of lawyers who don't know how the internet works
doesn't
make sense.  People can have wonderful and interesting opinions about
lots
of things.  But if they want to participate in technical coordinating
tasks
relevant to a global computer network, then having a clue how that
network
actually works would be a great idea.

So, let's re-cap the agenda:

1.  The APWG wants registrars to be able to delete domain names rapidly
soon
after registration if fraud is detected.  Much of the GNSO would like to
eliminate that capability.

2.  There is a security issue arising, in part, from too many changes
being
permitted to records in the TLD zone files maintained by the REGISTRIES.
Solving this problem is the responsibility of the REGISTRARS.

3.  Agreeing to an irrelevant and ineffective ICANN GNSO proposal will
prevent the US Government from doing silly things.

Hey, here's a "best practice" - how about if the Telco's and ISP's quit
shipping everyone's phone and internet traffic to the US Government
without
a warrant (even a retroactive warrant).  Boy, it's a good thing we don't
have outfits like that proposing ICANN policy.

Oh, wait a minute.  We do!

We obviously need better lobbyists.  ICANN participants in the other
constituencies can get their very own law that permits them to engage in
criminal activity with immunity, but we have to pretend to be solving a
problem by agreeing to a solution that won't solve the problem, or we'll
be
in big trouble.










<<< Chronological Index >>>    <<< Thread Index >>>