【转】用 BIND 搭建高可用性 DNSSEC Hidden Master Server

原文作者 Trusty Wolf 首发于 https://v2ex.com/t/266750

1. 关于 DNSSEC

关于 DNSSEC 的背景、目的和原理,强烈建议大家先阅读清华大学段海新老师的这篇文章,讲解的非常好,只是由于年代原因,其中 BIND 配置的章节已经过时,关于配置部分请大家参考下文。

简而言之,DNSSEC 通过数字签名的方法得以让用户验证 DNS 解析结果的真实性和完整性,但并不提供对 DNS 信息的加密,也就是说,在网络上传输的 DNS 信息依然是明文的,但是经过了可靠的签名。个人感觉这很类似于电子邮件领域的 PGP 签名,但 PGP 的公钥是自由发布的,可能并不可靠,而 DNSSEC 则建立了一套可靠的公钥基础设施(PKI),使得公钥像 SSL 证书一样也有了证书信任链。段老师的文章里还提到了可信锚(Trust Anchors),这就像 SSL 的根证书,在早些年 DNSSEC 的证书链还并未完善,有些顶级域的 DS 记录并未进入根域,这时候就需要 DNSSEC Look-aside Validation (DLV) 来提供证书信任链的支持,现在绝大部分的顶级域都已不再需要 DLV,ISC 也将于 2017 年停止对 DLV 的支持。

另一方面,DNSSEC 虽然是对现有 DNS 协议的扩展,但是对 DNS 报文的大小提出了更高的要求,支持 DNSSEC 的域名服务器必须支持 EDNS0(见 RFC2671),即允许 DNS 报文大小必须达到1220字节(而不是最初的 512 字节),在目前的实际操作中,DNS 报文大小通常是 4096字节。

我们来做一个小实验验证一下:

可以看到 udp: 4096 ,代表报文大小。并且 DNSSEC 的验证并不是直接查询一次递归服务器得到 RRSIG 记录就行了的,还需要查询上一级域中的 DS 记录才能完成验证,所以说如果 DNSSEC 被广泛部署和运用,无疑大量增加了 DNS 服务器和网络的负担,也成为了 DNSSEC 部署的最大阻力之一。

一个网域完成 DNSSEC 的部署需要以下前提条件:

  1. YOUR TOP-LEVEL DOMAIN (TLD) MUST BE SIGNEDTLD(顶级域的支持)
  2. YOUR DOMAIN REGISTRAR MUST SUPPORT DNSSEC(域名注册商的支持)
  3. YOUR DNS HOSTING PROVIDER MUST SUPPORT DNSSEC(DNS 服务提供商的支持)

早在 2010 年 5 月,ICANN 就已在全球 13 台 Root DNS Server 上部署了 DNSSEC,并设立了专门的网站。根据最近的 TLD DNSSEC Report,全球 1262 个 TLD 中已有 1093 个的 DS 记录被添加进了 Root Zone,也就是说 86.6% 的顶级域都已支持 DNSSEC。域名注册商的支持方面也取得了不小的进展,国外各大域名注册商都逐渐对 DNSSEC 的 DS 记录添加功能提供了支持,比如 GoDaddyNamecheapGandi.net 以及被 V2EXer 们讨论较多,性价比很高的NameSilo 等。具体的支持情况可以查询 ICANN 的 报表(不断更新中)。

如上所述,目前看来 DNSSEC 部署最薄弱的环节还是在 DNS 服务提供商提供的 Master DNS 和运营商的递归 DNS,当然,对于经济和技术实力有限的服务商来说,对 DNSSEC 保持谨慎的态度的确是一个明智的选择,因为在当今的网络环境中 DNS 非常脆弱,DNSSEC 并没有从根本上解决 DNS 服务本身的安全问题,针对 DNS 的 DDos 攻击依然存在,并且部署了 DNSSEC 之后被攻击所造成的后果可能更加严重,还可能产生新的隐私和安全问题,比如针对 DNSSEC NSEC 记录的恶意遍历攻击。

在公共递归 DNS 领域,Google Public DNS 从 2013 年开始支持 DNSSEC 查询请求。国内,CNNIC 的 SDNS云解析服务 也提供对 DNSSEC 的支持。而在运营商的递归 DNS 领域,国内基本还没有运营商支持 DNSSEC,下面给出验证一台递归 DNS 是否支持 DNSSEC 的方法。

如上所示,icann.org 是支持 DNSSEC 的域名,而 @1.2.4.8 指定了查询的 DNS 服务器(这里是 CNNIC 的公共 DNS ),当然如果不知道本地的递归 DNS 地址的话也可以留空。dig 查询到了 RRSIG 记录,证明该递归 DNS 支持 DNSSEC。

而在 DNS 服务提供商领域,几乎很少有支持 DNSSEC 的免费 DNS 托管服务,Dyn, Inc. 和 Amazon 等服务提供商都在收费 DNS 产品中提供了对 DNSSEC 的支持。特例也是有的,那就是大土豪 CDN 服务提供商 CloudFlare,在其与免费 CDN 所配套的 DNS 服务中提供了对 DNSSEC 的支持,并采用了 ECDSA 加密算法减少加密带来的服务器负担。

2. DNSSEC Test Project

好了,关于 DNSSEC 我们就介绍到这里,虽说 DNSSEC 有上述的缺点,但是作为一名励志成为大牛技术者的技术宅学生( 大雾,并不妨碍咱的学习,当然学习了解 DNSSEC 的最好的方法就是自己动手部署一个支持它的网域。下面咱就从一个网域管理员的角度从零开始用 BIND 进行部署 DNSSEC 的测试。

BIND 和 NSD 这两款常用的 DNS 服务器软件从很早的版本开始就已支持 DNSSEC。BIND 与 NSD 相比,虽然性能稍弱,但是相关的功能和文档都更加丰富,在各大 Linux 发行版的文档中都有 BIND 的身影,在 DNSSEC 领域更是如此,从 BIND 9.9 开始,新增了 Inline Signing 功能,这意味着 DNSSEC 的签名过程可以实现全自动,设定完毕后,平时的使用与维护操作与未导入 DNSSEC 功能时基本无异。

本次测试搭建的是 Hidden Master Server,关闭递归功能并开启区域传递,实际 DNS 查询流量由右侧的 Secondary DNS Server 负担,感谢 PUCK Free Secondary DNS ServiceRoller Network 提供免费并且支持 DNSSEC 的 Secondary DNS 服务,整体架构如下:

dnssec-inline-signing.png

为了实现高可用性,运用了 Inline Signing 并用无期限的 KSK 签署整个域,不使用 ZSK,避免了密钥的期限和更新问题。生成密钥的算法使用了 ECDSAP256SHA256 。

0)测试环境

其他的发行版可能在命令或者配置文件的位置上稍有不同,本文仅供参考。

1)系统准备

  • 系统安装和初始化设定(略)

  • SELinux 设定

    网络上的很多教程都在配置 BIND 时关闭了 SELinuxSELinux 严格控制着 BIND 对配置目录的访问和读写权限,这对提升 BIND 的安全性有极大的帮助,但也对配置文件存放的位置有了严格的要求,稍有差错 BIND 进程就会无法启动。CentOS 7 运行 named-chroot 时无需更改配置文件的位置。经实际测试后发现named-chrootSELinux 并无冲突且无需对SELinux的规则作出修改,故出于安全考虑本次实验中开启 SELinux。

    参考资料:1. SELinux-DNS 2. RHEL 7 网络指南中关于 BIND 的章节

    其中 RHEL 7 网络指南中详细说明了 BIND 的各项配置文件的存放位置。

  • 防火墙(Firewalld)设定

  • BIND 安装

    安装之后系统默认会生成 /etc/rndc.key,但是安全性较低,咱重新生成一个较高安全性的

    默认配置下的 BIND 是一个支持 DNSSEC 的递归 DNS,但只能供本机查询

  • Secondary DNS 服务商的设定 (略)

2)DNSSEC Master Server 的部署

  • 配置文件的修改

    请参考 RHEL 7 的官方文档:

  • Zone 文件的修改、密钥生成和权限管理

    稍微解释一下密钥生成时的参数:-a 密钥算法 -f 密钥类型(如果是ZSK,不需要此参数) -r 乱数来源 -K 输出目录

    生成了一对 KSK 密钥对 Kwolflab.net.+013+27278.keyKwolflab.net.+013+27278.private,其中的 13 代表算法,而 27278 则是 KEY Tag,一会去域名注册商的控制面板添加 DS 记录时会用到。

    named.conf 中 Zone 的配置里 update-check-ksk no; 代表忽略 ZSK 密钥,只使用 KSK 签署整个域,auto-dnssec maintain; 开启密钥的自动更新和配置。

  • 配置检查,测试

    可以看到 dig 查询到了 RRSIG 记录,并且其中的 KEY-ID 27278 与之前生成的一致,部署成功!

  • 将 NSEC 记录转换为 NSEC3 记录

    关于 NSEC 和 NSEC3 的区别,请看这里,如果懂日语的话也可以参考这里,不得不说日本人画画的功力超级强大,复杂的技术几幅图就可以搞明白了 QAQ

    默认情况下,DNSSEC 使用 NSEC 记录来提供对不存在域名查询的确认,但这样也带来了一定的隐私问题,并造成了可以被递归攻击的可能,NSEC3 用哈希算法解决了这一问题,但这也会增加数据包的大小,造成一定的负担。

    我们随便 dig 查询一个不存在的域名,可以看到,目前使用的是 NSEC记录,并且 dnssec.wolflab.net 这个真实存在的域名也暴露了,如果不希望这样,可以切换至 NSEC3 记录。

    配置上,由 NSEC 切换至 NSEC3 非常简单:

    这里的 10 是 NSEC3 使用的 Iteration 值,保持默认即可,而 macadd 是 Salt 值,是一个 16 进制数,且位数是 2 的倍数,咱这边取了 6 位。当然,你也可以随机生成它,使用下边的命令:

    这样应该更加稳妥并安全一些。我们在本地再次用 dig 查询一下:

    可以看到,NSEC3 已经启用成功,这样就很难知道dnssec.wolflab.net 这个域名是真实存在的了。

  • DS 记录的生成和上传

    经过以上步骤的测试,wolflab.net的 DNSSEC 记录已经符合规范。到这里可千万不能高兴太早,因为最后也是最重要的一部并没有完成:DS 记录的生成和上传。

    读过段老师的文章后,我们知道了 DS 记录其实就是之前生成的公钥的哈希值,用来提交给上一级的域名服务器。如果没有 DS 记录,那么这台 DNSSEC Master Server 公钥的真实性就没法得到证明,之前所有的努力都功亏一篑了。

    得到 DS 记录的方法有两种:

    得到之后我们就可以去域名注册商的管理面板里添加这两行记录了,这里我以 NameSilo 为例:

    dnssec-ds-1.jpg

    全部添加完毕之后应该是这样的:

    dnssec-ds-2.jpg

    验证一下结果:

  • DNSSEC 在线检验工具

    DNSSEC Debugger

    dnssec-check-1.jpg

    DNSViz

    dnssec-check-2.jpg
    前者速度较快,能够快速确定问题所在,后者比较直观,信息量更大。

3)DNSSEC Master Server 的后续维护和管理

由于此次搭建的是高可用性 DNSSEC Master Server,并没有设置密钥的有效期,而且整个签署过程都是自动完成的。所以维护起来相当方便,不会造成因为密钥过期等原因导致的认证故障。

当对 Zone 进行过修改后,使用 rndc reload 命令即可完成对整个域的重新签署,无需人工干预。

但是出于安全考虑,强烈建议定期重新生成 KSK 密钥并更新 DS 记录,并确保密钥文件权限的正确。

3. DNSSEC 的其他应用

DNSSEC 除了可以验证域名解析结果之外,还可以与 TLSA 记录结合用来验证 x509 (SSL) 证书的真实性。这种技术被成为 DNS-based Authentication of Named Entities (DANE),被定义于 RFC 6698。

生成 TSLA 的过程也很简单:

其中 server.crt 就是 SSL 证书。

然后在 Zone 文件中添加如下的记录:

dnssec 是原有的记录,可以按需替换为 www 等。之后使用 rndc reload 命令重新自动配置 BIND。

使用 CZ.NIC Labs 提供的两款浏览器插件可以得到更加直观的显示效果,如图:

dnssec-tlsa.jpg

这款插件也可以对 DNSSEC 进行检测。

4. 总结

从 1997 年第一个有关 DNSSEC 的标准 RFC 2065 发布至今已经快 20 年了,但是很显然还有很漫长的路要走。

最后很想用一个小时候看的动画片《春田花花同学会》里校长一段很经典的台词来结束这篇文章,也算是抒发一下心中的感慨了。

各位同学,本校创校快将五十年,未够五十年,但是,差不多五十年啦。很快,本校创校就要超过五十年啦。
恩,在这接近五十年,未够五十年间,本校已经为社会培养了很多条栋梁,很块,本校会为社会培养出更多条栋梁。
也许有人会问,校长,你在这五十年里,培养了这么多条社会栋梁,实际上,又有什么用呢?在这,我可以很清楚地告诉大家,本校创办,还要很久才够五十周年。
至于本校会不会有机会去庆祝我们的五十周年呢?为我们的社会,培养出更多的栋梁。就要看本校这个月……能不能受齐同学的学费啦。谢谢各位。

在技术进步的路上,的确还有很多的学费要交。不研究历史的人,注定要重复历史。

最后,感谢方校长,让我下定决心踏上异国求学之路。

Trusty Wolf

2016年3月28日于东京

Ps. 由于目前支持 DNSSEC 的免费 Secondary DNS 服务太少且都集中在欧美,如果您觉得这篇文章对您有所帮助且您有长期稳定运行并支持 DNSSEC 的 DNS 服务器,希望您也能为 wolflab.net 提供 Secondary DNS QAQ

PPs. @CloudXNS 你家的 DNS 蜘蛛简直丧心病狂 Log满屏幕的 *.ns.dns-spider.ffdns.net 和 *.ns.dns-spider.myxns.cn Orz

本文使用 CC BY-NC-SA 4.0 授权协议

【转】用 BIND 搭建高可用性 DNSSEC Hidden Master Server 有 12 个评论

  1. 新喵未来有打算把煮鸡壳的DNS也部署上这个吗?那样就太好了
    PS:Let’s Encrypt前几天部署上了新的中间证书,不知道煮鸡壳面板renew过后会不会变成Let’s Encrypt X3/X4的中间证书呢?

  2. 从loli.com扒过来 快告诉我 那个网站为啥永远只有一个首页。。。。

发表评论

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