ICANN ICANN Email List Archives


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

Re: [gnso-ff-pdp-may08] Re: [ntfy-gnso-ff-pdp-may08] FW: example: using fast-flux to escape censorship

  • To: joe@xxxxxxxxxxxxxxxxxx, dave.piscitello@xxxxxxxxx
  • Subject: Re: [gnso-ff-pdp-may08] Re: [ntfy-gnso-ff-pdp-may08] FW: example: using fast-flux to escape censorship
  • From: "Mike O'Connor" <mike@xxxxxxxxxx>
  • Date: Wed, 16 Jul 2008 11:33:16 -0500

Hi gang,

I'm happily pasting pieces of this thread to the wiki, here's the page;


Edit up a storm.


At 10:48 AM 7/16/2008, Joe St Sauver wrote:
-- Fastflux nameservers may be recursively fastflux in turn, but in many
   cases expect to see very LONG TTLs for fastflux name servers, taking
   advantage of caching and the "glue record problem."

-- Fastflux domains also differ from normal domains in HOW MANY A records
   may be returned for a given IP. While most normal web hosts return
   only one or perhaps two IPs, fastflux domains may return half a dozen
   or a dozen dotted quads in response to a single query.

-- Fastflux domains also usually will not change IPs just for the sake of
   changing. That is unlike some other services which may exploit what
   effectively amounts to IP "frequency hopping" (routinely and continually
   changing IPs in an effort to avoid monitoring and censorship), fastflux
   nodes tend to change IPs when they HAVE to be changed (e.g., because a
   formerly used node has become unresponsive or is performing poorly or
   is believed to have become compromised).

-- Fastflux domains will routinely have invalid domain whois data, such
   as bogus or incomplete address information

-- Fastflux domains will routinely be associated with registrars or
   registration service providers who have, or who may be perceived to
   have, lax or limited TOS or lax or limited abuse handling procedures

-- Fastflux A records have been seen on multiple occaisions associated
   with attempts to return additional NS resource records mapping "."
   to the misreants own servers on vulnerable name servers

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

Privacy Policy | Terms of Service | Cookies Policy