עודכן לפני חודש
מערכת הטלפוניה והאינטרנט צמחו בנפרד. מספרי טלפון עוקבים אחר E.164 — מערכת היררכית שתוכננה לרשתות עם מיתוג מעגלים. כתובות אינטרנט עוקבות אחר DNS — מערכת היררכית שתוכננה לרשתות מבוססות-חבילות. אף אחת מהן אינה יודעת לדבר את שפת האחרת.
רשומות NAPTR הן המתרגמות.
כאשר אתה מחייג מספר טלפון והוא מתחבר לשירות VoIP, או כאשר לקוח SIP מגלה איזה שרת מטפל בדומיין, רשומות NAPTR מבצעות את ההמרה. הן לוקחות מזהה ממרחב שמות אחד ומשנות אותו למזהה במרחב שמות אחר באמצעות כללי התאמת תבניות.
מבנה של שישה שדות
רשומות NAPTR (Naming Authority Pointer) הן בעלות הפורמט המורכב ביותר מכל סוג רשומת DNS:
שישה שדות, לכל אחד תפקיד ספציפי:
סדר (100): אילו רשומות לעבד ראשונות. מספרים נמוכים זוכים. רק רשומות שחולקות את ערך הסדר הנמוך ביותר נלקחות בחשבון.
עדיפות (10): מכריע בין רשומות עם ערכי סדר זהים. שוב, נמוך יותר זוכה.
דגלים ("u"): מה לעשות עם התוצאה. "u" אומר שהפלט הוא URI וסיימנו. "s" אומר לבצע שאילתה לרשומות SRV בשלב הבא. "a" אומר לבצע שאילתה לרשומות A/AAAA בשלב הבא. ריק אומר להמשיך לעבד רשומות NAPTR.
שירותים ("E2U+sip"): איזה שירות ופרוטוקול כלל זה מטפל בו. "E2U" פירושו ENUM (המרת מספר טלפון ל-URI). "SIP+D2T" פירושו SIP מעל TCP.
ביטוי רגולרי ("!^.*$!sip:info@example.com!"): ביטוי רגולרי שמשנה את הקלט. המפרידים (בדרך כלל "!") מפרידים בין תבנית ההתאמה למחרוזת ההחלפה.
החלפה (.): היכן להמשיך אם נדרשות שאילתות DNS נוספות. נקודה אומרת לא לאן — הפלט של הביטוי הרגולרי הוא סופי.
ENUM: מספרי טלפון הופכים לכתובות אינטרנט
ENUM (E.164 Number Mapping) הוא יישום הדגל של NAPTR. הוא עונה על השאלה: בהינתן מספר טלפון, אילו משאבי אינטרנט יכולים להגיע לאדם זה?
ההמרה היא ייחודית ומדויקת. קח את +1-555-123-4567. הסר את העיצוב, הפוך את הספרות, הכנס נקודות בין כל ספרה, והוסף e164.arpa:
מספר הטלפון הופך לשם דומיין, הניתן לקריאה על ידי DNS. בצע שאילתה לרשומות NAPTR בדומיין זה:
שלוש דרכים להגיע לבעל מספר הטלפון: שיחת SIP (עדיפות 10), אימייל (עדיפות 20), או טופס אינטרנט (עדיפות 30). יישומים בוחרים את השיטה שהם תומכים בה.
ניתוב SIP: בחירת פרוטוקולים ושרתים
מערכות Session Initiation Protocol משתמשות ב-NAPTR כדי לענות על שאלה שונה: כאשר מתחברים לדומיין SIP, איזה פרוטוקול תעבורה ושרת יש להשתמש בהם?
לקוח שרוצה להגיע אל user@example.com מבצע שאילתה לרשומות NAPTR ב-example.com:
הדגל "s" אומר: קח את שדה ההחלפה ובצע שאילתה לרשומות SRV שם. זה יוצר שרשרת פתרון:
- רשומות NAPTR קובעות את פרוטוקול התעבורה (TCP מועדף על UDP, שניהם מועדפים על TLS)
- רשומות SRV ב-_sip._tcp.example.com מזהות שרתים ספציפיים, פורטים ומשקלי איזון עומסים
- רשומות A/AAAA מספקות את כתובות ה-IP בפועל
שלושה חיפושי DNS, כל אחד עונה על שאלה שונה: איזה פרוטוקול, איזה שרת, איזו כתובת.
שרשרת ההאצלה
רשומות NAPTR לעתים נדירות עובדות לבד. התבנית הטיפוסית:
- בצע שאילתה ל-NAPTR כדי לקבוע שירות ופרוטוקול
- הדגל "s" של NAPTR מאצל לרשומות SRV
- בצע שאילתה ל-SRV כדי למצוא שרתים, פורטים, עדיפויות ומשקלים
- בצע שאילתה ל-A/AAAA כדי לתרגם שמות שרתים לכתובות IP
- התחבר
הפרדה זו חשובה. מנהלי מערכות יכולים לשנות תשתית שרתים (רשומות SRV ו-A/AAAA) מבלי לגעת במדיניות שירות (רשומות NAPTR). העדפות פרוטוקול ואיזון עומסים נמצאים בשכבות שונות, ומתעדכנים באופן עצמאי.
עוצמת הביטויים הרגולריים
שדה הביטוי הרגולרי יכול לעשות יותר מהחלפה פשוטה. קבוצות לכידה מאפשרות המרות מתוחכמות:
תבנית זו מתאימה למספרים +1-555, לוכדת את החלק המקומי בן שבע הספרות, ובונה URI של SIP תוך שימוש בחלק זה בלבד. קידומות אזוריות שונות יכולות להפנות לשרתים שונים. מספרים פרימיום יכולים להפנות למטפלים מיוחדים.
היכן נמצאות רשומות NAPTR
רוב מנהלי ה-DNS לעולם אינם נוגעים ברשומות NAPTR. הן מופיעות בסביבות מיוחדות:
- תשתית טלפוניה: ספקים ועסקים המיישמים ENUM או ניתוב SIP
- ספקי שירות גדולים: ארגונים המציעים מספר פרוטוקולים דרך מזהים מאוחדים
- אינטגרציות מחויבות-תקן: מערכות המיישמות RFCs הדורשים NAPTR
המורכבות דורשת בדיקה קפדנית. ביטוי רגולרי שגוי שובר את הפתרון לחלוטין. דגלים שגויים יוצרים לולאות אינסופיות או מבואות סתומים. איתור תקלות מחייב מעקב אחר השרשרת המלאה — מ-NAPTR ל-SRV ל-A/AAAA — שכן כשל בכל שלב מייצר את אותו תסמין: חיבור שנדחה.
המטמון מחמיר את המצב. אם לרשומת NAPTR שלך יש TTL של שעה אחת אך לרשומות SRV שלך יש TTL של 24 שעות, תוכל לעדכן את NAPTR להצביע על תשתית חדשה ולקוחות עדיין יעקבו אחר ה-SRV השמור במטמון לשרתים שהוצאו משירות למשך יום שלם. שרשרת הפתרון עדכנית רק כמו החוליה המיושנת ביותר שבה.
שאלות נפוצות על רשומות NAPTR
מדוע מספרי טלפון הפוכים בחיפושי ENUM?
DNS קורא באופן היררכי מימין לשמאל — example.com אומר "מצא את com, ואז מצא בתוכו את example". מספרי טלפון הם היררכיים משמאל לימין — +1-555 אומר "מדינה 1, ואז אזור 555". היפוך הספרות מיישר את ההיררכיה של מספר הטלפון עם ההיררכיה של DNS, ומאפשר האצלה בכל רמה.
מה קורה אם למספר רשומות NAPTR יש אותו סדר ועדיפות?
היישום בוחר ביניהן באופן שרירותי. זה מכוון לצורך חלוקת עומסים — אם אתה רוצה התנהגות דטרמיניסטית, השתמש בערכי עדיפות שונים. אם אתה רוצה חלוקה אקראית, השתמש בערכים זהים.
האם רשומות NAPTR יכולות להצביע ישירות על כתובות IP?
לא. שדה ההחלפה חייב להיות שם דומיין או ריק. לצורך פתרון סופי לכתובות IP, NAPTR מאצל לרשומות A/AAAA (דרך הדגל "a") או משתשל דרך רשומות SRV תחילה (דרך הדגל "s").
כיצד אני בודק את תצורת רשומות NAPTR?
השתמש ב-dig NAPTR example.com לביצוע שאילתה ישירה לרשומות NAPTR. לבדיקת ENUM, המר תחילה את מספר הטלפון שלך לפורמט e164.arpa ההפוך. עקוב אחר השרשרת המלאה: NAPTR → SRV → A/AAAA כדי לוודא שכל שלב האצלה נפתר כראוי.
האם דף זה היה מועיל?