Сетевик Джонни // Network Admin

🥷 Как работает DNS в Linux. Часть 3: кто на самом деле управляет resolv.conf? Когда-то давным-давно в далекой Галактике DNS настраивался простым редактированием /etc/resolv.conf: nameserver 8.8.8.8 nameserver 1.1.1.1 search example.com Сейчас же файл с содержанием nameserver 127.0.0.53 и предупреждением “DO NOT EDIT” может шокировать. Причина такого изменения в эволюции DNS-инфраструктуры: Раньше: приложения → resolv.conf → DNS-сервер Сейчас: приложения → локальный DNS-прокси → upstream серверы В современных дистрибутивах /etc/resolv.conf – это чаще всего не ручная настройка, а автоматически генерируемый конфиг, создаваемый и поддерживаемый системными компонентами: systemd-resolved, NetworkManager, resolvconf или их аналогами вроде openresolv. Эта автоматизация приносит гибкость (разные DNS для разных сетей, DNSSEC, LLMNR/mDNS), но с другой стороны и некоторые потенциальные проблемы: • Настройки могут слетать после перезагрузки сети или обновления пакетов. • Конфликты при подключении VPN, которые пытаются переписать DNS. • Сложности с использованием локальных доменов или специфичных DNS-серверов. • Затрудненная отладка: куда на самом деле идут запросы? Так кто же главный? systemd-resolved? NetworkManager? Как вернуть себе контроль? В следующем посте разберёмся в этом лабиринте: какие инструменты претендуют на управление /etc/resolv.conf, как они взаимодействуют и какие рычаги управления у нас есть, чтобы заставить DNS работать так, как нам нужно. Ставьте 👍 #DNS #Linux | 🙁 @iscode

🥷 Как работает DNS в Linux. Часть 3: разбираемся с resolv.conf, systemd-resolved, NetworkManager и другими Теоретическую основу кэширования DNS в Linux мы разбирали в первой части, где говорили про работу процесса разрешения имен — от вызова getaddrinfo() до получения IP-адреса. Вторая часть была посвящена различным уровням кэшей самой системы, приложений и языков программирования, контейнеров, прокси - а также их мониторингу и сбросу. Теперь самое время перейти к практике. Если вы когда-либо запускали подряд команды ping, curl, dig и получали разные IP-адреса, вы не одиноки. Поведение DNS в Linux — не просто вызов getaddrinfo(). Это взаимодействие множества слоёв: от glibc и NSS до NetworkManager, systemd-resolved, dnsmasq и облачных конфигураций. В этой части разберем практические аспекты DNS: • почему одинаковые запросы дают разные IP • как реально контролируется разрешение имен: что вызывает кого и зачем • как проводить диагностику: strace, resolvectl, tcpdump 🖥 Утилиты и их пути к DNS В Linux-системах преобразование доменных имён в IP-адреса — фундаментальный процесс, но не все утилиты делают это одинаково. Под капотом скрываются конкурирующие механизмы: классический стек glibc/NSS (с его правилами из /etc/nsswitch.conf, локальным файлом /etc/hosts и кеширующими сервисами, такими как systemd-resolved), прямые DNS-запросы (игнорирующие системные настройки) и альтернативные библиотеки (например, c-ares). Эти различия часто становятся источником неочевидных расхождений в работе инструментов, особенно при диагностике сетевых проблем. ‼️ Типичный пример — разница в выводе getent hosts и dig для одного домена: $ getent hosts google.com 142.250.179.206 google.com $ dig +short google.com 142.250.179.238 Здесь getent опирается на кеш systemd-resolved (через NSS), а dig обходит системные механизмы, запрашивая DNS-сервер напрямую. Практические советы: • Если ping и curl выдают разные IP, причина обычно в кеше NSS или настройках /etc/hosts. При работе с curl/wget учитывайте их зависимость от libc: расхождения могут указывать на проблемы в NSS (например, некорректный nsswitch.conf). • Для проверки системного разрешения (включая /etc/hosts) используйте getent, host или ping. • Для валидации работы DNS-сервера применяйте dig/nslookup — они не смотрят в локальные файлы. Итог: понимание внутренних механизмов разрешения имён критично при отладке сетевых проблем. Всегда сверяйтесь с таблицей выше, чтобы выбрать правильный инструмент: проверка локальных настроек требует NSS-зависимых утилит, а диагностика DNS — "прямых" запросов в обход системы. #DNS #Linux | 🙁 @iscode

🥷 Как работает DNS в Linux. Часть 2: мониторинг в среде Kubernetes Эффективная работа DNS критична для производительности кластера Kubernetes. CoreDNS, как стандартный резолвер, генерирует метрики, которые помогают выявлять: — эффективность кэширования (снижает ли нагрузку на upstream); — ошибки разрешения имен (например, всплески NXDOMAIN); — аномальные задержки (проблемы с сетью или перегрузку). Собирая эти данные через Prometheus, вы можете настроить алертинг и предотвратить сбои до их влияния на приложения. Примеры метрик: - Эффективность кэша: sum(rate(coredns_cache_hits_total{type="success"}[5m])) / sum(rate(coredns_cache_requests_total[5m])) - Отслеживание ошибок: rate(coredns_dns_responses_total{rcode="NXDOMAIN"}[5m]) - Задержки запросов: histogram_quantile(0.99, rate(coredns_dns_request_duration_seconds_bucket[5m])) Примеры алертов - Рост ошибок NXDOMAIN: rate(coredns_dns_responses_total{rcode="NXDOMAIN"}[5m]) > 10 - Деградация скорости ответа: histogram_quantile(0.99, rate(coredns_dns_request_duration_seconds_bucket[5m])) > 1 - Снижение эффективности: rate(coredns_cache_misses_total[15m]) / rate(coredns_cache_requests_total[15m]) > 0.5 Проактивные практики: — Автоматизируйте алерты на аномальный рост NXDOMAIN-ответов. — Контролируйте сроки жизни DNS-записей (TTL), чтобы избежать использования устаревших данных. — Визуализируйте hit/miss ratio для контроля эффективности кэширования.

🥷 Как работает DNS в Linux. Часть 2: как правильно управлять кэшем Немного практических советов по работе с кэшами. В разработке: 1. Использовать короткие TTL для тестовых доменов (60-120 секунд). Для негативных ответов (NXDOMAIN) устанавливайте ещё меньший TTL (5-30 сек) в конфигурации резолверов (например, cache_neg_ttl в dnsmasq), чтобы быстро тестировать исправления. 2. Знать, как сбросить кэш на каждом используемом уровне. 3. Тестировать изменения DNS в изолированной среде. В production: 1. Планировать изменения DNS: снижать TTL заранее. 2. Мониторить кэширование: логировать stale answers и NXDOMAIN. 3. Использовать централизованные резолверы с контролируемым кэшированием. 4. Настроить правильные TTL: - Для часто меняющихся сервисов: 60-300 секунд. - Для статичных данных: 3600+ секунд. Эффективное управление DNS в продакшене требует непрерывного контроля кэша. Ключевые метрики: hit rate (эффективность кэша), stale answers (устаревшие ответы), NXDOMAIN rate (ошибки резолвинга) и latency (задержка). #DNS #Linux #Cache | 🙁 @iscode

😢 Насколько утечки 🔼 бустят эффективность фишинга Речь пойдёт о целевых атаках, не буду говорить о массовых фишинговых письмах, на подобии наследства с Африки, ибо не эффективно, лидов нет. А вот когда у тебя на руках персональные данные сотрудников и правильно воспользовавшись можно превратить обычный спам в целевую атаку: ❗️ Допустим, в сеть утекли заказы из некоторого сервиса еды. Из них злоумышленник может узнать: · корпоративный адрес сотрудника, который заказывает еду в офис, его имя и фамилию; · когда происходит заказ — например, до обеда в пятницу; · что заказывают — пиццу, бургеры, вок и т. д.; · телефон того, кто встречает курьера; · сколько было заказов, какая регулярность После чего желательно в пятницу утром высылается письмо на адрес жерты:

Добрый день, Афанасий Валерьянович! Спасибо, что являетесь клиентом нашей пиццерии. Мы благодарны вам и дарим купон на скидку 20%. Работает только сегодня, автоматически применится при заказе по ссылке: <фишинговая ссылка> С уважением, пиццерия Мама Вонс.

Эффективность фишинга с применением персональных данных повышается в разы, в 51% случаев сотрудники открывают, и 40% из этого числа взаимодействует с сервисом, так что, будьте аккуратней и информируйте сотрудников. #Phishing #Dataleaks | 🙁 @iscode

Коллеги, продолжаем серию практикумов от Codeby Academy🔥 Встречаемся в понедельник и проводим настоящее OSINT-расследование с Катей Тьюринг. 🟧 Регистрация в боте: https://osint-workshop.codeby.school/ Что будет: 🟧 Реальное OSINT-расследование с экспертом 🟧 Поиск скрытых связей, бенефициаров бизнеса и теневых "решал" 🟧 Работа с открытыми источниками без шаблонов 🟧 Построение гипотез и их проверка в процессе 🟧 Верификация данных и аналитические решения Вы увидите работу опытного OSINT-аналитика в прямом эфире — с логикой, находкой, и решениями. Почему важно быть онлайн: можно задавать вопросы и по ходу увидеть процесс, понять как формируется аналитическое мышление. 🟧 2 февраля , 19:00 МСК 🟧 Онлайн, бесплатно 🟧 Регистрация: https://osint-workshop.codeby.school Вопросы по участию: @CodebyAcademyBot

💥 DDoS в 2025 году: более высокая интенсивность и огромные ботнеты Опубликовали наш годовой отчет «DDoS, боты и BGP-инциденты в 2025 году: статистика и тренды». Ключевые факты о DDoS-атаках: 🔹 Основные цели атак — «Финтех», «Электронная коммерция», «ИТ и Телеком», а также «Медиа». На эти четыре сегмента пришлось почти 75% всех DDoS-атак за год. 🔹 На уровне микросегментов чаще всего атаковали платежные системы, рестораны и доставку еды, медиа, банки и онлайн-образование — вместе они собрали около половины всех инцидентов. 🔹 В декабре зафиксировали самые интенсивные L3-L4 DDoS-атаки 2025 года: 3,06 и 3,51 Тбит/с в пике, примерно втрое выше рекорда 2024 года. Обе атаки были направлены на сегмент онлайн-букмекеров. 🔹 Растут не только максимумы, но и «масса»: медианная интенсивность UDP flood (преобладающий вектор) выросла на 🔺57%, то есть даже рядовые атаки стали ощутимо более разрушительными. 🔹 Самый крупный DDoS-ботнет — 5,76 млн IP-адресов. Про него подробно писали здесь. 🔹 Самая длительная атака продолжалась почти 5 суток, но в целом атаки стали короче: средняя длительность снизилась почти вдвое по сравнению с прошлым годом. 👉 Больше подробностей — в полной версии отчета на сайте CURATOR.