Домен обычно воспринимается как простой адрес сайта. Вы регистрируете имя, указываете DNS-серверы, связываете его с хостингом и после этого редко возвращаетесь к настройкам. Пока все работает, задумываться о том, откуда компьютер получил IP-адрес сайта и можно ли доверять этому ответу, действительно незачем.
Но обычный DNS изначально создавался не как система с криптографической проверкой каждого ответа. Его основная задача гораздо проще: получить информацию о домене и сообщить, например, на какой IP-адрес нужно отправить пользователя.
DNSSEC добавляет к этой системе механизм проверки подлинности данных. Благодаря цифровым подписям DNS-резолвер может убедиться, что полученный ответ относится к нужной DNS-зоне и не был незаметно изменен по дороге.
Звучит так, будто DNSSEC нужно немедленно включить для любого домена. На практике все немного интереснее. Технология действительно повышает безопасность DNS, но не заменяет HTTPS, защиту аккаунта регистратора, резервные копии или безопасность самого сервера. Более того, ошибка при настройке DNSSEC способна сделать совершенно исправный сайт недоступным.
Поэтому владельцу домена полезно понимать не столько криптографию DNSSEC, сколько его назначение, ограничения и правила безопасного включения.
Как DNSSEC защищает домен
Начнем с обычной ситуации. Посетитель вводит адрес сайта в браузере. Чтобы установить соединение, устройству нужно узнать, куда ведет это доменное имя.
Для этого используется DNS.
В упрощенном виде система получает вопрос: какой адрес соответствует example.ru? В ответ приходит нужная DNS-информация, например IP сервера.
DNSSEC не меняет назначение DNS и не придумывает для сайта новый адрес. Он позволяет дополнительно проверить полученные данные.
Для этого DNS-зона подписывается криптографическими ключами. Вместе с обычными DNS-данными появляются специальные записи, которые позволяют проверяющему резолверу убедиться в корректности цифровой подписи.
Если проверка проходит успешно, ответ считается подтвержденным. Если данные были изменены или цепочка проверки нарушена, валидирующий DNS-резолвер может признать ответ недостоверным и не передавать его пользователю как обычный правильный результат.
Главная идея DNSSEC именно в этом.
Он не скрывает DNS-записи от посторонних. Вместо этого он помогает проверить, что полученная информация является той информацией, которую опубликовал владелец соответствующей DNS-зоны.
Зачем нужна цифровая подпись
Представим очень упрощенный пример.
Настоящая A-запись вашего домена ведет на сервер 192.0.2.25. Пользователь запрашивает адрес сайта и должен получить именно этот IP.
Если каким-либо способом ему удастся подставить ложный DNS-ответ с другим адресом, браузер может отправиться уже на чужой сервер. Внешне адрес в строке браузера при этом остается знакомым пользователю.
DNSSEC позволяет валидирующему резолверу проверять цифровую подпись DNS-данных. Простого изменения IP в поддельном ответе становится недостаточно: корректная подпись для измененных данных отсутствует.
Именно поэтому DNSSEC часто описывают как защиту от подмены DNS-ответов. Но важно не делать из этого слишком широкий вывод. Технология защищает определенный уровень инфраструктуры, а не весь сайт от любых атак.
Что такое DNSKEY, RRSIG и DS
После включения DNSSEC в DNS появляются записи с непривычными названиями. Обычному владельцу сайта вручную работать с каждой из них обычно не приходится, но понимать их роли полезно.
DNSKEY публикует открытый ключ, используемый в механизме проверки подписей зоны.
RRSIG содержит цифровую подпись набора DNS-записей.
DS помогает связать подписанную дочернюю зону с родительской и является важной частью цепочки доверия.
Существуют также записи, позволяющие криптографически подтверждать отсутствие запрошенного имени или типа записи.
Для пользователя все это можно представить как последовательность проверок.
Недостаточно, чтобы ваш DNS-сервер просто заявил, что его собственному ключу можно доверять. Нужна цепочка, позволяющая валидирующему резолверу прийти от уже известной доверенной точки к данным конкретного домена.
Именно здесь становится особенно важным взаимодействие DNS-провайдера, регистратора домена и родительской зоны.
Цепочка доверия
DNS устроен иерархически. Есть корневая зона, ниже находятся доменные зоны верхнего уровня, а уже внутри них зарегистрированы отдельные домены.
DNSSEC использует эту иерархию для построения цепочки доверия.
Если все необходимые звенья настроены правильно, валидирующий резолвер может последовательно проверить данные вплоть до DNS-зоны нужного домена.
Для владельца сайта отсюда следует важный практический вывод: недостаточно просто нажать кнопку включения DNSSEC где-нибудь на DNS-сервере.
Должна корректно работать вся необходимая цепочка.
Именно поэтому DNSSEC лучше включать штатными средствами регистратора или DNS-провайдера и внимательно следовать их инструкции, а не копировать случайные DS-записи из чужих примеров.
От чего DNSSEC не защищает сайт
Самая распространенная ошибка при знакомстве с DNSSEC состоит в том, что его начинают воспринимать как универсальную защиту домена.
На самом деле область его ответственности довольно четкая.
DNSSEC помогает проверять происхождение и целостность DNS-данных. Он не превращает всю остальную инфраструктуру сайта в защищенную.
DNSSEC не заменяет HTTPS
DNS и HTTPS решают разные задачи.
DNS помогает определить, куда обращаться по указанному доменному имени. DNSSEC позволяет проверить подлинность соответствующих DNS-данных.
HTTPS защищает соединение между пользователем и сайтом и использует сертификат для аутентификации сервера в рамках TLS.
Поэтому ситуация DNSSEC включен, значит SSL больше не нужен является неправильной.
Современному сайту по-прежнему нужен корректно настроенный HTTPS.
DNSSEC не шифрует DNS-запросы
Слово Security в названии иногда создает впечатление, будто после включения DNSSEC никто больше не сможет увидеть, какие домены запрашивает пользователь.
Это не так.
DNSSEC обеспечивает аутентификацию происхождения и целостность DNS-данных, но не предназначен для обеспечения их конфиденциальности.
Шифрование DNS-трафика относится к другим механизмам. Поэтому DNSSEC и технологии защищенной передачи DNS-запросов не следует считать взаимозаменяемыми.
DNSSEC не защищает сервер от взлома
Если злоумышленник нашел уязвимость в CMS, украл пароль администратора WordPress или получил доступ к серверу, наличие DNSSEC само по себе не исправит ситуацию.
DNS продолжит корректно вести посетителей на сервер, только содержимое этого сервера уже может быть скомпрометировано.
По той же причине DNSSEC не заменяет обновления программного обеспечения, надежные пароли, ограничение доступа, резервное копирование и другие обычные меры безопасности.
DNSSEC не защищает от DDoS
Технология также не является системой защиты от перегрузки сайта запросами.
DDoS решается на другом уровне инфраструктуры: фильтрацией трафика, возможностями сети и серверов, специализированными сервисами защиты и архитектурой проекта.
Сам факт наличия подписанной DNS-зоны не увеличивает вычислительные ресурсы вашего хостинга и не блокирует поток вредоносных запросов.
DNSSEC не спасает плохо защищенный аккаунт регистратора
Это особенно важно для владельца домена.
Если посторонний получил полноценный доступ к аккаунту, через который управляются домен и его настройки, проблема находится уже не в подделке случайного DNS-ответа.
Поэтому аккаунт регистратора нужно защищать независимо от использования DNSSEC.
Для него стоит использовать уникальный сложный пароль и двухфакторную аутентификацию, если она поддерживается. Контактная почта, через которую восстанавливается доступ, тоже должна быть надежно защищена.
Получается, что DNSSEC является дополнительным слоем безопасности, а не заменой остальных.
Почему из-за неправильного DNSSEC сайт может перестать открываться
У DNSSEC есть особенность, которая отличает его от многих необязательных функций панели управления.
Неправильная настройка может оказаться хуже отсутствия настройки.
Если домен не использует DNSSEC, валидирующий резолвер понимает, что зона не заявлена как защищенная соответствующей цепочкой доверия, и обрабатывает ее как неподписанную.
Но если родительская зона сообщает, что для домена должна существовать определенная криптографическая связь, а фактические данные ей не соответствуют, проверка может завершиться ошибкой.
Для пользователя это выглядит странно.
Сервер работает. Хостинг оплачен. Файлы сайта находятся на месте. A-запись визуально содержит правильный IP. SSL-сертификат действителен.
А сайт у части пользователей или вообще у всех, кто использует валидирующие резолверы, не открывается.
Причина находится раньше веб-сервера: DNS-ответ не проходит проверку.
Особенно осторожно меняйте DNS-серверы
Одна из ситуаций, когда легко получить такую проблему, возникает при переносе DNS к другому провайдеру.
Предположим, DNSSEC был настроен у старого поставщика. В родительской зоне находится DS, связанный с ключами старой DNS-зоны.
Вы меняете DNS-серверы, новый поставщик использует уже другие ключи, а старые данные DNSSEC остаются там, где не должны.
Получается разрыв цепочки доверия.
Обычная проверка A-записи может при этом сбивать с толку: IP выглядит правильным, но валидирующий резолвер все равно считает ответ недостоверным.
Поэтому при переносе DNS недостаточно скопировать A, AAAA, MX, TXT и CNAME. Если домен использует DNSSEC, его состояние тоже входит в план миграции.
Не удаляйте ключи в случайном порядке
DNSSEC связан сразу с несколькими уровнями DNS, поэтому принцип сначала удалю все старое, потом настрою заново здесь особенно опасен.
При включении, отключении, смене ключей или DNS-провайдера важен правильный порядок действий.
Конкретная процедура зависит от регистратора и сервиса, который обслуживает DNS-зону. Поэтому в данном случае инструкция самого провайдера полезнее универсального набора команд.
Если вы не уверены, какие DS и DNSKEY сейчас используются, лучше сначала проверить существующую конфигурацию и только потом менять ее.
Почему проблема может проявляться не у всех
Не каждый DNS-резолвер обязательно ведет себя одинаково с точки зрения валидации.
Из-за этого неисправность иногда выглядит как загадочная проблема доступности: с одной сети сайт открывается, с другой нет.
Владелец начинает очищать кеш браузера, переустанавливать SSL или искать блокировку IP, хотя проблема находится в DNSSEC.
Если странности начались сразу после включения DNSSEC, смены DNS-серверов или переноса домена, проверка цепочки DNSSEC должна стать одним из пунктов диагностики.
Нужно ли включать DNSSEC для обычного сайта
Если доменная зона и используемые сервисы нормально поддерживают DNSSEC, сама технология является полезным дополнительным уровнем защиты.
Особенно логично использовать ее для доменов, от которых зависит бизнес: интернет-магазина, корпоративного сайта, личного кабинета, онлайн-сервиса или другого проекта, где перенаправление пользователя не туда может иметь серьезные последствия.
Но решение нельзя свести к правилу всем срочно включить.
Сначала нужно посмотреть, поддерживает ли DNSSEC ваша доменная зона, регистратор и сервис, который фактически обслуживает DNS.
Если в панели регистратора есть штатная функция включения и весь процесс автоматизирован, владельцу сайта обычно не приходится вручную заниматься ключами и подписями.
Это наиболее удобный сценарий.
Если же DNS находится у стороннего провайдера, настройка может потребовать передачи DS-данных регистратору. Здесь уже важно понимать, какая сторона подписывает зону и где публикуется информация, необходимая для продолжения цепочки доверия.
Сначала выясните, кто управляет вашей DNS-зоной
Домен и DNS не обязательно обслуживаются одной компанией.
Домен может быть зарегистрирован у одного регистратора, а NS указывать на DNS-серверы хостинга или стороннего DNS-провайдера.
Поэтому кнопка DNSSEC в личном кабинете регистратора сама по себе еще не объясняет всю конфигурацию.
Сначала полезно определить, какие NS являются авторитетными для домена и где фактически редактируется его DNS-зона.
После этого можно смотреть инструкцию именно для используемой схемы.
Проверьте поддержку до включения
DNSSEC должен поддерживаться не только на уровне красивой надписи в панели.
Нужна рабочая цепочка между подписанной зоной и ее родительской зоной. Если используемый регистратор или DNS-провайдер не позволяет корректно выполнить необходимую настройку, экспериментировать на рабочем домене не стоит.
Особенно осторожным нужно быть с важным сайтом, который уже получает посетителей и заказы.
Если вы никогда раньше не настраивали DNSSEC, сначала изучите инструкцию регистратора и DNS-провайдера. При непонятной схеме разумнее обратиться в поддержку, чем вручную менять DS и ключи методом проб и ошибок.
После включения обязательно проверьте результат
Сам факт появления статуса включено в панели еще не означает, что вся цепочка работает правильно.
После настройки стоит проверить домен внешним инструментом, который умеет валидировать DNSSEC и показывать цепочку доверия.
Важно убедиться, что подписи проверяются, DS соответствует нужному ключу и валидирующие резолверы получают корректный результат.
Затем нужно проверить сам сайт и связанные с доменом сервисы.
DNSSEC не меняет назначение обычных записей. A по-прежнему должен вести на правильный IPv4, AAAA на рабочий IPv6, MX на почтовые серверы, а CNAME и TXT выполнять свои задачи.
Подпись неправильной DNS-конфигурации не превращает ее в правильную. DNSSEC подтверждает подлинность опубликованных данных, но не знает, тот ли IP вы сами указали в A-записи.
Учитывайте DNSSEC при будущем переносе
После успешной настройки о DNSSEC действительно можно надолго забыть, особенно если ключами автоматически управляет провайдер.
Но вспомнить о нем необходимо перед изменением DNS-инфраструктуры.
Если вы переносите сайт на другой хостинг, но оставляете прежние DNS-серверы и меняете только A-запись, сама схема DNSSEC может вообще не потребовать перестройки.
Если же меняются NS и DNS-зона переезжает к другому поставщику, ситуация другая. Новый сервис может использовать собственные ключи, а значит, перенос нужно выполнять с учетом DNSSEC.
Это еще одна причина не менять NS при каждом переезде сайта без необходимости. Если DNS обслуживается надежным сервисом и устраивает владельца, для смены веб-сервера часто достаточно изменить адрес сайта в существующей зоне.
DNSSEC не относится к функциям, которые посетитель увидит на странице или заметит по новому значку в браузере. При правильной работе он остается практически невидимым.
И в этом как раз его смысл.
Обычный DNS сообщает, какие данные относятся к домену. DNSSEC добавляет возможность криптографически проверить происхождение и целостность этих данных. Это уменьшает риск того, что валидирующий резолвер примет подмененный DNS-ответ за настоящий.
Но границы технологии нужно понимать правильно. DNSSEC не шифрует DNS, не заменяет HTTPS, не защищает CMS и сервер от взлома, не останавливает DDoS и не отменяет необходимость надежно защищать аккаунт регистратора.
Для обычного владельца сайта лучший вариант выглядит довольно просто: если доменная зона, регистратор и DNS-провайдер полноценно поддерживают DNSSEC и предлагают понятную штатную настройку, его использование имеет смысл. Особенно для важных коммерческих доменов.
Главное не включать технологию вслепую и не забывать о ней во время будущей смены DNS-серверов.
Правильно настроенный DNSSEC почти не требует внимания. Неправильно настроенный способен сделать доступ к сайту невозможным даже тогда, когда с доменом, хостингом и самим сервером на первый взгляд все в полном порядке.
