systemd-resolved начал ломать DNS в Ubuntu 24.04 — кто как решает?

[RedisNinja]

Столкнулся с классической болью: после обновления нескольких серверов на Ubuntu 24.04.2 начали появляться периодические проблемы с резолвингом DNS. Симптомы: команды типа curl или wget иногда зависают на 5-10 секунд перед тем как что-то сделать, host и dig работают нормально и быстро. Покопавшись, выяснил что dig обращается напрямую к серверу, а curl использует glibc resolver, который идёт через /etc/resolv.conf -> 127.0.0.53 -> systemd-resolved. Иногда resolved начинает кешировать NXDOMAIN агрессивнее чем нужно, или DNSSEC проверка виснет. Кто с этим сталкивался в последнее время?

[grpc_veteran]

Да, это известная боль с systemd-resolved и DNSSEC. Самое простое решение — отключить DNSSEC валидацию если она вам не нужна. В /etc/systemd/resolved.conf добавляешь DNSSEC=no и DNS=8.8.8.8 8.8.4.4, потом systemctl restart systemd-resolved. Проблема с зависаниями обычно именно в том, что resolved пытается получить DS-записи для валидации, а upstream-сервер отвечает медленно или некорректно. Это не лечит root cause, но на практике работает.

[cudauser]

@grpc_veteran, Я пошёл другим путём — полностью отказался от systemd-resolved в пользу unbound. Ставится просто: apt install unbound, потом настраиваешь /etc/unbound/unbound.conf на форвардинг к вашим DNS-серверам, останавливаешь resolved: systemctl disable --now systemd-resolved, убираешь симлинк rm /etc/resolv.conf и создаёшь нормальный файл с nameserver 127.0.0.1. Работает стабильно, есть нормальный кеш, и нет всей этой магии с resolved. Правда на десктопе это сложнее из-за NetworkManager.

[jpmore]

Не советую сразу убивать systemd-resolved — он решает реальные задачи, особенно на машинах которые подключаются к разным сетям. Для серверов ладно, но подумайте о последствиях. Более аккуратное решение: включить режим stub resolver без DNSSEC. В /etc/systemd/resolved.conf: DNSStubListener=yes, DNSSEC=no, MulticastDNS=no, Cache=yes. Потом проверить через resolvectl status что всё применилось. Если проблема именно в конкретном домене — resolvectl query domain.com покажет откуда берётся ответ и сколько времени занимает.

[esp32_dev]

Ещё один симптом той же проблемы: если у вас есть внутренние домены (например .local или корпоративный домен) и resolved не знает куда их резолвить — он будет делать timeout вместо быстрого NXDOMAIN. Решение: добавить DNS search domain и указать DNS-сервер явно через resolvectl dns eth0 192.168.1.1 и resolvectl domain eth0 your.internal.domain. Это заставит resolved правильно маршрутизировать запросы по доменам.

[tomtom11]

На серверах где мне важна предсказуемость, я давно перешёл на статический /etc/resolv.conf с блокировкой его перезаписи: chattr +i /etc/resolv.conf. Да, это топорно, но работает надёжно. Прописываю туда два DNS-сервера (обычно внутренний и 1.1.1.1 как fallback), и никакой systemd-resolved больше ничего не трогает. Конечно, это не подойдёт если машина часто меняет сети, но для продовых серверов с фиксированной конфигурацией — отличный вариант.