2019达拉斯DNS-OARC会议记录- Day2

1. ECS – Cloudflare

Cloudflare工程师讨论了ECS的相关问题,对于递归来说,根据RFC7871规范,需要传递用户的ECS信息(子网网段)到权威服务器,从而获得最佳的DNS解析。Cloundflare从线上对于实际的查询进行分析发现,所有的查询来源AS中:

  • 92/42338自治域发送IPv4 ECS
  • 25/42338发送发送IPv6 ECS
  • 查询类型中A地址查询IPv4的在个别区域中具有较高的ECS查询比例
  • 部分NS信息也携带了ECS信息

分享提到了关于ECS与QM的相关问题,如果一个递归服务器不实施Query Minimization的话,则尽量关闭使用ECS,否则容易导致用户隐私的泄露。

同时通过对比发现Google作为递归服务器,在实际使用上贡献了大部分的ECS的查询比例。

实际发现的情况是至少从cloudflare.net和cdn.cloudflare.net都存在ECS的发送。

2. DDoS攻击 – Infobox

主要介绍了随机子域名的攻击,导致权威服务器负载过高,资源消耗性攻击。这些攻击尽管随机,但是可以通过一些机器学习算法(非监督学习)来对其进行分类识别,找到相似的特性,甚至是定位到某一类攻击软件的行为。通过特性来分类比如: QNAME, 相似性以及查询类型,甚至是用于生成子域名的字典信息分类 通过将大量特性分类的数据汇聚来获得最终的聚合分类,如下图所示:

攻击聚合除了可以发现不同类型的攻击软件,甚至有可能定位到软件的变化,比如新增了哪些攻击模式等。当前攻击模式越来越复杂,即便是随机域名攻击,呈现出多类型查询,完全随机的模式。

提问期间,有工程师提到是否采取必要的措施去解决问题,但是该项工作看来至少当前还仅仅是对于攻击模式进行分析。

3. NSEC缓存 – APNIC

根据RFC8198中关于NSEC的介绍,任何DNSSEC签名的数据,如果递归服务器查询不存在,会返回解析数据中不存在的记录,(如果查询已知域名的NSEC记录,将不断轮序得到下一个域名签名的记录)并被缓存。18年CZNIC的Peter发过一些基于实验室的实验,但是APNIC此次是在实际线上运行测试的结果。

基于APNIC的广告测试平台,可以实现每天800万-1200万的广告投放次数,每一个广告可以包括一些HTML5脚本和NSEC实验内容。

  • 构造独一无二的DNSSEC签名域名和查询
  • DNSSEC响应NXDOMAIN和对应的NSEC信息
  • 循环不断的生成。

通过实验测试发现,30%的递归服务器通过支持DNSSEC验证的递归服务器,因此预计约30%的NSEC缓存比例,然而实际缓存效果并不如预期,大约7%左右。

可能的解释是因为DNS递归服务集群的配置导致负载分发,导致无法共享解析缓存。在实际的测试中也发现了超过一半的IP地址可以归为一个子网网段(/24的IPv4或者/48的IPv6),可以看做为来自于同一个递归集群。集群分发负载的方式决定了缓存共享的效率。

4. DNS中关于TTL的相关分析 – ISI

DNS的递归查询中,TTL用于存储缓存的数据,但是定义的是最大的缓存存储时间,一些递归服务器可能会根据自己的需求进行一些调整。另外也没有具体的指导原则关于如何设置合适的TTL。

TTL本身可以设置继承父级

不同类型可以设置不同的TTL

当前TTL设置普遍偏小比如5Min,一些过小的TTL可能导致不必要的查询负担且影响查询效率.

对于父级别中存在NS比如设置TTL1天,而实际的子级别中设置为1H则实际的测试发现,子级别中的TTL将被更新到递归服务器中缓存。

对于NS和A记录的设置,如果同一个区中NS设置4小时,而A记录设置8小时,则当NS记录过期的时候,A记录会被重新刷新。非区中的记录则相互独立缓存。

通过对多个域名的查询(root, 顶级域,Alexe列表 )发现大部分的域名设置的NS记录约1天及以上,而40%的域名设置过短的NS, 过短的TTL将导致整个的查询时间的延长 ,不管是使用Anycast还是普通的DNS服务解析。

结论是如果不需要CDN负载均衡 DNS重定向DDoS或者维护变更的时候,尽量设置较高的TTL 比如1天。提问阶段,有工程师提到过短的TTL,可能在需要做解析记录调整(紧急情况下)的时候出现问题,觉得一天时间过长。

5. 根服务器系统的长期性能分析 – Verisign

Versign工程师介绍了他们利用RIPENCC提供的探测网络进行的针对根服务器的数据分析, RIPEAtlas网络具有超过10000的探测节点,分布在全球。

针对根的探测主要是:

  • 利用hostname.bind来检查协议,地址及RTT
  • 随机顶级域名探测
  • 针对13个根的响应时间探测
  • 可用性测试
  • 延迟测试
  • 被篡改几率(使用Hostname.bind的查询)

测试发现:

  • IPv4的可用性约98%, IPv695%
  • 延迟的平均时间约25-50ms左右
  • 篡改几率约0.4%
6. 域名中的内容分析- ISI

分享通过对于DITL数据的分析(来自B根的数据), 介绍了根查询中存在的一些问题,提到了Chrome随机发送的DNS查询请求(启动的时候发送三个随机的域名,检查是否存在NXDOMAIN劫持问题)

  • 根查询中标签个数统计发现:1 >3 >4 >2
  • 统计按时段划分,发现部分顶级域名查询在某个时间点分布不合理(存在20分钟后突然流量消失)可能是一些CC网络的指令信息。
  • 不同长度的域名可能存在不同的模式,比如标签个数6,7以内 的相对比较稳定,而8,9的则表现比较周期性(机器查询?)
  • 甚至很多超过60+长度的标签长度

Macfee等反病毒软件会通过域名发送一些查询,这些查询可能与上面的标签异常有关系。

7. 对于DNSSEC 否定响应的相关研究- BYU

DNS查询和响应中对于签名的否定响应应答主要包含以下的四种方式:

  • 对于常规的NSEC,通过链式的方式进行,存在遍历域名的问题,
  • 对于NSEC3,将所有的第一个label进行Hash处理,从而可以避免直接遍历的方式,但是使用GPU计算的方式可以在比较短的时间内获得域名的结果(GPU-Based NSEC3 Hash Breaking NCA 2014)
  • White Lies: 权威服务器动态生成NSEC记录,包含之前和之后的记录的HASH值信息。要求可以实时计算生成。
  • Black Lies: 权威服务器动态生成NSEC记录(利用PrivateKey生成签名记录),对于不存在的域名,直接追加一个\000.作为不存在的标志位,对其进行签名生成NSEC以及RRSIG返回, 大幅度减少响应的数据量(利用NSEC方式)
cloudflare.com.     1799    IN  SOA ns3.cloudflare.com. dns.cloudflare.com. 2020742566 10000 2400 604800 3600
blog.cloudflare.com. 3599 IN NSEC \000.blog.cloudflare.com. RRSIG NSEC
cloudflare.com. 1799 IN RRSIG SOA 13 2 86400 20160220230013 20160218210013 35273 cloudflare.com. kgjtJDuuNC/yX8yWQpol4ZUUr8s8yAXZi26KWBI6S3HDtry2t6LnP1ou QK10Ut7DXO/XhyZddRBVj3pIpWYdBQ==
blog.cloudflare.com. 3599 IN RRSIG NSEC 13 3 3600 20160220230013 20160218210013 35273 cloudflare.com. 8BKAAS8EXNJbm8DxEI1OOBba8KaiimIuB47mPlteiZf3sVLGN1edsrXE +q+pHaSHEfYG5mHfCBJrbi6b3EoXOw==

分享主要介绍了他们如何利用NSEC Hash算法的两个值之间的距离来估算其签名区大小,发现99%的域名签名大小处于40个域名或更少的数量。

8. 定义DNS

RFC1034并未给出具体的定义, RFC8499给出的解释是DNS被定义在多个不同的RFC中,是一个简单的查询响应协议。Wiki定义是一个多层去中心化的名称系统服务,或者是连接互联网或者私有网络中的相关资源的服务。

但是DNS已经由一个数据库变为一个导航系统,数据库会给出你相同的答案,而导航系统则根据你选择的节点,给出不同的结果。

我们需要充分的信任递归服务器,选择递归服务器也变得越来越重要。设置本地递归服务器,或者内部递归服务器可以减少一定的风险

9. DANE/DNSSEC数据分析

分享介绍了通过采集监测数据来完成的DANE及DNSSEC相关的数据分析:

  • 分析发现了逐步增长的DANE/SMTP的使用(150万域名)
  • 约1000千万域名配置MX DNSSEC验证保护
  • 约7400DANE MX主机
  • 2.5亿域名内有1000多万签名DNSSEC
  • 320万使用ECDSA算法,但是还有很多人使用旧的RSA算法

DANE: 基于DNS的域名实体认证协议,允许使用DNS和DNSSEC的方式结合x.509证书来完成域名的认证。DANE配合SMTP服务提供邮件的安全保护措施,但是需要依赖于DNSSEC的部署,当前部署率仍比较低。

为了实现DANE, 客户端和服务器端都必须支持DNSSEC, 同时支持DANE协议,另外服务器证书必须被存储在DNS中而且必须DNSSEC被签名。

发表评论

电子邮件地址不会被公开。 必填项已用*标注