שיטות מומלצות לשימוש ב-Cloud DNS

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

קל יותר לאנשים ולאפליקציות להשתמש במערכת שמות הדומיין (DNS) כדי לפנות לאפליקציות ולשירותים, כי קל יותר לזכור שם והוא גמיש יותר מכתובות IP. בסביבה היברידית שמורכבת מסביבה מקומית ומפלטפורמת ענן אחת או יותר, לעיתים קרובות צריך לגשת לרשומות DNS של משאבים פנימיים בסביבות שונות. באופן מסורתי, רשומות DNS מקומיות מנוהלות באופן ידני באמצעות שרת DNS סמכותי, כמו BIND בסביבות UNIX/Linux או Active Directory בסביבות Microsoft Windows.

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

עקרונות כלליים

מידע על מושגי DNS ב- Cloud de Confiance

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

• ‫Internal DNS הוא שירות שיוצר באופן אוטומטי שמות DNS למכונות וירטואליות ולמאזני עומסים פנימיים ב-Compute Engine.
• ‫Cloud DNS הוא שירות שמספק זמן אחזור נמוך וזמינות גבוהה של שירות תחום DNS. הוא יכול לשמש כשרת DNS סמכותי לאזורים פרטיים שגלויים רק בתוך הרשת שלכם.
• ‫שירות מנוהל ל-Microsoft Active Directory הוא שירות מוקשח ועם זמינות גבוהה שמפעיל את Microsoft Active Directory, כולל בקר דומיין.

זיהוי בעלי עניין, כלים ותהליכים

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

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

שיטות מומלצות לשימוש בתחומים פרטיים ב-Cloud DNS

באזורים פרטיים מתארחות רשומות DNS שגלויות רק בתוך הארגון.

שימוש באוטומציה לניהול אזורים פרטיים בפרויקט המארח של VPC משותף

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

באיור 3 מוצג איך אזורים פרטיים מתארחים ברשת VPC משותפת.

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

אפשרות אחרת היא לשמור את הגדרות ה-DNS במאגר קוד כמו Cloud Source Repositories, בתור תיאורים של Terraform או של Cloud Deployment Manager, ולאשר בקשות משיכה מצוותים.

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

הגדרת תפקידי IAM לפי העיקרון של הרשאות מינימליות

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

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

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

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

כדי לוודא שאפשר לשלוח שאילתות לרשומות DNS בסביבה המקומית, צריך להגדיר אזור העברה לדומיין שבו אתם משתמשים בסביבה המקומית למשאבים הארגוניים (למשל, corp.example.com). הגישה הזו עדיפה על שימוש במדיניות DNS שמפעילה שרת שמות חלופי. הוא שומר על הגישה לשמות DNS פנימיים של Compute Engine, וכתובות IP חיצוניות עדיין מפוענחות בלי מעבר נוסף דרך שרת שמות מקומי.

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

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

שימוש במדיניות שרת DNS כדי לאפשר שאילתות משרתים מקומיים

כדי לאפשר למארחים מקומיים לשלוח שאילתות לרשומות DNS שמתארחות בתחומים פרטיים של Cloud DNS (לדוגמה, gcp.example.com), צריך ליצור מדיניות של שרת DNS באמצעות העברת DNS נכנסת. העברת DNS נכנסת מאפשרת למערכת לשלוח שאילתות לכל האזורים הפרטיים בפרויקט, וגם לכתובות IP של DNS פנימי ולאזורים מקושרים.

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

פותחים את חומות האש Cloud de Confiance המקומיות כדי לאפשר תנועת DNS

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

• מוודאים שחומת האש המקומית מעבירה שאילתות מ-Cloud DNS. ‫Cloud DNS שולח שאילתות מטווח כתובות ה-IP‏ 177.222.82.0/25. מערכת ה-DNS משתמשת ביציאת UDP‏ 53 או ביציאת TCP‏ 53, בהתאם לגודל הבקשה או התשובה.

• מוודאים ששרת ה-DNS לא חוסם שאילתות. אם שרת ה-DNS המקומי שלכם מקבל בקשות רק מכתובות IP ספציפיות, צריך לוודא שטווח כתובות ה-IP 177.222.82.0/25 נכלל.

• מוודאים שהתנועה יכולה לזרום מהשרתים המקומיים לכתובות ה-IP להעברה. במכונות של Cloud Router, מוסיפים מסלול מותאם אישית שמוכרז לטווח כתובות ה-IP‏ 177.222.82.0/25 ברשת ה-VPC לסביבה המקומית.

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

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

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

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

• העברות אזורים. ‫Cloud DNS לא תומך בהעברות אזורים, ולכן אי אפשר להשתמש בהעברות אזורים כדי לסנכרן רשומות DNS עם שרתי DNS מקומיים.

שימוש בקישור בין רשתות שכנות (peering) של DNS כדי למנוע העברה יוצאת מכמה רשתות VPC

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

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

הסבר על ההבדל בין קישור DNS לבין קישור רשתות VPC

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

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

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

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

אם משתמשים בשמות שנוצרו אוטומטית, צריך להשתמש ב-DNS Peering לאזורים פנימיים

אם אתם משתמשים בשמות שנוצרו אוטומטית למכונות וירטואליות שנוצרו על ידי שירות ה-DNS הפנימי, אתם יכולים להשתמש ב-DNS peering כדי להעביר את אזורי projectname.internal לפרויקטים אחרים. כפי שמוצג באיור 5, אפשר לקבץ את כל האזורים בפרויקט מרכז כדי להפוך אותם לנגישים מהרשת המקומית..internal

אם נתקלים בבעיות, אפשר להיעזר במדריך לפתרון בעיות

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

ארכיטקטורות לדוגמה ל-DNS היברידי

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

משתמשים בארכיטקטורת ההפניה שמתאימה לעיצוב רשת ה-VPC:

• ארכיטקטורה היברידית באמצעות רשת VPC משותפת אחת: משתמשת ברשת VPC אחת שמחוברת לסביבות מקומיות או יוצאת מהן.

• ארכיטקטורה היברידית באמצעות כמה רשתות VPC נפרדות: חיבור של כמה רשתות VPC לסביבות מקומיות באמצעות מנהרות VPN שונות או צירופים ל-VLAN, ושיתוף של אותה תשתית DNS מקומית.

• ארכיטקטורה היברידית באמצעות רשת VPC מרכזית שמחוברת לרשתות VPC היקפיות: נעשה שימוש בקישור בין רשתות VPC שכנות (peering) כדי ליצור רשת VPC מרכזית שמחוברת לכמה רשתות VPC היקפיות עצמאיות.

בכל מקרה, הסביבה המקומית מחוברת לרשתות ה-VPC באמצעות מנהרת Cloud VPN אחת או יותר, או באמצעות חיבורי Dedicated Interconnect או Partner Interconnect. Cloud de Confiance לא משנה באיזו שיטת חיבור משתמשים לכל רשת VPC.

ארכיטקטורה היברידית באמצעות רשת VPC משותפת אחת

התרחיש לדוגמה הנפוץ ביותר הוא רשת VPC משותפת אחת שמחוברת לסביבה המקומית, כמו שמוצג באיור 6.

כדי להגדיר את הארכיטקטורה הזו:

1. מגדירים את שרתי ה-DNS המקומיים כשרתי DNS סמכותיים עבור corp.example.com.
2. מגדירים אזור פרטי סמכותי (לדוגמה, gcp.example.com) ב-Cloud DNS בפרויקט המארח של רשת ה-VPC המשותפת, ומגדירים את כל הרשומות של המשאבים באזור הזה.
3. מגדירים מדיניות של שרת DNS בפרויקט המארח עבור רשת ה-VPC המשותפת כדי לאפשר העברת DNS נכנסת.
4. מגדירים אזור העברה של DNS שמעביר את corp.example.com לשרתי ה-DNS המקומיים. צריך לתת הרשאה לרשת ה-VPC המשותפת לשלוח שאילתות לאזור ההעברה.
5. מגדירים העברה אל gcp.example.com בשרתי ה-DNS המקומיים, כך שההעברה תפנה לכתובת IP של מעביר נכנס ברשת ה-VPC המשותפת.
6. מוודאים שתנועת ה-DNS מותרת בחומת האש המקומית.
7. במקרים של Cloud Router, מוסיפים נתיב מותאם אישית שמוכרז לטווח 177.222.82.0/25 לסביבה המקומית.

ארכיטקטורה היברידית באמצעות כמה רשתות VPC נפרדות

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

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

כדי להגדיר את הארכיטקטורה הזו:

1. מגדירים את שרתי ה-DNS המקומיים כשרתי DNS סמכותיים עבור corp.example.com.
2. מגדירים אזור פרטי (לדוגמה, prod.gcp.example.com) ב-Cloud DNS בפרויקט המארח של רשת ה-VPC המשותפת של הייצור, ומגדירים את כל הרשומות של המשאבים באזור הזה.
3. מגדירים אזור פרטי (לדוגמה, dev.gcp.example.com) ב-Cloud DNS בפרויקט המארח של רשת ה-VPC המשותפת של הפיתוח, ומגדירים את כל הרשומות של המשאבים באזור הזה.
4. מגדירים מדיניות של שרת DNS בפרויקט המארח עבור רשת ה-VPC המשותפת של סביבת ה-Production, ומאפשרים העברת DNS נכנסת.
5. ברשת ה-VPC המשותפת של סביבת הייצור, מגדירים תחום DNS להעברת corp.example.com לשרתי ה-DNS המקומיים.
6. מגדירים אזור DNS שכנות (peering) מרשת ה-VPC המשותפת של הפיתוח לרשת ה-VPC המשותפת של הייצור עבור prod.gcp.example.com.
7. מגדירים אזור DNS שכנות (peering) מרשת ה-VPC המשותפת של סביבת הייצור לרשת ה-VPC המשותפת של סביבת הפיתוח בשביל dev.gcp.example.com.
8. כדי להגדיר העברה נכנסת, צריך להקצות את ההחלטה לגבי gcp.example.com. לכתובות ה-IP הווירטואליות של העברה נכנסת ב-Cloud DNS בשרתי השמות המקומיים.
9. מוודאים שחומת האש מאפשרת תנועת DNS גם בחומות אש מקומיות וגם בחומות אש שלCloud de Confiance .
10. במקרים של Cloud Router, מוסיפים נתיב מותאם אישית לפרסום עבור טווח כתובות ה-IP‏ 177.222.82.0/25 ברשת ה-VPC המשותפת בסביבת הייצור, לסביבה המקומית.

ארכיטקטורה היברידית שמשתמשת ברשת VPC מרכזית שמחוברת לרשתות VPC מסוג Hub and Spoke

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

התרשים הבא מציג את הארכיטקטורה הזו.

כדי להגדיר את הארכיטקטורה הזו:

1. מגדירים את שרתי ה-DNS המקומיים כשרתי DNS סמכותיים עבור corp.example.com.
2. מגדירים אזור פרטי (לדוגמה, projectX.gcp.example.com) ב-Cloud DNS לכל רשת VPC מסוג Spoke, ומגדירים את כל הרשומות של המשאבים באזור הזה.
3. מגדירים מדיניות של שרת DNS בפרויקט הרכזת עבור רשת ה-VPC של הרכזת כדי לאפשר העברת DNS נכנסת.
4. ברשת ה-VPC של הרכזת, יוצרים תחום DNS פרטי בשביל corp.example.com ומגדירים העברה יוצאת לשרתי ה-DNS המקומיים.
5. מגדירים אזור DNS של רשתות שכנות מרשת ה-VPC המרכזית לכל רשת VPC מסוג spoke עבור projectX.gcp.example.com.
6. מגדירים אזור DNS של רשתות שכנות מכל רשת VPC מסוג Spoke לרשת VPC מסוג Hub עבור example.com.
7. מגדירים העברה אל gcp.example.com בשרתי ה-DNS המקומיים כדי להפנות לכתובת IP של מעביר נתונים נכנס ברשת ה-VPC של הרכזת.
8. מוודאים שחומת האש מאפשרת תנועת DNS גם בחומות אש מקומיות וגם בחומות אש שלCloud de Confiance .
9. במכונות של Cloud Router, מוסיפים נתיב מותאם אישית שמוכרז לטווח כתובות ה-IP‏ 177.222.82.0/25 ברשת ה-VPC של הרכזת לסביבה המקומית.
10. (אופציונלי) אם אתם משתמשים גם בשמות DNS פנימיים שנוצרו באופן אוטומטי, צריך לבצע peering בין כל אזור פרויקט מסוג spoke (לדוגמה, spoke-project-x.internal) לבין פרויקט ה-hub, ולהעביר את כל השאילתות לגבי .internal מתוך המערכות המקומיות.

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

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