4.6. 用 DNSSEC 保护 DNS 流量

4.6.1. 介绍 DNSSEC

DNSSEC是一套“ 域名系统安全扩展 ”(DNSSEC,Domain Name System Security Extensions) ,能让“ 域名系统 ”(DNS,Domain Name System)客户端进行身份验证以及检查来自 DNS 域名服务器响应的完整性,以此鉴定它们的来源,并判断它们是否在传输过程中被篡改过。

4.6.2. 了解 DNSSEC

对于通过互联网连接,现在有越来越多的网站使用 超文本传输协议安全(HTTPS,Hyper Test Transfer Protocol Security) 来提供安全的链接。然而,除非您直接输入 IP 地址,在连接到 HTTPS 网络服务器之前,必须执行 DNS 查询。由于缺少身份验证,执行这些 DNS 查询是不安全的,且会遭到“ 中间人 ”攻击( MITM , man-in-the-middle attacks)。换句话说, DNS 客户端无法确信疑似来自特定的 DNS 域名服务器的应答是否可信,以及是否被篡改过。更重要的是,递归服务器无法确定从其他域名服务器获取的记录是真实的。 DNS 协议无法提供客户端可确保不遭受中间人攻击的机制。 DNSSEC 的引入解决了在使用 DNS 解析域名时,缺少身份验证和完整性检查的问题。但它不能解决机密性的问题。
DNSSEC 所发布的信息包括 DNS 资源记录的数字签字和公用加密密钥的分配,以这样的方式让 DNS 解析器建立起多层次的信息链。因所有 DNS 资源记录而生成的数字签名,添加到此 DNS 区域作为资源记录签名(RRSIG)。此区域所添加的公用加密密钥作为资源记录的域名系统密钥( DNSKEY )。要建立起多层次的信息链,则须将 DNSKEY 的散列值发布到父区域作为“ 代理签名 ”(DS,Delegation of Signing)资源记录。要验证不存在性,则须使用 NextSECureNSEC,下一代安全)和 NSEC3 (NSEC的替换或备用方案)资源记录。在 DNSSEC 区域签名中,每一个“ 资源记录集 ”(RRset,resource record set) 都有其对应的 RRSIG 资源记录。请注意, 用作子区域代理的记录(域名服务器粘附记录,NS and glue records)并没有进行签名;这些记录要显示在子区域,并在此区域进行签名。
运用 root 区域公用加密密钥进行配置的解析器会完成处理 DNSSEC 的信息。使用这种密钥,解析器可以验证用于 root 区域的签名。例如, root 区域对 .com 的 DS 记录进行签名。 root 区域也为 .com 域名服务器提供域名服务器粘附记录。解析器会跟踪代理和查询使用代理域名服务器 .com 的DNSKEY 记录。所获取的 DNSKEY 记录散列值应当与 root 区域的 DS 记录相匹配。如果匹配,则解析器将会信任所获取的 .com DNSKEY 。在 .com 区域内, RRSIG 记录是由 .com DNSKEY 所创建。同样地,在 .com 中的代理也是重复此程序,例如 redhat.com。用这种方法,尽管 DNS 验证解析器在其正常操作期间收集了很多 DNSKEY ,但只需用一个 root 密钥对其进行配置。如果密码检查失败了,则解析器将 SERVFAIL 会返回给应用程序。
DNSSEC 的设计是根据以下这种方式:对于不支持 DNSSEC 的应用程序完全不可见。如果非 DNSSEC 应用程序查询支持 DNSSEC的解析器 ,则它所接收的答复没有任何新资源记录类型,如 RRSIG 。然而, 支持 DNSSEC 的解析器仍将执行所有密码检查,若探测到恶意 DNS 答复,它仍会将 SERVFAIL 错误返回给应用程序。 DNSSEC 会保护 DNS 服务器(权威服务器和递归服务器)数据的完整性,但却不为应用程序和解析器提供的安全保护。因此,予以一个从应用程序到其解析器的安全传输方式十分重要。实现这一目的最容易的方法就是运行 localhost (本地主机)上支持 DNSSEC 的解析器,使用 /etc/resolv.conf下的 127.0.0.1 。或者可以使用虚拟专用网络( VPN ,Virtual Private Network)连接到远程 DNS 服务器。

了解热点问题

使用无线网络热点( Wi-Fi Hotspot ,Wireless Fidelity Hotspot)或 VPN 时,就会依赖 DNS 欺骗 (DNS lies)。所获取的端口往往会发生 DNS 劫持,以便重定向用户跳转到需要身份验证(或支付)的 Wi-Fi 服务网页。连接 VPN 的用户常常需使用 内部专用 DNS 服务器,以便定位那些在公司网络外不存在的资源。这需要软件进行额外处理。例如, dnssec-trigger 可用于探测一个无线热点( Hotspot )是否劫持 DNS 查询,或 unbound 是否充当代理域名服务器处理 DNSSEC 查询。

选择支持 DNSSEC 的递归解析器

要部署支持 DNSSEC 的递归解析器,则可使用 BINDunbound 。这两者在默认情况下都使用 DNSSEC ,并用 DNSSEC root 密钥进行配置。在服务器上使用 DNSSEC ,两者都可正常工作。然而, unbound 更常用于移动设备,如笔记本电脑。因为它允许本机用户对 DNSSEC 覆写动态重配置,无论是使用 dnssec-trigger 时无线热点所需求的, 亦或是使用 Libreswan 时 VPNs 所需求的。 unbound 守护进程进一步支持对列入 etc/unbound/*.d/目录的 DNSSEC 异常状况进行部署,这对服务器和移动设备都有用。

4.6.3. 了解 Dnssec-trigger

一旦 unbound 完成安装,并在 /etc/resolv.conf下进行配置,则所有来自应用程序的 DNS 查询都会通过 unbound进行处理。dnssec-trigger 只有在被触发时,才会对 unbound 解析器进行重配置。这大多数运用于漫游的客户机,如笔记本电脑,这种可连接到不同 Wi-Fi 网络的机器。其过程如下:
  • 通过 动态主机配置协议(DHCP,Dynamic host configuration protocol) 获取新的 DNS 服务器时,则 NetworkManager 会触发 dnssec-trigger
  • 随后,Dnssec-trigger 会对服务器执行一系列测试,判断其是否完全支持 DNSSEC 。
  • 如果支持,那么 dnssec-trigger 会重配置 unbound ,以用于作为所有查询转发程序的 DNS 服务器。
  • 如果测试失败,则dnssec-trigger 将忽略新的 DNS 服务器,并尝试一些可行的退却方法。
  • 如果它判定一个不受限制的 53 端口(用户数据报协议(UDP,User Datagram Protocol) 以及 传输控制协议(TCP,Transmission Control Protocol))可以使用,则它将告知 unbound 可成为全递归 DNS 服务器,无需使用任何转发程序。
  • 如果无法完成操作,如因 53 端口被防火墙阻拦,此防火墙会阻挡除连接网络的 DNS 服务器之外的所有程序,则它将会尝试通过使用 DNS 到 80 端口,亦或通过使用 DNS 封装的 安全传输层协议(TLS,Transport Layer Protocol) 到 443 端口。在 80 端口和 443 端口运行 DNS 的服务器可在 /etc/dnssec-trigger/dnssec-trigger.conf下进行配置。注释的范例可在默认配置文件中找到。
  • 如果这些退却方法也失败了,则 dnssec-trigger 将提供一种不安全的操作,这将完全忽略 DNSSEC ;亦或它将在 缓存专用 (cache only)模式下运行,此模式下它将不会尝试新的 DNS 查询,但将会应答所有已在缓存器中的数据。
无线热点更是常常在授予访问网络权限之前,重定向用户到登录页面。在探测上述编列期间,如果探测到重定向命令,则会提示用户,以询问是否通过要求登录来获取网络访问权限。dnssec-trigger 守护进程将继续对 DNSSEC 解析器每十秒进行探测。关于使用 dnssec-trigger 图形化工具的更多信息,请参阅 第 4.6.8 节 “使用 Dnssec-trigger”

4.6.4. 提供域和域名服务器的 VPN

VPN 一些连接类型可传输域和一系列域名服务器, 可用于作为 VPN 隧道安装部分的域。在 红帽企业版 Linux 中,这是由 NetworkManager 所支持的。这就是说, unbounddnssec-triggerNetworkManager 的结合产物能够完全支持 VPN 软件所提供的域和域名服务器。一旦 VPN 隧道完成,就可以清除关于所有接收域名的登录在本机的 unbound 缓存,从而通过 VPN 获取的内部域名服务器中提取最新对域名名称的查询。终止 VPN 隧道时,则会再次清除 unbound 缓存,以确保任何对域的查询会返回给公用 IP 地址,而不会返回到原先获取的 IP 地址。请参阅〈 第 4.6.11 节 “对连接所提供的域进行 DNSSEC 验证配置” 〉。

4.6.6. 了解信任锚(Trust Anchor)

信任锚由 DNS 域名以及此域名相关的公用密钥(或公用密钥的散列值)组成。其表述为一个基本的 64 比特加密密钥。其类似于一种信息交换方式的证书,含有公用密钥,可用于对 DNS 记录进行核实和身份验证。关于信任锚更加完整的定义,请参阅〈 RFC 4033 〉。

4.6.7. 安装 DNSSEC

4.6.7.1. 安装 unbound

要通过在本机上使用 DNSSEC 对 DNS 进行验证,则必须安装 DNS 解析器 unbound (或 bind )。移动设备上只需安装 dnssec-trigger 。对于服务器而言,安装unbound 就应当足够了,尽管根据服务器所在地(局域网(LAN,local area network) 或 Internet),可能会要求对本地域进行转发配置。 dnssec-trigger 当下只在全球公共 DNS 区域提供帮助。NetworkManagerdhclient, 以及 VPN 应用程序通常可以自动收集域列表(和域名服务器列表),但 dnssec-triggerunbound 却不行。
要安装 unbound ,则须作为 root 用户允许以下命令:
~]# yum install unbound

4.6.7.2. 检查 unbound 是否在运行

要判定 unbound 守护进程是否在运行,则须输入以下命令:
~]$ systemctl status unbound
 unbound.service - Unbound recursive Domain Name Server
	  Loaded: loaded (/usr/lib/systemd/system/unbound.service; disabled)
	  Active: active (running) since Wed 2013-03-13 01:19:30 CET; 6h ago
systemctl status 命令将会报告 unbound Active: inactive (dead) ,若 unbound 服务未在运行。

4.6.7.3. 启动 unbound

要启动 unbound 守护进程用于当前会话,则须作为 root 用户运行以下命令:
~]# systemctl start unbound
运行 systemctl enable 命令,以确保每次启动系统时, unbound 开始运行:
~]# systemctl enable unbound
unbound 守护进程允许使用以下目录对本地数据或覆写进行配置:
  • /etc/unbound/conf.d 用于为特定的域名添加配置。这用于重定向域名查询到特定的 DNS 服务器。这通常用于只存在于企业广域网(WAN,wide area network)的子域。
  • /etc/unbound/keys.d 目录用于为特定的域名添加信任锚。这在 DNSSEC 对内部专用域名进行签名时才需要,但并没有公用现有的 DS 记录来建立信任途径。另一种使用情况是,当对内部域进行签名时,使用不同的 DNSKEY ,而不是使用企业广域网之外可行的公用域名。
  • /etc/unbound/local.d 目录用于添加特定的 DNS 数据作为本地覆写。者可用于建立黑名单,或创建手动覆写。这个日期将会通过 unbound 返回给客户端,但是不会被标记为有 DNSSEC 签名。
NetworkManager 和一些 VPN 软件可改变动态配置。这些配置目录含有注释范例。更多信息请参阅 unbound.conf(5) 手册页。

4.6.7.4. 安装 Dnssec-trigger

dnssec-trigger 应用程序作为 dnssec-triggerd守护进程来运行。要安装 dnssec-trigger ,则须作为 root 用户运行以下命令:
~]# yum install dnssec-trigger

4.6.7.5. 检查 Dnssec-trigger 守护进程是否在运行

要判定 dnssec-triggerd 是否在运行,则须输入以下命令:
~]$ systemctl status dnssec-triggerd
systemctl status dnssec-triggerd.service
dnssec-triggerd.service - Reconfigure local DNS(SEC) resolver on network change
	  Loaded: loaded (/usr/lib/systemd/system/dnssec-triggerd.service; enabled)
	  Active: active (running) since Wed 2013-03-13 06:10:44 CET; 1h 41min ago
systemctl status 命令将会报告 dnssec-triggerd Active: inactive (dead) ,若 dnssec-triggerd 守护进程未在运行。要在当前会话中启用,则须作为 root 用户运行以下命令:
~]# systemctl start dnssec-triggerd
运行 systemctl enable 命令,以确保每次启动系统时, unbound 开始运行:
~]# systemctl enable dnssec-triggerd

4.6.8. 使用 Dnssec-trigger

dnssec-trigger 应用程序有GNOME panel 的功能,用于显示 DNSSEC 探测结果,以及用于执行 DNSSEC 探测命令请求。要启用此功能,则须按 Super 键进入应用程序概览视图( Activities Overview),输入 DNSSEC ,然后再按 Enter 。一个形似船锚的图标将会添加到屏幕底部的消息托盘。可通过按屏幕底部右侧的蓝色圆形通知图标来显示。右击锚状图标,则会出现弹出式菜单。
正常操作下, unbound 在本机可用作域名服务器, resolv.conf 会指向 127.0.0.1。当您在 无线热点登录(Hotspot Sign-On) 界面点击 OK 时,这就会改变。 DNS 服务器受到 NetworkManager 的查询,并被放入 resolv.conf。然后您就可以在无线热点登录页面进行身份验证。锚状图标会显示巨大的红色感叹号以作警示,提醒您 DNS 查询的执行并不安全。身份验证后, dnssec-trigger 可自动检测,并转换到安全模式。尽管在某些情况下,它无法自动检测,则用户必须手工操作,选择 重新检测(Reprobe)
正常情况下,Dnssec-trigger 不需要用户进行交互操作。一旦 启用,它会在后台工作。如果出现问题,它会弹出消息框来通知用户。它也会将 resolv.conf 文件的变更通知 unbound

4.6.9. 对 DNSSEC 使用 dig 命令

要查看 DNSSEC 是否在工作,则可用不同的命令行工具。最好的使用工具就是 bind-utils 工具包中的 dig 命令。其他可用的工具分别是, ldns 工具包中的 drillunbound 工具包中的 unbound-host 。旧版的 DNS 实用程序 nslookuphost 都已过时,不应再使用。
要使用 dig 发送 DNSSEC 数据查询请求,则须添加 +dnssec 选项到命令中,例如:
~]$ dig +dnssec whitehouse.gov
; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-4.P2.el7 <<>> +dnssec whitehouse.gov
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21388
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;whitehouse.gov.			IN	A

;; ANSWER SECTION:
whitehouse.gov.		20	IN	A	72.246.36.110
whitehouse.gov.		20	IN	RRSIG	A 7 2 20 20130825124016 20130822114016 8399 whitehouse.gov. BB8VHWEkIaKpaLprt3hq1GkjDROvkmjYTBxiGhuki/BJn3PoIGyrftxR HH0377I0Lsybj/uZv5hL4UwWd/lw6Gn8GPikqhztAkgMxddMQ2IARP6p wbMOKbSUuV6NGUT1WWwpbi+LelFMqQcAq3Se66iyH0Jem7HtgPEUE1Zc 3oI=

;; Query time: 227 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 22:01:52 EDT 2013
;; MSG SIZE  rcvd: 233
除 A 记录之外,所返回的 RRSIG 记录含有 DNSSEC 签名以及签名的初始时间和截止时间。据 unbound 服务器显示,通过返回的顶端 flags: 区段下 ad 比特可知数据已经过 DNSSEC 身份验证。
如果 DNSSEC 验证失败,则 dig 命令将会返回 SERVFAIL 错误:
~]$ dig badsign-a.test.dnssec-tools.org
; <<>> DiG 9.9.3-rl.156.01-P1-RedHat-9.9.3-3.P1.el7 <<>> badsign-a.test.dnssec-tools.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1010
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;badsign-a.test.dnssec-tools.org. IN	A

;; Query time: 1284 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 22:04:52 EDT 2013
;; MSG SIZE  rcvd: 60]
要请求查看关于失败的更多信息,则须指定 +cd 选项加入到 dig 命令中,以禁止 DNSSEC 检查:
~]$ dig +cd +dnssec badsign-a.test.dnssec-tools.org
; <<>> DiG 9.9.3-rl.156.01-P1-RedHat-9.9.3-3.P1.el7 <<>> +cd +dnssec badsign-a.test.dnssec-tools.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26065
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;badsign-a.test.dnssec-tools.org. IN	A

;; ANSWER SECTION:
badsign-a.test.dnssec-tools.org. 49 IN	A	75.119.216.33
badsign-a.test.dnssec-tools.org. 49 IN	RRSIG	A 5 4 86400 20130919183720 20130820173720 19442 test.dnssec-tools.org. E572dLKMvYB4cgTRyAHIKKEvdOP7tockQb7hXFNZKVbfXbZJOIDREJrr zCgAfJ2hykfY0yJHAlnuQvM0s6xOnNBSvc2xLIybJdfTaN6kSR0YFdYZ n2NpPctn2kUBn5UR1BJRin3Gqy20LZlZx2KD7cZBtieMsU/IunyhCSc0 kYw=

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 22:06:31 EDT 2013
;; MSG SIZE  rcvd: 257
通常, DNSSEC 错误会自己显示错误的初始时间或截止时间。尽管在本例中, www.dnssec-tools.org 的访问者蓄意损坏 RRSIG 签名,这是我们无法通过手动查看此输出来进行探测。错误将会显示在 systemctl status unbound 的输出中,且 unbound 守护进程会将这些错误记录到 syslog ,如下所示:
Aug 22 22:04:52 laptop unbound: [3065:0] info: validation failure badsign-a.test.dnssec-tools.org. A IN
使用 unbound-host的示例:
~]$ unbound-host -C /etc/unbound/unbound.conf -v whitehouse.gov
whitehouse.gov has address 184.25.196.110 (secure)
whitehouse.gov has IPv6 address 2600:1417:11:2:8800::fc4 (secure)
whitehouse.gov has IPv6 address 2600:1417:11:2:8000::fc4 (secure)
whitehouse.gov mail is handled by 105 mail1.eop.gov. (secure)
whitehouse.gov mail is handled by 110 mail5.eop.gov. (secure)
whitehouse.gov mail is handled by 105 mail4.eop.gov. (secure)
whitehouse.gov mail is handled by 110 mail6.eop.gov. (secure)
whitehouse.gov mail is handled by 105 mail2.eop.gov. (secure)
whitehouse.gov mail is handled by 105 mail3.eop.gov. (secure)

4.6.10. 装配 Dnssec-trigger 无线热点探测设备

连接网络时, dnssec-trigger 会尝试探测无线热点。无线热点通常是一种会在可使用网络之前迫使用户进行网页交互的设备。通过尝试下载一已知内容的指定网页,来完成探测。如果存在无线热点,则不会有如预期所料的接收内容。
要设置一已知的固定网页,使其可通过 dnssec-trigger 用于探测无线热点,则须如下执行:
  1. 对某些在互联网上可公开访问的机器,设置其网页服务器。关于网页服务器的更多信息,请参阅《Red Hat Enterprise Linux 7 系统管理员指南 》。
  2. 一旦您让服务器开始运行,则会将已知内容的静态页面发布到服务器上。此页面无需一定是有效的 HTML 页面。例如,您可使用一个名为 hotspot.txt只含有 OK 字符串的纯文本文件。假设您的服务器位于 example.com ,您可将 hotspot.txt 文件发布到网页服务器的 document_root/static/ 子目录,那么您静态网页服务器的地址将是 example.com/static/hotspot.txt 。请参阅《 Red Hat Enterprise Linux 7 系统管理员指南 》下的 DocumentRoot 指令。
  3. 将以下命令行添加到 /etc/dnssec-trigger/dnssec-trigger.conf 文件:
    url: "http://example.com/static/hotspot.txt OK"
    此命令添加了一个可通过 HTTP (80端口)探测到的 URL 。第一部分就是可解析的 URL 以及可下载的页面。命令的第二部分是所下载的网页预期含有的文本字符串。
关于配置选取的更多信息,请参阅手册页的 dnssec-trigger.conf(8)

4.6.11. 对连接所提供的域进行 DNSSEC 验证配置

在默认情况下,转发区及其固有的域名服务器会通过 dnssec-trigger 自动添加到 unbound ,以用于任何通过 NetworkManager 的连接所提供的域,除了 Wi-Fi 连接之外。默认情况下,所有添加到 unbound 的转发区都已进行 DNSSEC 验证。
用于验证转发区的默认行为可被更改,从而所有的转发区在默认情况下将 会进行 DNSSEC 验证。要做到这一点,则须更改 dnssec-trigger 配置文件 /etc/dnssec.conf 下的 validate_connection_provided_zones 变量。作为 root 用户,打开并编辑以下命令行:
validate_connection_provided_zones=no
无法更改任何现有的转发区,只能更改未来的转发区。因此,如果您想禁止 DNSSEC 用于当前所提供的域,那么您需要重新连接。

4.6.11.1. 对 Wi-Fi 所提供的域进行 DNSSEC 验证配置

为 Wi-Fi 所提供的区域添加转发区即可启用。要实现此功能,则须更改 dnssec-trigger 配置文件 /etc/dnssec.confadd_wifi_provided_zones 变量。作为 root 用户,打开并编辑以下命令行:
add_wifi_provided_zones=yes
对任何已存在的转发区无法进行更改,只能对将要执行的转发区进行更改。因此,如果您要禁止 DNSSEC 用于当前 Wi-Fi 所提供的域,那么您需要重新连接(重新开启) Wi-Fi 。

警告

要“ 打开 ”添加到 unbound 作为转发区的 Wi-Fi 所提供的域,则可能会出现安全隐患,例如:
  1. 一个 Wi-Fi 接入点可能有意通过 DHCP( Dynamic host configuration protocol,动态主机配置协议) 给您提供一个域,而它并无 DHCP 的权限,也无法将您所有的 DNS 查询发送到其 DNS 服务器。
  2. 如果您对“ 关闭 ”的转发区进行 DNSSEC 验证,那么 Wi-Fi 所提供的 DNS 服务器可从所提供的域中,伪造用于域名的 IP 地址,而您并不知情。

4.6.12. 附加资源

以下这些资源将对 DNSSEC 进行更多的 解释。

4.6.12.1. 已安装的文档

  • dnssec-trigger(8) 手册页 —— 描述用于 dnssec-triggerd, dnssec-trigger-control 以及 dnssec-trigger-panel 的命令选项。
  • dnssec-trigger.conf(8) 手册页 —— 描述用于 dnssec-triggerd 的配置选项。
  • unbound(8) 手册页 —— 描述用于 unbound 以及 DNS 验证解析器的命令选项。
  • unbound.conf(5) 手册页 —— 含有配置 unbound 的信息。
  • resolv.conf(5) 手册页 —— 含有解析器例程所读取的信息。

4.6.12.2. 在线文档

http://tools.ietf.org/html/rfc4033
RFC 4033 DNS 安全介绍及其要求( DNS Security Introduction and Requirements)。
http://www.dnssec.net/
有链接到许多 DNSSEC 资源的网站。
http://www.dnssec-deployment.org/
DNSSEC 部署计划( DNSSEC Deployment Initiative)由国土安全部赞助( Department for Homeland Security),含有大量 DNSSEC 信息,并通过 邮件列表来讨论 DNSSEC 部署事项。
http://www.internetsociety.org/deploy360/dnssec/community/
国际互联网大会(Internet Society)的 Deploy 360 计划是为了促进并协调 DNSSEC 部署,这是在全球范围内发现团体和 DNSSEC 活动的良好资源。
http://www.unbound.net/
此文档含有关于 unbound DNS 服务的基本信息。
http://www.nlnetlabs.nl/projects/dnssec-trigger/
此文档含有关于 dnssec-trigger 的基本信息。