где и как отправить запись DNSSEC DS для IDN ccTLD

В то время как Calle Dybedahl ответил "где", я хотел бы предложить несколько советов о том, "как" вы должны включить DNSSEC для вашего ccTLD (IDN или иного).

На странице Виктора Духовного "Распространенные ошибки" рассматривается множество вещей, характерных для DANE (использование DNSSEC как якорь для сертификатов, особенно для SMTP), но его первые два пункта (и предпоследний) действительны для любого оператора, реализующего DNSSEC, особенно TLD любого типа.

В частности, жизненно важен первый пункт, сокращенно приведенный ниже:

Публикация записей DNSSEC DS... как дань моде

Соблюдение этих правил требует операционной дисциплины. Администраторам, которые ожидают, что «выстрелил и забыл», не следует публиковать зоны, подписанные DNSSEC... Или они могут платить другим за размещение своих зон... Эксплуатация плохо обслуживаемых зон DNSSEC... создает проблемы не только для рассматриваемого домена, но и для все домены пытаются связаться с таким доменом. Всем будет лучше, если DNSSEC... [будет] восприниматься всерьез.

Есть ряд нДВУ, чьи записи в плане поддержания их зон, подписанных с помощью DNSSEC, в надлежащем режиме далеки от выдающихся; есть "зал позора" — просто ищите TLD, которые появляются более чем один раз в списке отключений IANIX.

Поскольку ваш 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 произошел значительный сбой DNSSEC).

Есть хорошие ресурсы на ISOC и PDF с рекомендациями, который поможет вам управлять DNSSEC, если вы хотите «сделать это самостоятельно» и внедрить собственную подпись зоны DNSSEC. Но очень легко ошибиться, и без регулярного мониторинга и реагирования на вызовы срок действия ваших подписей DNSSEC может истечь, и весь ваш домен станет недоступным для миллионов. Хуже того, если закрытые ключи, используемые для подписи DNSSEC, скомпрометированы, безопасность любых доменов, зависящих от DNSSEC, может оказаться под угрозой.

Вы можете серьезно подумать, не будет ли в долгосрочной перспективе проще и дешевле размещать зоны для вашего IDN ccTLD у коммерческого провайдера DNS, который может предоставить управляемую DNSSEC (пока вы работаете со стороной реестра TLD и обновляете зоны). из вашей реализации реестра с помощью API управления DNS).

Последний совет; если только вы не делегируете миллионы доменов, для которых нет записей DS в вашем ccTLD и вам не требуется отказ от NSEC3, или вы не работаете в Европе где действуют законы о конфиденциальности данных[1][2] может потребовать, чтобы вы использовать NSEC3, вам, вероятно, следует использовать старый стиль NSEC, так как он позволяет Google Public DNS (и другие реализации агрессивное кэширование NSEC), чтобы поглощать атаки типа "отказ в обслуживании" NXDOMAIN и нежелательные запросы, не перенаправляя их на ваши авторитетные серверы. Если бы NSEC3 действительно предлагал значительную защиту от перечисления зон, возможно, его стоило бы использовать, но это не сложно сломать его, если у вас приличный графический процессор и защита от атак NXDOMAIN (в 2016–2017 годах возможна только с NSEC) более полезна.

Запись DS находится в зоне делегирования, которая, если вы фактически настраиваете ccTLD, является корневой зоной. Поэтому поговорите со своим контактным лицом в ICANN о том, как передать им необходимую информацию.