我有机会配置 IDN ccTLD。我已经配置了 DNS 服务器并且它工作正常。现在我有一个挑战来保护 DNSSEC 的 dns 服务。我通过自签名配置了 DNSSECC。但是现在我不明白应该在哪里以及如何输入 DS 记录。
2 回答
虽然Calle Dybedahl回答“在哪里”,但我想提供一些关于“如何”为您的 ccTLD(IDN 或其他)启用 DNSSEC 的指示。
Viktor Dukhovni 的“常见错误”页面处理了许多特定于 DANE 的事情(使用 DNSSEC 作为证书的锚,尤其是 SMTP),但他的前两点(以及倒数第二点)对任何运营商都有效实施 DNSSEC,尤其是任何类型的 TLD。
特别是,下面删减的第一点至关重要:
发布 DNSSEC DS 记录……作为时尚宣言
保持这些正确需要操作纪律。期望“一劳永逸”的管理员不应该发布 DNSSEC 签名区域……或者他们可以付费给其他人托管他们的区域……操作维护不善的 DNSSEC 区域……不仅给相关域带来问题,而且给所有试图与这样一个域通信的域。如果 DNSSEC ... [被]认真对待,每个人都会过得更好。
有许多 ccTLD 在维护其 DNSSEC 签名区域正常运行方面的记录远非一流;有一个“耻辱厅” ——只需查找在 IANIX 中断列表中多次出现的 TLD。
由于您的 IDN ccTLD 是一个新的 TLD,DNSSEC 是强制性的,因此即使您吞下 IANIX 为您提供的红色药丸并放弃 DNSSEC,您仍然别无选择,只能实施它。您应该尽一切努力将您的 DNSSEC 部署视为最重要的责任,因为作为 TLD,它不仅会直接影响您的域的操作和安全,而且还会影响在其注册的所有域的操作和安全。
此外,与 DNSSEC 一样困难和有问题,它不太可能消失,并且验证 DNSSEC本身(或仅依赖 DNSSEC 验证解析服务,如Google Public DNS、Comcast ISP或Verisign Public DNS)的客户端数量是显着,超过全球所有客户的 15%,在许多可能成为 IDN ccTLD 候选者的国家/地区的客户数量要多得多(请参阅上一个链接中的区域和每个国家/地区的深入分析,例如肯尼亚,其中 40% 的客户依赖 DNSSEC 验证,而.KE TLD 上个月出现了严重的 DNSSEC 中断)。
如果您想“自己动手”并推出自己的 DNSSEC 区域签名,则ISOC有很好的资源和最佳实践 PDF来帮助您管理 DNSSEC。但是很容易出错,而且如果没有定期监控和待命响应,您的 DNSSEC 签名可能会过期并导致数百万人无法访问您的整个域。更糟糕的是,如果用于 DNSSEC 签名的私钥被泄露,任何依赖 DNSSEC 的域的安全都可能受到威胁。
您可能需要认真考虑,从长远来看,使用可以提供托管 DNSSEC 的商业 DNS 提供商为您的 IDN ccTLD 托管区域是否更容易和更便宜(当您操作 TLD 的注册方并更新区域时)使用 DNS 管理 API 从您的注册表实施中获取)。
最后一条建议;除非您授权数百万个在您的 ccTLD 中没有 DS 记录且需要NSEC3 选择退出的域,或者您在数据隐私法[1] [2]可能要求您使用 NSEC3 的欧洲运营,否则您可能应该使用旧的现在是 -style NSEC,因为它允许 Google 公共 DNS(和其他积极 NSEC 缓存的实现)吸收 NXDOMAIN 拒绝服务攻击和垃圾查询,而无需将它们转发到您的权威服务器。如果 NSEC3 确实提供了针对区域枚举的重要保护,那么它可能值得使用,但如果你有一个不错的 GPU并且可以防止 NXDOMAIN 攻击,那么破解它并不难(在 2016-2017 年只有 NSEC 才有可能)更有用。
DS 记录位于委派区域中,如果您实际配置的是 ccTLD,则该区域是根区域。因此,请与您在 ICANN 的联系人讨论如何向他们获取必要的信息。