דף זה תורגם על ידי Cloud Translation API.

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

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

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

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

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

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

הרשאות

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

תפקידים

אדמין DNS (roles/dns.admin)
שרת DNS עמית (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 unit, בוחרים את יחידת הזמן – לדוגמה, minutes. ערך ברירת המחדל הוא minutes.
לוחצים על הבא.

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

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

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

WRR

בשדה Weight, מזינים את המשקל שמתאים לקטע המשנה הזה של נתוני רשומת המשאב (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 אזורי
לוחצים על סיום.
אופציונלי: כדי להוסיף יעד נוסף לבדיקה של תקינות, לוחצים על Add target.
אופציונלי: כדי לאפשר כתובות IPv4 ללא בדיקת בריאות, מבצעים את הפעולות הבאות:
1. בוחרים באפשרות Allow IPv4 addresses without health checking.
2. בשדה IPv4 Address, מזינים כתובת IPv4.
אם רוצים להוסיף עוד קבוצה של נתוני ניתוב של מדיניות WRR, לוחצים על הוספת נתוני ניתוב.
לוחצים על הבא.

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

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

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

יתירות כשל

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

בדיקה ויצירה

לוחצים על בדיקה.
בודקים את קבוצת הרשומות ב-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, בשניות, שבו ה-Resolver מאחסן את 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, בשניות, שבו ה-Resolver מאחסן את 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, בשניות, שבו ה-Resolver מאחסן את 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 כדי להשבית את הגדרת הגבולות הגיאוגרפיים. אם לא מגדירים את ההגדרה הזו, שאילתות מופנות לאזור הקרוב ביותר כשכל נקודות הקצה באזור לא תקינות. ברירת המחדל היא false.
--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=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, בשניות, שבו ה-Resolver מאחסן את 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 כדי להשבית את הגדרת הגבולות הגיאוגרפיים. אם לא מגדירים את ההגדרה הזו, שאילתות מופנות לאזור הקרוב ביותר כשכל נקודות הקצה באזור לא תקינות. ברירת המחדל היא false.
--enable-health-checking: הדגל להפעלת בדיקת התקינות. כשמשתמשים בדגל הזה, צריך לציין את שם כלל ההעברה במקום את כתובת ה-IP בשדה --routing-policy-data.

API

משתמשים ב-method‏ resourceRecordSets.create.

WRR

POST https://www.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, בשניות, שבו ה-Resolver מאחסן את ה-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://www.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_BALANCING_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, בשניות, שבו ה-Resolver מאחסן את ה-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: האזור שבו יצרתם את כלל ההעברה

יתירות כשל

באפשרות של חלוקת עומסים בעת כשל, Cloud DNS תומך רק במדיניות GEO.

POST https://www.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, בשניות, שבו ה-Resolver מאחסן את ה-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 שמילא מראש – לדוגמה, mail. הנקודה בסוף נוספת באופן אוטומטי.

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

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

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

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

WRR

בשדה Weight, מזינים את המשקל שמתאים לקטע המשנה הזה של נתוני רשומת המשאב (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 address , מזינים כתובת IP חיצונית.
2. אופציונלי: כדי לבחור כתובת IP חיצונית של משאב Google Cloud בפרויקט הנוכחי, לוחצים על Select.
3. כדי להפעיל את בדיקת התקינות, בוחרים באפשרות Health checking 1.
4. אם רוצים להוסיף עוד כתובת IP חיצונית, לוחצים על הוספת כתובת IP.
5. לוחצים על סיום.
אם הפעלתם את בדיקת התקינות בשלב הקודם, ברשימה בדיקת התקינות בוחרים בדיקת התקינות או יוצרים בדיקה חדשה לפי השלבים הבאים.
1. לוחצים על Create a new health check.
2. בשדה Name, מזינים שם לבדיקת התקינות.
3. אופציונלי: בשדה Description, מזינים תיאור לבדיקת התקינות.
4. בקטע Source regions (אזורי מקור), בוחרים שלושה אזורים Google Cloudשרוצים לשלוח מהם בדיקות בריאות.
5. אם רוצים, בוחרים פרוטוקול מהרשימה Protocol.
6. בשדה יציאה, מזינים מספר יציאה.
  
  הפרוטוקול ומספר היציאה קובעים איך Cloud DNS שולח את הבדיקה של תקינות השרת.
7. אופציונלי: כדי להגדיר בדיקת תקינות מבוססת-תוכן, בשדה Response מזינים מחרוזת תגובה צפויה באורך של עד 1,024 תווים ASCII (בייט יחיד).
8. אופציונלי: כדי להפעיל את יומני בדיקת התקינות, לוחצים על On (מופעל) לצד Logs (יומנים).
9. בשדה מרווח בדיקה, מזינים את מרווח הזמן בשניות בין בדיקות תקינות. מרווח הבדיקה הוא משך הזמן מתחילת בדיקה אחת שהונפקה על ידי בודק אחד ועד לתחילת הבדיקה הבאה שהונפקה על ידי אותו בודק.
10. בשדה Timeout, מזינים את משך הזמן בשניות שרוציםGoogle Cloud להמתין לתגובה לבדיקה.
11. בשדה Healthy threshold, מזינים את מספר תוצאות הבדיקה הרצויות ברציפות כדי שהקצה העורפי ייחשב כתקין.
12. בשדה Unhealthy threshold, מזינים את מספר תוצאות הבדיקה שנכשלו ברציפות כדי שהקצה עורפי ייחשב כלא תקין.
13. לוחצים על יצירה.
לוחצים על הבא.

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

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

יתירות כשל

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

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

בדיקה ויצירה

לוחצים על בדיקה.
בודקים את קבוצת הרשומות ב-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, בשניות, שבו ה-Resolver שומר במטמון את ה-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, בשניות, שבו ה-resolver מאחסן את ה-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, בשניות, שבו ה-resolver מאחסן את ה-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 כדי להשבית את הגדרת הגבולות הגיאוגרפיים. אם לא מגדירים את ההגדרה הזו, שאילתות מופנות לאזור הקרוב ביותר כשכל נקודות הקצה באזור לא תקינות. הערך שמוגדר כברירת מחדל הוא false.
יתירות כשל
```
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, בשניות, שבו ה-Resolver שומר את ה-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://www.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/beta/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME"
            "wrr": {
                "items": [{
                    "weight": WEIGHT,
                    "healthCheckedTargets": {
                        "rrdata": ["RRDATA"]
                    }
                }, {
                    "weight": 1.0,
                    "healthCheckedTargets": {
                        "rrdata": ["RRDATA", "RRDATA"]
                    }
                }]
            }
        }
    }
  
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID: מזהה הפרויקט
- MANAGED_ZONE: התחום המנוהל שאליו משויך ResourceRecordSet, למשל service-zone. השם של ResourceRecordSet הזה חייב לכלול את שם ה-DNS של התחום המנוהל כסיומת שלו.
- RRSET_NAME: שם ה-DNS שתואמת לשאילתות הנכנסות עם שם ה-DNS של האזור הזה כסיומת, למשל service.example.com.
- TTL: משך הזמן ל-TTL, בשניות, שבו ה-Resolver שומר במטמון את ה-ResourceRecordSet הזה, למשל 30.
- RRSET_TYPE: סוג רשומת המשאב של ResourceRecordSet הזה, למשל A.
- 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.
מיקום גיאוגרפי
```
    POST https://www.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/beta/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME"
            "geo": {
          "enableFencing": ENABLE_FENCING
                "items": [{
                    "location": "LOCATION",
                    "healthCheckedTargets": {
                        "rrdata": ["RRDATA"]
                    }
                }, {
                    "location": "LOCATION",
                    "healthCheckedTargets": {
                        "rrdata": ["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: השם של בדיקת התקינות.
- 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.
יתירות כשל
באפשרות של חלוקת עומסים בעת כשל, Cloud DNS תומך רק במדיניות GEO.
```
    POST https://www.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/beta/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.
- RRDATA: ערך שרירותי שמשויך לקבוצת הרשומות של המשאב, למשל 198.51.100.5. אפשר גם להזין כמה ערכים, rrdata1,rrdata2,rrdata3, למשל 198.51.100.1, 203.0.113.1.
- ENABLE_FENCING: במדיניות הניתוב GEO, הערך הזה קובע אם התנועה צריכה לעבור לחלופין לאזורים אחרים אם כל נקודות הקצה באזור לא תקינות. כשהיא מוגדרת, Cloud DNS תמיד מפנה את השאילתות לאזור הקרוב ביותר, גם אם כל נקודות הקצה באזור הזה לא תקינות. אם לא מגדירים את ההגדרה הזו, שאילתות של Cloud DNS מועברות לאזור הקרוב ביותר כשכל נקודות הקצה באזור לא תקינות. ערך ברירת המחדל הוא false.
- LOCATION: במדיניות GEO, המיקום הגיאוגרפי שבו צריך ליצור את המדיניות, למשל asia-east1.

עדכון כללי מדיניות הניתוב של 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

יתירות כשל

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, בשניות, שבו ה-Resolver שומר במטמון את ה-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

משתמשים ב-method‏ resourceRecordSets.patch. צריך לציין רק אחד מבין הערכים rrset.rrdatas או rrset.routingPolicy. אם מציינים את routingPolicy, צריך לציין את השדה החדש routingPolicy במלואו.

WRR

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

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

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

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

PATCH https://www.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"
                    "region": "REGION"
                    }
                  ]
                }
            },
            {
                "location": "LOCATION",
                "healthCheckedTargets": {
                  "internalLoadBalancers": [
                    {
                    "loadBalancerType": "LOAD_BALANCING_TYPE"
                    "ipAddress": "IP_ADDRESS"
                    "port" : "PORT_NUMBER"
                    "ipProtocol": "IP_PROTOCOL"
                    "networkUrl": "NETWORK_URL"
                    "project": "PROJECT"
                    "region": "REGION"
                    }
                  ]
                }
            },
            }
        ]

      }
  }
}

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

‫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
TRICKLE_TRAFFIC: היחס של התנועה שצריך לשלוח ליעדים לגיבוי גם כשהמכונות הראשיות תקינות. היחס חייב להיות בין 0 ל-1, למשל 0.1
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…
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

משתמשים ב-method‏ resourceRecordSets.delete:

DELETE https://www.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

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

יתירות כשל

gcloud

WRR

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

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

יתירות כשל

API

WRR

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

יתירות כשל

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

המסוף

WRR

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

יתירות כשל

gcloud

WRR

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

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

יתירות כשל

API

WRR

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

יתירות כשל

עדכון כללי מדיניות הניתוב של DNS

המסוף

gcloud

WRR

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

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

יתירות כשל

API

WRR

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

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

המסוף

gcloud

API

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

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