Am 08. Dez, 2014 schwätzte Michael Butash so:

moin moin,

> On 12/07/2014 10:42 PM, der.hans wrote:
>> Am 07. Dez, 2014 schwätzte Michael Butash so:
>> 
>>> You'll want to allow tcp/53 if doing any sort of public dns - anything 
>>> greater than 1500 bytes (ie most domain-keys//spf records), and also any
>> 
>> True, if you're doing those things, you might have large dns payloads and
>> need tcp. If you think they cause problems rather than fixing them, then
>> ...
> "Normal" use of these yes, but imho better just to leave it be serviced 
> anyways, especially if any sort of provider for others.

Yeah, I suppose I pre-optimized and presumed this would be home, non 3rd
party use for Keith.

>>> anomaly mitigation gear (the things that keep 400gb DDoS at bay) use that 
>>> to
>> 
>> What would anomaly mitigation gear be doing to cause large dns payloads?
>> That's a serious question as I don't even know what anomaly mitigation
>> gear is.
> It's not a large payload issue, it's a method of them validating who is a 
> script opening a raw udp socket to spew junk, etc vs. a "real" RFC-compliant 
> client by sending that truncate bit back to the client, making them request 
> via tcp, and thus doing something more than legit aiming a cannon.

Hmm, this isn't making sense to me. Are you saying a client makes a
request to your dns service and you force the client over to tcp lookups?
If so, does that cause the rest of the recursive lookup to other servers
to be tcp as well?

> Having worked for one of those large hosting companies that gets those 300gb 
> ddos attacks you read about (not to mention being responsible for dealing 
> with them), you need something to do mitigate botnet blasts automagically,

Most of our protocols could use some updates.

> and luckily some smart people figure out protocol challenge behavioral hacks 
> to do that.  I remember back in 2003 needing to open firewalls to allow tcp 
> for our dns just for that alone when ddos became vogue among warring 
> customers, but became more common at various other businesses to have to 
> address allowing tcp as well for spf and others.
>
> It also broke some remote providers that blocked tcp/53 as well for some 
> reason when our devices couldn't "validate" them, adding them to a drop list 
> vs. whitelisting them as "valid" clients.

Did those remote providers block tcp/53 for client or just for server (
only incoming syn blocks )?

> Not that big a deal running a server at your house, and never using dkim/spf. 
> I think most default cisco asa firewall configs still filter udp dns protocol 
> traffic by default over 512 too.
>> 
>>> figure our if you're real or not. Blocking tcp for dns is not a good idea 
>>> as a whole, it's just RFC-compliant behavior things expect.
>> 
>> As I recall, the RFC only specifies tcp for large payloads. Don't allow
>> them and tcp isn't necessary.
> Less is more I suppose when talking firewalls, just know when you *do* need 
> things like tcp-based dns.

Yeah, good thing for Keith that you're pointing out that a service
provider probably has to leave tcp/53 exposed, especially when using newer
dns record 'features'.

ciao,

der.hans
-- 
#  http://www.LuftHans.com/        http://www.PhxLinux.org/
#  "Luckily, this is a comic book, for which no idea is too complex."
#    -- Larry Gonick from The Cartoon History of the United States