Доменная сеть имен: настройка локального DNS-сервера

В этот момент разработчики часто начинают перезапускать Nginx, чистить кэш браузера и обвинять Docker. Проблема обычно проще: имя не преобразуется в IP.

Файл /etc/hosts закрывает только базовые сценарии. Он умеет сопоставлять конкретные имена и адреса, но не поддерживает wildcard-записи вроде *.dev.local. Значит, app.dev.local, api.dev.local и admin.dev.local придётся прописывать вручную. Или ты поднимаешь нормальную локальную доменную сеть имен — DNS-сервис, который отвечает за зону целиком.

Это уже не косметический апгрейд. Это буст для локальной разработки, тестовых стендов, приватных сетей и небольших инфраструктур. Разберём, как работает локальный DNS, где в цепочке участвуют systemd-resolved и порт 53, когда выбирать BIND9, а когда Dnsmasq, и почему Windows Server закрывает задачу другим набором инструментов.

Если в проекте больше двух виртуальных хостов, ручное редактирование /etc/hosts быстро превращается в технический долг с плохим CTR по времени команды.

Почему /etc/hosts перестаёт давать профит

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

192.168.10.20 app.dev.local

После этого запрос к app.dev.local будет направлен на нужный IP. Для одной машины и двух имён — рабочая гипотеза. Для полноценной тестовой среды — уже нет.

Основная проблема в отсутствии логики зоны. /etc/hosts не понимает, что api.dev.local, admin.dev.local и cdn.dev.local принадлежат одной доменной структуре. Он не поддерживает маски и wildcard-записи. Строка вроде *.dev.local не станет универсальным правилом для всех поддоменов.

Отсюда появляются типичные симптомы:

1. Новый поддомен не открывается.

Ты добавил виртуальный хост в Nginx, настроил сертификат, но забыл внести имя на клиентской машине.

2. Команда работает только у одного разработчика.

У него в hosts лежит нужная запись. У остальных — нет. Документация молчит, onboarding буксует.

3. Контейнеры видят разные адреса.

Хост-система резолвит имя, а контейнер получает другой DNS-конфиг. Локальная сеть становится непредсказуемой.

4. Wildcard для тестовой зоны не работает.

Ты рассчитываешь на *.project.local, но hosts не умеет обрабатывать такие записи.

5. Любое изменение требует ручного редактирования нескольких файлов.

Добавил новый сервис — обновляй ноутбук, CI-агент, тестовый сервер и иногда настройки мобильного устройства.

Вот здесь и появляется локальный DNS-сервер. Он хранит записи в доменной зоне, отвечает на DNS-запросы и позволяет менять инфраструктуру централизованно. Один конфиг вместо пачки локальных исключений.

DNS не равен публичному домену

Локальная доменная сеть имен не делает сайт доступным из интернета. Это принципиальная граница.

Если твой DNS отвечает только внутри приватной сети, его зона существует для конкретных клиентов: ноутбуков, серверов, контейнеров, виртуальных машин. Публичные DNS-серверы не узнают о ней автоматически. Для внешней доступности нужны публичные NS-записи, маршрутизация, открытые порты и отдельная модель безопасности.

Локальный DNS решает другую задачу:

• связывает внутренние имена с приватными IP-адресами;
• направляет тестовые домены на localhost или внутренний сервер;
• обслуживает локальные зоны;
• может работать вместе с DHCP;
• уменьшает количество ручных настроек на рабочих станциях.

Не путай эти уровни. Иначе появится ложная гипотеза: «Я настроил BIND9, значит домен уже виден снаружи». Нет. DNS внутри сети и публичная делегация — разные контуры.

Как работает служба доменных имен внутри сети

DNS-запрос выглядит просто: клиент хочет узнать IP для имени. Например, браузер отправляет запрос на app.dev.local. Но между браузером и авторитетным сервером может быть несколько уровней:

• локальный кэш операционной системы;
• локальный резолвер;
• DNS-сервер сети;
• авторитетный сервер нужной зоны;
• внешние DNS-серверы, если имя не относится к локальной зоне.

В Linux с systemd-resolved в /etc/resolv.conf часто указывается адрес 127.0.0.53. Это локальный stub-резолвер systemd-resolved. Он принимает запросы от приложений и дальше сам решает, куда их отправить.

Если ты поднимаешь собственный DNS на локальном интерфейсе, часто используется 127.0.0.1. Но простая замена одного адреса на другой не всегда закрывает задачу. Нужно понимать, кто сейчас слушает порт и какой сервис управляет /etc/resolv.conf.

Стандартный DNS использует порт 53 по UDP и TCP. В большинстве обычных запросов применяется UDP. TCP нужен для отдельных сценариев: например, когда ответ слишком большой или требуется надёжное соединение между DNS-серверами.

Где чаще всего ломается настройка

1. Порт 53 уже занят

Если systemd-resolved или другой резолвер уже слушает нужный адрес, BIND9 или Dnsmasq не смогут привязаться к нему. Сервис может формально установиться, но не запуститься.

Проверяй, какой процесс занял порт 53, до изменения конфигурации. На Linux для диагностики обычно используют ss, lsof или системные журналы. Твоя цель — не просто увидеть ошибку запуска, а понять конфликт адреса и владельца порта.

2. /etc/resolv.conf управляется автоматически

На системах с systemd этот файл может быть символической ссылкой на сгенерированный конфиг. Ты вручную вписал nameserver 127.0.0.1, перезагрузил сеть — и запись исчезла.

Это не баг DNS. Это конфликт между ручной настройкой и менеджером сети. Сначала определи, кто управляет резолвингом: systemd-resolved, NetworkManager, netplan, DHCP-клиент или другой слой.

3. DNS-сервер доступен только локально

Если сервис слушает 127.0.0.1, он отвечает только на запросы этой машины. Соседний ноутбук в той же сети его не увидит. Для локальной доменной сети нужно слушать подходящий приватный интерфейс и разрешить запросы от нужных подсетей.

Но открывать рекурсивный DNS для всего мира нельзя. Это прямой путь к злоупотреблению сервером и DNS amplification-атакам.

4. Имя разрешается, но сайт всё равно не открывается

DNS возвращает IP. На этом его задача заканчивается.

Дальше вступают в игру:

• маршрутизация;
• firewall;
• reverse proxy;
• TLS-сертификат;
• заголовок Host;
• настройки виртуального хоста;
• Docker-сеть или Kubernetes Service.

Не смешивай уровни. Если dig app.dev.local возвращает правильный адрес, а браузер получает 502, это уже не проблема службы доменных имен.

Минимальная карта диагностики

DNS — это первый слой маршрута к приложению. Не заставляй его отвечать за проблемы, которые начинаются после получения IP.

BIND9: когда нужна полноценная локальная зона

BIND9 — классический вариант для настройки DNS-сервера. Он подходит, когда тебе нужно управлять зонами явно, разделять авторитетные записи, задавать политики доступа и строить инфраструктуру ближе к production-подходу.

Это не самый лёгкий инструмент для первого локального прототипа. Зато он даёт правильную модель мышления: домен — это зона, зона — отдельная конфигурация, а записи хранятся в zone-файле с определённым синтаксисом.

На Debian- и Ubuntu-подобных системах обычно устанавливают пакет BIND9 через менеджер пакетов дистрибутива. После установки основная работа проходит в нескольких местах:

• /etc/bind/named.conf.local — подключение локальных зон;
• отдельный файл зоны — записи домена;
• конфигурация общих параметров BIND9;
• журналы systemd для проверки запуска и ошибок.

Как описывается локальная зона

В /etc/bind/named.conf.local прописывают зону с указанием имени, типа и пути к файлу. Для локального мастер-сервера используется тип master.

Логика выглядит так:

• объявляется зона, например dev.local;
• задаётся тип master;
• указывается файл, где лежат SOA, NS и адресные записи;
• BIND9 загружает этот файл и начинает отвечать за домен.

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

Что находится в файле зоны

Файл зоны описывает, какие имена существуют и куда они указывают. В минимальной локальной конфигурации понадобятся:

• SOA-запись с параметрами зоны;
• NS-запись, указывающая авторитетный DNS-сервер;
• A-записи для конкретных имён;
• wildcard A-запись, если нужно направлять неизвестные поддомены на один адрес;
• при необходимости CNAME для алиасов.

Например, отдельные сервисы можно направить так:

• app.dev.local → 192.168.10.20;
• api.dev.local → 192.168.10.21;
• admin.dev.local → 192.168.10.22.

А wildcard-запись может отправлять остальные поддомены на общий reverse proxy. Это уже другой уровень гибкости по сравнению с hosts.

Но wildcard не означает «всё всегда и без исключений». Более конкретная запись имеет приоритет. Если для api.dev.local существует отдельный A-запись, она должна использоваться вместо общего wildcard-правила. Проверяй результат запросом, а не доверяй только чтению конфига.

Проверяй конфигурацию до перезапуска

Сильная DNS-гипотеза всегда проверяется в три шага:

1. Синтаксис конфигурации.

Используй штатные утилиты проверки BIND9, чтобы найти ошибки до перезапуска службы.

2. Загрузка зоны.

Отдельно проверь zone-файл. Синтаксис named.conf.local может быть корректным, а сама зона — нет.

3. Фактический ответ.

Отправь запрос через dig или nslookup и посмотри, какой сервер ответил, какой IP вернулся и какой статус получил запрос.

Например, тебе нужно проверить не только dig app.dev.local, но и явно указать сервер: dig @127.0.0.1 app.dev.local. Так ты исключишь ситуацию, когда запрос случайно ушёл во внешний DNS и вернул другой результат.

Где BIND9 оправдан

Выбирай BIND9, если:

• у тебя несколько локальных зон;
• нужно управлять DNS как отдельным инфраструктурным сервисом;
• требуется точный контроль авторитетных ответов;
• стенд должен быть похож на production;
• планируется несколько DNS-серверов;
• в команде есть DevOps-компетенции;
• зона будет использоваться не только одной рабочей станцией.

Для одного разработчика с тремя контейнерами BIND9 может быть избыточным. Это не проблема самого BIND9. Просто инструмент рассчитан на более глубокий контроль, а не на самый быстрый старт.

Dnsmasq: быстрый буст для локальной разработки

Dnsmasq объединяет лёгкий кэширующий DNS-сервер и DHCP-сервер. Именно поэтому он популярен в локальных сетях, лабораториях, тестовых стендах и средах разработки.

Его профит — в скорости внедрения. Не нужно строить тяжёлую иерархию зон, если задача звучит так: «Все *.project.test отправлять на локальный reverse proxy, а DHCP-клиентам выдавать этот DNS автоматически».

Основной конфигурационный файл — /etc/dnsmasq.conf. В зависимости от дистрибутива часть параметров может храниться в каталоге дополнительных конфигураций. Не существует одного универсального конфига для всех Linux-систем: пакет, способ запуска и сетевой менеджер влияют на структуру.

Сценарии, где Dnsmasq выигрывает

Wildcard для localhost

Файл hosts не поддерживает маски. Dnsmasq умеет задать правило, по которому домен и его поддомены будут направляться на выбранный адрес.

Это особенно удобно для проектов, где каждый pull request получает отдельный hostname:

• pr-101.project.test;
• pr-102.project.test;
• feature-login.project.test.

Тебе не нужно добавлять каждое имя вручную. Reverse proxy принимает запрос, смотрит на hostname и направляет его в нужный сервис.

Локальный DHCP

Если Dnsmasq одновременно выдаёт адреса по DHCP, клиентам можно автоматически сообщать DNS-сервер. Подключил ноутбук к тестовой сети — и он получил IP, gateway и адрес локального резолвера без ручной настройки.

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

Кэширование

Повторные запросы к одним и тем же доменам могут обслуживаться из локального кэша. Это уменьшает задержку и количество обращений к внешним DNS-серверам. Для разработки это приятный буст, особенно если стенд регулярно пересобирается и перезапрашивает зависимости.

Как построить конфигурацию Dnsmasq без хаоса

Сначала зафиксируй доменную модель:

• какой суффикс используется для разработки;
• какая подсеть считается локальной;
• какие адреса постоянные;
• какие имена должны уходить на внешний DNS;
• нужен ли DHCP;
• какие интерфейсы имеют право отправлять запросы.

Затем раздели правила по смыслу. Не складывай всё в один длинный конфиг без комментариев. Через месяц ты сам не вспомнишь, почему api.project.test указывает на один адрес, а wildcard — на другой.

Минимальная логика обычно такая:

1. локальная зона или доменный суффикс направляется на нужный адрес;

2. отдельные имена получают точечные записи;

3. внешние домены пересылаются upstream-серверам;

4. запросы принимаются только с разрешённых интерфейсов;

5. DHCP включается только при полной уверенности, что в сети нет второго DHCP-сервера.

Dnsmasq против BIND9

Гипотеза простая: если тебе нужно быстро поднять локальные имена и DHCP — начинай с Dnsmasq. Если ты строишь управляемую инфраструктуру зон — смотри в сторону BIND9.

Локальный резолвинг в Linux: systemd-resolved, resolv.conf и порядок действий

Самая частая ошибка при настройке локального DNS — установить сервис и считать задачу закрытой. Нет. Клиент должен использовать именно этот сервис.

Проверь цепочку:

1. DNS-сервер запущен.

2. Он слушает порт 53.

3. Он принимает запросы на нужном интерфейсе.

4. Клиент отправляет запрос на его IP.

5. Локальная зона загружена.

6. Ответ возвращается приложению.

7. Браузер и контейнер используют тот же маршрут резолвинга, если это требуется.

На Linux адрес 127.0.0.53 часто означает, что запросы принимает systemd-resolved. Это не то же самое, что твой BIND9 на 127.0.0.1. Можно оставить systemd-resolved как локальный stub и настроить upstream DNS через него. Можно направить клиентов напрямую на собственный сервис. Конкретный вариант зависит от сетевого менеджера и архитектуры машины.

Не переписывай /etc/resolv.conf вслепую. Сначала проверь, является ли файл обычным файлом или символической ссылкой. Затем посмотри статус systemd-resolved и параметры активного интерфейса.

Разные клиенты — разные DNS-настройки

Хост-система, Docker и виртуальная машина могут использовать разные DNS-маршруты.

Например:

• браузер на хосте видит app.project.test;
• контейнер не знает эту зону;
• виртуальная машина использует DNS роутера;
• CI-агент работает в отдельной сети;
• мобильное устройство вообще не получает доступ к локальному серверу.

Такой стенд нельзя считать настроенным. Он работает только для одного маршрута.

Если DNS нужен контейнерам, укажи им доступный адрес резолвера через сетевую конфигурацию Docker или оркестратора. Если DNS должен обслуживать несколько устройств, сервер обязан быть доступен на приватном интерфейсе, а firewall — разрешать запросы из нужной подсети.

Проверяй не только A-запись

Для локального веб-проекта обычно начинают с A-записи, но реальная проверка шире:

• имя зоны;
• точное имя хоста;
• тип ответа;
• IP-адрес;
• авторитетность ответа;
• TTL;
• наличие старой записи в кэше;
• доступность DNS-сервера по UDP и TCP;
• корректность reverse proxy.

Команда dig полезнее, чем бесконечное обновление вкладки. Она показывает, что реально вернул DNS, а не то, как браузер интерпретировал ошибку.

Если ты меняешь запись и сразу не видишь результат, учитывай TTL и локальное кэширование. В тестовой среде ставь короткое время жизни записей, но не превращай production-конфигурацию в бесконечный поток запросов.

Защита локального DNS: приватность не заменяет контроль

«Это же локальная сеть» — плохое оправдание для открытого резолвера. Даже внутренний DNS-сервер может стать точкой атаки, если он доступен из лишних сегментов.

Начни с базовой модели доступа:

• разреши DNS-запросы только нужным подсетям;
• ограничь интерфейсы, на которых сервис слушает;
• не открывай рекурсию во внешний интернет без необходимости;
• разделяй авторитетные ответы и рекурсивные запросы;
• фильтруй входящий трафик firewall;
• контролируй логи и частоту запросов;
• не публикуй внутренние зоны через публичные NS без архитектурной причины.

DNS часто содержит карту инфраструктуры: имена админских панелей, staging-серверов, внутренних API и служебных узлов. Это не секреты в прямом смысле, но и раздавать их всем подряд не нужно.

Для dev-среды достаточно аккуратных ACL и приватной адресации. Для корпоративной сети потребуется больше: резервирование, мониторинг, журналирование, разграничение зон и понятная процедура изменения записей.

Не путай DNS с TLS

Локальное имя может успешно разрешаться, но HTTPS всё равно выдаст предупреждение. Причина — сертификат не покрывает домен или клиент не доверяет локальному центру сертификации.

DNS отвечает на вопрос: куда идти. TLS отвечает на вопросы: с кем установлено соединение и можно ли доверять сертификату.

Для проекта с несколькими локальными поддоменами настрой оба слоя:

• DNS wildcard или набор конкретных записей;
• reverse proxy;
• локальный сертификат;
• доверие к корневому сертификату на нужных устройствах;
• корректный SNI и виртуальные хосты.

Если команда занимается интерфейсами и дизайн-системами, доменная схема тоже влияет на скорость работы: отдельные поддомены для storybook, документации и тестовых сборок сокращают ручные переключения. А если ты параллельно прокачиваешь визуальную часть продукта, можно посмотреть на курсы графического дизайна с нуля — но не смешивай обучение дизайну с задачами DNS: это разные треки, просто оба влияют на скорость выпуска веб-продукта.

Windows Server и Active Directory: DNS как часть доменной инфраструктуры

В Windows Server DNS часто разворачивается не как отдельная утилита для локальных имён, а как часть инфраструктуры Active Directory. При установке роли AD DS DNS может быть добавлен автоматически, потому что доменные службы зависят от корректного разрешения имён.

Роль DNS-сервера можно установить автономно через PowerShell с использованием Install-WindowsFeature. После установки конфигурация управляется средствами Windows Server: Server Manager, DNS Manager, PowerShell и групповыми политиками.

Когда достаточно автономного DNS

Отдельный DNS-сервер на Windows подходит, если нужно:

• обслуживать внутреннюю зону;
• разрешать имена серверов и рабочих станций;
• интегрировать DNS с DHCP;
• работать в инфраструктуре без Active Directory;
• централизовать настройки для Windows-клиентов.

Но если в сети уже используется домен Active Directory, DNS становится критической зависимостью. Неправильные записи ломают не только открытие сайтов, но и поиск контроллеров домена, вход пользователей, применение политик и взаимодействие сервисов.

Что меняется с Active Directory

В AD DNS тесно связан со структурой домена. Появляются SRV-записи, динамическая регистрация клиентов, репликация и требования к доступности контроллеров.

Здесь нельзя ограничиться подходом «пропишем пару A-записей и забудем». Нужны:

• резервные DNS-серверы;
• корректные forwarder-настройки;
• синхронизация времени;
• контроль динамических обновлений;
• резервное копирование;
• понятная схема внутренних зон;
• мониторинг ошибок разрешения имён.

Для небольшой тестовой машины Windows DNS может быть избыточен. Для среды на базе AD — наоборот, это базовый инфраструктурный компонент.

Как выбрать архитектуру под задачу

Не начинай с бренда сервера. Начинай с нагрузки и границ сети.

Сценарий 1. Один разработчик и локальный проект

Тебе нужны несколько имён для Nginx, Docker или локального reverse proxy. Подними Dnsmasq или используй hosts для точечных записей. Если нужен wildcard, hosts сразу исключай.

Сценарий 2. Команда и общий тестовый стенд

Нужен DNS, доступный по приватному интерфейсу, плюс понятная зона. Dnsmasq подойдёт для простой dev-сети. BIND9 — если зоны должны управляться структурированно и стенд близок к production.

Сценарий 3. Несколько VLAN и внутренние сервисы

Нужны ACL, маршрутизация, firewall и разделение рекурсивных и авторитетных функций. Здесь быстрый локальный конфиг уже не закрывает все риски. Проектируй DNS как инфраструктуру.

Сценарий 4. Windows-домен

Используй DNS, интегрированный с Active Directory, и не создавай параллельную схему имён без необходимости. В этой среде ошибки DNS быстро превращаются в ошибки всей доменной инфраструктуры.

Сценарий 5. Гибридная облачная среда

Локальные зоны должны быть согласованы с облачными сетями, VPN, private endpoints и сервисным discovery. Если часть приложений живёт в облаке, а часть — в офисной сети, заранее определи, где находится авторитетный ответ для каждого домена.

Практический план внедрения

Сделай не «настройку DNS вообще», а короткий управляемый спринт.

1. Зафиксируй доменную схему.

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

2. Определи границы доступа.

Реши, кто должен резолвить имена: только localhost, вся LAN, VPN-клиенты, контейнеры или виртуальные машины.

3. Выбери инструмент.

Dnsmasq — быстрый старт и DHCP. BIND9 — полноценные зоны и более строгий контроль. Windows DNS — естественный выбор для Windows Server и AD DS.

4. Проверь порт 53.

Найди существующий процесс и не допускай конфликтов с systemd-resolved или другим локальным резолвером.

5. Создай одну тестовую запись.

Не начинай с десяти зон. Добавь app.dev.local, проверь ответ через dig или nslookup, затем подключай остальные имена.

6. Проверь wildcard отдельно.

Запроси имя, которого нет в списке конкретных записей. Так ты поймёшь, работает ли механизм маски, а не просто одна A-запись.

7. Подключи клиентов.

Настрой хост, контейнеры, виртуальные машины и устройства команды. У каждого должен быть понятный DNS-маршрут.

8. Ограничь доступ firewall.

Разреши UDP/TCP 53 только нужным подсетям и интерфейсам.

9. Добавь наблюдаемость.

Логи DNS покажут, какие имена не находятся, кто генерирует лишние запросы и где появился конфликт.

10. Документируй откат.

Запиши, как вернуть прежний резолвер и восстановить стандартный /etc/resolv.conf или сетевой профиль Windows.

Что внедрить сегодня

Начни с одного проекта. Не строй DNS-империю ради трёх записей.

• Убери wildcard-гипотезу из /etc/hosts: файл её не поддерживает.
• Выпиши локальную зону и список сервисов.
• Для быстрого dev-сценария подними Dnsmasq.
• Для управляемых зон выбери BIND9 и вынеси описание зоны в /etc/bind/named.conf.local.
• Проверь, не занят ли порт 53.
• Разберись, кто управляет /etc/resolv.conf.
• Проверь ответы через dig @адрес_сервера имя.
• Отдельно протестируй хост, контейнер и виртуальную машину.
• Не открывай внутренний DNS наружу.
• После DNS настрой TLS и reverse proxy — иначе имя будет работать, а приложение всё равно останется недоступным.

Доменная сеть имен — это не магия и не отдельный ритуал системного администратора. Это слой маршрутизации по именам, который связывает браузер, сервер, контейнеры и приватную инфраструктуру. Убери ручные записи, централизуй зоны, проверь порт 53 и зафиксируй границы доступа.

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