On 12/08/2014 09:40 AM, der.hans wrote:
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.

I just bring it up as I've had "security experts" say to block things like that and icmp in more of a service-provider or servicing capacity, and experience has just told me best to leave it be as a natural thing for dns and networking in general.  Often makes for more complication and problem than you're fixing ultimately if ramifications are not understood.
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?

So if I remember the rfc process right, client requests record, that ends up being like a domain key over 512 bytes, server sends back a truncate message, basically "too large a reply, resend via tcp pls so I can fragment it".  Client then does, and normally gets their big dns record in a few chunks.

Better yet, cut and paste from rfc:

   In the absence of EDNS0 (Extension Mechanisms for DNS 0) (see below),
   the normal behaviour of any DNS server needing to send a UDP response
   that would exceed the 512-byte limit is for the server to truncate
   the response so that it fits within that limit and then set the TC
   flag in the response header.  When the client receives such a
   response, it takes the TC flag as an indication that it should retry
   over TCP instead.
Old Cisco anomaly mitigation appliances did that, and later Arbor tms and most other software that auto-mitigate dns attacks, as it's one of the few ways you can "challenge" a client to interact back in such a way you can identify whether it's a real client request or a raw socket bit-blast at udp/53 pr other. 

They have interesting ways of challenging other protocol behavior as well to verify who's real or not.

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

Well, I remember one instance we had to reach out to road runner cable engineers because they were blocking tcp/53 requests for their customer dns resolvers, and suddenly a large swatch of their customer base couldn't resolve anything hosted by us when our ddos appliances blacklisted them as an attacker (2 addresses doing a _lot_ of requests interpreted as bad, which at the time we had some 50mil domains under us, so it was felt).  They opened it, but we had to whitelist them specially until then.

Pedantic things you learn over the years that stick with you.
ciao,

der.hans