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

[Dave Piscitello <dave.piscitello@xxxxxxxxx>]

Absolutely agree. It's heavy handed, narrowly focused and shortsighted.

Basically, it takes three suggestions from SSAC and proposes them as solutions 
without adequate study (we are doing a better job here I think so 'grats to us 
all for thinking broadly and deeply).


On 8/27/08 6:32 PM, "Joe St Sauver" <joe@xxxxxxxxxxxxxxxxxx> wrote:

Dave mentioned:

# 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.

I think this draft, while well intentioned, would be a real mess
in practice.

I also think it is just the camel's nose under the tent if the FF
issue doesn't get dealt with via some other mechanism (like suitable
administrative procedures).

#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.

Of course, since many (single) flux networks already use name servers
with long TTLs, this will NOT inhibit fastlux.

Moreover, what's a "change"?

-- A new name server name?
-- A different name server dotted quad?
-- An additional name server?
-- One fewer name server?
-- Name servers listed in different order?
-- Changes to TTLs?

#   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.

I'm reminded of two ways of doing "undo"'s in programs.

Assume a sequence of commands/states:

B
C
D

Having done D, user reverts (does an "undo"), and is now effectively at
C.

User now does *another* undo. But what do they undo?

Do they undo the "undo" command they just did, bringing them back to state
D, or do "undos" get ignored when reverting, thereby resulting in the user
get rolled back one layer further, to B?

If the RFC contemplates the later, imagine a spammer who has taken the
time to set up a history of a dozen different sets of name servers, each at
least 72 hours after the preceding one. As written, they could then proceed
to unwind that stack at their pleasure, since reverting to a previous name
server is not subject to the 72 hour timer as written (as I read the draft).

I'm also curious where/how the previous name server names would be recorded,
eh? In whois? In some new (but undefined) record? Purely in the registrar's
own non-public records? How far back would that historical stack be kept?

#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) If the bad guys run their own authoritative servers, what if they
just disregard this requirement? If the answer is "3.3 will fix *them*,"
then why do we need "3.2" as well?

(b) If values of at least 24 hours are acceptable, why, if my TTL is
(24*60*60)+1, should it be rewritten to (72*60*60) instead of the
minimum acceptable value, instead? e.g., (24*60*60)?

#   A value MAY be specified
#   within 24-72 hours that will work, but values under 24 hours
#   will default to 72 hours.

*Who* may specify a value in the 24-72 hour range? The operator of
the authoritative server (if they like 31.3 better than 72)? Or the
person responsible for the domain's zone file entry?

#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.

An error giving no information still gives information ("the dog didn't
bark"). Instead of being coy about what's happening, I'd suggest returning
a unique code, just as NXDOMAIN is currently returned for some non-resolvable
conditions, or SERVFAIL is returned for others. I suggest the code FUBAR be
assigned for this new condition. :-;

[I won't even go into why negative caching might be important for this sort
of a non-response, or how negative caching, if implemented, might make a
great DOS vector]

#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.

Does 3.4 imply that all name servers for each domain must be checked
before a result is returned? ("DNS clients SHALL examine returned
values for *ALL* nameserver lookups for NS records [...]" (emphasis
added))

What if one name server has a low TTL but the others do not? Is only
that record discarded? Or are all records for that domain discarded?

Is a "low TTL" one that's less than 12 hours (inferred from context),
or is a "low TTL" site/implementation dependent? (I *think* I know what
the author means here, BUT I can only rely on what's written, not
my projections/inferences)

And then, drafting issues aside, there are realities such as:

www.army.mil.           3600    IN      CNAME   www1.ahp.us.army.mil.
www1.ahp.us.army.mil.   294     IN      A       143.69.249.10
us.army.mil.            600     IN      NS      ns01.army.mil.
us.army.mil.            600     IN      NS      ns02.army.mil.
us.army.mil.            600     IN      NS      ns03.army.mil.

I'd just love to see some attempt to enforce an 86400 or better TTL on
the Army. :-)

Regards,

Joe