ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


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

Re: [gnso-ff-pdp-may08] Internet Draft: Fast Flux Defense in DNS

  • To: Dave Piscitello <dave.piscitello@xxxxxxxxx>
  • Subject: Re: [gnso-ff-pdp-may08] Internet Draft: Fast Flux Defense in DNS
  • From: Marc Perkel <marc@xxxxxxxxxx>
  • Date: Wed, 27 Aug 2008 15:14:35 -0700


If I'm not mistaken, didn't we determine that stopping all fast flux was a bad idea?

Dave Piscitello wrote:
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-bambenek-doubleflux-
01.txt

I can't find reference to or recall any mention of this proposal.

This internet draft ( Intended status: Standard ) briefly describes single
and double flux in a manner consistent with SSAC's definitions and then
proposes the following:

3.  Recommended Changes

   In order to mitigate the threat of double flux service networks
   a variety of changes to the standard are proposed. The changes
   will affect a variety of levels so that if some of the changes
   are not implemented at certain levels, some protection will be
   afforded to consumers through the other levels.

3.1. Changes to Registrars

   Domain registrars SHALL limit the rate at which changes can be
   made to authoritative DNS servers for domains within their control
   to one set of changes per 72 hours. They SHOULD also allow for a
   "backout" to the previous settings in the event of errors. This
   backout will move the settings back to the previous nameserver
   settings and reset the clock for 72 hours. This will prevent
   malicious individuals from constantly changing their DNS records
   to avoid takedowns.

3.2. Changes to Authoritative DNS Services

   During startup, DNS services SHALL check both the TTL for NS
   records and check the TTL for the A records associated with the
   NS record. If the TTL is set to a value below 86400 (24 hours) it
   SHALL override the setting to 259200 (72 hours) and record an
   entry in the system logs to that affect. A value MAY be specified
   within 24-72 hours that will work, but values under 24 hours
   will default to 72 hours.

3.3. Changes to DNS Resolving Services

   DNS servers that are non-authoritative but performing queries on
   behalf of local clients SHALL examine the TTL of the NS record and
   if applicable, the A record for the cooresponding nameserver.
   If either non-cached TTL comes back with a value of less than
   12 hours, it SHALL be discarded and return an error giving no
   information to the requesting client.

3.4. Changes to DNS Clients

   DNS clients SHALL examine returned values for all nameserver
   lookups for NS records (and cooresponding A records for those
   NS records) for TTLs less than 12 hours. If a non-cached result
   of a query comes back with a low TTL, it SHALL be discarded with
   no IP address returned to the requesting application.

I suppose a "PREVENT THEM ALL" approach has the merit of making the issue of
the purpose of double flux networks moot, doesn't it?






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

Privacy Policy | Terms of Service | Cookies Policy