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

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

אזורים פרטיים

בקטע הזה מוסבר על בעיות באזורים פרטיים.

בעיות באזורים פרטיים בפרויקטים של שירות VPC משותף

מידע חשוב על שימוש באזורים פרטיים עם רשתות VPC משותפות זמין במאמר אזורים פרטיים ו-VPC משותף.

אי אפשר ליצור אזור פרטי, אי אפשר להציג או ליצור מדיניות

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

אזורים פרטיים לא נפתרים באותה רשת VPC

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

מוודאים שהממשק הראשי של מופע המכונה הווירטואלית נמצא באותה רשת כמו האזור הפרטי שיצרתם

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

בודקים שהמכונה הווירטואלית משתמשת ב:

gcloud compute instances describe VM_NAME \
    --zone=GCE_ZONE \
    --format="csv[no-heading](networkInterfaces['network'])"

מוודאים שהרשת מופיעה ברשימת הרשתות שמורשות לשלוח שאילתות לאזור הפרטי:

gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
    --format="csv(privateVisibilityConfig['networks'])"

מוודאים ששם ה-DNS בשאילתה זהה לאזור שלכם

‫Google Cloud פוענחת רשומה לפי סדר פענוח השמות, באמצעות האזור עם הסיומת הארוכה ביותר כדי להחליט איזה אזור לשאול לגבי שם DNS נתון. מוודאים שהסיומת של הרשומה שאתם שולחים לגביה שאילתה תואמת לפחות לאזור פרטי אחד שאפשר לגשת אליו ברשת ה-VPC. לדוגמה, Google Cloud קודם המערכת מחפשת את myapp.dev.gcp.example.lan באזור שמשרת את dev.gcp.example.lan, אם יש גישה, לפני שהיא מחפשת אותו באזור שמשרת את gcp.example.lan, אם יש גישה.

הפלט של הפקודה הבאה מציג את הסיומת של DNS לאזור פרטי נתון:

gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
    --format="csv[no-heading](dnsName)"

שליחת שאילתה לשרת המטא-נתונים לגבי שם ה-DNS

משתמשים ב-dig כדי לשלוח את השאילתה של שם ה-DNS ישירות לשרת המטא-נתונים, 169.254.169.254: Google Cloud

dig DNS_NAME @169.254.169.254

משתמשים ב-dig כדי לשלוח שאילתה לשרת השמות שמוגדר כברירת מחדל במכונה הווירטואלית:

dig DNS_NAME

אם הפלט של שתי הפקודות dig מניב תשובות שונות, צריך לבדוק את הקטע ;; SERVER: של הפקודה השנייה. השרת שמגיב חייב להיות שרת המטא-נתונים, 169.254.169.254. אם לא, סימן שהגדרתם את מערכת ההפעלה של האורח להשתמש בשרת שמות DNS בהתאמה אישית במקום בGoogle Cloud שרת המטא-נתונים שמוגדר כברירת מחדל. כדי להשתמש באזורים פרטיים ב-Cloud DNS, צריך להשתמש בשרת המטא-נתונים לפתרון שמות. הפעולה הזו מתבצעת באופן אוטומטי גם בסביבת האורח של Linux וגם בסביבת האורח של Windows. אם ייבאתם את האימג' שבו אתם משתמשים למכונה וירטואלית, אתם צריכים לוודא שסביבת האורח המתאימה הותקנה.

אזורים פרטיים לא נפתרים באמצעות Cloud VPN או Cloud Interconnect

קודם צריך לוודא שאפשר לבצע שאילתה ולפתור את שם ה-DNS מתוך רשת VPC מורשית.

אימות הקישוריות דרך Cloud VPN או Cloud Interconnect

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

אתם יכולים להשתמש בכל פרוטוקול, כמו ping (ICMP), כדי לבדוק את הקישוריות למכונה וירטואלית לדוגמה ברשת ה-VPC מהרשת המקומית. למרות שבקשות Cloud DNS לא נשלחות למכונות וירטואליות, בדיקת הקישוריות למכונה וירטואלית לדוגמה מאפשרת לאמת את הקישוריות דרך מנהרת Cloud VPN או חיבור Cloud Interconnect. Google Cloud חשוב לוודא שהגדרתם כלל חומת אש מתאים שמאפשר תעבורת נתונים נכנסת (ingress) למכונה הווירטואלית לדוגמהGoogle Cloud , כי אחרת כלל ברירת המחדל שחוסם תעבורת נתונים נכנסת יחסום את כל התעבורה הנכנסת.

מוודאים שההפניה האוטומטית של תעבורה נכנסת מופעלת ברשת ה-VPC המורשית

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

gcloud dns policies list

מזהים את הרשת בטבלת הפלט ובודקים את השדה העברה כדי לראות אם ההעברה מופעלת.

מוודאים שהרשת המורשית היא רשת VPC

הכוונה אוטומטית של DNS דורשת תת-רשתות, שזמינות רק ברשתות VPC, ולא ברשתות מדור קודם.

gcloud compute networks list \
    --format="csv[no-heading](name, SUBNET_MODE)"

רשתות מדור קודם מזוהות בפלט כ-LEGACY.

מוודאים שכתובת DNS תקינה להעברה שמורה ברשת הזו

הפקודה הבאה מציגה את כל כתובות ה-IP השמורות להעברת DNS בפרויקט:

gcloud compute addresses list \
    --filter="purpose=DNS_RESOLVER" \
    --format='csv[no-heading](address, subnetwork)'

אפשר להוסיף פסקה של AND למסנן כדי להגביל את הפלט רק לרשת המשנה שמעניינת אתכם.

דוגמה:

--filter="name ~ ^dns-forwarding AND subnetwork ~ SUBNETWORK_NAME"

אם לא מופיעה כתובת IP ברשת או באזור שציפיתם, צריך לפתוח כרטיס תמיכה בGoogle Cloud תמיכה.

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

dig DNS_NAME @10.150.0.1 # address returned by previous command

חוזרים על אותה פקודת dig אבל ממארח מקומי דרך ה-VPN.

רשומת CNAME שמוגדרת באזור פרטי לא פועלת

‫Cloud DNS עוקב רק אחרי רשומות CNAME, כמו שמתואר במאמר בנושא מעקב אחרי CNAME.

אזורי חיפוש הפוך

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

לא ניתן לפתור בעיה במכונה וירטואלית עם כתובת שהיא לא RFC 1918

אם יש לכם כתובת שאינה RFC 1918, עליכם לבצע התאמה של המכונה הווירטואלית.

התאמה של מכונה וירטואלית עם כתובת שאינה RFC 1918

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

אזורי העברה

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

אזורי העברה (העברה יוצאת) לא פועלים

קודם צריך לוודא שאפשר לבצע שאילתה ולפתור את שם ה-DNS מתוך רשת VPC מורשית.

העברת שאילתות ממכונות וירטואליות ברשת VPC של צרכן לרשת VPC של יצרן לא פועלת

אם אתם משתמשים בקישור DNS ואתם רוצים להעביר שאילתות ממכונות וירטואליות ברשת VPC של צרכן לרשת VPC של יצרן, ואז לשרת שמות אחד או יותר מקומיים, ודאו שאחד מהתנאים המוקדמים הבאים מתקיים:

  • מצב הניתוב הדינמי ברשת ה-VPC של הספק מוגדר ל-GLOBAL.

  • המכונה הווירטואלית ברשת ה-VPC של הצרכן נמצאת באותו אזור כמו מנהרת ה-VPN או Cloud Interconnect ב-VPC של היצרן.

  • ((Static routes or custom next hops only) The producer VPC network has a static route configured to send traffic destined for the on-premise name servers through the Classic VPN tunnel, a self-managed VPN, or a non-BGP gateway. בנוסף, ברשת ה-VPC של היצרן צריכה להיות מכונה וירטואלית או מנהרת VPN באותו אזור כמו רשת המשנה שבה משתמשות המכונות הווירטואליות של הלקוח.

    • לדוגמה, נניח שרשת VPC1 משתמשת באזור peering ששולח שאילתות לגבי example.com. אל רשת VPC2. נניח גם של-VPC2 יש אזור העברה פרטי בשביל example.com. שמעביר את השאילתות לשרת שמות מקומי באמצעות מנהרת VPN קלאסית.

      כדי שמכונה וירטואלית שנמצאת ב-us-east1 ב-VPC1 תוכל לשלוח שאילתה ל-example.com., ב-VPC2 צריכה להיות מכונה וירטואלית שנמצאת ב-us-east1. צריך גם להגדיר ניתוב סטטי שמכסה את טווחי ה-CIDR של שרתי השמות המקומיים, כשהניתוב הבא מוגדר כמנהרת VPN קלאסי.

      אימות הקישוריות דרך Cloud VPN או Cloud Interconnect

אתם יכולים להשתמש בכל פרוטוקול, כמו ping (ICMP), כדי לבדוק את הקישוריות למכונה וירטואלית לדוגמה ברשת ה-VPC מהרשת המקומית. בנוסף, צריך לנסות לשלוח שאילתה לשרת השמות המקומי ישירות ממכונת VM לדוגמהGoogle Cloud באמצעות כלי כמו dig:

dig DNS_NAME @192.168.x.x # address of the onprem DNS server

בדיקת כללי חומת האש ברשת ה-VPC

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

בדיקה של חומת האש המקומית

מוודאים שחומת האש המקומית מוגדרת כך שתאפשר תנועה נכנסת מ- ותנועה יוצאת אל .

בודקים את היומנים בחומת האש המקומית ומחפשים בקשות DNS מ-. כדי להשתמש בביטוי regex לחיפוש, משתמשים ב:

"35\.199\.(19[2-9]|20[0-9]|21[0-9]|22[0-3]).*"

בדיקה של שרת שמות מקומי

מוודאים שלא מוגדרת רשימת בקרת גישה (ACL) בשרת השמות המקומי שחוסמת שאילתות מ-.

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

sudo tcpdump port 53 and tcp -vv

אימות של מסלולי החזרה

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

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

אם חיברתם יותר מרשת VPC אחת לרשת המקומית, אתם צריכים לוודא שתשובות DNS לא נשלחות לרשת הלא נכונה. Google Cloud מבטל תשובות DNS שנשלחות לרשת VPC לא נכונה. פתרון מומלץ מופיע במדריך שלנו בנושא שיטות מומלצות.

העברה יוצאת ל-NIC משני נכשלת

מוודאים שהגדרתם נכון את בקר ממשק הרשת (NIC) המשני.

הוראות להגדרת כרטיסי NIC נוספים מפורטות במאמר יצירת מכונות וירטואליות עם כמה ממשקי רשת.

שאילתות שמועברות החוצה מקבלות שגיאות SERVFAIL

אם Cloud DNS מקבל שגיאה מכל שרתי השמות של היעד או לא מקבל תשובה מאף אחד מהם, הוא מחזיר שגיאה SERVFAIL.

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

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

רשומות משאבים

בקטע הזה מפורטים טיפים לפתרון בעיות שקשורות לרשומות משאבים.

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

יכולות להיות כמה סיבות לכך שתקבלו נתונים לא צפויים כשאתם שולחים שאילתה לגבי קבוצות של רשומות של משאבים שנמצאות באזור מנוהל של Cloud DNS:

  1. לא ניתן להשתמש בקבוצות של רשומות משאבים שנוצרו באמצעות התחביר @ שצוין ב-RFC 1035. ‫Cloud DNS מפרש את הסמל @ בקבוצות של רשומות משאבים באופן מילולי. לכן, באזור example.com., קבוצת רשומות שנוצרה עבור QNAME‏ @ מתפרשת כ-@.example.com. במקום כ-example.com.. כדי לפתור את הבעיה, צריך לוודא שיוצרים קבוצות של רשומות ללא הסמל @. כל השמות הם יחסיים לנקודת השיא של האזור.

  2. כמו כל הרשומות, רשומות CNAME עם תווים כלליים כפופות לכללי הקיום שמתוארים ב-RFC 4592. לדוגמה, נניח שהגדרתם את קבוצות הרשומות הבאות באזור example.com.:

    *.images.example.com. IN CNAME _static.example.com.

    srv1.images.example.com. IN A 192.0.2.91

    _static.example.com. IN A 192.0.2.92

    שאילתה לגבי public.srv1.images.example.com. מחזירה את NOERROR עם קטע תשובה ריק. הקיום של רשומה בין ה-CNAME לבין ה-QNAME מונע את החזרת ה-CNAME, אבל אין רשומה שתואמת בדיוק ל-QNAME, ולכן Cloud DNS מחזיר תשובה ריקה. זוהי התנהגות רגילה של DNS.

קבוצות של רשומות משאבים של Cloud DNS מוחזרות בסדר אקראי

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

סוג משאב של תחום מוגדר שלא נתמך

כשמזינים את הדגל --location לפקודה gcloud או לבקשת API לתכונה שמיועדת לתחום DNS אחר של Cloud DNS, הבקשה נדחית. לדוגמה, אם שולחים הגשת בקשה להוספת תכונה אזורית בלבד לשרת גלובלי, או הגשת בקשה להוספת תכונה גלובלית בלבד לשרת אזורי, השרת דוחה את הבקשה ומחזיר שגיאה מסוג ‎_UNSUPPORTED_ZONAL_RESOURCETYPE.

רשימה של משאבים ותכונות שנתמכים ב-Cloud DNS אזורי זמינה במאמר תמיכה אזורית ב-Cloud DNS.

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