差别

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

--- notes:d:dnssec-authorative [2015/05/05 07:51] – delphij
+++ notes:d:dnssec-authorative [2020/02/14 06:44] (当前版本) – [DANE] delphij
@@ 行 35: / 行 35: @@
 ===== 生成相关密钥 =====
-假定在我们希望的配置中，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 域名 =====
@@ 行 124: / 行 135: @@
 <code bash>
-dnssec-keygen -K keys -a RSASHA256 -3 -b 1024 -P 20150725 -A 20150731 -I 20151101 -D 20151107 域名
+dnssec-keygen -K keys -a ECDSAP384SHA384 -3 -P 20150725 -A 20150731 -I 20151101 -D 20151107 域名
 </code>
-KSK 的轮转与此类似。需要注意的是，KSK 的发布是需要在注册商那里进行的。
+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比较不容易出问题。
 ==== 修改域名中的记录 ====
@@ 行 138: / 行 157: @@
 ==== 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]]