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

🥷 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()), без кэширования.

🥷 Джонни вещает: 8 популярных сетевых протоколов с наглядным объяснением Сетевые протоколы работают на разных уровнях модели OSI, это важно знать. 🌜 Эта многоуровневая архитектура обеспечивает стандартизированное взаимодействие между различными программными и аппаратными компонентами в сети. 1. 𝗧𝗖𝗣/𝗜𝗣 — базовый метод передачи информации между устройствами в Интернете. В то время как IP отвечает за адресацию и маршрутизацию пакетов данных, TCP заботится о сборке данных в пакеты, а также о надежной доставке. 2. 𝗛𝗧𝗧𝗣 — играет решающую роль при доступе к веб-сайтам. Он отвечает за получение и доставку веб-контента с серверов конечным пользователям. 3. 𝗛𝗧𝗧𝗣𝗦 — усовершенствованная версия HTTP, HTTPS объединяет протоколы безопасности (а именно TLS) для шифрования данных, обеспечивая безопасный и конфиденциальный обмен между браузерами и веб-сайтами. 4. 𝗙𝗧𝗣 — Как следует из названия, FTP используется для передачи файлов (загрузки и скачивания) между компьютерами в сети. 5. 𝗨𝗗𝗣 — более оптимизированный аналог TCP, UDP передает данные без накладных расходов на установление соединения, что приводит к более быстрой передаче, но без гарантии, что данные будут доставлены или будут в порядке. 6. 𝗦𝗠𝗧𝗣 — движущая сила обмена электронной почтой, которая управляет форматированием, маршрутизацией и доставкой писем между почтовыми серверами. 7. 𝗦𝗦𝗛 — криптографический сетевой протокол, который обеспечивает безопасную передачу данных по незащищенной сети. - Он обеспечивает безопасный канал, гарантируя, что хакеры не смогут интерпретировать информацию путем подслушивания 📠 #Protocol #cheatsheet | 😊 @iscode

🥸 Личный VPN: юзер ликует, VLESS смеётся, а РКН плачет. v.2 Представьте: ваш VPN становится невидимкой для РКН, маскируясь под обычный трафик от народного мессенджера Max. Никаких блокировок, никаких подозрений. — В этой статье вы узнаете, как настроить такой «стелс» за 10 минут через удобный 3x-UI интерфейс с учётом последних потуг от регулятора (лазейка есть, и способ в разы дешевле чем Double VPN + gRPC + SelfSNI + бубны + домены с закосом под трафик от сайта и прочая х) ⤷ teletype.in/@secur_researcher/vpn_tutorial #VPN #xHTTP #VLESS | 😈 @secur_researcher

⚡ Как данные передаются через Интернет? Какое это имеет отношение к модели OSI? Как TCP/IP вписывается в это? 🚠 Семь уровней модели OSI: 1. Физический уровень 2. Канальный уровень 3. Сетевой уровень 4. Транспортный уровень 5. Сеансовый уровень 6. Уровень представления 7. Прикладной уровень #Network #OSI

🥷 Как работает DNS в Linux. Часть 2: где именно кэшируется DNS в Linux Ядро Ядро Linux может опосредованно “кэшировать” DNS-трафик через подсистему netfilter/conntrack, если используется stateful-фильтрация. Несмотря на то, что UDP — протокол без установления соединения, ядро отслеживает состояние пакетов, относящихся к одному блоку запрос-ответ (например, запрос от [src_ip:src_port] к [8.8.8.8:53] и ожидаемый ответ от [8.8.8.8:53] к [src_ip:src_port]) и временно хранит информацию — по умолчанию около 30 секунд. Это необходимо для NAT и правил вроде iptables -m conntrack --ctstate ESTABLISHED,RELATED. Проверить текущие записи можно командой: conntrack -L -p udp --dport 53 В списке отобразятся активные DNS-сессии, которые считаются допустимыми до истечения таймаута. Повторные DNS-запросы к тем же адресам в пределах срока жизни этих записей могут быть обработаны в рамках существующей записи состояния. Это не полноценное кэширование DNS-ответов, но conntrack может влиять на поведение сетевого уровня, особенно при диагностике проблем с NAT или firewall. Для удаления записей из таблицы отслеживания соединений можно воспользоваться командой: conntrack -D -p udp --dport 53 Системный уровень 1. systemd-resolved Современные дистрибутивы с systemd часто используют systemd-resolved в качестве основного DNS-клиента, который: - имеет собственный кэш DNS-запросов, включая положительные и (опционально) отрицательные ответы; - поддерживает split DNS (разные DNS-серверы для разных доменов), конфигурируется через systemd-networkd или NetworkManager; - поддерживает DNS-over-TLS (DoT), включая fallback-серверы и DNSSEC; - предоставляет API по D-Bus (org.freedesktop.resolve1), позволяет получать статус, менять настройки и управлять кэшем через resolvectl. 2. nscd (Name Service Cache Daemon) Если запущен nscd, он кэширует результаты NSS-вызовов, включая DNS. Его настройки находятся в /etc/nscd.conf enable-cache hosts yes positive-time-to-live hosts 600 negative-time-to-live hosts 20 ‼️ Важный момент: nscd устарел и не рекомендуется к использованию в новых системах. В Debian-based дистрибутивах чаще всего его заменяет systemd-resolved, но в RHEL-based дистрибутивах он ещё встречается. 3. Популярные локальные кэширующие резолверы dnsmasq — популярный выбор для локального кэширования(настройка кэша): cache-size=1000 (cache-size управляет размером кэша. По умолчанию он небольшой (150), и для заметного эффекта его увеличивают до 1000–5000) neg-ttl=60 unbound — более мощный DNS-рекурсор. Управление кэшем гибкое: Размер кэша задаётся параметром msg-cache-size (отвечает за ответы) и rrset-cache-size (за записи ресурсов): msg-cache-size: 50m rrset-cache-size: 100m TTL кэшированных ответов можно ограничить директивами cache-min-ttl и cache-max-ttl cache-min-ttl: 30 # минимальный TTL для любых ответов cache-max-ttl: 86400 # максимальный TTL (24 часа) bind - распространенный DNS-сервер с поддержкой рекурсивного разрешения и кэширования. Управление кэшем и его мониторинг осуществляется через команду rndc (Remote Name Daemon Control). В конфигурационном файле named.conf можно задавать TTL для кэша и контролировать поведение: options { max-cache-ttl 86400; // максимальное время жизни кэша (в секундах) max-ncache-ttl 3600; // максимальное время жизни негативных ответов (NXDOMAIN) }; ✋ В следующей части расскажу про уровни приложений и языков программирования, ставьте 👍 #DNS #Linux | 😏 @iscode

👀 Наглядно показываем принцип работы и область применения восьми самых популярных сетевых протоколов

⚙️ Публикации краткого формата: 1. Насколько утечки 🔼 бустят эффективность фишинга 2. Удаляем файлы с Linux правильно 3. 10 полезных команд в Linux для сетей LAN и WI-FI 4. NAT в сетях 5. Пишем более читаемый текст в терминале Linux 6. Реверс сокс-прокси 7. Утечка DNS 8. Шпаргалка по OpenSSL 9. Основы DNS: работа DNS-request'a 10. Основы DNS: иерархия 11. Записи DNS и их типы 12. 12 заблуждений сетевого администратора 13. Настройка Git сервера с нуля 14. Десятка лучших консольных команд 15. DNS-хостинг для начинающих, многообразие ресурсных записей (ч.1) 16. DNS-хостинг для начинающих, многообразие ресурсных записей (ч.2) 17. DNS-хостинг для начинающих, многообразие ресурсных записей (ч.3) 18. DNS-хостинг для начинающих, многообразие ресурсных записей (ч.4) 19. 10 опасных команд Linux, которые вы никогда не должны запускать 20. Функционал SSH: проброс портов 21. Откуда этот конфиг? [Debian/Ubuntu] 22. Функционал SSH: ключ сервера SSH 23. Функционал SSH: вложенные туннели 24. Функционал SSH: динамический проброс портов 25. Функционал SSH: управление ключами SSH 26. HTTP: Uniform Resource Locator — или просто URL 27. Протокол HTTP: принцип работы и методы 28. Протокол HTTP: коды состояния ответов и ошибки 29. Распространенные ошибки веб-сервера Nginx (1 ч.) 30. Консольная утилита для визуализации результата любых shell команд 31. Как провести стресс-тестирование вашей системы Linux 32. Распространенные ошибки веб-сервера Nginx (2 часть) 33. Функционал SSH: проброс X-сервера 34. Функционал SSH: проброс stdin/out 35. Функционал SSH: туннелирование 36. Руководство по настройке и использованию rsync 37. Тонкая настройка SSH для безопасности серверов 38. Функционал SSH: алиасы в SSH 39. А ваша система мониторинга орёт, когда меняется маршрутизация? (ч.1) 40. А ваша система мониторинга орёт, когда меняется маршрутизация? (ч.2) 41. А ваша система мониторинга орёт, когда меняется маршрутизация? (ч.3) 42. По следам одного взлома: когда 'a' не равно 'а' (ч.1) 43. По следам одного взлома: когда 'a' не равно 'а' (ч.2) 44. По следам одного взлома: когда 'a' не равно 'а' (ч.3) 45. Проблема ботов и идея защиты, или о том как я использую zip-бомбы для защиты своего сервера 46. Проблема ботов и идея защиты, или о том как я использую zip-бомбы для защиты своего сервера(ч.2) 47. Дыра в щите Cloudflare: как атака на Jabber.ru вскрыла проблему, о которой молчат c 2023 (ч.1) 48. Технический ликбез: CAA, RFC 8657 и как это должно нас спасать 49. Слон в посудной лавке: при чём тут Cloudflare? 50. Как работает DNS в Linux. Часть 1: от getaddrinfo до resolv.conf 51. Как работает DNS в Linux. Часть 1: NSS 52. Как работает DNS в Linux. Часть 1: Библиотеки 53. Как работает DNS в Linux. Часть 1: обработка resolv.conf и что делает res_query() 54. Как работает DNS в Linux. Часть 1: порядок реализации запросов и приоритеты 55. Как работает DNS в Linux. Часть 1: порядок реализации запросов и приоритеты (ч.2) 56. Как работает DNS в Linux. Часть 1: краткое резюме и ключевые моменты 57. Как работает DNS в Linux. Часть 2: все уровни DNS-кэширования 🖥 Подборки обучающих материалов: 1. Подборка обучающих материалов по компьютерных сетях 2. Cisco Systems — подборка обучающих материалов 3. Сетевое администрирование: подборка бесплатных курсов 4. Большая подборка вопросов с собеседований: Системного администратора Linux/Devops 5. Репозиторий 101 Linux Commands eBook 🔍 Доклады и видеоматериалы: 1. Мониторинг и Kubernetes 2. Автомасштабирование и управление ресурсами в Kubernetes 3. Деление IP сети на подсети при помощи маски легко и быстро 4. portknocking на mikrotik 5. Mikrotik на VPS 6. Установка и настройка Sysmon 7. Изменение Windows 10 из Proffesional в Enterprise 2021 LTSC 8. Расследование одного взлома: SSH туннель

🔹🔹🔹🔹🔹🔹🔹🔹🔹 Оказался(ась) на этом канале впервые и потерялся? — можешь звать меня Джонни, я буду твоим проводником. Этот Telegram-канал — солянка для сетевых инженеров и сисадминов. Здесь мы не ищем тайны, а чиним сети, настраиваем серверы и пишем скрипты, чтобы работалось лучше. Мы соберём пазл из BGP, OSPF, Ansible и Kubernetes, чтобы ты видел картину целиком, а не только красные дашборды. 🕹 Хочешь, чтобы твои сети аптаймились, а скрипты работали с первого раза? Тогда проваливайся глубже в канал и начинай читать. Добро пожаловать! 🔍 Протоколы сетевого управления и стандарты: 1. OSPF — протокол динамической маршрутизации 2. NDP — протокол управления сетевыми узлами IPv6 3. BGP — протокол маршрутизации 4. RIP — протокол маршрутизации 5. FTP — протокол передачи файлов 6. SONET — стандарт передачи данных по оптоволоконным сетям 7. RDP — протокол удаленного рабочего стола 8. RPC — протокол удаленного вызова процедур 9. SMB — протокол общего доступа к файлам 10. SIP — протокол инициации сеанса 11. QUIC — протокол универсальной управляемой передачи 12. NTP — протокол сетевой синхронизации времени 13. LLDP — протокол обнаружения топологии сети 14. SNMP — инструмент для управления сетями 15. DNS — система преобразования доменных имен 🔍 Статьи и методики по использованию: 1. Примеры атак XSS и способов их ослабления 2. Что такое триада КЦД: шпаргалка для начинающих специалистов в сфере кибербезопасности 3. Микросервисная архитектура на примере Python и gRPC 4. Компьютерные сети от А до Я: стек протоколов TCP/IP 5. Основы методологии DevOps 6. «Я тебя по IP вычислю»: как хакеры рассекречивают звенья цепи Tor 7. TCPDump — инструмент для анализа сетевого трафика 8. Wireshark — Анализ сетевого трафика 9. VMWare: создание виртуальных машин 10. Утилиты на PowerShell для системных администраторов 11. Как я искал нормальный RDP-клиент и нашел целых три 12. DNSSEC — набор расширений для обеспечения безопасности DNS 13. Будни техпода. Ошибки при подключении по RDP 14. Будни техпода. Как разместить Telegram-бота на виртуальном сервере 15. Будни техпода. Подготовка сервера с Linux для работы по RDP 16. Будни техпода. Разворачиваем сайт из конструктора на VDS за 130 рублей 17. Будни техпода. Как перенести данные с одного виртуального хостинга на другой 18. Как я сделал самый быстрый в мире файловый сервер 19. HDD, SSD или NVMe: что выбрать для виртуального сервера 20. Nmap — инструмент для сканирования хостов 21. Две скрытые кайфовые фичи Windows Admin Center: как найти, настроить и использовать 22. Устройство TCP: Реализация SYN-flood атаки 23. Tcpdump на разных уровнях: анализ и перехват трафика 24. Тачку на прокачку: тюнинг Wireshark 25. Настройка Git сервера с нуля 26. 10 типичных ошибок при использовании k8s 27. Внутреннее устройство Kubernetes-кластера простым языком 28. Сказ о том, как два сервера изменили судьбу сетевой команды

🔹🔹🔹🔹🔹🔹🔹🔹🔹 Оказался(ась) на этом канале впервые и не знаешь с чего начать? — можешь звать меня Джонни, я буду твоим проводником Этот Telegram-канал — солянка для сетевых инженеров и сисадминов. Здесь мы не ищем тайны, а чиним сети, настраиваем серверы и пишем скрипты, чтобы работалось лучше. Мы соберём пазл из BGP, OSPF, Ansible и Kubernetes, чтобы ты видел картину целиком, а не только красные дашборды. 🕹 Хочешь, чтобы твои сети аптаймились, а скрипты работали с первого раза? Тогда проваливайся глубже в канал и начинай читать. Добро пожаловать! Статьи и методики по использованию: 1. Примеры атак XSS и способов их ослабления 2. Что такое триада КЦД: шпаргалка для начинающих специалистов в сфере кибербезопасности 3. Микросервисная архитектура на примере Python и gRPC 4. Компьютерные сети от А до Я: стек протоколов TCP/IP 5. Основы методологии DevOps 6. «Я тебя по IP вычислю»: как хакеры рассекречивают звенья цепи Tor 7. TCPDump — инструмент для анализа сетевого трафика 8. OSPF — протокол динамической маршрутизации 9. NDP — протокол управления сетевыми узлами IPv6 10. BGP — протокол маршрутизации 11. RIP — протокол маршрутизации 12. DNSSEC — набор расширений для обеспечения безопасности DNS 13. SONET — стандарт передачи данных по оптоволоконным сетям 14. FTP — протокол передачи файлов 15. RDP — протокол удаленного рабочего стола 16. RPC — протокол удаленного вызова процедур Публикации краткого формата: Подборки обучающих материалов: 1. Подборка обучающих материалов по компьютерных сетях 2. Cisco Systems — подборка обучающих материалов 3. 4. 5. 6. 7. 8.

🥷 Как работает DNS в Linux. Часть 2: все уровни DNS-кэширования В первых частях мы разобрали, как в Linux работает процесс разрешения имен — от вызова getaddrinfo() до получения IP-адреса. Однако если бы каждый вызов требовал нового DNS-запроса, это было бы неэффективно и сильно нагружало как систему, так и сеть. Поэтому используется кэширование. Кэширование DNS может быть везде — в glibc, в systemd-resolved, в браузерах и даже в приложениях на Go. Кэш помогает увеличить скорость работы, но создает дополнительные сложности при отладке. Например: вы меняете DNS-запись, но сервер продолжает ходить по старому IP-адресу. Или, Dig показывает правильный адрес, а curl всё равно подключается к устаревшему. 🌟 В этой серии постов разберем различные уровни кэшей самой системы, приложений и языков программирования, контейнеров, прокси. А также их мониторинг и сброс. 1. Что такое DNS-кэш и зачем он нужен: DNS-кэш — это не единое хранилище, а многоуровневая система механизмов кэширования на разных уровнях системы. Каждый DNS-запрос — это долгий сетевой вызов, поэтому многие компоненты стараются сохранять результаты локально. TTL (Time To Live) — время жизни записи в кэше. Оно указывается в DNS-ответе и определяет, как долго можно использовать сохранённый IP-адрес. Задается обычно в секундах. После истечения TTL необходимо обновить данные. 🕹 Таким образом, кэширование позволяет: - повысить скорость обработки повторных DNS запросов - снизить нагрузку на серверную и сетевую инфраструктуру - обеспечить отказоустойчивость при временной потере соединения - уменьшить задержки в работе приложений — Но у кэширования есть и обратная сторона: устаревшие данные могут стать причиной недоступности сервисов при изменении инфраструктуры. ✋ В следующей части дополним картину темой в каких уровнях работы кэшируются DNS в Linux, ставьте 👍 #DNS #Linux | 😏 @iscode

🥷 Как работает DNS в Linux. Часть 1: краткое резюме и ключевые моменты DNS-запрос в Linux — это не обязательно запрос к DNS-серверу. Цепочка обращений может включать hosts, NSS, glibc и другие источники. NSS и nsswitch.conf определяют порядок и источники разрешения имён. glibc использует NSS и может кэшировать результаты; musl реализует DNS-резолвинг напрямую с ограниченной поддержкой опций resolv.conf. Resolv.conf управляет настройками резолвера, но может быть изменен динамически. Getaddrinfo() — основной интерфейс для разрешения имен, обрабатывает как DNS, так и другие источники. В разных языках программирования (Go, Java, Python с dns.resolver, Node.js) могут использоваться собственные механизмы DNS-запросов. ✋ В следующей части дополним картину общим представлением того, как устроено кэширование DNS записей — ключевой механизм, который напрямую влияет на производительность, надежность и поведение приложений при смене IP-адресов, ставьте 👍 #DNS #Linux | 😏 @iscode

114 - размер дополнительных данных, например CNAME, или авторитетные серверы в случае рекурсивного запроса. 5. TCP-соединение по IP connect(5, ..., sin_addr=inet_addr("130.193.50.59")) Здесь уже сам curl устанавливает TCP-соединение по IP-адресу, который ему вернула getaddrinfo(). ‼️ Таким образом, когда мы вызываем curl, мы не видим DNS-запросов напрямую — их делает библиотека glibc внутри вызова getaddrinfo(). Но strace позволяет увидеть косвенные признаки:

Среди вызовов будет попытка подключиться к nscd, вызов connect() к DNS-серверу, отправка UDP-пакета через sendmmsg(), а затем — стандартное TCP-соединение по IP:

connect(7, {AF_INET, 172.24.31.107:53}) = 0 sendmmsg(7, [{ "download.astralinux.ru" }]) = 2 recvfrom(7, ...) = ... connect(5, {130.193.50.59:80}) = 0 Важно отметить, что поведение getaddrinfo() может зависеть от реализации libc. Например, в glibc результаты могут кэшироваться, что влияет на производительность и актуальность данных. #DNS #Linux | 😏 @iscode

🥷 Как работает DNS в Linux. Часть 1: порядок реализации запросов и приоритеты Важно: если имя найдено на одном из шагов, например, в hosts, последующие источники не используются. В минималистичных системах, таких как Alpine Linux с musl, порядок может отличаться, так как musl не использует NSS и реализует DNS-запросы напрямую, читая /etc/hosts и resolv.conf самостоятельно. Некоторые приложения и языки (например, Go, Java, Node.js) могут использовать собственные DNS-резолверы, полностью игнорируя системные настройки. Для примера проанализируем работу утилиты curl. Команда: strace -f -e trace=network curl -s download.astralinux.ru > /dev/null Вывод strace: socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3 socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0 socketpair(AF_UNIX, SOCK_STREAM, 0, [5, 6]) = 0 strace: Process 283163 attached [pid 283163] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 7 [pid 283163] connect(7, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (Нет такого файла или каталога) [pid 283163] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 7 [pid 283163] connect(7, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (Нет такого файла или каталога) [pid 283163] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 7 [pid 283163] connect(7, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.24.31.107")}, 16) = 0 [pid 283163] sendmmsg(7, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\250\207\1\0\0\1\0\0\0\0\0\0\10download\nastralinux"..., iov_len=40}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=40}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\240\215\1\0\0\1\0\0\0\0\0\0\10download\nastralinux"..., iov_len=40}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=40}], 2, MSG_NOSIGNAL) = 2 [pid 283163] recvfrom(7, "\250\207\201\200\0\1\0\1\0\0\0\0\10download\nastralinux"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.24.31.107")}, [28->16]) = 56 [pid 283163] recvfrom(7, "\240\215\201\200\0\1\0\0\0\1\0\0\10download\nastralinux"..., 65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.24.31.107")}, [28->16]) = 114 [pid 283163] sendto(6, "\1", 1, MSG_NOSIGNAL, NULL, 0) = 1 [pid 283163] +++ exited with 0 +++ socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 5 setsockopt(5, SOL_TCP, TCP_NODELAY, [1], 4) = 0 setsockopt(5, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0 setsockopt(5, SOL_TCP, TCP_KEEPIDLE, [60], 4) = 0 setsockopt(5, SOL_TCP, TCP_KEEPINTVL, [60], 4) = 0 connect(5, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("130.193.50.59")}, 16) = -1 EINPROGRESS (Операция выполняется в данный момент) getsockopt(5, SOL_SOCKET, SO_ERROR, [0], [4]) = 0 getpeername(5, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("130.193.50.59")}, [128->16]) = 0 getsockname(5, {sa_family=AF_INET, sin_port=htons(48488), sin_addr=inet_addr("172.24.31.241")}, [128->16]) = 0 sendto(5, "GET / HTTP/1.1\r\nHost: download.a"..., 86, MSG_NOSIGNAL, NULL, 0) = 86 recvfrom(5, "HTTP/1.1 200 OK\r\nServer: nginx/1"..., 102400, 0, NULL, NULL) = 1617 🔍 Что мы видим в этом strace? 1. Попытка использовать NSCD (Name Service Cache Daemon) connect(..., "/var/run/nscd/socket", ...) = -1 ENOENT - Это означает, что glibc сначала пытается использовать кеш имён из NSCD, если он запущен. В системе его нет, и запрос идёт дальше. 2. Вызов socket() и connect() к DNS-серверу socket(AF_INET, SOCK_DGRAM|..., IPPROTO_IP) = 7 connect(7, ..., sin_addr=inet_addr("172.24.31.107")...) - Здесь создаётся UDP-сокет для обращения к DNS-серверу, указанному в /etc/resolv.conf. 3. Вызов sendmmsg() — отправка DNS-запросов sendmmsg(7, [ { "download.astralinux.ru" }, { "download.astralinux.ru" } ], ...) Здесь отправляются запросы на резолв имени. 4. Ответ от DNS recvfrom(...) = 56 recvfrom(...) = 114 Теперь IP-адрес известен. 56 - это размер DNS-ответа в байтах, содержащего А-запись (IPv4-адрес)