מונחי מפתח

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

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

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

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

מדיניות שרת DNS

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

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

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

DNSSEC

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

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

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

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

אזור העברה

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

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

DNS פנימי

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

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

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

אזור מנוהל

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

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

אזור פירינג

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

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

אזור פרטי

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

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

פרויקט

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

אזור ציבורי

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

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

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

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

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

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

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

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

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

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

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

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.

פורמט המספר הסידורי של ה-SOA

המספרים הסידוריים של רשומות 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`
פעולות באזור

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