Управление DNS в Google Cloud: Cloud DNS, DNSSEC, приватные зоны

Настройка и управление DNS в Google Cloud: Cloud DNS, DNSSEC, приватные зоны

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

Cloud DNS — это не просто перенести зону в GCP. Это управляемый anycast DNS с SLA 100%, интеграцией с IAM, поддержкой DNSSEC и приватными зонами для внутренней маршрутизации. Вопрос только в том, правильно ли всё настроено. Мы настраиваем DNS в GCP под ключ: от простых зон до гибридных топологий с forwarding и split-horizon.

Как Cloud DNS решает проблему DNS-leakage в гибридных сетях?

Одна из самых частых ошибок — публичная зона для внутреннего домена internal.company.com. Это создаёт риск утечки DNS-запросов наружу и лишние расходы. Правильное решение — приватная зона, которая резолвится только внутри VPC или через Cloud VPN/Interconnect.

Создание приватной зоны через gcloud:

gcloud dns managed-zones create internal-zone \
    --dns-name="internal.company.com." \
    --description="Internal services zone" \
    --visibility=private \
    --networks=projects/my-project/global/networks/default

Для публичной зоны с DNSSEC:

gcloud dns managed-zones create public-zone \
  --dns-name="company.com." \
  --description="Public zone" \
  --visibility=public \
  --dnssec-state=on

После включения DNSSEC нужно передать DS-записи регистратору — без этого DNSSEC не работает, а зона будет валидироваться как unsigned.

Почему стоит использовать Terraform для управления DNS-зонами?

Ручное создание записей в GCP Console — путь к расхождению между реальностью и документацией. Держим всё в Terraform:

resource "google_dns_managed_zone" "public" {
  name        = "company-public"
  dns_name    = "company.com."
  description = "Public DNS zone"

  dnssec_config {
    state = "on"
  }
}

resource "google_dns_record_set" "api" {
  name         = "api.company.com."
  managed_zone = google_dns_managed_zone.public.name
  type         = "A"
  ttl          = 300
  rrdatas      = [google_compute_global_address.lb.address]
}

resource "google_dns_record_set" "mx" {
  name         = "company.com."
  managed_zone = google_dns_managed_zone.public.name
  type         = "MX"
  ttl          = 3600
  rrdatas      = ["10 aspmx.l.google.com.", "20 alt1.aspmx.l.google.com."]
}

TTL для A-записей, указывающих на LB с часто меняющимися бэкендами, держим 60–300 секунд. Для MX и NS — 3600+.

Сравнение публичных и приватных зон

Split-horizon DNS для гибридных окружений

Если у вас Cloud VPN или Interconnect до on-premise, нужна split-horizon конфигурация: один и тот же домен резолвится по-разному снаружи и изнутри VPC. Cloud DNS поддерживает это через forwarding zones:

gcloud dns managed-zones create onprem-forward \
    --dns-name="corp.internal." \
    --visibility=private \
    --networks=projects/my-project/global/networks/vpn-network \
    --forwarding-targets=10.0.0.53

Запросы к *.corp.internal будут форвардиться на корпоративный DNS-сервер 10.0.0.53 через VPN-туннель.

Мониторинг DNS: что отслеживать?

Для production-среды критично настроить мониторинг DNS-запросов через Cloud Monitoring. Рекомендуемые метрики: количество запросов в минуту, процент ошибок (NXDOMAIN, SERVFAIL), задержка ответа. При превышении порога (например, >5% ошибок) срабатывает оповещение. SLA 100% Cloud DNS — это не панацея: неправильная конфигурация зон может привести к недоступности сервисов. Поэтому мы также настраиваем дашборды в Grafana с Loki для логирования изменений зон.

Disaster Recovery для DNS

Резервирование DNS включает создание backup-зон и вторичного DNS через gcloud dns managed-zones create с параметром --visibility=public и отдельным managed-зоной. В случае сбоя автоматически переключаем трафик на резервную зону. Тестируем failover каждые 6 месяцев.

Что входит в работу по настройке Cloud DNS?

• Аудит текущей DNS-инфраструктуры — выявление зон, записей, зависимостей.
• Проектирование архитектуры — определение приватных/публичных зон, DNSSEC, split-horizon.
• Реализация через IaC — Terraform или Pulumi с ревью кода.
• Миграция с сохранением сервиса — zero-downtime за счёт постепенного переключения TTL.
• Документация — схема DNS, описание зон, инструкции для команды.
• Обучение инженеров — работа с Cloud DNS, типовые сценарии.
• Пост-релизная поддержка — 2 недели мониторинга и корректировок.

Процесс работы

1. Аналитика — получаем доступы к GCP, изучаем текущую сеть, Kubernetes, CI/CD.
2. Проектирование — создаём схему DNS-зон, определяем IAM-роли и политики.
3. Реализация — пишем Terraform-модули, разворачиваем в тестовом окружении.
4. Тестирование — проверяем разрешение из VPC, из интернета, DNSSEC-валидацию.
5. Деплой — применяем в production с канареечным развёртыванием.
6. Мониторинг — настраиваем оповещения на ошибки DNS (например, через Cloud Monitoring).

Сроки и стоимость

Ориентировочные сроки: от 2 часов для простой публичной зоны до 3 дней для комплексной гибридной топологии с фрагментированными зонами и DNSSEC. Стоимость рассчитывается индивидуально — зависит от количества зон, записей и необходимых интеграций. Оценим ваш проект, напишите нам!

Типичные ошибки и чек-лист

• Не включили DNSSEC — зона остаётся без подписи, атаки возможны.
• Опубликовали приватный домен — создали публичную зону для internal.company.com.
• Забыли про TTL — при смене IP клиенты долго получают старый адрес.
• Нет мониторинга — сбой DNS может остаться незамеченным до инцидента.
• Использовали одинаковые TTL для всех записей — оптимально дифференцировать: для A-записей с LB 60-300 с, для MX 3600+, для NS 86400.

Мы настраивали DNS для проектов с трафиком более 1 млн запросов в день. Наш опыт — 10+ лет в GCP, сертифицированные Google Cloud Architects. Гарантируем SLA 100% на время ответа Cloud DNS. Получите консультацию — напишите нам!