עודכן לפני חודש
בכל פעם שאתה מקליד שם דומיין, אתה שואל שאלה. לא רק "מה כתובת ה-IP?" אלא גם "מי רשאי לענות?"
השאלה השנייה היא המעניינת. כל אחד יכול לטעון שהוא יודע היכן google.com נמצאת. מערכת ה-DNS קיימת כדי להבטיח שתקבל תשובות רק משרתים שיש להם סמכות לתת אותן.
היררכיית הסמכות
DNS בנוי על שרשרת אמון. בראש עומדים שרתי השורש — 13 כתובות שמכירות את כל הדומיינים ברמה העליונה (.com, .org, .app). מתחתיהם, שרתי TLD מכירים את כל הדומיינים הרשומים תחת הסיומת שלהם. בתחתית, שרתים סמכותיים מכירים את כתובות ה-IP בפועל עבור דומיינים ספציפיים.
כשאתה מבקש connected.app, המחשב שלך לא פונה לכולם. הוא פונה ל-resolver רקורסיבי — שרת (שמופעל בדרך כלל על ידי ספק האינטרנט שלך או ספק ציבורי כמו Cloudflare) שעושה את עבודת החקירה בשמך.
ה-resolver מתחיל מלמעלה. הוא שואל שרת שורש: "איפה connected.app?"
שרת השורש לא יודע. הוא רק יודע למי לשאול הלאה. "אני לא מטפל בדומיינים של .app, אבל הנה מי כן."
ה-resolver שואל את שרת ה-.app: "איפה connected.app?"
שרת ה-.app גם לא יודע. "אני לא מטפל בדומיין הספציפי הזה, אבל הנה השרת הסמכותי של connected.app."
לבסוף, ה-resolver פונה לאותו שרת סמכותי, שמספק את התשובה הסופית: כתובת ה-IP שבה connected.app נמצאת בפועל.
כל זה לוקח מילישניות. שרתי השורש לא יודעים היכן google.com נמצאת — הם רק יודעים למי לשאול הלאה. זו לא מגבלה; זו כל הנקודה. אף שרת בודד לא צריך לדעת הכל. כל רמה צריכה לדעת רק מספיק כדי להכווין אותך לכיוון הנכון.
שלושה שרתים, שלושה תפקידים
Recursive resolvers עובדים בשבילך. הם לוקחים את השאלה שלך, עוקבים אחריה דרך ההיררכיה, שומרים את התשובה במטמון, ומחזירים אותה. כשאתה משתמש ב-8.8.8.8 (Google) או ב-1.1.1.1 (Cloudflare), אתה בוחר איזה resolver יעשה את העבודה הזו בשמך.
שרתים סמכותיים הם מקור האמת. אם אתה הבעלים של example.com, השרת הסמכותי שלך הוא היחיד שמורשה לומר לאן example.com מצביע. שרתים אלה לא שואלים שאלות — הם רק עונים עליהן.
שרתי העברה הם מתווכים. הנתב הביתי שלך כנראה פועל כאחד כזה, לוקח בקשות DNS מהמכשירים שלך ומעביר אותן ל-resolver של ספק האינטרנט שלך. הם שומרים תוצאות במטמון כדי להאיץ דברים, אבל הם לא מבצעים בעצמם את החיפוש ההיררכי.
מי מפעיל את התשתית הזו?
ספק האינטרנט שלך מפעיל recursive resolvers כחלק מהשירות הבסיסי. כשאתה מתחבר דרך Comcast או Verizon, הנתב שלך מוגדר אוטומטית להשתמש בשרתי ה-DNS שלהם. ספקים ציבוריים כמו Cloudflare, Google ו-Quad9 מציעים חלופות — לרוב מהירות יותר, לעיתים פרטיות יותר.
בעלי דומיינים מפעילים שרתים סמכותיים (או משלמים לספקים כמו Cloudflare או AWS להפעיל אותם). כשהחברה Connected מפעילה את connected.app, אנחנו אחראים על השרתים שעונים על שאילתות לגבי הדומיין שלנו.
שרתי השורש הם המקרה המעניין. 13 כתובות משרתות את האינטרנט כולו — אבל ה-13 כתובות האלה מייצגות למעשה כמעט 2,000 שרתים פיזיים המפוזרים ברחבי העולם. כשאתה שולח שאילתה לשרת שורש, ניתוב anycast שולח את הבקשה שלך לשרת הקרוב ביותר גיאוגרפית. אתה לעולם לא יודע איזו מכונה פיזית ענתה לך.
תשתית זו מופעלת על ידי 12 ארגונים עצמאיים: Verisign (שמפעילה שני שרתי שורש), NASA, הצבא האמריקאי, אוניברסיטאות, ISC ואחרים. הם מתאמים דרך ICANN, אבל כל אחד מפעיל את השרתים שלו באופן עצמאי. אף ארגון בודד אינו שולט בשורש.
מתוכנן לשרוד כשלים
DNS מצפה שדברים יישברו. הפרוטוקול דורש לפחות שני שרתי שמות סמכותיים לכל דומיין. מערכת השורש משתמשת בכמעט 2,000 שרתים מאחורי 13 כתובות. Recursive resolvers שומרים הכל במטמון, כך שהם יכולים להמשיך לענות על שאילתות גם אם שרתים סמכותיים יורדים זמנית.
שרתי DNS בודדים נכשלים כל הזמן — תחזוקה, מתקפות, הפסקות — אבל האינטרנט ממשיך לעבוד. אין נקודת כשל יחידה כי התכנון מלכתחילה הניח שדברים יכשלו.
לכן DNS נראה בלתי נראה. לא כי דברים לא משתבשים, אלא כי המערכת מוצאת מסלול עוקף לכל מה שכן משתבש.
שאלות נפוצות על שרתי DNS
איזה שרת DNS אני משתמש בו עכשיו?
המכשיר שלך כנראה משתמש בשרת ה-DNS שהנתב שלך הקצה אוטומטית — בדרך כלל ה-resolver של ספק האינטרנט שלך. ברוב המערכות, תוכל לבדוק את הגדרות הרשת כדי לראות את כתובת שרת ה-DNS המוגדרת. כלים כמו nslookup או בדיקות DNS leak מקוונות מראות איזה resolver עונה בפועל על השאילתות שלך.
האם כדאי לעבור לספק DNS ציבורי כמו 1.1.1.1 או 8.8.8.8?
תלוי מה חשוב לך. ספקי DNS ציבוריים מציעים לעיתים קרובות זמני תגובה מהירים יותר מ-resolvers של ספקי אינטרנט, וחלקם (כמו 1.1.1.1 של Cloudflare) מדגישים פרטיות על ידי אי-רישום שאילתות. אחרים (כמו Quad9) חוסמים דומיינים זדוניים ידועים. הפשרה: ספק האינטרנט שלך כבר לא יכול לראות את שאילתות ה-DNS שלך, אבל הספק שבחרת יכול.
מה קורה אם שרת DNS יורד?
אם שרת ה-DNS המוגדר שלך נכשל, המכשיר שלך לא יכול לפתור שמות דומיין — אתרי אינטרנט נראים לא זמינים למרות שהם בסדר גמור. זו הסיבה שתשתית ה-DNS מיותרת מאוד, וזו הסיבה שהגדרת שרת DNS גיבוי מונעת נקודת כשל יחידה אצלך.
מדוע שינויי DNS לוקחים זמן להתפשט?
כשאתה מעדכן רשומת DNS, התשובה הישנה עדיין שמורה במטמון של resolvers ברחבי העולם. לכל רשומה שמורה במטמון יש TTL (Time To Live) שמציין כמה זמן resolvers צריכים לסמוך עליה לפני שבודקים שוב. עד שה-TTL האלה יפוגו, חלק מהמשתמשים רואים את הכתובת הישנה בעוד אחרים רואים את החדשה. "ההתפשטות" הזו נמשכת בדרך כלל דקות עד 48 שעות בהתאם לערכי ה-TTL.
מקורות
האם דף זה היה מועיל?