Управління 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. Отримайте консультацію — напишіть нам!