🥷 Как работает 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 настраивался простым редактированием /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