Настройка 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).
Процесс работы
- Аналитика: какие домены используете, какие записи нужны, есть ли DNSSEC у регистратора.
- Проектирование: архитектура зон (публичная/приватная), схема subnet для приватных зон.
- Реализация: Terraform-код, импорт существующих записей, настройка external-dns.
- Тестирование: проверка резолвинга, работы DNSSEC (dnssec-verify), failover.
- Деплой: обновление 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 без головной боли.







