רשומות SRV: גילוי שירותים

DNS נבנה כדי לענות על שאלה אחת: בהינתן שם, מה כתובת ה-IP? רשומות SRV מבקשות ממנו לענות על שאלה שונה לגמרי: בהינתן שירות שאני צריך, כיצד אני מתחבר אליו?

כשטלפון VoIP מופעל וצריך למצוא את שרת הטלפון של החברה, כשלקוח צ'אט צריך לאתר את שרת ה-XMPP עבור דומיין, כשמשחקן Minecraft מקליד כתובת שרת — משהו צריך לאמר לו לא רק לאן להתחבר, אלא כיצד. לאיזה פורט? באיזה פרוטוקול? ואם יש כמה שרתים, איזה מהם לנסות קודם?

רשומות SRV אורזות את כל זה לתוך DNS.

מבנה רשומת SRV

רשומת SRV עוקבת אחרי פורמט ספציפי:

_service._protocol.name TTL class SRV priority weight port target

כל רכיב ממלא תפקיד:

• _service: שם השירות (_sip, _xmpp, _ldap, _minecraft)
• _protocol: פרוטוקול ההעברה (_tcp או _udp)
• name: הדומיין המציע את השירות
• priority: ערכים נמוכים יותר נוסים ראשונים (כמו רשומות MX)
• weight: מחלק את העומס בין שרתים בעלי אותה עדיפות
• port: פורט ה-TCP או UDP להתחברות
• target: שם המארח בפועל המספק את השירות

דוגמה אמיתית עבור מערכת טלפון SIP:

_sip._tcp.example.com. 86400 IN SRV 10 60 5060 sipserver1.example.com.
_sip._tcp.example.com. 86400 IN SRV 10 40 5060 sipserver2.example.com.
_sip._tcp.example.com. 86400 IN SRV 20 100 5060 sipbackup.example.com.

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

עדיפות ומשקל: בחירה דו-שכבתית

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

משקל מחלק תנועה בתוך אותה רמת עדיפות. כאשר sipserver1 (משקל 60) ו-sipserver2 (משקל 40) זמינים שניהם, הלקוחות בוחרים ביניהם בצורה אקראית משוקללת — כך ש-sipserver1 מקבל כ-60% מהחיבורים ו-sipserver2 מקבל 40%.

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

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

היכן רשומות SRV מצטיינות

SIP (VoIP): כשטלפון השולחן שלך מאתחל, הוא שואל _sip._tcp.company.com כדי לגלות את שרת הטלפון. מחלקת IT יכולה להפעיל כמה שרתים, להעביר שירותים בין מכונות, לשנות פורטים — והטלפונים מוצאים את המיקום החדש אוטומטית.

XMPP (צ'אט): צ'אט מאוחד תלוי ברשומות SRV. כשאתה שולח הודעה ל-someone@example.com, הלקוח שלך שואל _xmpp-client._tcp.example.com כדי למצוא את השרת שלהם². ארגונים שונים יכולים להפעיל שרתים משלהם ועדיין לתקשר זה עם זה בצורה חלקה.

LDAP (שירותי ספרייה): Windows Active Directory משתמש ברשומות SRV באופן נרחב. בקרי דומיין מפרסמים את עצמם דרך רשומות כמו _ldap._tcp.company.com, כך שתחנות העבודה מגלות שרתי אימות אוטומטית.

Minecraft: שרתי משחק רצים לעתים קרובות על פורטים לא סטנדרטיים. רשומת SRV ב-_minecraft._tcp.play.example.com מאפשרת למפעילים להפנות לכל פורט שהם, בעוד שהשחקנים פשוט מקלידים play.example.com. כתובות נקיות, תשתית גמישה.

CalDAV/CardDAV: לקוחות סנכרון של לוח שנה ואנשי קשר משתמשים ברשומות SRV כדי לגלות את השרתים הנכונים ללא הגדרה ידנית.

מדוע לא עבור גלישה רגילה?

רשומות SRV עובדות בצורה מצוינת עבור פרוטוקולים כמו SIP ו-XMPP. מדוע הדפדפן שלך לא משתמש בהן?

אישורי HTTPS קשורים לשמות דומיין ספציפיים. אם רשומת SRV הייתה מפנה את הדפדפן מ-www.example.com ל-webserver1.example.com, האישור לא היה תואם את ה-URL שהקלדת, ומפעיל אזהרות אבטחה.

האינטרנט פותר בעיות אלה בדרכים אחרות: מאזני עומסים, CDN, GeoDNS, anycast. כולם פועלים בתוך מגבלות אימות האישורים.

דוגמה מלאה

חברה עם מרכזי נתונים בארה"ב ובאירופה עשויה להגדיר XMPP כך:

; שרתים ראשיים בארה"ב (עדיפות 10, איזון עומסים 50/50)
_xmpp-client._tcp.example.com. 3600 IN SRV 10 50 5222 xmpp-us1.example.com.
_xmpp-client._tcp.example.com. 3600 IN SRV 10 50 5222 xmpp-us2.example.com.

; גיבוי אירופה (עדיפות 20)
_xmpp-client._tcp.example.com. 3600 IN SRV 20 100 5222 xmpp-eu1.example.com.

; כתובות ה-IP בפועל
xmpp-us1.example.com. 3600 IN A 203.0.113.10
xmpp-us2.example.com. 3600 IN A 203.0.113.11
xmpp-eu1.example.com. 3600 IN A 198.51.100.20

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

הערך העמוק

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

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

עבור פרוטוקולים שתומכים בהן, רשומות SRV הן הדרך לבנות תשתית שיכולה להשתנות מבלי לשבור את כל מה שתלוי בה.

שאלות נפוצות על רשומות SRV

כיצד מחפשים רשומת SRV?

השתמשו ב-dig או ב-nslookup. לדוגמה: dig _sip._tcp.example.com SRV יציג את כל רשומות ה-SRV עבור שירותי SIP בדומיין זה, כולל עדיפויותיהן, משקליהן, פורטיהן ושמות המארחים היעד.

מה קורה אם אין רשומת SRV?

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

האם אפשר להשתמש ברשומות SRV עבור שירותים מותאמים אישית?

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

איזה TTL מומלץ לרשומות SRV?

TTL נמוך (300–3600 שניות) מאפשר מעבר מהיר יותר לגיבוי אך מגדיל את עומס שאילתות ה-DNS. TTL גבוה מפחית שאילתות אך מאט את המעבר לגיבוי. עבור שירותים קריטיים, 5–15 דקות מאזן בין תגובתיות ליעילות.

מקורות