DNS-over-TLS на авторитативных серверах DNS
Авторитативные серверы DNS – это серверы, которым делегирована поддержка заданной доменной зоны. Другими словами, это основные серверы, служащие первоисточником информации об адресации внутри доменной зоны. Именно к авторитативным серверам должен обращаться рекурсивный резолвер при поиске значений DNS-записей.
DNS-over-TLS – технология, защищающая трафик DNS-запросов при помощи TLS. Обычно, DNS-запросы и DNS-ответы передаются по протоколу UDP (реже – TCP) в открытом и незащищённом виде. Существует технология DNSSEC, которая позволяет снабдить содержание DNS-ответов электронной подписью, затруднив, таким образом, подмену информации. Но DNSSEC не скрывает сам трафик: то есть, третья сторона всё равно будет видеть состав запросов и ответов. Кроме того, DNSSEC аутентифицирует только передаваемые данные, привязывая их к некоторому открытому ключу, но не позволяет аутентифицировать сервер, который данные передал. В принципе, в модели угроз DNSSEC аутентификация сервера и не требуется: основная идея этой технологии состоит в том, что не имеет значения, каким маршрутом и от какого узла DNS-данные попали к клиенту – если данным соответствует валидная подпись от доверенного ключа, то они, так или иначе, достоверны. То есть, с точки зрения достоверности, канал получения DNS-информации для DNSSEC не важен. Если данные, защищённые DNSSEC, будут как-то изменены на транзитном узле, то клиент сможет обнаружить подмену. С DNS-over-TLS (или DoT) – другая история. Эта технология оборачивает обычный трафик DNS в TLS, создавая защищённый канал связи. DoT позволяет узлам, которые намерены обменяться DNS-запросом и DNS-ответом, аутентифицировать друг друга до отправки запроса. В подавляющем большинстве случаев, конечно, будет использоваться только аутентификация сервера клиентом.
В DNS, как в сервисе, большое значение имеет взаимодействие рекурсивного резолвера с так называемым stub-резолвером. Последний представляет собой самый простой вариант резолвера, который не выполняет поиска в DNS, а лишь перенаправляет запросы рекурсивному резолверу. Stub-резолвер – это типовой резолвер в подавляющем большинстве конфигураций операционных систем. Сервис же рекурсивного резолвера предоставляется либо провайдером доступа, либо отдельным провайдером DNS, как, например, в случае общедоступных резолверов Cloudflare (1.1.1.1) и Google (8.8.8.8).
Так вот, сейчас часто приходится слышать, что технология DNS-over-TLS предназначена лишь для защиты DNS-трафика на пути от stub-резолвера до рекурсивного резолвера, а на авторитативных серверах – не нужна. Это не так. Авторитативным серверам тоже рекомендована поддержка DNS-over-TLS, так как такая поддержка позволит защитить обмен информацией с рекурсивными резолверами. Дело в том, что прослушивание DNS-запросов или подмена данных – возможны и для трафика рекурсивного резолвера, адресованного не клиенту, а авторитативному серверу. Другое дело, что реализовать избирательность такой атаки становится сложнее, поскольку точно не известно, какие запросы какому клиенту соответствуют. Но, например, если используется популярный сервис DNS, то IP-адреса его узлов-резолверов известны, поэтому подмена может осуществляться избирательно. Впрочем, атакующему придётся каким-то образом встать своим транзитным узлом между авторитативным сервером и сервером DNS-резолвера. Это сложно, но возможно. Причём, разными способами. А не раз продемонстрированные на практике BGP-атаки позволяют перехватить трафик между сетями, которые, в смысле маршрутизации, находятся “далеко” от точки перехвата.
Поддержка DoT на авторитативных серверах пока что является большой редкостью и встречается существенно реже, чем даже поддержка DNSSEC. Тем не менее, один масштабный пример внедрения DoT здесь уже есть: технология поддерживается авторитативными серверами Facebook, на которые делегирована зона facebook.com.
Адрес записки: https://dxdt.ru/2020/06/15/8898/
Похожие записки:
- Работа GPS и коррекция по данным многих устройств
- HTTPS-записи в DNS и RFC 9460
- Пресертификаты в Certificate Transparency
- Нормализация символов Unicode и доменные имена
- Ретроспектива заметок: ключ по фотографии
- Подпись и использование ключей из TLS-сертификатов для веба
- Статья о Certificate Transparency
- Статья про защиту DNS-доступа
- Обновление описания TLS
- Starlink и взаимодействие с наземными GSM-сетями
- SPF и домен Microsoft hotmail.com
Комментарии читателей блога: 2
1. 15th June 2020, 13:26 // Читатель Илья написал:
Полностью согласен.
Как человек, имеющий небольшой кеширующий рекурсор дома (unbound с парой самопальных патчей), могу сказать, что мой эксперимент с включением DoT (в смысле, снача DoT, после таймаута, plain) для рекурсивных запросов полностью провалился: подавляющее большинство авторитативных серверов либо не имеют поддержки DoT, либо имеют, но отвечают с некорректным сертификатом.
Я логгировал все запросы к авторитативным серверам. Результат расстроил: за неделю корректных ответов было что-то около пары сотен (из около 2млн). Сколько всего серверов отвечали корректно я не считал, но подозреваю, что не больше 3-4х.
2. 15th June 2020, 15:17 // Александр Венедюхин:
> отвечают с некорректным сертификатом
Там есть разные модели аутентификации. В принципе, сертификат здесь даже может быть самоподписанным: такой вариант, конечно, в общем случае, не защитит от активного перехвата и подмены, но позволит использовать шифрование. Кроме того, аутентификация может проводиться по отпечатку серверного ключа, который резолвер либо запоминает при первом обращении (как вариант), либо получает из доверенного источника, в том числе, при помощи DNSSEC. На данном этапе развития DoT – я бы принимал сертификаты вообще без валидации.
Написать комментарий