‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

הגדרת מדיניות ניתוב של DNS ובדיקות תקינות

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

לפני שמתחילים

כדי להגדיר מדיניות ניתוב DNS, צריך ליצור קבוצת רשומות משאבים ולבחור אחת ממדיניות ניתוב ה-DNS הבאות כדי להחיל אותה על קבוצת רשומות המשאבים.
- מדיניות ניתוב של סדר סיבובי משוקלל (WRR)
- מדיניות ניתוב לפי מיקום גיאוגרפי
  - מדיניות ניתוב לפי מיקום גיאוגרפי עם גדר וירטואלית
- מדיניות ניתוב למקרה של כשל
מדיניות ניתוב DNS תומכת במספר כתובות IP לכל מיקום גיאוגרפי במדיניות הניתוב לפי מיקום גיאוגרפי. כשמציינים כמה כתובות IP למיקום גיאוגרפי, Cloud DNS מחזיר את כל כתובות ה-IP שצוינו למיקום הזה. אי אפשר לשלב מדיניות ניתוב לפי מיקום גיאוגרפי עם מדיניות WRR מותאמת אישית עם משקלים.
אפשר להחיל רק סוג אחד של מדיניות ניתוב על קבוצת רשומות משאב בכל פעם. אי אפשר לשלב בין כללי מדיניות של ניתוב, אלא אם מגדירים מדיניות ניתוב למעבר לגיבוי במקרה של כשל. במקרה כזה, אפשר להגדיר מדיניות ניתוב לפי מיקום גיאוגרפי כגיבוי.
חשוב לוודא שהפעלתם גישה גלובלית למאזני עומסים אזוריים.
לפני שמגדירים מדיניות ניתוב DNS לאזורים ציבוריים, צריך להשבית את constraints/compute.disableInternetNetworkEndpointGroupהאילוץ של מדיניות הארגון. מידע נוסף זמין במאמר בנושא אילוצים של מדיניות הארגון.
חשוב לוודא שיש לכם את ההרשאות הנדרשות כדי להגדיר מדיניות ניתוב DNS.

ההרשאות שנדרשות למשימה הזו

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

הרשאות

‫dns.networks.useHealthSignals כדי ליצור מדיניות עם בדיקות תקינות למאזני עומסי רשת פנימיים להעברת סיגנל ללא שינוי
dns.changes.create כדי ליצור קבוצת רשומות משאבים
‫dns.managedZones.list כדי להציג רשימה של אזורים מנוהלים

תפקידים

אדמין DNS‏ (roles/dns.admin)
DNS Peer (roles/dns.peer)

יצירת כללי מדיניות לניתוב DNS עבור תחומים פרטיים

לפני שיוצרים מדיניות ניתוב DNS לתחומים פרטיים, צריך לבצע את השלבים הבאים.

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

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

המסוף

התחלת ההגדרה

נכנסים לדף Cloud DNS zones במסוף Google Cloud .

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

נתוני בסיס

אופציונלי: בדף Create record set with routing policy, בשדה DNS name, מזינים תת-דומיין של שם ה-DNS. לדוגמה, mail. הנקודה בסוף מתווספת אוטומטית.

חשוב: הוספת התו @ בשדה הזה גורמת לכך שהרשומה תיכשל.
בוחרים אפשרות בשדה Resource record type.
בשדה TTL, מזינים ערך מספרי לאורך החיים של רשומת המשאבים, כלומר משך הזמן שבו אפשר לשמור אותה במטמון. הערך חייב להיות מספר שלם חיובי.
אופציונלי: בשדה יחידת TTL, בוחרים את יחידת הזמן – לדוגמה, minutes. ערך ברירת המחדל הוא minutes.
לוחצים על הבא.

סוג מדיניות תכנון המסלול

בקטע Routing policy (מדיניות ניתוב), בוחרים באפשרות Weighted round robin (סדר סיבובי משוקלל), Geolocation (מיקום גאוגרפי) או Failover (יתירות כשל).
לוחצים על הבא.

נתונים של מדיניות תכנון מסלול

WRR

בקטע משקל, מזינים את המשקל שמתאים לקטע המשנה הזה בנתוני רשומת המשאב (RR).

המשקל הזה חייב להיות מספר לא שלילי בין 0.0 ל-1000.0. היחס בין נפח התנועה שמופנה ליעד מחושב על סמך היחס בין המשקל האישי לבין המשקל הכולל של כל המשקלים. לדוגמה, אם ליעד א' יש משקל של 25 וליעד ב' יש משקל של 75, והמשקל הכולל הוא 100, מערכת Cloud DNS תנתב 25/100 = 0.25 (25%) מהתנועה הכוללת ליעד א', ו-75/100= 0.75 (75%) ליעד ב'.
בקטע IPv4 health checked targets:
1. בקטע Project (פרויקט), בוחרים את הפרויקט שבו קיים כלל ההעברה.
2. בקטע כלל העברה, בוחרים כלל העברה.
  
  כלל ההעברה מציין כתובת IP פנימית, יציאה ואחד מהיעדים הבאים:
  - שירות לקצה העורפי אזורי
  - שרת proxy ל-HTTPS עם יעד גלובלי או אזורי
  - שרת proxy ל-TCP עם יעד אזורי
לוחצים על סיום.
אופציונלי: כדי להוסיף עוד יעד שנבדק, לוחצים על הוספת יעד.
אופציונלי: כדי לאפשר כתובות IPv4 ללא בדיקת תקינות, מבצעים את הפעולות הבאות:
1. בוחרים באפשרות Allow IPv4 addresses without health checking (אישור כתובות IPv4 ללא בדיקת תקינות).
2. בקטע IPv4 Address, מזינים כתובת IPv4.
אופציונלי: כדי להוסיף עוד נתונים של ניתוב מדיניות WRR, לוחצים על הוספת נתוני ניתוב.
לוחצים על הבא.

מיקום גיאוגרפי

בקטע גידור גיאוגרפי, בוחרים באפשרות מושבת או מופעל.

הפעלת הגידור הגיאוגרפי מגבילה את התנועה למיקום גיאוגרפי ספציפי, גם אם כל נקודות הקצה במיקום הגיאוגרפי הזה לא תקינות.
בשדה אזור מקור, בוחרים אזור מקור תקין Google Cloud.
בקטע IPv4 health checked targets:
1. בקטע Project (פרויקט), בוחרים את הפרויקט שבו קיים כלל ההעברה.
2. בקטע כלל העברה, בוחרים כלל העברה.
  
  כלל ההעברה מציין כתובת IP פנימית, יציאה ואחד מהיעדים הבאים:
  - שירות לקצה העורפי אזורי
  - שרת proxy ל-HTTPS עם יעד גלובלי או אזורי
  - שרת proxy ל-TCP עם יעד אזורי
לוחצים על סיום.
אופציונלי: כדי להוסיף עוד יעד שנבדק, לוחצים על הוספת יעד.
אופציונלי: כדי לאפשר כתובות IPv4 ללא בדיקת תקינות, מבצעים את הפעולות הבאות:
1. בוחרים באפשרות Allow IPv4 addresses without health checking (אישור כתובות IPv4 ללא בדיקת תקינות).
2. בקטע IPv4 Address, מזינים כתובת IPv4.
אופציונלי: כדי להוסיף עוד נתוני ניתוב של מדיניות מיקום גיאוגרפי, לוחצים על הוספת נתוני ניתוב.
לוחצים על הבא.

מעבר לגיבוי (Failover)

בקטע Primary health checked targets:
1. בקטע Project (פרויקט), בוחרים את הפרויקט שבו קיים כלל ההעברה.
2. בקטע כלל העברה, בוחרים כלל העברה.
  
  כלל ההעברה מציין כתובת IP פנימית, יציאה ואחד מהיעדים הבאים:
  - שירות לקצה העורפי אזורי
  - שרת proxy ל-HTTPS עם יעד גלובלי או אזורי
  - שרת proxy ל-TCP עם יעד אזורי
בקטע Backup geolocation policy:
1. בקטע גידור גיאוגרפי, בוחרים באפשרות מושבת או מופעל. הפעלת גידור גיאוגרפי מגבילה את התנועה למיקום גיאוגרפי ספציפי גם אם כל נקודות הקצה במיקום הגיאוגרפי הזה לא תקינות.
2. בשדה אזור מקור, בוחרים אזור מקור תקין Google Cloud.
3. בקטע IPv4 health checked targets:
  1. בקטע Project (פרויקט), בוחרים את הפרויקט שבו קיים כלל ההעברה.
  2. בקטע כלל העברה, בוחרים כלל העברה.
    
    כלל ההעברה מציין אחת מהאפשרויות הבאות:
    - כתובת IP פנימית, יציאה ושירות לקצה העורפי אזורי
    - שרת proxy ל-HTTP(S)
    - שרת proxy ל-TCP
אם כל כתובות ה-IP הראשיות לא תקינות, המערכת מטפלת בתנועה באופן אוטומטי בהתאם למדיניות הגיבוי של המיקום הגיאוגרפי.
לוחצים על סיום.
אופציונלי: כדי להוסיף עוד יעד שנבדק, לוחצים על הוספת יעד.
אופציונלי: כדי לאפשר כתובות IPv4 ללא בדיקת תקינות, מבצעים את הפעולות הבאות:
1. בוחרים באפשרות Allow IPv4 addresses without health checking (אישור כתובות IPv4 ללא בדיקת תקינות).
2. בקטע IPv4 Address, מזינים כתובת IPv4.
אופציונלי: כדי להוסיף עוד נתוני ניתוב של מדיניות גיבוי למיקום גיאוגרפי, לוחצים על הוספת נתוני ניתוב.
בשדה פיזור תעבורת הנתונים (%), מזינים את אחוז תעבורת הנתונים שנשלחת ליעדי הגיבוי, ללא קשר לסטטוס בדיקת התקינות של היעדים העיקריים.
לוחצים על הבא.

בדיקה ויצירה

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

gcloud

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

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

מריצים את הפקודה gcloud dns record-sets create:

WRR

gcloud dns record-sets create RRSET_NAME \
  --ttl=TTL \
  --type=RRSET_TYPE \
  --zone=MANAGED_ZONE \
  --routing-policy-type=WRR \
  --routing-policy-data=ROUTING_POLICY_DATA \
  --enable-health-checking

מחליפים את מה שכתוב בשדות הבאים:

‫RRSET_NAME: שם ה-DNS שתואם לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, כמו service.example.com.
‫TTL: ה-TTL, בשניות, שבו מפענח ה-DNS שומר במטמון את ResourceRecordSet, למשל 30.
‫RRSET_TYPE: סוג רשומת המשאב של ResourceRecordSet, למשל A. רשימה של סוגי הרשומות הנתמכים זמינה במאמר סוגי רשומות נתמכים למדיניות ניתוב DNS.
‫MANAGED_ZONE: האזור המנוהל שאליו משויך ResourceRecordSet, למשל service-zone. השם של ResourceRecordSet הזה צריך להסתיים בסיומת של שם ה-DNS של האזור המנוהל.
‫ROUTING_POLICY_DATA: מזינים רשימה של ערכים מופרדים באמצעות נקודה-פסיק בפורמט ${weight_percent}:${rrdatas}, למשל .8=203.0.113.1;.2=198.51.100.1. מציינים את המשקל כמספר עשרוני לא שלילי. יחס תנועת הגולשים שמופנית ליעד מחושב על סמך היחס בין המשקל האישי לבין המשקל הכולל של כל המשקלים. שמות של כללי העברה הם ערכים קבילים ומובילים לבדיקת תקינות.
‫--enable-health-checking: הדגל להפעלת בדיקת התקינות. כשמשתמשים בדגל הזה, צריך לציין את שם כלל ההעברה במקום את כתובת ה-IP בשדה --routing-policy-data.

מיקום גיאוגרפי

gcloud dns record-sets create RRSET_NAME \
  --ttl=TTL \
  --type=RRSET_TYPE \
  --zone=MANAGED_ZONE \
  --routing-policy-type=GEO \
  --routing-policy-data=ROUTING_POLICY_DATA \
  --enable-health-checking

מחליפים את מה שכתוב בשדות הבאים:

‫RRSET_NAME: שם ה-DNS שתואם לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, כמו service.example.com.
‫TTL: ה-TTL, בשניות, שבו מפענח ה-DNS שומר במטמון את ResourceRecordSet, למשל 30.
‫RRSET_TYPE: סוג רשומת המשאב של ResourceRecordSet, למשל A. רשימה של סוגי הרשומות הנתמכים זמינה במאמר סוגי רשומות נתמכים למדיניות ניתוב DNS.
‫MANAGED_ZONE: האזור המנוהל שאליו משויך ResourceRecordSet, למשל service-zone. השם של ResourceRecordSet הזה צריך להסתיים בסיומת של שם ה-DNS של האזור המנוהל.
‫ROUTING_POLICY_DATA: מזינים רשימה של ערכים מופרדים באמצעות נקודה-פסיק בפורמט ${region}=${IP_address}, למשל asia-east1=198.51.100.1;us-central1=203.0.113.1. כדי לציין כמה כתובות IP לאזור אחד, מוסיפים את כתובות ה-IP מופרדות בפסיק. שמות של כללי העברה הם ערכים קבילים ומובילים לבדיקת תקינות.
‫--enable-health-checking: הדגל להפעלת בדיקת התקינות. כשמשתמשים בדגל הזה, צריך לציין את שם כלל ההעברה במקום את כתובת ה-IP בשדה --routing-policy-data.

מיקום גיאוגרפי עם גבול וירטואלי

gcloud dns record-sets create RRSET_NAME \
  --ttl=TTL \
  --type=RRSET_TYPE \
  --zone=MANAGED_ZONE \
  --routing-policy-type=GEO \
  --routing-policy-data=ROUTING_POLICY_DATA \
  --enable-geo-fencing \
  --enable-health-checking

מחליפים את מה שכתוב בשדות הבאים:

‫RRSET_NAME: שם ה-DNS שתואם לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, כמו service.example.com.
‫TTL: ה-TTL, בשניות, שבו מפענח ה-DNS שומר במטמון את ResourceRecordSet, למשל 30.
‫RRSET_TYPE: סוג רשומת המשאב של ResourceRecordSet, למשל A. רשימה של סוגי הרשומות הנתמכים זמינה במאמר סוגי רשומות נתמכים למדיניות ניתוב DNS.
‫MANAGED_ZONE: האזור המנוהל שאליו משויך ResourceRecordSet, למשל service-zone. השם של ResourceRecordSet הזה צריך להסתיים בסיומת של שם ה-DNS של האזור המנוהל.
‫ROUTING_POLICY_DATA: מזינים רשימה של ערכים מופרדים באמצעות נקודה-פסיק בפורמט ${region}=${IP_address}, למשל asia-east1=198.51.100.1;us-central1=203.0.113.1. כדי לציין כמה כתובות IP לאזור אחד, מוסיפים את כתובות ה-IP מופרדות בפסיק. שמות של כללי העברה הם ערכים קבילים ומובילים לבדיקת תקינות.
‫--enable-geo-fencing: במדיניות ניתוב של GEO, ההגדרה הזו קובעת אם התנועה תעבור אוטומטית לאזורים אחרים אם כל נקודות הקצה באזור מסוים לא תקינות. כשמגדירים את האפשרות הזו, Cloud DNS תמיד מפנה שאילתות לאזור הקרוב ביותר, גם אם כל נקודות הקצה באזור הזה לא תקינות. כדי להשבית את הגידור הגיאוגרפי, משתמשים ב---no-enable-geo-fencing. אם לא מגדירים את האפשרות הזו, Cloud DNS מפנה שאילתות לאזור הקרוב הבא אם כל נקודות הקצה באזור מסוים לא תקינות. ברירת המחדל היא false.
‫--enable-health-checking: הדגל להפעלת בדיקת התקינות. כשמשתמשים בדגל הזה, צריך לציין את שם כלל ההעברה במקום את כתובת ה-IP בשדה --routing-policy-data.

מעבר לגיבוי (Failover)

gcloud dns record-sets create RRSET_NAME \
  --ttl=TTL \
  --type=RRSET_TYPE \
  --zone=MANAGED_ZONE \
  --routing-policy-type=FAILOVER  \
  --routing-policy-primary-data=ROUTING_POLICY_PRIMARY_DATA \
  --routing-policy-backup-data-type=ROUTING_POLICY_BACKUP_DATA_TYPE \
  --routing-policy-backup-data=ROUTING_POLICY_BACKUP_DATA \
  --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO \
  --enable-geo-fencing \
  --enable-health-checking

מחליפים את מה שכתוב בשדות הבאים:

‫RRSET_NAME: שם ה-DNS שתואם לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, כמו service.example.com.
‫TTL: ה-TTL, בשניות, שבו מפענח ה-DNS שומר במטמון את ResourceRecordSet, למשל 30.
‫RRSET_TYPE: סוג רשומת המשאב של ResourceRecordSet, למשל A. רשימה של סוגי הרשומות הנתמכים זמינה במאמר סוגי רשומות נתמכים למדיניות ניתוב DNS.
‫MANAGED_ZONE: האזור המנוהל שאליו משויך ResourceRecordSet, למשל service-zone. השם של ResourceRecordSet הזה צריך להסתיים בסיומת של שם ה-DNS של האזור המנוהל.
‫ROUTING_POLICY_PRIMARY_DATA: היעד הראשי לשימוש במדיניות הניתוב של FAILOVER. היעד הזה צריך להיות הפניה לכלל העברה אחד או יותר, כמו forwarding-rule-1. כל עוד לפחות אחד מכללי ההעברה האלה תקין, כתובות ה-IP של כל כללי ההעברה התקינים משמשות למענה על שאילתות לגבי השם הזה.
‫ROUTING_POLICY_BACKUP_DATA_TYPE: במדיניות ניתוב של FAILOVER, סוג מדיניות הניתוב שנתוני הגיבוי משתמשים בה. הערך חייב להיות GEO.
‫ROUTING_POLICY_BACKUP_DATA: יעד הגיבוי שבו יש להשתמש עבור מדיניות הניתוב FAILOVER. יעדי ההעברה האלה משמשים כשהמצב של כל כללי ההעברה שצוינו ב---routing-policy-primary-data הוא לא תקין. ‫Cloud DNS תומך רק ביעדי גיבוי שמבוססים על מיקום גיאוגרפי. הפורמט של השדה הזה זהה לפורמט של --routing-policy-data כש--routing-policy-type = 'GEO', למשל asia-east1=forwarding-rule-2.
‫BACKUP_DATA_TRICKLE_RATIO: היחס של התנועה שתישלח ליעדי הגיבוי, גם כשהיעדים הראשיים תקינים. היחס צריך להיות בין 0 ל-1, למשל 0.1. ערך ברירת המחדל הוא 0.
‫--enable-geo-fencing: במדיניות ניתוב של GEO, ההגדרה הזו קובעת אם התנועה תעבור אוטומטית לאזורים אחרים אם כל נקודות הקצה באזור מסוים לא תקינות. כשמגדירים את האפשרות הזו, Cloud DNS תמיד מפנה שאילתות לאזור הקרוב ביותר, גם אם כל נקודות הקצה באזור הזה לא תקינות. כדי להשבית את הגידור הגיאוגרפי, משתמשים ב---no-enable-geo-fencing. אם לא מגדירים את האפשרות הזו, Cloud DNS מפנה שאילתות לאזור הקרוב הבא אם כל נקודות הקצה באזור מסוים לא תקינות. ברירת המחדל היא false.
‫--enable-health-checking: הדגל להפעלת בדיקת התקינות. כשמשתמשים בדגל הזה, צריך לציין את שם כלל ההעברה במקום את כתובת ה-IP בשדה --routing-policy-data.

API

משתמשים בשיטה resourceRecordSets.create.

WRR

POST https://dns.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
{
  "name": "RRSET_NAME",
  "type": "RRSET_TYPE",
  "ttl": TTL,
  "routingPolicy": {
    "wrr": {
      "items": [
        {
          "weight": WEIGHT,
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "LOAD_BALANCER_TYPE"
                "ipAddress": "IP_ADDRESS"
                "port": "PORT_NUMBER"
                "ipProtocol": "IP_PROTOCOL"
                "networkUrl": "NETWORK_URL"
                "project": "PROJECT_ID"
                "region": "REGION"
              }
            ]
          }
        },
        {
          "weight": WEIGHT,
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "LOAD_BALANCER_TYPE"
                "ipAddress": "IP_ADDRESS"
                "port": "PORT_NUMBER"
                "ipProtocol": "IP_PROTOCOL"
                "networkUrl": "NETWORK_URL"
                "project": "PROJECT_ID"
                "region": "REGION"
              }
            ]
          }
        }
      ]
    }
  }
}

מחליפים את מה שכתוב בשדות הבאים:

‫PROJECT_ID: מזהה הפרויקט
‫MANAGED_ZONE: התחום המנוהל שאליו משויך ResourceRecordSet, למשל service-zone. השם של ResourceRecordSet חייב להסתיים בסיומת של שם ה-DNS של התחום המנוהל
‫RRSET_NAME: שם ה-DNS שתואם לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, למשל service.example.com
‫RRSET_TYPE: סוג רשומת המשאבים של ResourceRecordSet, למשל A
‫TTL: ה-TTL, בשניות, שבו מפענח ה-DNS שומר במטמון את ResourceRecordSet, למשל 30
‫WEIGHT: למדיניות WRR, רשימה מופרדת באמצעות נקודה-פסיק בפורמט ${weight_percent}=${rrdatas}, כמו .8=10.128.1.1;.2=10.130.1.1. מציינים את המשקל כמספר עשרוני לא שלילי. הערה: חובה לציין את המשקל כמספר לא שלילי. יחס תנועת הגולשים שמופנית ליעד מחושב על סמך היחס בין המשקל האישי לבין המשקל הכולל של כל המשקלים.
‫LOAD_BALANCER_TYPE: סוג מאזן העומסים, למשל regionalL4ilb,‏ globalL7ilb או regionalL7ilb. ההגדרה הזו היא אופציונלית.
‫IP_ADDRESS: כתובת ה-IP שהכלל להעברת תעבורה משרת
PORT_NUMBER: זהו מספר היציאה
‫IP_PROTOCOL: מגדיר את הפרוטוקול שמשמש לבדיקת תקינות. האפשרויות התקינות הן tcp ו-udp.
‫NETWORK_URL: כתובת ה-URL ברשת שאליה חל כלל ההעברה הזה
‫REGION: האזור שבו יצרתם את כלל ההעברה

מיקום גיאוגרפי

POST https://dns.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
{
  "name": "RRSET_NAME",
  "type": "RRSET_TYPE",
  "ttl": TTL,
  "routingPolicy": {
    "geo": {
      "items": [
        {
          "location": "LOCATION",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "LOAD_BALANCER_TYPE"
                "ipAddress": "IP_ADDRESS"
                "port": "PORT_NUMBER"
                "ipProtocol": "IP_PROTOCOL"
                "networkUrl": "NETWORK_URL"
                "project": "PROJECT_ID"
                "region": "REGION"
              }
            ]
          }
        },
        {
          "location": "LOCATION",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "LOAD_BALANCER_TYPE"
                "ipAddress": "IP_ADDRESS"
                "port": "PORT_NUMBER"
                "ipProtocol": "IP_PROTOCOL"
                "networkUrl": "NETWORK_URL"
                "project": "PROJECT_ID"
                "region": "REGION"
              }
            ]
          }
        }
      ]
    }
  }
}

מחליפים את מה שכתוב בשדות הבאים:

‫PROJECT_ID: מזהה הפרויקט
‫MANAGED_ZONE: התחום המנוהל שאליו משויך ResourceRecordSet, למשל service-zone. השם של ResourceRecordSet חייב להסתיים בסיומת של שם ה-DNS של התחום המנוהל
‫RRSET_NAME: שם ה-DNS שתואם לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, למשל service.example.com
‫RRSET_TYPE: סוג רשומת המשאבים של ResourceRecordSet, למשל A
‫TTL: ה-TTL, בשניות, שבו מפענח ה-DNS שומר במטמון את ResourceRecordSet, למשל 30
‫LOCATION: במדיניות GEO, המיקום הגיאוגרפי שעבורו צריך ליצור את המדיניות, למשל asia-east1
‫LOAD_BALANCER_TYPE: סוג מאזן העומסים, למשל regionalL4ilb,‏ globalL7ilb או regionalL7ilb. ההגדרה הזו היא אופציונלית.
‫IP_ADDRESS: כתובת ה-IP שהכלל להעברת תעבורה משרת
‫PORT_NUMBER: מספר היציאה של מאזן העומסים הפנימי
‫IP_PROTOCOL: מגדיר את הפרוטוקול שמשמש לבדיקת תקינות. האפשרויות התקינות הן tcp ו-udp.
‫NETWORK_URL: כתובת ה-URL ברשת שאליה חל כלל ההעברה הזה
‫REGION: האזור שבו יצרתם את כלל ההעברה

מעבר לגיבוי (Failover)

באפשרות המעבר לגיבוי, Cloud DNS תומך רק במדיניות GEO.

POST https://dns.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
{
  "name": "RRSET_NAME",
  "type": "RRSET_TYPE",
  "ttl": TTL,
  "routingPolicy": {
    "primaryBackup": {
      "trickleTraffic": TRICKLE_TRAFFIC,
      "primaryTargets": {
        "internalLoadBalancers": [
          {
            "ipAddress": "IP_ADDRESS"
            "ipProtocol": "IP_PROTOCOL"
            "loadBalancerType": "LOAD_BALANCER_TYPE"
            "networkUrl": "NETWORK_URL"
            "port": "PORT_NUMBER"
            "project": "PROJECT_ID"
            "region": "REGION"
          }
        ]
      },
      "backupGeoTargets": {
        "enableFencing": ENABLE_FENCING,
        "items": [
          {
            "location": "LOCATION",
            "rrdatas": [
              "RRDATA"
            ]
          },
          {
            "location": "LOCATION",
            "rrdatas": [
              "RRDATA"
            ]
          }
        ]
      }
    }
  }
}

מחליפים את מה שכתוב בשדות הבאים:

‫PROJECT_ID: מזהה הפרויקט
‫MANAGED_ZONE: התחום המנוהל שאליו משויך ResourceRecordSet, למשל service-zone. השם של ResourceRecordSet חייב להסתיים בסיומת של שם ה-DNS של התחום המנוהל
‫RRSET_NAME: שם ה-DNS שתואם לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, למשל service.example.com
‫RRSET_TYPE: סוג רשומת המשאבים של ResourceRecordSet, למשל A
‫TTL: ה-TTL, בשניות, שבו מפענח ה-DNS שומר במטמון את ResourceRecordSet, למשל 30
‫TRICKLE_TRAFFIC: היחס של התנועה לשליחה ליעדי הגיבוי גם כשהיעדים הראשיים תקינים. היחס חייב להיות בין 0 ל-1, למשל 0.1
‫IP_ADDRESS: כתובת ה-IP שהכלל להעברת תעבורה משרת
PORT_NUMBER: זהו מספר היציאה
‫IP_PROTOCOL: מגדיר את הפרוטוקול שמשמש לבדיקת תקינות. האפשרויות התקינות הן tcp ו-udp.
‫NETWORK_URL: כתובת ה-URL ברשת שאליה חל כלל ההעברה הזה
‫PORT_NUMBER: מספר היציאה של מאזן העומסים הפנימי
‫REGION: האזור שבו יצרתם את כלל ההעברה
‫ENABLE_FENCING: במדיניות הניתוב של GEO, ההגדרה הזו קובעת אם התנועה תעבור אוטומטית לאזור אחר אם כל נקודות הקצה באזור מסוים לא תקינות. כשההגדרה הזו מופעלת, Cloud DNS תמיד מפנה שאילתות לאזור הקרוב ביותר, גם אם כל נקודות הקצה באזור הזה לא תקינות. אם לא מגדירים את ההגדרה הזו, Cloud DNS מפנה שאילתות לאזור הקרוב הבא אם כל נקודות הקצה באזור מסוים לא תקינות. ברירת המחדל היא false.
‫LOCATION: במדיניות GEO, המיקום הגיאוגרפי שעבורו צריך ליצור את המדיניות, למשל asia-east1
‫WEIGHT: למדיניות WRR, רשימה מופרדת באמצעות נקודה-פסיק בפורמט ${weight_percent}=${rrdatas}, כמו .8=10.128.1.1;.2=10.130.1.1. צריך לציין את המשקל כמספר עשרוני לא שלילי.
הערה: המשקל חייב להיות מספר לא שלילי. יחס תנועת הגולשים שמופנית ליעד מחושב על סמך היחס בין המשקל האישי לבין הסכום הכולל של כל המשקלים.
‫RRDATA: ערך שרירותי שמשויך לקבוצת רשומות של המשאב, כמו 198.51.100.5. אפשר גם להזין כמה ערכים, כמו rrdata1 rrdata2 rrdata3, למשל 198.51.100.1 203.0.113.1...

יצירת מדיניות ניתוב DNS לתחומים ציבוריים

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

המסוף

התחלת ההגדרה

נכנסים לדף Cloud DNS zones במסוף Google Cloud .

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

נתוני בסיס

אופציונלי: בדף Create record set with routing policy (יצירת קבוצת רשומות עם מדיניות ניתוב), בשדה DNS name (שם DNS), מזינים תת-דומיין של שם ה-DNS שמולא מראש – לדוגמה, mail. הנקודה בסוף מתווספת אוטומטית.

חשוב: הוספת התו @ בשדה הזה גורמת לכך שהרשומה תיכשל.
בוחרים אפשרות בשדה Resource record type.
בשדה TTL, מזינים ערך מספרי לאורך החיים של רשומת המשאב, כלומר משך הזמן שבו אפשר לשמור אותה במטמון. הערך חייב להיות מספר שלם חיובי.
אופציונלי: בשדה יחידת TTL, בוחרים את יחידת הזמן – לדוגמה, minutes. ערך ברירת המחדל הוא minutes.
לוחצים על הבא.

סוג מדיניות תכנון המסלול

בקטע Routing policy (מדיניות ניתוב), בוחרים באפשרות Weighted round robin (סדר סיבובי משוקלל), Geolocation (מיקום גאוגרפי) או Failover (יתירות כשל).
לוחצים על הבא.

נתונים של מדיניות תכנון מסלול

WRR

בקטע משקל, מזינים את המשקל שמתאים לקטע המשנה הזה בנתוני רשומת המשאב (RR).

המשקל הזה חייב להיות מספר לא שלילי בין 0.0 ל-1000.0. היחס בין נפח התנועה שמופנה ליעד מחושב על סמך היחס בין המשקל האישי לבין המשקל הכולל של כל המשקלים. לדוגמה, אם ליעד א' יש משקל של 25 וליעד ב' יש משקל של 75, והמשקל הכולל הוא 100, מערכת Cloud DNS תנתב 25/100 = 0.25 (25 אחוז) מהתנועה הכוללת ליעד א', ו-75/100= 0.75 (75 אחוז) ליעד ב'.
בקטע External IP addresses:
1. בשדה כתובת IP , מזינים כתובת IP חיצונית.
2. אופציונלי: כדי לבחור כתובת IP חיצונית של Google Cloud משאב בפרויקט הנוכחי, לוחצים על Select.
3. כדי להפעיל את בדיקת התקינות, בוחרים באפשרות Health checking 1.
4. אופציונלי: כדי להוסיף עוד כתובת IP חיצונית, לוחצים על הוספת כתובת IP.
5. לוחצים על סיום.
אם הפעלתם בדיקת תקינות בשלב הקודם, ברשימה בדיקת תקינות, בוחרים בדיקת תקינות או יוצרים בדיקה חדשה לפי השלבים הבאים.
1. לוחצים על יצירת בדיקת תקינות חדשה.
2. בשדה Name, מזינים שם לבדיקת תקינות.
3. אופציונלי: בשדה Description, מזינים תיאור לבדיקת תקינות.
4. בשדה Source regions (אזורי מקור), בוחרים שלושה Google Cloudאזורים שמהם רוצים לשלוח בדיקות תקינות.
5. אופציונלי: בוחרים פרוטוקול מהרשימה Protocol.
6. בשדה יציאה, מזינים מספר יציאה.
  
  הפרוטוקול ומספר היציאה קובעים איך Cloud DNS שולח את בדיקות התקינות.
7. אופציונלי: כדי להגדיר בדיקת תקינות מבוססת-תוכן, בשדה תגובה, מציינים מחרוזת תגובה צפויה, כל אחת באורך של עד 1,024 תווי ASCII (בייט יחיד).
8. אופציונלי: כדי להפעיל את היומנים של בדיקת התקינות, בוחרים באפשרות מופעל בקטע יומנים.
9. בשדה Check interval (מרווח בדיקה), מזינים את מרווח הזמן בשניות בין בדיקות תקינות. מרווח הבדיקה הוא משך הזמן שחל מתחילת בדיקה אחת שהונפקה על ידי בודק אחד ועד לתחילת הבדיקה הבאה שהונפקה על ידי אותו בודק.
10. בקטע Timeout, מזינים את משך הזמן בשניות שרוצים ש-Google Cloud ימתין לתגובה לבדיקה.
11. בקטע Healthy threshold (סף תקין), מזינים את מספר התוצאות הרצופות של בדיקת תקינות שצריך לקבל מהקצה העורפי כדי שהוא ייחשב כתקין.
12. בסף לא תקין, מזינים את מספר התוצאות הרצופות של בדיקת תקינות שנכשלה כדי שהקצה העורפי ייחשב כלא תקין.
13. לוחצים על יצירה.
לחצו על Next.

מיקום גיאוגרפי

בקטע גידור גיאוגרפי, בוחרים באפשרות מושבת או מופעל. הפעלת גידור גיאוגרפי מגבילה את התנועה למיקום גיאוגרפי ספציפי גם אם כל נקודות הקצה במיקום הגיאוגרפי הזה לא תקינות.
בשדה אזור מקור, בוחרים אזור מקור תקין Google Cloud.
בקטע External IP addresses (כתובות IP חיצוניות), מבצעים את הפעולות הבאות:
1. בשדה כתובת IP , מזינים כתובת IP חיצונית.
2. אופציונלי: כדי לבחור כתובת IP חיצונית של משאב Google Cloud בפרויקט הנוכחי, לוחצים על Select.
3. כדי להפעיל את בדיקת התקינות, בוחרים באפשרות Health checking 1.
4. אופציונלי: כדי להוסיף עוד כתובת IP חיצונית, לוחצים על הוספת כתובת IP.
5. לוחצים על סיום.
אם הפעלתם בדיקת תקינות בשלב הקודם, ברשימה בדיקת תקינות, בוחרים בדיקת תקינות או יוצרים בדיקה חדשה לפי השלבים הבאים.
1. לוחצים על יצירת בדיקת תקינות חדשה.
2. בשדה Name, מזינים שם לבדיקת תקינות.
3. אופציונלי: בשדה Description, מזינים תיאור לבדיקת תקינות.
4. בשדה Source regions (אזורי מקור), בוחרים שלושה Google Cloudאזורים שמהם רוצים לשלוח בדיקות תקינות.
5. אופציונלי: בוחרים פרוטוקול מהרשימה Protocol.
6. בשדה יציאה, מזינים מספר יציאה.
  
  הפרוטוקול ומספר היציאה קובעים איך Cloud DNS שולח את בדיקות התקינות.
7. אופציונלי: כדי להגדיר בדיקת תקינות מבוססת-תוכן, בשדה תגובה, מציינים מחרוזת תגובה צפויה, כל אחת באורך של עד 1,024 תווי ASCII (בייט יחיד).
8. אופציונלי: כדי להפעיל את היומנים של בדיקת התקינות, בוחרים באפשרות מופעל בקטע יומנים.
9. בשדה Check interval (מרווח בדיקה), מזינים את מרווח הזמן בשניות בין בדיקות תקינות. מרווח הבדיקה הוא משך הזמן שחל מתחילת בדיקה אחת שהונפקה על ידי בודק אחד ועד לתחילת הבדיקה הבאה שהונפקה על ידי אותו בודק.
10. בקטע Timeout, מזינים את משך הזמן בשניות שרוצים ש-Google Cloud ימתין לתגובה לבדיקה.
11. בקטע Healthy threshold (סף תקין), מזינים את מספר התוצאות הרצופות של בדיקת תקינות שצריך לקבל מהקצה העורפי כדי שהוא ייחשב כתקין.
12. בסף לא תקין, מזינים את מספר התוצאות הרצופות של בדיקת תקינות שנכשלה כדי שהקצה העורפי ייחשב כלא תקין.
13. לוחצים על יצירה.
לחצו על Next.

מעבר לגיבוי (Failover)

בקטע Primary external IP address target, בשדה IP address, מזינים את כתובת ה-IP החיצונית הראשית שנבדקת לגבי תקינות ברשומה הזו.
אופציונלי:כדי לבחור כתובת IP חיצונית ראשית של משאב בפרויקט הנוכחי, לוחצים על Select. Google Cloud
אופציונלי: כדי להוסיף עוד כתובת IP חיצונית ראשית, לוחצים על הוספת יעד. כש-DNSSEC מופעל, אפשר להוסיף רק כתובת IP חיצונית ראשית אחת כיעד .
בקטע Backup geolocation policy (מדיניות גיבוי של מיקום גיאוגרפי), מבצעים את הפעולות הבאות:
1. בקטע גידור גיאוגרפי, בוחרים באפשרות מושבת או מופעל. הפעלת גידור גיאוגרפי מגבילה את התנועה למיקום גיאוגרפי ספציפי גם אם כל נקודות הקצה במיקום הגיאוגרפי הזה לא תקינות.
2. בשדה אזור מקור, בוחרים אזור מקור תקין Google Cloud.
3. בקטע External IP addresses (כתובות IP חיצוניות), מבצעים את הפעולות הבאות:
  1. בשדה כתובת IP , מזינים כתובת IP חיצונית.
  2. אופציונלי: כדי לבחור כתובת IP חיצונית של Google Cloud משאב בפרויקט הנוכחי, לוחצים על Select.
  3. כדי להפעיל את בדיקת התקינות, בוחרים באפשרות Health checking 1.
  4. אופציונלי: כדי להוסיף עוד כתובת IP חיצונית, לוחצים על הוספת כתובת IP.
4. לוחצים על סיום.
אם הפעלתם בדיקת תקינות בשלב הקודם, בוחרים בדיקת תקינות ברשימה Health check (בדיקת תקינות).

אם אין לכם בדיקת תקינות קיימת, אתם יכולים ליצור בדיקת תקינות חדשה.
1. לוחצים על יצירת בדיקת תקינות חדשה.
2. בשדה Name, מזינים שם לבדיקת תקינות.
3. אופציונלי: בשדה Description, מזינים תיאור לבדיקת תקינות.
4. בשדה Source regions (אזורי מקור), בוחרים שלושה Google Cloudאזורים שמהם רוצים לשלוח בדיקות תקינות.
5. אופציונלי: בוחרים פרוטוקול מהרשימה Protocol.
6. בשדה יציאה, מזינים מספר יציאה.
הפרוטוקול ומספר היציאה קובעים איך Cloud DNS שולח את בדיקות התקינות.
1. אופציונלי: כדי להגדיר בדיקת תקינות מבוססת-תוכן, בשדה תגובה, מציינים מחרוזת תגובה צפויה, כל אחת באורך של עד 1,024 תווי ASCII (בייט יחיד).
2. אופציונלי: כדי להפעיל את היומנים של בדיקת התקינות, בוחרים באפשרות מופעל בקטע יומנים.
3. בשדה Check interval (מרווח בדיקה), מזינים את מרווח הזמן בשניות בין בדיקות תקינות. מרווח הבדיקה הוא משך הזמן שחל מתחילת בדיקה אחת שהונפקה על ידי בודק אחד ועד לתחילת הבדיקה הבאה שהונפקה על ידי אותו בודק.
4. בקטע Timeout, מזינים את משך הזמן בשניות שרוצים ש-Google Cloud ימתין לתגובה לבדיקה.
5. בקטע Healthy threshold (סף תקין), מזינים את מספר התוצאות הרצופות של בדיקת תקינות שצריך לקבל מהקצה העורפי כדי שהוא ייחשב כתקין.
6. בסף לא תקין, מזינים את מספר התוצאות הרצופות של בדיקת תקינות שנכשלה כדי שהקצה העורפי ייחשב כלא תקין.
7. לוחצים על יצירה.
בשדה Trickle traffic (%), מזינים את אחוז פיזור תעבורת הנתונים שנשלחת ליעדי הגיבוי, ללא קשר לסטטוס של בדיקת התקינות של היעדים העיקריים.
ברשימה Health check, בוחרים בדיקת תקינות.
לוחצים על הבא.

בדיקה ויצירה

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

gcloud

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

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

מריצים את הפקודה gcloud beta compute health-checks create:
```
gcloud beta compute health-checks create PROTOCOL HEALTH_CHECK_NAME \
    --global \
    --check-interval=CHECK_INTERVAL \
    --source-regions=SOURCE_REGIONS \
    --port=PORT_NUMBER
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROTOCOL: הפרוטוקול שמשמש לבדיקת תקינות. האפשרויות התקפות הן http, https, ssl או tcp.
- ‫HEALTH_CHECK_NAME: השם של בדיקת תקינות.
- ‫CHECK_INTERVAL: משך הזמן מתחילת החיבור של מערכת בדיקת תקינות אחת ועד לתחילת החיבור של הבדיקה הבאה. היחידות הן שניות. הערך CHECK_INTERVAL חייב להיות בין 30 ל-300 שניות.
- ‫SOURCE_REGIONS: רשימה מופרדת בפסיקים שלGoogle Cloud אזורים שמהם רוצים לשלוח בדיקות תקינות.
- ‫PORT_NUMBER: מספר היציאה של בקשות בדיקת תקינות.
כדי ליצור ResourceRecordSet ולהחיל עליו מדיניות ניתוב, מריצים את הפקודה gcloud beta dns record-sets create.
WRR
gcloud beta dns record-sets create RRSET_NAME \ --ttl=TTL \ --type=RRSET_TYPE \ --zone=MANAGED_ZONE \ --routing-policy-type=WRR \ --routing-policy-data=ROUTING_POLICY_DATA \ --health-check=HEALTH_CHECK_NAME
מחליפים את מה שכתוב בשדות הבאים:
- ‫RRSET_NAME: שם ה-DNS שתואם לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, כמו service.example.com.
- ‫TTL: משך הזמן ל-TTL, בשניות, שבו מפענח ה-DNS שומר במטמון את ResourceRecordSet, למשל 30.
- ‫RRSET_TYPE: סוג רשומת המשאב של ResourceRecordSet, למשל A.
- ‫MANAGED_ZONE: האזור המנוהל שאליו משויך ResourceRecordSet, למשל service-zone. השם של ResourceRecordSet הזה צריך להסתיים בסיומת של שם ה-DNS של האזור המנוהל.
- ‫ROUTING_POLICY_DATA: נתוני מדיניות הניתוב. מזינים רשימה מופרדת באמצעות נקודה-פסיק בפורמט ${weight_percent}:${rrdatas}, לדוגמה .8=203.0.113.1;.2=198.51.100.1. מציינים את המשקל כמספר עשרוני לא שלילי. המשקל חייב להיות מספר לא שלילי בין 0 ל-1000.
- ‫HEALTH_CHECK_NAME: השם של בדיקת תקינות שיצרתם בשלב הקודם.
מיקום גיאוגרפי
gcloud beta dns record-sets create RRSET_NAME \ --ttl=TTL \ --type=RRSET_TYPE \ --zone=MANAGED_ZONE \ --routing-policy-type=GEO \ --routing-policy-data=ROUTING_POLICY_DATA \ --health-check=HEALTH_CHECK_NAME
מחליפים את מה שכתוב בשדות הבאים:
- ‫RRSET_NAME: שם ה-DNS שתואם לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, כמו service.example.com.
- ‫TTL: ה-TTL, בשניות, שבו מפענח ה-DNS שומר במטמון את ResourceRecordSet, למשל 30.
- ‫RRSET_TYPE: סוג רשומת המשאב של ResourceRecordSet, למשל A.
- ‫MANAGED_ZONE: האזור המנוהל שאליו משויך ResourceRecordSet, למשל service-zone. השם של ResourceRecordSet הזה צריך להסתיים בסיומת של שם ה-DNS של האזור המנוהל.
- ‫ROUTING_POLICY_DATA: נתוני מדיניות הניתוב. מזינים רשימה מופרדת באמצעות נקודה-פסיק בפורמט ${region}=${IP_address},${IP_address}, לדוגמה asia-east1=198.51.100.1;us-central1=203.0.113.1, 203.0.113.2. אפשר לציין כמה כתובות IP לאזור אחד על ידי הוספת כתובות IP מופרדות בפסיקים. שמות של כללי העברה הם ערכים קבילים ומובילים לבדיקת תקינות.
- ‫HEALTH_CHECK_NAME: השם של בדיקת תקינות שיצרתם בשלב הקודם.
מיקום גיאוגרפי עם גבול וירטואלי
gcloud beta dns record-sets create RRSET_NAME \ --ttl=TTL \ --type=RRSET_TYPE \ --zone=MANAGED_ZONE \ --routing-policy-type=GEO \ --routing-policy-data=ROUTING_POLICY_DATA \ --health-check=HEALTH_CHECK_NAME \ --enable-geo-fencing
מחליפים את מה שכתוב בשדות הבאים:
- ‫RRSET_NAME: שם ה-DNS שתואם לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, כמו service.example.com.
- ‫TTL: ה-TTL, בשניות, שבו מפענח ה-DNS שומר במטמון את ResourceRecordSet, למשל 30.
- ‫RRSET_TYPE: סוג רשומת המשאב של ResourceRecordSet, למשל A.
- ‫MANAGED_ZONE: האזור המנוהל שאליו משויך ResourceRecordSet, למשל service-zone. השם של ResourceRecordSet הזה צריך להסתיים בסיומת של שם ה-DNS של האזור המנוהל.
- ‫ROUTING_POLICY_DATA: נתוני מדיניות הניתוב. מזינים רשימה מופרדת באמצעות נקודה-פסיק בפורמט ${region}=${IP_address}, לדוגמה asia-east1=198.51.100.1;us-central1=203.0.113.1. אפשר לציין כמה כתובות IP לאזור אחד על ידי הוספת כתובות IP מופרדות בפסיקים. שמות של כללי העברה הם ערכים קבילים וגורמים לבדיקת תקינות.
- ‫HEALTH_CHECK_NAME: השם של בדיקת תקינות שיצרתם בשלב הקודם.
  
  ‫--enable-geo-fencing: במדיניות הניתוב של GEO, ההגדרה הזו קובעת אם התנועה תעבור אוטומטית לאזור אחר אם כל נקודות הקצה באזור מסוים לא תקינות. אם מגדירים את האפשרות הזו, Cloud DNS תמיד מפנה שאילתות לאזור הקרוב ביותר, גם אם כל נקודות הקצה באזור הזה לא תקינות. כדי להשבית את הגידור הגיאוגרפי, משתמשים ב---no-enable-geo-fencing. אם לא מגדירים את האפשרות הזו, Cloud DNS מפנה שאילתות לאזור הקרוב הבא אם כל נקודות הקצה באזור מסוים לא תקינות. ברירת המחדל היא false.
מעבר לגיבוי (Failover)
gcloud beta dns record-sets create RRSET_NAME \ --ttl=TTL \ --type=RRSET_TYPE \ --zone=MANAGED_ZONE \ --routing-policy-type=FAILOVER \ --routing-policy-primary-data=ROUTING_POLICY_PRIMARY_DATA \ --routing-policy-backup-data=ROUTING_POLICY_BACKUP_DATA \ --routing-policy-backup-data-type=ROUTING_POLICY_BACKUP_DATA_TYPE \ --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO \ --health-check=HEALTH_CHECK_NAME
מחליפים את מה שכתוב בשדות הבאים:
- ‫RRSET_NAME: שם ה-DNS שתואם לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, כמו service.example.com.
- ‫TTL: ה-TTL, בשניות, שבו מפענח ה-DNS שומר במטמון את ResourceRecordSet, למשל 30
- ‫RRSET_TYPE: סוג רשומת המשאב של ResourceRecordSet, למשל A.
- ‫MANAGED_ZONE: האזור המנוהל שאליו משויך ResourceRecordSet, למשל service-zone. השם של ResourceRecordSet הזה צריך להסתיים בסיומת של שם ה-DNS של האזור המנוהל.
- ‫ROUTING_POLICY_PRIMARY_DATA: יעד ראשי לשימוש בכללי ניתוב של FAILOVER. היעד הזה צריך להיות הפניה לכלל העברה אחד או יותר, כמו forwarding-rule-1. כל עוד לפחות אחד מכללי ההעברה האלה תקין, כתובות ה-IP של כל כללי ההעברה התקינים משמשות למענה על שאילתות לגבי השם הזה.
- ‫ROUTING_POLICY_BACKUP_DATA: יעד הגיבוי שבו יש להשתמש עבור מדיניות הניתוב FAILOVER. יעדי ההעברה האלה משמשים כשהמצב של כל כללי ההעברה שצוינו ב---routing-policy-primary-data הוא לא תקין. ‫Cloud DNS תומך רק ביעדי גיבוי שמבוססים על מיקום גיאוגרפי. הפורמט של השדה הזה זהה לפורמט של --routing-policy-data כשהערך הוא --routing-policy-type = 'GEO', למשל asia-east1=forwarding-rule-2.
- ‫ROUTING_POLICY_BACKUP_DATA_TYPE: במדיניות ניתוב של FAILOVER, סוג מדיניות הניתוב שנתוני הגיבוי משתמשים בה. הערך חייב להיות GEO.
- ‫BACKUP_DATA_TRICKLE_RATIO: היחס של התנועה שתישלח ליעדי הגיבוי, גם כשהיעדים הראשיים תקינים. היחס צריך להיות בין 0 ל-1, למשל 0.1. ערך ברירת המחדל הוא 0.
- ‫HEALTH_CHECK_NAME: השם של בדיקת תקינות שיצרתם בשלב הקודם.

API

כדי להפעיל בדיקות תקינות במדיניות הניתוב של DNS לאזורים ציבוריים, משתמשים בשיטה healthChecks.insert.
כדי ליצור ResourceRecordSet ולהחיל עליו מדיניות ניתוב, משתמשים ב-method ‏resourceRecordSets.create.
WRR
POST https://dns.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets { "name": "RRSET_NAME", "type": "RRSET_TYPE", "ttl": TTL, "routingPolicy": { "healthCheck": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME" "wrr": { "items": [ { "weight": WEIGHT, "rrdata": ["RRDATA"], "healthCheckedTargets": { "externalEndpoints": ["EXTERNAL_ENDPOINTS"] } }, { "weight": WEIGHT, "rrdata": ["RRDATA"], "healthCheckedTargets": { "externalEndpoints": ["EXTERNAL_ENDPOINTS"] } } ] } } }
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID: מזהה הפרויקט
- ‫MANAGED_ZONE: התחום המנוהל שאליו משויך ResourceRecordSet, למשל service-zone. השם של ResourceRecordSet חייב להסתיים בסיומת של שם ה-DNS של התחום המנוהל.
- ‫RRSET_NAME: שם ה-DNS שתואם לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, כמו service.example.com.
- ‫RRSET_TYPE: סוג רשומת המשאב של ResourceRecordSet, למשל A.
- ‫TTL: משך הזמן ל-TTL, בשניות, שבו ה-resolver שומר במטמון את ResourceRecordSet, למשל 30.
- ‫HEALTH_CHECK_NAME: השם של בדיקת תקינות.
- ‫WEIGHT: במדיניות WRR, רשימה של ערכים מופרדים באמצעות נקודה-פסיק בפורמט ${weight_percent}=${rrdatas}, למשל .8=10.128.1.1;.2=10.130.1.1. צריך לציין את המשקל כמספר עשרוני לא שלילי. הערה: המשקל חייב להיות מספר לא שלילי. יחס תנועת הגולשים שמופנית ליעד מחושב על סמך היחס בין המשקל האישי לבין המשקל הכולל של כל המשקלים.
- ‫RRDATA: ערך שרירותי שמשויך לקבוצת רשומות של המשאב, כמו 198.51.100.5. אפשר גם להזין כמה ערכים, כמו rrdata1,rrdata2,rrdata3, לדוגמה 198.51.100.1,203.0.113.1.
- ‫EXTERNAL_ENDPOINTS: כתובות ה-IP באינטרנט שצריך לבדוק את תקינותן.
מיקום גיאוגרפי
POST https://dns.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets { "name": "RRSET_NAME", "type": "RRSET_TYPE", "ttl": TTL, "routingPolicy": { "healthCheck": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME" "geo": { "enableFencing": ENABLE_FENCING "items": [ { "location": "LOCATION", "rrdata": ["RRDATA"], "healthCheckedTargets": { "externalEndpoints": ["EXTERNAL_ENDPOINTS"] } }, { "location": "LOCATION", "rrdata": ["RRDATA"], "healthCheckedTargets": { "externalEndpoints": ["EXTERNAL_ENDPOINTS"] } } ] } } }
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID: מזהה הפרויקט
- ‫MANAGED_ZONE: התחום המנוהל שאליו משויך ResourceRecordSet, למשל service-zone. השם של ResourceRecordSet חייב להסתיים בסיומת של שם ה-DNS של התחום המנוהל.
- ‫RRSET_NAME: שם ה-DNS שתואם לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, כמו service.example.com.
- ‫RRSET_TYPE: סוג רשומת המשאב של ResourceRecordSet, למשל A.
- ‫TTL: משך הזמן ל-TTL, בשניות, שבו ה-resolver שומר במטמון את ResourceRecordSet, למשל 30.
- ‫HEALTH_CHECK_NAME: השם של בדיקת תקינות.
- ‫ENABLE_FENCING: במדיניות הניתוב GEO, ההגדרה הזו קובעת אם התנועה תעבור אוטומטית לאזור אחר אם כל נקודות הקצה באזור מסוים לא תקינות. כשההגדרה הזו מופעלת, Cloud DNS תמיד מפנה שאילתות לאזור הקרוב ביותר, גם אם כל נקודות הקצה באזור הזה לא תקינות. אם לא מגדירים את האפשרות הזו, Cloud DNS מפנה שאילתות לאזור הקרוב הבא אם כל נקודות הקצה באזור מסוים לא תקינות. האפשרויות הקבילות הן true ו-false. הגדרת ברירת המחדל היא false.
- ‫LOCATION: במדיניות GEO, המיקום הגיאוגרפי שעבורו צריך ליצור את המדיניות, כמו asia-east1.
- ‫RRDATA: ערך שרירותי שמשויך לקבוצת רשומות של המשאב, כמו 198.51.100.5. אפשר גם להזין כמה ערכים, כמו rrdata1,rrdata2,rrdata3, לדוגמה 198.51.100.1,203.0.113.1.
- ‫EXTERNAL_ENDPOINTS: כתובות ה-IP באינטרנט שצריך לבדוק את תקינותן.
מעבר לגיבוי (Failover)
באפשרות המעבר לגיבוי, Cloud DNS תומך רק במדיניות GEO.
POST https://dns.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets { "name": "RRSET_NAME", "type": "RRSET_TYPE", "ttl": TTL, "routingPolicy": { "healthCheck": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME" "primaryBackup": { "trickleTraffic": TRICKLE_TRAFFIC, "primaryTargets": { "rrdata": ["RRDATA"] }, "backupGeoTargets": { "enableFencing": ENABLE_FENCING, "items": [ { "location": "LOCATION", "rrdatas": ["RRDATA] }, { "location": "LOCATION", "rrdatas": ["RRDATA", "RRDATA"] } ] } } } }
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID: מזהה הפרויקט
- ‫MANAGED_ZONE: התחום המנוהל שאליו משויך ResourceRecordSet, למשל service-zone. השם של ResourceRecordSet חייב להסתיים בסיומת של שם ה-DNS של התחום המנוהל.
- ‫RRSET_NAME: שם ה-DNS שתואם לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, כמו service.example.com.
- ‫RRSET_TYPE: סוג רשומת המשאב של ResourceRecordSet, למשל A.
- ‫TTL: משך הזמן ל-TTL, בשניות, שבו ה-resolver שומר במטמון את ResourceRecordSet, למשל 30.
- ‫HEALTH_CHECK_NAME: השם של בדיקת תקינות.
- ‫TRICKLE_TRAFFIC: היחס של התנועה לשליחה ליעדי הגיבוי גם כשהיעדים הראשיים תקינים. היחס צריך להיות בין 0 ל-1, למשל 0.1.
- ‫LOCATION: במדיניות GEO, המיקום הגיאוגרפי שעבורו צריך ליצור את המדיניות, כמו asia-east1.
- ‫RRDATA: ערך שרירותי שמשויך לקבוצת רשומות של המשאב, כמו 198.51.100.5. אפשר גם להזין כמה ערכים, rrdata1,rrdata2,rrdata3, כמו 198.51.100.1,203.0.113.1.
- ‫ENABLE_FENCING: במדיניות הניתוב GEO, ההגדרה הזו קובעת אם התנועה תעבור אוטומטית לאזור אחר אם כל נקודות הקצה באזור מסוים לא תקינות. כשההגדרה הזו מופעלת, Cloud DNS תמיד מפנה שאילתות לאזור הקרוב ביותר, גם אם כל נקודות הקצה באזור הזה לא תקינות. אם לא מגדירים את האפשרות הזו, Cloud DNS מפנה שאילתות לאזור הקרוב הבא אם כל נקודות הקצה באזור מסוים לא תקינות. הגדרת ברירת המחדל היא false.

עדכון מדיניות ניתוב DNS

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

המסוף

נכנסים לדף Cloud DNS zones במסוף Google Cloud .

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

gcloud

מריצים את הפקודה gcloud dns record-sets update:

WRR

gcloud dns record-sets update RRSET_NAME \
  --ttl=TTL \
  --type=RRSET_TYPE \
  --zone=MANAGED_ZONE \
  --routing-policy-type=WRR \
  --routing-policy-data=ROUTING_POLICY_DATA \
  --enable-health-checking

מיקום גיאוגרפי

gcloud dns record-sets update RRSET_NAME \
  --ttl=TTL \
  --type=RRSET_TYPE \
  --zone=MANAGED_ZONE \
  --routing-policy-type=GEO \
  --routing-policy-data=ROUTING_POLICY_DATA \
  --enable-health-checking

מיקום גיאוגרפי עם גבול וירטואלי

gcloud dns record-sets update RRSET_NAME \
  --ttl=TTL \
  --type=RRSET_TYPE \
  --zone=MANAGED_ZONE \
  --routing-policy-type=GEO \
  --routing-policy-data=ROUTING_POLICY_DATA \
  --enable-geo-fencing
  --enable-health-checking

מעבר לגיבוי (Failover)

gcloud dns record-sets update RRSET_NAME \
  --ttl=TTL \
  --type=RRSET_TYPE \
  --zone=MANAGED_ZONE \
  --routing-policy-type=FAILOVER \
  --enable-geo-fencing \
  --routing-policy-primary-data=ROUTING_POLICY_PRIMARY_DATA \
  --routing-policy-backup-data=ROUTING_POLICY_BACKUP_DATA \
  --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO \
  --enable-health-checking

מחליפים את מה שכתוב בשדות הבאים:

‫RRSET_NAME: שם ה-DNS שתואם לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, למשל service.example.com
‫TTL: ה-TTL, בשניות, שבו מפענח ה-DNS שומר במטמון את ResourceRecordSet, למשל 30
‫RRSET_TYPE: סוג רשומת המשאבים של ResourceRecordSet, למשל A

רשימה של סוגי הרשומות הנתמכים זמינה במאמר בחירת סוגים של רשומות משאבים.
‫MANAGED_ZONE: האזור המנוהל שאליו משויך ResourceRecordSet, למשל service-zone. השם של ResourceRecordSet הזה צריך לכלול את שם ה-DNS של האזור המנוהל כסיומת
‫ROUTING_POLICY_TYPE: סוג מדיניות הניתוב.

מזינים WRR לסדר סיבובי משוקלל, GEO למיקום גיאוגרפי או FAILOVER למדיניות יתירות כשל. אי אפשר לשנות את השדה הזה אחרי שבוחרים סוג מדיניות. אפשר רק למחוק את המדיניות ולהוסיף מדיניות חדשה עם סוג אחר.
‫ROUTING_POLICY_DATA: נתוני מדיניות הניתוב
- בעמודה --routing-policy-type=WRR, מזינים רשימה של ערכים מופרדים באמצעות נקודה-פסיק בפורמט ${weight_percent}:${rrdatas}, למשל .8=203.0.113.1;.2=198.51.100.1. מציינים את המשקל כמספר עשרוני לא שלילי. יחס תנועת הגולשים שמופנית ליעד מחושב על סמך היחס בין המשקל האישי לבין המשקל הכולל של כל המשקלים. שמות של כללי העברה הם ערכים קבילים ומובילים לבדיקת תקינות.
- בעמודה --routing-policy-type=GEO, מזינים רשימה של ערכים מופרדים באמצעות נקודה-פסיק בפורמט ${region}=${IP_address}, למשל asia-east1=198.51.100.1;us-central1=203.0.113.1. כדי לציין כמה כתובות IP לאזור אחד, מוסיפים את כתובות ה-IP מופרדות בפסיק. שמות של כללי העברה הם ערכים קבילים ומובילים לבדיקת תקינות.
- בשדה --routing-policy-type=FAILOVER, מזינים את השם של כלל ההעברה שיצרתם בפורמט ${region}=${Forwarding rule name}.
  
  הערה: כשבדיקות תקינות מושבתות, ה-rrdata של `WRR` או `GEO` יכול להיות בפורמט DNS ‏ `rrdata` של RFC 1035.
  כשבדיקות התקינות מופעלות, ה-rrdata הוא הפניה לכלל העברה. ‫Cloud DNS משתמש בכתובת ה-IP של כלל ההעברה כ-rrdata. אם הוא לא תקין, Cloud DNS עוקב אחרי סטטוס התקינות של כלל ההעברה ומסיר את כלל ההעברה מהתוצאות.
‫--enable-geo-fencing: במדיניות ניתוב של GEO, ההגדרה הזו קובעת אם התנועה תעבור אוטומטית לאזורים אחרים אם כל נקודות הקצה באזור מסוים לא תקינות. כשמגדירים את האפשרות הזו, Cloud DNS תמיד מפנה שאילתות לאזור הקרוב ביותר, גם אם כל נקודות הקצה באזור הזה לא תקינות. כדי להשבית את הגידור הגיאוגרפי, משתמשים ב---no-enable-geo-fencing. אם לא מגדירים את הערך הזה, כל נקודות הקצה באזור לא תקינות, ו-Cloud DNS מפנה את השאילתות לאזור הקרוב הבא. הגדרת ברירת המחדל היא false.
‫ROUTING_POLICY_PRIMARY_DATA: היעד הראשי לשימוש במדיניות הניתוב של FAILOVER. היעד הזה צריך להיות הפניה לאחד או יותר כללי העברה, כמו forwarding-rule-1. כל עוד לפחות אחד מכללי ההעברה האלה תקין, כתובות ה-IP של כל כללי ההעברה התקינים משמשות למענה על שאילתות לגבי השם הזה.
‫ROUTING_POLICY_BACKUP_DATA: יעד הגיבוי שבו יש להשתמש עבור מדיניות הניתוב FAILOVER. יעדי ההעברה האלה משמשים כשהמצב של כל כללי ההעברה שצוינו ב---routing-policy-primary-data הוא לא תקין. ‫Cloud DNS תומך רק ביעדי גיבוי שמבוססים על מיקום גיאוגרפי. הפורמט של השדה הזה זהה לפורמט של --routing-policy-data כש--routing-policy-type = 'GEO', למשל asia-east1=forwarding-rule-2.
‫BACKUP_DATA_TRICKLE_RATIO: היחס בין התנועה שצריך לשלוח ליעדי הגיבוי גם כשהיעדים הראשיים תקינים. היחס צריך להיות בין 0 ל-1, למשל 0.1. ערך ברירת המחדל הוא 0.
‫--enable-health-checking: הפעלה של בדיקת תקינות של כללי העברה שמוגדרים כ-rrdata ל---routing-policy-data.

API

משתמשים בשיטה resourceRecordSets.patch. צריך לציין רק אחד מהמאפיינים rrset.rrdatas או rrset.routingPolicy. אם מציינים את routingPolicy, צריך לציין את השדה החדש routingPolicy במלואו.

WRR

למדיניות WRR, משתמשים בשיטה הבאה:

PATCH https://dns.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets/RRSET_NAME/RRSET_TYPE
{
  "name": "RRSET_NAME",
  "type": "RRSET_TYPE",
  "ttl": TTL,
  "routingPolicy": {
    "wrr": {
      "items": [
        {
          "weight": WEIGHT,
          "rrdatas": ["RRDATA"]
        },
        {
          "weight": WEIGHT,
          "rrdatas": ["RRDATA"]
        }
      ]
    }
  }
}

מחליפים את מה שכתוב בשדות הבאים:

‫PROJECT_ID: מזהה הפרויקט
‫MANAGED_ZONE: התחום המנוהל שאליו משויך ResourceRecordSet, למשל service-zone. השם של ResourceRecordSet חייב להסתיים בסיומת של שם ה-DNS של התחום המנוהל
‫RRSET_NAME: שם ה-DNS שתואם לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, למשל service.example.com
‫RRSET_TYPE: סוג רשומת המשאבים של ResourceRecordSet, למשל A
‫WEIGHT: למדיניות WRR, רשימה מופרדת באמצעות נקודה-פסיק בפורמט ${weight_percent}=${rrdatas}, כמו .8=10.128.1.1;.2=10.130.1.1. צריך לציין את המשקל כמספר עשרוני לא שלילי.
הערה: המשקל חייב להיות מספר לא שלילי. יחס תנועת הגולשים שמופנית ליעד מחושב על סמך היחס בין המשקל האישי לבין הסכום הכולל של כל המשקלים.
‫RRDATA: ערך שרירותי שמשויך לקבוצת רשומות של המשאב, כמו 198.51.100.5. אפשר גם להזין כמה ערכים, כמו rrdata1 rrdata2 rrdata3, למשל 198.51.100.1 203.0.113.1...

מיקום גיאוגרפי

משתמשים בשיטה הבאה:

PATCH https://dns.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets/RRSET_NAME/RRSET_TYPE
{
  "name": "RRSET_NAME",
  "type": "RRSET_TYPE",
  "ttl": TTL,
  "routingPolicy": {
    "geo": {
      "items": [
        {
          "location": "LOCATION",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "LOAD_BALANCER_TYPE"
                "ipAddress": "IP_ADDRESS"
                "port": "PORT_NUMBER"
                "ipProtocol": "IP_PROTOCOL"
                "networkUrl": "NETWORK_URL"
                "project": "PROJECT_ID"
                "region": "REGION"
              }
            ]
          }
        },
        {
          "location": "LOCATION",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "LOAD_BALANCER_TYPE"
                "ipAddress": "IP_ADDRESS"
                "port": "PORT_NUMBER"
                "ipProtocol": "IP_PROTOCOL"
                "networkUrl": "NETWORK_URL"
                "project": "PROJECT_ID"
                "region": "REGION"
              }
            ]
          }
        }
      ]
    }
  }
}

מחליפים את מה שכתוב בשדות הבאים:

‫PROJECT_ID: מזהה הפרויקט
‫MANAGED_ZONE: התחום המנוהל שאליו משויך ResourceRecordSet, למשל service-zone. השם של ResourceRecordSet חייב להסתיים בסיומת של שם ה-DNS של התחום המנוהל
‫RRSET_NAME: שם ה-DNS שתואם לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, למשל service.example.com
‫RRSET_TYPE: סוג רשומת המשאבים של ResourceRecordSet, למשל A
‫TTL: ה-TTL, בשניות, שבו מפענח ה-DNS שומר במטמון את ResourceRecordSet, למשל 30
‫LOCATION: במדיניות GEO, המיקום הגיאוגרפי שצריך לעדכן את המדיניות לגביו, למשל asia-east1
‫LOAD_BALANCER_TYPE: סוג מאזן העומסים, למשל regionalL4ilb,‏ globalL7ilb או regionalL7ilb. ההגדרה הזו היא אופציונלית.
‫IP_ADDRESS: כתובת ה-IP שהכלל להעברת תעבורה משרת
PORT_NUMBER: זהו מספר היציאה
‫IP_PROTOCOL: מגדיר את הפרוטוקול שמשמש לבדיקת תקינות. האפשרויות התקינות הן tcp ו-udp.
‫NETWORK_URL: כתובת ה-URL ברשת שאליה חל כלל ההעברה הזה
‫REGION: האזור שבו יצרתם את כלל ההעברה

מחיקת כללי מדיניות לניתוב DNS

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

המסוף

נכנסים לדף Cloud DNS zones במסוף Google Cloud .

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

gcloud

מריצים את הפקודה gcloud dns record-sets delete:

gcloud dns record-sets delete RRSET_NAME \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \

מחליפים את מה שכתוב בשדות הבאים:

‫RRSET_NAME: שם ה-DNS שתואם לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, למשל service.example.com
‫RRSET_TYPE: סוג רשומת המשאבים של ResourceRecordSet, למשל A

רשימה של סוגי הרשומות הנתמכים זמינה במאמר בחירת סוגים של רשומות משאבים.
‫MANAGED_ZONE: התחום המנוהל שאליו משויך ResourceRecordSet, למשל service-zone. השם של ResourceRecordSet חייב להסתיים בסיומת של שם ה-DNS של התחום המנוהל

API

משתמשים בשיטה resourceRecordSets.delete:

DELETE https://dns.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets/RRSET_NAME/RRSET_TYPE

מחליפים את מה שכתוב בשדות הבאים:

‫PROJECT_ID: מזהה הפרויקט
‫MANAGED_ZONE: התחום המנוהל שאליו משויך ResourceRecordSet, למשל my-zone-name. השם של ResourceRecordSet חייב להסתיים בסיומת של שם ה-DNS של התחום המנוהל
‫RRSET_NAME: שם ה-DNS שתואם לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, למשל test.example.com
‫RRSET_TYPE: סוג רשומת המשאבים של ResourceRecordSet, למשל A

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

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

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

לפני שמתחילים

ההרשאות שנדרשות למשימה הזו

יצירת כללי מדיניות לניתוב DNS עבור תחומים פרטיים

המסוף

WRR

מיקום גיאוגרפי

מעבר לגיבוי (Failover)

gcloud

WRR

מיקום גיאוגרפי

מיקום גיאוגרפי עם גבול וירטואלי

מעבר לגיבוי (Failover)

API

WRR

מיקום גיאוגרפי

מעבר לגיבוי (Failover)

יצירת מדיניות ניתוב DNS לתחומים ציבוריים

המסוף

WRR

מיקום גיאוגרפי

מעבר לגיבוי (Failover)

gcloud

WRR

מיקום גיאוגרפי

מיקום גיאוגרפי עם גבול וירטואלי

מעבר לגיבוי (Failover)

API

WRR

מיקום גיאוגרפי

מעבר לגיבוי (Failover)

עדכון מדיניות ניתוב DNS

המסוף

gcloud

WRR

מיקום גיאוגרפי

מיקום גיאוגרפי עם גבול וירטואלי

מעבר לגיבוי (Failover)

API

WRR

מיקום גיאוגרפי

מחיקת כללי מדיניות לניתוב DNS

המסוף

gcloud

API

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

הגדרת מדיניות ניתוב של DNS ובדיקות תקינות

ההרשאות שנדרשות למשימה הזו