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

Вы наверняка знакомы с публичным 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 — это основа, внутри которой будет работать резолвер:

      # Создать приватную сеть и подсеть
resource "openstack_networking_network_v2" "network_1" {
  name           = "private-network"
  admin_state_up = "true"
}

resource "openstack_networking_subnet_v2" "subnet_1" {
  name       = "private-subnet"
  network_id = openstack_networking_network_v2.network_1.id
  cidr       = "192.168.199.0/24"
}

Затем подключаем созданную сеть к сервису приватного DNS. Здесь мы связываем сетевой сегмент с инфраструктурой резолвера, используя ID проекта и региона:

      # Подключить сеть к DNS-резолверу (region и tenant_id задаюится при инициализации провайдера OpenStack)
resource "selectel_private_dns_service_v1" "service_1" {
  region     = openstack_networking_network_v2.network_1.region
  project_id = openstack_networking_network_v2.network_1.tenant_id
  network_id = openstack_networking_network_v2.network_1.id
}

Когда связь настроена, переходим к описанию самой зоны и записей внутри нее. В блоке records прописываем нужные адреса для БД и почты. Установленный TTL в десять секунд даст быстрое обновление данных при их изменении:

      #Создать зону с записями (записи задаются )
resource "selectel_private_dns_zone_v1" "zone_1" {
  region     = openstack_networking_network_v2.network_1.region
  project_id = openstack_networking_network_v2.network_1.tenant_id
  domain     = "example.com."
  ttl        = 10

  records {
    domain = "database.example.com."
    type   = "A"
    ttl    = 10
    values = [
      "192.168.0.2",
    ]
  }

  records {
    domain = "mail.example.com."
    type   = "MX"
    ttl    = 10
    values = [
      "192.168.0.3",
    ]
  }
}

Больше нюансов в работе с Terraform можно найти в нашей документации. Также для интеграции со своими инструментами для автоматизации доступен публичный API.

Но управлять всем этим вручную сложно. Проще автоматизацию имен для инфраструктуры отдать провайдеру, просто подключив сеть к доменной зоне.

Какой итог

Приватный DNS решает те же задачи, что и публичный, но основной его фокус — это безопасность, скорость и контроль. И тот, и другой это критичный компонент инфраструктуры, от которого ожидается максимальная доступность. Но в случае с приватным DNS это централизованный подход с полноценно построенным HA решением.

Запуская инфраструктуру в облаке, можно строить свой сервис приватного DNS, а можно арендовать готовый. Готовый подходит для быстрого time-to-market и делегирования технической составляющей работы провайдеру. Свой сервис чаще поднимают, когда нужна интеграция с готовой инфраструктурой, например работающей в on-prem. Но даже в этом случае, если инфраструктура в облаке выделена в отдельную доменную зону, можно интегрироваться с готовым решением провайдера через форвардер.

В обоих подходах надежнее всего работает автоматика работы с записями для внутренней инфраструктуры. И снова ее можно делать самому через API или Terraform. Или воспользоваться готовой от провайдера.

Свобода в выборе решения позволяет строить ваше уникальное преимущество на рынке.