הערכה ואופטימיזציה של העלויות ב-DNS Armor

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

למידע כללי על התמחור של Cloud DNS, אפשר לעיין במאמר תמחור של Cloud DNS.

מידע נוסף על התמחור של DNS Armor זמין במאמר בנושא תמחור של זיהוי איומים מתקדם.

אומדן עלויות

אפשר להשתמש במדד dns.googleapis.com/query/response_count עם מסננים target_type=external ו-source_type==gce-vm כדי להעריך את העלויות.

הוזלת עלויות

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

החרגה של ממשקי API ושירותים של Google

כברירת מחדל, שאילתות אל googleapis.com מועברות באופן רקורסיבי לאינטרנט, כלומר השאילתות האלה נחשבות לשאילתות external ולכן הן נכללות בהיקף העיבוד של DNS Armor. כדי להימנע מהתרחיש הזה, צריך ללכוד את התעבורה הזו באזור פרטי של Cloud DNS ולהפנות אותה אל כתובות ה-IP הווירטואליות (VIP) הפנימיות של Google. אם תעשו את זה, השאילתות האלה יסומנו כ-internal והן ידלגו על הבדיקה של DNS Armor.

כדי לא לכלול את הקריאות ל-API בעיבוד של DNS Armor, צריך להגדיר גישה פרטית ל-Google או Private Service Connect ל-Google APIs. מידע נוסף זמין במאמרים הגדרת גישה פרטית ל-Google ומידע על גישה ל-Google API דרך נקודות קצה.

החרגה של הדומיינים שלכם

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

אזור פרטי מנוהל

האפשרות הזו מתאימה אם רוצים לשמור עותק מלא ונפרד של אזורי ה-DNS הפנימיים ב-Cloud DNS (נקרא גם DNS מסוג split-brain או split-horizon).

לדוגמה, אם יוצרים תחום פרטי ב-Cloud DNS בשביל example.com ומאכלסים אותו ברשומות ה-DNS, אפשר לצרף את התחום לרשת ה-VPC. המשמעות של הגישה הזו היא שכאשר עומס עבודה שולח שאילתה ל-api.example.com, מערכת Cloud DNS בודקת קודם את התחום הפרטי המצורף, מוצאת את הרשומה הפנימית ומספקת תשובה באופן מיידי. השאילתה אף פעם לא יוצאת מה-VPC והיא מתויגת כ-internal, מה שעוזר לשאילתה להימנע מעיבוד של DNS Armor.

מדיניות תגובה ב-Cloud DNS

משתמשים באפשרות הזו אם צריך לפתור רק כמה שמות מארחים ספציפיים (כמו api.example.com או db.example.com) לכתובות IP פנימיות, אבל רוצים ששאר הדומיין ימשיך להיפתר באופן ציבורי באינטרנט.

לדוגמה, אפשר ליצור כלל במדיניות תגובה עבור api.example.com שמחזיר את כתובת ה-IP הפנימית שלכם ולצרף אותו ל-VPC. הוא מיירט את השאילתות המהימנות שלכם בהיקף גדול ועונה עליהן באופן מקומי. שאילתות מדומיינים אחרים (כמו www.example.com) עדיין יפעלו באופן ציבורי ויעובדו על ידי DNS Armor.

אזור העברה

משתמשים בשיטה הזו אם מפעילים שרתי DNS מקומיים (כמו Active Directory,‏ InfoBlox או BIND) שהם סמכותיים לאזורי DNS פנימיים ומחוברים ל- Google Cloud באמצעות Cloud VPN או Dedicated Interconnect.

לדוגמה, אפשר ליצור אזור העברה ב-Cloud DNS עבור example.com ולהגדיר אותו כך שיפנה ישירות לכתובות ה-IP הפנימיות (בדרך כלל כתובות RFC 1918) של שרתי ה-DNS המקומיים. בשיטה הזו, השאילתה נשלחת ברשת הפרטית לשרתים הפנימיים. מכיוון שיעד השאילתה הוא כתובת IP פרטית, השאילתה מתויגת כ-forwarding-zone ולא חל עליה עיבוד על ידי DNS Armor.

מידע נוסף זמין במאמר שימוש באזורי העברה כדי לשלוח שאילתות לשרתים מקומיים.

שרתי DNS מותאמים אישית במכונות וירטואליות ב-Compute Engine

אם אתם מפעילים שרתי DNS משלכם (למשל BIND, ‏ Active Directory, ‏ dnsmasq) במכונות וירטואליות, השימוש ב-DNS Armor תלוי בטופולוגיית הניתוב שבה אתם משתמשים.Google Cloud

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

  • המכונה הווירטואלית מעבירה ל-Cloud DNS. אם אתם מעבירים את כל תנועת ה-DNS של החברה באינטרנט דרך מכונה וירטואלית של שרת DNS מרכזי, שמעבירה את התנועה ל-Cloud DNS, הפלטפורמה רואה רק את השאילתות שמגיעות מהמקור היחיד הזה. השימוש במכונה וירטואלית מוזיל את העלות בסביבות עם נפח נמוך עד בינוני, כי החיוב ב-DNS Armor מבוסס על GREATEST(Workloads, Queries / 150), והשיטה הזו מורידה את בסיס העומס ל-1.

רזולוציה של אזורים פרטיים

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

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

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