systemd-resolved: split-DNS и DNS-over-TLS (DoT) на практике

systemd-resolved — локальный резолвер в современных Linux-дистрибутивах (Ubuntu/Debian, Fedora, Arch и др.). Он получает DNS-настройки от сетевого стека (NetworkManager или systemd-networkd), кеширует ответы, поддерживает split DNS и умеет шифровать запросы к upstream через DNS-over-TLS (DoT).

На серверах это особенно полезно: вместо «ручного редактирования» /etc/resolv.conf при каждом изменении сети вы получаете предсказуемую схему — приложения всегда обращаются к локальному resolved, а он уже выбирает правильный DNS по домену/интерфейсу.

Ниже — практический разбор: как устроен stub resolver, как правильно читать /etc/resolv.conf в мире systemd, как делать split DNS для VPN/внутренних доменов, как включить DoT и как проверить, что не происходит DNS leak.

Как устроен systemd-resolved и почему вокруг него столько путаницы

Классическая модель DNS в Linux долгое время сводилась к файлу /etc/resolv.conf, который читали приложения через glibc. Проблема в том, что сеть стала динамической: Wi‑Fi, VPN, несколько интерфейсов, корпоративные зоны и разные DNS «на входе».

systemd-resolved решает это так:

• слушает локальный адрес 127.0.0.53 (и ::1), выступая как stub-резолвер для приложений;
• получает upstream DNS и доменные маршруты от NetworkManager или systemd-networkd;
• маршрутизирует запросы по доменам/интерфейсам (split DNS);
• по желанию шифрует запросы к upstream через DoT.

Stub resolver и «режимы» /etc/resolv.conf

Ключевой момент: /etc/resolv.conf часто является не «конфигом», а симлинком на файл, который генерирует systemd.

• /run/systemd/resolve/stub-resolv.conf — режим stub (внутри будет nameserver 127.0.0.53).
• /run/systemd/resolve/resolv.conf — «полный» список upstream DNS без 127.0.0.53.

Для split DNS почти всегда нужен именно stub: тогда все приложения ходят в resolved и не обходят его правила. Если вы вручную фиксируете /etc/resolv.conf на публичные nameserver, вы часто ломаете split DNS и иногда — DoT.

Быстрая проверка:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf

Диагностика:

systemctl status systemd-resolved
resolvectl status

Базовая диагностика: что резолвится и через какой DNS

Перед настройкой полезно научиться быстро отвечать на три вопроса: какие DNS назначены системе, по какому интерфейсу идет конкретный запрос, и какие доменные маршруты реально применились.

resolvectl: базовый инструмент администратора

Вместо гаданий по /etc/resolv.conf используйте resolvectl:

resolvectl status
resolvectl dns
resolvectl domain

Проверка резолюции через systemd-resolved (важно: это не то же самое, что проверять отдельный DNS через dig):

resolvectl query example.com
resolvectl query internal.service.corp

Чтобы увидеть выбор интерфейса/upstream в логах, на короткое время включайте debug:

sudo resolvectl log-level debug
sudo journalctl -u systemd-resolved -f

Вернуть уровень обратно:

sudo resolvectl log-level info

Признаки «не того» /etc/resolv.conf

Частые симптомы, что приложения обходят resolved:

• split DNS «как будто не работает»: внутренние имена не резолвятся при активном VPN;
• в resolvectl status DNS-серверы и домены видны, но приложения резолвят иначе;
• после перезагрузки DNS «откатывается»;
• NetworkManager или VPN-клиент постоянно переписывают /etc/resolv.conf.

Первая проверка — куда указывает /etc/resolv.conf и кто именно им управляет.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Если вы настраиваете VPN, split DNS и свои резолверы на сервере, удобнее делать это на отдельной VDS: конфигурации не конфликтуют с «соседями», а сетевой стек и политики маршрутизации полностью под вашим контролем.

Split DNS: что это и зачем нужно на сервере

Split DNS — это маршрутизация DNS-запросов: одни домены (или запросы, пришедшие с разных интерфейсов) резолвятся через разные DNS-серверы. Классический кейс: интернет — через публичные DNS, а зоны .corp/.internal — только через DNS внутри VPN.

Почему это важно:

• снижает риск DNS leak (внутренние запросы не уходят наружу);
• ускоряет резолюцию внутренних имен (нет таймаутов на публичных резолверах);
• убирает конфликт «корпоративный DNS ломает внешний интернет» и наоборот.

Split DNS — это не «две строки nameserver в /etc/resolv.conf». Это именно выбор upstream по домену/интерфейсу, который и выполняет systemd-resolved.

Split DNS в терминах systemd-resolved

systemd-resolved оперирует понятиями:

• Link (интерфейс): eth0, ens3, wg0, tun0;
• DNS на Link: upstream DNS, назначенные этому интерфейсу;
• Domains на Link: доменные маршруты. Важное — ~domain (routing domain), это не search suffix.

Посмотреть по интерфейсам:

resolvectl status eth0
resolvectl status wg0

Split DNS через systemd-networkd: пример для VPN-интерфейса

Если сеть на сервере управляется systemd-networkd, split DNS обычно задают в .network-файлах.

Пример: внешний интерфейс eth0 получает DNS по DHCP, а VPN-интерфейс wg0 использует корпоративный DNS только для зон corp и internal.

Внешний интерфейс:

[Match]
Name=eth0

[Network]
DHCP=yes

VPN-интерфейс (пример принципа; сам WireGuard настраивается отдельно):

[Match]
Name=wg0

[Network]
DNS=10.10.0.53
Domains=~corp ~internal

Ключевой момент — Domains=~corp ~internal. Тильда означает: запросы к этим зонам маршрутизировать на DNS этого интерфейса. Если указать домены без тильды, вы получите search domains, что часто не нужно и иногда ломает резолюцию.

Применение:

sudo systemctl restart systemd-networkd
sudo systemctl restart systemd-resolved
resolvectl status

Split DNS через NetworkManager: что проверить и где ломается

На многих системах сетью управляет NetworkManager. Он умеет отдавать настройки в systemd-resolved на уровне соединений, но проблемы часто появляются из-за VPN-плагинов и ручных правок /etc/resolv.conf.

Проверить, что NetworkManager реально работает в связке с resolved

Задача: убедиться, что приложения используют stub, а NM не ведет отдельный «свой» resolv.conf.

Проверка NM:

nmcli general status
nmcli dev show

Детали конкретного соединения:

nmcli con show
nmcli con show "Wired connection 1"

И сверяем с:

resolvectl status

Типовой кейс: VPN должен давать DNS только для внутренних доменов

Ожидаемая модель: VPN поднимает интерфейс, задает корпоративный DNS и routing domains (например, ~corp), а внешний DNS остается для остального.

Если VPN «перехватывает всё» и прописывает глобальный DNS, то split DNS не получится: resolved будет считать корпоративный DNS основным маршрутом. Диагностика всегда одинаковая:

• какие DNS назначены VPN-интерфейсу в resolvectl status;
• какие домены назначены VPN-интерфейсу, и есть ли тильда;
• есть ли глобальный DNS, который перетягивает маршрут.

DNS-over-TLS (DoT) в systemd-resolved: включение и нюансы

DNS-over-TLS (DoT) шифрует DNS-трафик между хостом и upstream DNS-сервером. Это защищает от пассивного наблюдения на участке сети (например, у провайдера) и усложняет подмену на этом участке. При этом DoT не делает «анонимности»: upstream DNS всё равно видит ваши запросы, просто канал до него шифруется.

Включение DoT

Основная настройка — в /etc/systemd/resolved.conf или drop-in в /etc/systemd/resolved.conf.d/.

Минимальный пример:

[Resolve]
DNSOverTLS=yes

Дальше важное: если upstream DNS не поддерживает TLS на 853 порту или этот порт блокируется, резолюция начнет «подвисать» или сыпать ошибками.

Перезапуск и проверка:

sudo systemctl restart systemd-resolved
resolvectl status

DoT и проверка сервера: что реально важно

Для DoT важно понимать, как именно клиент убеждается, что подключился к «тому самому» DNS-серверу. В systemd-resolved поведение зависит от версии systemd и от того, как заданы DNS (IP или имя, дополнительные параметры). Если DoT включен без строгой валидации, вы получаете шифрование канала, но не всегда получаете строгую гарантию подлинности upstream.

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

• если цель — приватность от локальной сети/провайдера, DoT уже полезен;
• если нужна строгая защита от подмены upstream, проверяйте логи systemd-resolved и осознанно выбирайте способ задания DNS для DoT.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Если вы публикуете собственные DoT/DoH-эндпоинты или внутренние сервисы с TLS, заранее продумайте сертификаты и срок их обновления. Для публичных имен проще использовать нормальные SSL-сертификаты, чтобы не завязаться на самоподписанные решения и ручные исключения.

DoT и split DNS одновременно

DoT отвечает за «как шифровать канал к upstream», split DNS — за «какой upstream выбрать для домена/интерфейса». Эти функции не конфликтуют, но в продакшене согласуйте ожидания:

• для публичных доменов — DoT к публичному резолверу (если он поддерживает);
• для корпоративных доменов — часто DoT внутри VPN не используют (и это нормально), либо поднимают внутренний DoT-резолвер.

/etc/resolv.conf: что должно быть на хосте, где нужен split DNS

Чтобы split DNS работал стабильно, resolved должен быть единой точкой входа для приложений.

В идеале /etc/resolv.conf указывает на stub-конфиг. Концептуально содержимое выглядит так:

nameserver 127.0.0.53
options edns0 trust-ad
search .

Проверяйте фактический путь через readlink -f. Если у вас «настоящий» файл с публичными nameserver, приложения будут идти напрямую, и resolved уже не сможет применить маршрутизацию по доменам.

DNS leak: как понять, что запросы утекают не туда

В админской практике под DNS leak обычно понимают две ситуации:

• внутренние домены (например, db01.corp) уходят на публичный DNS;
• при активном VPN публичные домены продолжают резолвиться через внешний DNS, хотя по политике должны идти через VPN (чаще на рабочих станциях, реже на серверах).

Проверка на практике

Проверяем резолюцию через resolved:

resolvectl query db01.corp
resolvectl query example.com

Смотрим, какие DNS и домены назначены интерфейсам:

resolvectl status

И включаем debug на короткое время, чтобы увидеть выбор сервера:

sudo resolvectl log-level debug
sudo journalctl -u systemd-resolved -f

Если запрос к .corp уходит на DNS внешнего интерфейса — значит routing domain не настроен или не применяется (например, VPN не передал ~corp, либо /etc/resolv.conf обходит stub).

Частые грабли и быстрые решения

1) DNS «сломался» после установки VPN-клиента

VPN-клиенты любят менять /etc/resolv.conf или запускать собственные резолверы. В итоге systemd-resolved остается в системе, но приложения ходят не через него.

Что делать: проверить симлинк /etc/resolv.conf, выяснить, кто его изменяет, вернуть модель stub. Затем настроить VPN так, чтобы он передавал DNS и домены в resolved, а не переписывал resolv.conf.

2) Внутренние домены резолвятся, но с задержкой

Часто это означает: запрос сначала идет на внешний DNS (таймаут), потом на внутренний. Для split DNS это почти всегда признак отсутствия routing domains с тильдой или неправильного приоритета.

Что делать: убедиться, что внутренние зоны добавлены как ~corp, а не как corp; проверить, что DNS указан именно на нужном Link.

3) DoT включили, а DNS стал «подвисать»

Если upstream DNS не поддерживает DoT или блокируется порт 853, резолюция деградирует.

Что делать: проверить логи systemd-resolved; временно отключить DoT для подтверждения; выбрать upstream, который поддерживает TLS, или включать DoT только там, где это оправдано.

4) systemd-networkd и NetworkManager одновременно

На сервере лучше иметь один управляющий компонент. Смешивание приводит к «прыгающим» DNS-настройкам.

Что делать: определить, кто управляет интерфейсами, и привести к одному варианту. Проверка — какие службы активны и какие интерфейсы они держат.

Мини-чеклист: split DNS + DoT без сюрпризов

1. Убедитесь, что приложения используют resolved: /etc/resolv.conf указывает на stub.

2. Через resolvectl status проверьте, что у каждого интерфейса корректные DNS и домены.

3. Для split DNS задавайте routing domains с тильдой: ~corp, ~internal.

4. DoT включайте осознанно: проверьте поддержку upstream и отсутствие блокировок порта 853.

5. Для расследований используйте debug-логи resolved короткими сессиями.

Итоги

systemd-resolved — это точка согласования DNS в системе: он позволяет делать split DNS корректно (по доменам и интерфейсам) и включать DoT там, где это дает пользу. Как только вы перестаете считать /etc/resolv.conf главным источником истины и начинаете опираться на resolvectl, диагностика становится проще: видно, кто выдал DNS, какой интерфейс выбран и почему конкретное имя резолвится именно так.

Если вы параллельно наводите порядок в доменной инфраструктуре (зоны, перенос, обновление NS), пригодятся материалы про перенос домена с EPP-кодом и настройку DNS и про периоды продления домена и восстановление после удаления.