[dns-operations] Configurable TC=1?

Paul Vixie paul at redbarn.org
Sun Dec 20 23:19:58 UTC 2015


On Sunday, December 20, 2015 02:14:10 PM Dave Warren wrote:
> On 2015-12-20 10:16, Paul Vixie wrote:
> > this won't help all victims of dns amplification attacks, since many
> > of the congestion points are measured in PPS not BPS. they need
> > attenuation, not just the absence of amplification. attenuation in
> > both PPS and BBS.
> 
> If all you care about (as an attacker) is causing high PPS, an attacker
> doesn't need to use DNS servers in particular, virtually any host that
> responds on TCP or UDP or ICMP will reply back with a single packet
> (even if it's just a refusal) will be sufficient for a reflection style
> PPS attack.

on my freebsd kernels, both tcp and icmp are rate limited. i think that's relatively common. i 
see your point, but we need attenuation _everywhere_. see:

http://queue.acm.org/detail.cfm?id=2578510

> DNS is largely used because of amplification, which is a combined PPS
> and BPS attack.
> 
> Returning TC=1 has the unique advantage of allowing a DNS server to stop
> responding to the packets at all for a little while until/unless you see
> a TCP DNS query from the same host (after which point you might start
> answering UDP again, since you at least know the queries are from a DNS
> server and not a reflection attack)

i don't see that happening. that is, TC=1 is a per-query result. if the same server asks 
another question (maybe the same q-tuple, maybe not) then you'll have to send another 
response (maybe TC=1 again, maybe not.)

> I agree that DNS RRL helps in the case of amplification. However, as I
> understand it, RRL only steps in for duplicate queries and in a pure PPS
> attack, an attacker can simply ask tons of different queries and
> partially side-step RRL.

no. that is, yes, rrl can be bypassed. but not as simply as you described.

> As attackers develop future techniques in the
> future, I expect both RRL and TC=1 will be useful in reducing the impact
> on victims.

if an attacker sends a stream of spoofed-sourced queries to a reflector, then the reflector is 
going to have to answer, or else rate limit, its responses. whether those responses are short 
TC=1 or, full responses, doesn't mean much to the victim.

> Also potentially useful (although it would require wide deployment)
> would be if a victim could send out some sort of "I'm being attacked,
> stop responding to UDP queries" squelch, and after receiving such a
> packet, a DNS server would only respond with TC=1 responses, and only a
> small percentage of them (to ensure that this doesn't create a DoS
> mechanism), with the victim knowing to use TCP. [...]

forcing a victim to rely on tcp would be, today, a separate and valuable attack, since current-
specification tcp/53 servers are quite weak. see:

http://tools.ietf.org/html/draft-ietf-dnsop-edns-tcp-keepalive-04.html

and:

http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/

-- 
P Vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20151220/9d34f034/attachment.html>


More information about the dns-operations mailing list