כך פועל פתרון ה-DNS — שלב אחר שלב

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

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

מטמון הדפדפן: בדיקת הזיכרון תחילה

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

אם ביקרת ב-example.com לאחרונה וה-TTL טרם פג, הדפדפן שלך כבר יודע את התשובה. הוא מדלג על כל תהליך הפתרון ומתחיל להתחבר מיד.

אך אם המטמון ריק או פג-תוקף, הדפדפן שואל את מערכת ההפעלה.

מטמון מערכת ההפעלה

מערכת ההפעלה שלך מנהלת מטמון DNS משלה, נפרד מכל דפדפן. כאשר ל-Chrome אין תשובה, ייתכן ש-Firefox פתר את אותו דומיין זה עתה — ואותה תשובה שוכנת במטמון של מערכת ההפעלה.

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

הפותר הרקורסיבי: הנציג שלך

המחשב שלך לא שואל את מערכת ה-DNS העולמית ישירות. הוא שולח את שאלתו לפותר DNS רקורסיבי — המופעל בדרך כלל על ידי ספק האינטרנט שלך או שירות כמו Cloudflare ‏(1.1.1.1) או Google ‏(8.8.8.8).

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

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

אך כאשר המטמון ריק, הפותר מתחיל בראש ההיררכיה.

שרתי שמות שורש: נקודת ההתחלה

13 מערכות שרתי שמות שורש יושבות בראש ה-DNS. הן לא יודעות היכן נמצא example.com. הן יודעות משהו בסיסי יותר: מי אחראי לכל דומיין ברמה העליונה.

הפותר הרקורסיבי שואל שרת שורש: "היכן אוכל למצוא את example.com?"

שרת השורש משיב בהפניה: "אינני יודע את example.com, אך הנה שרתי השמות שמטפלים בכל מה שתחת .com."

זוהי שאילתה איטרטיבית. שרת השורש לא מוצא את התשובה — הוא מצביע על מי שאולי יודע.

שרתי שמות TLD: צמצום הטווח

הפותר הרקורסיבי פונה כעת לשרת שמות TLD של .com עם אותה שאלה.

שרת ה-TLD גם הוא לא יודע את כתובת ה-IP של example.com. אך הוא יודע אילו שרתי שמות הם הסמכותיים לדומיין הספציפי הזה. הוא משיב: "הנה שרתי השמות שמטפלים ב-example.com."

שתי שאילתות, וצמצמנו מ"איפשהו באינטרנט" ל"שרתי השמות הספציפיים האלה יודעים."

שרתי שמות סמכותיים: הסמכות הסופית

הפותר הרקורסיבי פונה לשרת שמות סמכותי עבור example.com. שרת זה מחזיק את רשומות ה-DNS בפועל של הדומיין.

הפותר שואל: "מהי כתובת ה-IP של example.com?"

שרת השמות הסמכותי משיב: "רשומת ה-A עבור example.com היא 93.184.216.34, תקפה ל-3600 שניות."

מסע החזרה

הפותר הרקורסיבי מחזיר את כתובת ה-IP למערכת ההפעלה שלך, שמחזירה אותה לדפדפן שלך. בכל שלב, התשובה נשמרת במטמון לפי ה-TTL.

המשתמש הבא שישאל את הפותר על example.com יקבל תשובה מיידית. אם תבקר שוב תוך שעה, מערכת ההפעלה שלך תענה ללא שאילתת רשת כלשהי. הדפדפן שלך סוף סוף קיבל מה שהיה לו צורך בו: כתובת IP. הוא מתחיל ליצור חיבור TCP לכתובת 93.184.216.34.

רקורסיבי לעומת איטרטיבי: שני סוגי שאילתות

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

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

חלוקת העבודה הזו היא העיצוב. אתה שולח שאילתה אחת. אתה מקבל תשובה אחת. הפותר מטפל במורכבות כדי שאתה לא תצטרך.

מדוע המטמון הופך DNS לאפשרי

פתרון ללא מטמון — כשאין כלום שמור בשום מקום — דורש ארבעה סיבובי תקשורת ברשת: לפותר, לשרת השורש, לשרת ה-TLD ולשרת הסמכותי. זה 80 עד 200 מילישניות.

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

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

ערכי TTL שולטים בפשרה הזו. TTL של 60 שניות פירושו שאילתות תכופות לשרתים הסמכותיים. TTL של 24 שעות פירושו שרוב השאילתות נענות מהמטמון — אך שינויי DNS ייקחו יום שלם להתפשט.

מה זה אומר

כל חיבור מתחיל ב-DNS. לפני שהדפדפן יוכל לאחזר דף, להוריד תמונה, או לפתוח חיבור WebSocket, הוא זקוק לכתובת IP.

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

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

שאלות נפוצות על פתרון DNS

מדוע שינויי DNS לוקחים זמן להתפשט?

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

מה קורה אם שרת DNS לא מגיב?

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

האם אוכל לראות את תהליך פתרון ה-DNS בעצמי?

כן. הפקודה dig עם הדגל +trace מציגה כל שלב: dig +trace example.com. תראה את השאילתה לשרתי השורש, את ההפניה לשרתי ה-TLD, את ההפניה לשרתים הסמכותיים ואת התשובה הסופית. זהו המסע המלא, גלוי לעין.

מדוע חלק מהאתרים מתפתרים מהר יותר מאחרים?

אתרים פופולריים נהנים מהמטמון בכל רמה. הפותר הרקורסיבי שלך כנראה ענה על "היכן נמצא google.com?" אלפי פעמים היום — הוא מחזיר תשובה מיידית מהמטמון. דומיין שאף אחד לא שאל עליו דורש את שרשרת הפתרון המלאה, ומוסיף 100 מילישניות ומעלה.

מקורות