另一种方式是不管域名服务器，而是让 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 ，不过在这个方向上也有一些进展了。
GNU glibc 爆 gethostbyname 缓冲区溢出漏洞
glibc gethostbyname缓冲区溢出漏洞(CVE-2015-0235)