מונחי מפתח

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

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

פרויקט

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

תחום מנוהל

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

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

תחום פרטי

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

Service Directory

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

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

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

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

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

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

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

תחום העברה

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

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

אזור peering

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

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

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

מדיניות תגובה היא מושג של תחום פרטי ב-Cloud DNS שמכיל כללים במקום רשומות. אפשר להשתמש בכללים האלה כדי להשיג אפקטים דומים לטיוטת הקונספט של תחום מדיניות התגובה (RPZ) ב-DNS (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 פנימי

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

תחום משנה שהוקצה

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

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

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

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

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

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

המדיניות של שרת ה-DNS

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

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

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

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

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

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