מדוע רשומת SRV עוזרת רק ללקוח ששואל אותה בעצמו

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

רשומה שאיש אינו שואל אותה לא יכולה לעזור לאיש

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

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

קראו את השדות לפני שאתם כותבים אותם

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

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

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

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

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

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

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

גם היעד חייב להתקיים

יעד שנפתר אינו אותו דבר כמו שירות שעונה. בדקו את רשומות הכתובת של היעד, ואז בדקו שמשהו מאזין בפורט ובפרוטוקול שפורסמו. רשומת TCP שמצביעה על מאזין UDP בלבד היא אי-התאמה ששום עריכת אזור לא מתקנת. שמרו על TTL קצר כל עוד היעד בתנועה, והאריכו אותו כשהשם מפסיק לזוז.

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

גילוי אינו אימות

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

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