הגדרת DNS ב-Google Cloud: אזורים ציבוריים ופרטיים עם DNSSEC

הגדרת DNS ב-Google Cloud: אזורים ציבוריים ופרטיים עם DNSSEC

כשהדומיין של הפרויקט שלך מתחיל להיפתר דרך תשתית Google Cloud, השאלה הראשונה היא כיצד לנהל את ה-DNS. אפשר לערוך רשומות ידנית אצל הרשם, אבל ככל שזה גדל, זה הופך לכאוס. אנחנו משתמשים ב-Google Cloud DNS — שירות מנוהל עם SLA של 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

לאחר יצירת האזור, עליך לעדכן את רשומות ה-NS אצל רשם הדומיינים שלך לשרתי השמות שסופקו על ידי Cloud DNS (בדרך כלל 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.

איך להגדיר אזור פרטי לשירותים פנימיים?

שירותים פנימיים — מסדי נתונים, תורי הודעות, APIs — עדיף לטפל בהם באמצעות 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. יישומים משתמשים ב-ns-cloud-{a-d}1.googledomains.com במקום IP — במהלך כשל או העברה, אתה משנה רק את רשומת ה-DNS, לא את התצורה של כל השירותים.

מה זה DNSSEC ולמה צריך אותו?

DNSSEC מגן על אזורים ציבוריים מפני זיוף DNS. לאחר ההפעלה, Cloud DNS חותם על האזור באופן אוטומטי. צריך להוסיף רשומת DS לאזור האב (אצל הרשם שלך). כדי לקבל את רשומת ה-DS, הרץ:

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

הליך זה אורך כ-10 דקות ומספק הגנה מפני זיוף תגובות DNS. אנו ממליצים להפעיל אותו עבור כל האזורים הציבוריים.

השוואה בין אזורים ציבוריים ופרטיים

רשומות DNS אופייניות ומטרתן

מקרה: העברת DNS ל-GCP עבור פרויקט SaaS

מהניסיון שלנו: לקוח (חברת SaaS) היה עם הדומיין 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] } , שנוהל בעבר אצל רשם חיצוני. עדכוני רשומות ידניים במהלך פריסות ארכו 30 דקות ולעיתים קרובות הובילו לשגיאות. הקמנו אזור ציבורי ב-Cloud DNS, העברנו את כל הרשומות הקיימות (A, CNAME, MX, TXT) דרך Terraform, והפעלנו DNSSEC. לתקשורת פנימית — אזור פרטי postgres.internal.example.com, הוספנו רשומות עבור PostgreSQL ו-Redis. external-dns ב-GKE יצר רשומות אוטומטית עבור מיקרוסרוויסים חדשים. תוצאה: זמן עדכון ה-DNS במהלך פריסות ירד מ-30 דקות ל-3 שניות (סנכרון external-dns).

תהליך העבודה

1. ניתוח: אילו דומיינים אתה משתמש, אילו רשומות נדרשות, האם DNSSEC זמין אצל הרשם.
2. תכנון: ארכיטקטורת אזורים (ציבורי/פרטי), תכנית רשתות משנה עבור אזורים פרטיים.
3. יישום: קוד Terraform, ייבוא רשומות קיימות, הגדרת external-dns.
4. בדיקות: אימות פתרון, פעולת DNSSEC (dnssec-verify), מעברי כשל.
5. פריסה: עדכון רשומות NS אצל הרשם, ניטור דרך Cloud Monitoring + Grafana.

לוחות זמנים משוערים

• אזור ציבורי עם DNSSEC ורשומות בסיסיות: מ-4 שעות.
• אזור פרטי עם אינטגרציית external-dns עבור GKE: מיום אחד.
• הגדרה מורכבת (העברת כל האזורים + אוטומציה): מ-3 ימים.

מה כלול בעבודה

• יצירת אזורים ציבוריים ופרטיים עם הרשומות הנדרשות (A, AAAA, CNAME, MX, TXT, SRV).
• הפעלת DNSSEC וביקורת ציבורית של חתימות.
• הגדרת external-dns עבור Kubernetes (GKE).
• מודולי Terraform לניהול אזורים כקוד.
• תיעוד: סכמת DNS, הוראות להוספת רשומות, runbook לאירועים.
• הכשרת הצוות שלך לעבודה עם Cloud DNS.
• תמיכה למשך שבועיים לאחר הפריסה.

למה לסמוך עלינו

יש לנו 5 שנות ניסיון ב-DevOps ו-SRE, עם למעלה מ-20 פרויקטים מוצלחים של העברת DNS ל-GCP. המהנדסים שלנו מחזיקים בהסמכות Google Cloud Professional DevOps Engineer. אנו מבטיחים יציבות: כל השינויים עוברים בדיקת קוד ואזורי בדיקה.

אנחנו מוכנים לדון בפרויקט שלך. צור קשר לקבלת ייעוץ. הזמן הגדרת Google Cloud DNS וקבל ניהול DNS שקוף ללא כאבי ראש.