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

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

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

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

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

בסקירה הכללית על DNS מפורטת רשימה של מונחי DNS כלליים.

רשימה של מונחים מרכזיים שעליהם מבוסס Cloud DNS מופיעה במאמר מונחים מרכזיים.

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

נסו בעצמכם

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

להתנסות ב-Cloud DNS בחינם

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

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

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

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

Google Cloud מציע העברה (forwarding) של 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 שלכם להשתמש בו. במאמר יעדי העברה ושיטות ניתוב מוסבר איך Google Cloudמנתבת את התנועה ליעד העברה.
  • יוצרים מדיניות שרת יוצאת לרשת ה-VPC כדי לשלוח את כל בקשות ה-DNS לשרת שמות חלופי. כשמשתמשים בשרת שמות חלופי, מכונות וירטואליות ברשת ה-VPC כבר לא יכולות לפתור רשומות בתחומים פרטיים של Cloud DNS, בתחומי העברה, בתחומי שיתוף או בתחומי DNS פנימיים של Compute Engine. פרטים נוספים זמינים במאמר סדר פתרון השמות.

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

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

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

DNSSEC

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

DNS64 (תצוגה מקדימה)

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

מגדירים DNS64 ותרגום כתובות רשת באמצעות NAT ציבורי (NAT64) כדי לאפשר למכונות הווירטואליות עם IPv6 בלבד (גרסת טרום-השקה) לתקשר עם יעדים של IPv4 באינטרנט. כדי להגדיר NAT64, פועלים לפי ההוראות במאמר יצירת שער Cloud NAT.

בדוגמה הבאה מוסבר איך מכונה וירטואלית מסוג IPv6 בלבד (Preview) בשם 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.

DNS64 מתרגם כתובת IPv4 לכתובת IPv6 מסונתזת.
DNS64 מתרגם כתובת IPv4 לכתובת IPv6 מסונתזת (לחיצה להגדלה).

לדוגמה, אם כתובת ה-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.

בקרת גישה

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

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

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

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

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

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

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

גישה לפי הרשאת משאב

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

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

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

העברת שינויים

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

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

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

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