Home

DNS-OARC: 2015.05 会议

dns-oarc 2015.05

https://indico.dns-oarc.net/event/21/contributions

随机子域名DDOS攻击、开放递归用于DDOS攻击

增加递归侧的各项处理，弱化根的作用，减轻TLD的压力

DNS多数问题也根源于协议层面DNS查询应答没有双向认证、DNS应答包的放大性、DNS分层服务流量透传，以及实际操作中开放递归的滥用、分层授权后由TTL决定的更新时间不均

A Day in the Life of a DNS Resolver

欧洲小开放递归

DDOS查询包约占递归总查询量的11%~12%；DDOS查询包中，85%~99%都是随机子域名攻击，此外为放大查询攻击。

A countermeasure of random subdomain attacks (Aggressive negative caching with NSEC)

中间的递归否定缓存溢出，影响正常用户递归访问体验

即使递归通过NSEC/NSEC3记录确认了NXDOMAIN，递归仍要去权威查询，确认是否存在泛域名配置。

Draft改进就是如果确认了NSEC/NSEC3 & NO WILDCARD，递归可以直接返回NXDOMAIN：

Caching of Negative DNS records（微软）

不同的权威软件、服务器返回的否定应答TTL策略相差较大，可能不直接按照SOA MINIMAL记录来设置，而是自己设定一个值。

Alexa Top 100w域名中，4.6%设的过高，0.1%设的过低。

否定缓存的TTL设置长短，影响记录误删除故障的恢复时间。建议SOA TTL 与 Min TTL 时间一致，且 < 3600s

Dealing with large DNS packet floods

Cloudflare Anycast 　+　域名分散配置NS(例如域名A用NS1,NS2域名B用NS3、NS4)

Iptables bpf （速度快，支持复杂匹配）：https://github.com/cloudflare/bpftools

直接查询 1k pps -> answer，间接查询 recursor 200k pps -> answer，伪造包查询 100m pps -> drop

Anycast : 非本地ip -> block；白名单recursor ip列表。

Drilling down into DNS DDoS Data Nominum

通过open resolver间接攻击的，一般是多ip (>1000)低流量

通过恶意IP攻击的，一般是大查询量 > 1000qps，IP数少；rutgers.edu

随机子域名攻击影响正常用户查询；权威流量限制可以有效保护未被攻击的域名体验，但对于被攻击的域名会有影响。

{random}.www.appledaily.com.tw 在40分钟内总查询量 735M，client 10.6M；攻击流量37.9M，攻击client 79.7 thousand，avg attack client qps = 0.2。

{random}.rutgers.edu 在60分钟内总查询量1.01billion，client 11.1Million；攻击查询19.1Million，client 238；avg qps / client = 22。

对合法查询域名的白名单；对随机域名查询的黑名单。

Everyday attacks against Verisign-operated DNS infrastructure

Verisign .com / .net 共 130 million 域名, A-root, J-root

110 billion DNS query/day

17个大节点（major internet exchange points）

69+ 小节点（regional sites）: .com / .net / J-root

网络：2+ Tbps 防御带宽（还在扩），EDGE节点支持BGP FlowSpec牵引攻击流量清洗

服务器：所有zone data载入内存数据库

过滤：核心路由器acl/flow spec/qos/mpls te；负载均衡系统 pkt size/query type/rate limits；实时自动化清洗 snmp + netflow + routing policy adjustments / filter deployment

自研dns软件

快速分配、调整查询资源；应用层过滤优先快速部署、往源端压

一些策略启动可能存在副作用，例如，block traffic / rrl

真实递归攻击

如果QNANME正好是NXDOMAIN，那么针对该QNAME的随机LABEL攻击会透传到上一级DNS 设施；有时候根也看得到。

开始过滤之后，递归启动重试风暴，流量本来打3million qps，可以冲到14 million qps。

递归最好对重试做限速，一般会重试4~5次；100%过滤随机QNAME攻击流量会倒逼流量增长 => RRL（有副作用）；与递归联系（不现实）；TLD处理（授权之后流量未必过TLD）；把随机攻击的域名引到特定的NS处理（反应时间问题）

EDNS0=9000，一般就是512、1024、2048、4096

ANY/DNSKEY查询放大攻击：入32bit，出2000+bit；大范围的IP地址；伪造源

zz.com式攻击：verisign被用作反射器，此时，需用RRL

涨带宽，涨单机性能，分散部署

RRL细调，避开OS层协议栈用户空间开销（0-copy），单机解析性能优化 6 million qps / 10 Gps

可扩展性，网络层多路传输；

Observations on DNSSEC and ECDSA in the wild

DNSSEC实际部署采用的加密算法探测，RSA/ECDSA，后者支持比例较小，但相对RSA的长度较短

Popularity ranking for domains based on DNS traffic

借鉴TF-IDF算法的思路，WORD -> DOMAIN, DOCUMENT -> SRC IP。

暂未考虑TTL的影响，以及根据SRC IP的重要性区分权重。

Query name minimization and authoritative server behavior Verisign

www.example.com :

简单的方案：com. => root , example.com. => com. , www.example.com. => example.com. ；中间有返回NXDOMAIN,则迭代查询立即停止

稍复杂的方案：中间查询NS记录；最终才查真实query type；对上级隐藏真实查询内容。

可能导致权威无法返回较优的结果（上层只查NS而非发具体域名具体QTYPE）；越上层cut的越多。

CDN用起来可能有问题。举了www.ietf.org.cdn.cloudflare.net.的例子，中间查cdn.cloudflare.net.是NXDOMAIN(而非NODATA)，直接断掉。

NXDOMAIN is an authoritative indication that the queried name doesn’t exist in the DNS (and that nothing below it exists either).

多层域名DDoS攻击；中间查询变多。

对根隐藏这个力度有点大。

Signing DNSSEC answers on the fly at the edge: challenges and solutions!

小查询量域名占多数；分布式网络（34个数据中心）；

RR动态生成；避免zone walking

Live Sign海量rrsig data，无法离线预测（这个主要是CDN业务的特殊性，应答与地理位置有关）

NSEC3没大用，NSEC5还没做。

三个关键点：速度；否定应答；密钥管理

目标：small size( key / signatures)，not require full zone files

自研DNS，后端采用数据库，支持dynamic answers，cname flattening等等

DNSSEC做为”filter”应用到answer上

ECDSA P256 签名速度比 RSA1024 快 3倍以上，用go重写之后加速21倍

NSEC3太重，调整成RFC4470/RFC4471推荐的white lies模式，类似于wildcard。也就是，当+dnssec时，把NXDOMAIN转成NOERROR，指向泛域名的RR。

Cloudfare 只sign NOERROR，true lies，域名配NSEC/RRSIG。

只是做一次签名，不需db lookup / zone walking。

此时，NSEC需区分NXDOMAIN，以及空RR：https://datatracker.ietf.org/doc/draft-ogud-fake-nxdomain-type/

查存在域名的不存在RR时，还是要查DB里的NSEC关系，然后在NSEC应答里全部返回。

ZSK分散到edge，KSK集中管理。

多个域名共用相同的KSK/ZSK。

The iDNS attack (resolver loop)

通过glue ns的多层NS授权，放大10倍攻击第三方；或者使得多层NS查询使得递归cache过多无效信息同时消耗CPU。

RFC1034只写了避免出现无限loop，没有具体约定，编程各自实现。

www.example.com -> NS1.EXAMPLE.COM -> NS2.EXAMPLE.COM/NS3.EXAMPLE.COM
-> NS4.EXAMPLE.COM/NS5.EXAMPLE.COM -> NS[6-16].EXAMPLE.COM (受害IP)

Update on experimental BIND features to rate-limit recursive queries

Client 查询量上涨；SERVER返回NXDOMAIN/SERVFAIL应答量上涨

时延，丢包，内存消耗，连接耗尽

递归检测到异常流量，临时充当“LIE”目标域名的权威（LOCAL ZONE/ DNS-RPZ），攻击结束后自动/手动恢复，all queries返回NXDOMAIN。可能误判。

直接应答SERVFAIL而非hold住等timeout（减轻递归压力）

递归监测 ratio = timeout / success（per server），自动调整阈值

SERVFAIL上升一般是权威被打僵了；NXDOMAIN上升可以启动LIE模式。

SERVFAIL/DROP/NXDOMAIN 哪个好。

可能要白名单。

内置auto-DNS-RPZ模块。

持久性的good RRSET（non-expiring），其实就是优先保证的东西。

Zonemaster - do we need another DNS testing tool?

开源的域名zone配置检查工具

sudo cpan -i Zonemaster

sudo cpan -i Zonemaster::CLI

https://github.com/pawal/zonemaster-collector

Published

19 May 2015

Tags


Share On