Защита DNS при помощи TLS позволяет скрыть состав DNS-трафика, который обычно передаётся в открытом виде. Соединения DNS-over-TLS не так распространены, как DNS-over-HTTPS, но зато могут прозрачно применяться не только для доступа к резолверам, но и на авторитативных серверах. Посмотрим, вооружившись консольными утилитами, как всё это работает на практике.
Я много пишу о технологиях, которые показались мне сложными. Недавно моя подруга Сумана задала мне интересный вопрос – почему все эти вещи так сложно изучать? Почему они кажутся такими загадочными?
Для примера возьмём DNS. Мы пользуемся DNS с 80-х (больше 35 лет!). Он применяется на каждом веб-сайте Интернета. И он довольно стабилен – во многих смыслах он работает точно так же, как делал это тридцать лет назад.
Но мне понадобились ГОДЫ, чтобы понять, как с уверенностью отлаживать проблемы с DNS, и я видела множество программистов, тоже испытывавших трудности с отладкой проблем DNS. Что же происходит?
Я приведу пару своих рассуждений о том, почему устранять проблемы DNS трудно.
(В этом посте я не буду глубоко объяснять DNS, подробности о его работе см. в моём посте Implement DNS in a Weekend или в других моих постах о DNS.)
Протокол DNS (Domain Name System Protocol) является одним из важнейших инфраструктурных протоколов для поддержки сети Интернет и первоначально он разрабатывался для максимальной производительности и возможности распределенного хранения неограниченного числа доменных зон. DNS может функционировать поверх UDP-протокола и это уменьшает накладные расходы на установку соединения и избыточный трафик в сети. Но одной из важнейших проблем стала безопасность обмена данными, поскольку клиент в первоначальном варианте протокола не может проверить достоверность информации и это может приводить к подмене ip-адресов злоумышленниками с переадресацией клиента на фишинговый сайт.
Для решения этой проблемы были введены расширения DNSSEC для генерации цифровой подписи ответа. Но сам запрос и ответ при этом не шифровались, что могло быть использовано для ограничения доступа к определенным доменам или для получения на транзитных узлах статистики доступа к хостам. Частично эту проблему решило использование инкапсуляций DNS-over-TLS (DoT, использует TLS для шифрования UDP-дэйтаграмм) и DNS-over-HTTPS (DoH, передает запросы и ответы поверх HTTPS-подключения), которые функционируют поверх TCP. В первом случае запрос более компактный (но может быть обнаружен по анализу трафика), во втором DNS-диалог неотличим от подключения к сайту или веб-сервисам, но при этом существенно увеличивает избыточной трафик (даже при использовании HTTP/2), а также вынужденно добавляет заголовки (которые могут использоваться для трекинга и перехвата cookies). Но можно ли как-то объединить преимущества UDP и DoH? Встречаем DNS-over-QUIC, который был утвержден в RFC9250 как Proposed Standard.
Примерно в середине сентября 2021 года на сети Мегафон заработала DNSSec валидация. Такой вывод можно сделать из изменений в графике на ресурсе stats.labs.apnic.net.
Сегодня я расскажу о том, как быстро собрать отказоустойчивый кластер с балансировкой нагрузки с помощью keepalived на примере DNS-серверов.
В сети любого Интернет-провайдера можно встретить такой обязательный элемент, как кэширующий DNS сервис. А поскольку работа сети Интернет без службы DNS невозможно, серверов таких будет минимум два, с обязательным резервированием и балансировкой. В заметке я постараюсь описать один из вариантов балансировки нагрузки между несколькими кэширующими серверами на основе Cisco IP SLA.
В своем блоге мы уже касались темы законодательных инициатив, формирующих мировой интернет-ландшафт. Сегодня говорим про еще один проект, который может изменить расстановку сил на европейском ИТ-рынке. Правда, далеко не все верят в его успешность (и необходимость).
По мере того, как наши дети погружаются в современные технологии, им приходится сталкиваться с новыми угрозами, с которыми не всегда способны справиться даже их родители. Запрещать использование интернета ради детской безопасности в нашем мире уже бессмысленно — это неотъемлемая часть нашей реальности. Для примерно 15% подростков в возрасте от 12 до 17 лет интернет стал местом, где они проводят треть жизни. Надо отметить, что подростки не стремятся разделить этот новый опыт с родителями: более половины детей скрывают от родителей свои нежелательные действия в интернете. А раз мы не можем постоянно сопровождать детей в новом для них мире, остается положиться на автоматизированные средства защиты.
Надо было мне разобраться получше с iptables и ansible, а для этого нужна задачка. Задачка была выбрана такая: поднять свой VPN сервер с возможностью резки рекламы и прочего spyware.
Суть происходящего при резке рекламы с помощью DNS сервера состоит в том, что когда клиент спрашивает сервер какой IP адрес сопоставлен имени хоста, то DNS сервер отвечает ему 0.0.0.0 В итоге клиент ходит сам к себе и быстро получает отказ, так что не пользуется для этого модемом связи в случае с телефоном. Что экономит батарейку не просто на процент, а при моем режиме использования телефона время автономной работы выросло с 8-10 часов до 23.5. Специально засекал и был мягко говоря удивлен. Как показала практика 85% запросов от телефона это spyware.
Ansible был выбран потому, что для настройки всего даже на настраиваемый сервер заходить не надо, просто нужен доступ по ssh к нему. После настройки конфиги для подключения к VPN будут лежать в папке с плейбуком. Да и сам запуск это одна команда. Не люблю я запоминать, что я там пять лет назад настроил и Ansible для того что бы этого не делать идеален, не говоря уже о прочих его достоинствах. Запустил у себя на ноуте плейбук, он все тебе на сервере настроил, потом отсканил QR код на телефоне, работает.
В качестве DNS сервера с возможностью резать телеметрию и прочую гадость был выбран Pi-hole DNS. Просто потому, что он очень не требователен к ресурсам и мне хватает на амазоне t3.nano ноды, которую мне дали бесплатно на год. При этом я видел на DigitalOcean готовый дрополет Pi-hole VPN, но он прибит к этому провадйеру, а мой плейбук я пробовал уже на двух разных и он просто пашет, плюс там видно все, что он делает. Плюс ко всему при установке он закачивает более 5млн бан записей в DNS что бы не искать их потом.
Различные аспекты эксплуатации DNS уже неоднократно затрагивались автором в ряде статей опубликованных в рамках блога. При этом, основной акцент всегда делался на повышение безопасности этого ключевого для всего Интернет сервиса.
До последнего времени, несмотря на очевидность уязвимости DNS трафика, который, до сих пор, по большей части, передаётся в открытом виде, для злонамеренных действий со стороны провайдеров, стремящихся повысить своих доходы за счёт встраивания рекламы в контент, государственных силовых органов и цензуры, а также просто преступников, процесс усиления его защиты, несмотря на наличие различных технологий, таких как DNSSEC/DANE, DNScrypt, DNS-over-TLS и DNS-over-HTTPS, буксовал. И если серверные решения, а некоторые из них существуют уже довольно долгое время, широко известны и доступны, то поддержка их со стороны клиентского программного обеспечения оставляет желать много лучшего.
