GOOGLE DNS? - עמוד 6 - רשתות ואינטרנט - HWzone פורומים
עבור לתוכן
  • צור חשבון

GOOGLE DNS?

shlomo1441

נוצר על ידי shlomo1441
ב רשתות ואינטרנט

Recommended Posts

  • תגובות 107
  • נוצר
  • תגובה אחרונה
איסתרא בלגינא Zone Junkie

איסתרא בלגינא

פורסם
פורסם

מאחר שהן מילפורד והן צ'יף מסרבים לבצע בדיקה פשוטה, להלן הסבר אודות דרך העבודה של ה- DNS ומדוע ה- DNS של לא יכול להתעדכן מהר יותר מזה של הספק שלכם:

כתובת דומיין בנויה בצורה היררכית, כשהרמות מופרדות זו מזו ע"י נקודות. קחו למשל את הדומיין www.hwzone.co.il: הרמה הגבוהה ביותר היא ה- root, שמסומנת כנקודה ונמצאת בצד הימני ביותר של הדומיין. אל תחפשו אותה שם, לא רושמים אותה. הרמה הבאה היא ה- Top Level Domain, או בקיצור TLD, שבדוגמה הנ"ל הוא il (אגב, TLD-ים בני שתי אותיות שמוקצים למדינות ספציפיות נקראים country code TLD או בקיצור ccTLD). הרמה השלישית בדוגמה היא co, הרביעית היא hwzone והאחרונה בדוגמה היא www. אם ממספרים את הרמות, בד"כ לא מספרים את ה- root (או ממספרים כאפס) ולכן תראו לפעמים התיחסות לרמה שמתחת ל- TLD כאל second-level domain.

כל דומיין מוגדר על שרת DNS אחד שאחראי עליו. השרת הזה מכיר כל רשומה בדומיין הזה וכל עידכון בדומיין מתבצע עליו. מאחר שזה השרת שאחראי על הדומיין, הוא נקרא primary server עבור ה- domain הזה והתשובות שמקבלים ממנו הן authoritative - רשמיות. רשומה שלא קיימת עליו, לא קיימת בדומיין. בנוסף ישנו עוד סוג של שרת שנחשב authoritative הוא ה- secondary server: שרת (או יותר מאחד) שמקבל עותק שלם של כל ההגדרות בדומיין מהשרת הראשי.

איך מתנהל התהליך של המרת דומיין לכתובת IP? אתם כותבים בדפדפן www.hwzone.co.il. הדפדפן פונה למערכת ההפעלה וזו מפנה שאילתה לשרת ה- DNS שהוגדר לה ומבקשת לדעת מהי כתובת ה- IP שמשוייכת לדומיין הזה. אם שרת ה- DNS הזה הוא authoritative עבור הדומיין hwzone.co.il אז אין בעיה: הוא מכיר את כל הרשומות בדומיין, יודע מי זה www ומחזיר את כתובת ה- IP שלו.

אם השרת הוא לא ה- authoritative עבור הדומיין, הוא צריך ללכת לחפש את הכתובת. ישנו סט אחד של רשומות שיש לכל שרת DNS באינטרנט: כתובות שרתי ה- root. ישנם לפחות 12 שרתים ברמת ה- root ואולי יותר, כדי שגם אם כמה מהם מפסיקים לעבוד או אינם נגישים, מערכת ה- DNS לא תישבר. השרתים האלו הם ה- authoritative עבור רמת ה- root, כלומר מכירים כל רשומה שנמצאת ברמה הזו: הם יודעים מה זה com, הם יודעים מה זה net, הם יודעים מה זה us, הם יודעים מה זה de וכו'. אז שרת ה- DNS שלכם פונה לאחד משרתי ה- root ושואל אותו מהי כתובת ה- IP של www.hwzone.co.il. שרת ה- root לא יודע, זו לא רמה שהוא אחראי עליה, אבל הוא כן יכול להפנות אתכם למישהו שקרוב יותר לדומיין ממנו: הוא יודע מיהם שרתי ה- DNS שאחראים ל- il, שהוא דומיים שנמצא ברמת ה- root.

השרת שלכם מקבל את כתובות השרתים שאחראים על הדומיין il ושואל אחד מהם מהי הכתובת של www.hwzone.co.il. גם השרת הזה לא יודע, אבל הוא יכול לקחת אתכם עוד צעד אחד קדימה: הוא יודע מה כתובות השרתים שאחראים על co.il. השרת שלכם פונה לאחד מאלו שאחראים על co.il ושואל מה הכתובת, גם הפעם הןא לא מקבל את התשובה שרצה אבל הולך עוד צעד קדימה ומקבל את הכתובת של השרת שהוא authoritative על הדומיין hwzone.co.il. השאילתה הבאה מגיעה לשרת שאחראי על hwzone.co.il, השרת הזה הוא ה- authoritative בדומייןם המבוקש ולכן יודע מה הכתובת של www.hwzone.co.il ויכול להחזיר לשרת שלכם את התשובה. כשהשרת שלכם מקבל את השתובה, הוא יכול להעביר אותה למערכת הההפעלה שלכם וכך אתם יכולים להגיע לאתר.

אבל במהלך העלאת דף בודד באתר נפתחים בד"כ כמה קישורים: אחד לדף ה- HTML, אחד לכל תמונה באתר, עוד אחד או יותר לקובץ (או קבצי) ה- CSS ולסקריפטים ולפריימים ושאר מריעין בישין. לא הגיוני לעבור כל פעם את כל התהליך הזה רק כדי לקבל בדיוק את אותה תשובה, שהרי האתר לא מחליף כתובת IP כמה פעמים בשניה; לא חבל על העומס שיוטל על שרתי ה- DNS? לכן הוסיפו מנגנון נוסף: ה- cache.

כששרת DNS שולח תשובה, הוא מצרף אליה גם "תאריך תפוגה" ה- TTL, הזמן בשניות מרגע קבלת התשובה בו היא תהיה תקפה. הערך שבד"כ מגדירים הוא 24 שעות. מרגע קבלת התשובה ועד שה- TTL עובר, השרת שקיבל את התשובה מחזיק אותה במטמון שלו ואם יתבקש לענות שוב על אותה שאלה, הוא יחזיר את התשובה מהמטמון הזה בלי ללכת את כל הדרך מה- root ועד לשרת ה- DNS הספציפי. זה חוסך מהעומס על השרתים השונים בדרך ומקטין את הזמן שלוקח לשרת לספק לכם את התשובה (כיוון שהוא לא צריך להמתין לכל השרתים האחרים). כששרת מחזיר תשובה מה- cache שלו, הוא מסמן אותה כ- non authoritative, כדי שמי שיקבלאותה ידע שהיא לא הגיעה מהשרת הרשמי אלא מ- cache, שיתכן שאינו מעודכן. אחרי שהזמן שמוגדר ב- TTL עבר, הרשומה נמחקת מה- cache ובפעם הבאה שישאלו את השרת מהי כתובותו של הדומיין הזה, הוא שוב יחפש וישאל את השרת הראשי לדומיין כדי לקבל עותק טרי של התשובה.

למה שה- cache לא יהיה מעודכן? כי לפעמים כתובות IP משתנות. יכול להיות ש- www.hwzone.co.il היה במשך כמה שנים בכתובת ה- IP 9.9.9.9 ועכשיו העבירו אותו לכתובת 11.11.11.11. קורה. ה- primary תמיד מעודכן, הרי את השינוי עושים עליו, וה- secondary מתעדכן לכל היותר כמה שעות אחריו. ומה עם השרת שלכם? אם אין ב- cache שלו עותק של הרשומה הזו, כי אף אחד מעולם לא שאל אותו או כי שאלו אותו אבל תוקפה של התשובה כבר פג והיא נמחקה מה- cache, אין שום בעיה: כשתשאלו, השרת ילך ל- DNS שאחראי על hwzone.co.il (בתהליך שמתואר לעיל) ויקבל את הכתובת החדשה כפי שעודכנה בשרת הראשי לא מזמן - 11.11.11.11.

אבל מה אם אתם או מישהו אחר שמשתמש באותו שרת DNS כמוכם נכנס לאתר לפני שעה? לפני שעה שרת ה- DNS שלכם קיבל משרת ה- DNS של hwzone.co.il שהכתובת של www.hwzone.co.il היא 9.9.9.9 ושעליו להחזיק את התשובה הזו ב- cache שלו למשך, נאמר, 24 שעות. בינתיים חלפה שעה כך שלאותה שתובה יש משך חיים של עוד 23 שעות. באותן 23 שעות, כל מי שישאל את שרת ה- DNS שלכם מהי כתובת ה- IP של www.hwzone.co.il יקבל את התשובה 9.9.9.9 למרות שהשרת כבר לא יושב בכתובת הזו. רק בעוד 23 שעות מעכשיו, כשהרשומה הזו תמחק מה- cache, ה- DNS שלכם יוכל להתעדכן בכתובת החדשה של האתר. אין שום דרך להאיץ את זה: השרת שלכם לא יכול לדעת מתי הרשומה התעדכנה בשרת שאחראי על הדומיין בלי ללכת לשאול אותו מחדש ואם הוא ילך לשאול אותו בכל פעם, אין שום טעם להחזיק cache.

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

ניקח דומיין לדוגמה: howdnsworks.com (ניסיתי כמה אפשרויות עד שמצאתי אחת ששרתי ה- DNS שניסיתי לא הכירו). אחד מהשרתים שאחראים עליו, או ה- primary או ה- secondary, לא יודע, הוא learn16.learntcpip.com. זה מה שמקבלים כששואלים אותו ישירות מהי כתובת ה- IP של www.howdnsworks.com:

> [url=http://www.howdnsworks.com]www.howdnsworks.com[/url].
Server: learn16.learntcpip.com
Address: 173.160.150.73

------------
Got answer:
  HEADER:
    opcode = QUERY, id = 30, rcode = NOERROR
    header flags: response, auth. answer, want recursion, recursion avail.
    questions = 1, answers = 1, authority records = 0, additional = 0

  QUESTIONS:
    [url=http://www.howdnsworks.com]www.howdnsworks.com[/url], type = A, class = IN
  ANSWERS:
  -> [url=http://www.howdnsworks.com]www.howdnsworks.com[/url]
     address = 173.160.150.73
    ttl = 3600 (1 hour)

------------
Name:  [url=http://www.howdnsworks.com]www.howdnsworks.com[/url]
Address: 173.160.150.73

ראשית, קיבלנו את התשובה: 173.160.150.73. אבל קיבלנו עוד כמה פרטים: השרת הזה הוא authoritative לשומיין (תכף תראו איך יודעים) ואנחנו צריכים להחזיק את התשובה הזו ב- cache שלנו למשך שעה. מאחר שזה השרת הראשי הוא תמיד יחזיר את אותו ערך של TTL. אתם מוזמנים לבדוק: מתי שלא תשלו, תקבלו שעה.

עכשיו נלך לגוגל:

> [url=http://www.howdnsworks.com]www.howdnsworks.com[/url].
Server: -public-dns-a.google.com
Address: 8.8.8.8

------------
Got answer:
  HEADER:
    opcode = QUERY, id = 32, rcode = NOERROR
    header flags: response, want recursion, recursion avail.
    questions = 1, answers = 1, authority records = 0, additional = 0

  QUESTIONS:
    [url=http://www.howdnsworks.com]www.howdnsworks.com[/url], type = A, class = IN
  ANSWERS:
  -> [url=http://www.howdnsworks.com]www.howdnsworks.com[/url]
     address = 173.160.150.73
    ttl = 3600 (1 hour)

------------
Non-authoritative answer:
Name:  [url=http://www.howdnsworks.com]www.howdnsworks.com[/url]
Address: 173.160.150.73

אותה תשובה, כצפוי. כאן אפשר לראות שהתשובה הגיעה משרת שאינו ה- authoritative - זה כתוב המפורש מעל לתשובה. וכך אפשר לדעת שהשרת הראשון כן היה authoritative, כיוון שהוא לא אמר שהוא לא :) . וגם כאן ה- TTL שקיבלנו הוא שעה אחת - זה מה שגוגל קיבלו מהשרת הראשון וזה מה שהם מעבירים אלינו. הדומיין הזה לא היה ב- cache שלהם קודם.

כמה שניות מאוחר יותר:

> [url=http://www.howdnsworks.com]www.howdnsworks.com[/url].
Server: -public-dns-a.google.com
Address: 8.8.8.8

------------
Got answer:
  HEADER:
    opcode = QUERY, id = 33, rcode = NOERROR
    header flags: response, want recursion, recursion avail.
    questions = 1, answers = 1, authority records = 0, additional = 0

  QUESTIONS:
    [url=http://www.howdnsworks.com]www.howdnsworks.com[/url], type = A, class = IN
  ANSWERS:
  -> [url=http://www.howdnsworks.com]www.howdnsworks.com[/url]
     address = 173.160.150.73
    ttl = 3554 (59 mins 14 secs)

------------
Non-authoritative answer:
Name:  [url=http://www.howdnsworks.com]www.howdnsworks.com[/url]
Address: 173.160.150.73

אותה שאלה, אותה תשובה, רק שבינתיים עברו 46 שניות מהזמן שבו התשובה נכנסה ל- cache של ולכן משך החיים שנשאר לאותה תשובה ב- cache הוא 59 דקות ו- 14 שניות.

ונעבור לבזב"ל. פעם ראשונה:

> [url=http://www.howdnsworks.com]www.howdnsworks.com[/url].
Server: dnsdrp.bezeqint.net
Address: 62.219.186.7

------------
Got answer:
  HEADER:
    opcode = QUERY, id = 39, rcode = NOERROR
    header flags: response, want recursion, recursion avail.
    questions = 1, answers = 1, authority records = 0, additional = 0

  QUESTIONS:
    [url=http://www.howdnsworks.com]www.howdnsworks.com[/url], type = A, class = IN
  ANSWERS:
  -> [url=http://www.howdnsworks.com]www.howdnsworks.com[/url]
     address = 173.160.150.73
    ttl = 3600 (1 hour)

------------
Non-authoritative answer:
Name:  [url=http://www.howdnsworks.com]www.howdnsworks.com[/url]
Address: 173.160.150.73

אין הפתעות: אותה תשובה, non authoritative, שעה ב- cache. קצת מאוחר יותר:

> [url=http://www.howdnsworks.com]www.howdnsworks.com[/url].
Server: dnsdrp.bezeqint.net
Address: 62.219.186.7

------------
Got answer:
  HEADER:
    opcode = QUERY, id = 41, rcode = NOERROR
    header flags: response, want recursion, recursion avail.
    questions = 1, answers = 1, authority records = 0, additional = 0

  QUESTIONS:
    [url=http://www.howdnsworks.com]www.howdnsworks.com[/url], type = A, class = IN
  ANSWERS:
  -> [url=http://www.howdnsworks.com]www.howdnsworks.com[/url]
    internet address = 173.160.150.73
    ttl = 3481 (58 mins 1 sec)

------------
Non-authoritative answer:
Name:  [url=http://www.howdnsworks.com]www.howdnsworks.com[/url]
Address: 173.160.150.73

עכשיו נשארו לתשובה הזו ב- cache עוד 58 דקות ושניה אחת.

אם עכשיו ישנו את כתובת ה- IP של האתר בשרת ה- DNS - או אפילו יכבו את שרת ה- DNS לגמרי - שום דבר לא ישתנה כל עוד תשאלו את השרתים של או של בזב"ל: מבחינתם, התשובה היא 173.160.150.73 למשך חמישים ומשהו הדקות הבאות. הם לא ילכו לבדוק אולי משהו השתנה בשרת הראשי כי הוא אמר להם לא לשאול. אחרי אותן חמישים ומשהו דקות, הם שוב ילכו לשאול את השרת הראשי ואז יתעדכנו שהיה שינוי (או שאי אפשר לקבל תשובה בכלל כי משהו קרה לשרת הראשי והוא לא מחזיר תשובה). אם תנסו את אותה שאילתה בינתיים בשרת אחר, נאמר של 012, תקבלו תשובה מעודכנת: התשובה הישנה לא היתה ב- cache שלהם ולכן הם הלכו לשרת הראשי והתעדכנו ממנו. זה לא בגלל ש- 012 מהירים יותר בעדכון מגוגל.

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

בהצלחה.

קישור לתוכן
שתף באתרים אחרים
איסתרא בלגינא Zone Junkie

איסתרא בלגינא

פורסם
פורסם

מדהים איך הצלחת לחפור כלכך הרבה ופשוט להתעלם בהפגנתיות מהתוצאות בשטח.

אבל נו, ככה זה טרולים.

אני אמרתי את שלי, עם הסבר מפורט, הדגמות והוראות פשוטות לשיחזור בבית שכל אחד עם ידע מינימלי יכול לעשות (שכחתי לכתוב: כדי לראות TTL ב- nslookup, תפעילו set debug לפני השאילתה). אתה אמרת את שלך. ישפטו הקוראים.

קישור לתוכן
שתף באתרים אחרים
Cheif Zone Master

Cheif

פורסם
פורסם

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

אם מישהו מתלהב מאריכות הפוסטים של איסתרא ולא מהדיוק הטכני שלהם - שיבושם לו.

קישור לתוכן
שתף באתרים אחרים
איסתרא בלגינא Zone Junkie

איסתרא בלגינא

פורסם
פורסם

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

היררכי - נכון. למעשה, כך בדיוק התחלתי את ההסבר שלי!

אין שום הבדל בין המרחק בהיררכיה של גוגל או של ספק ישראלי. אם אתה לא authoritative ואין לך נתונים ב- cache, אתה תמיד מתחיל מה- root ולא משנה אם אתה חברת ענק עם מחזור שגדול יותר מהתל"ג של ישראל או ששיעמם לך אז התקנת שרת DNS בבית. אין שום דרך אחרת בה ניתן לעבוד במערכת היררכית בה כל ענף בעץ שאינו השורש יכול להשתנות בלי כל התראה מוקדמת.

ואם כבר יש נותנים ב- cache? שוב, נאמר שאתה מחפש את www.hwzone.co.il. נאמר ששרת A לא יודע כלום כרגע ולכן הולך בנתיב root->il->co.il->hwzone.co.il->www.hwzone.co.il ולעומתו שרת B כבר מחזיק את כתובות שרתי ה- DNS של co.il ב- cache ולכן יכול לקצר את הנתיב ל- co.il->hwzone.co.il->www.hwzone.co.il. נאמר ששניהם מקבלים את התשובה באותה שניה ושה- TTL שכל שרת מחזיר לכל רשומה הוא 24 שעות. נאמר ששרת B מחזיק ב- cache שלו את הכתובות של co.il כבר 12 שעות ולכן נשאר להם משך חיים של עוד 12 שעות, בזמן ששרת A שרק הרגע התעדכן בכתובות של co.il יחזיק אותן ב- cache למשך 24 שעות. עכשיו נאמר שמשנים את כתובת ה- IP של www.hwzone.co.il, מי משני השרתים יקבל את העדכון מהר יותר?

התשובה היא שאין שום הבדל בכלל. אמנם שרת B ניגש ישר לאמצע הדרך, אבל סופה של הדרך נשאר זהה: בסוף שניהם תשאלו את שרת ה- DNS של hwzone.co.il וזה החזיר לשניהם את אותה התשובה עם אותו TTL של 24 שעות. רק בעוד 24 שעות שניהם יגשו אליו שוב ויוכלו להתעדכן בשינוי הכתובת.

אבל מה אם נעשה שינוי בכתובות שרתי ה- DNS של co.il? במקרה הזה, שרת A יתעדכן בשינוי רק בעוד 24 שעות בעוד ששרת B יתעדכן בעוד 12 שעות. הנה, יש יתרון! לא בהכרח. הרי שרתי ה- DNS שלנו לא יכולים לדעת מתי יחליטו לעשות שינוי בכתובות של co.il ולתזמן את השאילתות שלהם בהתאם, זה עניין של מזל; כפי שיתכן ששרת A ישלח שאילתה לשרת שאחראי על co.il כמה שניות לפני העדכון ויתקע למשך 24 שעות עם תשובה לא מעודכנת (או 12 שעות יותר משרת B), יתכן גם ששרת A ישלח את השאילתה כמה שניות אחרי העדכון של co.il ולכן יקבל אותו מיד (או 12 שעות פחות משרת B). הסבירות של שתי האפשרויות שווה.

אפשר להאיץ את העדכונים של שרת ה- DNS. אפשר למשל לדאוג שאת ערך ה- TTL שנקבל נחלק לחצי לפני שנכניס אותו ל- cache. אבל זה לא רעיון חכם: הערך נקבע כפי שהוא ע"י מי שמנהל את הדומיין, הוא זה שיודע מה הסבירות שה- IP ישתנה ובאיזה עומס שרת ה- DNS שלו יכול לעמוד ובהתאם לכך קובע את משך ה- TTL; לקבוע ערך משלנו, נמוך יותר, יגרום להגדלת העומס על השרת שלנו שיקבל הרבה יותר שאילתות לגבי אותו דומיין, להגדלת העומס על השרת המרוחק, שיצטרך לענות לשרת שלנו על הרבה יותר שאילתות, ולזמני תגובה גבוהים יותר כיוון שהשרת המקומי יצטרך לתת יותר תשובות מהשרת המרוחק ולא מה- cache המקומי שלו. ובכל מקרה כבר הראיתי שגוגל לא עושים את זה: ה- DNS שלהם מחזיר בדיוק את אותו ערך ה- TTL כמו שרת של ספק מקומי (בזב"ל) ולא התעדכן בשינוי גם אחרי 3/4 מהזמן הזה.

צ'יף, הדומיין שלך בשליטתך, לא? אז תבצע את הבדיקה שהצעתי ותראה: צור רשומה חדשה בדומיין ותפנה אותה לכתובת כלשהי. תפנה שאילתות עבור הרשומה החדשה לשרת ה- DNS של ושל הספק המקומי שלך (מומלץ כמה למקרה שה- load balancer לא מפנה אותך תמיד לאותו שרת) ואח"כ תשנה את הרשומה כך שתפנה לכתובת IP אחרת. המתן את רוב ה- TTL ושלח שוב כמה שאילתות לשני השרתים. האם אחד מהם כבר התעדכן או ששניהם עדיין מראים את הכתובת המקורית, לפני השינוי?

זו בדיקה פשוטה, למה אתה לא מוכן לנסות אותה?

קישור לתוכן
שתף באתרים אחרים

ארכיון

דיון זה הועבר לארכיון ולא ניתן להוסיף בו תגובות חדשות.

עבור לרשימת הדיונים
×
  • צור חדש...