DNSSEC的目的是防止像缓存中毒这样的攻击,这样客户端就可以确保从递归DNS服务器获得的答案是正确的( IP是正确的IP)。根DNS持有一个密钥对,该密钥对签署低于它的级别的键(例如,.com),等等(.com为example.com DNS服务器签名键)。
当客户端查询递归DNS ( DNS层次结构中的最后一个DNS )时,他将得到一个签名的答案。我的问题是:谁拥有客户接收的签名密钥?是域名所有者(example.com)吗?谁向域名所有者提供了这个密钥?它是由上面的DNS服务器(.com)签名的自生成密钥对吗?
请向我说明钥匙的所有权和谁产生的?
发布于 2018-05-17 03:51:58
在每个级别上,在每个区域中,记录由一个(或多个)键签名,即区域中的自身(公共部分)作为DNSKEY记录。
此外,在父区域中,DS记录(与该区域中的任何其他记录一样在区域中签名)“指向”下面的DNSKEY,因为它是DNSKEY和域名的散列。
这在每一级都有重复。因此,如果您从根开始使用一个完全受信任的密钥(一个锚,必须存在于每个递归名称服务器中),那么您将在.com区域中为某个键找到一个有符号的DS记录,在那里您可以找到它的DNSKEY记录和所有其他由该键签名的记录,包括用于example.com的键的DS记录,在该记录中,您将找到一个DNSKEY记录,该记录将对所有其他记录进行签名,从而生成RRSIG记录。
(当然,这是简化的,因为您通常有单独的区域签名密钥和密钥签名密钥,但这并不改变上面的一般想法)。
键通常是由名称服务器或某些外部工具以某种频率自动生成的(通常在几个月或几年内计算)。它们绝对不能由父区域处理/生成,每个区域负责它的键,它们有多少,更改它们的频率,它们存储在哪里(比如KSK离线的HSM上,或者仅仅是在文件系统上)。每个区域只向其父区域提供一个DS记录(每个键一条,特别是每KSK一条,包括那些与发布的DNSKEY记录不相对应的记录,作为备份),以便构建信任链。
因此,它可以是域的所有者,也可以是DNSSEC签名(因此也可以外包密钥生成服务):一些提供者将给您提供一个名称服务器,充当连接节点,它将通过自己的名称服务器服务一个无符号区域并管理密钥和签名本身,从您的内容中为一个签名区域提供服务。
example.com中的签名以某种方式(取决于您所拥有的是什么)由该区域上的权威名称服务器拥有。它们要么是预先计算的,要么是在请求到达时计算出来的(这两个模型都存在)。签名本身有开始日期和结束日期。
使用像https://dnsviz.net/这样的在线工具以图形方式显示任何域的信任链。通过你的鼠标在图片的各个部分,你有很多有用的信息覆盖。
您也可以在本地使用dig +trace +dnssec。或者更好的是现在的delv +vtrace或drill -S。
https://security.stackexchange.com/questions/185893
复制相似问题