פתרון בעיות ב-Cloud DNS

במאמר הזה מוסבר איך לפתור בעיות ב-Cloud DNS ב-Google Distributed Cloud (GDC)‎ עם air gap. הוא כולל שגיאות ובעיות פוטנציאליות שאתם עשויים להיתקל בהן כשאתם מבצעים פעולות ניהול בהגדרות DNS, וטיפים והצעות לניפוי באגים בבעיות שקשורות לפענוח DNS. המסמך הזה מיועד לאדמינים של פלטפורמות ולמפעילי אפליקציות שאחראים על ניהול רשומות DNS בפרויקט.

פתרון בעיות בפעולות הניהול של Cloud DNS

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

פתרון בעיות בסיסיות

  • מוודאים שיש לכם את התפקידים הנכונים ב-IAM, כמו שמתואר במאמר הכנת הרשאות IAM.
  • אם אתם משתמשים ב-gdcloud, אתם יכולים לרענן את אסימון האימות על ידי הפעלת gdcloud auth login.

מתן שמות למשאבים ואימות (RFC 1123)

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

פרטים:

  • שמות משאבים: השמות של תחומי ה-DNS וקבוצות הרשומות חייבים להיות תואמים ל-RFC
    1. הם חייבים להכיל רק תווים אלפאנומריים קטנים או -, ולהתחיל ולהסתיים בתו אלפאנומרי.
  • שמות DNS: הערכים של שמות הדומיינים ושמות הדומיינים שמוגדרים במלואם (FQDN) חייבים להיות שמות דומיינים תקינים.
  • ערכי Enum: ערכים כמו הרשאות גישה (PUBLIC או PRIVATE) וסוגי רשומות (למשל, A,‏ CNAME) תלויים באותיות רישיות וחייבים להתאים בדיוק למחרוזת הצפויה.

אי אפשר למחוק אזורים לא ריקים

הבעיה: אי אפשר למחוק אזור מנוהל, הפעולה נדחית.

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

התנגשויות בין שמות ודומיינים

הבעיה: לא מצליחים ליצור משאב ומוצגת הודעת שגיאה שהשם או הדומיין כבר בשימוש.

פרטים:

  • שם המשאב ב-Kubernetes: שם האובייקט (למשל, השם ב-metadata.name) חייב להיות ייחודי במרחב השמות של הפרויקט הספציפי.
  • שם DNS‏ (FQDN): שם הדומיין בפועל (למשל, dnsName לאזורים או לרשומות) חייב להיות ייחודי בתוך חשיפה נתונה (ציבורית או פרטית). אי אפשר ליצור שני אזורים או שתי רשומות עם שם דומיין זהה באותה רמת חשיפה.

פתרון בעיות בפענוח DNS

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

המתנה להפצה וניקוי של מטמון ה-DNS

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

  1. זמן התאמה: המערכת צריכה זמן כדי לעבד את הבקשה ולעדכן את ההגדרות של שרת ה-DNS. בדרך כלל התהליך נמשך כמה דקות.
  2. עיכוב בהפצת DNS (שמירה במטמון): מפענחי DNS ולקוחות שומרים רשומות במטמון כדי להאיץ את החיפושים. יכול להיות שהלקוחות ימשיכו להשתמש ברשומה הישנה עד שתקופת אורך החיים (TTL) תסתיים.

המלצות:

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

אימות ההגדרות של המפענח המקומי

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

  • ‫Linux/macOS: בודקים את התוכן של /etc/resolv.conf.
  • Windows: מריצים את ipconfig /all ובודקים את שרתי ה-DNS שמופיעים ברשימה.

תחנות העבודה של מנהל הפלטפורמה (PA) ומפעיל האפליקציה (AO) ברשת של הלקוח צריכות להשתמש בפענוח DNS שנפרד מרשת ה-IO WAN ו-OIRv2. שמות דומיינים זהים של GDC מתורגמים לכתובות IP שונות, בהתאם לשאלה אם השאילתה מגיעה דרך ה-WAN של ה-IO או דרך ה-Interconnect של הלקוח. לכן אי אפשר להשתמש בהגדרת DNS משותפת גם לתחנות עבודה של IO וגם לתחנות עבודה של PA או AO. מידע נוסף זמין במאמרים חיבורים בין מערכות, סכימת שמות דומיינים ב-DNS ובמדריך ההפעלה DNS-R0016.

בדיקת הרזולוציה באמצעות כלים רגילים

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

  • חיפוש בסיסי:

    dig <domain_name>

    או

    nslookup <domain_name>

  • שליחת שאילתה לשרת DNS ספציפי: אם אתם יודעים את כתובת ה-IP של שרת ManagedDNS הציבורי, שלחו אליו שאילתה ישירות כדי לעקוף את המפענחים המקומיים:

    dig @<public_dns_server_ip> <domain_name>

  • שליחת שאילתה לשרת שמות ציבורי: כדי לשלול בעיות במפענח המקומי, נסו לשלוח שאילתה למפענח ציבורי כמו Google DNS:

    dig @8.8.8.8 <domain_name>

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

כשמשתמשים ב-dig או ב-nslookup, צריך לבדוק את קוד הסטטוס בתגובה:

  • ‫NXDOMAIN: שם הדומיין לא נמצא. צריך לבדוק אם יש שגיאות הקלדה או לוודא שהרשומה קיימת.
  • ‫SERVFAIL: השרת לא הצליח לעבד את השאילתה. בדרך כלל זה מעיד על בעיה בצד השרת או על כשל בתקשורת בין שרתי DNS.
  • ‫NOERROR: השאילתה הצליחה, אבל יכול להיות שאין תשובות. בודקים אם סוג הרשומה המבוקש (למשל, A, ‏ CNAME) קיים.
  • ‫REFUSED: השרת סירב לענות על השאילתה, כנראה בגלל הגדרות של מדיניות או של בקרת גישה.

צריך לבדוק את החיבור לרשת

מוודאים שהתנועה ברשת לשרת ה-DNS לא חסומה.

  • ב-DNS נעשה שימוש ביציאה 53 גם ל-UDP וגם ל-TCP.

  • בודקים את הקישוריות באמצעות nc ‏(netcat):

    nc -zv <dns_server_ip> 53

  • מוודאים שהכללים של חומת האש מאפשרים תנועה ביציאה 53.

ניקוי מטמון ה-DNS

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

  • Windows: ipconfig /flushdns
    • מה הפעולה עושה: מנקה את המטמון של מפענח ה-DNS שמנוהל על ידי שירות הלקוח של ה-DNS.
  • macOS: sudo killall -HUP mDNSResponder
    • מה היא עושה: שולחת אות ניתוק (HUP) לתהליך mDNSResponder, ומאלצת אותו לטעון מחדש ולנקות את המטמון שלו.
  • ‫Linux (systemd-resolved): sudo systemd-resolve --flush-caches או sudo resolvectl flush-caches
    • מה היא עושה: מורה לשירות systemd-resolved למחוק את המטמון הפנימי של ה-DNS.

בדיקת סטטוס המשאב באמצעות API או gdcloud

אם אתם דיירים או שיש לכם גישה ל-GDC API, אתם יכולים לבדוק את סטטוס המשאבים ישירות:

  • בדיקת תחום DNS:

    kubectl describe manageddnszone <zone_name> -n <project_namespace>

  • בדיקה של קבוצת רשומות משאבים:

    kubectl describe resourcerecordset <record_name> -n <project_namespace>

    מחפשים תנאים ואירועים שעשויים להצביע על כשלים בתהליך ההתאמה.

אם יש לכם גישה לשורת הפקודה של gdcloud, אתם יכולים להשתמש בפקודת המשנה describe כמו שמתואר במאמרים הצגת רשימה של רשומות DNS או הצגת רשימה של תחומי DNS.