🥷 Как работает 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 году для упрощения современных сетевых задач. Взаимодействие с ним настолько “упрощает” работу с сетью, что очень многие системные администраторы отключают его сразу.
Поведение при обработке 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 и 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