מונחי מפתח

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

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

פרויקט

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

אזור מנוהל

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

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

אזור ציבורי

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

שם DNS	סוג	TTL (בשניות)	נתונים
www.example.com	A	300	198.51.100.0

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

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

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

אזור פרטי

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

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

אפשר להשתמש באזורים פרטיים עם VPC משותף. מידע חשוב על שימוש באזורים פרטיים עם VPC משותף זמין במאמר בנושא שיקולים לגבי VPC משותף.

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

אפשר לשלוח שאילתות לשרת השמות הזה מכל מכונה וירטואלית שמשתמשת ברשת VPC מורשית. לדוגמה, אפשר ליצור תחום פרטי בשביל dev.gcp.example.com כדי לארח רשומות DNS פנימיות לאפליקציות ניסיוניות. בטבלה הבאה מוצגות רשומות לדוגמה באזור הזה. לקוחות של מסדי נתונים יכולים להתחבר לשרת מסד הנתונים db-01.dev.gcp.example.com באמצעות שם ה-DNS הפנימי שלו במקום כתובת ה-IP שלו. לקוחות מסד נתונים פותרים את שם ה-DNS הפנימי הזה באמצעות פותר המארח במכונה הווירטואלית, ששולח את שאילתת ה-DNS לשרת המטא-נתונים 169.254.169.254. שרת המטא-נתונים פועל כמפענח DNS רקורסיבי כדי לשלוח שאילתה לאזור הפרטי שלכם.

שם DNS	סוג	TTL (בשניות)	נתונים
db-01.dev.gcp.example.com	A	5	10.128.1.35
instance-01.dev.gcp.example.com	A	50	10.128.1.10

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

Service Directory

Service Directory הוא רישום שירותים מנוהל ל-Google Cloud שמאפשר לכם לרשום ולגלות שירותים באמצעות HTTP או gRPC (באמצעות Lookup API), בנוסף לשימוש ב-DNS רגיל. אפשר להשתמש בספריית השירותים כדי לרשום שירותים שלGoogle Cloud וגם שירותים שהם לא שלGoogle Cloud .

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

כשיוצרים אזור שמגובה על ידי Service Directory, אי אפשר להוסיף רשומות לאזור ישירות. הנתונים מגיעים ממאגר השירותים של Service Directory.

‫Cloud DNS וחיפוש הפוך של כתובות שאינן RFC 1918

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

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

כשיוצרים אזור DNS מנוהל של חיפוש הפוך, אי אפשר להוסיף רשומות לאזור ישירות. הנתונים מגיעים מנתוני כתובות ה-IP של Compute Engine.

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

אזור העברה

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

כשיוצרים אזור העברה, אי אפשר להוסיף רשומות לאזור ההעברה ישירות. הנתונים מגיעים מאחד או יותר משרתי השמות או מפתרי הכתובות שהוגדרו כיעדים.

אזור פירינג

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

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

מדיניות תגובה

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

מדיניות תגובה שונה מאזור RPZ, שהוא אזור DNS רגיל עם נתונים בפורמט מיוחד שגורם לפתרונות תואמים לבצע פעולות מיוחדות. מדיניות תגובה היא לא אזור DNS, והיא מנוהלת בנפרד ב-API.

פעולות באזור

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

שם דומיין בינלאומי (IDN)

שם דומיין בינלאומי (IDN) הוא שם דומיין באינטרנט שמאפשר לאנשים בכל העולם להשתמש בסקריפט או באלפבית ספציפיים לשפה, כמו ערבית, סינית, קירילית, דבאנגארי, עברית או תווים מיוחדים שמבוססים על האלפבית הלטיני בשמות דומיינים. ההמרה הזו מיושמת באמצעות Punycode, שהוא ייצוג של תווי Unicode שמשתמשים ב-ASCII. לדוגמה, ייצוג IDN של .ελ הוא .xn--qxam. דפדפנים, תוכנות אימייל ואפליקציות מסוימות עשויים לזהות את התג ולעבד אותו כ-.ελ בשמכם. תקן Internationalizing Domain Names in Applications ‏ (IDNA) מאפשר רק מחרוזות Unicode קצרות מספיק כדי להיות מיוצגות כתווית DNS תקינה. מידע על שימוש ב-IDN עם Cloud DNS זמין במאמר יצירת אזורים עם שמות דומיין בינלאומיים.

רשם

רשם שמות דומיינים הוא ארגון שמנהל את ההזמנה של שמות דומיינים באינטרנט. רשם צריך להיות מוסמך על ידי מרשם של דומיין גנרי ברמה העליונה (gTLD) או מרשם של דומיין ברמה העליונה עם קוד מדינה (ccTLD).

DNS פנימי

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

אזור משנה מואצל

מערכת ה-DNS מאפשרת לבעלים של אזור להקצות תת-דומיין לשרת שמות אחר באמצעות רשומות NS (שרת שמות). מערכות לפתרון שמות פועלות לפי הרשומות האלה ושולחות שאילתות לגבי תת-הדומיין לשרת השמות של היעד שצוין בהקצאת ההרשאות.

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

קבוצות של רשומות משאבים

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

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

שינוי של קבוצת רשומות משאבים

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

לדוגמה, אם יש לכם רשומת A שנראית כך:

www  A  203.0.113.1 203.0.113.2

ואז מריצים פקודה שנראית כך:

DEL  www  A  203.0.113.2
ADD  www  A  203.0.113.3

כך נראית הרשומה אחרי השינוי בכמות גדולה:

www  A  203.0.113.1 203.0.113.3

הפעולות ADD ו-DEL מתבצעות בו-זמנית.

פורמט המספר הסידורי בדף "דוח תנועות בחשבון"

המספרים הסידוריים של רשומות SOA שנוצרו באזורים מנוהלים של Cloud DNS גדלים באופן מונוטוני עם כל שינוי טרנזקציוני בקבוצות הרשומות של אזור שבוצע באמצעות הפקודה gcloud dns record-sets transaction. עם זאת, אתם יכולים לשנות ידנית את המספר הסידורי של רשומת SOA למספר שרירותי, כולל תאריך בפורמט ISO 8601, כמומלץ ב-RFC 1912.

לדוגמה, ברשומת ה-SOA הבאה, אפשר לשנות את המספר הסידורי ישירות ממסוף Google Cloud על ידי הזנת הערך הרצוי בשדה השלישי של הרשומה, שמופרד ברווח:

ns-gcp-private.googledomains.com. cloud-dns-hostmaster.google.com.
[serial number] 21600 3600 259200 300`

מדיניות שרת DNS

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

דומיין, תת-דומיין והענקת גישה

רוב התת-דומיינים הם רק רשומות באזור המנוהל של דומיין האב. תת-דומיינים שמועברים על ידי יצירת רשומות NS (שרת שמות) באזור של דומיין ההורה שלהם צריכים גם אזורים משלהם.

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

תוספי האבטחה של DNS ‏ (DNSSEC) הם חבילה של תוספים ל-DNS של כוח המשימה להנדסת אינטרנט (IETF), שמאמתים תגובות לבדיקות של שמות דומיין. ‫DNSSEC לא מספק הגנה על הפרטיות של השאילתות האלה, אבל הוא מונע מתוקפים לשנות או להרעיל את התשובות לבקשות DNS.

איסוף של רשומות DNSKEY

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