DNSPod十问吴洪声:云时代,DNS面临哪些安全挑战？

腾讯云DNSPod团队

发布于 2020-08-07 11:10:47

1.6K0

发布于 2020-08-07 11:10:47

8月5日，腾讯云中小企业产品中心总经理吴洪声受邀以演讲嘉宾的身份参加第八届互联网安全大会（简称“ISC 2020”），演讲主题为《DNS在云时代的安全挑战及应对》。ISC安全大会是亚太地区规格最高、规模最大的安全峰会，吴洪声于本次会议云安全论坛中，阐述了DNS在云时代下所面临的问题和安全建设方案，并分享了腾讯云在DNS安全领域积累多年的实战经验。

今天这一期的十问是DNS安全的特别专题。现在主流的DNS安全方案有哪些缺陷？关于云上DNS安全，腾讯云今天的运营数据现状如何？又对未来做了哪些布局？关于上述问题，本次DNSPod十问栏目的第12期，将结合吴洪声ISC 2020演讲内容一一为各位解读。

嘉宾介绍：

吴洪声（人称：奶罩）：第八届互联网安全大会演讲嘉宾，腾讯云中小企业产品中心总经理，DNSPod创始人，洋葱令牌创始人，网络安全专家，域名及DNS技术专家，知名个人站长，中欧国际工商学院校友。

以下为吴洪声在第八届互联网安全大会云论坛的演讲 ——《DNS在云时代的安全挑战及应对》全文。

正文：大家好，我是来自腾讯云DNSPod的吴洪声，今天很高兴可以在这里与大家分享一下云时代的DNS安全挑战和我们所做的一些应对。DNS作为互联网的基础协议，它的安全关乎着整个互联网的安全。

我们知道DNS是用户浏览网络的第一步，没有DNS则意味着没有互联网业务。DNS系统对互联网应用至关重要，使得它成为了黑客的主要攻击目标。

这里我举一个典型的攻击案例。就在2016年的10月份，北美地区的重要域名服务商D Y N公司，遭到了强烈的DDos攻击，导致北美地区大规模的网络瘫痪。大量用户反馈互联网网站无法正常访问，其中包括北美用户最常用的推特、纽约时报等重要网站。这一次针对DNS系统的攻击，影响范围巨大，引起了美国政府和军方的高度重视和警觉。

而这个案例只是众多DNS攻击案例中的一个。统计数据表明，在城域网级别的DNS 流量中，大约有万分之一到万分之五的 DNS 请求是恶意的。2020年，有百分之七十九的组织遭受了DNS攻击，攻击造成的损失平均高达92.4万美元。

一般来说，有哪些DNS攻击方式呢？

现在常见的DNS攻击，有大流量DoS攻击、基于DNS的漏洞攻击、还有DNS劫持、欺骗等各种攻击方式。这些DNS攻击可能针对的是DNS服务商，也可能针对的是某个企业，也可能针对的是个人用户。

这里我想重点讲一下DNS劫持、欺骗攻击。

DNS劫持、欺骗攻击，是指通过劫持DNS请求、发送欺诈性DNS响应报文造成DNS缓存毒化等方式，引导用户访问恶意网站。这种攻击方式会直接造成严重的信息泄漏和经济损失。

先简单介绍一下，DNS为什么会被劫持和欺骗。首先，DNS协议缺乏对源的验证，无法验证报文来源的合法性和对端的身份。其次，DNS缺乏对数据的校验，无法确认数据是否被篡改。除此之外，DNS协议是明文传输的，全流程都缺乏对数据的加密保护，流量在网络上可以被监听到。

针对DNS的这些问题，人们设计了很多安全方案来弥补这些缺陷。比如使用DNS Cookie，可以在一定程度上验证报文的来源是否正确。使用0x20 Encode方案，也能具备一定的数据校验能力等。

1.DNSSEC – 缺陷与挑战

DNSSEC方案用于增强DNS数据验证的强度。DNS数据所有者为DNS数据生成数字签名，这个签名的合法性能被验证是否有效。如果签名未通过验证，则意味着这条DNS数据可能是非法的，应该直接被丢弃。

也就是说，DNSSEC方案具备有数据完整性校验功能，可以确保所接收到的DNS数据来源的合法性和数据的完整性，解决了数据校验安全性不足的问题。

但是DNSSEC也不是尽善尽美的，它并不能完全解决DNS劫持的问题。

我们来看一下PPT的这张图。我们以bra.run这个域名来举例。用户发起了一个DNS查询请求，如果被查询的域名开启了DNSSEC，首先会由根DNS节点返回.run的签名数据，然后.run的DNS节点又会返回bra.run的签名数据，最后bra.run的DNS节点，会返回对应的A记录和相关的签名数据。整个查询过程就和套娃一样，一层套一层。通过链条的方式保证数据是准确并且未被篡改。

但我们再来设想另外一个场景，用户在发起bra.run的DNS查询时，如果攻击者进行了抢答，给用户返回了被篡改的数据包，那么会怎么样？因为DNSSEC并不是一个强制的option，客户端需要拿到根DNS服务器返回的数据包才能知道这个域名是否开启了DNSSEC。所以当攻击者抢在根服务器返回前响应了用户，抢先传输回一个并不包含签名的域名数据包给到用户，用户会误以为域名并不支持DNSSEC，那么客户端就会采纳攻击者返回的恶意响应，访问到攻击者返回的恶意IP。

所以，DNSSEC并不能百分百的解决域名劫持的问题。

除了上述问题外，DNSSEC还存在其他的缺陷。

首先，目前使用DNSSEC方案的DNS流量很少。DNSSEC方案实际效果有限，而且会加大服务商的资源负担，因此，虽然ICANN对域名注册局和服务商提出了部署DNSSEC的要求，但因为成本和收益问题，服务商的积极性并不高。

其次，正是因为DNSSEC并不是DNS流程的必选项，它可能被客户端解析忽略。DNSSEC不仅需要服务商支持，还需要客户端解析器的支持才能起作用。如果客户端解析器版本太老旧，或者被攻击者篡改过配置，即使服务商支持DNSSEC，也无法起到保护效果。

再次，DNSSEC安全机制基于从根证书开始的完整证书链。也就是说，为了使DNSSEC起作用，需要从顶级域开始逐级对域名进行签名，这形成了一个证书链条。为了保证DNSSEC的安全，整个证书链条必须从根密钥开始是不间断的，任何中断都可能导致无法验证DNS记录。

还有，DNSSEC方案对查询失败的处理做的不够好。DNSSEC方案中规定了如何对成功响应的域名签名，但如果服务器响应的是空域名，空域名是不具备签名的。这为攻击者实施抢答攻击提供了条件，攻击者可以抢答一个空域名误导用户。更进一步看，如果攻击者抢答了一个错误的域名，DNSSEC方案虽然可以识别到错误，但它也得不到正确的结果。

最后，DNSSEC会增加服务器的负担。使用DNSSEC方案，服务器需要为每个域名生成对应的签名。如果采用静态签名的方法，服务器需要消耗大量的存储资源存储这些域名的签名文件。如果采用动态生成签名的方法，又会给服务器带来巨大的计算性能压力。同时，启用DNSSEC方案会增大DNS报文，也就会增大服务器的网络流量压力。

因此，我们认为DNSSEC方案在使用场景上还存在很多局限，这个方案不能完全避免被劫持，也不能避免诸如ISP厂商对域名请求的监控和阻断，而且就算发现数据被篡改，也只能丢弃数据，得不到正确的结果。

2.安全方案 – DoT/DoH

在讲DoT/DoH方案前，我们思考一下，用户会希望拥有一个什么样的DNS系统？

DNS系统类似于因特网的电话簿，它应当是私密的，是不容易被监控和探测的。然而默认情况下，DNS查询和响应以明文的方式发送，这意味着ISP或任何能够监视传输的人，都能监视到用户的上网行为。即使我们使用了HTTPS来浏览网页，我们也无法避免DNS请求记录被暴露。如果DNS查询不是私密的，恶意的攻击者、广告商就可以跟踪用户的在线行为。

DoT/DoH方案可以非常好的解决这些问题。DoT方案是指利用TLS加密传输的DNS数据，DoH方案是指通过HTTPs协议传输DNS解析请求和响应。两个方案都是基于TLS协议。利用它可以实现了基于证书的DNS通信双方身份认证和数据加密，从而保证了数据不被攻击者窃听或篡改。

DoT/DoH方案已经成为了标准组织的定稿标准，得到了整个产业链的积极认可。除了标准组织的大力推行外，DoT/DoH方案也得到了来自浏览器厂商，移动设备，路由设备、云服务商等的大力支持。现在用户已经可以非常方便的接入到DoT/DoH服务。

前面我们提到DNSSEC的不足，那么DoT/DoH方案是如何解决这些问题的呢？

首先第一点，使用了DoH/DoT方案，用户传输给服务器的请求包就已经是加密的，这样攻击者就无法知晓用户希望访问的域名。

其次，用户和服务器之间建立了连接通道，经过了TCP的3次握手，TCP连接外的数据会被直接丢弃掉。也就是说，攻击者发送的数据实际上是连接之外的数据，攻击者传输给用户的数据包都会遭到用户侧的丢弃。

最重要的是，用户和服务器之间的传输，已经形成了加密的机制。解密的方式只有用户和服务器双方知道，攻击者没有办法创建出合理的加密报文。

下面给各位展示一下，使用DoH前后的抓包效果。

第一个图是标准的DNS查询，从抓包结果看，用户的DNS请求信息与服务器的响应信息都以纯文本的方式传输。我们能看到用户请求的域名名称，得到的响应IP地址。

第二个图是DoH方案的抓包结果。可以看到报文从UDP报文转变成了TLS报文。用户数据被隐藏在了TLS的加密数据里，即便是遭到了拦截，第三方也无法得到用户具体的访问信息。

除了DoT/DoH外，还有同样用于解决DNS劫持问题的HttpSDNS方案，腾讯云目前已经全面部署了HttpsDNS，可以更好的为用户提供DNS防劫持保护。

DoT/DoH不管在安全性还是先进性上，都体现了充分的优势，这里我再谈一下DoT/DoH的一些问题。

首先，是DoT/DoH方案带来的性能挑战：

第一点是计算资源挑战。TLS握手流程的计算量很大，涉及到大量动态的加解密，这会对现有服务器计算资源产生巨大挑战。在计算资源需求剧增的条件下，DNS服务商需要审视原有的服务架构是否能满足需求，这可能会产生新的服务架构设计。

第二点是业务时延挑战。与原有的UDP流程相比，新的DNS查询流程是基于TCP和TLS，增加了握手、认证、密钥协商之类的流程，它不可避免的会增加业务的查询时延。DNS时延的增加，可能会引起整个业务体验的下降。这需要在客户端、路由侧做额外的设计，来降低时延带来的影响。

这里重点强调一下，腾讯云在针对加解密和网络性能上做了积极的优化，取得了非常优秀的效果。腾讯云的最佳实践方案，可以将业务时延影响降低到接近于0。

第二是加密方案带来了监管难题

DoT/DoH对用户隐私安全有着积极的意义，加密后的DNS请求，无法被旁路设备所获取到，从而带来了监管难题。企业或家长可能希望自己的员工或者孩子不要去访问某些网站，政府部门也会有对域名的监管需求。如何寻找到隐私和监管之间的平衡点，还需要做更多的探索。

同时业界对DoH方案也有担忧的声音出现。DNS设计先驱Paul Vixie就曾尖锐的指出，DoH方案将DNS流量作为HTTPS流量对待，可能会危及到整个HTTPS生态的安全。

第三是，DoT/DoH方案如何实现全链路安全

DoT/DoH并不是全链路安全方案。它工作在客户端到递归服务器之间，递归服务之后的路径，则需要额外的安全保护。

从图中可以看到，客户端和递归服务之间建立了DoH通道，客户端的域名请求数据被有效保护了。但是DoH方案并不能保护递归服务器之后的DNS递归查询数据。如果递归服务器到权威服务器之间的查询被劫持或污染，递归服务器返回的也将是被污染后的结果。那DoH保护的意义就没有了。

这里我们可以使用多种安全协议结合的办法。比如在递归到权威服务器之间强制实行DNSSEC，通过DNSSEC对后端链路的数据进行强校验来保证数据的完整性，弥补DoH方案保护范围不足的缺陷。递归服务器可以通过修改代码，读取whois信息中的DNSSEC签名状态，来判断一个域名是否打开了DNSSEC，并进行数据的校验。

第四是DOH的域名解析难题

因为DOH是基于HTTPS协议，所以大部分的DOH服务器，都是通过域名来访问的。但是，一旦涉及到域名，就必须要涉及到DNS解析。所以这就产生了一个先有鸡还是先有蛋的问题。客户端首先需要对DOH的域名解析出IP地址，连接上DOH的服务器，才能解析其他域名。如果DOH服务的域名被劫持，那么就会导致用户无法解析出正确的DOH服务器IP，从而导致无法使用DOH服务。如果DOH服务器不是用域名，而是改为IP地址访问的方式，又会导致DOH服务器的IP地址被封禁。虽然TLS 1.3提出了ESNI来加密HTTPS协议中的域名，但ESNI又依赖于DOH。所以这里似乎是个无解的难题。

另外，浏览器厂商可能会对DoH服务商的域名安全带来挑战。传统DNS时代，用户大多使用的是系统的DNS配置。但DoH技术的出现，域名解析从操作系统层面，变成了浏览器层面。会让用户更多的依赖浏览器中的DNS配置。浏览器可以在此充当DoH服务商域名劫持者的角色，它可以决定解析流量往哪里走。在DoH技术流行的时代，浏览器厂商的影响力被大大增强了。

3.云上DNS安全

前面我们讲了当前行业中的一些主流的DNS安全技术方案，接下来我想从云服务商的角度来说一下DNS安全对云厂商的重要性。

云DNS安全对云服务的重要性不言而喻。企业对云服务日益依赖，DNS的安全性已成为云服务安全的“头等大事”。

在我看来，云上DNS安全显著具备以下几个特征：

首先，云DNS服务需要具备极强的DDoS防御能力。

当前，针对云DNS服务的DDoS攻击，在规模和频次上逐渐上升。带宽越来越便宜，可利用设备越来越多，云上DNS如何才能承受住日益增长的高流量DDoS攻击，是云服务稳定性的关键。

其次，云服务应当部署强有力的安全方案，承担起DNS安全方案的推广责任。云服务商对安全方案的支持程度，决定了客户的DNS安全，甚至决定了客户整个网络架构的安全。

4.腾讯云DNS安全方案

和大家分享一些我们腾讯云DNS安全方案的运营数据：

第一是我们腾讯云的HTTPDNS方案，目前我们的HTTPDNS已经覆盖了超过10亿的终端用户。QPS数超过了500万，日请求量超过了1500亿次。

另外我们的DoT/DoH方案也开始对外提供服务，大家现在可以使用域名dns.pub接入到腾讯云的DoT/DoH服务。

前面说的是运营数据，接下来我们给大家公布一下我们的在性能优化上的最新数据。

目前我们的HTTPDNS在单机环境下，加解密性能达到了160万QPS的水平。

我们的DoH服务，在不使用硬件卡的情况下，达到了8.5万的QPS，使用加速卡可以达到20万的QPS。

然后，腾讯云DNSSEC静态签名的性能，在 40G的网卡下可以达到一千八百五十万QPS。纯动态签名可以达到30万QPS

上面是我们腾讯云的性能和运营数据，最后，我想谈谈DNS安全的未来。

近年来针对DNS的攻击，越来越精细化，从之前的大流量DDOS演变成低信号攻击。特别是在全球新冠肺炎大流行期间，使用混合云环境的企业增多，部署在混合云的关键业务也在增加，DNS攻击者越来越多地将目标对准云计算。遭受云服务停机影响的公司从2019年的41％增长到2020年的50％，大幅增长了近22％。

Cisco公司在2016年提出了一个『DNS盲点』的概念，说的是有91%的恶意软件会使用 DNS 作为攻击手段，但 68%的企业却没有意识到这个严重的安全问题

现在，这个现象正在逐渐的好转。最近几年，随着DNS安全问题的揭露，大量企业和个人开始重视DNS安全，越来越多厂商都加大了投入，这对于DNS行业的发展起到了很大的促进作用。

5.DNS安全前景展望

对于DNS的未来发展，我觉得可能会有几点：

第一，未来针对DNS的攻击，会从大流量逐步转为精细化的精准攻击，威胁会更严重，更难被发现。因此，我们建议企业的架构师，在做整体安全系统设计时，必须将DNS安全性作为系统安全设计的重要部分。

第二，我认为需要关注全链路保护的技术标准。DNS安全应该，也必须是全链路安全，是多安全机制结合的安全。多协议的结合和安全标准化的推广，将更有利于DNS安全的发展。

第三，个人隐私需要被保护，DNS流量也需要被监管，我们需要在其中找到一个平衡点。个人用户通常希望自己的行为是完全自由的，但完全脱离监管的网络也不是安全的。DNSSEC方案没有对数据做加密，只是对数据做了签名，这可以认为是它在设计上的一个妥协。DoH则是将数据完全隐藏在了加密流量里，如何解决监管难题，平衡隐私与监管之间的关系，也会是DNS安全积极探索的方向。

以上是我的分享，谢谢大家！

（栏目统筹：赵九州责任编辑：张洁张琪瑶杨佳屹）

SMB

腾讯云中小企业产品中心

腾讯云中小企业产品中心（简称SMB），作为腾讯云体系中唯一专业服务于8000万中小企业的业务线，致力于为中小微企业提供全面完善贴心的数字化解决方案。产品线覆盖了企业客户从创业起步期、规范治理期、规模化增长期、战略升级期等全生命周期，针对性的解决企业的信息化、数字化、智能化的生产力升级需求。本中心还拥有两大独立腾讯子品牌：DNSPod与Discuz!，在过去15年间，为超过500万企业级客户提供了强大、优质、稳定的IT服务。

SMB团队成员大多都有过创业经历，有获得过知名VC数千万投资的，有被一线互联网巨头以数千万全资收购的，也有开设数十家分公司后技术转型而失败倒闭的，我们成功过，也失败过，我们深知创办企业的难处与痛点，深刻的理解中小企业该如何敏捷起步、规范治理、规模化增长与数字化升级发展，我们会用自己踩坑的经验给出最适合你的答案。

腾讯云中小企业产品中心，助力中小企业数字化升级的好伙伴。