DNS *

Очень часто на этапе стажировки новых сотрудников мы в нашей компании сталкиваемся с типичными простыми ошибками, непониманием работы DNS и почты. При этом обучение новых сотрудников по этой теме — достаточно длительный и сложный процесс, так как сами вопросы требуют построения сложных логических цепочек в голове у начинающего инженера. В один момент мы составили свою вики и схемы для обучения и решили поделиться этим опытом на Хабре в виде серии статей, чтобы людям, которые решили связать свою жизнь с IT вообще и администрированием в частности, стало проще. Материалы этой серии предназначены для начинающих администраторов.

В этом материале будет представлена связка полноценного почтового сервера в виде Exim4+Dovecot+PostfixAdmin+RainLoop.

Написать данную статью меня побудили следующие обстоятельства:

Обновление ОС на своём роутере до OpenWrt 23.05, сломавшее мой предыдущий setup, где я делал роутинг по GeoIP.

Многочисленные вопросы знакомых и в дискуссиях в постах на Хабре.

Статья на Хабре, по которой я стал делать и понял, что так делать не надо.

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

В этой статье я хочу рассказать о своем опыте создания DNS сервера. Разрабатывал я его "чисто повеселиться", при разработке будем придерживаться спецификации RFC.

Надо было мне разобраться получше с 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 что бы не искать их потом.

Всем нам нравится писать в строке бровсера https://habr.com/. Никому не
захотелось бы писать там https://178.248.237.68/. К тому же, IP-адрес может
измениться, если Хабр решит перейти на другой хостинг.

Служба Интернета, которая превращает удобные всем имена в IP-адреса,
называется DNS, Domain Name System, "система доменных имен".

В этой статье я собираюсь описать работу DNS с разных аспектов, как с
технических, так и с организационно-административных.

Эта статья не является введением в DNS для начинающих. Скорее, моя
предполагаемая аудитория - это ИТ-профессионалы разной специализации,
которые хотят получше разобраться в анатомии сети Интернет.

Здесь я попытаюсь изложить сложные вещи простым языком, не погрязая в
излишних подробностях - моему читателю судить, насколько мне это
удалось.

Я много пишу о технологиях, которые показались мне сложными. Недавно моя подруга Сумана задала мне интересный вопрос – почему все эти вещи так сложно изучать? Почему они кажутся такими загадочными?

Для примера возьмём DNS. Мы пользуемся DNS с 80-х (больше 35 лет!). Он применяется на каждом веб-сайте Интернета. И он довольно стабилен – во многих смыслах он работает точно так же, как делал это тридцать лет назад.

Но мне понадобились ГОДЫ, чтобы понять, как с уверенностью отлаживать проблемы с DNS, и я видела множество программистов, тоже испытывавших трудности с отладкой проблем DNS. Что же происходит?

Я приведу пару своих рассуждений о том, почему устранять проблемы DNS трудно.

(В этом посте я не буду глубоко объяснять DNS, подробности о его работе см. в моём посте Implement DNS in a Weekend или в других моих постах о DNS.)

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

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

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

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

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

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

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

Первая Часть

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

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

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

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

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

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

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

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

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

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