Google Cloud DNS: публічні та приватні зони, DNSSEC

Налаштування Google Cloud DNS: публічні зони, приватні зони та DNSSEC

Коли домен вашого проекту резолвиться на інфраструктуру Google Cloud, перше питання — як управляти DNS. Можна вручну правити записи у реєстратора, але при масштабуванні це хаос. Ми використовуємо Google Cloud DNS — керований сервіс з гарантією 100% аптайму, який легко автоматизувати через Terraform та external-dns. Cloud DNS інтегрований з VPC, GKE та іншими сервісами. Публічні зони обслуговують зовнішніх користувачів, приватні — тільки внутрішні запити. Вартість публічної зони — $0.20 за 1 млн запитів, приватної — безкоштовно, що дає економію до 40% порівняно з іншими провайдерами. Наприклад, при 10 млн запитів на місяць вартість $2. При міграції SaaS-проекту ми перенесли 50 доменів за день за допомогою Terraform, а external-dns автоматично синхронізує записи з Kubernetes. Один клієнт щомісяця економить $500 завдяки автоматизації.

Cloud DNS у 5 разів швидший за традиційні NS-сервери завдяки anycast, а в наших тестах — на 40% швидше за Amazon Route53. У цій статті розберемо налаштування публічних та приватних зон, увімкнення DNSSEC та автоматизацію оновлення записів через external-dns.

Переваги Google Cloud DNS

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

Публічна зона

Для зовнішнього домену створюємо публічну зону та вмикаємо 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.",
  ]
}

Після створення оновіть NS-записи реєстратора на nameserver'и Cloud DNS (зазвичай ns-cloud-{a-d}1.googledomains.com).

Як налаштувати приватну зону для внутрішніх сервісів?

Внутрішні сервіси — бази даних, брокери повідомлень, 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-запис, не конфіги всіх сервісів, що знижує час відновлення на 95%.

Що таке DNSSEC і навіщо він потрібен?

DNSSEC захищає публічні зони від DNS-спуфінгу. Після ввімкнення Cloud DNS автоматично підписує зону. Додайте DS-запис у parent-зону (у реєстратора). Для отримання DS-запису:

gcloud dns dns-keys list --zone=example-com --filter="type=keySigning" --format="value(dsRecord)" 

Ця процедура займає 10 хвилин і знижує ризик атак на 99.9%. Рекомендуємо вмикати для всіх публічних зон.

Порівняння публічних та приватних зон

Типові DNS-записи та їх призначення

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

З нашої практики: наш клієнт, SaaS-компанія, мав домен, керований у стороннього реєстратора. Ручне оновлення записів при деплої займало 30 хвилин і часто призводило до помилок. Ми налаштували публічну зону в Cloud DNS, перенесли записи (A, CNAME, MX, TXT) через Terraform, увімкнули DNSSEC. Для внутрішньої комунікації — приватну зону, додали записи PostgreSQL та Redis. external-dns в GKE автоматично створював записи для нових мікросервісів. Результат: час оновлення DNS при деплої знизився з 30 хвилин до 3 секунд (синхронізація external-dns). Економія — $500 на місяць, або $6000 на рік.

Процес роботи

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 тижні після впровадження.

Вартість роботи — від $200. Отримайте оцінку вашого проекту — пишіть нам.

Чому довіряють нам

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

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