Михаил Копытин

Вы наверняка знакомы с публичным DNS, если хоть раз задумывались, почему на запрос пушистые-котики.рф компьютер открывает сайт котиков, а не чертежи крыла самолета. В глобальной сети все прозрачно: есть многомиллиардный рынок доменов, есть огромная иерархия серверов, чья задача максимально быстро доставить вас на сайт котиков, банка или онлайн-кинотеатра. Но есть и другая сторона — когда доменные имена живут только внутри вашей приватной сети. Это и есть приватный DNS. Он не показывает адрес сервера для внешних запросов на резолв имени db.internal, да и вообще не отвечает на запросы извне. Он нужен, чтобы не запоминать, на каком IP локальный GitLab или тестовый стенд, и не гадать: «так, .105 — это балансировщик или база данных?». Ну и чтобы не бегать по всем серверам, заменяя один IP-адрес на другой для той самой базы, переехавшей на более мощное железо руками, — это долго, и легко ошибиться. Что такое приватный DNS и зачем он нужен Структуру внутренней инфраструктуры не выставляют напоказ. Более того, сегментируют по зонам контроля доступа — демилитаризованными (DMZ) и доверенными зонами, с тщательной фильтрацией трафика на границах. Но при этом не хочется отказываться от удобства использования доменных имен для адресации в приватных сетях — запоминать цифры людям сложно, и ошибиться при их наборе легко. Публикация имен внутренней инфраструктуры с приватными IP в публичном DNS — это подарок для OSINT. Перебор имен поддоменов по словарю позволит злоумышленнику узнать структуру вашей сети и спланировать эффективный вектор атаки. Поэтому появился приватный DNS, решающий проблему безопасности и удобства: размещается в изолированных приватных сетях — доступ к доменным именам закрыт снаружи, при этом адресация инфраструктуры делается через доменные имена. В отличие от публичного веба, где на первом месте стоит маркетинг и узнаваемость бренда, приватный DNS решает чисто прагматичные задачи: безопасность, прозрачность и полный контроль трафика. Вот что это дает на практике: Прозрачность и читаемость: приватный DNS позволяет использовать любые доменные имена для настройки инфраструктуры (например, в зонах .lab, .prod, или .office), не подтверждая владение доменным именем. Контроль времени жизни записей (TTL): в публичных сетях TTL носит скорее рекомендательный характер — записи могут кэшироваться на промежуточных узлах DNS инфраструктуры игнорируя ваши настройки. В приватном DNS управление кэшированием на вас: если нужно сейчас переключить трафик, то он переключится именно сейчас. Гибкое управление трафиком: чтобы перенаправить трафик на другой сервер, достаточно обновить одну A-запись. Нет необходимости перенастраивать IP-адреса на серверах-отправителях трафика. Что нужно знать про DNS в приватном контуре Если у публичного DNS основная задача — это найти IP-адрес для любого доменного имени в интернете, то для приватного DNS задача сужена до поиска доменных имен, определенных в рамках приватной сети. Это те зоны, для которых DNS является авторитативным сервером. Поэтому далее мы будем разделять DNS-резолвер и DNS-рекурсор: задача резолвера — обрабатывать запросы на резолв доменных имен в пределах своего авторитативного сервера; задача рекурсора — рекурсивный обход DNS-инфраструктуры интернета в поисках данных о внешнем домене. Авторитативный DNS-сервер, с которым работает DNS-резолвер, является «источником правды» о доменных зонах и записях для тех сетей, которые к нему подключены — хранит самую актуальную копию данных. Технически обе эти роли часто реализуются единым сервисом, специальными программами-серверами: BIND (самый старый стандарт, на котором держится значительная часть интернета), PowerDNS (удобен, если нужно управлять тысячами имен через базу данных) или современный и очень быстрый Knot DNS. Хотя любое из этих решений умеет все сразу, логически их роли лучше разделять: авторитативный сервер — отвечает за хранение доменных зон и записей. Его фокус направлен на: целостность, валидность данных и удобство работы с ними; DNS-резолвер — принимает запросы на резолв доменных имен. Он фокусируется на доступности, скорости и производительности. То есть мы снова говорим о полном контроле администрирования: в пределах приватной сети авторитативный сервер хранит всю информацию об инфраструктуре в зоне своей ответственности. Приватный DNS в распределенных сетевых контурах Часто облачная и локальная (on-premise) инфраструктуры разделены: они управляются через разные доменные зоны и через разные авторитативные серверы. Чтобы обеспечить доступность доменных имен из on-prem (и наоборот), к роли резолвера добавляется новая роль — DNS-форвардера. Это сервер, который отвечает за резолв доменных имен определенных зон через другие внешние для него авторитативные серверы. Например, у вас есть база данных в локальном дата-центре с адресом db.on-prem.local. Вы поднимаете приложение в облаке, которому нужно подключиться к этой базе. Облачный DNS-сервер ничего не знает про зону .on-prem.local — для него ее не существует. Без DNS-форвардера приложение просто не найдет путь к базе. Вы настраиваете форвардер так, чтобы все запросы на зону *.on-prem.local он перенаправлял на ваш локальный DNS-сервер в дата-центре. В итоге связность налажена, и приложение видит базу по имени, а не по неотличимому IP-адресу. DNS-форвардер также можно использовать как аналог рекурсора для публичных имен: если запрашиваемый домен не принадлежит конкретным зонам, то форвардер перенаправляет запрос на публичные рекурсоры. Такой подход даже безопаснее, поскольку запросы от форвардера разрешаются только на доверенные IP-адреса вышестоящих рекурсоров, что ограничивает неконтролируемый DNS-трафик. Приватные доменные зоны и записи Доменная зона для публичного DNS — это признак владения доменным именем. Для приватного DNS фокус смещается на ответственность конкретного авторитативного сервера в управлении зонами. Не буду детально останавливаться на доменных записях, скажу только, что в приватных сетях наиболее часто используется только часть из них: A, AAAA — основные записи, которые связывают имя с IP-адресом; TXT — для дополнительной информации о доменном имени, используемой некоторыми сервисами; MX — запись нужна, если в вашей сети есть внутренняя почта; CNAME — «псевдонимы», нужны для гибкости в создании алиасов. Что касается обязательных SOA (паспорт зоны) и PTR (поиск имени по IP), то для приватного DNS это скорее формальность. На что обратить внимание при организации приватного DNS Если настройка DNS— часто выполняемая задача, то поднять приватный DNS в новом контуре не занимает много времени: несколько часов вместе с настройкой автоматики и мониторинга. Автоматика рекомендуется для динамичных сред, где новые вычислительные инстансы регулярно появляются и исчезают. Тогда DNS-cервис должен поддерживать работу через API и, для полноценного IaC, поддержку Terraform. Вручную добавлять и удалять записи будет затратно по времени и увеличивает вероятность ошибки. Кроме того, со временем возникает неприятный эффект — потихоньку растет «кладбище записей». Это ситуация, когда неактуальные DNS-записи удаленных ресурсов не удаляются и накапливаются. Например, вы удалили сервер, но по какой-то причине не удалили его A-запись. Позже для этого доменного имени задается новый IP-адрес. В итоге часть трафика будет уходить или в никуда, или вовсе на другой сервер, вызывая потери пакетов или даже утечки данных. В сложной распределенной сети на диагностику проблемы уйдет много времени. Для продакшн-систем резервирование приватного DNS обязательно. При всей своей незаметности этот сервис является единой точкой отказа: когда у него начинаются проблемы, это сразу замечают все. Обязательно проверьте производительность полученной системы — время резолва имен под планируемой нагрузкой. При анализе результатов исходите из собственных требований к производительности, так как допустимая скорость отклика индивидуальна для каждой конкретной инфраструктуры. Облако — свое решение или от провайдера Облачные провайдеры предлагают готовые сервисы приватного DNS. Решение о построении своего или использовании готового зависит от нескольких факторов. Свое решение имеет смысл, если облачная инфраструктура работает в той же доменной зоне, что и on-prem инфраструктура. То есть on-prem инфраструктура с точки зрения доменных имен неотличима от облачной, и облако используется как скейлинг текущего on-prem решения. Решений «из коробки» для такой интеграции с готовыми сервисами приватного DNS от провайдера на рынке мы не нашли, так что выбор остается таким: или городить сложную автоматику, которая будет синхронизировать зону между on-prem и решением провайдера, либо использовать стандартную функциональность, например PowerDNS. Другой случай: если облачная инфраструктура работает под отдельной доменной зоной, то есть имеется логическое разделение on-prem и облака. Тогда готовое решение будет удобным инструментом для следующих сценариев: быстрый запуск нового проекта — чтобы не тратить время на базу, сфокусироваться на ценности; несколько изолированных сред для команд разработки в облаке — команды не зависят от админа и могут быстро разворачивать рабочие среды сами. Конечно это при условии, что провайдер сделал решение, учитывающие все те моменты что мы обсудили выше. Что мы построили в Selectel При разработке приватного DNS в облаке мы сфокусировались на потребностях наших пользователей и на надежности: «Идеальный DNS — это тот, о котором не вспоминаешь. Это сервис-функция: включил и забыл». Технически это реализовано так, чтобы инфраструктура выдерживала высокие нагрузки без деградации. Тесты показывают: сервис быстрый и производительный — резолвит доменные имена за 1 мс при нагрузке 5 000 rps и больше. Из коробки — отказоустойчивый и изолированный от внешнего влияния. Приватный DNS легко управляется через Terraform-провайдеры OpenStack и Selectel, как в примере ниже. Сначала готовим сетевой уровень. Описываем саму сеть и подсеть с нужным CIDR — это основа, внутри которой будет работать резолвер: Затем подключаем созданную сеть к сервису приватного DNS. Здесь мы связываем сетевой сегмент с инфраструктурой резолвера, используя ID проекта и региона: Когда связь настроена, переходим к описанию самой зоны и записей внутри нее. В блоке records прописываем нужные адреса для БД и почты. Установленный TTL в десять секунд даст быстрое обновление данных при их изменении: Больше нюансов в работе с Terraform можно найти в нашей документации. Также для интеграции со своими инструментами для автоматизации доступен публичный API. Но управлять всем этим вручную сложно. Проще автоматизацию имен для инфраструктуры отдать провайдеру, просто подключив сеть к доменной зоне. Какой итог Приватный DNS решает те же задачи, что и публичный, но основной его фокус — это безопасность, скорость и контроль. И тот, и другой это критичный компонент инфраструктуры, от которого ожидается максимальная доступность. Но в случае с приватным DNS это централизованный подход с полноценно построенным HA решением. Запуская инфраструктуру в облаке, можно строить свой сервис приватного DNS, а можно арендовать готовый. Готовый подходит для быстрого time-to-market и делегирования технической составляющей работы провайдеру. Свой сервис чаще поднимают, когда нужна интеграция с готовой инфраструктурой, например работающей в on-prem. Но даже в этом случае, если инфраструктура в облаке выделена в отдельную доменную зону, можно интегрироваться с готовым решением провайдера через форвардер. В обоих подходах надежнее всего работает автоматика работы с записями для внутренней инфраструктуры. И снова ее можно делать самому через API или Terraform. Или воспользоваться готовой от провайдера. Свобода в выборе решения позволяет строить ваше уникальное преимущество на рынке.

Михаил Копытин

Материалы автора

DNS в приватных сетях: мои сети — мои домены

Как настроить защиту сети в облаке: группы безопасности и файрвол