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