DNS *

В предыдущей статье мы начали рассматривать использование анализатора пакетов Wireshark для работы с DNS. В этой мы продолжим рассмотрение данной темы и поговорим о рекурсии DNS. Здесь принцип обмена пакетами будет немного сложнее, потому что помимо обмена DNS пакетами между клиентом и сервером будет также обмен с авторитетным DNS сервером.

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

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

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

О том, как поставить и начать работу в Wireshark, написано множество различных публикаций. Такие базовые вещи, как применение параметров перехвата и работа с фильтрами рассматриваются в различных публикациях. Поэтому в данной статье я не буду подробно рассматривать базовые вещи, вместо этого предлагаю поработать с помощью Wireshark с протоколами прикладного уровня, в частности с DNS. В этой статье мы поговорим о простых DNS запросах, а в следующей рассмотрим более сложные случаи. Но, для начала вспомним немного теории.

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

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

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

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

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

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

В начале сентября мы перенесли облако NGcloud на новый домен. Перед миграцией проанализировали домен с помощью инструментов OSINT. Зачем? Потому что из сведений о домене хакеры могут добыть массу информации: начиная от данных владельца и заканчивая внутренними документами компании. В этой статье собрали все шаги и бесплатные OSINT-инструменты, которые помогут определить: какая информация о вашей компании есть в открытом доступе, как ее могут использовать злоумышленники и что можете сделать вы, чтобы предотвратить потенциальную атаку. 

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

Все естественно помнят, что существуют базовые проверки почты:

SPF "Sender Policy Framework" (фреймворк политики отправителя) - это метод проверки электронной почты, который позволяет проверять, действительно ли отправитель имеет право отправлять электронные письма от имени определенного домена.

DKIM "DomainKeys Identified Mail" (идентификация почты с помощью домена) - это метод проверки электронной почты, который используется для подтверждения подлинности сообщений, отправленных с определенного домена.

DMARC "Domain-based Message Authentication, Reporting and Conformance" (доменная аутентификация сообщений, отчетность и соответствие) - это метод проверки электронной почты, который позволяет проверять, соответствуют ли SPF и DKIM домену отправителя, и определяет, что делать с сообщениями, которые не соответствуют этим проверкам.

Всем привет, дамы и господа. Ну-с начнем.

Предисловие

В одной из обслуживаемых организаций N возникла непонятная ситуация, а именно: на границе стоит некоторая модель Mikrotik с прошивкой 7.7, и вот этот самый Mikrotik самостоятельно генерирует исходящий трафик до 8.1Мбит\с, при этом из локальной сети ничего не выходит.

использование интернета Starlink и протокола WireGuard позволяет обойти цензуру и ограничения доступа к информации, что особенно важно для жителей стран с жесткими режимами. Как отмечает Илон Маск: "Я считаю, что любой, кто желает свободу, должен иметь возможность получить ее" . Для нас важно поддерживать свободу интернета и обеспечивать безопасность передачи данных, поэтому мы решили использовать интернет Starlink и протокол WireGuard для создания VPN сети

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

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

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

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

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

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

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

Первая Часть

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