差别

这里会显示出您选择的修订版和当前版本之间的差别。

--- notes:d:dnssec-authorative [2015/05/05 06:48] – [配置 hidden master 服务器全局配置] delphij
+++ notes:d:dnssec-authorative [2020/02/14 06:44] (当前版本) – [DANE] delphij
@@ 行 18: / 行 18: @@
 用作从域名服务器的 DNS 服务器并不需要相关密钥。一般来说，为了分散风险，DNSsec 的配置应以 "hidden master" （隐藏主DNS：主DNS并不对公众直接提供服务）。
+===== 推荐的部署步骤 =====
+以下是个人推荐的部署步骤。
+  - 收集必要的相关信息，如 zone 文件等等。设计部署方案。
+  - 配置全部的从 DNS 服务器（启用其上的 DNSsec 配置）确认服务正常。
+  - 如果目前使用的不是 hidden master，将 DNS 集群改为 hidden master 方式。（非常简单，本文暂略）
+  - 生成相关密钥。
+  - 将 hidden master 配置为使用 DNSsec 签名，测试 （dig +dnssec soa 域名 @服务器）。
+  - 如果无问题，在域名注册商处发布 DS 记录。
+  - 进一步生产环境测试。
+DNSsec需要持续维护。持续维护阶段，需要每隔一段时间生成并轮换密钥，在轮换 KSK 时需要在注册商那里发布。
 ===== 生成相关密钥 =====
-假定在我们希望的配置中，KSK使用2048-bit RSA/SHA256，ZSK使用1024-bit RSA/SHA256并每季度轮转一次，且今天是2015年5月1日，那么：
+假定在我们希望的配置中，KSK和KSK均使用P-384的椭圆曲线DSA和 SHA384，并每季度轮转一次，且今天是2015年5月1日，那么：
 <code bash>
-dnssec-keygen -K keys -a RSASHA256 -3 -b 2048 -f KSK -I 20160501 -D 20160507 域名
+dnssec-keygen -K keys -a ECDSAP384SHA384 -3 -f KSK -I 20160501 -D 20160507 域名
-dnssec-keygen -K keys -a RSASHA256 -3 -b 1024 -I 20150801 -D 20150807 域名
+dnssec-keygen -K keys -a ECDSAP384SHA384 -3 -I 20151201 -D 20151207 域名
 </code>
-以上，第一个命令生成2048-bit的KSK，并将过期时间设置为2016年5月1日（这之后新的记录将不再使用这个key签名），并约定2016年5月7日从域中剔除（这之后查询该key将不再返回结果）。 XXX 此处重叠时间应继续查看文档了解。
+以上，第一个命令生成KSK，并将过期时间设置为2016年5月1日（这之后新的记录将不再使用这个key签名），并约定2016年5月7日从域中剔除（这之后查询该key将不再返回结果）。 XXX 此处重叠时间应继续查看文档了解。
 注意，运行 BIND 的用户必须能够访问这些 key 文件（chown bind:bind keys/*）。
+在生成了密钥之后，还必须生成与之对应的 DS 记录。假定我们的 KSK 的id是52874，那么对应的密钥文件就是 K域名.+014+52874.key 和 K域名.+014+52874.private（其中，014的意思是ECDSA P384 SHA384），那么具体的命令是：
+<code bash>
+dnssec-dsfromkey K域名.+014+52874.key
+dnssec-dsfromkey -a SHA-384 K域名.+014+52874.key
+</code>
+第一个命令会生成SHA1和SHA2的DS记录，第三个会生成SHA384的DS记录。实际操作中，我认为如果支持 ECDSA P384 SHA384 的解析器一定已经支持了 SHA384 的hash，因此只要有最后一个记录即可。
+如果使用旧式的 RSA 2048/1024 配合 SHA1/SHA256 算法，则应使用与之对应的 SHA1 或 SHA256 的 DS 记录。本着不升级的人死了活该的精神，我认为完全不应该考虑这些用户的感受，使用 ECDSA 签名既节省流量，又更加安全。
 ===== 配置 DNSsec 域名 =====
@@ 行 77: / 行 102: @@
 启动 BIND 后，BIND 会自动对原有的 example.com 根据需要进行签名，并通知我们指定的辅 DNS 服务器，后者会到 hidden master 来拉，具体可以看 DNS 服务器的日志。
-未完待续。
+==== NSEC3 ====
+DNSsec 是对域名地址记录进行签名，那么如何知道一个域名不存在呢？假如每一次请求都需要 DNS 服务器签署一个类似（张三不存在）这样的消息的话，无疑会成为 DNSsec 服务器的一处软肋。
+假定一个域名中有 alice, bob 和 carol 三个名字，那么，在签署 alice, bob, carol 对应的地址记录时，我们可以同时签署这样的消息：以字典序排列域名时， alice 和 bob 之间没有其他名字。这种方法称作 NSEC。
+NSEC 有一项明显的缺点：我们可以向 DNSsec 故意询问不存在的名字，这时可以知道两个存在的端点；持续这一过程，就可以遍历整个 DNSsec 域了。这未必是一个安全问题（攻击者能够攻击，意味着这些机器在公网上），但是许多系统管理员会因此感到不安，因为域名往往会提供一些其他信息，例如某个特定的机器叫 db，那么这台机器很可能是运行数据库的比较关键的服务器，等等。
+为了解决这个问题， [[https://tools.ietf.org/html/rfc5155]] 定义了 NSEC3。简而言之，NSEC3 并不告诉查询者 “alice和bob之间没有人”而是告诉查询者“hash ALICE和hash BOB之间没有人”。由于采用的hash函数是不可逆的，并且通常是进行多轮加salt，因此NSEC3避免了NSEC的域名遍历问题。
+BIND中启用NSEC3需要设置一个NSEC3参数，方法是：
+<code bash>
+rndc signing -nsec3param 1 0 10 `dd if=/dev/random bs=4 count=1 | od -An -vtx` 域名
+</code>
+启用 NSEC3 之后，zone 将不再是正常人类所能理解的形式。使用下面的命令可以将其转换为人类可以勉强阅读的格式：
+<code bash>
+named-compilezone -D -f raw -o - example.net example.net.signed
+</code>
+（以上将 example.net.signed 转换为裸奔格式）。
+===== 维护 DNSsec 域名 =====
+==== ZSK和PSK的轮换 ====
+前面我们已经用 inline signing 解决了 ZSK 签名的轮转问题（代价是隐蔽的主 DNS 服务器必须能够访问 ZSK 和 KSK），但 DNSsec 域名仍然需要经常轮转 ZSK 和定期轮转 KSK。
+BIND 可以自动完成轮转所需的大部分工作，但用户仍然需要生成相关的 key。前面我们的例子中，ZSK 将在 20150801 过期，一般来说我们希望有至少1周时间来发布一个新的key（这样有7天重叠），并从7月31日开始以新的key来签署域名。 XXX 确认这是否最佳实践
+<code bash>
+dnssec-keygen -K keys -a ECDSAP384SHA384 -3 -P 20150725 -A 20150731 -I 20151101 -D 20151107 域名
+</code>
+KSK 的轮转与此类似。需要注意的是，KSK 的发布是需要在注册商那里进行的。轮转 KSK 的方法略微复杂一些，因此这里展开说一下。
+  * 首先，要把新的 key 添加到域里。简而言之，按照前面 生成相关密钥 的部分做就行了，注意激活时间最好比当前时间稍微提前一点，这样下次 BIND 扫描时便会注意到这些 key。注意一定要把权限配对。
+  * 假设有足够的耐心，可以等 BIND pickup 相关的变化。然而很多人并没有足够的耐心，可以用 rndc reload 来踹它一脚，确认所有的 slave 都获得了同步的数据。
+  * 检查 DNSsec 中的签署情况。此时，你应该看到两个 KSK 互相签署，而且签署了所有的 ZSK。
+  * 如果没有问题，可以进一步去注册商那里，先添加新的 KSK 的 DS 记录，确认无误后，再删除旧 KSK 的 DS 记录。
+  * 最后，使用 dnssec-settime 修正旧 KSK 的 inactive 和 delete 时间，最终它们会从域中剔除掉。
+以上过程的考虑是：根域名的同步是需要时间的，在过渡期内，应该同时用两个key签署ZSK。此外，先添加新的DS再删去旧的DS比较不容易出问题。
+==== 修改域名中的记录 ====
+===== 其他话题 =====
+==== SSHFP ====
+==== DANE ====
+DANE记录可以从证书中提取公钥来生成。DANE记录有4个字段：
+  * 用途 Usage 字段，允许的数值有：
+    * 0 - PKIX-TA: Certificate Authority Constraint 指定一个CA，服务器必须使用该CA签发的证书，并且受用户信任。
+    * 1 - PKIX-EE: Service Certificate Constraint 指定服务器证书，服务器必须使用这个证书，并且该证书必须通过PKIX的验证。
+    * 2 - DANE-TA: Trust Anchor Assertion 指定一个CA，服务器必须使用该CA签发的证书，但该证书不必为用户信任。
+    * 3 - DANE-EE: Domain Issued Certificate 指定服务器证书，服务器必须使用这个证书，但证书不必通过PKIX验证。
+  * 选择器 Selector 字段，允许的数值有：
+    * 0 - Cert: Use full certificate 使用完整的证书。
+    * 1 - SPKI: Use subject public key 只使用证书的公钥部分。
+  * 匹配类型 Matching Type 字段，允许的数值有：
+    * 0 - Full: No Hash 不进行hash。（并无必要，通常应选择以下两种之一）
+    * 1 - SHA-256: SHA-256 hash。（回应尺寸小，但计算较慢）
+    * 2 - SHA-512: SHA-512 hash。（回应尺寸大，但计算较快）
+  * TLSA 数据（参见下面的生成命令）
+举个例子：3 1 2 表示我们的 TLSA 记录将指明服务器所用的证书的公钥的 SHA-512 hash。用途字段（目前是3）选1时，客户端需要进行更严格一些的验证（例如确认域名匹配等）。
+TLSA 数据是根据上述选择器指定的内容产生的，通常来说我们匹配公钥的SHA-512 hash就可以了，下面的命令可以生成需要的数据。
+<code bash>
+openssl x509 -noout -pubkey -in domainname.cer | \
+  openssl rsa -pubin -outform DER | sha512 | \
+  tr "a-f" "A-F"
+</code>
+最后将数据写到DNS TLSA记录里。BIND的写法类似下面这样：
+<code>
+_443._tcp.www.example.org TLSA (3 1 2 <上面命令生成的结果>)
+</code>
 ===== 参考文献 =====
   * NIST Publication SP-800-81 [[http://csrc.nist.gov/publications/PubsSPs.html|NIST SP]]
+  * [[https://deepthought.isc.org/article/AA-00711/0/In-line-Signing-With-NSEC3-in-BIND-9.9-A-Walk-through.html|ISC KB AA-00711 In-line Signing With NSEC3 in BIND 9.9+ -- A Walk-through]]