DNSSEC解释:为什么要在您的域上实现它

域名系统安全扩展提供了加密身份验证,以防止重定向到流氓网站,但是许多域的所有者尚未采用它。

挂锁/域名系统/ DNS / ICANN /安全
Alpesh Ambalal Patel /盖蒂图片社

DNSSEC定义

域名系统安全扩展(DNSSEC)是一组规范,通过为从权威DNS服务器收到的响应添加加密身份验证来扩展DNS协议。其目标是防御黑客用来将计算机定向到恶意网站和服务器的技术。虽然DNSSEC已经部署在许多通用和国家/地区级顶级域名(TLD)中,但在单个域名级别和最终用户级别的采用却落后了。

什么是DNS欺骗和劫持?

2008年,安全研究员Dan Kaminsky发现了DNS协议中的一个基本缺陷,该缺陷影响了使用最广泛的DNS服务器软件。该漏洞使外部攻击者能够毒害电信提供商和大型组织使用的DNS服务器的缓存,并迫使它们为DNS查询提供恶意响应,从而有可能将用户发送到欺骗性网站或恶意电子邮件服务器。

迄今为止,该缺陷被最大程度地协调了IT行业对安全漏洞的响应,但DNS劫持攻击的威胁依然存在。由于未对DNS流量进行身份验证或加密,因此任何攻击者在用户的DNS解析路径中控制DNS服务器都可以提供恶意响应,并将其重定向到恶意服务器-这是中间人的情况。

DNS就像互联网的电话簿。它允许计算机将人类可读的域名转换为他们需要通信的数字Internet协议(IP)地址,因为核心网络协议使用IP地址而非主机名。

域名系统具有层次结构,其顶部有13个服务器群集,用于管理所谓的根区域,然后是每个顶级域名(TLD)的服务器(如.com或.net或国家/地区代码TLD)(如.us)。或.ca,然后是每个特定域名的服务器(例如google.com),然后是单独的服务器,用于处理特定子域(例如cloud.google.com)。

每次客户端(例如计算机或设备)进行查询时,都会从顶部遍历此层次结构,直到找到用于查询主机名的权威DNS服务器并以IP地址作为响应。但是,为了提高DNS的性能,可以将响应在路径中的服务器中缓存一段时间。大多数设备本身不会查询根区域,但会查询充当解析器的本地DNS服务器,这又可能会查询另一个DNS解析器。例如,家用路由器通常充当DNS解析器,并且充当局域网中所有计算机和设备的DNS链中的第一跳。路由器通常还会将请求转发到客户ISP运营的DNS解析器。

了解DNS的工作原理非常重要,因为该链中的任何服务器都可能是薄弱环节,并且是攻击者可以提供恶意响应的起点。某些恶意软件会将计算机上的DNS设置更改为使用攻击者操作的DNS服务器,在这种情况下,受感染计算机的用户将受到影响。大规模攻击破坏了家用路由器上的DNS设置(这称为路由器篡改),影响了这些路由器所服务的网络的所有用户。其他攻击会破坏ISP的DNS解析器,在这种情况下,所有依赖那些服务器的ISP客户都可能受到影响。

输入DNSSEC

DNSSEC旨在解决这些风险,并通过数字签名提供加密验证,该数字签名可用于验证DNS响应中传递的记录来自提供查询域名的权威DNS服务器,并且在途中没有被更改。

像传输层安全性(TLS)和其他安全通信协议一样,DNSSEC依赖于公钥加密。每个权威名称服务器都有一个密钥对,该密钥对由私钥和公钥组成,并以密码方式链接在一起。私钥用于对记录(实际上是区域中的记录集)进行签名,并且签名本身会作为DNS记录发布。公钥可用于验证签名,也可存储在DNS记录中。

解析器如何确保签名和公钥来自真正的权威名称服务器而不是中间人攻击者?它们在层次结构链中更高一级,到达要验证其签名的子区域的父区域。例如,.com区域是google.com区域的父级,而。(root)区域是.com区域的父级。

DNS服务器使用的另一对私钥和公私钥对称为密钥签名密钥(KSK)。专用KSK密钥用于对用于签署记录的第一对密钥中的公用密钥进行签名。然后,将KSK的公共部分提供给父区域,该父区域将其发布为自己的子区域记录的一部分,并且本质上用于验证子区域中显示的信息是否有效。

总而言之,DNS解析器使用名称服务器的公钥来检查其提供的记录是否已使用其对应的私钥签名。然后,通过查看包含该密钥签名的另一条记录并将其与父区域中的记录(称为DS记录)进行比较,以确保服务器首先提供的公钥是合法的。它。这将在父区域和子区域之间建立信任链。

如果您在链中的地位越来越高,谁会验证用于签署Internet根DNS区域的最顶层密钥对?根密钥对在保存在安全位置的硬件安全模块中生成,并在 公开且经过高度审核的仪式 来自世界各地值得信赖的社区代表参与。在发生重大灾难时,还有一个密钥恢复过程,其中几个称为“恢复密钥共享持有者”的人需要在同一地方聚集在一起,并使用拥有的加密令牌来重建密钥。

什么不是DNSSEC

DNSSEC看起来不错,但不能解决DNS安全性的所有问题。首先,要发挥其最大的潜力,就必须在所有DNS区域,所有域和所有DNS解析器上的任何地方都对其进行支持和实施。我们离完美的世界还很远,攻击者可以将自己插入链中的差距仍然存在。

例如,经常听到的对DNSSEC的批评是对所谓的“最后一英里”缺乏保护。由于DNSSEC验证是由解析程序完成的,因此可以保护解析程序与该解析程序的用户之间DNS响应的完整性。例如,如果支持DNSSEC的解析器是家用路由器,则攻击者仍然可以破坏家用路由器并破坏“最后一英里”,并且 这种情况经常发生。

许多家用路由器,尤其是较旧的型号,可能不支持DNSSEC或未启用它。也许他们将查询转发到支持DNSSEC的DNS解析器,例如由ISP运行的解析器。那总比没有好,但是无担保的“最后一英里”现在已经扩展了。

DNSSEC也不提供机密性和保密性,因为DNS协议本身未加密。提供了数字签名以验证记录的完整性,但是记录本身仍为纯文本格式。某些国家的中间人攻击者,ISP或进行互联网监视的政府可以通过查看DNS查询来查看用户正在访问的域和网站。

他们还可以使用DNS阻止某些网站。某些国家/地区的ISP被迫通过法院或政府发布的命令来阻止访问某些被视为非法的其他网站,例如Bittorrent跟踪器,而这是通过DNS进行的。

DNSSEC并非旨在解决这些问题,其他协议(如TLS上的DNS(DoT)或HTTPs上的DNS(DoH))可用于加密最终用户与他们信任的DNS解析器之间的DNS通信。公用DNS解析器(例如Cloudflare的1.1.1.1,Google的8.8.8.8,Quad9的9.9.9.9等)都支持DNSSEC和DoT或DoH(通常两者),并且越来越受到用户的青睐,而不是出于商业或法律原因可能是其本地ISP的用户干扰或收集DNS流量数据。

DNSSEC部署和采用

APNIC是管理亚太地区IP地址的Internet注册表。 监视DNSSEC验证的项目 世界各地的。根据最新统计数据,全球DNSSEC验证率约为26%,但验证率因国家和地区而异。美国的DNSSEC验证率为30%,加拿大仅为17%,西欧为46%,东欧为26%,而非洲和亚洲约为24%。但是,在某些国家/地区,DNSSEC验证超过90%。

深入研究数据后,您发现例如在亚洲部分地区,主要的ISP就选择将DNS查询转发给Google的Public DNS解析器,而不是运行自己的本地DNS服务器,互联网协会开放组织的负责人Dan York标准无处不在的项目告诉CSO。他说,在其他地区,大型ISP近年来决定在其DNS解析器上打开DNSSEC验证,例如美国的Comcast。

DNSSEC部署有很多层。它始于2010年的第一个根密钥对的生成,但随后在经过数年的计划和执行的过渡过程中更新了密钥对,并于2018年10月完成。密钥对的公共部分必须是与互联网服务提供商,企业网络管理员,DNS解析器运营商,DNS解析器软件开发人员,系统集成商以及硬件和软件发行商共享,这是一个漫长的过程。

TLD和ccTLD运营商还必须生成并部署自己的密钥和流程,以为其各自的DNS区域启用DNSSEC。然后是单个域所有者实际上选择签署自己的记录的问题。

约克说:“部署正在继续。” “我认为在2015年至2018年之间会有一个停顿,而我们一直在等待根密钥的更改,运行DNS基础结构的人们希望等待,看看根密钥的过渡将如何进行。它于2018年和一切都很好,灯是绿色的,现在我们在图表中看到了DNSSEC部署的进展情况。”

根据约克的说法,在签署其域和旋转密钥方面存在一些挑战,尤其是在企业领域。如果域注册商也是DNS提供者并维护域的权威服务器,则它们可以自动进行签名并将签名记录传输到TLD以建立信任链,因此该过程非常无缝。但是,企业倾向于运行自己的DNS服务器,或者使用既不是注册商又是内容交付网络或DNS提供商,在这种情况下,他们需要自己处理此过程。

“当您在域上签名时,必须将此小记录(称为DS记录)提供给TLD注册管理机构-.org,.com,.bank等。这是验证您的信任链的一部分域已签名。”约克说。 “许多企业所面临的挑战是他们想去签署自己的记录..,但是随后他们必须确保在更改其签名密钥时,将其传达给TLD。通常,他们只需这样做一次一年,但这是一些企业感到笨拙的部分。”

过去曾发生过因DNSSEC配置错误或记录过期而无法使用网站的事件-NASA和HBO Now网站就是两个例子。相比之下,TLS / SSL行业和证书颁发机构已设法使涉及证书和密钥轮换的某些过程自动化。

约克说:“这是企业必须考虑的问题。” “正在进行中的工作。有一些标准可以使人们做到这一点。他们只需要了解这些东西的存在即可。”

约克说,这也有助于DNSSEC的部署 提高DANE的采用率 (基于DNS的命名实体认证)。这是一个依靠DNSSEC记录将TLS证书绑定到域名的协议,从本质上告诉客户端它们应该为特定服务器接受哪个TLS证书。这是为了防止TLS拦截,在TLS拦截中,位于用户和服务器之间的代理可以终止TLS连接,并使用其他证书将其提供给用户。即使没有由公共信任的证书颁发机构(CA)颁发的证书,也可以使用和信任由域通过DNS声明并与DNSSEC进行加密签名的证书。

约克说:“这在浏览器领域还没有取得成功,主要是因为涉及到额外的检查,浏览器侧重于性能和速度,但其中起作用的是安全电子邮件。” “越来越多的人使用DANE,然后再由DNSSEC签名,以做为从电子邮件服务器到电子邮件服务器的安全加密电子邮件的一种方式。这是一个有趣的方面,企业可以着眼于此:他们可以通过这种方式通过为电子邮件服务器提供这类记录来使其电子邮件更安全?”

1 2 Page 1
第1页,共2页