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

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

אזורי העברה

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

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

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

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

יעד ההעברה תיאור ניתוב רגיל תומך באפשרויות הבאות: תמיכה בניתוב פרטי מקור הבקשות
סוג 1 כתובת IP פנימית של Google Cloud VM או של מאזן עומסי רשת פנימי להעברת נתונים באותה רשת VPC שמורשית להשתמש באזור ההעברה. רק כתובות IP מסוג RFC 1918 – תעבורת הנתונים תמיד מנותבת דרך רשת VPC מורשית. כל כתובת IP פנימית, כמו כתובת פרטית מסוג RFC 1918, כתובת IP פרטית שאינה מסוג RFC 1918 או כתובת IP חיצונית בשימוש חוזר פרטי, למעט כתובת IP אסורה להעברת יעד – תעבורת הנתונים תמיד מנותבת דרך רשת VPC מורשית. ‫35.199.192.0/19 או טווח של רשת משנה לשרת proxy בלבד, אם משתמשים בנקודות קצה יוצאות (גרסת טרום-השקה (Preview))
סוג 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 או טווח של רשת משנה לשרת proxy בלבד, אם משתמשים בנקודות קצה יוצאות (גרסת טרום-השקה (Preview))
סוג 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 מבצע פענוח 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 לא תומך בניתוב טרנזיטיבי ליעדי העברה. כדי להשתמש באזור העברה, צריך להגדיר את ה-VM כך שישתמש בשרת המטא-נתונים שלו.

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

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

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

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

במאמר יצירת אזור העברה מוסבר איך יוצרים אזורי העברה.

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

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

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

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

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

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

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

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

מגבלות ונקודות עיקריות של קישור בין רשתות שכנות (peering) ב-DNS

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

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

במאמר יצירת תחום קישור בין רשתות שכנות מוסבר איך יוצרים תחום קישור בין רשתות שכנות.

תחומי DNS מנוהלים לחיפוש הפוך (reverse lookup zone)

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

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

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

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

במאמר יצירת תחום DNS לחיפוש הפוך (reverse lookup zone) מנוהל מוסבר איך יוצרים תחום DNS לחיפוש הפוך (reverse lookup zone) מנוהל.

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

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

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

  • שרת המטא-נתונים משתמש בשרתי שמות ציבוריים כדי לפתור רשומה של myapp.example.com. (שימו לב לנקודה בסוף), כי אין אזור פרטי של example.com שאושר לרשת ה-VPC. משתמשים ב-dig ממכונה וירטואלית של 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 המבוקשת לבין האזורים הפרטיים הזמינים.

דוגמה ל-Split horizon DNS

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

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

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

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

קישור בין פרויקטים מאפשר:

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

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

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

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

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

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

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

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

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

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

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

חיוב על אזורי Cloud DNS לפי אזור

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

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