域名解析系统（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 里来处理？