סקירה כללית על תחומי 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 פנימית של Google Cloud מכונה וירטואלית או של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי באותה רשת VPC שקיבלה הרשאה להשתמש באזור ההעברה. רק כתובות IP מסוג RFC 1918 – התנועה תמיד מנותבת דרך רשת VPC מורשית. כל כתובת IP פנימית, כמו כתובת פרטית מסוג RFC 1918, כתובת IP פרטית שאינה מסוג RFC 1918 או כתובת IP חיצונית שנעשה בה שימוש חוזר באופן פרטי, למעט כתובת IP של יעד העברה אסור – התעבורה תמיד מנותבת דרך רשת VPC מורשית. 35.199.192.0/19
Type 2 כתובת IP של מערכת מקומית שמחוברת לרשת ה-VPC שאושרה לשליחת שאילתות לאזור ההעברה, באמצעות Cloud VPN או Cloud Interconnect. רק כתובות IP מסוג RFC 1918 – התנועה תמיד מנותבת דרך רשת VPC מורשית. כל כתובת IP פנימית, כמו כתובת פרטית מסוג RFC 1918, כתובות IP פרטיות שאינן מסוג RFC 1918 או כתובת IP חיצונית שנעשה בה שימוש חוזר באופן פרטי, למעט כתובת IP של יעד העברה אסורה – התעבורה תמיד מנותבת דרך רשת VPC מורשית. 35.199.192.0/19
סוג 3 כתובת IP חיצונית של שרת שמות דומיין (DNS) שאפשר לגשת אליו באינטרנט או כתובת IP חיצונית של משאב Google Cloud . לדוגמה, כתובת IP חיצונית של מכונה וירטואלית ברשת VPC אחרת. רק כתובות IP חיצוניות שניתנות לניתוב באינטרנט – תעבורת הנתונים תמיד מנותבת לאינטרנט או לכתובת ה-IP החיצונית של משאב Google Cloud . אין תמיכה בניתוב פרטי – מוודאים שלא נבחר ניתוב פרטי. טווחים של מקורות Google Public DNS
סוג 4 שם דומיין שמוגדר במלואו של שרת שמות יעד שיכול להגיע לכתובות IPv4 ו-IPv6 דרך סדר ההחלטה של רשת ה-VPC. בהתאם לרשת של יעד ההעברה שנפתר, התנועה מנותבת באחת משתי דרכים:
  • כתובות IP מסוג RFC 1918 – התעבורה תמיד מנותבת דרך רשת VPC מורשית.
  • כתובות IP חיצוניות שניתנות לניתוב באינטרנט – תעבורת הנתונים תמיד מנותבת לאינטרנט או לכתובת ה-IP החיצונית של משאב ב- Google Cloud .

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

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

אזורי חיפוש הפוך מנוהלים

אזור מנוהל של חיפוש הפוך הוא אזור פרטי עם מאפיין מיוחד שמורה ל-Cloud DNS לבצע חיפוש PTR מול נתוני ה-DNS של Compute Engine.

רשומות PTR לכתובות RFC 1918 באזורים פרטיים

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

דוגמאות לאזורים:

  • 10.in-addr.arpa.
  • 168.192.in-addr.arpa.
  • ‫16.172.in-addr.arpa., ‏ 17.172.in-addr.arpa.,‏ ... עד 31.172.in-addr.arpa.

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

לדוגמה, נניח שיוצרים אזור פרטי מנוהל בשביל in-addr.arpa. עם רשומת ה-PTR הבאה בשביל מכונה וירטואלית שכתובת ה-IP שלה היא 10.1.1.1:

1.1.1.10.in-addr.arpa. -> test.example.domain

בדוגמה הזו, רשומת ה-PTR באזור הפרטי של Cloud DNS עבור in-addr.arpa. מתעלמת. כל שאילתות ה-PTR עבור 1.1.1.10.in-addr.arpa. נענות על ידי תחום ה-DNS הפנימי הספציפי יותר 10.in-addr.arpa..

כדי לבטל את רשומות ה-PTR של ה-DNS הפנימי שנוצרות באופן אוטומטי למכונות וירטואליות, צריך לוודא שיוצרים רשומות PTR בהתאמה אישית באזור פרטי שהוא לפחות ספציפי כמו אחד מהאזורים שמוצגים בסעיף הזה. לדוגמה, אם יוצרים את רשומת ה-PTR הבאה באזור פרטי בשביל 10.in-addr.arpa., הרשומה מחליפה את הרשומה שנוצרה אוטומטית: 1.1.1.10.in-addr.arpa. -> test.example.domain.

אם אתם צריכים לבטל רק חלק מחסימת רשת, אתם יכולים ליצור תחומים פרטיים ספציפיים יותר ב-Cloud DNS. לדוגמה, אפשר להשתמש באזור פרטי של 5.10.in-addr.arpa. כדי להחזיק רשומות PTR שמבטלות רשומות PTR פנימיות של DNS שנוצרות באופן אוטומטי למכונות וירטואליות עם כתובות IP בטווח הכתובות 10.5.0.0/16.

הוראות ליצירת אזור מנוהל של חיפוש הפוך מפורטות במאמר יצירה של אזור מנוהל של חיפוש הפוך.

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

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

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

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

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

  • אזור פרטי יכול לחפוף לכל אזור ציבורי.

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

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

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

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

אלא אם ציינתם שרת שמות חלופי במדיניות של שרת יוצא, Google Cloud הניסיון הראשון למצוא רשומה באזור פרטי (או באזור העברה או באזור קישור בין רשתות שכנות (peering)) שאושר עבור רשת ה-VPC שלכם לפני החיפוש של הרשומה באזור ציבורי. בדוגמאות הבאות מוסבר הסדר שבו שרת המטא-נתונים משתמש כשמריצים שאילתות על רשומות DNS. בכל אחת מהדוגמאות האלה, נניח שיצרתם שני אזורים פרטיים, gcp.example.com ו-dev.gcp.example.com, והענקתם הרשאת גישה אליהם מאותה רשת VPC. Google Cloudמטפל בשאילתות DNS ממכונות וירטואליות ברשת VPC באופן הבא:

  • שרת המטא-נתונים משתמש בשרתי שמות ציבוריים כדי לפתור רשומה עבור myapp.example.com. (שימו לב לנקודה בסוף) כי אין אזור פרטי עבור example.com שאושר לרשת ה-VPC. משתמשים בפקודה dig ממכונת VM ב-Compute Engine כדי לבצע שאילתה בשרת השמות שמוגדר כברירת מחדל למכונה הווירטואלית:

    dig myapp.example.com.

    פרטים נוספים זמינים במאמר בנושא שאילתה לשם DNS באמצעות שרת המטא-נתונים.

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

  • באופן דומה, שאילתות לגבי myapp.dev.gcp.example.com נפתרות בהתאם לרשומות באזור הפרטי המורשה dev.gcp.example.com. הערך NXDOMAIN מוחזר אם אין רשומה עבור myapp.dev.gcp.example.com באזור dev.gcp.example.com, גם אם יש רשומה עבור myapp.dev.gcp.example.com באזור פרטי או ציבורי אחר.

  • שאילתות לגבי myapp.prod.gcp.example.com מפוענחות לפי רשומות באזור הפרטי gcp.example.com כי gcp.example.com הוא הסיומת המשותפת הארוכה ביותר בין רשומת ה-DNS המבוקשת לבין האזורים הפרטיים הזמינים.

דוגמה ל-DNS עם אופק מפוצל

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

דוגמה ל-split horizon:

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

באזור הפרטי, יצרתם רשומה אחת כמו שמוצג בטבלה הבאה.

הקלטה סוג TTL (בשניות) נתונים
myrecord1.gcp.example.com A 5 10.128.1.35

באזור הציבורי, יצרתם שתי רשומות.

הקלטה סוג TTL (בשניות) נתונים
myrecord1.gcp.example.com A 5 104.198.6.142
myrecord2.gcp.example.com A 50 104.198.7.145

השאילתות הבאות נפתרות כפי שמתואר:

  • שאילתה לגבי myrecord1.gcp.example.com ממכונה וירטואלית ברשת ה-VPC מחזירה 10.128.1.35.
  • שאילתה לגבי myrecord1.gcp.example.com מהאינטרנט מחזירה 104.198.6.142.
  • שאילתה לגבי myrecord2.gcp.example.com ממכונה וירטואלית ברשת ה-VPC מחזירה שגיאת NXDOMAIN כי אין רשומה לגבי myrecord2.gcp.example.com באזור הפרטי gcp.example.com.
  • שאילתה לגבי myrecord2.gcp.example.com מהאינטרנט מחזירה 104.198.7.145.

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

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

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

איך מגדירים אזור ב-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 ועל מדיניות תגובה גלובלית.

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