סקירה כללית על אזורי DNS

‫Cloud DNS תומך בסוגים שונים של תחומים (zones) פרטיים. במסמך הזה מפורטים סוגים שונים של אזורים ומתי אפשר להשתמש בסוג אחד או בסוג אחר.

אזורי העברה

אזורי העברה ב-Cloud DNS מאפשרים להגדיר שרתי שמות יעד לאזורים פרטיים ספציפיים. אחת הדרכים להטמיע העברת DNS יוצאת מרשת ה-VPC היא באמצעות אזור העברה.

אזור העברה ב-Cloud DNS הוא סוג מיוחד של אזור פרטי ב-Cloud DNS. במקום ליצור רשומות בתוך האזור, מציינים קבוצה של יעדי העברה. כל יעד להעברה הוא שם דומיין שמוגדר במלואו (FQDN) או כתובת IP של שרת DNS, שנמצא ברשת ה-VPC או ברשת מקומית שמחוברת לרשת ה-VPC באמצעות Cloud VPN או Cloud Interconnect.

יעדי העברה ושיטות ניתוב

‫Cloud DNS תומך בארבעה סוגים של יעדים ומציע שיטות ניתוב רגילות או פרטיות לקישוריות.

יעד ההעברה תיאור הניתוב הרגיל תומך ב תמיכה בניתוב פרטי מקור הבקשות
סוג 1 כתובת IP פנימית של Cloud de Confiance מכונה וירטואלית או של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי באותה רשת VPC שקיבלה הרשאה להשתמש באזור ההעברה. רק כתובות IP מסוג RFC 1918 – התנועה תמיד מנותבת דרך רשת VPC מורשית. כל כתובת IP פנימית, כמו כתובת פרטית מסוג RFC 1918, כתובת IP פרטית שאינה מסוג RFC 1918 או כתובת IP חיצונית שנעשה בה שימוש חוזר באופן פרטי, למעט כתובת IP של יעד העברה אסור – התעבורה תמיד מנותבת דרך רשת VPC מורשית. 177.222.82.0/25
Type 2 כתובת IP של מערכת מקומית שמחוברת לרשת ה-VPC שאושרה לשליחת שאילתות לאזור ההעברה, באמצעות Cloud VPN או Cloud Interconnect. רק כתובות IP מסוג RFC 1918 – התנועה תמיד מנותבת דרך רשת VPC מורשית. כל כתובת IP פנימית, כמו כתובת פרטית מסוג RFC 1918, כתובות IP פרטיות שאינן מסוג RFC 1918 או כתובת IP חיצונית שנעשה בה שימוש חוזר באופן פרטי, למעט כתובת IP של יעד העברה אסורה – התעבורה תמיד מנותבת דרך רשת VPC מורשית. 177.222.82.0/25
סוג 4 שם דומיין שמוגדר במלואו של שרת שמות יעד שיכול להגיע לכתובות IPv4 ו-IPv6 דרך סדר ההחלטה של רשת ה-VPC. בהתאם לרשת של יעד ההעברה שנפתר, התנועה מנותבת באחת משתי דרכים:
  • כתובות IP מסוג RFC 1918 – התעבורה תמיד מנותבת דרך רשת VPC מורשית.
  • כתובות IP חיצוניות שניתנות לניתוב באינטרנט – תעבורת הנתונים תמיד מנותבת לאינטרנט או לכתובת ה-IP החיצונית של משאב ב- Cloud de Confiance .

בהתאם לרשת של יעד ההעברה שזוהה, התעבורה מנותבת דרך כל כתובת IP פנימית, כמו כתובת פרטית מסוג RFC 1918, כתובת IP פרטית שאינה מסוג RFC 1918 או כתובת IP חיצונית שנעשה בה שימוש חוזר באופן פרטי, למעט כתובת IP של יעד העברה שאסור להשתמש בה – התעבורה תמיד מנותבת דרך רשת VPC מורשית.

אם שרת שמות ה-DNS הומר לכתובת IP חיצונית שאפשר לגשת אליה באינטרנט או לכתובת IP חיצונית, לא תהיה תמיכה בניתוב פרטי.

כשמוסיפים את יעד ההעברה לאזור ההעברה, אפשר לבחור באחת משתי שיטות הניתוב הבאות:

  • ניתוב רגיל: התנועה מנותבת דרך רשת VPC מורשית או דרך האינטרנט, בהתאם לשאלה אם יעד ההעברה הוא כתובת IP לפי RFC 1918. אם יעד ההעברה הוא כתובת IP מסוג RFC 1918,‏ Cloud DNS מסווג את היעד כיעד מסוג 1 או מסוג 2, ומנתב בקשות דרך רשת VPC מורשית. אם היעד הוא לא כתובת IP מסוג RFC 1918, שירות Cloud DNS מסווג את היעד כסוג 3, ומצפה שהיעד יהיה נגיש לאינטרנט.

  • ניתוב פרטי: הניתוב תמיד מתבצע דרך רשת VPC מורשית, ללא קשר לכתובת ה-IP של היעד (RFC 1918 או לא). לכן, יש תמיכה רק ביעדים מסוג 1 ומסוג 2.

אם משתמשים ב-FQDN ליעד ההעברה, שיטת הניתוב צריכה להתאים לסוג הרשת. כששרת השמות של הדומיין מזהה כתובת IP ציבורית, צריך להשתמש בניתוב רגיל.

כדי לגשת ליעד העברה מסוג 1 או מסוג 2, ‏ Cloud DNS משתמש בנתיבים ברשת ה-VPC המורשית שבה נמצא לקוח ה-DNS. המסלולים האלה מגדירים נתיב מאובטח ליעד ההעברה:

הנחיות נוספות לגבי דרישות הרשת ליעדים מסוג 1 ומסוג 2 זמינות במאמר דרישות הרשת של יעד ההעברה.

כדי לגשת ליעד העברה מסוג 4, מערכת Cloud DNS קודם מבצעת המרה של שם הדומיין, ואז משתמשת בשיטת הניתוב של רשת המקור. לדוגמה, אם subdomain.example.com מומר לכתובת IP של מערכת מקומית שמחוברת לרשת ה-VPC ומורשית לשלוח שאילתות לאזור ההעברה דרך Cloud VPN, המערכת משתמשת באותם כללי ניתוב כמו יעד העברה מסוג 2.

כשמשתמשים בשם דומיין מלא (FQDN) כיעד להעברה, אפשר להשתמש רק באחד. יעד ההעברה יכול להפוך לעד 50 כתובות IP.

כתובות IP אסורות של יעדי העברה

אי אפשר להשתמש בכתובות ה-IP הבאות כיעדים להעברה ב-Cloud DNS:

  • 169.254.0.0/16
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 224.0.0.0/4
  • 240.0.0.0/4
  • ::1/128
  • ::/128
  • 2001:db8::/32
  • fe80::/10
  • fec0::/10
  • ff00::/8

סדר הבחירה של יעדי ההעברה

‫Cloud DNS מאפשר להגדיר רשימה של יעדי העברה לאזור העברה.

כשמגדירים שני יעדי העברה או יותר, Cloud DNS משתמש באלגוריתם פנימי כדי לבחור יעד העברה. האלגוריתם הזה מדרג כל יעד להעברה.

כשמשתמשים ב-FQDN כיעד להעברה, Cloud DNS מבצע המרה של שם הדומיין לקבוצה של עד 50 כתובות IP, ואז מפעיל את אותו אלגוריתם על כתובות ה-IP האלה.

כדי לעבד בקשה, Cloud DNS מנסה קודם לבצע שאילתת DNS על ידי פנייה ליעד ההעברה עם הדירוג הגבוה ביותר. אם השרת הזה לא מגיב, Cloud DNS חוזר על הבקשה אל יעד ההעברה הבא בדירוג. אם אף אחד מיעדי ההעברה לא מגיב, Cloud DNS יוצר תגובה מסוג SERVFAIL.

אלגוריתם הדירוג הוא אוטומטי, והגורמים הבאים מעלים את הדירוג של יעד ההעברה:

  • ככל שמספר התשובות המוצלחות של DNS שעובדו על ידי יעד ההעברה גבוה יותר. תשובות DNS מוצלחות כוללות תשובות NXDOMAIN.
  • ככל שזמן האחזור (זמן הלוך ושוב) של התקשורת עם יעד ההעברה נמוך יותר.

שימוש באזורי העברה

מכונות וירטואליות ברשת VPC יכולות להשתמש באזור העברה של Cloud DNS במקרים הבאים:

  • הרשאת השימוש ברשת ה-VPC ניתנה לאזור ההעברה של Cloud DNS. כדי להשתמש באזור ההעברה, אתם יכולים להעניק הרשאה לכמה רשתות VPC באותו פרויקט או בפרויקטים שונים, כל עוד רשתות ה-VPC נמצאות באותו ארגון.

  • מערכת ההפעלה של האורח בכל מכונה וירטואלית ברשת ה-VPC משתמשת בשרת המטא-נתונים של המכונה הווירטואלית 169.254.169.254 כשרת השמות שלה.

אם אתם משתמשים ב-FQDN כשרת השמות של היעד, כדאי לבדוק את הפריטים הבאים:

  • אפשר להגדיר רק יעד אחד להעברה.
  • אין תמיכה בפתרון של יעד FQDN דרך אזור העברה אחר.
  • אי אפשר להשתמש ב-FQDN כשרת שמות חלופי במדיניות שרתים.
  • יעד FQDN יכול להתפרש כעד 50 כתובות IP משויכות. אם יש יותר מ-50 כתובות שנפתרו, הן ייחתכו.

אזורי העברה חופפים

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

אזורים של שמירה במטמון והעברה

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

  • ‫60 שניות
  • משך הזמן של אורך החיים (TTL) של הרשומה

כשכל יעדי ההעברה של אזור העברה הופכים ללא נגישים, Cloud DNS שומר את המטמון של הרשומות שנדרשו קודם באותו אזור למשך הזמן של ה-TTL של כל רשומה.

מתי כדאי להשתמש ב-peering

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

  • השתמשתם ב-Cloud VPN או ב-Cloud Interconnect כדי לחבר רשת מקומית לרשת VPC בשם vpc-net-a.

  • השתמשתם בקישור בין רשתות VPC שכנות (peering) כדי לקשר בין רשת ה-VPC‏ vpc-net-a לבין vpc-net-b. הגדרתם את vpc-net-a לייצוא של מסלולים מותאמים אישית, ואת vpc-net-b לייבוא שלהם.

  • יצרתם אזור העברה שמטרות ההעברה שלו נמצאות ברשת המקומית שאליה vpc-net-a מחובר. נתת הרשאה ל-vpc-net-b להשתמש באזור ההעברה הזה.

פתרון רשומה באזור שמוגש על ידי יעדי ההעברה נכשל בתרחיש הזה, למרות שיש קישוריות מ-vpc-net-b לרשת המקומית שלכם. כדי להדגים את הכשל הזה, מבצעים את הבדיקות הבאות ממכונה וירטואלית ב-vpc-net-b:

  • מריצים שאילתה על שרת המטא-נתונים של המכונה הווירטואלית 169.254.169.254 כדי למצוא רשומה שהוגדרה באזור ההעברה. השאילתה הזו נכשלת (כצפוי) כי ב-Cloud DNS אין תמיכה בניתוב טרנזיטיבי ליעדי העברה. כדי להשתמש באזור העברה, צריך להגדיר מכונה וירטואלית כך שתשתמש בשרת המטא-נתונים שלה.

  • שולחים שאילתה ישירות ליעד ההעברה לגבי הרשומה הזו. למרות ש-Cloud DNS לא משתמש בנתיב הזה, השאילתה הזו מדגימה שהקישוריות הטרנזיטיבית מצליחה.

כדי לתקן את התרחיש הלא תקין הזה, אפשר להשתמש באזור peering של Cloud DNS:

  1. יוצרים תחום (zone) של Cloud DNS עם שירותי Peering שמוסמך ל-vpc-net-b ומכוון ל-vpc-net-a.
  2. יוצרים אזור העברה שמוסמך ל-vpc-net-a, והיעדים של ההעברה הם שרתי שמות מקומיים.

אפשר לבצע את השלבים האלה בכל סדר. אחרי שתשלימו את השלבים האלה, מכונות של Compute Engine ב-vpc-net-a וב-vpc-net-b יוכלו לשלוח שאילתות ליעדי ההעברה המקומיים.

מידע על יצירת אזורי העברה זמין במאמר יצירת אזור העברה.

אזורי קישור בין רשתות שכנות (peering)

אזור peering הוא אזור פרטי ב-Cloud DNS שמאפשר לשלוח בקשות DNS בין אזורים ב-Cloud DNS ברשתות VPC שונות. לדוגמה, ספק של תוכנה כשירות (SaaS) יכול לתת ללקוחות גישה לרשומות DNS מנוהלות ב-Cloud DNS.

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

אזור ה-peering גלוי רק לרשתות VPC שנבחרו במהלך הגדרת האזור. רשת ה-VPC שמורשית להשתמש באזור ה-peering נקראת רשת צרכנית DNS.

אחרי שמאשרים את המשאבים ברשת צרכני ה-DNS, הם יכולים לבצע חיפושים של רשומות במרחב השמות של אזור קישור בין רשתות שכנות (peering) כאילו הם נמצאים ברשת יצרני ה-DNS. Cloud de Confiance חיפושים של רשומות במרחב השמות של אזור הקישור בין רשתות שכנות (peering) מתבצעים לפי סדר תרגום שם (name resolution) של רשת יצרן ה-DNS.

לכן,משאבי Cloud de Confiance ברשת הצרכנית של DNS יכולים לחפש רשומות במרחב השמות של האזור מהמקורות הבאים שזמינים ברשת היצרנית של DNS:

  • תחומים פרטיים מנוהלים ב-Cloud DNS שמורשים לשימוש ברשת של יצרן ה-DNS.
  • תחומי העברה מנוהלים של Cloud DNS שמורשים לשימוש על ידי רשת יצרן ה-DNS.
  • שמות DNS פנימיים של Compute Engine ברשת של ספק ה-DNS.
  • שרת שמות חלופי, אם הוגדרה מדיניות שרת יוצא ברשת של יצרן ה-DNS.

באמצעות DNS peering, רשת אחת (רשת צרכנית של DNS) יכולה להעביר בקשות DNS לרשת אחרת (רשת יצרנית של DNS), שמבצעת חיפושי DNS.

מגבלות ונקודות חשובות לגבי DNS Peering

כשמגדירים DNS Peering, חשוב לזכור את הנקודות הבאות:

  • קישור בין רשתות שכנות (peering) של DNS הוא קשר חד-כיווני. היא מאפשרת למשאבי Cloud de Confiance רשת צרכני ה-DNS לחפש רשומות במרחב השמות של אזור הקישור בין רשתות שכנות (peering) כאילו המשאבים Cloud de Confiance היו ברשת יצרני ה-DNS.
  • רשתות ה-DNS של הספק והצרכן חייבות להיות רשתות VPC.
  • בדרך כלל רשתות של בעלי תוכן וצרכנים של DNS הן חלק מאותו ארגון, אבל יש גם תמיכה בקישור בין רשתות שכנות (peering) של DNS בין ארגונים.
  • קישור בין רשתות DNS שכנות (peering) וקישור בין רשתות VPC שכנות (peering) הם שירותים שונים. שיתוף DNS לא מתבצע אוטומטית כשמפעילים קישור בין רשתות VPC שכנות (peering). אפשר להשתמש בקישור DNS עם קישור בין רשתות VPC שכנות, אבל לא צריך קישור בין רשתות VPC שכנות כדי להשתמש בקישור DNS.
  • יש תמיכה בקישור מעבר בין רשתות שכנות (peering) של DNS, אבל רק דרך צעד אחד של קישור מעבר. במילים אחרות, יכולות להיות מעורבות לכל היותר שלוש רשתות VPC (כשהרשת באמצע היא הניתור הטרנזיטיבי). לדוגמה, אפשר ליצור אזור peering ב-vpc-net-a שמטרגט את vpc-net-b, ואז ליצור אזור peering ב-vpc-net-b שמטרגט את vpc-net-c.
  • אם אתם משתמשים ב-DNS peering כדי לטרגט אזור העברה בזמן שניתוב דינמי גלובלי מושבת ברשת ה-VPC של היצרן, רשת ה-VPC של היעד עם אזור ההעברה צריכה להכיל מכונה וירטואלית, צירוף ל-VLAN או מנהרת Cloud VPN שנמצאים באותו אזור כמו המכונה הווירטואלית של המקור שמשתמשת באזור ה-DNS peering. לפרטים נוספים על המגבלה הזו, ראו העברת שאילתות ממכונות וירטואליות ברשת VPC של צרכן לרשת VPC של ספק לא פועלת.

הוראות ליצירת אזור peering מפורטות במאמר יצירת אזור peering.

אזורים חופפים

שני אזורים חופפים זה לזה כששם דומיין המקור של אזור אחד זהה למקור של האזור השני או שהוא תת-דומיין שלו. לדוגמה:

  • יש חפיפה בין האזור של gcp.example.com לבין האזור של gcp.example.com כי שמות הדומיין זהים.
  • יש חפיפה בין התחום של dev.gcp.example.com לבין התחום של gcp.example.com כי dev.gcp.example.com הוא תת-דומיין של gcp.example.com.

כללים לאזורים חופפים

ב-Cloud DNS נאכפים הכללים הבאים לגבי אזורים חופפים:

  • אזורים פרטיים בהיקף של רשתות VPC שונות יכולים לחפוף זה לזה. לדוגמה, יכולות להיות שתי רשתות VPC שלכל אחת מהן יש מכונה וירטואלית של מסד נתונים בשם database.gcp.example.com באזור gcp.example.com. שאילתות לגבי database.gcp.example.com מקבלות תשובות שונות בהתאם לרשומות האזור שהוגדרו באזור שהורשה לכל רשת VPC.

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

    • דוגמאות לפתרון שאילתות

    ‫Cloud de Confiance פותר אזורי Cloud DNS כפי שמתואר בסדר פתרון השמות. כשמנסים לקבוע את האזור שאליו צריך לשלוח שאילתה לגבי רשומה מסוימת, Cloud DNS מנסה למצוא אזור שתואם לכמה שיותר חלקים מהרשומה המבוקשת (התאמה של הסיומת הארוכה ביותר).

    אלא אם ציינתם שרת שמות חלופי במדיניות של שרת יוצא, Cloud de Confiance הניסיון הראשון למצוא רשומה באזור פרטי (או באזור העברה או באזור קישור בין רשתות שכנות (peering)) שאושר עבור רשת ה-VPC שלכם.

    קישור בין פרויקטים

    קישור בין פרויקטים מאפשר לכם לשמור על הבעלות על מרחב שמות ה-DNS של פרויקט השירות באופן עצמאי מהבעלות על מרחב שמות ה-DNS של רשת ה-VPC כולה.

    בדרך כלל, בהגדרה של VPC משותף יש פרויקטים של שירותים שמקבלים בעלות על אפליקציה או שירות של מכונה וירטואלית (VM), בעוד שהפרויקט המארח מקבל בעלות על רשת ה-VPC ותשתית הרשת. לרוב, מרחב שמות של DNS נוצר ממרחב השמות של רשת ה-VPC כדי להתאים למשאבים של פרויקט השירות. במקרים כאלה, יכול להיות שיהיה קל יותר להעביר את הניהול של מרחב שמות ה-DNS של כל פרויקט שירות לאדמינים של כל פרויקט שירות (שהם לרוב מחלקות או עסקים שונים). קישור בין פרויקטים מאפשר להפריד בין הבעלות על מרחב שמות ה-DNS של פרויקט השירות לבין הבעלות על מרחב שמות ה-DNS של רשת ה-VPC כולה.

    באיור הבא מוצגת הגדרה אופיינית של VPC משותף עם DNS Peering.

    הגדרת VPC משותף עם קישור DNS בין רשתות שכנות (peering).
    הגדרה של VPC משותף עם קישור DNS בין רשתות שכנות (peering) (לחצו להגדלה)

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

    הגדרה עם קישור בין פרויקטים.
    הגדרה עם קישור בין פרויקטים (לחצו כדי להגדיל)

    קישור בין פרויקטים מספק את היתרונות הבאים:

    • מנהלי מערכת ומשתמשים בפרויקט שירות יכולים ליצור ולנהל אזורי DNS משלהם.
    • אין צורך ליצור רשת VPC של placeholder.
    • אדמינים בפרויקט המארח לא צריכים לנהל את פרויקט השירות.
    • תפקידי IAM עדיין חלים ברמת הפרויקט.
    • כל אזורי ה-DNS משויכים ישירות לרשת ה-VPC המשותפת.
    • פענוח DNS מכל מקום לכל מקום זמין בקלות. כל מכונה וירטואלית ברשת ה-VPC המשותפת יכולה לפתור אזורים משויכים.
    • אין הגבלה על מספר הקפיצות המעברות. אפשר לנהל את זה במבנה של רכזת ונקודות הסתעפות.

    במאמר יצירת אזור עם קישור בין פרויקטים מוסבר איך ליצור אזור עם קישור בין פרויקטים.

    תחומי Cloud DNS אזוריים

    ‫Cloud DNS אזורי מאפשר לכם ליצור אזורי DNS פרטיים שמוגבלים לאזור מסוים. Cloud de Confiance אזורים של Cloud DNS נוצרים עבור GKE כשבוחרים היקף אשכול.

    שירות Cloud DNS שמוגדר כברירת מחדל הוא גלובלי, ושמות ה-DNS גלויים באופן גלובלי ברשת ה-VPC. ההגדרה הזו חושפת את השירות שלכם להפסקות שירות גלובליות. ‫Cloud DNS אזורי הוא שירות חדש של Cloud DNS פרטי שקיים בכל אזור. Cloud de Confiance דומיין הכשל נמצא בתוך אזור Cloud de Confiance . תחומים פרטיים ב-Cloud DNS ברמת אזור לא מושפעים כשמתרחשים שיבושים גלובליים. הפסקות שירות אזוריות משפיעות רק על האזור הספציפי ועל אזורי Cloud DNS באותו אזור. Cloud de Confiance Cloud de Confiance Cloud de Confiance חשוב לזכור שכל משאב שנוצר בשירות אזורי גלוי רק באותו אזור Cloud de Confiance.

    איך מגדירים אזור ב-Cloud DNS בהיקף של אשכול אזורי

    תמיכה ב-Cloud DNS אזורי

    בטבלה הבאה מפורטים המשאבים והתכונות של Cloud DNS שנתמכים על ידי שירותי Cloud DNS אזוריים.

    משאב או תכונה זמין ב-Cloud DNS גלובלי זמין ב-Cloud DNS אזורי
    תחומים פרטיים מנוהלים (בטווח רשת או VPC)
    אזורים פרטיים מנוהלים (בהיקף GKE)
    אזורי העברה1
    אזורי קישור בין רשתות שכנות (peering)
    אזורי חיפוש הפוך מנוהלים
    יצירת שינויים או ניהול רשומות2
    אזורים ב-Service Directory
    מדיניות
    מדיניות תגובה (במסגרת הרשת)
    מדיניות תגובה (בהיקף אשכול GKE)
    כללים של מדיניות התגובה

    ‫1Zonal Cloud DNS תומך רק בהעברת אזורים בהיקף של אשכול GKE.

    ‫2במהלך הפעלה מחדש של בקר GKE, הוא מחליף את כל השינויים ברשומות.

    חיוב על אזורים של Cloud DNS

    החיוב על תחומים אזוריים ב-Cloud DNS ועל מדיניות תגובה זהה לחיוב על תחומים גלובליים ב-Cloud DNS ועל מדיניות תגובה גלובלית.

    המאמרים הבאים