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

["Margie Milam" <Margie.Milam@xxxxxxxxxxxxxxx>]

Ross-

Unfortunately some large registrars are not as helpful dealing with phishing as others.  We tracked the response time in our Autumn Brand Jacking Index of registrars responding to phish take down requests, and it varied quite dramatically, with the fastest 10 registrars responding on average in less than an hour, and the slowest registrars responding on average in over three hundred hours.  Surprisingly, there were some large registrars among the slowest responders.  This is why the best practice approach doesn't really solve the problem.

You are correct that ISP's also offer DNS in addition to most registrars. Since ISPs also participate in ICANN-- is there a way to work on this through ICANN?  I don't know if there is a better forum for this.   

One of the objections we hear from registrars when seeking cooperation for a shut-down is that they are unsure whether they are allowed to disable the domain due to phishing.   If ICANN were to issue an advisory to registrars that they should disable and/or delete a domain name for phishing--- this might be more effective than the best practice approach.  

Margie


-----Original Message-----
From: Ross Rader [mailto:ross@xxxxxxxxxx] 
Sent: Thursday, March 06, 2008 8:48 AM
To: Margie Milam
Cc: Thomas Keller; registrars@xxxxxxxxxxxxxx
Subject: Re: [registrars] WG: [council] Fast Flux DNS

Margie -

My point is that this is an issue that DNS operators need to be  
concerned with. Most registrars offer DNS service as part of the  
registration process, but this isn't something that is required or  
covered by our contracts with ICANN. Most ISPs offer DNS service in  
some way as well. I believe that we should be working with the larger  
DNS management community to solve this problem. Maybe "best practice"  
wasn't the most appropriate term to use - this could be the subject of  
an RFC, BCP or some other internet standards document.

I believe our collective interests would be best served by developing  
this document instead of investing our energy in engaging the ICANN  
policy process, lobbying congress or fighting one another about the  
political details.

Also, I think your arguments would be much more convincing without the  
rhetorical attacks. Many ICANN registrars are actively involved in  
dealing with the "phishing issue". Whether we see eye to eye on your  
trademark and intellectual property issues is entirely another story -  
one that we probably shouldn't distract ourselves with if we really  
want to deal with the DNS problem.

-ross


On Mar 5, 2008, at 5:50 PM, Margie Milam wrote:

>
> Tom and Ross,
>
> I disagree with the position that Fast Flux issues should be dealt  
> with as a best practice and not GNSO policy.
>
> The Anti-Phishing Working Group has been trying for years to get  
> registrars to conform to their best practice approach.  We have  
> received numerous presentations at our registrar meetings urging for  
> adoption of best practices.  The results are that some registrars  
> are extremely helpful and cooperative, while others do not choose to  
> help.   In the meantime phishing has skyrocketed--particularly  
> domain name based phishing due to the ability to update DNS records  
> so quickly.
>
> I think it would be useful to understand why registrars would be  
> opposed to evaluating this problem and how they could effectively  
> limit their customers from frequently updating their DNS records.    
> Are there customers asking for frequent updates that would be harmed  
> if there were a daily limit on DNS updates?   At MarkMonitor, we  
> generally don't see customers asking for multiple DNS updates per  
> day, but it may be because of our unique corporate focus.
>
> My point is that if the GNSO or ICANN thinks this is out-of-scope,  
> the problem will likely be dealt with in a different forum, where  
> registrars may not have a lot of influence. 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.   If ICANN registrars or the GNSO were  
> actively pursuing or participating in a solution to the phishing  
> problem, there would likely be less interest in a legislative  
> solution.
>
> Margie
>
>
> -----Original Message-----
> From: owner-registrars@xxxxxxxxxxxxxx [mailto:owner-registrars@xxxxxxxxxxxxxxx 
> ] On Behalf Of Thomas Keller
> Sent: Monday, March 03, 2008 8:37 AM
> To: 'Ross Rader'
> Cc: registrars@xxxxxxxxxxxxxx
> Subject: AW: [registrars] WG: [council] Fast Flux DNS
>
>
> Hello,
>
> If there is no argument made by this group why this could be a  
> worthwhile
> endeavor I will vote against the preparation of an issues report. I  
> totally
> agree with Ross that dealing with the Fast-Flux phenomenon should be  
> subject
> to best practice and not GNSO policy.
>
> Best,
>
> tom
>
> -----Ursprüngliche Nachricht-----
> Von: Ross Rader [mailto:ross@xxxxxxxxxx]
> Gesendet: Donnerstag, 28. Februar 2008 15:30
> An: Thomas Keller
> Cc: registrars@xxxxxxxxxxxxxx
> Betreff: Re: [registrars] WG: [council] Fast Flux DNS
>
> Ask them how this is in scope of the policy mandate of the GNSO.
>
> The GNSO is purely concerned with gTLD policy, not DNS policy. If  
> Mike and
> his crew want to push this up the hill, they should first satisfy  
> the GNSO
> as to how this is a matter that the GNSO can be concerned with.
>
> Creating limitations around the timing of updates to registration  
> records is
> a tricky matter that should not be dealt with hysterically.
> I think this is more  a matter best left to a technical operations  
> group
> like NANOG, etc.
>
> It would be a more fruitful investment for our constituency to  
> pursue the
> development of operational best practices in this area in  
> conjunction with
> folks that actually have clue like Gadi, NANOG ops, etc.
>
> Letting the lawyers drive this bus is just plain dumb.
>
> -ross
>
> On Feb 28, 2008, at 3:38 AM, Thomas Keller wrote:
>
>>
>>
>> now we finally reached the point where the BC wants to turn all of us
>> into their private law enforcement squad. Looking forward to receive
>> advise on how to react to this.
>>
>> Best,
>>
>> tom
>>
>> -----Ursprüngliche Nachricht-----
>> Von: owner-council@xxxxxxxxxxxxxx [mailto:owner-
>> council@xxxxxxxxxxxxxx] Im Auftrag von Mike Rodenbaugh
>> Gesendet: Mittwoch, 27. Februar 2008 18:12
>> An: 'Council GNSO'
>> Betreff: [council] Fast Flux DNS
>>
>>
>> Hello,
>>
>> I propose the following motion for Council consideration in our next
>> meeting
>> on March 7th, may I please have a 'second'?
>>
>> Thanks,
>> Mike Rodenbaugh
>>
>>
>>
>> Whereas, "fast flux" DNS changes are increasingly being used to
>> commit crime
>> and frustrate law enforcement efforts to combat crime, with criminals
>> rapidly modifying IP addresses and/or nameservers in effort to evade
>> detection and shutdown of their criminal website;
>>
>> Whereas, the Security and Stability Advisory Committee has reported
>> on this
>> trend in its Advisory SAC 025, dated January 2008:
>> http://www.icann.org/committees/security/sac025.pdf/
>>
>> Whereas, the SSAC Advisory describes the technical aspects of fast
>> flux
>> hosting, explains how DNS is being exploited to abet criminal
>> activities,
>> discusses current and possible methods of mitigating this activity,
>> and
>> recommends that appropriate bodies consider policies that would make
>> practical mitigation methods universally available to all
>> registrants, ISPs,
>> registrars and registries,
>>
>> Whereas, the GNSO is likely an appropriate party to consider such
>> policies
>>
>> The GNSO Council RESOLVES:
>>
>> ICANN Staff shall prepare an Issues Report with respect to "fast
>> flux" DNS
>> changes, for deliberation by the GNSO Council.  Specifically the
>> Staff shall
>> consider the SAC Advisory, and shall outline potential next steps
>> for GNSO
>> policy development designed to mitigate the current ability for
>> criminals to
>> exploit the DNS via "fast flux" IP or nameserver changes.
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>