🥷 Как работает 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

⚡ Как данные передаются через Интернет? Какое это имеет отношение к модели OSI? Как TCP/IP вписывается в это?

🚠 Семь уровней модели OSI:

1. Физический уровень
2. Канальный уровень
3. Сетевой уровень
4. Транспортный уровень
5. Сеансовый уровень
6. Уровень представления
7. Прикладной уровень

#Network #OSI

🥸 Личный VPN: юзер ликует, VLESS смеётся, а РКН плачет. v.2

Представьте: ваш VPN становится невидимкой для РКН, маскируясь под обычный трафик от народного мессенджера Max. Никаких блокировок, никаких подозрений.

— В этой статье вы узнаете, как настроить такой «стелс» за 10 минут через удобный 3x-UI интерфейс с учётом последних потуг от регулятора (лазейка есть, и способ в разы дешевле чем Double VPN + gRPC + SelfSNI + бубны + домены с закосом под трафик от сайта и прочая х)

⤷ teletype.in/@secur_researcher/vpn_tutorial

#VPN #xHTTP #VLESS | 😈 @secur_researcher

🥷 Джонни вещает: 8 популярных сетевых протоколов с наглядным объяснением

Сетевые протоколы работают на разных уровнях модели OSI, это важно знать.

🌜 Эта многоуровневая архитектура обеспечивает стандартизированное взаимодействие между различными программными и аппаратными компонентами в сети.

1. 𝗧𝗖𝗣/𝗜𝗣 — базовый метод передачи информации между устройствами в Интернете. В то время как IP отвечает за адресацию и маршрутизацию пакетов данных, TCP заботится о сборке данных в пакеты, а также о надежной доставке.

2. 𝗛𝗧𝗧𝗣 — играет решающую роль при доступе к веб-сайтам. Он отвечает за получение и доставку веб-контента с серверов конечным пользователям.

3. 𝗛𝗧𝗧𝗣𝗦 — усовершенствованная версия HTTP, HTTPS объединяет протоколы безопасности (а именно TLS) для шифрования данных, обеспечивая безопасный и конфиденциальный обмен между браузерами и веб-сайтами.

4. 𝗙𝗧𝗣 — Как следует из названия, FTP используется для передачи файлов (загрузки и скачивания) между компьютерами в сети.

5. 𝗨𝗗𝗣 — более оптимизированный аналог TCP, UDP передает данные без накладных расходов на установление соединения, что приводит к более быстрой передаче, но без гарантии, что данные будут доставлены или будут в порядке.

6. 𝗦𝗠𝗧𝗣 — движущая сила обмена электронной почтой, которая управляет форматированием, маршрутизацией и доставкой писем между почтовыми серверами.

7. 𝗦𝗦𝗛 — криптографический сетевой протокол, который обеспечивает безопасную передачу данных по незащищенной сети.

- Он обеспечивает безопасный канал, гарантируя, что хакеры не смогут интерпретировать информацию путем подслушивания 📠

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

• 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

🥷 4 YouTube-канала для системного администратора

По просьбе одного из подписчиков, а точнее Alexander S выложить YT авторов по нашему направлению, что-ж, тема отличная, не знаю почему раньше этим не занялся, так как в любой связанной с айтишкой профессии, в системном администрировании специалисту требуется постоянное обучение, без которого нельзя развить необходимые навыки и наработать опыт.

1. Andrey Sozykin — на канале доступны видеолекции, подготовленные автором на основе этих курсов. Информация подается в краткой форме без затрудняющих восприятие деталей. Автор подробно разбирает следующие темы: компьютерные сети, защищенные сетевые протоколы, SQL, Python и нейросети.

2. Вера Дроздова — роликов немного, но они оформлены в виде лекций и хорошо продуманы.

🕹 Объясняются следующие темы: введение в компьютерные сети, сети ЭВМ и телекоммуникации, беспроводные технологии и компьютерные сети, сетевые технологии – все как в универе.

3. tutoriaLinux — автор профессиональный системный администратор, веб-разработчик, безопасник и архитектор датацентров с более чем десятилетним опытом. Обсуждаются следующие темы: получение первой работы, команды Linux, SRE, GIT, сети, VPN, оболочки и масса прочего. Также здесь можно найти интересные интервью.[EN]

4. ExtremeCode — и замыкающий автор в нашем списке это ExtremeCode, первые три автора это скучная техническая часть, а этот автор поможет скрасить вечера или послеобеденные будни в офисе)

админ вернулся с попойки, лайк посту поставьте братва и посты чаще начнут выходить 🌟

😢 Насколько утечки 🔼 бустят эффективность фишинга

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

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

После чего желательно в пятницу утром высылается письмо на адрес жерты:

Добрый день, Афанасий Валерьянович!

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

С уважением, пиццерия Мама Вонс.

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

#Phishing #Dataleaks | 🙁 @iscode

🥷 Как работает 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

🥷 Как работает 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. Часть 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. Часть 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

🔍 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

🥷 Как работает 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

Telegram в России ЗАБЛОКИРОВАН на ~80% — пишут СМИ.

В отдельных федеральных округах цифра близится к
90%.

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

👮‍♀️ Личный VPN: юзер ликует, VLESS смеётся, а РКН плачет. v.2 (цветет и пахнет, пинг минимальный 200-300ms)

🥷 4 YouTube-канала для системного администратора

По просьбе одного из подписчиков, а точнее Alexander S выложить YT авторов по нашему направлению, что-ж, тема отличная, не знаю почему раньше этим не занялся, так как в любой связанной с айтишкой профессии, в системном администрировании специалисту требуется постоянное обучение, без которого нельзя развить необходимые навыки и наработать опыт.

1. Andrey Sozykin — на канале доступны видеолекции, подготовленные автором на основе этих курсов. Информация подается в краткой форме без затрудняющих восприятие деталей. Автор подробно разбирает следующие темы: компьютерные сети, защищенные сетевые протоколы, SQL, Python и нейросети.

2. Вера Дроздова — роликов немного, но они оформлены в виде лекций и хорошо продуманы.

🕹 Объясняются следующие темы: введение в компьютерные сети, сети ЭВМ и телекоммуникации, беспроводные технологии и компьютерные сети, сетевые технологии – все как в универе.

3. tutoriaLinux — автор профессиональный системный администратор, веб-разработчик, безопасник и архитектор датацентров с более чем десятилетним опытом. Обсуждаются следующие темы: получение первой работы, команды Linux, SRE, GIT, сети, VPN, оболочки и масса прочего. Также здесь можно найти интересные интервью.[EN]

4. ExtremeCode — и замыкающий автор в нашем списке это ExtremeCode, первые три автора это скучная техническая часть, а этот автор поможет скрасить вечера или послеобеденные будни в офисе)

админ вернулся с работы, лайк посту поставьте братва и посты чаще начнут выходить 🌟