ניהול DNS ב-Google Cloud: Cloud DNS, DNSSEC, אזורים פרטיים

ניהול DNS ב-Google Cloud: Cloud DNS, DNSSEC, Private Zones

הגיע אלינו לקוח עם בעיה: לאחר מעבר ל-GCP, חלק מהשירותים הפנימיים הפסיקו להיפתר, וחלק מהדומיינים דלפו לאינטרנט. התברר שאזורי ה-DNS נוצרו כציבוריים, למרות שהיו צריכים להיות פרטיים. ארגנו מחדש את הארכיטקטורה ביום אחד, תוך ביטול סיכוני אבטחה ועלויות מיותרות.

Cloud DNS הוא לא רק העברת אזור ל-GCP. זהו שירות DNS מנוהל מסוג anycast עם SLA של 100%, אינטגרציה עם IAM, תמיכה ב-DNSSEC, ואזורים פרטיים לניתוב פנימי. השאלה היא האם הכל מוגדר נכון. הקמנו DNS ב-GCP באופן מלא: מאזורים פשוטים ועד טופולוגיות היברידיות עם forwarding ו-split-horizon.

כיצד Cloud DNS פותר דליפת DNS ברשתות היברידיות

אחת הטעויות הנפוצות ביותר היא אזור ציבורי לדומיין פנימי כמו 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 לא יעבוד והאזור ייחשב כלא חתום.

למה להשתמש ב-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."]
}

עבור רשומות A המצביעות על מאזני עומס עם backends המשתנים תדיר, אנחנו שומרים על TTL של 60–300 שניות. עבור MX ו-NS, אנו משתמשים ב-3600 ומעלה.

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

Split-Horizon DNS לסביבות היברידיות

אם יש לך Cloud VPN או Interconnect לאתר מקומי, אתה צריך תצורת 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

בקשות ל-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 יועברו לשרת ה-DNS הארגוני 10.0.0.53 דרך מנהרת ה-VPN.

ניטור DNS: מה לעקוב?

עבור סביבות production, קריטי להגדיר ניטור שאילתות DNS דרך Cloud Monitoring. מדדים מומלצים: מספר שאילתות לדקה, אחוז שגיאות (NXDOMAIN, SERVFAIL), זמן תגובה. אם חריגה מסף (למשל, >5% שגיאות), מופעלת התראה. SLA של 100% על Cloud DNS אינו פתרון קסם — תצורת אזור שגויה יכולה להוביל לחוסר זמינות שירות. לכן, אנחנו גם מגדירים לוחות מחוונים ב-Grafana עם Loki לרישום שינויי אזורים.

התאוששות מאסון עבור DNS

יתירות DNS כוללת יצירת אזורי גיבוי ו-DNS משני דרך gcloud dns managed-zones create public-zone \ --dns-name="company.com." \ --description="Public zone" \ --visibility=public \ --dnssec-state=on עם 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."] } ואזור מנוהל נפרד. במקרה של תקלה, אנו מעבירים תנועה אוטומטית לאזור הגיבוי. אנו בודקים failover כל 6 חודשים.

מה כלול בהקמת Cloud DNS?

• ביקורת תשתית DNS קיימת — זיהוי אזורים, רשומות, תלויות.
• עיצוב ארכיטקטורה — קביעת אזורים פרטיים/ציבוריים, DNSSEC, split-horizon.
• יישום דרך IaC — Terraform או Pulumi עם סקירת קוד.
• העברה תוך שמירה על השירות — ללא השבתה על ידי הפחתת TTL הדרגתית.
• תיעוד — סכמת DNS, תיאורי אזורים, הוראות לצוות.
• הכשרת מהנדסים — עבודה עם Cloud DNS, תרחישים אופייניים.
• תמיכה לאחר השקה — שבועיים של ניטור והתאמות.

תהליך עבודה

1. ניתוח — קבלת גישה ל-GCP, לימוד הרשת הנוכחית, Kubernetes, CI/CD.
2. עיצוב — יצירת סכמת אזורי DNS, הגדרת תפקידים ומדיניות IAM.
3. יישום — כתיבת מודולי Terraform, פריסה בסביבת בדיקות.
4. בדיקות — אימות פתרון שמות מ-VPC, מהאינטרנט, אימות DNSSEC.
5. פריסה — יישום ל-production עם פריסה הדרגתית (canary).
6. ניטור — הגדרת התראות לשגיאות DNS (למשל, דרך Cloud Monitoring).

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

לוח זמנים משוער: משעתיים לאזור ציבורי פשוט ועד 3 ימים לטופולוגיה היברידית מורכבת עם אזורים מפוצלים ו-DNSSEC. העלות מחושבת באופן אישי — תלויה במספר האזורים, הרשומות והאינטגרציות. נבחן את הפרויקט שלך, צור קשר!

טעויות נפוצות ורשימת בדיקה

• DNSSEC לא מופעל — האזור נשאר לא חתום, אפשריות התקפות.
• דומיין פנימי פורסם — נוצר אזור ציבורי עבור internal.company.com.
• שכחו את ה-TTL — לקוחות מקבלים IP ישן לאורך זמן לאחר שינוי.
• אין ניטור — תקלת DNS יכולה להיעלם מעין עד לאירוע.
• TTL זהה לכל הרשומות — עדיף להבדיל: 60-300 שניות לרשומות A עם LB, 3600+ עבור MX, 86400 עבור NS.

הגדרנו DNS לפרויקטים עם למעלה ממיליון שאילתות ביום. הניסיון שלנו: 10+ שנים ב-GCP, Google Cloud Architects מוסמכים. אנו מבטיחים SLA של 100% על זמן תגובה של Cloud DNS. קבל ייעוץ — צור קשר!