我有兴趣为我的域名getvalid.com获得NSEC3支持，以便防止名称遍历。
DYN 似乎不支持NSEC3 ，显然BIND和DNS服务器需要支持NSEC3的能力…但我不确定底层注册商是否对NSEC3支持有任何影响。
我需要为NSEC3的注册商做些什么吗？
在DNSSEC中，根和中间名称服务器的作用是提供一个信任链，直到到达您的区域的权威名称服务器。 除了托pipe与签名区域相关的公钥DS密钥之外，它们在NSEC3validation中没有任何作用。
要使NSEC3正常工作，您需要使用强制支持该function的algorithm对您的区域进行签名。 较早的algorithm通过包含-NSEC3-标识符的变体来支持。 除非以这种方式公布支持，否则parsing器不会尝试使用更新的function。 如果区域已经正确签名，您所需要做的就是按照通常的步骤将DS密钥摘要发布到名称服务器上，紧接在您的授权链之前。
从RFC5155 ：
为了有助于部署，本规范使用信令技术来防止NSEC3未知的parsing器尝试validationNSEC3签名区域的响应。
这个规范为此分配了两个新的DNSKEYalgorithm标识符。 algorithm6，DSA-NSEC3-SHA1是algorithm3，DSA的别名。 algorithm7，RSASHA1-NSEC3-SHA1是algorithm5的别名RSASHA1。 这些不是新algorithm，它们是现有algorithm的附加标识符。
根据这个规范签名的区域必须只使用这些algorithm标识符作为它们的DNSKEY RRs。 由于这些新的标识符对于现有的NSEC3未知的parsing器是未知的algorithm，那么这些parsing器将把来自NSEC3签名区域的响应视为不安全的，详见[RFC4035]的第5.2节。
只要注册服务商允许您将任何有效的DSlogging添加到您所在区域的授权中，注册服务商就不会成为一个因素。
有些事情，注册商可以这样做会导致一个问题是：
如果他们不允许你添加DSlogging，那么根本就不能有一个签名的代表团（ DLV作为一个潜在的解决方法），而不是NSEC3的问题，但对于DNSSEC
如果它们对DSlogging（特别是algorithm域）的值施加限制，可能会迫使你使用一个在NSEC3之前的algorithm。
algorithm的局限性并不是我所遇到的，但至less在理论上可能有人可能已经过时了validation代码或类似的东西。