Настройка DNS-резолвера: где ломается разрешение имён
Разрешение имён на сервере — это цепочка: приложение, локальный распознаватель, вышестоящие серверы и корневая зона. Ломается обычно не сама цепочка, а её стыки: пустой кэш после перезапуска, единственный вышестоящий адрес в конфигурации и предсказуемо непредсказуемый первый запрос.
При перезапуске службы разрешения имён локальный кэш обнуляется, и первый запрос после перезапуска идёт по полному пути — рекурсивный обход, проверка подписей, а при усечённом ответе ещё и повтор по другому транспорту. На старте приложения таких запросов десятки, они выстраиваются в очередь, и отклик сервиса в первые секунды заметно проседает. Постоянный кэш с прогревом при старте убирает эффект: имена отдаются из локальной базы, пока вышестоящие только опрашиваются.
Вторая точка отказа — привязка к одному вышестоящему адресу: он уходит в таймаут или отвечает медленно, и ждёт всё приложение, а не только служебная служба. Третья — файл конфигурации разрешения имён перезаписывается менеджером сети при следующем поднятии интерфейса, а встроенный распознаватель занимает локальный адрес и конфликтует с собственными зонами и разделяемыми каталогами.
Выбор между встроенным механизмом и отдельным сервисом — systemd-resolved или Unbound — это выбор между «работает из коробки» и «управляемо настраивается»: отдельный сервис даёт отрицательное кэширование, несколько вышестоящих с проверкой доступности, разделение зон по доменам и статистику запросов. Как закрывается каждая из этих точек отказа при настройке DNS-резолвера — ниже.
Локальный кэш, отказоустойчивость и приватность запросов
Локальный кэш имен меняет профиль нагрузки сервиса целиком. Вместо сетевого обращения на каждый вызов приложение получает ответ из памяти резолвера, и повторные разрешения одних и тех же имён перестают зависеть от внешней сети. Время отклика приложения на типичном профиле определяется обработкой, а не ожиданием разрешения, и держится на одном уровне даже при перегрузке внешних серверов. Отрицательный кэш работает так же: имя, которого нет, не переспрашивается на каждый вызов.
Отказоустойчивость строится на резервных серверах разрешения, а не на надежде, что провайдер не упадёт. В конфигурации прописывают несколько внешних адресов с приоритетом и таймаутом: недоступность одного переводит запрос на следующий, а не роняет разрешение целиком. Устойчивость к недоступности провайдера даёт и сам кэш — уже известные имена продолжают отвечать, пока внешний канал лежит, и сервис не теряет связность с теми, с кем уже обменивался трафиком.
Приватность — следствие того же кэша. Наружу уходит только доля запросов, остальные гасятся локально, поэтому внешний наблюдатель видит не полную картину обращений сервиса, а её фрагмент. Транспорт до внешних серверов закрывают шифрованием, чтобы запросы не читались по пути.
Что именно ставить — вопрос сценария. Unbound как полноценный рекурсивный резолвер даёт контроль над зонами, лимитами и размером кэша, но требует собственной эксплуатации; systemd-resolved ближе к роли локальной заглушки, дешевле в поддержке и штатно ложится на большинство серверов. Оба варианта закрывают кэш, резервные серверы и уход трафика наружу — разница в том, кому вы отдаёте управление разрешением.
Варианты организации разрешения имён: сравнение режимов
Разрешение имён на сервере почти никогда не сводится к «поставить резолвер и забыть»: значение имеет то, кто владеет конфигурацией узла и как поведёт себя разрешение, когда вышестоящий сервер перестанет отвечать. Встроенная служба разрешения живёт рядом с сетевой подсистемой и управляется теми же средствами, а отдельный кэширующий сервер — самостоятельный процесс со своим конфигом, кэшем и правилами пересылки.
На практике выбирают между тремя схемами, и разница проявляется не в скорости одного ответа, а в том, как схему сопровождают, наблюдаем и отлаживают. Ниже — реальные альтернативы, между которыми чаще всего стоит выбор.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Встроенная служба разрешения | Одиночный узел или небольшой контур, где сетью уже управляет системный менеджер | Кэш и статистика ограничены, тонкой политики по зонам нет, поведение зависит от сборки дистрибутива |
| Отдельный кэширующий сервер | Несколько узлов, нужен общий кэш и своя локальная зона для внутренних имён | Требует собственного конфига, мониторинга и обновления — это ещё один сервис, за которым следят |
| Комбинированная схема с перенаправлением запросов | Внутренние зоны обслуживаются локально, внешние уходят на доверенные вышестоящие резолверы | Путь запроса проходит два звена, сложнее отладка и разграничение зон |
Ключевой критерий — не «какой вариант современнее», а сколько у вас узлов, нужна ли локальная зона для внутренних имён и насколько легко вы найдёте причину, когда конкретное имя не разрешается. Опишите ваш контур — вернёмся с оценкой и планом перехода.
Этапы внедрения: от аудита текущих настроек до передачи
Порядок работ выстраиваем так, чтобы смена резолвера не превращалась в аварию: сначала фиксируем текущую картину, потом меняем. Каждый этап заканчивается артефактом — конфигом, схемой или отчётом проверки, поэтому решение остаётся воспроизводимым.
- Аудит настроек сервера. Собираем, кто и как разрешает имена: интерфейсы и их состояние, статические записи, условные перенаправления для внутренних зон, переопределения, какие службы обращаются к локальному обработчику напрямую. Отдельно смотрим хосты, где прописан сторонний адрес — обычно именно они дают расхождения после переключения.
- Проектирование схемы. Сравниваем systemd-resolved и Unbound под задачу: нужна ли валидация подписей, свои зоны, разделение внутренних и внешних имён, отдельный кэш для сервисов. Фиксируем, где будет точка отказа и как она переживает недоступность вышестоящего сервера.
- Стенд. Разворачиваем конфигурацию в изоляции и сверяем ответы с текущей схемой по критичным именам: те же адреса, те же сроки жизни записи, предсказуемое поведение при недоступности источника.
- План отката. Исходные файлы и параметры запуска сохраняем до правок, порядок возврата описываем построчно. Переключаем по одному узлу, а не весь парк сразу — при отклонении возврат занимает минуты.
- Переключение. Меняем системные обработчики имён, перезапускаем службу и следим за долей отказов и временем ответа. Рост обращений к внешним серверам — первый признак, что кэш не прогрелся.
- Проверка после переключения. Контрольные запросы по внутренним и внешним зонам, поведение кэша, реакция на перезапуск службы и на разрыв связи с вышестоящим сервером. Результаты фиксируем в отчёте.
- Передача. Конфиги уходят в репозиторий, к ним — схема, политика обновления зон и короткая инструкция для дежурного: что смотреть и что откатывать.
Опишите текущую схему разрешения имён — вернёмся с оценкой и планом работ.
Конфигурации, схемы зон и регламенты: что остаётся у вас
Резолвер перестаёт быть чёрным ящиком, когда вся его конфигурация лежит в репозитории и описана словами. Мы передаём не набор «магических» файлов, а рабочую систему: по ней ваш инженер поднимет такой же узел с нуля, повторит конфигурацию на стенде и откатит изменение, не разбираясь в чужих заметках.
- Файлы настроек — основная конфигурация и дополнительные файлы переопределения в системе контроля версий, с историей правок и осмысленным описанием каждого изменения.
- Схема зон и перенаправлений — какие домены резолвятся локально, какие уходят на вышестоящие резолверы, где стоят условные перенаправления для внутренних зон и как это связано с доменом поиска.
- Правила доступа — с каких подсетей разрешены запросы к служебным портам, кому открыта рекурсия, что закрыто наружу и почему.
- Регламент обслуживания — периодичность проверки зон, обновление корневых подсказок, ротация служебных записей и перезапуск службы без простоя.
- Порядок действий при сбое — с чего начинать диагностику, как переключиться на резервный резолвер, какой командой откатить конфигурацию до последней рабочей ревизии.
- Документация по инфраструктуре — адреса и роли узлов, точки мониторинга, ответственные, связи резолвера с остальными сервисами.
- Набор проверок после правки — время ответа, доля отказов, доступность внутренних зон; алерты привязаны именно к этим метрикам. Пакет остаётся у вас вместе с разбором на созвоне: что проверять после каждой правки и по каким признакам видно деградацию. Эксплуатация не должна зависеть от одного человека.
Пример внедрения: разрешение имён перестало зависеть от провайдера
Серверный парк заказчика — около 60 машин на двух площадках — ходил за именами напрямую к резолверам провайдера, а на части хостов работал локальный кэш из состава дистрибутива, и настройки со временем разъехались. Доля неуспешных запросов на пике держалась около 4%, а прикладной сервис, который при старте разбирает десятки внутренних имён, отвечал вдвое дольше обычного.
Что изменили
Подняли рекурсивный резолвер на Unbound и поставили два независимых узла на разных площадках — отказ любого из них больше не останавливает разрешение имён. Локальные кэши на хостах выключили, машины перевели на два адреса через управляемый параметр, внутренние зоны описали отдельно от внешних. Доступность узлов, время отклика и долю ошибок отдали в мониторинг с автоматическими проверками.
Метрики до и после
- Доля неуспешных запросов: около 4% на пике → стабильно ниже 0,2%, единичный отказ закрывается повтором на второй узел.
- Время отклика прикладного сервиса при старте сократилось вдвое — за счёт кэша и предсказуемого маршрута запросов.
- Обращения по инцидентам с разрешением имён: 8–10 в месяц → одно за квартал, и то по внутренней зоне.
Единая точка отказа ушла: внешние резолверы остались резервным путём, но перестали быть единственным источником ответов. Дальше развиваем схему — добавляем разделение зон по площадкам и проверки, которые ловят расхождение настроек до того, как его заметят пользователи.
Встроенный резолвер или отдельный: когда нужен второй?
Короткий ответ: встроенная служба закрывает одиночный сервер, а отдельный экземпляр нужен, когда появляется парк машин, изолированный контур или требование видеть каждый запрос. Встроенный резолвер стартует вместе с системой и отдаёт кэш всем локальным процессам — этого достаточно, пока сетевые настройки не меняются из-под него.
Встроенный резолвер читает параметры от менеджера сети и переписывает вышестоящие серверы при каждом обновлении адресов. Журналирование запросов у него общее с системным журналом, без разбивки по клиентам, а объём кэша нечем ограничить — на нагруженном хосте это первое, что хочется вынести наружу.
Отдельный Unbound даёт явные зоны, локальные переопределения, кэш с подогревом популярных имён и отдельный журнал: видно, кто, что и когда спрашивал. Нагрузка на сервер становится предсказуемой — процесс живёт под своим ограничителем ресурсов, а на парке машин его выносят на выделенный узел с доступом по списку подсетей.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Встроенная служба | Одиночный сервер, простая сеть | Настройки переписывает менеджер сети, журнала по клиентам нет |
| Отдельный экземпляр на том же хосте | Нужны локальные зоны и разбор запросов | Один хост — одна точка отказа, делит ресурсы с приложениями |
| Отдельный узел для парка машин | Общий кэш на десятки серверов | Нужны ограничение доступа и контроль доступности |
| Резолвер в изолированном контуре | Внутренние имена не должны уходить наружу | Только свои источники и форвардер периметра |
В изолированном контуре резолвер вообще не ходит наружу: внутренние зоны отдаёт авторитетный источник, внешние — форвардер на периметре. Ответы идут только по разрешённым маршрутам, утечка внутренних имён через публичные резолверы исключена.
Сомнения инженера: кэш, шифрование, откат настроек
Перед стартом работ инженеры задают один и тот же набор вопросов: что будет с уже накопленным кэшем, уходят ли запросы наружу в открытом виде, не сломается ли разрешение имён у служб, которые уже развёрнуты, и как вернуться к прежней схеме, если что-то пойдёт не так. Ниже — короткие ответы по каждому пункту.
Что делать с устаревшими записями в кэше?
Кэш живёт по времени жизни записи, поэтому старая зона после переезда сервиса — обычное дело. У нас есть явный сброс кэша, а перед изменениями мы понижаем время жизни записей и возвращаем прежнее значение после проверки.
Передаются ли запросы наружу в шифрованном виде?
Исходящие запросы можно заворачивать в шифрованный транспорт, чтобы провайдер и промежуточные узлы не видели имена. Внутри периметра резолвер отвечает по обычному порту — иначе контейнеры и старые службы перестанут разрешать имена.
Совместимость со службами, которые уже работают?
Перед заменой снимаем список тех, кто и как спрашивает DNS: системные службы, контейнеры, VPN, домены. Разделение зон — внутренние локально, внешние наружу — настраивается до переключения, поэтому службы видят привычные имена.
Как проходит откат настроек?
Конфигурации лежат в системе контроля версий, применение и откат — переключением на предыдущий набор файлов. Старый резолвер не удаляем, пока новая схема не отработает под нагрузкой; возврат занимает минуты и не требует перезагрузки сервера.
Обсудим задачу: как мы приходим к плану внедрения
Чтобы оценка опиралась на факты, а не на догадки, нужен минимум входных данных: как устроены контуры, кто и как разрешает имена сейчас, какие требования предъявляются к изоляции запросов. Именно это определяет выбор между локальным кеширующим резолвером и Unbound с собственными зонами и пересылкой в закрытые контуры.
Что запрашиваем на входе:
- Схему контуров: сегменты сети, где стоят потребители, как трафик ходит между ними.
- Перечень серверов и ролей: где локальный резолвер, где кеширующий, где форвардер.
- Требования к изоляции: какие зоны не должны уходить во внешние резолверы, нужен ли DNSSEC и как обрабатывать ответы с ошибкой подписи.
- Текущее состояние: рабочие конфигурации, способ распространения resolv.conf, управление через конфигурационный менеджер.
- Окно переключения, допустимое время недоступности разрешения имён, доступы и ответственные за приёмку.
В ответ вы получаете план внедрения по этапам с критериями готовности каждого, состав работ с разделением зон ответственности и состав артефактов: конфигурации, unit-файлы, политики кеширования и пересылки, схему отката к прежнему резолверу.
Отдельно согласуем порядок переключения потребителей и проверок после него, а также регламент передачи в эксплуатацию — метрики, алерты, инструкцию для дежурного. Опишите задачу — вернёмся с оценкой, планом и составом работ.
