ICANN ICANN Email List Archives

[fast-flux-initial-report]


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

My comments regarding the Initial Report on Fast-Flux Hosting

  • To: fast-flux-initial-report@xxxxxxxxx
  • Subject: My comments regarding the Initial Report on Fast-Flux Hosting
  • From: Steven Chamberlain <steven@xxxxxxxxxxx>
  • Date: Thu, 29 Jan 2009 23:12:53 +0000

Hi,

I believe the major motivation behind looking to restrict fast flux
techniques was to be able to promptly disable access to malware,
phishing sites or illegal content hosted on such domains.  I believe
this is a sensible goal, but I feel it is wrong, and ultimately futile,
to restrict the use of fast flux as a way to counter these threats.

I consider fast-flux domains to be valuable in their ability to provide
decentralised services which can be designed for one or more of:

* speed -- clients can be served by geographically closer hosts;

* load balancing -- under normal operating conditions, or even DDoS
attacks, client connections can be served by a varying number of hosts;

* reliability -- clients can be always directed to functional servers,
even when some become unavailable, perhaps for maintenance or due to an
unexpected outage.

I believe there are some well-known content distribution networks that
use these techniques extensively.  But these techniques can be of
particular value to smaller organisations and individuals who may not be
able to afford hosting on multi-homed or anycasted systems.

I can suggest viable methods for disabling domains without penalising
legitimate users of fast flux techniques, and without imposing any new
restrictions on domain registration.

I believe the necessary data and tools are already widely available.  To
some extent I imagine the techniques I suggest below are already used to
limited extent in various situations, but could bring greater benefit
through wider deployment.

Blacklists of domains known to host malware, phishing sites or illegal
content can be equally effective against fast-flux domains as against
any other domain.

There need not be a single, master blacklist.  Data can be compiled and
published by government or law-enforcement agencies, security
researchers or private individuals;  lists may be free or proprietary.
Per-country blacklists could exist which take into account the legality
of the domain's hosted content in that jurisdiction.  Data can be
distributed as often as considered necessary, perhaps as bulk or
incremental downloads, DNS AXFR transfers, or even as a real-time
service offered using DNS or other means.

One way to disable access to blacklisted domains would be to promptly
remove their records from all authoritative root servers worldwide.
This action may in fact be most effective against domains using the
double-flux technique, because their use of necessarily short TTLs means
that any cached nameserver records would expire the soonest.  This
action would be less effective against domains using longer TTLs, but
these domains are already the most vulnerable to take-down by shutting
down their authoritative nameservers, of which there should only be a
relatively small number.

If the above is not feasible, perhaps due to technical, legal or
political contraints, then ISPs could make use of the blacklist data
instead.  DNS servers are typically already provided by ISPs for
customers to use, but these could be configured to filter out
black-listed domains.  Widely-used DNS server software such as BIND is
very easily configured to do this by loading authoritative zone data for
the blacklisted domains.  Alternatively, any transparent HTTP proxy
servers already in use by an ISP could be configured to perform the
necessary filtering.  Deep-packet inspection of DNS queries or HTTP
requests is also an option, but in most cases this may be more difficult
than the other techniques I have suggested.

The same techniques may also be employed within corporate environments,
by educational establishments, and by other providers of Internet
access.  Different blacklist data sources may be selected in different
environments, in order to be more or less restrictive.  Private DNS
services with malware domain filtering may be offered by third parties
to establishments or individuals unwilling or unable to do this in-house.

Finally, it is also possible for Internet users to protect themselves as
long as one or more sources of domain blacklist data are publicly
available.  A local DNS cache, a resolver or 'hosts' file, browser, or
separate security tool could block access to blacklisted domains in
order to protect the user.

In any case it remains a possibility that an Internet user may
deliberately subvert filtering of blacklisted domains.  The user could
try to access DNS servers which do not employ filtering, or bypass any
filtering proxy servers or deep-packet inspection by using encrypted
tunnels or other means, but they would do so at their own risk.

Entities seeking to prevent Internet users from actively seeking out
illegal content have little reason to restrict domain registrations or
the use of fast flux techniques:  illegal content can be, and
increasingly is, made available without a domain registration at all.

Regards,
-- 
Steven Chamberlain
steven@xxxxxxxxxxx (steven-at-pyro-dot-eu-dot-org)



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

Privacy Policy | Terms of Service | Cookies Policy