差别
这里会显示出您选择的修订版和当前版本之间的差别。
两侧同时换到之前的修订记录前一修订版后一修订版 | 前一修订版 | ||
notes:d:dnssec-authorative [2015/05/05 07:48] – 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> | <code bash> | ||
- | dnssec-keygen -K keys -a RSASHA256 | + | dnssec-keygen -K keys -a ECDSAP384SHA384 |
- | dnssec-keygen -K keys -a RSASHA256 | + | dnssec-keygen -K keys -a ECDSAP384SHA384 |
</ | </ | ||
- | 以上,第一个命令生成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/ | 注意,运行 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 | ||
+ | </ | ||
+ | |||
+ | 第一个命令会生成SHA1和SHA2的DS记录,第三个会生成SHA384的DS记录。实际操作中,我认为如果支持 ECDSA P384 SHA384 的解析器一定已经支持了 SHA384 的hash,因此只要有最后一个记录即可。 | ||
+ | |||
+ | 如果使用旧式的 RSA 2048/1024 配合 SHA1/SHA256 算法,则应使用与之对应的 SHA1 或 SHA256 的 DS 记录。本着不升级的人死了活该的精神,我认为完全不应该考虑这些用户的感受,使用 ECDSA 签名既节省流量,又更加安全。 | ||
===== 配置 DNSsec 域名 ===== | ===== 配置 DNSsec 域名 ===== | ||
行 124: | 行 135: | ||
<code bash> | <code bash> | ||
- | dnssec-keygen -K keys -a RSASHA256 | + | dnssec-keygen -K keys -a ECDSAP384SHA384 |
</ | </ | ||
- | 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比较不容易出问题。 | ||
==== 修改域名中的记录 ==== | ==== 修改域名中的记录 ==== | ||
- | 未完待续。 | + | ===== 其他话题 ===== |
+ | ==== 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 " | ||
+ | </ | ||
+ | |||
+ | 最后将数据写到DNS TLSA记录里。BIND的写法类似下面这样: | ||
+ | |||
+ | < | ||
+ | _443._tcp.www.example.org TLSA (3 1 2 < | ||
+ | </ | ||
===== 参考文献 ===== | ===== 参考文献 ===== | ||
* NIST Publication SP-800-81 [[http:// | * NIST Publication SP-800-81 [[http:// | ||
+ | * [[https:// |