Home

DNS Security: RRL <=> CACHE POISON dns

rrl

http://www.redbarn.org/dns/ratelimits

https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Response-Rate-Limiting.html

http://www.zytrax.com/books/dns/ch7/hkpng.html#rate-limit

rate-limit {
     [ domain domain-name ; ]
     [ responses-per-second [size number] [ratio fixedpoint] number ; ]  #可以指定每秒返回较少的大应答包
     [ referrals-per-second number ; ]
     [ nodata-per-second number ; ]
     [ nxdomains-per-second number ; ]
     [ errors-per-second number ; ]
     [ all-per-second number ; ]
     [ window number ; ]  # 默认值 15 sec; 计算速率的时间窗  query_pkt_num / window = qps
     [ log-only yes_or_no ; ]
     [ qps-scale number ; ]  #默认不开启；全局rate-limit
     [ ipv4-prefix-length number ; ]
     [ ipv6-prefix-length number ; ]
     [ slip number ; ]  # 默认值 0 直接丢包；n 第n个查询包回应TC=1
     [ exempt-clients { address_match_list } ; ]
     [ max-table-size number ; ]  #统计列表支持的最大长度
     [ min-table-size number ; ] 
};

qps-scale 是大招

( qps-scale / DNS query arrival rate ) * responses-per-second = effective rate-limit

假设算出来的 effective rate-limit 为 4，则权威在1 sec内对指定条件的任意client只响应前4个查询

rrl 的问题

https://www.isc.org/blogs/cache-poisoning-gets-a-second-wind-from-rrl-probably-not/

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

分析挺有意思的，大致是扯这些个观点：

一切痛苦源于没有SAV，即源地址认证 （俺同意）

全部换成TCP会导致查询性能下降，人家不愿意（俺觉得未来还是会上）

禁掉ANY也没有用，DNSSEC应答包也很大（俺同意）

RRL的slip value设成2,不会对CACHE POISON造成明显不利的影响（唔。。。）

slip value = 2 收到同一CLIENT的一堆相同查询时，只对其中一半时间内的查询返回TC置位应答，其余一半时间的查询请求全部不管

slip value = 1 每个查询都返回TC置位应答

不做RRL的话，dns server因遭受攻击而使响应变慢，同样会增大CACHE POISON的概率（这话说的有点损，哈哈）

本质上，查询应答加上一些状态检查（RRL，一定时间内的查询个数/TCP握手，确定真的是活的/DNS COOKIE，保证随机数来自指定窗口），都是性能与安全的折衷（确实如此）

没有做SAV，主要的威胁（问题就在于做SAV，ISP看不到自身直接的好处吧，所以累己利他人的东东总是很少）

放大攻击（查询不知道是不是真的查询） =》 TC

缓存中毒（应答不知道是不是真的应答） =》 UDP源端口随机化（SPR），DNSSEC，

DNS碎片攻击（缓存中毒的一种）：例如，应答包拆成两个碎片，后一个碎片包是不检查应答ID的，也就是说，伪造的碎片数据包命中缓存的可能性增大 => 没通过DNSSEC/TSIG认证的碎片数据包直接不收

Published

15 September 2013

Tags


Share On