域名解析系统（DNS）是互联网安全的许多薄弱环节之一；可以将应用程序所访问的主机对应的 IP 地址误导到其它地方。也就是说，会连接到错误的位置，从而引发中间人man-in-the-middle攻击等等。而 DNSSEC 扩展协议则通过为 DNS 信息建立一条加密的可信通道来解决这个漏洞。在正确地配置好 DNSSEC 后，应用程序将可以得到可靠的主机查询信息。通过关于尝试将 DNSSEC 更好地集成到 GNU C 库里的讨论，我们知道，确保 DNS 查询信息安全这件事并不是那么简单。

从某种意义上来说，这个问题多年以前就解决了，我们可以配置一个本地域名服务实现完整的 DNSSEC 校验verification并允许应用程序通过 glibc 函数来使用该服务。DNSSEC 甚至还可以用于提高其他领域的安全性，比如，它可以携带 SSH 或 TLS 密钥指纹，让应用程序可以确认其在与正确的服务器对话。不过，当我们希望确认这条自称带有 DNSSEC 校验的 DNS 结果是不是真的已通过认证的时候 - 也就是说，当我们想依赖 DNSSEC 所承诺的安全的时候，事情变得有点复杂。

/etc/resolv.conf 问题

从 glibc 的角度来看，这个问题一部分是因为 glibc 本身并没有做 DNSSEC 校验，而是引用 /etc/resolv.conf 文件，从该文件里读出的服务器来做解析以及校验，再将结果返回给应用程序。如果应用程序使用底层 res_query() 接口，那结果中将会包含“已认证数据authenticated data”（AD）标识（如果域名服务器设定了的话）以表示 DNSSEC 校验已经成功。但是 glibc 却完全不知道提供这些结果的域名服务器的信用，所以它其实并不能告诉应用程序结果是否真的可靠。

由 glibc 的维护者 Carlos O'Donell 提出的建议是在 resolv.conf 文件里增加一个选项（dns-strip-dnssec-ad-bit）告诉 glibc 无条件移除 AD 标识。这个选项可以由各发行版设定，表示 DNSSEC 级别的 DNS 查询结果并不可靠。而一旦建立好合适的环境可以获得可靠的查询结果后，再移除这个选项。这样一来，虽然问题还没有完全解决，至少应用程序有依据来评价从 glibc 获取的 DNS 查询结果的可靠性。

一个可靠的环境配置应该是什么样？标准情况应该和这个差不太多：有一个本地域名服务器，通过环路loopback接口访问，作为访问 /etc/resolv.conf 文件的唯一条目。这个域名服务器应该配置来做校验，而在校验失败后就只是简单地不返回任何结果。绝大多数情况下，应用程序就不再需要关心 AD 标识，如果结果不可靠，应用程序就根本看不到。一些发行版已经倾向于这种模型，不过情况仍然不像一些人所设想的那么简单。

其中一个问题是，这种方式将 /etc/resolv.conf 文件放到整个系统可信任度的中心。但是，在一个典型的 Linux 系统里，有无数的 DHCP 客户端、网络脚本以及其他更多的程序可以修改这个文件。就像 Paul Wouters 所指出的，在短时间内锁定这个文件是不可能的。有时候这种修改是必须的：在一个无盘系统启动的时候，在自身的域名服务器启动之前也是需要域名服务的；一个系统的整个 DNS 环境也会根据所连接的网络不同而有所改变；运行在容器里的系统也最好是配置成使用宿主机的域名服务器；等等。

所以，现在一般认为，现有系统里的 /etc/resolv.conf 文件并不可信。于是有人提出增加另一个配置文件（/etc/secure-resolv.conf 或其他什么），但这并没有从根本上解决问题。除此之外，有些参与者觉得就算有一个运行在环路接口上的域名服务器也不是真正可靠，比如 Zack Weinberg 甚至建议系统管理员可以有意禁用 DNSSEC 确认validation。

既然当前系统里的配置不足以信任，那可以这样推断，在情况有改善能够取得可信的结果后，glibc 需要有一种方式来通知应用程序。可以是上面讨论的屏蔽 AD 标识的方式（或者与之相反，增加一个显示的“此域名服务器可以信任”选项）；当然，这都需要一定程度上锁定系统以免 /etc/resolv.conf 受到任何不可预计的修改。按 Petr Spacek 的建议，还有一种引申方式，就是提供一种途径允许应用程序查询 glibc 当前通讯的是不是本地域名服务器。

在 glibc 里来处理？

另一种方式是不管域名服务器，而是让 glibc 本身来做 DNSSEC 确认。不过，把这么大一坨加密相关代码放进 glibc 也是有很大阻力。这样将增加库本身的大小，从而感觉会增加使用它的应用程序的受攻击可能性。这个方向再引申一下，由 Zack 提出的建议，可以把确认相关代码放到域名服务缓冲守护进程（nscd）里。因为 nscd 也是 glibc 的一部分，由 glibc 开发人员维护，因此在一定程度上可以相信能正确执行 DNSSEC 确认。而且 nscd 的通讯 socket 所在位置也是公开的，所以可以不考虑 /etc/resolv.conf 问题。不过，Carlos 担心这种方式不能让那些不想使用 nscd 缓存功能的用户所接受；在他看来，基本可以排除 nscd 的方式。

所以，至少近期内，glibc 不太可能全部执行 DNSSEC 确认了的整个查询过程。这意味着，如果一个有安全考虑的应用要使用 glibc 库来查询域名，该库将需要提供一个标识来评价从独立域名服务器返回的结果有多大程度的可靠性。这几乎肯定需要发行版或系统管理员做出一些明确的改动。就像 Simo Sorce 说的那样：

如果 glibc 不使用明确的配置选项来通知应用程序它所用的域名解析是可信的，不会有什么用……不改一下还有很大弊端，因为应用程序开发者将马上认识到他们不能信任从 glibc 获取的任何信息，从而在处理 DNSSEC 相关信息时就简单地不用它。

要配置一个系统能正常使用 DNSSEC 需要改动该系统的很多组件 - 这是一个发行版范围的问题，需要时间来完全解决。在这个转变过程中 glibc 所扮演的角色很可能会比较小，但是很重要的一部分：如果应用程序不实现一套自己的域名解析代码，glibc 很可能是保证 DNS 结果可信的唯一方式。在一个系统中运行多个 DNSSEC 实现方式看起来不像是一种安全的方式，所以最好还是把事情做对了。

glibc 项目目前并没有确定用哪种方式来做这个事情，虽然从 /etc/resolv.conf 文件里的某些标记看上去快好了。这种改动应该需要发布新版本；考虑到 glibc 开发的保守天性，很可能来不及加入预计二月份发布的 2.23 版本了。所以 glibc 中暂时还不会有更高安全性的 DNSSEC ，不过在这个方向上也有一些进展了。