ICANN ICANN Email List Archives


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

Re: [gnso-ff-pdp-may08] Crafting a solution for fast flux

  • To: marc@xxxxxxxxxx
  • Subject: Re: [gnso-ff-pdp-may08] Crafting a solution for fast flux
  • From: Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>
  • Date: Wed, 16 Jul 2008 17:09:01 -0700

Marc asked:

#If I'm not jumping into the solution side to fast, what do you think is 
#the best solution?

I don't think any single thing will eliminate fastflux, I think a
multipronged strategy will be needed (including improved information
sharing, as you've suggested). A short/very incomplete list:

-- Publicly encourage service providers to have abuse reporting addresses,
   and current domain/IP/ASN whois point of contact data (including an 
   explicit abuse contact in those whois records). Flag those who elect
   NOT to do so. 

-- Name servers in domain registrations should be identified as static or
   dynamic by the registrant. If static name servers, the IP's used for
   those name servers should be provided. If dynamic, that's fine, but 
   sites electing to use dynamic name servers should expect that their 
   choice will be taken into account when other sites assess their 
   reputation and decide what (if anything) they want to do 
   with their traffic. Charge a premium for dynamic name server domains.

-- Changes to static name server IPs should also incur a nominal fee, split
   between ICANN and the Registry, with the funds received from that fee
   should be dedicated to abuse handling/security-related purposes at 
   ICANN and each Registry.

-- Encourage ISPs to document IP address ranges which should NOT be
   hosting web pages or DNS servers, much as the PBL is used to document
   IP address ranges which should not be emitting email.

-- Fix the WDPRS process, so that fastflux domains with bogus contact
   information can be efficiently reported.

   What would such a "fix" entail? Well, I'd start with:

   1) If one domain with a given bit of bad information is reported,
      make it possible for submitters to request equivalent treatment
      for ALL domains that share that same specific information defect.

      Thus, for example, if someone registers 150 domains that all
      have the hypothetical and obviously bogus address:

      blah blah blah 
      you can't catch me
      north, pole 99999

      do NOT require someone reporting those addresses to report all 
      (or some fraction of all) 150 domains one-by-one.

   2) Publish monthly summaries of unique complaint volumes by registrar,
      by TLD, and by name server. Also provide a report by privacy
      protection service associated with complained-of domains. 

   3) FOLLOW UP on WDPRS complaints and make sure that something is DONE 
      about the issues which get identified.

   4) Provide a channel for Internet users to report illegal domain use
      (currently it is rather ironic that ICANN will let me report a 
      domain for having the wrong zip code, but not for hosting a 
      phishing site or child pr0n -- something's wrong there, I think).

   5) Allow users to flag domains that appear to be fastfluxing. 

-- Encourage the creation of national cleanup resources for those whose 
   systems have been infected by bots. These resources may vary from country
   to country, but should include technical experts who can help clean
   and harden infected systems (along the lines of what I proposed in
   http://www.uoregon.edu/~joe/ecrime-summit/ecrime-summit.pdf )

-- Encourage ISPs to instrument their own networks, so they have
   visibility into what's being done *with* their resources, and *to* 
   their customers. Fastflux can only survive if networks are blind to 
   upstream hosts.



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

Privacy Policy | Terms of Service | Cookies Policy