סקירה כללית על תחומי DNS

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

אזורי העברה

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

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

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

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

יעד להעברה	תיאור	תמיכה בניתוב רגיל	תמיכה במסלולי ניתוב פרטיים	מקור הבקשות
סוג 1	כתובת IP פנימית של מכונה וירטואלית מסוג Trusted Cloud או של מאזן עומסים פנימי של Network Load Balancer עם תעבורה ישירה באותה רשת VPC, עם הרשאה להשתמש באזור ההעברה.	רק כתובות IP מסוג RFC 1918 – תעבורת הנתונים תמיד מנותבת דרך רשת VPC מורשית.	כל כתובת IP פנימית, כמו כתובת פרטית מסוג RFC 1918, כתובות IP פרטיות שאינן מסוג RFC 1918 או כתובת IP חיצונית שנעשה בה שימוש חוזר באופן פרטי, מלבד כתובת IP של יעד העברה אסור – תעבורת הנתונים תמיד מנותבת דרך רשת VPC מורשית.	177.222.82.0/25
סוג 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 החיצונית של Trusted Cloud משאב.	בהתאם לרשת של יעד ההעברה המאומת, התנועה מנותבת דרך כל כתובת IP פנימית, כמו כתובת פרטית מסוג RFC 1918, כתובת IP פרטית שאינה מסוג RFC 1918 או כתובת IP חיצונית שנעשה בה שימוש חוזר באופן פרטי, מלבד כתובת IP אסורה של יעד העברה. התנועה תמיד מנותבת דרך רשת VPC מורשית. אם שרת השמות של ה-DNS נפתר לכתובת IP חיצונית שגלויה לאינטרנט או לכתובת ה-IP החיצונית, אין תמיכה בניתוב פרטי.	177.222.82.0/25 טווחי מקור של Google Public DNS

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

• ניתוב רגיל: ניתוב התנועה דרך רשת VPC מורשית או דרך האינטרנט, בהתאם ליעד ההעברה (forwarding) – כתובת 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, Cloud DNS משתמש בנתיבי תת-רשת שנוצרים באופן אוטומטי. כדי להשיב, יעדים מסוג 1 משתמשים בנתיב ניתוב מיוחד לתשובות של Cloud DNS.

• כדי לשלוח תעבורת נתונים ליעדים מסוג 2, Cloud DNS יכול להשתמש בנתיבים דינמיים מותאמים אישית או בנתיבים סטטיים מותאמים אישית, מלבד נתיבים סטטיים מותאמים אישית עם תגי רשת. כדי להשיב, יעדי העברה מסוג 2 משתמשים במסלולים ברשת המקומית.

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

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

כשמשתמשים ב-FQDN כיעד להעברה, אפשר להשתמש רק ב-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 של רשומה.

מתי כדאי להשתמש בקישור ישיר במקום זאת

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

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

1. יוצרים תחום של Cloud DNS peering עם הרשאה ל-vpc-net-b שמטרגט את vpc-net-a.
2. יוצרים תחום העברה עם הרשאה ל-vpc-net-a, שבו יעדי ההעברה הם שרתי שמות מקומיים.

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

מידע נוסף על יצירת תחומי העברה זמין במאמר יצירת תחום העברה.

תחומי קישור בין רשתות שכנות (peering)

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

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

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

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

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

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

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

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

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

• קישורי DNS הם קשר חד-כיווני. הוא מאפשר ל Trusted Cloud משאבים ברשת של צרכן ה-DNS לחפש רשומות במרחב השמות של תחום ה-peering כאילו Trusted Cloud המשאבים נמצאים ברשת של יצרן ה-DNS.
• הרשתות של הבעלים והצרכן של ה-DNS חייבות להיות רשתות VPC.
• בדרך כלל, רשתות של יצרני DNS ושל צרכני DNS הן חלק מאותו ארגון, אבל יש גם תמיכה בקישור בין רשתות DNS בארגונים שונים.
• קישור בין רשתות DNS וקישור בין רשתות VPC שכנות (peering) הם שירותים שונים. קישור בין רשתות VPC שכנות (peering) לא משתף באופן אוטומטי פרטי DNS. אפשר להשתמש בקישור בין רשתות VPC שכנות (peering) עם קישור DNS, אבל לא נדרש קישור בין רשתות VPC שכנות כדי ליצור קישור DNS.
• יש תמיכה בקישור מעבר בין רשתות שכנות (peering) של DNS, אבל רק דרך צעד מעבר יחיד. במילים אחרות, לא יכולות להיות מעורבות יותר משלוש רשתות VPC (הרשת שבאמצע היא הקפיצה הטרנזיטיבית). לדוגמה, אפשר ליצור תחום peering ב-vpc-net-a שמטרגט את vpc-net-b, ואז ליצור תחום peering ב-vpc-net-b שמטרגט את vpc-net-c.
• אם אתם משתמשים בקישור DNS כדי לטרגט תחום העברה בזמן שהניתוב הדינמי הגלובלי מושבת ברשת ה-VPC של הבעלים, רשת ה-VPC היעד עם תחום ההעברה חייבת להכיל מכונה וירטואלית, צירוף VLAN או מנהרה של Cloud VPN שנמצאים באותו אזור כמו המכונה הווירטואלית המקורית שמשתמשת בתחום הקישור של ה-DNS. לפרטים נוספים על המגבלה הזו, ראו העברת שאילתות ממכונות וירטואליות ברשת 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 לא יכולים להיות מקורות זהים, אלא אם אחד מהתחומים הוא תת-דומיין של השני. שרת המטא-נתונים משתמש בהתאמה של הסיומת הארוכה ביותר כדי לקבוע באיזה מקור יש להריץ שאילתה לגבי רשומות באזור נתון.

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

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

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

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

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

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

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

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

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

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

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

תחומים של Cloud DNS ברמת האזור

באמצעות Zonal Cloud DNS אפשר ליצור תחומי DNS פרטיים ברמת Trusted Cloud התחום בלבד. תחומים של Cloud DNS ברמת האזור נוצרים ב-GKE כשבוחרים בהיקף של האשכולות.

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

במאמר הגדרת תחום ברמת האזור ב-GKE מוסבר איך מגדירים תחום ברמת האזור ב-Cloud DNS.

תמיכה ב-Cloud DNS ברמת תחום

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

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

¹Cloud DNS אזורי תומך רק באזורי העברה ברמת האשכולות של GKE.

²בזמן ההפעלה מחדש, בקר GKE מחליף את כל השינויים ברשומות.

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

החיוב על תחומים (zones) של Cloud DNS ועל כללי תגובה ברמת תחום פועל באותו אופן כמו החיוב על אלה ברמת החשבון.

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

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