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

[Dave Piscitello <dave.piscitello@xxxxxxxxx>]

Yes, Mark. This Internet-draft is a good example of work done in parallel by 
two non-communicating parties with varying levels of expertise and "practical 
data" resulting in dramatically different conclusions.

After reading Joe's email, I think we should just let the US Army reply to the 
IETF regarding this I-D:-)

It would be interesting to understand what the army uses TTL/600 for but I 
imagine it's one of those "we could tell you but then we'd have to kill you" 
answers. Nonetheless, it would be interesting to collect at least a sample list 
of network operators who use TTLs of 5 mins or less to illustrate there are 
parties who use it in phishing and fraud attack networks and parties who use it 
for other purposes.


On 8/27/08 6:14 PM, "Marc Perkel" <marc@xxxxxxxxxx> wrote:

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?
>
>
>
>