מדיניות שרת DNS

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

אפשר גם להגדיר DNS64 כדי לאפשר למכונות וירטואליות עם IPv6 בלבד לתקשר עם יעדים עם IPv4 בלבד.

רשתות משנה של VPC עם IPv6 בלבד לא תומכות בכללי מדיניות של שרת DNS נכנס. עם זאת, אתם יכולים להגדיר כללי מדיניות של שרת DNS יוצא למכונות וירטואליות עם IPv6 בלבד.

כללי מדיניות לשרתים נכנסים

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

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

כשיוצרים מדיניות שרתים לתעבורה נכנסת, Cloud DNS יוצר נקודות כניסה למדיניות שרתים לתעבורה נכנסת ברשת ה-VPC שעליה חלה מדיניות השרתים. נקודות הכניסה של מדיניות השרתים לתעבורה נכנסת הן כתובות IPv4 פנימיות שמקורן בטווח הכתובות הראשי של IPv4 של כל רשת משנה ברשת ה-VPC הרלוונטית, חוץ מרשתות משנה עם נתוני --purpose ספציפיים, כמו רשתות משנה של שרתי proxy בלבד למאזני עומסים מסוימים ורשתות משנה שמשמשות את Cloud NAT ל-Private NAT.

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

במאמר יצירת מדיניות שרת נכנס מוסבר איך יוצרים מדיניות שרת נכנס ל-VPC.

רשת ואזור לשאילתות נכנסות

כדי לעבד שאילתות DNS שנשלחות לנקודות כניסה של מדיניות שרתים נכנסים, Cloud DNS משייך את השאילתה לרשת VPC ולאזור:

  • רשת ה-VPC שמשויכת לשאילתת DNS היא רשת ה-VPC שמכילה את מנהרת Cloud VPN, את הצירוף ל-VLAN של Cloud Interconnect או את ממשק הרשת של הנתב הווירטואלי שמקבל את החבילות של שאילתת ה-DNS.

    • ‫Google ממליצה ליצור מדיניות שרת נכנס ברשת ה-VPC שמחוברת לרשת המקומית. כך נקודות הכניסה של מדיניות השרת הנכנס נמצאות באותה רשת VPC כמו מנהרות Cloud VPN, חיבורי VLAN של Cloud Interconnect או נתבים וירטואליים שמחוברים לרשת המקומית.

    • אי אפשר להגיע לכתובות ה-IP של העברת DNS נכנסת דרך הגבולות של VPC Network Peering או של Network Connectivity Center ‏ (NCC), ונדרשת מדיניות מקומית. כדי לפתור את הבעיה, צריך לבצע את הפעולות הבאות:

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

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

  • האזור שמשויך לשאילתת DNS הוא תמיד האזור שמכיל את מנהרת Cloud VPN, את הצירוף ל-VLAN של Cloud Interconnect או את ממשק הרשת של הנתב הווירטואלי שמקבל את החבילות של שאילתת ה-DNS, ולא האזור של רשת המשנה שמכילה את נקודת הכניסה של מדיניות השרת לתעבורה נכנסת.

    • לדוגמה, אם החבילות של שאילתת DNS נכנסות לרשת VPC באמצעות מנהרת Cloud VPN שנמצאת באזור us-east1, ונשלחות לנקודת כניסה של מדיניות שרת נכנס באזור us-west1, האזור שמשויך לשאילתת ה-DNS הוא us-east1.
    • ההמלצה שלנו היא לשלוח שאילתות DNS לכתובת ה-IPv4 של נקודת כניסה של מדיניות שרת נכנס באותו אזור שבו נמצאים מנהרת Cloud VPN, הצירוף ל-VLAN של Cloud Interconnect או הנתב הווירטואלי.
    • האזור שמשויך לשאילתת DNS חשוב אם אתם משתמשים במדיניות ניתוב לפי מיקום גיאוגרפי. מידע נוסף זמין במאמר ניהול מדיניות הניתוב ובדיקות התקינות של DNS.

פרסום ניתוב (route advertisement) של נקודת כניסה למדיניות של שרת נכנס

כתובות ה-IP של נקודות הכניסה של מדיניות השרתים הנכנסים נלקחות מטווח הכתובות הראשי של IPv4 של רשתות המשנה, ולכן נתבי Cloud Router מפרסמים את כתובות ה-IP האלה כשסשן Border Gateway Protocol ‏ (BGP) של מנהרת Cloud VPN, של צירוף ל-VLAN של Cloud Interconnect או של מכשיר נתב מוגדר להשתמש במצב הפרסום שמוגדר כברירת מחדל של Cloud Router. אם אתם משתמשים במצב הפרסום בהתאמה אישית של Cloud Router, אתם יכולים גם להגדיר סשן BGP כדי לפרסם את כתובות ה-IP של נקודות הכניסה של מדיניות השרת הנכנס באחת מהדרכים הבאות:

  • אתם מפרסמים טווחי כתובות IP של רשתות משנה בנוסף לקידומות בהתאמה אישית.
  • אתם כוללים את כתובות ה-IP של נקודות הכניסה למדיניות השרת הנכנס בפרסומות של הקידומות בהתאמה אישית.

כללי מדיניות לשרתים יוצאים

כדי לשנות את סדר תרגום השמות של Cloud DNS ברשת VPC, יוצרים מדיניות שרת יוצא שמציינת רשימה של שרתי שמות חלופיים. כשמכונה וירטואלית משתמשת בשרת המטא-נתונים שלה 169.254.169.254 בתור שרת השמות, וכשמציינים שרתי שמות חלופיים לרשת VPC, ‏Cloud DNS שולח את כל השאילתות לשרתי השמות החלופיים, אלא אם השאילתות תואמות למדיניות תגובה ברמת האשכול של Google Kubernetes Engine או לאזור פרטי ברמת האשכול של GKE.

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

סוגים חלופיים של שרתי שמות, שיטות ניתוב וכתובות

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

סוג שרת שמות חלופי ניתוב רגיל תומך באפשרויות הבאות: תמיכה בניתוב פרטי טווח הכתובות של מקור השאילתה

הקלדת שרת שמות אחד

כתובת IP פנימית של מכונה וירטואלית ב- Google Cloud באותה רשת 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

ב-Cloud DNS יש שתי שיטות ניתוב לשליחת שאילתות לשרתי שמות חלופיים:

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

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

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

כתובות 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

דרישות רשת לשרת שמות חלופי

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

דרישות הרשת לשרתי שמות חלופיים מסוג 1

‫Cloud DNS שולח חבילות שהמקורות שלהן הם מטווח כתובות ה-IP של 35.199.192.0/19 לכתובת ה-IP של שרת השמות החלופי מסוג 1.Google Cloud מנתב חבילות לשאילתות באמצעות נתיבי רשת משנה מקומיים ברשת ה-VPC. חשוב לוודא שלא יצרתם נתיבים מבוססי-מדיניות שהיעדים שלהם כוללים כתובות IP של שרתי שמות חלופיים מסוג 1.

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

  • יעדים: חייבים לכלול את המכונות הווירטואליות של שרת השמות החלופי
  • מקורות: 35.199.192.0/19
  • פרוטוקולים: TCP ו-UDP
  • יציאה: 53

ב-Cloud DNS, כל שרת שמות חלופי צריך לשלוח חבילות תגובה בחזרה לכתובת ה-IP של Cloud DNS ב-35.199.192.0/19 שממנה הגיעה השאילתה. המקורות של חבילות התגובה חייבים להתאים לכתובת ה-IP של שרת השמות החלופי שאליו Cloud DNS שולח את השאילתה המקורית. מערכת Cloud DNS מתעלמת מתגובות אם הן מגיעות מכתובת IP לא צפויה, למשל כתובת IP של שרת שמות אחר, ששרת שמות חלופי עשוי להעביר אליו שאילתה.

כששרת שמות חלופי מסוג 1 שולח חבילות תגובה אל 35.199.192.0/19, הוא משתמש בנתיב ניתוב מיוחד.

דרישות הרשת לשרתי שמות חלופיים מסוג 2

‫Cloud DNS שולח חבילות שהמקורות שלהן הם מטווח כתובות ה-IP של 35.199.192.0/19 לשרתי שמות חלופיים מסוג 2. ‫Cloud DNS מסתמך על סוגי המסלולים הבאים בתוך רשת ה-VPC שעליה חלה מדיניות השרת לתעבורת נתונים יוצאת:

כדי לאפשר חבילות נכנסות בשרתי שמות חלופיים מסוג 2, צריך לוודא שאתם מגדירים כללי חומת אש שמאפשרים תעבורת נתונים נכנסת (ingress) שרלוונטיים לשרתי השמות החלופיים ולכל ציוד רלוונטי ברשת המקומית עם תכונות של חומת אש. הגדרת חומת האש בפועל חייבת לאפשר את הפרוטוקולים TCP ו-UDP עם יציאת היעד 53 והמקורות 35.199.192.0/19.

ב-Cloud DNS, כל שרת שמות חלופי צריך לשלוח חבילות תגובה בחזרה לכתובת ה-IP של Cloud DNS ב-35.199.192.0/19 שממנה הגיעה השאילתה. המקורות של חבילות התגובה חייבים להתאים לכתובת ה-IP של שרת השמות החלופי שאליו Cloud DNS שולח את השאילתה המקורית. מערכת Cloud DNS מתעלמת מתגובות אם הן מגיעות מכתובת IP לא צפויה, למשל כתובת IP של שרת שמות אחר, ששרת שמות חלופי עשוי להעביר אליו שאילתה.

ברשת המקומית צריכים להיות נתיבים ליעד 35.199.192.0/19, שהצעדים הבאים שלהם הם מנהרות Cloud VPN, צירופים ל-VLAN של Cloud Interconnect או נתבי Cloud Router שנמצאים באותם רשת VPC ואזור שמהם Cloud DNS שולח את השאילתה. כל עוד הדילוגים הבאים עומדים בדרישות הרשת והאזור, Google Cloud לא דורש נתיב החזרה סימטרי. אי אפשר לנתב תשובות משרתי שמות חלופיים מסוג 2 באמצעות אף אחד מהדילוגים הבאים:

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

כדי להגדיר את המסלולים של 35.199.192.0/19 ברשת המקומית, משתמשים במצב הפרסום בהתאמה אישית של Cloud Router וכוללים את 35.199.192.0/19 בתור קידומת בהתאמה אישית בסשנים של BGP במנהרות הרלוונטיות של Cloud VPN, בצירופים ל-VLAN של Cloud Interconnect או ב-Cloud Routers שמחברים את רשת ה-VPC לרשת המקומית שמכילה את שרת השמות החלופי מסוג 2. לחלופין, אפשר להגדיר נתיבים סטטיים מקבילים ברשת המקומית.

דרישות הרשת לשרתי שמות חלופיים מסוג 3

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

כדי לאפשר חבילות נכנסות בשרתי שמות חלופיים מסוג 3, ודאו שהגדרת חומת האש שחלה על שרת השמות החלופי מאפשרת חבילות מטווח המקורות של Google Public DNS.

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