域名dwc-amsterdam.com在支持DNSSEC的托pipe公司A（hostA）上获得。
然后被转移到不提供DNSSEC的托pipe公司B（hostB）。
在检测到域名的某些问题后，罪魁祸首似乎是仍然对该域名有效的DSlogging：
dwc-amsterdam.com. 86400 IN DS 17739 7 1 05D720F7D200908C61631CD257A60F16ACE9D13D HostB说，DSlogging从来没有进入他们的区域，所以不能帮助我，并指示我到HostA。
HostA表示，转移2周后，所有logging都被删除。 技术支持人员确认了这一点，并将其引导回当前主机HostB。
我怎样才能打破僵局？
是否可以直接检查DSlogging的来源？
DS （代表签名人）密钥通过您的注册商添加到父区 （在您的情况下为com. ） 。
这继续了.com > dwc-amsterdam.com之间的信任链。 .com （父母）处的DSlogging用于certificate您的名称服务器（子）返回的logging是他们声称的内容。 要清楚的是，HostB的名称服务器（子）不会托pipe这个logging，控制面板也不会添加它，除非它们也是注册服务商。
如果新托pipe公司HostB负责将注册服务商列出的域名服务器粘合剂更改为新的服务器，那么他们将负责清理注册服务商的旧logging。
要真正看到logging，我们首先从com.获得一个名称服务器列表com. ：
$ dig com. IN NS
…从列表中select一个名称服务器，然后查询您的DS：
$ dig dwc-amsterdam.com IN DS @d.gtld-servers.net
答复中要注意的一点是， aa标志被设置 – 这意味着它是一个权威答案; 简单地说，名称服务器响应“拥有”该logging。
但你有DSlogging，你刚刚在你的post中显示。 您只需要在新域名注册商控制面板中重新input该logging即可。
您可以在域设置中find您需要input的参数：
Key tag: 17739 Algorithm: 7 Digest Type: 1 Digest: 05D720F7D200908C61631CD257A60F16ACE9D13D
请注意，如果不起作用，您可能需要再次签署DSlogging以生成新的代表签名者。