הצבת פותר פנימי ראשון ופותר ציבורי שני אינה אומרת ל-Squid אילו שמות שייכים לאיזה מרחב שמות.

ב-Squid 6 ו-7, dns_nameservers מחליף את רשימת הפותרים הרגילה בכתובות שרת. בתחביר שלו אין מיפוי לפי דומיין. גם תשובה שלילית תקפה שונה מפותר שאינו נגיש, ולכן חלופות אינן דרך מהימנה לחפש במרחבי שמות בלתי תואמים.

ניתוב שאילתות לפי דומיין

מעביר DNS מקומי יכול לבטא את המדיניות החסרה. בתצורת dnsmasq קיימת, ניתן לנתב סיומת פרטית כך:

server=/internal.example/192.0.2.53

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

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

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

בדקו גם את המקרה השלילי

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

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

מאמרים קשורים