Комментарий пользователя
У нас есть несколько десятков серверов, объединенных в одну приватную сеть. Запоминать локальные IP-адреса стало невозможно. Как правильно и с минимальными усилиями организовать внутренний DNS, чтобы серверы могли обращаться друг к другу по понятным коротким именам?
Ответ специалиста
Привет, Михаил! В растущей инфраструктуре рано или поздно наступает момент, когда держать в голове адрес каждого узла становится невозможно и чревато ошибками.
Для решения вашей задачи необходимо организовать приватный DNS. Его главное преимущество в том, что внутри закрытого контура вы можете использовать абсолютно любые доменные зоны — например, .internal, .lab, .prod или .office. Вам не нужно покупать эти домены у регистратора или подтверждать права владения ими, так как существовать они будут исключительно внутри вашей частной сети.
Если говорить о решении «с минимальными усилиями», у вас есть два основных пути.
1. Использовать наш управляемый приватный DNS для облака.
Это самый простой вариант: зона и записи настраиваются прямо в панели управления или через Terraform/API. Облако само позаботится об отказоустойчивости DNS-резолверов.
По умолчанию выданные адреса DNS-резолверов передаются на серверы автоматически по DHCP. Если же вы используете статическую настройку сети, вам потребуется указать их в конфигурации сети, которая обновит файлы /etc/resolv.conf на ваших серверах.
Остается только задать псевдонимы IP-адресов через Terraform/API или в панели управления в разделе Облачные серверы, в подразделе Приватный DNS. В последнем случае нужно создать зону, затем Добавить запись типа A и ввести имена хостов с соответствующими IP-адресами.
2. Развернуть свои DNS‑серверы.
Второй способ может заинтересовать опытных администраторов с особыми требованиями к архитектуре. Потребуются некоторые знания и опыт.
Если инфраструктура on-premise или хочется все контролировать самостоятельно, отлично подойдут такие инструменты, как CoreDNS или dnsmasq. С архитектурной точки зрения есть две роли:
- авторитативный сервер — хранит доменную зону и отвечает за валидность данных;
- DNS-резолвер (рекурсивный резолвер или рекурсор) — принимает DNS-запросы и возвращает результат, находя нужные записи в кеше или обращаясь к авторитативным DNS-серверам.
Со второй ролью есть нюанс: CoreDNS в режиме чтения зоны из файла работает исключительно как авторитет. Чтобы он стал полноценным резолвером и перенаправлял внешние запросы в интернет, в его конфигурации нужно дополнительно включить плагин forward.
Важное правило отказоустойчивости
Если требования проекта не допускают риска даже временной потери связи с DNS‑сервером, то нельзя его поднимать только на одной виртуальной машине. Если она упадет, приложения не смогут разрезолвить IP-адреса, и взаимодействие между сервисами остановится.
Должно быть хотя бы два отдельных DNS-сервера, записи на которых поддерживаются в синхронном состоянии — например, 192.168.1.2 и 192.168.1.3.
Как это выглядит на практике?
Допустим, вы завели зону myproject.internal. Прописываются в ней обычные A-записи:
db-master.myproject.internal→192.168.1.15,redis-cache.myproject.internal→192.168.1.25.
Сама по себе установка CoreDNS или dnsmasq ничего не изменит, пока другие серверы в проекте не начнут использовать их для запросов.
В современных дистрибутивах Linux файл /etc/resolv.conf уже давно не редактируют руками — им управляет служба systemd-resolved. Для перенаправления запросов вашей приватной зоны на новые DNS-серверы, потребуется внести изменения на каждом клиентском сервере сети. Чтобы не трогать основную конфигурацию ОС, лучше использовать дополнительный файл настроек — например, /etc/systemd/resolved.conf.d/internal.conf:
[Resolve]
DNS=192.168.1.2 192.168.1.3
Domains=~myproject.internal
Символ тильды (~) перед именем домена означает, что к новым серверам 192.168.1.2 и 192.168.1.3 будут отправляться запросы только для зоны myproject.internal. Остальные — пойдут через стандартный DNS провайдера.
После этого останется только перезапустить службу:
systemctl restart systemd-resolved
Теперь все приложения могут обращаться к базе данных по понятному имени. И здесь кроется главный плюс приватного DNS — гибкое управление трафиком.
Если завтра потребуется перенести базу данных на новый сервер, например, с IP 192.168.1.50, то не придется «ходить» по десяткам конфигурационных файлов веб-серверов и переписывать IP-адреса. Достаточно будет обновить одну A-запись в приватном DNS. Поскольку кэшированием управляете полностью вы (можно задать минимальный TTL для записей), переключение трафика на новый адрес произойдет практически мгновенно.
Ниже — примеры настройки.
1. Если вы предпочитаете самый простой вариант, dnsmasq, то здесь все максимально приближено к привычной работе с файлом /etc/hosts.
Прописать соответствия прямо в стандартном файле /etc/hosts на том сервере, где установлен dnsmasq, либо создать для этого отдельный текстовый файл — например, /etc/dnsmasq.hosts. В таком формате на каждой строчке сначала идет IP-адрес, а затем через пробел — доменное имя:
192.168.1.15 db-master.myproject.internal
192.168.1.25 redis-cache.myproject.internal
2. Если вы работаете с современным CoreDNS, то используется специальный плагин file или hosts. В таком случае создается отдельный текстовый файл в стандартном формате RFC 1035 (так называемый синтаксис BIND) зоны в директории с конфигурацией CoreDNS — например, db.myproject.local.
$ORIGIN myproject.internal.
@ IN SOA ns.myproject.internal. admin.myproject.internal. ( ... )
db-master IN A 192.168.1.15
redis-cache IN A 192.168.1.25
В главном конфигурационном файле CoreDNS (Corefile) просто указывается путь к этому файлу зоны.
