DNS עם אופקים מפוצלים (פנימי לעומת חיצוני)

אותה שאלה — "איפה נמצא mail.company.com?" — מקבלת תשובה שונה ונכונה בהתאם למי שמציג אותה. עובד ברשת הארגונית מקבל כתובת IP פנימית. לקוח שמגיע מהאינטרנט מקבל כתובת IP ציבורית. שתי התשובות נכונות. לשם יש שתי משמעויות בו-זמנית.

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

הבעיה שהוא פותר

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

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

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

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

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

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

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

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

אותו שם, שירותים שונים

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

שקלו את api.company.com. שותפים חיצוניים מגיעים לנקודת הקצה הזו לממשק ה-API הציבורי שלכם — עם הגבלת קצב, תחום פעולה מוגדר בקפידה, ומוקשח לייצור. מפתחים פנימיים זקוקים לאותו שם מארח כדי להגיע ל-API פנימי עם הרשאות מורחבות, פלט ניפוי שגיאות מפורט, וגישה לתכונות טרום-שחרור.

ללא DNS מפוצל, היה עליכם להשתמש בשמות מארח שונים: api.company.com לחיצוניים, api-internal.company.com לפנימיים. המפתחים צריכים לזכור מה להשתמש. התיעוד מתפצל. מישהו בהכרח מקודד לתוך הקוד את הלא-נכון.

עם DNS מפוצל, שתי הקבוצות משתמשות ב-api.company.com. תשתית ה-DNS מטפלת בניתוב בהתאם למי שמבקש. פשטות נשמרת, הפרדה מתוחזקת.

גישות מימוש

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

view "internal" {
    match-clients { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };
    zone "company.com" { file "company.com.internal"; };
};

view "external" {
    match-clients { any; };
    zone "company.com" { file "company.com.external"; };
};

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

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

היכן זה הולך לא כשורה

הכשל הנפוץ ביותר: סיווג שגוי של מקור השאילתה. הרשת הפנימית שלכם מנתבת שאילתות DNS דרך שער NAT או פרוקסי. שרת ה-DNS רואה את כתובת ה-IP של השער, לא של הלקוח המקורי. אם כתובת ה-IP של השער אינה ברשימת ההתאמה של התצוגה הפנימית שלכם, משתמשים פנימיים מקבלים תשובות חיצוניות.

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

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

משתמשי VPN יוצרים מקרה מיוחד. כאשר עובדים מתחברים מרחוק, שאילתות ה-DNS שלהם צריכות לקבל תשובות פנימיות — אבל רק אם ה-VPN שולח כראוי שרתי DNS פנימיים ללקוחות המחוברים ומנתב תעבורת DNS דרך המנהרה. VPN שמוגדר בצורה שגויה ומאפשר לשאילתות DNS לדלוף לפותרים מקומיים שובר את מודל ה-DNS המפוצל.

מה זה לא עושה

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

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

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

הדפוס העמוק יותר

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

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

זה לא פתרון מאולתר או עקיפה. זוהי הכרה בכך שהקשר חשוב — אפילו ברמת פענוח ה-DNS.

שאלות נפוצות על DNS עם אופקים מפוצלים

האם DNS מפוצל דורש תצורת לקוח מיוחדת?

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

האם אני יכול להשתמש ב-DNS מפוצל עם שירותים מתארחים בענן?

כן. רוב ספקי ה-DNS בענן תומכים באזורים פרטיים שמגיבים רק לשאילתות מה-VPCs שלכם או מרשתות מוגדרות. AWS Route 53, Google Cloud DNS ו-Azure DNS מציעים את הפונקציונליות הזו, אם כי פרטי המימוש משתנים.

מה קורה אם שם מארח קיים בתצוגה החיצונית אבל לא בפנימית?

משתמשים פנימיים שמבצעים שאילתה לשם המארח הזה מקבלים תגובת NXDOMAIN (הדומיין אינו קיים) גם אם משתמשים חיצוניים יכולים לפענח אותו. לפעמים זה מכוון — לשמור שירותים מסוימים הפונים כלפי חוץ נפרדים מהתשתית הפנימית — אבל לעיתים קרובות מצביע על השמטה בתצורה שיש לתקן.

כיצד אני בודק איזו תצוגה אני מגיע אליה?

שאלו את שרת ה-DNS שלכם ישירות ובחנו את התגובה. ממיקומי רשת שונים, הריצו dig @your-dns-server hostname.company.com והשוו את כתובות ה-IP שהוחזרו. תוכלו גם לבדוק את יומני שרת ה-DNS כדי לראות איזו תצוגה טיפלה בכל שאילתה.