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

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

אזורים ציבוריים

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

אי אפשר ליצור אזור ציבורי

אם מופיעה השגיאה attempted action failed, סימן ש-Cloud DNS API לא מופעל בפרויקט.

כדי להפעיל את Cloud DNS API, פועלים לפי השלבים הבאים:

  1. במסוף Google Cloud , נכנסים לדף API Library.

    לדף API Library

  2. בקטע Select a recent project, בוחרים את הפרויקט שבו רוצים להפעיל את ה-API של Google Cloud .

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

  4. לוחצים על הפעלה.

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

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

בעיות באזורים פרטיים בפרויקטים של שירות 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 של ספק לא פועלת

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

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

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

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

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

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

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

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

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

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

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

sudo tcpdump port 53 and tcp -vv

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

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

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

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

העברה יוצאת לשרת שמות שמשתמש בכתובת IP שאינה RFC 1918 נכשלת

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

כדי להעביר שאילתות לשרת שמות שמשתמש בכתובת IP שאינה RFC 1918 דרך רשת ה-VPC, צריך להגדיר את אזור ההעברה או את מדיניות השרת של Cloud DNS כך שישתמשו בניתוב פרטי לשרת השמות של היעד.

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

המגבלה הזו חלה גם אם יש נתיב VPC לשרת שמות היעד. לנתיבים לכתובות שאינן RFC 1918 אין השפעה על התנהגות ההעברה היוצאת של Cloud DNS כשמוגדר ניתוב רגיל.

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

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

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

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

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

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

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

Google Cloud מכונה וירטואלית מציגה רשומות PTR שגויות

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

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

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

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

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

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

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

זיהוי איומים מתקדם

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

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

קודם כול, מוודאים שיש לכם גלאי איומים ב-DNS.

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

  1. נכנסים לדף Advanced threat detection במסוף Google Cloud .

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

  2. מוודאים שגלאי האיומים מופיע ברשימה.

אימות התמיכה באזור

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

מוודאים שיש שאילתות שקשורות לאינטרנט

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

  1. נכנסים לדף Monitoring במסוף Google Cloud .

    כניסה ל-Monitoring

  2. בקטע מדד, בוחרים באפשרות Cloud DNS Query, ואז בוחרים באפשרויות Query ו-DNS response counts.

  3. צפייה במדדים של סוגי טירגוט שמוגבלים לאינטרנט.

לחלופין, אם הפעלתם את Cloud Logging לשאילתות DNS, תוכלו להשתמש ב-Logs Explorer כדי לוודא שיש לכם שאילתות שמופנות לאינטרנט.

  1. נכנסים לדף Logs Explorer במסוף Google Cloud .

    כניסה לדף Logs Explorer

  2. צריך להציג את יומני ה-DNS ולבדוק אם יש שאילתות שמופנות לאינטרנט.

לא מוחזרים יומנים של אירועי איומים

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

איך מוודאים שזיהוי האיומים מופעל

  1. נכנסים לדף Advanced threat detection במסוף Google Cloud .

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

  2. מוודאים שגלאי האיומים מופיע ברשימה.

אירועים של איומים ב-DNS לא נוצרים עבור דומיינים מסוימים שמשמשים להתנהלות פוגעת או זדונית

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

אלה דומיינים לניסיון שבהם אפשר להשתמש כדי לאמת דומיינים של איומים ב-DNS:

  • dnst-gcp-blox.com
  • ftags-gcp-blox.com
  • dga-gcp-blox.com

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

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

  2. פותחים טרמינל ומריצים פקודת dig לאחד מדומייני הבדיקה. 

    domain=TEST_DOMAIN 
    
dig $domain -t A

    מחליפים את TEST_DOMAIN באחד מהדומיינים שמופיעים ברשימה.

  3. פותחים את מסוף Google Cloud ועוברים לדף Logs Explorer.

    כניסה לדף Logs Explorer

  4. מריצים את השאילתה הבאה: resource.type="networksecurity.googleapis.com/DnsThreatDetector"

  5. מחפשים את דומיין הבדיקה שבו השתמשתם בפקודה dig.

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

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