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

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

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

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

С чего начать

Не пытайтесь применить всё сразу. Сначала настройте окружение так, чтобы команды было удобно повторять, а результаты — проверять. Для DNS в Linux это важнее, чем кажется: половина ускорения даёт предсказуемый рабочий процесс.

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"

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

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

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

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

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

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

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

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

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

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

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

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

Совет 6. Для диагностики используйте dig +trace, но помните о нагрузке.

Для диагностики используйте dig +trace, но помните о нагрузке.

Настройки, которые стоит сохранить

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

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

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

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

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

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

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

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

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

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

Практический сценарий

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

Дальше действуйте короткими шагами: установка, минимальная конфигурация, проверка, затем расширение. После каждого шага фиксируйте, что именно изменилось и как это проверить. Такой журнал экономит время, когда через месяц понадобится повторить настройку на другом сервере или объяснить её коллеге.

Порядок работ для этого сценария выглядит так:

  1. Посмотрите текущий статус
  2. Проверьте конкретный запрос
  3. Настройте DNS для интерфейса
  4. Проверьте /etc/resolv.conf
  5. Очистите кэш

Отдельно продумайте, что произойдёт при сбое. Для DNS в Linux важно заранее знать, где хранятся данные, как их скопировать и сколько времени займёт восстановление. Если ответа нет, не двигайтесь дальше: сначала закройте этот пробел, потом добавляйте новые возможности.

Что проверить перед вводом в работу

Перед тем как считать настройку завершённой, пройдитесь по короткому списку. Он не заменяет полноценный аудит, но отсекает большинство очевидных проблем.

Чек-лист

  • Версия DNS в Linux зафиксирована, а обновления не применяются вслепую.
  • Есть резервная копия конфигурации и данных, восстановление проверено.
  • Доступ ограничен нужными пользователями и сетями, лишние порты закрыты.
  • Логи и метрики собираются, понятно, куда смотреть при сбое.
  • Изменения описаны в документации и могут быть повторены на другой машине.
  • Есть план отката и понятный критерий, по которому вы решите его применить.

Если какой-то пункт вызывает затруднение, это сигнал вернуться к соответствующему разделу, а не откладывать проверку. Настройка, которую нельзя повторить, плохо работает не только у коллег, но и у вас самих через полгода.

Итог

Главная ценность приёмов выше — в экономии внимания. Выберите два-три, доведите до автоматизма, и DNS в Linux перестанет отнимать время на рутину.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте