סקירה כללית על Cloud DNS

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

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

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

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

לרשימה של מונחי DNS כלליים, ראו סקירה כללית על DNS.

רשימה של מונחי מפתח שעליהם מבוסס Cloud DNS

כדי להתחיל להשתמש ב-Cloud DNS, תוכלו להיעזר במדריך למתחילים.

שיקולים לגבי VPC משותף

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

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

שיטות להעברת DNS

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

העברת DNS שיטות של Cloud DNS
לקבלת נתונים

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

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

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

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

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

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

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

נקודות קצה של תקשורת יוצאת

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

DNS64

אתם יכולים לחבר את המכונות הווירטואליות (VM) של Compute Engine עם IPv6 בלבד ליעדי IPv4 באמצעות Cloud DNS DNS64. ‫DNS64 מספק כתובת IPv6 מסונתזת לכל יעד IPv4. ‫Cloud DNS יוצר כתובת מסונתזת על ידי שילוב של Well-Known Prefix (WKP) 64:ff9b::/96 עם 32 הביטים של כתובת היעד ב-IPv4.

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

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

  2. אם קיימת רשומת AAAA (כתובת IPv6),‏ Cloud DNS מחזיר את כתובת ה-IPv6, והמכונה הווירטואלית של vmipv6 משתמשת בה כדי להתחבר ליעד.

  3. אם אין רשומת AAAA אבל הגדרתם DNS64,‏ Cloud DNS מחפש רשומת A (כתובת IPv4). אם Cloud DNS מוצא רשומת A, הוא יוצר רשומת AAAA על ידי הוספת הקידומת 64:ff9b::/96 לכתובת ה-IPv4.

לדוגמה, אם כתובת ה-IPv4 היא 32.34.50.60, כתובת ה-IPv6 המסונתזת שנוצרת היא 64:ff9b::2022:323c, כאשר 2022:323c היא המקבילה ההקסדצימלית של כתובת ה-IPv4. הקידומת 64:ff9b::/96 מוגדרת ב-RFC 6052. ‫Cloud DNS מסנתז את כתובות ה-IPv6 האלה גם כשמארחים את רשומות ה-DNS באופן מקומי, כל עוד מפעילים העברת DNS ב-Cloud DNS.

אפשר להשתמש ב-DNS64 בתרחישים הבאים:

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

כדי להגדיר DNS64 לרשת VPC, פועלים לפי ההוראות במאמר הגדרת DNS64.

בקרת גישה

בדף IAM & Admin במסוףCloud de Confiance אתם יכולים לנהל את המשתמשים שמורשים לבצע שינויים ברשומות ה-DNS. כדי שלמשתמשים תהיה הרשאה לבצע שינויים, צריך להיות להם תפקיד אדמין ב-DNS‏ (roles/dns.admin) בקטע Permissions במסוף Cloud de Confiance . התפקיד "קריאת DNS" (roles/dns.reader) נותן הרשאת קריאה בלבד לרשומות של Cloud DNS.

ההרשאות האלה חלות גם על חשבונות שירות שבהם אתם יכולים להשתמש כדי לנהל את שירותי ה-DNS.

כדי לראות את ההרשאות שמוקצות לתפקידים האלה, קראו את המאמר תפקידים.

בקרת גישה לאזורים מנוהלים

משתמשים עם הרשאת בעלות או הרשאת עריכה בפרויקט (roles/owner או roles/editor) יכולים לנהל או להציג את האזורים המנוהלים בפרויקט הספציפי שהם מנהלים.

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

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

גישה להרשאות לכל משאב

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

ביצועים ותזמון

‫Cloud DNS משתמש ב-anycast כדי להציג את האזורים המנוהלים.

הפצת השינויים

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

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

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

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