<html>
<head>
<meta content="text/html; charset=iso-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12/08/2014 09:40 AM, der.hans wrote:<br>
</div>
<blockquote
cite="mid:alpine.DEB.2.02.1412080914100.4225@www.LuftHans.com"
type="cite">Am 08. Dez, 2014 schwätzte Michael Butash so:
<br>
<br>
moin moin,
<br>
<br>
<blockquote type="cite">On 12/07/2014 10:42 PM, der.hans wrote:
<br>
<blockquote type="cite">Am 07. Dez, 2014 schwätzte Michael
Butash so:
<br>
<br>
<blockquote type="cite">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
<br>
</blockquote>
<br>
True, if you're doing those things, you might have large dns
payloads and
<br>
need tcp. If you think they cause problems rather than fixing
them, then
<br>
...
<br>
</blockquote>
"Normal" use of these yes, but imho better just to leave it be
serviced anyways, especially if any sort of provider for others.
<br>
</blockquote>
<br>
Yeah, I suppose I pre-optimized and presumed this would be home,
non 3rd
<br>
party use for Keith.
<br>
</blockquote>
<br>
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.<br>
<blockquote
cite="mid:alpine.DEB.2.02.1412080914100.4225@www.LuftHans.com"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">anomaly mitigation gear (the things
that keep 400gb DDoS at bay) use that to
<br>
</blockquote>
<br>
What would anomaly mitigation gear be doing to cause large dns
payloads?
<br>
That's a serious question as I don't even know what anomaly
mitigation
<br>
gear is.
<br>
</blockquote>
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.
<br>
</blockquote>
<br>
Hmm, this isn't making sense to me. Are you saying a client makes
a
<br>
request to your dns service and you force the client over to tcp
lookups?
<br>
If so, does that cause the rest of the recursive lookup to other
servers
<br>
to be tcp as well?
<br>
</blockquote>
<br>
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.<br>
<br>
Better yet, cut and paste from rfc:<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=iso-8859-15">
<pre style="color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; white-space: pre-wrap;"> 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.</pre>
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. <br>
<br>
They have interesting ways of challenging other protocol behavior as
well to verify who's real or not.<br>
<blockquote
cite="mid:alpine.DEB.2.02.1412080914100.4225@www.LuftHans.com"
type="cite">
<blockquote type="cite">
<br>
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.
<br>
</blockquote>
<br>
Did those remote providers block tcp/53 for client or just for
server (
<br>
only incoming syn blocks )?
<br>
</blockquote>
<br>
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.<br>
<br>
Pedantic things you learn over the years that stick with you.<br>
<blockquote
cite="mid:alpine.DEB.2.02.1412080914100.4225@www.LuftHans.com"
type="cite">ciao,
<br>
<br>
der.hans
<br>
</blockquote>
<br>
</body>
</html>