פרוטוקול ה-DNS משמש אותנו כדי להפוך מכתובות מילוליות לכתובות IP (שהן המציין הייחודי של כל מחשב באינטרנט) – על מנת שנוכל להשתמש בשמות קלים לזיכרון, כמו גם לחסוך לנו את הצורך לברר בכל פעם על שינויים שנעשים בכתובות IP השייכות למערכות שאליהן אנו מעוניינים להתחבר. ניתן להגיד ש-DNS הוא בעצם ה”דפי זהב” של רשת האינטרנט.
מערכת ה-DNS מורכבת מהיררכיית עץ, שהענפים שבעץ מופרדים ביניהם בסימן הנקודה. שורשו של העץ, כלומר נקודת המפתח שלו, גם מסומן מסימן נקודה, ונקרא root. מתחת לשורש העץ, נמצאים שמות מתחם ראשיים (gTLD – global Top Level Domain) -המוכרים לנו מכתובות האתרים כגון com, net, org ושמות מתחם ארציים (ccTLD – country code Top Level Domain), כגון לדוגמא il עבור ישראל. מבחינה טכנית אין כל הבדל בין שני הסוגים – שניהם – כפי שיוסבר בהמשך – בסך הכל רשומות בתוך שם מתחם השורש (.).
כל ענף בעץ ה-DNS מוגדר בתור איזור (zone) – ובתוך כל איזור שכזה מוגדרות רשומות משאב מסוגים שונים. בין השאר ישנן רשומות הממירות שם מתחם (domain name) או שם מארח בתוך המתחם (hostname) כהפנייה אל כתובת IP מגירסא 4 (או IPv4) – מה שנקרא רשומת “A”, הפנייה אל שרת הדואר המקבל דואר עבור שם המתחם (רשומת MX – Mail eXchange), הפנייה אל כתובת IP מגירסא 6 (או IPv6) – רשומת “AAAA”, או אפילו הפנייה לתת-מתחם בהמשך העץ, אשר מנוהל על ידי שרת DNS אחר (רשומת “NS” – קיצור של Name Server”), ואפילו – מי אחראי על האיזור (רשומת RP – Responsible Person).
בנוסף לרשומות המשאב, האיזור מכיל גם מידע אודות עצמו. כגון – מספר גירסת שינוי (Serial) – אשר בדרך כלל מגדירים בפורמט של תאריך ושעה לצורכי נוחות, המרווח בשניות בין רענוני מידע (Refresh) של שרתי DNS משניים, זמן ההשהיה בין נסיונות כנ”ל במקרה של כשלון
(Retry), ואף הזמן שאחריו על שרת ה-DNS להניח שהמידע כבר לא תקף אם הוא לא הצליח לקבל עדכונים עד אז (Expire). נתון נוסף חשוב מאוד שיכול להיות מוגדר על כל האיזור באופן גלובאלי (ניתן גם להגדיר לרשומה פרטנית בתוך האיזור) – הוא “זמן המחייה”, או TTL באנגלית – Time To Live. זהו ערך, המוגדר ביחידת מידה של שניות, שאומר מה אורך תקפותה של רשומה כלשהיא, ושאין להחזיק במידע אודות רשומה בעותקי מטמון מקומיים (cache) אם עבר זמן זה. הסיבה מדוע בכלל צריך לשמור עותק מקומי ולא פשוט לקבל עותק עדכני של המידע בכל פעם ישירות משרת ה-DNS המוסמך – תוסבר בהמשך.
כדי שניתן יהיה “לראות בעיניים” איך נראית הגדרת קובץ איזור, הנה דוגמא לפורמט של קובץ כזה עבור האתר בו אתם גולשים כעת, בשרת ה-DNS הנפוץ בעולם – BIND – Berkeley Internet Name Daemon. אין כאן משום המלצה על השרת הזה, ואף להפך, לעניות דעתי tinydns עושה עבודה הרבה יותר טובה, אינו פדנט בצורה מוטרפת, ואף חסכן רציני במשאבים. זוהי רק דוגמא:
$TTL 86400@ IN SOA shimi.net. hostmaster.shimi.net. ( 2007040808 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum shimi.net. IN NS ns2.powweb.com. shimi.net. IN NS ns3.powweb.com. shimi.net. IN MX 30 mx.shimi.net. shimi.net. IN A 65.254.250.106 www IN CNAME shimi.net. mx IN A 65.254.254.50 mx IN A 65.254.254.51
תוכלו לשים לב לדברים החשובים הבאים: מוגדר TTL כללי עבור האיזור, שהוא 86400 שניות (יממה שלמה אחת. לא מאמינים? תכפילו – 60*60*24 ותראו בעצמכם…). זה אומר שכל נתון שלקוח DNS כלשהוא בעולם יחליט לשמור מאתר זה, נאסר עליו “לזכור” את מה שהוא למד למשך יותר מ-24 שעות. ולמה זה חשוב לנו? משום שאם יום אחד אני אחליט להעביר את האתר שלי, או את שרת הדואר שלי, למחשב אחר, אני רוצה שכל הגולשים באתר יקבלו עדכון על כתובת המחשב החדש תוך זמן קצר, ולא ימשיכו במשך המון זמן (נניח – שבוע…) לנסות להגיע אל השרת הישן, שכבר עשוי כלל לא להכיל את האתר שלי או את תיבת הדואר האלקטרוני שלי, ואז אאבד מבקרים ו/או דואר אלקטרוני. אמרתי קודם שאסביר מדוע בכלל שומרים את הנתונים האלה ולא מבררים מהמקור המעודכן את הנתונים שבטוח נכונים? ובכן, הסיבה פשוטה. קודם כל, עניין של עומסים על השרתים המרכזיים. כיוון שכל חיפוש ברשת ה-DNS מתחיל משורש העץ כלפי מטה, אם לא היה מנגנון שהיה זוכר את תוצאות השאילתות, אזי כל חיפוש DNS, על ידי כל אחד ממליוני (או שמא מליארדי?) המשתמשים באינטרנט, היה מגיע אל שרתי ה-DNS המרכזיים – ואין שום סיכוי שהם היו עומדים בעומס הזה, לא מבחינת קצב עיבוד נתונים, וייתכן מאוד שגם לא מבחינת רוחב הפס המוקצה להם. לכן חשוב לזכור נתונים שכבר נאספו. סיבה שנייה היא יעילות עבור משתמש הקצה. כשהתוצאה מאוחסנת בלקוח ה DNS המקומי (שזה בדרך כלל שרת הנמצא בספק האינטרנט שאליו משתמש הקצה מחובר), זמן הגישה אל הנתונים מהיר בהרבה. בחיבור אינטרנט ממוצע, מדובר על לא יותר מכ-50 מילי-שניות בין זמן שליחת הבקשה לקבלת התגובה. אם הבקשה הייתה צריכה בכל פעם לשאול את כל שרתי ה DNS המרכיבים את העץ (הסבר יבוא בהמשך), ייתכן שהמשתמש היה ממתין זמן של אפילו שניות שלמות כדי לקבל תשובה.
מכל התאוריה שלעיל, נעבור כעת לת’אכלס – מה קורה, לדוגמא, כאשר גולשים לאתר www.cnn.com.
נניח שאני לקוח של חברת נטויז’ן. כשאני מתחבר לאינטרנט, המערכות של נטויז’ן אומרות למחשב (או לנתב הביתי שלי) שעליו להשתמש בשרתי ה-DNS הבאים: 194.90.1.5 ו- 194.90.1.49 כדי לבצע שאילתות DNS.
אני מעוניין, כאמור, לגלוש ל www.cnn.com. לצורך כך, אני צריך למצוא את כתובת ה-IP של השרת של www.cnn.com. המחשב שלי יפנה לשרת ה-DNS של נטויז’ן וישאל אותו: תן לי בבקשה רשומת A של www.cnn.com. נניח שלשרת של נטויז’ן אין שום מידע קודם בנושא. מה הוא ילך לעשות? הוא ילך לברר בעצמו מה הכתובת של www.cnn.com, ולשם כך הוא ישאל את אחד משרתי ה-DNS הראשיים של האינטרנט, לדוגמא השרת a.root-servers.net:
; <<>> DiG 9.2.5 <<>> @a.root-servers.net www.cnn.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23611 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14 ;; QUESTION SECTION: ;www.cnn.com. IN A ;; AUTHORITY SECTION: com. 137834 IN NS d.gtld-servers.net. com. 137834 IN NS e.gtld-servers.net. com. 137834 IN NS f.gtld-servers.net. com. 137834 IN NS g.gtld-servers.net. com. 137834 IN NS h.gtld-servers.net. com. 137834 IN NS i.gtld-servers.net. com. 137834 IN NS j.gtld-servers.net. com. 137834 IN NS k.gtld-servers.net. com. 137834 IN NS l.gtld-servers.net. com. 137834 IN NS m.gtld-servers.net. com. 137834 IN NS a.gtld-servers.net. com. 137834 IN NS b.gtld-servers.net. com. 137834 IN NS c.gtld-servers.net. ;; ADDITIONAL SECTION: a.gtld-servers.net. 171837 IN A 192.5.6.30 a.gtld-servers.net. 171759 IN AAAA 2001:503:a83e::2:30 b.gtld-servers.net. 161282 IN A 192.33.14.30 b.gtld-servers.net. 165361 IN AAAA 2001:503:231d::2:30 c.gtld-servers.net. 171159 IN A 192.26.92.30 d.gtld-servers.net. 161282 IN A 192.31.80.30 e.gtld-servers.net. 171159 IN A 192.12.94.30 f.gtld-servers.net. 171159 IN A 192.35.51.30 g.gtld-servers.net. 171159 IN A 192.42.93.30 h.gtld-servers.net. 171159 IN A 192.54.112.30 i.gtld-servers.net. 170422 IN A 192.43.172.30 k.gtld-servers.net. 171159 IN A 192.52.178.30 l.gtld-servers.net. 171159 IN A 192.41.162.30 m.gtld-servers.net. 171159 IN A 192.55.83.30 ;; Query time: 190 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Sun Apr 8 15:20:24 2007 ;; MSG SIZE rcvd: 493
כלומר, המידע על רשומות המשאבים של com,מוחזק בסט שלם של שרתי DNS אחרים, תחת שם המתחם gtld-servers.net. כדי לעשות לנו את החיים “קלים”, מסופקות גם “רשומות דבק” שנותנות לנו כבר בבקשה זו את כתובות ה – IP של שרתים אלה, כדי שלא נצטרך לבדוק אותם בעצמנו. עכשיו יפנה שרת ה DNS של נטויז’ן באופן אקראי לאחת מכתובות ה-IP שהוא קיבל בתשובה משרתי ה-DNS הראשיים של האינטרנט, וישאל אותו: “www.cnn.com – מה דינו?” – ויקבל את התשובה הבאה:
; <<>> DiG 9.2.5 <<>> @a.gtld-servers.net www.cnn.com ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 408 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;www.cnn.com. IN A ;; AUTHORITY SECTION: cnn.com. 172800 IN NS twdns-01.ns.aol.com. cnn.com. 172800 IN NS twdns-02.ns.aol.com. cnn.com. 172800 IN NS twdns-03.ns.aol.com. cnn.com. 172800 IN NS twdns-04.ns.aol.com. ;; ADDITIONAL SECTION: twdns-01.ns.aol.com. 172800 IN A 149.174.213.151 twdns-02.ns.aol.com. 172800 IN A 152.163.239.216 twdns-03.ns.aol.com. 172800 IN A 207.200.73.85 twdns-04.ns.aol.com. 172800 IN A 64.12.147.120 ;; Query time: 233 msec ;; SERVER: 192.5.6.30#53(192.5.6.30) ;; WHEN: Sun Apr 8 15:30:53 2007 ;; MSG SIZE rcvd: 192
גם כאן אומר לנו a.gtld-servers.net בעצם: “מה אתם רוצים מהחיים שלי – אני לא יודע כלום על www.cnn.com, אם אתם רוצים משהו על כל מה שמתחת ל cnn.com, אנא פנו לאחד משרתי ה-DNS הבאים: twdns-01.ns.aol.com, twdns-02.ns.aol.com, twdns-03.ns.aol.com, twdns-04.ns.aol.com”, ושוב, מנדב לנו גם את כתובות ה-IP של שרתים אלה כתוספת לתשובה, כדי שלא נצטרך לחפש אותם. “סבבה”, אומר לעצמו השרת של נטויז’ן, בוחר אקראית את אחד מארבעת השרתים האלה, ושואל אותו: “נו, שמישהו יגיד לי כבר מה ה-IP של www.cnn.com!”, והנה התשובה שהוא מקבל:
; <<>> DiG 9.2.5 <<>> @twdns-02.ns.aol.com www.cnn.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6714 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.cnn.com. IN A ;; AUTHORITY SECTION: www.cnn.com. 3600 IN NS dmtns01.turner.com. www.cnn.com. 3600 IN NS dmtns02.turner.com. ;; ADDITIONAL SECTION: dmtns01.turner.com. 3608 IN A 64.236.29.150 dmtns02.turner.com. 3608 IN A 64.236.22.150 ;; Query time: 163 msec ;; SERVER: 152.163.239.216#53(152.163.239.216) ;; WHEN: Sun Apr 8 15:33:16 2007 ;; MSG SIZE rcvd: 112
מה הולך כאן? היינו אמורים לקבל תשובה כבר מהשרת הזה! נו טוב. אז CNN החליטו להחליף את שרתי ה-DNS שלהם – אבל למה שהם יעדכנו את רשם שמות המתחם אודות שרתי ה-DNS החדשים אם ניתן פשוט לגרום ללקוחות שלהם עוד עיכוב, ולשלוח אותם לשרת DNS נוסף ומיותר? באין ברירה, שרת ה-DNS של נטויז’ן ממשיך הלאה, ופונה אל dmtns01.turner.com כדי לקבל סופסוף את המידע הנכסף, וזה נראה כך:
; <<>> DiG 9.2.5 <<>> @dmtns01.turner.com www.cnn.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44943 ;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.cnn.com. IN A ;; ANSWER SECTION: www.cnn.com. 600 IN A 64.236.29.120 www.cnn.com. 600 IN A 64.236.91.21 www.cnn.com. 600 IN A 64.236.91.22 www.cnn.com. 600 IN A 64.236.91.23 www.cnn.com. 600 IN A 64.236.91.24 www.cnn.com. 600 IN A 64.236.16.20 www.cnn.com. 600 IN A 64.236.16.52 www.cnn.com. 600 IN A 64.236.24.12
פשש, כמה שרתים יש להם! כנראה שהדפדפן של הגולש יצטרך לבחור אקראית אחד משמונה כדי לקבל ממנו את האתר! שימו לב לעוד נתון מעניין – הTTL שלהם הוא בסך הכל 600 שניות, או עשר דקות. למה כל כך נמוך? כדי שיבררו את עדכניות הנתונים כל עשר דקות. ולמה להעמיס כל כך הרבה על ה-DNS? כנראה משום שזמינות חשובה להם, ורוצים שאם שרת מתוך השמונה ייפול, ה-DNS יעודכן מייד על ידי תהליך אוטומטי שיסיר את השרת מהרשימה, ולאף אחד האתר לא יהיה זמין למשך זמן שארוך יותר מעשר דקות, הלא הוא הזמן המקסימלי שיהיה מותר ללקוחות לשמור את המידע אודות המרת כתובת ל-IP זו.
לסיום, נקודות שחשוב להבהיר: כל אחד מהשלבים שהוזכר, גם שומר לעצמו את המידע שהתקבל כתוצאה מהשאילתא בעותק מקומי (בהנחה ומדובר ב-caching name server – ולרוב אכן בכך מדובר), כך שאם המידע כבר היה זמין מקומית, השרת לא היה טורח לטייל בכל כדור הארץ כדי למצוא אותו, אלא טוען אותו מהעותק המקומי, ובכך חוסך תעבורת רשת וזמן. ובנוסף, אם שרת DNS כלשהוא, מרמת הלקוח, וכל השרתים שעזרו לתהליך הפיענוח בדרך, היה לא זמין, אזי המבקש היה פונה לשרת אקראי אחר ברשימה, ומקבל את התשובה ממנו. זה היה לוקח יותר זמן, אבל היה מצליח בסוף. זו הסיבה שתמיד משתמשים ביותר משרת DNS אחד לכל איזור – שרידות.