DNS *

Привет, меня зовут Сергей Качеев, я старший разработчик в отделе сетевой инфраструктуры Яндекса. Сегодня я расскажу целый сетевой детектив о том, как мы искали баг, который убивал DNS сервер Unbound. Приготовьтесь, он будет долгим.

Всё началось с того, что мне предложили помочь ребятам из команды DNS найти такие метрики и наборы запросов, по которым будет однозначно понятно, какие настройки влияют на производительность Unbound и какие запросы вызывают у него проблемы.

В самом начале на графиках нагрузочного тестирования я увидел очень плохие результаты: случайным образом абсолютно все запросы нагрузочного теста таймаутились, но сервер, который был под нагрузкой, никак не реагировал на проблему. Как выяснилось позже, по чистой случайности я допустил ошибку в конфигурации нашего плагина Pandora, и в итоге он сам ходил в DNS на каждый запрос, чтобы узнать ip адрес тестируемого сервера. Возможно, это сыграло мне на руку и помогло найти первую из проблем, а потом и вовсе задало вектор поисков остальных багов. А в Unbound их накопилось достаточно.

Всем привет! Меня зовут Максим, я руководитель одной из групп эксплуатации инфраструктурных сервисов в Ozon. Наша команда занимается поддержкой и развитием нескольких базовых сервисов компании, одним из которых, по историческим причинам, является сервис разрешения доменных имен (DNS).

В Ozon много различных сервисов и систем. Они общаются друг с другом и внешним миром по доменным именам. DNS — центральное звено, без которого не обходится почти ни одна инфраструктура. Понятно, что когда DNS отдаёт некорректные данные, то это неприятно, когда таймаутит — плохо, когда прилёг — очень плохо, когда прилёг надолго — в принципе, можно расходиться. Значит, одна из основных задач команды инфраструктуры — обеспечить сервисам надёжное и, желательно, быстрое разрешение доменных имён. Об этом мы и поговорим. Также затронем вопросы управления ресурсными записями, жизнь в Multi DC-среде, обслуживание DNS, кеширование, журналирование запросов и возможные проблемы.

Статья может быть полезна коллегам, интересующимся эксплуатацией, архитектурой и высокой доступностью сервисов, да и просто может быть любопытна как история построения инфраструктурной единицы в крупной компании.

В своем блоге мы уже касались темы законодательных инициатив, формирующих мировой интернет-ландшафт. Сегодня говорим про еще один проект, который может изменить расстановку сил на европейском ИТ-рынке. Правда, далеко не все верят в его успешность (и необходимость).

Первая Часть

Предыдущая часть закончилась неудачной балансировкой, которая не решает практически никаких проблем. В комментариях кто-то спросил, почему я не использовал балансировку на уровне DNS. Так вот, я ее использовал. Оказалось, что c помощью DNS записей можно организовать балансировку Round Robin. Для этого в конфигурации Wireguard всего лишь нужно использовать доменное имя вместо IP адреса.

Привет, Хабр!

Меня зовут Ксения Рысаева, я руковожу группой аналитиков в Центре противодействия киберугрозам Innostage CyberART. Мы с командой решили пофантазировать, а что может случиться, если хакер пробьет защиту регистратора доменов. Фантазии быстро улетучились, когда цепочка привела нас к неутешительным выводам — если положить регистратора, пострадают абсолютно все.

Давайте вместе разберемся, что будет, если злоумышленник получит доступ к регистратору домена.

Ранее (11 февраля 2019) пост уже публиковался мной с таким заголовком, но был отправлен в небытие по причине смерти домена, а как следствие и сервиса с ним связанного. Причин тогда было две — статистика скачивания докер-образа оставляла желать лучшего, и цена за продление домена (что был зарегистрирован в nic) стала для меня неожиданно выше той, которую я был морально готов заплатить за него.

Но есть время не продлять домены разбрасывать камни, а есть время извиниться за сделанную ошибку. Все, кому сервис был полезен, кто им пользовался и однажды заметил что он (localhost.tools) не резолвится — приношу свои извинения, и исправляю ситуацию (лучше поздно чем никогда, верно?).

Ниже я вкратце расскажу о чем вообще идёт речь, что изменилось, и как этим всем пользоваться. Для нетерпеливых, традиционно — репозиторий и ссылочка на сайт.

Если вы впервые столкнулись с необходимостью поднять DNS-сервер для локальной сети под Linux, то эта статья – для вас. Преимущество предлагаемого способа – простота: сервер можно настроить буквально за несколько минут. Но этот способ, скорее всего, не подойдёт для продакшн серверов.

Автор статьи провёл несколько часов в борьбе с ошибками, багами и непонятным поведением системы прежде чем получил стабильный результат.

Протокол 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.

Год назад я написал статью про "Национальную систему доменных имён", в которой были рассмотрены некоторые технические аспекты её организации, в основном то что касается доступности узлов этой системы, а не аспектов работы DNS. Я не следил, но надеялся встретить за этот год больше информации изнутри, но мне она не попалась. Конференций и каких-то публичных технических мероприятий всё ещё было не очень много, где обычно такая информация появляется, но если кто-то что-то встретил просьба поделиться, я добавлю ссылки сюда и удовлетворю своё любопытство.

Я попробовал поискать в Google доступную информацию, но и там ничего не нашёл, кроме новостей, приказов об основании этой системы и редких ссылок на инструкцию по подключению, вот например на labs.ripe.net в PDF и с подписями. На сайте Роскомнадзора мои усилия тоже закончились ничем. Я подозреваю что какие-то документы есть внутри ЦМУ ССОП, но туда заходить я не стал.

При всём при этом НСДИ остаётся публичной системой, воспользоваться которой может, как минимум, каждый пользователь Интернет в России. Кроме того, за год накопились данные мониторинга с RIPE Atlas на созданных мною измерениях, используя которые мы и посмотрим к чему мы пришли. Мы не выйдем структурно за рамки прошлой статьи и наш взгляд будет всё равно поверхностный, но имея гораздо больший объём данных сможем посмотреть на это чуть пошире.

Тема задержки доступа и скорости извлечения сетевых ресурсов никогда не перестанет быть актуальной. Максимально близкое расположение источника влияет не только на скорость загрузки и пользовательский опыт, но и на эффективность работы глобальной сети в целом, поскольку позволяет локализовать трафик и сократить загрузку магистральных каналов, предпочитая использовать кэшированные или расположенные локально реплики сетевых ресурсов. Не случайно Google реализует модель сохранения локальных кэшей на оборудовании крупных региональных провайдеров (Google Global Cache) и интеллектуальные алгоритмы в маршрутизации на ближайшую реплики. В этой статье мы обсудим различные подходы к реализации распределенной сети доставки контента (Content Delivery Network, он же CDN), а также акцентируем возможные решения для создания CDN в масштабах отдельно взятой страны или города.

Система доменных имён разрабатывалась как замена hosts файлам, и в то время, в ограниченной среде университетских сетей никто не думал о безопасности. Всё основывалось на доверии. Ещё буквально лет 8-10 назад никто не думал о том, что трафик между сервером DNS и клиентом можно записывать для продажи, либо заменять для достижения своих целей. Но уже в то время существовали трояны, добавляющие записи в локальный файл hosts, чтобы перенаправлять пользователей на подконтрольные серверы. В последние несколько лет появилось несколько новых протоколов, которые помогают устранить перехват или подмену трафика DNS. Но это только смещение точки доверия от одной группы провайдеров, к другой.

Но есть способ сделать создание и синхронизацию доменных имён и записей DNS очень простыми, да ещё и безопасными и не подверженными цензуре.

Примерно в середине сентября 2021 года на сети Мегафон заработала DNSSec валидация. Такой вывод можно сделать из изменений в графике на ресурсе stats.labs.apnic.net.

Одним недавним летним вечером коротал я время за выпуском сертификатов Let's Encrypt (LE) в кубере, и долго не мог понять с какого перепугу сработало ограничение на количество сертификатов в неделю, т.е. 50 штук.

Быстрая проверка на https://crt.sh/ показала, что действительно для совершенно разных поддоменов было выпущено много странных сертификатов, и это, мягко говоря, удивило.

С 29 октября 2021 года читатели российских библиотек не могут открыть газетную базу EastView с советскими газетами и журналами. Причиною стал Роскомнадзор. Запрет обошли, создав новый домен.

Привет, Хабр. Меня зовут Рустам. Я работаю в Ozon: админю Kubernetes и пишу на Go.

У нас очень много сервисов на Go — их количество исчисляется тысячами. Запускаются они внутри кластеров Kubernetes. А я плотно работаю с Kubernetes и заметил, что при запуске кода внутри Kubernetes для резолва одного адреса делается до десяти DNS-запросов. Это, конечно, влияет на производительность.

Я решил разобраться, как Go делает DNS-запросы. В результате мне удалось уменьшить их количество в наших проектах до одного-двух. Как у меня это получилось и можно ли использовать мой опыт в вашем проекте, я расскажу в статье.

В современном мире уже просто неприлично использовать HTTP, но не все веб приложения можно легко развернуть на HTTPS, некоторые вообще могут не поддерживать такую схему работы. Сегодня мы получим SSL сертификат бесплатно без регистрации и смс и настроим HTTPS на примере TeamCity.

Все запросы и ответы DNS идут по сети в открытом виде, поэтому в изначальной вариации шпионить за пользователем может не только администратор DNS-сервера, но и операторы всех промежуточных узлов, через которые проходит трафик. Современные решения вроде DNSCrypt, DNS over HTTPS и подобные им решают проблему перехвата информации по пути ее следования, так как шифруют DNS-запросы от пользователя до сервера. Но! Протоколы, которые шифруют трафик, не решают один важный вопрос - анализ всех запросов на стороне самого сервера, который всё еще видит как сам запрос, так и IP-адрес, с которого он пришел.

DNS over I2P, или DoI2P (или вовсе DoI) - это весьма занимательная вариация использования скрытых сетей, подробным рассмотрением которой сейчас и займемся.