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

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

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

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

זיהוי איומים מתקדם

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

DNS64

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

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

בדוגמה הבאה מוצג אופן ההמרה של שם של יעד IPv4 בלבד על ידי מכונה וירטואלית (VM) מסוג IPv6 בלבד בשם vmipv6.

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

  2. אם קיימת רשומת AAAA (כתובת IPv6),‏ Cloud DNS מחזיר את כתובת ה-IPv6, ומכונת ה-VM‏ 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) בקטע Permissions (הרשאות) במסוף Google Cloud . התפקיד 'קריאת DNS' (roles/dns.reader) מעניק גישת קריאה בלבד לרשומות Cloud DNS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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