DNS в Linux: как это работает под капотом

Коротко о главном

Проблемы с DNS выглядят как «интернет не работает», хотя сеть есть. В Linux за разрешение имён отвечают systemd-resolved, NetworkManager, dhcp-клиент и иногда локальный dnsmasq. Понимание цепочки помогает быстро найти причину.

Неправильный DNS ломает обновления, контейнеры и VPN-подключения. Умение читать resolvectl и проверять конфигурацию экономит часы диагностики.

DNS в Linux выглядит простым снаружи, но именно детали определяют поведение под нагрузкой. Посмотрим на внутреннее устройство и тонкие настройки.

Как это устроено

DNS в Linux состоит из нескольких взаимодействующих частей: конфигурации, рабочего процесса и данных, с которыми он работает. Понимание этой схемы помогает предсказывать поведение системы и быстрее находить причину сбоя.

Неправильный DNS ломает обновления, контейнеры и VPN-подключения. Умение читать resolvectl и проверять конфигурацию экономит часы диагностики. Именно поэтому настройка через переменные окружения и конфигурационные файлы предпочтительнее ручных правок «на месте».

Разбор конфигурации

Начните с минимального рабочего варианта. Не копируйте большой конфиг целиком: добавляйте параметры по одному и проверяйте результат после каждого изменения.

[Resolve]
DNS=1.1.1.1 9.9.9.9
FallbackDNS=8.8.8.8
DNSSEC=allow-downgrade

Ключевые компоненты и их взаимодействие

1. Посмотрите текущий статус

resolvectl показывает интерфейсы, DNS-серверы и статистику. Начните с него, а не с правки resolv.conf.

resolvectl status
resolvectl statistics

2. Проверьте конкретный запрос

Сравните ответ systemd-resolved и прямого запроса к серверу. Это покажет, виноват ли резолвер.

resolvectl query example.com
dig @1.1.1.1 example.com

3. Настройте DNS для интерфейса

В NetworkManager задайте DNS для подключения, чтобы настройки не терялись после перезагрузки.

nmcli connection modify "Wired connection 1" ipv4.dns "1.1.1.1 9.9.9.9"
nmcli connection up "Wired connection 1"

4. Проверьте /etc/resolv.conf

Это часто симлинк на stub-resolv.conf. Не редактируйте его вручную, если используете systemd-resolved.

ls -l /etc/resolv.conf
cat /etc/resolv.conf

5. Очистите кэш

После смены DNS сбросьте кэш и проверьте, что новые записи применяются.

sudo resolvectl flush-caches
resolvectl query example.com

Диагностика и тонкая настройка

Начинайте с журналов и проверки версии. Затем изолируйте проблему: конфигурация, права доступа, сеть или данные. Не меняйте несколько параметров одновременно — иначе невозможно понять, что именно помогло.

Практические советы

Эти рекомендации проверены на повседневных задачах. Начните с тех, которые закрывают вашу текущую боль, а не со всего списка сразу.

Совет 1. Не смешивайте dnsmasq и systemd-resolved на одном интерфейсе без поним

Не смешивайте dnsmasq и systemd-resolved на одном интерфейсе без понимания приоритетов.

Совет 2. Для локальных имён используйте отдельный домен и осознанную конфигурац

Для локальных имён используйте отдельный домен и осознанную конфигурацию.

Совет 3. Проверяйте DNSSEC: ошибки валидации выглядят как недоступность домена.

Проверяйте DNSSEC: ошибки валидации выглядят как недоступность домена.

Совет 4. В контейнерах DNS может отличаться от хоста.

В контейнерах DNS может отличаться от хоста.

Совет 5. Сохраняйте резервный DNS-сервер, но не полагайтесь только на него.

Сохраняйте резервный DNS-сервер, но не полагайтесь только на него.

Типичные ошибки

Ниже — сбои, которые встречаются чаще всего. Перед исправлением сохраните текущие конфиги и запишите, какие изменения вносите: так проще откатиться.

1. resolv.conf перезаписывается

Управляйте настройками через NetworkManager или systemd-resolved, а не правкой файла.

2. Домен не resolves, а IP пингуется

Проверьте DNS-серверы, search-домены и DNSSEC. Сравните ответы через dig.

3. После VPN ломается DNS

Проверьте приоритет интерфейсов и split DNS. Не отключайте системный резолвер вслепую.

Что улучшить после базовой настройки

Когда DNS в Linux работает предсказуемо, следующий шаг — наблюдаемость. Добавьте проверку состояния, которая отвечает на вопрос «жив ли сервис», и метрику, показывающую нагрузку. Без этого вы узнаёте о проблеме от пользователей, а не от системы.

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

Не оптимизируйте то, что не измеряли. Сначала соберите базовые показатели, затем меняйте один параметр и сравнивайте результат. Иначе легко получить конфигурацию, которая выглядит сложнее, но работает не быстрее.

Итог

Понимание внутреннего устройства DNS в Linux экономит часы диагностики. Когда знаете, где хранится состояние и как компоненты общаются, ошибка перестаёт быть «магией».