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

🔠 Слили 4 ТБ по IT, хакингу и разработке. ⚪️ Все лучшие инструкции, гайды, книги и инструменты — без воды. 🖥 Курсы & GitHub — 579GB ☁️ Хакинг & ИБ — 756GB 🤒 OSINT — 315GB ⌨️ Python — 955GB 🙃 Linux & Bash — 459GB 😦 Работа в IT — 278GB 🖥 Общий архив — 946GB ➡️ Присоединяйтесь и скачивайте. Пост будет удален через 48 часов.

👩‍💻 Открытый урок «Сети ЦОД - SP vs. DC. Какой же подход к построению сетей оказался более распространен и почему?» 📌11 марта в 20:00 МСК Бесплатно. Урок в рамках старта курса «Дизайн сетей ЦОД» от Otus. Разберемся в плюсах и минусах использования технолгий MPLS и VxLAN в сетях ЦОД На открытом уроке рассмотрим: 💛 Выясним, почему появилась необходимость в новом протоколе для сетей ЦОД. 💛 Разберемся, чем именно отличаются технологии MPLS и VxLAN между собой. 💛 Поймем, в каких именно сценариях оправдано применение MPLS в сетях ЦОД. Вебинар будет полезен: Сетевым инженерам, сетевым архитекторам. Всем, кто глубоко интересуется современными сетевыми технологиями. В результате вебинара: Разберем основы примнения технолгий MPLS и VxLAN в сетях ЦОД. 🚀 Ссылка на регистрацию: https://otus.pw/GjQg/ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🥷 Как работает DNS в Linux. Часть 3: кто на самом деле управляет resolv.conf? Мы уже знаем, как dhclient и resolvconf пишут настройки DNS. Но что происходит, когда в игру вступают тяжеловесы вроде NetworkManager, systemd-resolved, отдельно стоящий unbound или корпоративный BIND? А если сверху это всё приправлено облачной инициализацией cloud-init и абстракцией netplan? Файл /etc/resolv.conf может вести себя непредсказуемо. 🔍 systemd-resolved — это локальный кэширующий dns-сервер (systemd-networkd), процесс systemd-resolved слушает 127.0.0.53:53, и nameserver в resolv.conf указывает на 127.0.0.53 соответственно. Файл /etc/resolv.conf обычно является symlink на /run/systemd/resolve/stub-resolv.conf В свою очередь /run/systemd/resolve/stub-resolv.conf — содержит 127.0.0.53, а прямой список upstream DNS можно найти в файле /run/systemd/resolve/resolv.conf. Диагностика: # Основная информация о состоянии resolvectl status # Статистика запросов resolvectl statistics # Информация по конкретному интерфейсу resolvectl status eth0 🖥 dnsmasq — это простой DHCP/DNS сервер, который работает зачастую как локальный кэш на 127.0.0.1:53. Обычно dnsmasq не пишет в resolv.conf самостоятельно, а читает upstream из resolv.conf, использует директиву --server= при запуске, или сервера прописаны в конфигурационном файле /etc/dnsmasq.conf. Диагностика: # Перезагрузка конфигурации sudo kill -USR1 $(pidof dnsmasq) # Проверка параметров запуска ps aux | grep dnsmasq 🕹 NetworkManager — это инструмент для автоматической настройки сети в большинстве современных десктопных и серверных дистрибутивах Linux. Был разработан компанией Red Hat в 2004 году для упрощения современных сетевых задач. Взаимодействие с ним настолько “упрощает” работу с сетью, что очень многие системные администраторы отключают его сразу.

— Обычно NetworkManager получает настройки от DHCP (через внутренний DHCP-плагин или внешний dhclient), принимая DNS-серверы из DHCP-ответа (опция option domain-name-servers), и передает их в системную службу управления DNS.

Поведение при обработке DHCP DNS можно контролировать через параметр ipv4.ignore-auto-dns: ipv4.ignore-auto-dns=no (по умолчанию) - NM использует DNS-серверы, полученные от DHCP ipv4.ignore-auto-dns=yes - игнорировать DNS от DHCP и использовать только статически заданные серверы Сам NetworkManager не обрабатывает DNS-запросы и не слушает порт 53, а в зависимости от настроек запускает dnsmasq (который слушает 127.0.0.1:53) или взаимодействует с systemd-resolved (обычно слушает 127.0.0.53:53). Что запускается - зависит от параметра dns в /etc/NetworkManager/NetworkManager.conf: dns=systemd-resolved — используется только systemd-resolved. dns=dnsmasq — запускается dnsmasq через NetworkManager. dns=none — NetworkManager не берет на себя функции управления резолвингом DNS dns=default — NetworkManager сам решает, что делать. При взаимодействии с systemd-resolved NetworkManager выступает в роли менеджера конфигурации, передавая параметры DNS через D-Bus API systemd-resolved, но не участвуя в обработке DNS-запросов напрямую. Тогда у нас будет наблюдаться следующая картина: resolvectl status # отображает текущие DNS-серверы, которые systemd-resolved получил от NetworkManager nmcli dev show | grep DNS # показывает DNS-серверы, которые NetworkManager передал в systemd-resolved

🔍 dhclient — стандартный DHCP-клиент в Linux-системах, входящий в пакет ISC DHCP. Его основная задача автоматически получать настройки сети (IP-адрес, сетевую маску, шлюз, DNS-сервера) у DHCP-сервера и применять их локально. По умолчанию DHCP-клиент (программа /sbin/dhclient) не изменяет /etc/resolv.conf напрямую. Вместо этого вызывается вспомогательный скрипт /sbin/dhclient-script, который получает параметры (в том числе DNS-серверы) от DHCP-сервера. — Внутри dhclient-script есть функция make_resolv_conf(), которая формирует содержимое файла /etc/resolv.conf и записывает новые настройки DNS. Кроме того используются так называемые хуки (скрипты), которые лежат в каталогах /etc/dhcp/dhclient-exit-hooks.d/ или /etc/dhcp/dhclient-enter-hooks.d/. Они позволяют изменить логику формирования или перезаписи /etc/resolv.conf, переопределяя функции или добавляя свои параметры. Диагностика: # Проверить конфигурацию DHCP-клиента cat /etc/dhcp/dhclient.conf # Запустить dhclient в debug-режиме dhclient -v -d <интерфейс> # выведет подробный лог, включая обработку DNS). # Проверить lease-файл DHCP** cat /var/lib/dhcp/dhclient.leases # там хранятся полученные параметры, включая DNS-серверы 🖥 resolvconf — это устаревший, но иногда встречающийся служебный инструмент для централизованного управления содержимым файла /etc/resolv.conf в UNIX-подобных системах. Он сохраняет и обновляет /etc/resolv.conf, собирая настройки DNS с различных источников: DHCP-клиентов, VPN-клиентов, сетевых интерфейсов, NetworkManager, позволяет нескольким программам и сервисам вносить свои DNS-серверы, динамически формируя итоговый конфиг для системы. — Работает как демон или в виде набора скриптов-хуков, которые вызываются при изменении сетевой конфигурации, принимает входящие DNS-настройки через программу или скриптовые вызовы, обновляет кэш и генерирует конечный /etc/resolv.conf. В resolvconf используются шаблоны для формирования итогового файла DNS: - /etc/resolvconf/resolv.conf.d/head — вставляется в начало результата. - /etc/resolvconf/resolv.conf.d/base — база доменов и серверов. - /etc/resolvconf/resolv.conf.d/tail — добавляется в конец. resolvconf может использоваться другими службами (например, NetworkManager, dhclient, openvpn) для централизованного обновления DNS-конфига.

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

Диагностика: # Вывод актуальной информации resolvconf -l # Обновить /etc/resolv.conf resolvconf -u В следующем посте продолжим навигацию по этому лабиринту: разберёмся, как systemd-resolved, dnsmasq, NetworkManager, unbound, BIND, cloud-init и netplan управляют /etc/resolv.conf, в каких случаях они конфликтуют, а когда — работают сообща, и какие рычаги у нас остаются над DNS. Ставьте 👍 #DNS #Linux | 🙁 @iscode

Новые рекорды ирбиса PT NGFW 🐆❄️Наш ирбис — прирожденный спринтер-чемпион. Но чтобы сохранить титул быстрой кошки, нужно постоянно бить свои же рекорды. Новый вызов поступил от ЦОД: покорить высоты производительности и обработать сотни миллионов микроскопических 📈 В гонку вступил новый чемпион — модель 3050. В зачете «пропускная способность с включенным IPS» он установил новый рекорд 🥇🚀 Мы приглашаем вас за кулисы рекорда — на вебинар 5 марта в 11:00. Это будет не скучная презентация, а технический разбор победы 🔧🎥 Программа: 🏁 Конструкция чемпиона: как спроектирована платформа, чтобы сохранять устойчивость на «марафонских дистанциях» (elephant flows) и не сбивать дыхание на «скоростном спринте» (UDP 64b). 🏁Гонка за эффективностью: 100 Гбит/с — экстремальная нагрузка. Покажем «боевую машину» 3050 и расскажем, зачем нам понадобился 3D-принтер. 🏁Новая дисциплина: remote access VPN. 🏁Обновление экипировки: возможности релизов 1.10 и 1.11 — инструменты для будущих побед. 👉Зарегистрироваться

🥷 Как работает 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 (задержка).

Не двигайтесь: вы в ИИ-кадре Этот бот создает фото для соцсетей в футуристичном стиле. Его можно поставить на аватарку, особенно если идете на t-sync conf. Конференция от «Т-Технологий» для опытных инженеров впервые пройдет в Москве 7 февраля. Попробовать бота можно здесь. А узнать больше о t-sync conf и зарегистрироваться — здесь

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

Добрый день, Афанасий Валерьянович! Спасибо, что являетесь клиентом нашей пиццерии. Мы благодарны вам и дарим купон на скидку 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.

🥷 4 YouTube-канала для системного администратора По просьбе одного из подписчиков, а точнее Alexander S выложить YT авторов по нашему направлению, что-ж, тема отличная, не знаю почему раньше этим не занялся, так как в любой связанной с айтишкой профессии, в системном администрировании специалисту требуется постоянное обучение, без которого нельзя развить необходимые навыки и наработать опыт. 1. Andrey Sozykin — на канале доступны видеолекции, подготовленные автором на основе этих курсов. Информация подается в краткой форме без затрудняющих восприятие деталей. Автор подробно разбирает следующие темы: компьютерные сети, защищенные сетевые протоколы, SQL, Python и нейросети. 2. Вера Дроздова — роликов немного, но они оформлены в виде лекций и хорошо продуманы. Объясняются следующие темы: введение в компьютерные сети, сети ЭВМ и телекоммуникации, беспроводные технологии и компьютерные сети, сетевые технологии – все как в универе. 3. tutoriaLinux — автор профессиональный системный администратор, веб-разработчик, безопасник и архитектор датацентров с более чем десятилетним опытом. Обсуждаются следующие темы: получение первой работы, команды Linux, SRE, GIT, сети, VPN, оболочки и масса прочего. Также здесь можно найти интересные интервью.[EN] 4. ExtremeCode — и замыкающий автор в нашем списке это ExtremeCode, первые три автора это скучная техническая часть, а этот автор поможет скрасить вечера или послеобеденные будни в офисе) админ вернулся с попойки, лайк посту поставьте братва и посты чаще начнут выходить 🌟

🥷 4 YouTube-канала для системного администратора По просьбе одного из подписчиков, а точнее Alexander S выложить YT авторов по нашему направлению, что-ж, тема отличная, не знаю почему раньше этим не занялся, так как в любой связанной с айтишкой профессии, в системном администрировании специалисту требуется постоянное обучение, без которого нельзя развить необходимые навыки и наработать опыт. 1. Andrey Sozykin — на канале доступны видеолекции, подготовленные автором на основе этих курсов. Информация подается в краткой форме без затрудняющих восприятие деталей. Автор подробно разбирает следующие темы: компьютерные сети, защищенные сетевые протоколы, SQL, Python и нейросети. 2. Вера Дроздова — роликов немного, но они оформлены в виде лекций и хорошо продуманы. Объясняются следующие темы: введение в компьютерные сети, сети ЭВМ и телекоммуникации, беспроводные технологии и компьютерные сети, сетевые технологии – все как в универе. 3. tutoriaLinux — автор профессиональный системный администратор, веб-разработчик, безопасник и архитектор датацентров с более чем десятилетним опытом. Обсуждаются следующие темы: получение первой работы, команды Linux, SRE, GIT, сети, VPN, оболочки и масса прочего. Также здесь можно найти интересные интервью.[EN] 4. ExtremeCode — и замыкающий автор в нашем списке это ExtremeCode, первые три автора это скучная техническая часть, а этот автор поможет скрасить вечера или послеобеденные будни в офисе)

2026 станет годом гибридных атак: цифровые взломы → физический ущерб Бизнес входит в 2026 год с новым типом угроз: атака начинается в почте → заканчивается пустым складом. Кибергруппировки уже координируют действия с физическими преступниками: письмо → взлом → подмена документов → отключение камер → перехват груза. Такие атаки не ловятся антивирусом. Их ловят выстроенные процессы, обучение и зрелость информационной безопасности компании. Если хочешь войти в 2026 осознанно, а не вслепую — здесь ты узнаешь, что действительно происходит в мире угроз: Мир Цифры | Туманов 👉 Подписывайтесь, чтобы быть на шаг впереди Реклама. О рекламодателе.

От отключения хостером до полной стабильности Как CURATOR защитил 3DNews и ServerNews от DDoS и ускорил доставку контента Атака почти 3000 Мбит/с — и хостер 3DNews «падает» меньше чем за полчаса, просто отключив сеть. Для медиа это катастрофа: простой, потеря трафика и удар по репутации. Команда CURATOR подключилась в самый критичный момент и быстро вернула сайт к жизни. Подробнее о том, как это было сделано - в карточках. Этот и другие реальные кейсы, а также экспертная информация в области кибербезопасности — в канале CURATOR.

• aiohttp по умолчанию работает через getaddrinfo(), но может быть настроен на использование aiodns (асинхронный DNS через libcares), где возможно встроенное кэширование. • dnspython — отдельный DNS-клиент, выполняющий DNS-запросы напрямую. С версии 2.0 поддерживает явное включение кэша: import dns.resolver resolver = dns.resolver.Resolver() resolver.cache = dns.resolver.Cache() Таким образом, поведение зависит от конкретной библиотеки. Стандартный socket и большинство оберток над ним, включая requests, кэширование не реализуют и полагаются на системный резолвер. ✋ В следующей части расскажу про контейнеры и оркестрацию, ставьте 👍 #DNS #Linux | 😏 @iscode

🥷 Как работает DNS в Linux. Часть 2: уровень приложений и языков программирования glibc Хотя официально считается, что glibc не реализует полноценный DNS-кэш (в отличие от демонов вроде systemd-resolved, dnsmasq или nscd), в её реализации резолвера есть несколько механизмов, которые действуют как очень простое и ограниченное кэширование или оптимизация запросов. — Во-первых, используется NSS (Name Service Switch), который может быть сконфигурирован для работы с nscd, systemd-resolved или другими кэширующими компонентами. Например, с помощью следующей директивы в файле nsswitch.conf: hosts: files resolved myhostname Где вместо resolved также может быть и nscd. Хотя nscd — отдельный демон, он поставляется вместе с glibc в большинстве дистрибутивов и тесно интегрирован с ней. Когда nscd запущен и настроен (часто включен по умолчанию для passwd, group, hosts), библиотеки glibc (getaddrinfo, gethostbyname) будут обращаться к нему первыми. Nscd кэширует ответы до истечения их TTL. Кэширование в этом случае происходит вне самой библиотеки glibc, но glibc использует этот кэш прозрачно для приложения. 🔍 В реализации DNS-резолвера внутри glibc (в файле resolv/res_query.c и др.) содержатся оптимизации, такие как повторное использование сокета и игнорирование TTL при повторных запросах внутри одного вызова, которые можно рассматривать в качестве некого микро-кэша в контексте одного вызова функции разрешения. Эти оптимизации не сохраняют результаты между разными вызовами getaddrinfo или между разными процессами и действуют только в рамках одного системного вызова функции. — Модули NSS (особенно files) кэшируют данные из статических файлов. Например, nss-files (работающий в том числе с /etc/hosts) по сути "кэширует" содержимое этих файлов в памяти процесса после их первого чтения (до перезагрузки процесса или вызова, инвалидирующего кэш NSS). Это не DNS-кэширование в чистом виде, но влияет на процесс разрешения имен, в котором участвует DNS. Java Java поддерживает встроенный DNS-кэш с гибкими настройками времени жизни записей. Особенности работы Без использования Security Manager (начиная с Java 11 - это поведение по умолчанию): - положительные ответы кэшируются на 30 секунд (максимум, даже если DNS-сервер указал больший TTL); - отрицательные ответы (NXDOMAIN) — 10 секунд. С использованием Security Manager: - положительные ответы кэшируются бесконечно (риск устаревших записей); - отрицательные ответы не кэшируются. Управление Настройки указываются в свойствах JVM. TTL в секундах для успешных запросов: networkaddress.cache.ttl=60 TTL для неудачных запросов (NXDOMAIN): networkaddress.cache.negative.ttl=10 Варианты значений: 0 — отключить кэширование; -1 — кэшировать бессрочно (только для положительных ответов). Способы настройки 1. Аргументы JVM: java -Dnetworkaddress.cache.ttl=60 -jar app.jar 2. В коде (глобально для JVM): Security.setProperty("networkaddress.cache.ttl", "60"); Go Go использует две модели резолвинга: - через cgo — вызывает системный getaddrinfo() (включая NSS). Работает через системные настройки (/etc/nsswitch.conf, /etc/resolv.conf); - Pure Go resolver — реализует собственный DNS клиент, минуя системные библиотеки. Выбор резолвера: GODEBUG=netdns=go # встроенный резолвер с кэшем GODEBUG=netdns=cgo # через системный getaddrinfo() При использовании Pure Go резолвера Go реализует in-memory DNS-кэш внутри процесса. Этот кэш хранит успешные (A, AAAA, CNAME) и отрицательные (NXDOMAIN) ответы, соблюдая их TTL. Кэш имеет фиксированный размер (реализует эвристику LRU), хранится в памяти процесса и разделяется между горутинами внутри этого процесса, но не разделяется между разными процессами или экземплярами приложений. Python По умолчанию модуль socket и большинство стандартных библиотек (включая requests, urllib3) используют системный вызов getaddrinfo() и не имеют встроенного кэша DNS. • requests → использует urllib3, который делегирует разрешение DNS системной библиотеке (socket.getaddrinfo()), без кэширования.