≪ View Page

差别

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

到此差别页面的链接

两侧同时换到之前的修订记录前一修订版
后一修订版		前一修订版
notes:d:dnssec-authorative [2015/06/26 07:07] – delphijnotes:d:dnssec-authorative [2020/02/14 06:44] (当前版本) – [DANE] delphij
行 39: 行 39:
 <code bash> <code bash>
 dnssec-keygen -K keys -a ECDSAP384SHA384 -3 -f KSK -I 20160501 -D 20160507 域名 dnssec-keygen -K keys -a ECDSAP384SHA384 -3 -f KSK -I 20160501 -D 20160507 域名
-dnssec-keygen -K keys -a ECDSAP384SHA384 -3 -I 20150801 -D 20150807 域名+dnssec-keygen -K keys -a ECDSAP384SHA384 -3 -I 20151201 -D 20151207 域名
 </code> </code>
  
行 135: 行 135:
  
 <code bash> <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> </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比较不容易出问题。
  
 ==== 修改域名中的记录 ==== ==== 修改域名中的记录 ====
行 149: 行 157:
 ==== DANE ==== ==== 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]]   * 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]]   * [[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]]