21 октября в рамках конференции ICANN87 прошел традиционный семинар DNSSEC and Security Workshop – технический форум, посвященный расширениям безопасности системы доменных имен и общим вопросам защиты DNS-инфраструктуры. В семинаре принял участие консультант Координационного центра доменов .RU/.РФ по инфраструктуре Вадим Михайлов.
Мероприятие организовано Консультативным комитетом по безопасности и стабильности (SSAC) ICANN и традиционно собирает ведущих специалистов отрасли для обмена опытом и передовыми практиками, связанными с развертыванием и управлением DNSSEC. Семинар направлен на распространение знаний о методах работы, возникающих проблемах, факторах безопасности и стратегиях управления интернет-инфраструктурой.
Открыл семинар Гэвин Браун (Gavin Brown) с докладом «DNSSEC Automation Fast Track RSEP». Он представил обзор принципов автоматизации DNSSEC и соответствующих стандартов RFC, а затем подробно остановился на трех рекомендациях, которые были приняты Правлением ICANN к рассмотрению в сентябре 2025 года и в настоящее время находятся в стадии разработки плана по их внедрению. В соответствии с ними, рекомендуемым совместимым механизмом для автоматизации DNSSEC является CDS/CDNSKEY (RFC 7344, RFC 9615). ICANN должна оказывать поддержку реестрам и регистраторам, внедряющим автоматизацию DS-записей, в том числе путем содействия включению соответствующих механизмов в процедуру Fast-Track RSEP, а также содействовать разработке эксплуатационных руководств для реестров и регистраторов по внедрению автоматизации DS-записей. Эти рекомендации призваны упростить и стандартизировать процессы управления DNSSEC для операторов доменных зон по всему миру.
Билькису М. Кида (Bilkisu M. Kida), представляющая Комиссию по связи Нигерии (NCC) и Ассоциацию интернет-регистрации Нигерии (NiRA), рассказала о важности применения DNSSEC в национальных доменных зонах. В своем докладе она объяснила, как расширение DNSSEC позволяет противостоять таким атакам, как отравление кэша DNS, и представила дорожную карту внедрения и валидации доменных имен в Нигерии.
Процесс стартовал относительно недавно – в 2024 году, с обсуждения со всеми заинтересованными сторонами региона. В феврале 2026 года зона .NG была успешно подписана. На текущий момент из чуть более чем 250 тысяч зарегистрированных доменов второго уровня в зоне подписано около 300, что демонстрирует начало практического внедрения технологии на национальном уровне.
Годсвей Куби (Godsway Kubi), стипендиат ICANN, в презентации «From Global DNS Security Norms to Local Survivability: Policy Lessons from Africa» поднял вопрос о том, что понимается под глобальными нормами безопасности DNS в мире и в африканском регионе в частности. Докладчик начал с краеугольных понятий стабильности, устойчивости и выживаемости DNS, особо отметив, что последнее сложнее всего протестировать на состоятельность. Он рассказал об основных компонентах DNS – криптографии, сетевой маршрутизации, инфраструктуре и ПО, а также о персонале, работающем со всем этим. По его мнению, только слаженное взаимодействие всех этих компонентов способно обеспечить выживаемость DNS. В завершение Годсвей Куби сформулировал тезисы для формирования фреймворка по выживаемости DNS и пригласил всех желающих присоединиться к этой работе.
Сайед Васиф Аббас Хамдани (Syed Wasif Abbas Hamdani) из отделения ISOC в Исламабаде (Пакистан) представил доклад «Decentralized, Tamper-Evident Audit Trails for Network Security Monitoring: The BENSAM Framework». Он поднял вопрос доверия к различным записям, в том числе к ресурсным записям DNS.
Основная мысль доклада заключалась в том, что при расследовании инцидентов множество записей попадает в так называемый security log – журнал событий информационной безопасности, и зачастую нет понимания, насколько можно доверять содержащейся в нем информации и каким образом ее валидировать. В качестве решения Хамдани предложил BENSAM (Blockchain-Enhanced Network Scanning and Monitoring) – фреймворк для хранения, передачи и валидации security logs на основе технологии блокчейн, что обеспечивает неизменяемость и прозрачность аудиторских следов.
Вторая часть семинара была полностью посвящена автоматизации DS-записей и процедурам мультиподписания DNSSEC. Секция была построена в формате дискуссии со вступительными словами отдельных представителей отрасли. Модератором выступил Питер Томассен (Peter Thomassen, deSEC), который также рассказал о недавно опубликованном документе Best Current Practice on DS Automation (BCP 246), посвященном лучшим практикам автоматизации управления DS-записями.
Аарон Фоули (Aaron Foley) из IANA представил доклад «The Road to KSK Rollover #2», посвященный третьей в истории ротации ключа корневой зоны DNSSEC – KSK-2024, которая состоялась 11 октября 2026 года. Ключ был опубликован за 21 месяц до ротации – 11 января 2025 года, чтобы все резолверы могли своевременно к нему адаптироваться, а сгенерирован он был 26 апреля 2024 года на специальной церемонии генерации ключа. Предыдущий ключ, KSK-2017, получит статус «revoke» (отозван) с 11 января 2027 года и будет полностью удален из корневой зоны 22 марта 2027 года.
Карлос Вера (Carlos Vera) из ISOC в докладе «DNSSEC LAC» рассказал об опыте внедрения технологии DNSSEC в Латинской Америке в целом и в Эквадоре в частности. Также он представил результаты исследования поддержки технологии DNSSEC в Аргентине, Панаме, Уругвае и Парагвае, что позволило участникам семинара получить представление о региональной специфике внедрения механизмов безопасности DNS.
Витторио Бертолла (Vittorio Bertolla) из Open-Xchange поднял актуальную тему блокировок доступа к ресурсам на разных уровнях: на уровне политик пользователей (например, родительский контроль), на уровне интернет-провайдеров (ISP) и на уровне решений локальных (страновых) регуляторов.
Докладчик не стал давать оценку тому, хорошо это или плохо – споры в экспертной среде на эту тему не угасают. Однако он представил работу, проводимую в IETF, по маркировке блокировок на уровне ответов резолверов в целях улучшения пользовательского опыта. Действительно, пользователь зачастую видит, что не может получить доступ к запрашиваемому ресурсу, однако причины от него сокрыты: является ли это результатом сбоя у ISP (или политики защиты пользователей), ошибочной настройки собственного ПО или государственным регулированием, запретившим доступ к ресурсу.
В рамках работы IETF предлагается маркировать ответы специфическим кодом ошибки в случае блокировок ресурса в соответствии со следующим принципом:
- Error 15 – Blocked – заблокировано интернет-провайдером;
- Error 16 – Censored – цензура государственного регулятора;
- Error 17 – Filtered – отфильтровано по запросу пользователя.
Обсуждение этой инициативы было инициировано еще в 2020 году, однако первый драфт стандарта появился только в ноябре 2024 года. На текущий момент обсуждается вторая модификация предложенного драфта.
Семинар DNSSEC and Security Workshop подтвердил, что безопасность DNS остается одной из наиболее динамичных и практически значимых сфер в работе интернет-сообщества. Технические стандарты, региональный опыт внедрения и инновационные подходы к защите инфраструктуры тесно переплетаются с вопросами пользовательского опыта и государственной политики, формируя комплексную картину современной интернет-безопасности.