GOOGLE DNS?

[Charybdis]

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

אני מבקש. אל תהפכו את הדיון הזה לשטות, יש לו פוטנציאל. חבל.

זו אזהרה אחרונה לפני נעילה.

[Cheif]

עמרי - תזהר - עוד תקבל BAN...

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

בואו נתאר את התסריט הבא עם TTL של 24 שעות.

שעה 0:00 - שרת ה-DNS של ספקית באנגליה מתעדכן בכתובת של www.xxx.co.uk

שעה 23:59 - שרת ה-DNS של co.uk מתעדכן בכתובת של www.xxx.co.uk

שעה 24:00 - כתובת האתר www.xxx.co.uk משתנה. לצורך הדוגמא, www.xxx.co.uk רשום אצל ספק אמריקאי כמו godaddy.

בשעה 23:58 - מה תהיה כתובת ה-DNS של www.xxx.co.uk אצל הספקית האנגלית?

בשעה 24:01 - אותה שאלה?

בשעה 47:58 - אותה שאלה?

באיזה שעה לכל המוקדם ידע ה-DNS של הספקית האנגלית על הכתובת החדשה?

לצורך המענה, שימו לב ששאילתת ה-DNS לאתר www.xxx.co.uk עוברת דרך שתי היררכיות בעץ שמסתנכרנות באופן שונה.

ונקודה למחשבה של כולם - לכל אחד מכם יש שרת DNS קטן במחשב/בנתב שלו. קחו גם את ה-TTL שלהם בחשבון...

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

אה, יש לנו כאן שתי בעיות שונות.

הבעיה הראשונה היא בהבנת הנקרא שלך. הפעם הראשונה בה דיברתי על הגדרת TTL בשרת היתה כאן:

תן לרשומה TTL של 24 שעות.

24 שעות. בהמשך אותה הודעה כתבתי:

עשיתי את זה עכשיו. כיוון שאין לי סבלנות, הסתפקתי ב- TTL של שעה.

איפה אתה רואה שכתבתי שה- TTL חייב להיות שעה? או חייב להיות 24 שעות? הרי אם ערך אחד הוא חובה, ברור שהשני אסור ולהיפך, אז איך כתבתי על שני הערכים? כתוספת, בהודעה הארוכה הראשונה כתבתי:

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

את ההדגשה הוספתי עכשיו, למי שמתקשה.

ובהמשך אותה הודעה:

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

כאן יש דוגמה מהחיים וכאן ה- TTL שהשרת מחזיר הוא שעה. הדומיין הזה יתעדכן תמיד בתוך שעה לכל היותר כי זה הערך שמי שאחראי עליו הגדיר. בד"כ מקובל להגדיר 24 שעות - אז מה? הוא החליט שהוא רוצה שעה.

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

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

לשרתי cache אין TTL משל עצמם. מה שהם מחזירים לך זה את הערך שקיבלו מהשרת שהוא authoritative לדומיין. לעזאזל, הראיתי את זה כמה פעמים! על הדומיין בדוגמה השניה למשל, howdnsworks.com, קיבלתי (וגם אתה יכול לקבל) בדיוק את אותו ה- TTL כששלחתי את השאילתה לגוגל, לבזב"ל ולשרת שהחזיק את הדומיין, כלומר ה- authoritative DNS. איך זה יתכן? פשוט, כפי שהסברתי עוד באותו מקום: ה- cache-ים של גוגל ובזב"ל מחזירים את הערך שקיבלו מה- authoritative ולכן ערך ה- TTL שהם יחזירו עבור הרשומות האלו חייב להיות זהה לזה של ה- authoritative - לפחות בפעם הראשונה, כשהרשומה נכנסת ל- cache.

לשרתי cache אין מיקום בהיררכיה - הם לא מחזיקים דומיינים כ- authoritative. גם אם החלטת משיקולי חיסכון להשתמש באותו שרת הן כ- cache server והן כ- authoritative name server, עדיין אין ל- cache מקום בהיררכיה: אף אחד לא אמר שאתה חייב להחזיק על השרת דומיין אחד. מה אם אתה מחזיק בו את buzaglo.com ואת buzaglo.co.il? הראשון דומיין ברמה השניה, השני ברמה שלישית. אז מה מיקומו של ה- cache בהיררכיה?

גם אם תחזיק שם רק דומיין אחד כך שתוכל להתעקש שיש לשרת מקום בהיררכיה, עדיין לא תוכל לשנות את קצב העדכון שלו. אז אתה מחזיק שם את ה- zone file של buzaglo.com, איך זה עוזר לך למצוא את הכתובת של Google.com?

ולדוגמה שלך:

שרת ה- DNS של co.uk לא יתעדכן בכתובת של www.xxx.co.uk כיוון שה- zone שלו, co.uk, הוא ברמה השניה והדומיין המבוקש הוא ברמה הרביעית. ה- zone שלנו מכיל אמנם את רשומות ה- NS של xxx.co.uk, אבל את www.xxx.co.uk הוא בכלל לא מכיר. לא מאמין? תראה:

> set type=any

> co.uk.

Server: Google-public-dns-a.google.com

Address: 8.8.8.8

Non-authoritative answer:

co.uk

primary name server = ns1.nic.uk

responsible mail addr = hostmaster.nominet.org.uk

serial = 1302552699

refresh = 900 (15 mins)

retry = 300 (5 mins)

expire = 2419200 (28 days)

default TTL = 10800 (3 hours)

co.uk ??? unknown type 46 ???

co.uk nameserver = nsb.nic.uk

co.uk nameserver = nsc.nic.uk

co.uk nameserver = nsd.nic.uk

co.uk nameserver = ns5.nic.uk

co.uk nameserver = ns4.nic.uk

co.uk nameserver = ns6.nic.uk

co.uk nameserver = ns7.nic.uk

co.uk nameserver = ns1.nic.uk

co.uk nameserver = nsa.nic.uk

co.uk nameserver = ns2.nic.uk

co.uk nameserver = ns3.nic.uk

co.uk ??? unknown type 46 ???

co.uk ??? unknown type 48 ???

co.uk ??? unknown type 46 ???

co.uk ??? unknown type 51 ???

co.uk ??? unknown type 46 ???

co.uk ??? unknown type 65534 ???

co.uk ??? unknown type 46 ???

אלו שרתי ה- authoritative של co.uk. נבחר אחד מהם ונבדוק מה הוא יודע על bbc.co.uk ועל www.bbc.co.uk:

> bbc.co.uk
Server: ns1.nic.uk
Addresses: 2a01:40:1001:35::2
     195.66.240.130

bbc.co.uk    nameserver = ns1.thdow.bbc.co.uk
bbc.co.uk    nameserver = ns1.rbsov.bbc.co.uk
bbc.co.uk    nameserver = ns1.tcams.bbc.co.uk
ns1.rbsov.bbc.co.uk   Internet address = 212.58.241.67
ns1.tcams.bbc.co.uk   Internet address = 212.72.49.3
ns1.thdow.bbc.co.uk   Internet address = 212.58.240.163
> [url=http://www.bbc.co.uk]www.bbc.co.uk[/url]
Server: ns1.nic.uk
Addresses: 2a01:40:1001:35::2
     195.66.240.130

bbc.co.uk    nameserver = ns1.tcams.bbc.co.uk
bbc.co.uk    nameserver = ns1.thdow.bbc.co.uk
bbc.co.uk    nameserver = ns1.rbsov.bbc.co.uk
ns1.rbsov.bbc.co.uk   Internet address = 212.58.241.67
ns1.tcams.bbc.co.uk   internet address = 212.72.49.3
ns1.thdow.bbc.co.uk   internet address = 212.58.240.163
> abcdefg123456.bbc.co.uk
Server: ns1.nic.uk
Addresses: 2a01:40:1001:35::2
     195.66.240.130

bbc.co.uk    nameserver = ns1.rbsov.bbc.co.uk
bbc.co.uk    nameserver = ns1.thdow.bbc.co.uk
bbc.co.uk    nameserver = ns1.tcams.bbc.co.uk
ns1.rbsov.bbc.co.uk   internet address = 212.58.241.67
ns1.tcams.bbc.co.uk   internet address = 212.72.49.3
ns1.thdow.bbc.co.uk   internet address = 212.58.240.163

בשאילתה הראשונה ביקשתי מ- ns1.nic.uk את כל מה שהוא יודע על bbc.co.uk ובתשובה הוא החזיר לי את כתובות שרתי ה- DNS של הדומיין. בשאילתה השניה ביקשתי את כל מה שהוא יודע על www.bbc.co.uk וקיבלתי בדיוק את אותה התשובה: את שרתי ה- DNS של bbc.co.uk. השרת אומר לי "אין לי מושג, אבל לך תשאל אותם, הם צריכים לדעת". בשאילתה השלישית ביקשתי סאב-דומיין שאינו קיים בכלל ב- bbc.co.uk. אבל השרת שאחראי על co.uk לא יודע כלום על מה שיש מתחת ל- bbc.co.uk, הוא לא יכול לומר לי שאין בכלל שם כמה. כל מה שהוא יכול לומר לי זה ללכת לשאול את שרתי ה- DNS של bbc.cu.uk.

תרגיש חופשי לחזור על התרגיל עם דומיים ברטי אחר ועם שרת DNS אחר מבין ה- authoritative של co.uk. או, אם אתה מעדיף, לך על משהו אחר לגמרי, נאמר על net.il, לא יהיה הבדל בתוצאות.

לא משנה איפה הדומיין רשום. לא משנה איפה שרת ה- DNS יושב פיזית. לא משנה איפה השרת המתשאל יושב פיזית או, אם הוא גם מחזיק דומיינים, לא משנה מה הם. בכל מקרה בסופו של התהליך השרת יגיע ל- authoritative, השרת שאחראי על xxx.co.uk, וישאל אותו מה הכתובת של www.xxx.co.uk ואת הערך הזה הוא יחזיק ב- cache שלו למשל הזמן שהשרת שאחראי על xxx.co.uk יאמר לו ולא משנה איך הוא הגיע לשם. ובכל מקרה אין מצב שתצטרך לעבור שתי היררכיות - אין לזה משמעות בכלל. חיפוש מתחיל תמיד מהנקודה הכי קרובה לדומיין שהשרת מכיר. אם הוא יוד מיהם שרתי ה- DNS של xxx.co.uk, הוא ישאל אותם ישירות. אם את זה הוא לא יודע אבל יודע מהם שרתי ה- DNS של co.uk, הוא יתחיל משם ואז יגיע ל- DNS של xxx.co.uk. אם הוא לא יודע גם את זה אבל מכיר את שרתי ה- DNS של uk, הוא יתחיל מהם, ירד ל- co.uk ומשם ל- xxx.co.uk. אם גם את uk הוא לא מכיר, הוא יתחיל שרתי ה- root. אין שום סיבה לעבור על היררכיה אחרת כיוון שהיא, טוב, אחרת! השרת לא צריך ללכת לחפש את הכתובות של שרתי ה- root כיוון שזו הגדרה שיש לכל שרת DNS שקיים באינטרנט. לא מאמין? תראה:

> server 8.8.8.8
Default Server: Google-public-dns-a.google.com
Address: 8.8.8.8

> .
Server: google-public-dns-a.google.com
Address: 8.8.8.8

Non-authoritative answer:
(root) nameserver = i.root-servers.net
(root) nameserver = e.root-servers.net
(root) nameserver = b.root-servers.net
(root) nameserver = a.root-servers.net
(root) nameserver = g.root-servers.net
(root) nameserver = l.root-servers.net
(root) nameserver = f.root-servers.net
(root) nameserver = j.root-servers.net
(root) nameserver = d.root-servers.net
(root) nameserver = c.root-servers.net
(root) nameserver = h.root-servers.net
(root) nameserver = m.root-servers.net
(root) nameserver = k.root-servers.net
> server 4.2.2.2
Default Server: vnsc-bak.sys.gtei.net
Address: 4.2.2.2

> .
Server: vnsc-bak.sys.gtei.net
Address: 4.2.2.2

Non-authoritative answer:
(root) nameserver = j.root-servers.net
(root) nameserver = k.root-servers.net
(root) nameserver = f.root-servers.net
(root) nameserver = c.root-servers.net
(root) nameserver = g.root-servers.net
(root) nameserver = d.root-servers.net
(root) nameserver = e.root-servers.net
(root) nameserver = a.root-servers.net
(root) nameserver = i.root-servers.net
(root) nameserver = l.root-servers.net
(root) nameserver = h.root-servers.net
(root) nameserver = m.root-servers.net
(root) nameserver = b.root-servers.net
> server 62.219.186.7
Default Server: [62.219.186.7]
Address: 62.219.186.7

> .
Server: [62.219.186.7]
Address: 62.219.186.7

Non-authoritative answer:
(root) nameserver = b.root-servers.net
(root) nameserver = j.root-servers.net
(root) nameserver = i.root-servers.net
(root) nameserver = f.root-servers.net
(root) nameserver = d.root-servers.net
(root) nameserver = c.root-servers.net
(root) nameserver = h.root-servers.net
(root) nameserver = m.root-servers.net
(root) nameserver = g.root-servers.net
(root) nameserver = k.root-servers.net
(root) nameserver = e.root-servers.net
(root) nameserver = l.root-servers.net
(root) nameserver = a.root-servers.net
>

גם גוגל יודעים מהם שרתי ה- root, גם OpenDNS וגם בזב"ל. הם חייבים לדעת אחרת לא יוכלו לשאול אף שרת אחר. וברגע שאתה יודע איפה נמצא השורש, אין שום סיבה להתחיל מהענף הלא-נכון. גרוע יותר, אם תתחיל מהענף הלא-נכון, יש סיכוי לא רע שלעולם לא תגיע ליעד, כיוון שכל שרת מכיר את הרשומות שנמצאות מיד מתחתיו אבל לא את אלו שנמצאות מעליו: שרת ה- DNS של bbc.co.uk יודע מהי הכתובת של www.bbc.co.uk אבל לא יודע מה שרת ה- DNS שאחראי על co.uk. אם תתחיל מה- bbc, לא תוכל לטפס למעלה ל- root כדי לרדת משם למטה ל, נאמר, www.hwzone.co.il.

ונעבור לוויקיפדיה:

https://en.wikipedia.org/wiki/Domain_Name_System#Address_resolution_mechanism

Address resolution mechanism Domain name resolvers determine the appropriate domain name servers responsible for the domain name in question by a sequence of queries starting with the right-most (top-level) domain label.

[/q]

A DNS recursor consults three nameservers to resolve the address www.wikipedia.org. The process entails:

[list type=decimal]

[*]A network host is configured with an initial cache (so called hints) of the known addresses of the root nameservers. Such a hint file is updated periodically by an administrator from a reliable source.

[*]A query to one of the root servers to find the server authoritative for the top-level domain.

[*]A query to the obtained TLD server for the address of a DNS server authoritative for the second-level domain.

[*]Repetition of the previous step to process each domain name label in sequence, until the final step which returns the IP address of the host sought.

The diagram illustrates this process for the host www.wikipedia.org.

The mechanism in this simple form would place a large operating burden on the root servers, with every search for an address starting by querying one of them. Being as critical as they are to the overall function of the system, such heavy use would create an insurmountable bottleneck for trillions of queries placed every day. In practice caching is used in DNS servers to overcome this problem, and as a result, root nameservers actually are involved with very little of the total traffic.

הדיאגרמה מסבירה את התהליך בצורה פשוטה לדעתי. הלאה:

https://en.wikipedia.org/wiki/Domain_Name_System#Record_caching

Record caching The DNS Resolution Process reduces the load on individual servers by caching DNS request records for a period of time after a response. This entails the local recording and subsequent consultation of the copy instead of initiating a new request upstream. The time for which a resolver caches a DNS response is determined by a value called the time to live (TTL) associated with every record. The TTL is set by the administrator of the DNS server handing out the authoritative response. The period of validity may vary from just seconds to days or even weeks.

As a noteworthy consequence of this distributed and caching architecture, changes to DNS records do not propagate throughout the network immediately, but require all caches to expire and refresh after the TTL. RFC 1912 [/q]

conveys basic rules for determining appropriate TTL values. Some resolvers may override TTL values, as the protocol supports caching for up to 68 years or no caching at all. Negative caching, i.e. the caching of the fact of non-existence of a record, is determined by name servers authoritative for a zone which must include the Start of Authority (SOA) record when reporting no data of the requested type exists. The value of the MINIMUM field of the SOA record and the TTL of the SOA itself is used to establish the TTL for the negative answer.

ההדגשה שלי. ועכשיו הגיע הזמן ללכת לישון ולחלום על רשומות PTR... 8)

[Idannn]

איסתרא בלגינא, אני מתפלא עלייך לטובה, ואני יסביר למה...

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

נראה לי שהדיון הזה לא יסתיים ואתה תמשיך להוכיח את עצמך פעם אחרי פעם ומי יודע עד מתי...

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

ותשובות כמו "אתה משעשע מרגע לרגע" ללא ביסוס או הוכחה מראה כנראה על חוסר ידע באותו תחום, אחרת היה מה להוכיח.

אין צורך בתוגבה שתגיד, שמע... אתה צודק, טעינו.

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

שיהיה לילה טוב לכולנו, ונקווה שהויכוח הזה יסתיים

[אורח]

^ ומטרת ההודעה שלך היתה מה? לעצבן אנשים?

אם אין לך מה להוסיף לדיון אז תמשיך לדיון הבא.

[Idannn]

מטרת התגובה הייתה לתת קצת חיזוק חיובי למי שמגיע לו... ומגיע לו!

[Milford Cubicle]

לא מגיע לו כלום כי הוא מדבר שטויות, אבל כאמור אתה מוזמן להמשיך להאמין למי שבא לך

[Kalen]

אחרי כל החפירות והעלבות, עדיין לא היתה התיחסות אמיתית לטענות מ 2 אנשים, שיש חיסרון בשרתי ה DNS של הספקיות. (מילפורד: "אני עובד הרבה עם רישום דומיינים חדשים/עדכון קיימים וכו' - במקרים רבים איטיות העדכון של שרתי ה-DNS הישראלים היא מביכה.")

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

אז בואו נשוב לשאלה המקורית. מה עדיף: להשתמש ב DNS של גוגל או בזה של הספקיות?

ואני אוסיף עוד שאלה: לארגון של מאות עמדות, מה עדיף? במיוחד כאשר יש בתוך האירגון שרתי עידכון שונים. (WSUS, Anti virus Server, וכו')

[Gil28]

לא באמת משנה... למה שלא תנסה?

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

אחרי כל החפירות והעלבות, עדיין לא היתה התיחסות אמיתית לטענות מ 2 אנשים, שיש חיסרון בשרתי ה DNS של הספקיות. (מילפורד: "אני עובד הרבה עם רישום דומיינים חדשים/עדכון קיימים וכו' - במקרים רבים איטיות העדכון של שרתי ה-DNS הישראלים היא מביכה.")

אני לא רואה איך זה יכול להיות אפשרי, העדכון של רשומה חדשה הוא מיידי אלא אם נעשה שימוש ב- negative cache (כלומר שמירה במטמון של תשובות שליליות - אין דומיין כזה) וגם אז, לתשובות שליליות יש בד"כ TTL מאוד נמוך, מס' שעות לכל היותר.

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

מתי עוד יכולה להיות בעיה? כשהדומיין היה מאוכסן אצל ספק מקומי. נאמר שהדומיין שלך ישב על שרת ה- DNS של בזב"ל. זה לא אומר שהוא חייב להיות דומיין ישראלי וזה לא אומר שהאתר חייב לשבת בחווה של בזב"ל, רק שה- authoritative DNS, שרת ה- DNS שמחזיק את הדומיין, שייך לבזב"ל. יום אחד מציעים לך הצעה שאי אפשר לסרב לה בנטויז'ן (אתה מוצא על הכרית ראש של שרת... 8) ) ומעביר את הדומיין אליהם. איך? אתה פומה לרשם הדומיינים ומודיע לו שמעכשיו, ה- DNS-ים שאחראים על הדומיין שלך הם אלו של נטויז'ן במקום אלו של בזב"ל. מהרגע שבו הרשם דואג לעדכון ה- DNS ברמה שמעל לדומיין שלך, כל מי שישלח שאילתה על kalen.co.il, יקבל את שרתי ה- DNS של הנטויז'ן - כלומר אחרי שה- TTL של הרשומה הישנה, שהפנתה לבזב"ל, יפוג. נאמר 24 שעות.

אבל מה קורה אם שכחת לספר לבזב"ל שאתה מעביר את הדומיין לנטויז'ן או אם אמרת להם אבל הם שכחו להסיר את הדומיים משרת ה- DNS שלהם? למי שלא משתמש ב- DNS של בזב"ל אין שום בעיה. לקוח של סמייל, למשל, יפנה לשרתים של סמייל, שיגיעו בסופו של תהליך לשרתים של נטויז'ן ויקבלו את כתובת ה- IP המעודכנת שלך. אבל לקוחות של בזב"ל בבעיה: הם פונים לשרת של בזב"ל, שעדיין חוש שהוא זה שאחראי על הדומיין שלך. כששרת מקבל שאילתה לדומיין שהוא ה- authoritative שלו, הוא לא הולך לחפש את התשובה בעולם - אין טעם, בסופו של דבר התהליך הרקורסיבי הזה יפנה את השאילתה בחזרה לעצמו, כיוון שהוא זה שאחראי על הדומיין. אז הוא פשוט יענה לך לפי מה שמופיע ב- zone file אצלו, שמנה עדיין ל- IP הישן. לא משנה מה תעדכן בנטויז'ן, כל עוד השרת של בזב"ל חושב שהוא אחראי על הדומיין, הלקוחות של בזב"ל לא ידעו איפה האתר שלך. כמובן שזו לא בעיה שקיימת רק בבזב"ל, סתם לקחתי אותם כדוגמה, אני יכול לספר לך שורה של סיפורי ימה על בעלי אתרים שמתקשרים בלחץ להתלונן שהאתר שלהם הפסיק לעבוד או שהוא נשאר לא מעודכן אבל כשאני בודק אותו, הכל נראה בסדר. לוקח זמן לאסוף מספיק תלונות כדי לאבחן שהבעיה מוגבלת לספק אחד ואז בדיקה מהירה בשרתי ה- DNS שלו בד"כ תבהיר מה הבעיה. ואז מתחיל הסיפור הארוך של להסביר ל- NOC של הספק מה הבעיה, לגלות שהעבירו אותך לתמיכה כי אין אף אחד שיכול לטפל בזה בשעה הזו, לגלות שהתמיכה לא יכולה לעזור לך בכלל כי אתה לא לקוח שלהם, הם לא מצליחים להבין את הבעיה ובכל מקרה אין להם שום שליטה על שרת ה- DNS, לעבור שוב ל- NOC ולנסות לשכנע אותו שהוא צריך להקפיץ hostmaster בגלל שמישהו שכבר אינו לקוח שלהם סובל מטעות שהם עשו, לגלות שהוא לא יכול לעשות כלום בלי מספר לקוח שכבר לא קיים... כמה טוב שזה לא קורה לעיתים קרובות.

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

דבר דומה יכול לקרות ברישום דומיין חדש. אתה רושם דומיין דרך בזב"ל. הדומיין שלך מוגדר ב-- DNS של בזב"ל ונרשם ברשם הדומיינים המתאים, נאמר ISOC-IL. אלא מה, רשם הדומיינים יכול להפעיל את הדומיין שלך למחרת או אפילו אחרי יומיים ועד שהוא לא יעשה זאת, רק לקוחות של בזב"ל יוכלו להגיע לאתר שלך. למה? כי כשהם שואלים את ה- DNS של בזב"ל איפה www.kalen.co.il, הוא יודע איפה הוא כיוון שהוא authoritative לדומיין הזה, אבל כששואלים את השרת של, נמאר, סמייל, הוא פונה ל- DNS שאחראי על co.il בחיפוש אחר kalen.co.il והשרת, שעוד לא עודכן ע"י רשם הדומיינים, מחזיר שהדומיין לא קיים.

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

מיקרוסופט בהחלט יכולה. אבל מיקרוסופט לא הקימה רשת CDN משל עצמה, היא משתמשת ברשת של חברה אחרת (אקאמאי). כדי שזה יעבוד, הקישור באתר www.microsoft.com צריך להפנות אותך לאתר המקומי, נאמר 012.il.download.microsoft.com, ואז לא משנה באיזה שרת DNS תשתמש, תמיד תגיע למקום הנכון. אבל אקאמאי לא יכולה לשנות את האתר של מיקרוסופט. מיקרוסופט יכולה, אבל שם לא יודעים עם אלו ספקים יש לאקאמאי חוזים ומה הסטטוס של כל שרת של אקאמאי בעולם. יכול להיווצר מצב שלקוחות של בזב"ל לא יכולים להוריד כי מיקרוסופט מפנה לשרת מקומי של אקאמאי שבכלל לא קיים. אקאמאי לא יודעת מה ה- IP שלך כשאתה פונה לשרת ה- DNS כיוון שאתה לא עושה את זה ישירות, שרת ה- DNS המקומי שלך (או שרת אחר, למשל זה של גוגל), עושה את זה בשבילך. הם יכולים להחזיר לכולם את אותה כתובת IP ובאותה כתובת להחזיק שרת שיזהה לפי הכתובת שממנה אתה מגיע לאיזה ספק אתה שייך ואז להפנות אותך בהתאםלשרת הקרוב ביותר, אבל זו שיטה מסורבלת שסובלת מאותה בעיה שיש כשאתהלא משתמש ברשת CDN - אתה צריך לצאת מהרשת של הספק המקומי שלך. הרבה יותר שפוט וזול והתשמש בשירותי ה- DNS וזה כאמור יעבוד עבור 99% מהמשתמשים.

אבל יש חברות שבונות רשת CDN משל עצמם. גוגל, למשל, מחזיקה שרתים בכל העולם שמפיצים סרטוני YouTube. אם זה סרטון פופולרי, מה הרעיון לשלוח אותו מארה"ב לארץ עשר פעמים כל שניה? עדיף לשלוח אותו פעם אחת לשרת שנמצא בארץ והוא יפיץ אותו לגולשים ישראליים עשר פעמים בשניה. פחות רוחב פס, טעינה מהירה יותר. ל- GGN (גוגל גלובל נטוורק) יש שרתים אצל הספקים השונים. כשאתה נכנס ל- YouTube, ה- URL של הסרט מותאם לזיהוי הספק שלך, למיטב ידיעתי לפי כתובת ה- IP שלך. במקרה שלי, למשל, סרטונים מגיעים מ-

[Milford Cubicle]

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

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

[Kalen]

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

הם אומרים שמניסיונם זה קורה יותר מדי פעמים.

אז מה זה משנה מדוע זה קורה אם זה אכן קורה ? האם לא עדיף למנוע את זה בכלל ?

[Milford Cubicle]

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

הם אומרים שמניסיונם זה קורה יותר מדי פעמים.

ואת המסקנה, קוראים נכבדים, אני מקווה שאתם סוף סוף מצליחים להבין לבד

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

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

אהלן מילפורד! אז מה, כשאתה רואה פתח מילוט פתאום אני כבר לא טרול?

לא נשבר ולא נעליים. וגם לא עמוד עשר. כתבתי את זה כבר בעמוד שמונה:

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

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

דוגמה:

> hwzone.co.il
Server: box.privatebox
Address: 192.168.200.1

Non-authoritative answer:
hwzone.co.il  Internet address = 212.199.164.135
hwzone.co.il  nameserver = ns1.hwzone.co.il
hwzone.co.il  nameserver = ns2.hwzone.co.il
> ns1.hwzone.co.il
Server: box.privatebox
Address: 192.168.200.1

Non-authoritative answer:
ns1.hwzone.co.il    Internet address = 212.199.164.135
> ns2.hwzone.co.il
Server: box.privatebox
Address: 192.168.200.1

Non-authoritative answer:
ns2.hwzone.co.il    Internet address = 212.199.164.135

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

מי שמשתמש בשרתי ה- DNS של נטויז'ן יתעדכן מיד. השרת שם הוא מעכשיו authoritative וכבר לא משתמש יותר ב- cache שלו כדי להחזיר תשובות עבור hwzone.co.il. מי שמשתמש בשרתי ה- DNS של סמייל יתעדכן מיד. השרת שם כבר לא מחזיק יותר את ה- zone file של הדומיין ואין לו נתונים ב- cache, כי עד עכשיו הוא לא היה צריך להשתמש בו ולכן ילך לחפש באינטרנט מי אחראי על הדומיין, יגלה שזה נטויז'ן ויתעדכן משם (כלומר בהנחה שה- name server וה- cache server שלהם הם אותו שרת. אם הם לא, יקרה מה שצפוי לקרות בגוגל, להלך). ומי שמשתמש בשרתי ה- DNS של גוגל? השרתים של גוגל יתעדכנו כשה- TTL יפוג ויהיה צורך לרענן את הנתונים. אבל זה לא ה- A record, הרשומה שמפנה את הדומיין לכתובת IP, זה ה- NS record, הרשומה שמפנה לשרת ה- DNS של הדומיין. הרשומות האלו נמצאות רמה אחת למעלה, בשרתים שאחראים על ההיררכיה co.il (אחרת אי אפשר יהיה למצוא את הדומיין), הורדת ה- TTL בשרת ה- DNS שמאחסן את hwzone.co.il מראש כדי להקטין את זמן העדכון בכלל לא תשפיע:

> hwzone.co.il.
Server: nse.ns.il
Address: 192.115.141.253

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

  QUESTIONS:
    hwzone.co.il, type = NS, class = IN
  AUTHORITY RECORDS:
  -> hwzone.co.il
    nameserver = ns2.spd.co.il
    ttl = 86400 (1 day)
  -> hwzone.co.il
    nameserver = ns1.spd.co.il
    ttl = 86400 (1 day)

------------
hwzone.co.il
    nameserver = ns2.spd.co.il
    ttl = 86400 (1 day)
hwzone.co.il
    nameserver = ns1.spd.co.il
    ttl = 86400 (1 day)
>

ה- TTL הוא 24 שעות כלומר יקח בין אפס ל- 24 שעות עד שהשרתים של גוגל יתעדכנו (תלוי כמה זמן לפני השינוי הרשומה נכנסה ל- cache של גוגל. מאחר שמאחורי הכתובת 8.8.8.8 יושבים כמה שרתים, זה יכול להשתנות מגולש לגולש). בנטויז'ן זה יקח אפס, בגוגל זה יקח עד 24 שעות. אז מי יותר מהיר?

כמובן שגם ההיפך אפשרי. אבל מצב שבו רק גוגל מהירים יותר? זה לא.

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

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

[Milford Cubicle]

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

א. זה לא מקרים חריגים.

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

ההבדל היה חד משמעי, בולט מאוד, אחיד וקבוע בכמעט 100% מהמקרים.

אבל לך כנראה קצת קשה להתמודד עם עובדות, אתה מעדיף להמשיך לחיות בעולם התיאוריות שאתה מפתח לעצמך

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

מי שרוצה, יקשיב.

מי שלא רוצה, לא חייב