У меня появилась возможность настроить ccTLD IDN. Я уже настроил DNS-сервер, и он работает правильно. Теперь у меня есть вызов для обеспечения службы dns DNSSEC. Я сконфигурировал DNSSECC самоподписанием. Но теперь я не могу понять, где и как я должен записывать запись DS.где и как подать DNSSEC DS-запись для IDN ccTLD
Запись DS живет в зоне делегирования, которая, если вы на самом деле настраиваете ccTLD, является корневой зоной. Поэтому поговорите с вашим контактом в ICANN о том, как получить необходимую информацию.
В то время как Calle Dybedahl ответил «где», я хотел бы предложить несколько указателей о том, «как» вы должны включить DNSSEC для вашего ccTLD (IDN или иначе).
Страница "Common Mistakes" Виктора Духовни посвящена множеству вещей, специфичных для DANE (использование DNSSEC в качестве привязки для сертификатов, особенно для SMTP), но его первые два пункта (и следующий за последним) действительны для любых оператор, осуществляющий DNSSEC, , особенно ДВУ любого типа.
В частности, первая точка, сокращенная ниже, имеет жизненно важное значение:
Publishing DNSSEC DS записи ... как мода заявление
Сохраняя это правильно требует оперативной дисциплины. Администраторы , которые ожидают, что «огонь и забыть» не должны публиковать подписанные зоны DNSSEC ... Или они могут заплатить другим за размещение своих зон ... Плохо работает Зоны DNSSEC ... создают проблемы не только для домена , но и для всех доменов, пытающихся установить связь с таким доменом. Все лучше, если DNSSEC ... [принимается] серьезно.
Существует несколько нДВУ, чьи записи с точки зрения поддержания их зон, подписанных DNSSEC, в правильной эксплуатации далеки от звездных; есть "hall of shame" - просто посмотрите на TLD, которые появляются более одного раза в списке IANIX.
Поскольку ваш IDN ccTLD является новым TLD, DNSSEC является обязательным, поэтому даже если вы должны проглотить красную таблетку, которую IANIX предлагает вам и откажется от DNSSEC, у вас все равно не будет выбора, кроме как реализовать ее. Вы должны приложить все усилия, чтобы рассматривать развертывание DNSSEC как обвинение в максимальной степени тяжести, поскольку в качестве TLD оно непосредственно влияет на работу и безопасность не только вашего домена, но и всех зарегистрированных на нем доменов.
Кроме того, как трудно и проблематично, так как DNSSEC есть, вряд ли уйдет, а число clients that validate DNSSEC самих (или полагаться исключительно на услуги разрешения DNSSEC-проверочных как Google Public DNS, Comcast ISP или Verisign Public DNS) является значительным, exceeding 15% of all clients worldwide и значительно больше во многих странах, которые, вероятно, являются кандидатами на ccTLD IDN (см. regional и данные по странам по предыдущей ссылке для примеров, таких как Kenya where 40% of clients rely on DNSSEC validation и .KE TLD had a significant DNSSEC outage last month).
Есть хорошие ресурсы в ISOC и a best practices PDF, чтобы помочь вам управлять DNSSEC, если вы хотите «сделать это сами» и перевернуть свою собственную подпись зоны DNSSEC.Но это очень легко сделать неправильно, и без регулярного мониторинга и ответа по вызову ваши подписки DNSSEC могут истечь и сделать весь ваш домен недостижимым для миллионов. Хуже того, если секретные ключи, используемые для подписи DNSSEC, скомпрометированы, безопасность любых доменов в зависимости от DNSSEC может быть поставлена под угрозу.
Возможно, вам стоит серьезно подумать над тем, не может ли быть проще и дешевле в долгосрочной перспективе разместить зоны для вашего IDN ccTLD с помощью коммерческого DNS-провайдера, который может предоставить управляемый DNSSEC (при управлении участком реестра TLD и обновлять зоны из реестра, используя API управления DNS).
Последний совет; если вы не делегируете миллионы доменов, у которых нет записей DS в вашем ccTLD, и вам нужно NSEC3 opt-out, или вы работаете в Европе, где законы конфиденциальности данных [1][2] могут потребовать использования NSEC3, вероятно, вы должны использовать NSEC старого стиля, поскольку сейчас он позволяет Google Public DNS (и другим реализациям aggressive NSEC caching) поглощать атаки NXDOMAIN Denial Service и нежелательные запросы без пересылки их на ваши авторитетные серверы. Если бы NSEC3 фактически предлагал значительную защиту от переписи зон, ее можно было бы использовать, но это not hard to break it if you have a decent GPU, а protection against NXDOMAIN attacks (в 2016-2017 гг. Возможно только с помощью NSEC) является более полезным.