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

Когда ваш домен начинает работать на инфраструктуре Google Cloud, ручное управление DNS-записями быстро превращается в хаос, особенно при росте проектов. Мы настраиваем Google Cloud DNS — публичные и приватные зоны с DNSSEC, автоматизируя процесс через Terraform и external-dns. Наша команда реализует проект под ключ, обеспечивая надёжное и масштабируемое решение с последующей поддержкой.
Часто задаваемые вопросы

Настройка DNS в Google Cloud

Отметим: когда домен вашего проекта начинает ресолвиться на инфраструктуру Google Cloud, первый вопрос — как управлять DNS. Можно вручную править записи у регистратора, но при масштабировании это превращается в хаос. Мы используем Google Cloud DNS — managed сервис с гарантией 100% аптайма, который легко автоматизировать через Terraform и external-dns. Cloud DNS тесно интегрирован с VPC, GKE и другими сервисами. Публичные зоны обслуживают внешние пользователи, приватные — только внутренние запросы. Для инфраструктуры на Google Cloud это естественный выбор: не нужно городить свои NS-серверы, весь контроль через единое API. Например, при миграции SaaS-проекта мы перенесли 50 доменов за один день с помощью Terraform, а external-dns автоматически синхронизирует записи с Kubernetes.

В этой статье разберём, как настроить публичные и приватные зоны, включить DNSSEC и автоматизировать обновление записей через external-dns. Приведём готовые Terraform-модули и реальный кейс с цифрами.

Преимущества Google Cloud DNS

Cloud DNS тесно интегрирован с VPC, GKE и другими сервисами Google Cloud. Публичные зоны обслуживают внешних пользователей, приватные — только внутренние запросы. Для инфраструктуры на GCP это естественный выбор: не нужно городить свои NS-серверы, весь контроль через единое API.

Публичная зона

Для внешнего домена создаём публичную зону и включаем DNSSEC:

resource "google_dns_managed_zone" "public" {
  project = var.project_id
  name = "example-com"
  dns_name = "example.com."
  description = "Public DNS zone"
  dnssec_config {
    state = "on"
  }
}

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

# MX-записи для почты
resource "google_dns_record_set" "mx" {
  project = var.project_id
  managed_zone = google_dns_managed_zone.public.name
  name = "example.com."
  type = "MX"
  ttl = 3600
  rrdatas = [
    "1 aspmx.l.google.com.",
    "5 alt1.aspmx.l.google.com.",
  ]
}

Google Cloud DNS documentation

После создания зоны нужно обновить NS-записи у регистратора домена на nameserver'ы, выданные Cloud DNS (обычно ns-cloud-{a-d}1.googledomains.com). Это обеспечит резолвинг вашего домена через Google.

Как настроить приватную зону для внутренних сервисов?

Внутренние сервисы — базы данных, брокеры сообщений, API — лучше адресовать по DNS, а не по IP. Приватная зона видна только внутри VPC:

resource "google_dns_managed_zone" "private" {
  project = var.project_id
  name = "internal-example-com"
  dns_name = "internal.example.com."
  description = "Private DNS for VPC"
  visibility = "private"
  private_visibility_config {
    networks {
      network_url = var.vpc_self_link
    }
  }
}

resource "google_dns_record_set" "postgres" {
  project = var.project_id
  managed_zone = google_dns_managed_zone.private.name
  name = "postgres.internal.example.com."
  type = "A"
  ttl = 60
  rrdatas = [google_sql_database_instance.main.private_ip_address]
}

Приватные зоны видны только изнутри VPC. Приложения используют postgres.internal.example.com вместо IP — при failover или переезде меняем только DNS-запись, не конфиги всех сервисов.

Что такое DNSSEC и зачем он нужен?

DNSSEC защищает публичные зоны от DNS-спуфинга. После включения Cloud DNS автоматически подписывает зону. Вам нужно добавить DS-запись в parent-зону (у регистратора). Для получения DS-записи выполните:

# Получить DS-запись для регистратора
gcloud dns dns-keys list \
    --zone=example-com \
    --filter="type=keySigning" \
    --format="value(dsRecord)"

Эта процедура занимает около 10 минут и даёт защиту от подмены DNS-ответов. Рекомендуем включать для всех публичных зон.

Как проверить работу DNSSEC?Используйте утилиту `dnssec-verify` или онлайн-сервисы вроде dnssec-debugger.verisignlabs.com. Если DS-запись добавлена правильно, проверка покажет зелёный статус.

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

Характеристика Публичная зона Приватная зона
Доступность Весь интернет Только внутри VPC
DNSSEC Поддерживается Не требуется (по умолчанию отключен)
Интеграция с external-dns Для Ingress/Service LoadBalancer Для внутренних сервисов (ClusterIP, Headless)
Типичный TTL 300–3600 сек 60–300 сек
Сценарий example.com, api.example.com db.internal.example.com, kafka.internal.example.com

Типичные DNS-записи и их назначение

Тип записи Назначение Пример TTL
A IPv4 адрес 300
AAAA IPv6 адрес 300
CNAME Псевдоним (каноническое имя) 600
MX Почтовый сервер 3600
TXT Текстовые данные (SPF, DKIM) 3600
SRV Сервисные записи 300

Кейс: миграция DNS на GCP для SaaS-проекта

Из нашей практики: у клиента (SaaS-компания) был домен mysaas.com, который раньше управлялся у стороннего регистратора. Ручное обновление записей при деплое новой версии занимало 30 минут и часто приводило к ошибкам. Мы настроили публичную зону в Cloud DNS, перенесли все существующие записи (A, CNAME, MX, TXT) через Terraform, включили DNSSEC. Для внутренней коммуникации — приватную зону internal.mysaas.com, в неё добавили записи для PostgreSQL и Redis. external-dns в GKE автоматически создавал записи для новых микросервисов. Результат: время обновления DNS при деплое снизилось с 30 минут до 3 секунд (синхронизация external-dns).

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

  1. Аналитика: какие домены используете, какие записи нужны, есть ли DNSSEC у регистратора.
  2. Проектирование: архитектура зон (публичная/приватная), схема subnet для приватных зон.
  3. Реализация: Terraform-код, импорт существующих записей, настройка external-dns.
  4. Тестирование: проверка резолвинга, работы DNSSEC (dnssec-verify), failover.
  5. Деплой: обновление NS-записей у регистратора, мониторинг через Cloud Monitoring + Grafana.

Сроки ориентировочно

  • Публичная зона с DNSSEC и базовыми записями: от 4 часов.
  • Приватная зона с интеграцией external-dns для GKE: от 1 дня.
  • Комплексная настройка (миграция всех зон + автоматизация): от 3 дней.

Что входит в работу

  • Создание публичных и приватных зон с нужными записями (A, AAAA, CNAME, MX, TXT, SRV).
  • Включение DNSSEC и публичный аудит подписей.
  • Настройка external-dns для Kubernetes (GKE).
  • Terraform-модули для управления зонами как кодом.
  • Документация: схема DNS, инструкция по добавлению записей, runbook при инцидентах.
  • Обучение вашей команды работе с Cloud DNS.
  • Поддержка в течение 2 недель после внедрения.

Почему доверяют нам

У нас 5 лет опыта в DevOps и SRE, более 20 успешных проектов по миграции DNS на GCP. Инженеры имеют сертификации Google Cloud Professional DevOps Engineer. Мы гарантируем стабильность: все изменения проходят через code review и тестовые зоны.

Готовы обсудить ваш проект? Свяжитесь с нами для консультации. Закажите настройку Google Cloud DNS и получите прозрачное управление DNS без головной боли.

Наши компетенции:

Последние работы

  • Разработка сайта компании B2B ADVANCE
    Разработка сайта компании B2B ADVANCE
    1542
  • Разработка веб-приложения для компании FEEDME
    Разработка веб-приложения для компании FEEDME
    1393
  • Разработка веб-сайта для компании БЕЛФИНГРУПП
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1081
  • Разработка интернет магазина для компании FURNORO
    Разработка интернет магазина для компании FURNORO
    1368
  • Разработка логотипа компании B2B Advance
    Разработка логотипа компании B2B Advance
    815
  • Разработка веб-приложения для компании Enviok
    Разработка веб-приложения для компании Enviok
    1139