| מודל השכבות > DNS < IP | עמוד השער | מושגים |
| |
| |||||||||||||||||||||||||||||||
| פענוח שמות באינטרנט - DNS | |||||||||||||||||||||||||||||||
|
מיפוי שמות domain לשמות פיסיים
| |||||||||||||||||||||||||||||||
| אם כדי להתחבר לאתר באינטרנט, היינו צריכים לזכור את כתובת ה- IP שלו, סביר להניח שהאינטרנט לא הייתה זוכה לפופולריות הנוכחית שלה. כדי להקל על המשתמשים, פותח מנגנון המאפשר למשתמש לבקש להתחבר לאתר לפי שם, שנוח לזכור, ולא לפי כתובת ה- IP של האתר. בזכות מנגנון זה, הנקרא DNS (שירות שמות באינטרנט, domain name server), אפשר להקליד כתובת כמו www.google.com בחלון הדפדפן, במקום מספר כמו 130.49.53.2. הרבה יותר נוח... | |||||||||||||||||||||||||||||||
|
בראשית ימי האינטרנט, כל אתר בחר לו שם, ללא מבנה קבוע. אתר מרכזי היה אמור לבדוק כל שם ולהחליט אם הוא חוקי. | |||||||||||||||||||||||||||||||
| היתרון המרכזי שבמרחב שמות שטוח הוא שהשמות בו הם נוחים וקצרים. החיסרון המרכזי הוא שמרחב שמות כזה לא יכול להיות מוכלל לקבוצות גדולות של מחשבים, מסיבות טכניות ומנהלתיות כאחד. ראשית, משום שהשמות לקוחים מקבוצה סופית של מזהים, הפוטנציאל לקונפליקטים גדל ככל שמספר האתרים גדל. שנית, בגלל שהסמכות להוספת שמות חדשים נמצאת בידיו של אתר ניהולי מרכזי אחד, עומס העבודה המנהלתית אצלו גדלה גם היא, ככל שגדלים מספר האתרים. (כדי להבין את חומרת הבעיה, ניתן לדמיין את האינטרנט, כפי שהוא מוכר לנו היום, במבנה שטוח: לפי המבנה הזה, בכל פעם שמישהו מחבר מחשב פרטי אל הרשת, השם שלו צריך להיות מאושר על ידי האתר המרכזי). שלישית, משום שהקשר בין שם לכתובת פיסית משתנה בצורה תכופה, העלות של שמירת עותקים מעודכנים של הרשימה כולה היא גבוהה, ועולה ככל שמספר האתרים גדל. | |||||||||||||||||||||||||||||||
| כיצד יכולה מערכת שמות לתחזק קבוצת שמות גדולה, המתפשטת במהירות, בלי להזדקק לאתר מרכזי שינהל אותה? התשובה נעוצה בביזור מנגנון השמות באמצעות האצלת סמכויות על חלקים ממרחב השמות וחלוקת האחריות על מיפוי השמות לכתובות. האינטרנט המבוסס על TCP/IP משתמש בתוכנית כזאת. | |||||||||||||||||||||||||||||||
| כדי להבין כיצד יש לחלק מרחב שמות גדול, ניתן לחשוב על המבנה הפנימי של ארגונים גדולים. בראש עומד המנכ"ל שהוא בעל אחריות כוללת. משום שהוא אינו מסוגל לפקח על כל העבודה, הארגון עשוי להיות מחולק למחלקות, שבראש כל אחת מהן עומד מנהל מחלקה שאחראי עליה. המנכ"ל מקנה לכל מחלקה עצמאות בגבולות מוגדרים, כך שמבחינה מעשית, מנהל המחלקה יכול לשכור או לפטר עובדים, לחלק משימות ולהאציל סמכויות, הכל בהתאם לשיקול דעתו, ובלי לקבל אישור ישיר מן המנכ"ל. | |||||||||||||||||||||||||||||||
|
ההיררכיה של ארגון גדול מאפשרת להאציל סמכויות בצורה נוחה. יתרה מכך, היא מציגה אפשרות של פעילות אוטונומית בלתי תלויה במנכ"ל.
| |||||||||||||||||||||||||||||||
| מערכת שמות היררכית עובדת כמו מערכת ניהולית של ארגון גדול. מרחב השמות מחולק ברמה הגבוהה ביותר, והסמכות להענקת שמות בתתי המרחבים שנוצרו מועברת לסוכנים מיוחדים. בצורה הזו הסמכות העליונה אחראית לחלוקת מרחב השמות לתתי מחלקות ולהאצלת סמכויות לכל תת מחלקה שנוצרה. אות הסמכות עליונה לא צריכה להטריד את עצמה בשינויים שמתרחשים בתוך תתי המחלקות. | |||||||||||||||||||||||||||||||
| המבנה התחבירי של השמות משקף, פעמים רבות, את החלוקה ההיררכית של מרחב השמות. למשל במרחב השמות שכולל את השם Local.site: local הוא שם האתר והוא נשלט על ידי הסמכות המרכזית, ו site נשלט על ידי האתר ונמצא באחריותו. הנקודה שבין שני השמות מציינת את ההפרדה ביניהם. כאשר הסמכות העליונה ביותר מאשרת להוסיף אתר חדש בשם X, היא מוסיפה את השם X לרשימת השמות התקפים, ומאצילה לו את הסמכות לקבוע שמות שיסתיימו ב "X". | |||||||||||||||||||||||||||||||
| במרחב שמות היררכי ניתן לחלק עוד את הסמכות בכל רמה. למשל, בחלוקה לאתרים, האתר עצמו יכול להיות מורכב מכמה קבוצות ניהוליות, והסמכות המרכזית באתר יכולה להחליט על חלוקת מרחב השמות של האתר בין הקבוצות הללו. הרעיון הוא להמשיך ולחלק את מרחב השמות עד שמגיעים לקבוצה קטנה מספיק שאותה נוח לנהל. | |||||||||||||||||||||||||||||||
| מבחינה תחבירית, חלוקת מרחב השמות יוצרת חלוקה נוספת של השם. למשל, הוספת תת קבוצה בשם group לאתר local יוצרת את השם הבא: local.group.site. | |||||||||||||||||||||||||||||||
| מכיוון שהרמה הגבוהה ביותר מאצילה מסמכותה, שמות הקבוצות לא צריכים להתאים זה לזה בין כל האתרים. אתר האוניברסיטה, למשל, יכול לבחור שמות של קבוצות כמו: הנדסה, מדעים,ואומנויות. אתר מסחרי יכול לבחור שמות כמו ייצור, הנהלת חשבונות, ומנהלה. | |||||||||||||||||||||||||||||||
|
באינטרנט המבוסס על TCP/IP, שם המחשב נקבע לו באופן היררכי, על פי מיקומו במבנה הארגון שאליו הוא שייך. חשוב לציין כי המיקום הנדון הוא מיקום ארגוני שנקבע על ידי הסמכות הארגונית. זהו לא מיקום פיסי! יש לציין, עם זאת, כי ברור שבאתרים רבים, המבנה הארגוני יהיה מתאים למבנה הפיסי של הרשתות המקושרות. באוניברסיטה גדולה, למשל, סביר שלכל מחלקה תהיה רשת מקומית עצמאית משלה. אם למחלקה מוקצה חלק ממרחב השמות, כל המכונות שיהיו בעלי שמות ששייכים למרחב השמות הזה, יהיו מחוברים לרשת פיסית אחת.
| |||||||||||||||||||||||||||||||
| שמות domain באינטרנט | |||||||||||||||||||||||||||||||
| כפי שצוין כבר, המנגנון המממש את היררכית השמות לרשתות TCP/IP נקרא DNS. DNS ממלא שני תפקידים עיקריים: | |||||||||||||||||||||||||||||||
| הגדרת המבנים התחביריים של שמות, וחלוקת הסמכויות להענקת השמות. | |||||||||||||||||||||||||||||||
| מימוש מערכת שרתים מבוזרת הממפה ביעילות את השמות לכתובות IP. | |||||||||||||||||||||||||||||||
| מערכת השמות משתמשת בתוכנית היררכית המכונה "שמות domain". לפי התוכנית הזאת, שם domain מורכב מרצף של תתי שמות מופרדים בתו מפריד (נקודה). ציינו כבר שחלקים שונים של השם עשויים לייצג עבורנו אתרים שונים או קבוצה מסוימת בתוך אתר יחיד; מבחינתה של מערכת השמות מכונה כל קטע של השם תווית (label). | |||||||||||||||||||||||||||||||
| ניקח למשל את השם tau.ac.il: | |||||||||||||||||||||||||||||||
| TAU - אוניברסיטת ת"א, | |||||||||||||||||||||||||||||||
| AC - אתר אקדמי, | |||||||||||||||||||||||||||||||
| IL - אתר הנמצא בישראל . | |||||||||||||||||||||||||||||||
| כל סיומת של תווית בשם ה domain מכונה בעצמה domain. כך שבדוגמא ראינו שם שיש לו ארבע רמות: | |||||||||||||||||||||||||||||||
|
IL AC.IL TAU.AC.IL | |||||||||||||||||||||||||||||||
| שמות רשמיים ולא רשמיים | |||||||||||||||||||||||||||||||
| שם ה-domain מגדיר היררכיה מופשטת של מרחב השמות עם ערכים שרירותיים לתוויות. בגלל שמערכת ה domain מכתיבה רק את מבנה השמות, ולא את הערכים שלהם - כל אתר יכול לבחור בערכי השמות שרצויים לו, ואינו חייב להשתמש בשמות הרשמיים. כך, למשל, חברה פרטית יכולה להגדיר היררכית domain שבה התוויות מהרמה הגבוהה ביותר מגדירה את חברות הבת שלה, הרמה הנמוכה יותר מגדירה את מחלקות הארגון, והרמה התחתונה ביותר את המשרדים השונים. | |||||||||||||||||||||||||||||||
|
עם זאת, רוב המשתמשים של טכנולוגיית ה domain משתמשים בתוויות ההיררכיות הרשמיות של מערכת ה domain המרכזית. יש לכך שתי סיבות. ראשית, מערך השמות הרשמי הוא גם פשוט ובהיר, וגם גמיש. הוא מסוגל לאכלס מגוון רחב של ארגונים, ולאפשר לכל קבוצה לבחור בין היררכית שמות גיאוגרפית להיררכית שמות ארגונית. שנית, רוב האתרים משתמשים במערך השמות המקובל כדי להתאים את התקנות ה TCP/IP לאינטרנט הגלובאלי בלי לשנות שמות.
| |||||||||||||||||||||||||||||||
|
ICANN, הגורם הרשמי האחראי על מתן השמות באינטרנט בחר לחלק את שמות הdomain ברמתם הגבוהה ביותר לפי החלוקה הבאה:
| |||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
| למעשה, השמות ברמתם הגבוהה ביותר הם שמאפשרים בחירה בין חלוקה היררכית גיאוגרפית לארגונית. החלוקה הגיאוגרפית מחלקת את העולם לפי מדינות: כך למשל, ארגונים בארה"ב יכולים לקבל את הסיומת US, וארגונים ישראליים יכולים לקבל את הסיומת IL. כאלטרנטיבה להיררכיה הגיאוגרפית, קיימת חלוקה לפי סוגי הארגון - למשל הסיומת COM לחברות מסחריות. | |||||||||||||||||||||||||||||||
| כאשר ארגון רוצה לקבל שם ממרחב השמות הרשמי, הוא בוחר בשם הרצוי ךן ומחכה לאישור רשמי. הסמכות המרכזית בוחנת את הבקשה ומקצה לארגון sub-domain תחת אחד ה 'domainים מהרמה הגבוהה ביותר. למשל, אוניברסיטה יכולה לבקש לרשום את עצמה כ domain מהרמה השנייה של ה domain העליון EDU. לחלופין, היא יכולה לבקש להירשם תחת המדינה אליה היא שייכת. בארה"ב, נראה שמרבית הארגונים בוחרים בהיררכיה הארגונית על פני זו הגיאוגרפית, ויש לכך שתי סיבות. ראשית, שמות גיאוגרפיים הם ארוכים יותר ולכן קשה יותר לזכור אותם ולהקליד אותם. שנית, קשה יותר לגלות או לנחש שמות גיאוגרפיים. למשל, אוניברסיטת purdue ממוקמת במערב לאפייט שבאינדיאנה. בעוד שהמשתמש יכול בקלות לנחש שאתר האוניברסיטה הוא purdue.edu, סביר שהוא יתקשה לנחש את השם ההיררכי גיאוגרפי purdue.laf.in.us. גם חברות מסחריות מעדיפות להירשם תחת שם ה- domain "COM", כדי לא לשייך את עצמן למדינה אחת בלבד. בארץ, עם זאת, רוב הארגונים והמוסדות החינוכיים כן משתמשים בסיומת של המדינה, וכך אוניברסיטאות בארץ אינן משתמשות בסיומת EDU אלא בשם AC.IL.
| |||||||||||||||||||||||||||||||
| מיפוי שמות domain לכתובות פיסיות | |||||||||||||||||||||||||||||||
| DNS מאפשר, כמובן, גם לאתר כתובות IP של אתרים, לפי שמותיהם. לשם כך, מערכת השמות כוללת מערכת מבוזרת ויעילה למיפוי של שמות אתרים לכתובות IP. המערכת מבוזרת, בכך שאין שרת אחד בלבד ששאליו צריכים כולם לגשת, אלא קבוצה גדולה של שרתי שמות (Domain Name Servers) בהרבה אתרים. המערכת יעילה, בכך שלרוב לא נדרשת תעבורה גוזלת זמן ברשת למטרת מיפוי שם. המערכת אמינה, ומבטיחה שנפילה של שרת אחד לא תפגע בתפקודה של המערכת כולה. | |||||||||||||||||||||||||||||||
| הדרך הקלה ביותר להבין כיצד פועלים שרתי ה domain היא לדמיין אותם מסודרים במבנה של עץ, שמתאים מבחינת ההיררכיה שלו להיררכית השמות. שורש העץ הוא שרת שמזהה את ה domains ברמתם הגבוהה ביותר ויודע אילו שרתים ממפים את שמות ה domain הללו. בהינתן שם לפענוח, השורש יכול לבחור את השרת המתאים עבור השם הזה. ברמה הבאה, קבוצת שמות של שרתים המספקים שמות עבור domainים מרמה מסוימת (למשל קבוצת שרתים המפענחים שמות המסתיימים ב edu). שרת ברמה הזו יודע אילו שרתים יכולים לפענח תתי domainים שתחת ה domain שלו. העץ הקונספטואלי הזה ממשיך עוד ועוד עד שהשם מוגדר כולו. מכיוון שהשרתים שבעץ אינם תלויים אלה באלה, הם יכולים להימצא במקומות שונים באינטרנט, כך ששרתי העץ עצמם מהווים אבסטרקציה שמשתמשת באינטרנט לצורך תקשורת. | |||||||||||||||||||||||||||||||
| אם השרתים של מערכת השמות היו עובדים בדיוק לפי המודל הפשטני שתיארנו, אז כאשר הסמכות המרכזית היתה מקצה שם תחת domain מסוים - הארגון המבקש היה צריך פשוט ליצור שרת domain שיחובר אל עץ שרתי השמות. במציאות, זה לא קורה בדרך כלל. לעצי השרתים יש מעט מאד רמות, משום ששרת פיסי אחד יכול להכיל את כל המידע עבור היררכית השמות. כך יוצא שהחיפוש הוא הרבה יותר יעיל בעיקר משום שעץ החיפוש הוא הרבה פחות עמוק. | |||||||||||||||||||||||||||||||
| קיימות שתי דרכים לשימוש במערך פענוח השמות: באמצעות התקשרות לשרתי השמות בזה אחר זה או באמצעות בקשה ממערך השמות שיבצע את הפענוח כולו. בכל מקרה, התוכנה של הלקוח יוצרת בקשה שמכילה את השם שיש לפענח (למשל, www.google.com), הכרזה על סוג האובייקט שהשם אמור לייצג (במקרה זה - שרת web), וקוד שמגדיר האם יש לתרגם את השם כולו. הבקשה הזו נשלחת אל שרת השמות. | |||||||||||||||||||||||||||||||
|
כאשר שרת השמות מקבל בקשה כזו, הוא בודק האם השם הנתון נמצא תחת שליטתו. אם כן, הוא מתרגם את השם לכתובת IP בהתאם לבסיס הנתונים שלו ומצרף את התשובה שלו אל הבקשה לפני שהוא שולח אותה חזרה אל הלקוח. אם השרת מגלה שאינו מסוגל לפענח את השם (השם לא תחת שליטתו), הוא בודק איזה סוג של פענוח הלקוח ביקש. אם הלקוח ביקש פענוח מלא, השרת מתקשר עם שרת אחר שמסוגל לפענח את השם ומחזיר את התשובה של אותו שרת אל הלקוח. אחרת (הלקוח ביקש פענוח לא מלא) השרת לא מסוגל לספק תשובה: הוא מייצר תשובה שמבהירה מיהו השרת שאליו יש לפנות בכדי לקבל פענוח של השם הנדון. | |||||||||||||||||||||||||||||||
| כיצד מוצא הלקוח את השרת שאצלו יש להתחיל את החיפוש? כיצד יודע השרת למצוא שרת מתאים שיוכל לספק תשובה לשאלה שהוא לא יודע את התשובה עליה? התשובות הן פשוטות: הלקוח צריך להכיר לפחות שרת שמות אחד. מערכת השמות מבטיחה ששרת יכיר לפחות שרת "שורש" אחד, ובדרך כלל גם את ההורה שלו בעץ - כך שמובטח שכל שרת שהלקוח יכיר יוכל, בסופו של דבר, לאפשר לו לפענח כל שם במערכת. | |||||||||||||||||||||||||||||||
| למרות שנראה טבעי לפענח שמות באמצעות טיול במורד עץ שרתי השמות (כלומר, להתחיל בחיפוש מההיררכיה הגבוהה ביותר, שממנה ניתן להגיע לכל מקום), הטיול הזה עלול להיות לא יעיל וזאת מכמה סיבות: | |||||||||||||||||||||||||||||||
| 1. רוב השמות שיש לפענח שייכים לשמות מקומיים
הנמצאים באותה תת מחלקה של מרחב השמות כמו המכונה המייצרת את הבקשה. התחקות
אחר המסלול בהיררכיה הכוללת היא מאוד לא יעילה במקרה הזה. 2. אם כל פענוח של שם היה מתחיל בהתקשרות עם השרת שנמצא בשורש עץ שרתי השמות, השרת הזה היה עמוס מדי. 3. נפילה של שרת בהיררכיה הגבוהה ביותר של עץ שרתי השמות הייתה מונעת פענוח גם של שמות שהסמכות המקומית יכולה לפענח. | |||||||||||||||||||||||||||||||
| מכיוון שרוב בקשות הפענוח מתייחסות לשמות מקומיים, הפענוח מתחיל בשרת שמות מקומי. רק אם השרת הזה לא מסוגל לפענח את השם, הבקשה נשלחת לשרת אחר במערכת שמות ה domain. | |||||||||||||||||||||||||||||||
|
עלות החיפוש לשמות שאינם מקומיים היא גבוהה מאד. לכן, כדי לשפר את
תפקוד מערכת שמות
| |||||||||||||||||||||||||||||||
| שרתי השמות באינטרנט שומרים בזכרון שלהם, בנוסף לשמות שהם אחראים עליהם, גם מאגר מידע לגבי שמות שאינם בתחום סמכותם, ושבקשה לפענוח שלהם התקבלה אצלם באחרונה. ליד כל בקשה כזו, השרת שומר רישום של השרת בו לבסוף נמצא המידע המבוקש. כאשר לקוח מבקש מהשרת לפענח עבורו שם, השרת בודק קודם כל אם השם הנדון נמצא תחת סמכותו. אם לא, הוא בודק במאגר המידע הזה ורואה אם השם פוענח באחרונה. אם הוא מוצא שהשם פוענח באחרונה, הוא מחזיר ללקוח את הפענוח ואת שם שרת ה domain שבסמכותו נמצא השם הזה. המידע המועבר על ידי השרת מסומן כמידע "בלתי מוסמך". משמעות הסימון הזה היא שהמידע איננו בהכרח מדויק: אם יש חשיבות גבוהה לדיוק, הפענוח יבוצע מחדש, כדי לבדוק שהוא תקף. אחרת- אם הדגש המושם הוא על יעילות, המחשב ישתמש במידע הלא בהכרח מדויק שהועבר לידיו. | |||||||||||||||||||||||||||||||
| שיטת עבודה זו היא יעילה במערכת שמות ה domain, משום שהקישור בין שמות וכתובות לא משתנה בצורה תכופה. למרות זאת, קורה שהקישור הזה משתנה. לכן, המידע שבמבנה הנתונים אינו נשאר שם לעד: מדי זמן מסוים הוא נמחקף וכך מובטחת עדכניותו. | |||||||||||||||||||||||||||||||
| לפעמים, במערכות שבהם מושם דגש על מהירות תגובה, מחשב הקצה בוחר להוריד את בסיס הנתונים של השרת המקומי כדי להשתמש במידע שלו, בלי צורך לפנות אליו בכלל. במקרה כזה פונים אל השרת המקומי רק כאשר לא מוצאים את השם במחשב המקומי. מעבר ליתרון הברור במהירות, השיטה הזו גם יוצרת עמידות משום שהתלות בשרת קטנה (נפילה של השרת לא מונעת ממחשבי הקצה להמשיך לעבוד בצורה תקינה). | |||||||||||||||||||||||||||||||
| לפני שמוסד מקבל סמכות על Sub domain מהרמה השנייה, הוא חייב להסכים לספק ולתפעל שרת שמות שעומד בתנאים של האינטרנט. השרת הזה חייב לציית לפרוטוקול המגדיר סטנדרטים לבקשות וחוקים למתן תשובות. בנוסף, עליו לדעת את כתובות השרתים שמטפלים בכל Subdomain (אם קיימים כאלה), כמו גם את הכתובת של לפחות שרת אחד שמהווה שורש בעץ שרתי השמות. | |||||||||||||||||||||||||||||||
| בפועל, מערכת השמות היא הרבה יותר מורכבת ממה שתואר כאן. ברב המקרים, שרת פיסי אחד יכול לטפל ביותר מחלק אחד של היררכית השמות. בנוסף, הוא מסוגל לטפל ביותר מבקשה אחת בו זמנית. מימוש השרת גם הוא מסובך, משום שמערכת השמות דורשת שהמידע הנמצא בו ימצא ביותר ממקום אחד, כך שכל מידע הנמצא בשרת אחד חייב להימצא לפחות במחשב פיסי נוסף אחד. | |||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
|
