我有机会配置IDN ccTLD。 我已经配置了DNS服务器并且它正常工作。 现在我面临着通过DNSSEC保护DNS服务的挑战。 我通过自签名配置了DNSSECC。 但现在我无法理解我应该在何处以及如何输入DS记录。
答案 0 :(得分：1)
Calle Dybedahl回答＆＃34;在哪里＆＃34;，我想提供一些关于＆＃34;＆＃34;＆＃34;您应该为您的ccTLD（IDN或其他）启用DNSSEC。
Viktor Dukhovni的"Common Mistakes"页面处理了许多特定于DANE的事情（使用DNSSEC作为证书的锚点，特别是用于SMTP），但是他的前两点（以及下一个点）最后一个）对任何实施DNSSEC的运营商都有效，尤其是任何种类的TLD 。
特别是，下面删节的第一点至关重要：
发布DNSSEC DS记录......作为时尚陈述
保持这些正确需要操作纪律。管理员 谁期望＆＃34;火灾和忘记＆＃34;不应该发布DNSSEC签名区域... 或者他们可以支付其他人来管理他们的区域...运营不佳 维护DNSSEC区域...不仅为域创建问题 有问题，但也适用于所有尝试与之沟通的域名 这样的域名。如果采用DNSSEC，每个人都会变得更好 严重。
有许多ccTLD在维持其DNSSEC签名区域正常运行方面的记录远非一流;有一个"hall of shame" - 只需查看在IANIX中断列表中出现多次的TLD。
由于您的IDN ccTLD是新TLD，因此DNSSEC是强制性的，因此即使您吞下IANIX为您提供的红色药丸并放弃DNSSEC，您仍然别无选择，只能实施它。您应尽一切努力将DNSSEC部署视为最重要的一项，因为作为顶级域名，它不仅直接影响您的域的操作和安全性，还会影响其注册的任何和所有域的操作和安全。
此外，与DNSSEC一样困难和有问题，它不太可能消失，clients that validate DNSSEC本身的数量（或仅依赖于Google Public DNS，{{3}等DNSSEC验证解决服务}}或Comcast ISP）很重要，Verisign Public DNS并且在许多可能成为国际化域名（IDN）国家和地区代码顶级域名（ccTLD）候选国家的国家/地区显着增加（请参阅前一链接的exceeding 15% of all clients worldwide和每个国家/地区的下钻）例如regional和Kenya where 40% of clients rely on DNSSEC validation）。
.KE TLD had a significant DNSSEC outage last month和ISOC有很好的资源可以帮助您管理DNSSEC，如果您想要自己做的话＃34;并滚动您自己的DNSSEC区域签名。但是很容易弄错，如果没有定期监控和随叫随到的响应，您的DNSSEC签名就会过期，并使整个域无法访问数百万。更糟糕的是，如果用于DNSSEC签名的私钥遭到破坏，任何依赖DNSSEC的域的安全性都可能处于危险之中。
您可能需要认真考虑，从长远来看，使用可提供托管DNSSEC的商业DNS提供商来托管您的IDN ccTLD区域是否可能更容易和更便宜（当您运营TLD的注册管理机构和使用DNS管理API从注册表实现更新区域。）
最后一条建议;除非您委托数百万个在您的ccTLD中没有DS记录且需要a best practices PDF的域名，或者您在欧洲运营，其中数据隐私法NSEC3 opt-out [1]可能要求您使用NSEC3，您现在应该使用旧式NSEC，因为它允许Google Public DNS（以及[2]的其他实现）吸收NXDOMAIN拒绝服务攻击和垃圾查询，而无需将其转发到您的权威服务器。如果NSEC3实际上提供了针对区域枚举的重要保护，那么可能值得使用，但它是aggressive NSEC caching并且not hard to break it if you have a decent GPU（2016-2017只能在NSEC中使用）更有用。
答案 1 :(得分：0)
DS记录位于委派区域，如果您实际配置ccTLD，则为根区域。因此，请与您在ICANN的联系人讨论如何向他们提供必要的信息。