เปอร์เซ็นต์ของเซิร์ฟเวอร์ชื่อที่ให้เกียรติกับ TTL ในวันนี้คือเท่าไหร่?

หลายปีก่อนฉันต้องทำการเปลี่ยนแปลง DNS หลายครั้งในช่วงหลายสัปดาห์ที่ผ่านมาเนื่องจากฉันย้ายบิตของอุปกรณ์จากศูนย์ข้อมูลหนึ่งไปยังอีกแห่งหนึ่ง ในช่วงเวลาที่ฉันทำสิ่งนี้ประมาณ 95% ของเซิร์ฟเวอร์ชื่อในโลกดูเหมือนจะเคารพค่า TTL และประมาณ 5% เพิกเฉยต่อเราและสร้างขึ้นเอง กล่าวอีกนัยหนึ่ง 95% ของปริมาณการใช้ข้อมูลเคลื่อนไหวภายใน TTL 15 นาทีที่เรากำหนดไว้ อีก 3% ทำในชั่วโมงแรก 1% ในวันแรกและพลัดหลงสองสามคนใช้เวลาถึงสามวัน

(ใช่แล้วฉันสับสนเปอร์เซ็นต์ของปริมาณการใช้งานกับเปอร์เซ็นต์ของเนมเซิร์ฟเวอร์โปรดแทรก handwaving)

อย่างไรก็ตามนี่เป็นประมาณปี 2001 และเราใช้ไดโนเสาร์เพื่อส่งแพ็คเก็ตผ่านท่อ ฉันเดาว่าเซิร์ฟเวอร์ชื่อวันนี้มีมารยาทที่ดีขึ้นและจะมีปัญหาน้อยลงกับคนหลงทาง ทุกคนมีความรู้สึกต่อปริมาณการรับส่งข้อมูลใดที่จะเปลี่ยนภายใน TTL ที่กำหนดในวันนี้? ยังมีเซิร์ฟเวอร์ชื่อจำนวนมากที่ไม่สนใจ TTL หรือไม่

เราเพิ่งย้ายและมีปัญหากับ DNS ทุกประเภท

เมื่อเราทำการแกว่งลูกค้าส่วนใหญ่เริ่มกด IP ใหม่ทันที แต่บางคนก็ยังคงใช้ไอพีเก่า ๆ อยู่หลายสัปดาห์ เราออกจากเซิร์ฟเวอร์ไปหนึ่งเดือนหรือมากกว่านั้น ในที่สุดเราก็ผ่าน IIS บันทึกในเครื่องเก่าและเรียกลูกค้าบอกให้ล้าง DNS บน บริษัท หรือเซิร์ฟเวอร์ ISP DNS นั่นเป็นครั้งสุดท้ายที่พวกเขาย้ายไป

เป็นคนจำนวนเล็กน้อยที่เก็บไว้กับ IP เก่า จากลูกค้า 20k, 50 อาจมีปัญหาหลังจากวันแรก

(มาก) ค่า TTL ของสัปดาห์ที่ยาวนานนั้นอยู่ในเดือนพฤษภาคม 2554 ซึ่งได้รับเกียรติจาก DNS เนมเซิร์ฟเวอร์มากถึง 2 สัปดาห์

ในการทดสอบโดยใช้ just-dnslookup.com มีจุดตรวจวัดแบบแอ็คทีฟกระจายอยู่ทั่วโลก 50 จุดโดยตั้งค่าระเบียน A เป็น 99.999.999 = 165 สัปดาห์ (แม่นยำ: 165 สัปดาห์ 2 วัน 9 ชั่วโมง 46 นาที 39 วินาที) และค่าเริ่มต้นของ TTL ของ 2 สัปดาห์ (= SOA + NS TTL)

ผลการค้นหาครั้งแรก :

• a TTL 1 สัปดาห์สำหรับ 3 คะแนนจาก 50 คะแนนการวัด
• TTL ที่ 165 สัปดาห์สำหรับ 47 จาก 50 คะแนนการวัด

การค้นหาที่ต่อเนื่องกันส่งคืน (แปลงเป็นค่า TTL ดั้งเดิม):

• a TTL 1 สัปดาห์สำหรับ 3 คะแนนจาก 50 คะแนนการวัด
• a TTL 2 สัปดาห์สำหรับ 46 จาก 50 คะแนนการวัด
• TTL ที่ 165 สัปดาห์สำหรับ 1 ใน 50 คะแนนการวัด

การทดสอบครั้งที่สอง (ใช้โดเมนอื่น) โดยที่ค่าเริ่มต้นของ TTL ถูกตั้งค่าเป็น 4 สัปดาห์ (= SOA + NS TTL) ผลลัพธ์ที่ด้านล่าง

ผลการค้นหาครั้งแรก :

• a TTL 1 สัปดาห์สำหรับ 3 คะแนนจาก 50 คะแนนการวัด
• a TTL 2 สัปดาห์สำหรับ 1 ใน 50 คะแนนการวัด
• TTL ที่ 165 สัปดาห์สำหรับ 46 จาก 50 คะแนนการวัด

การค้นหาต่อเนื่องกันส่งคืน (แปลงเป็นความยาว TTL เต็มรูปแบบ):

• a TTL 1 สัปดาห์สำหรับ 3 คะแนนจาก 50 คะแนนการวัด
• a TTL 2 สัปดาห์สำหรับ 47 จาก 50 คะแนนการวัด
• TTL ที่ 165 สัปดาห์สำหรับ 0 จาก 50 คะแนนการวัด

จากบริการตัวแก้ไขสาธารณะที่รู้จักกันดี / เชื่อมต่อดีที่สุด:

• DNS สาธารณะของ Google [8.8.8.8 และ 8.8.4.4] ลดลงเหลือ 1 วัน
• UltraDNS [rdns (1 | 2) .ultradns.net] ให้เกียรติเต็ม 165 สัปดาห์
• Sprintlink [ns (1 | 2 | 3) .sprintlink.net] ให้เกียรติเต็ม 165 สัปดาห์

ฉันเพิ่งย้าย DNS สำหรับบางโดเมนที่โฮสต์ไซต์ส่วนตัวของฉันและไซต์โปรเจ็กต์จาก GoDaddy ไปยัง DNS ในบ้าน (ใช่แล้วคือบ้านของฉัน) โดยรวมแล้วทุก ๆ ไซต์ที่ฉันเข้าถึงจากระยะไกลเพื่อเคารพ TTL และทำให้การเปลี่ยนแปลงดีขึ้น เพื่อนทุกคนฉันสามารถขอตรวจสอบได้เช่นเดียวกันรายงานผ่านโทรศัพท์บ้านและมือถือ ปัญหาเดียวที่น่าสังเกตคือเซิร์ฟเวอร์แคช DNS หลักที่ $ University ที่ฉันทำงานซึ่งดูเหมือนจะไม่สนใจ TTL ทั้งหมดสำหรับการสืบค้นที่ถูกแคช (และยังไม่สนใจค่า TTL ที่พวกเขากำหนดให้กับผลการแคช)

ดูเหมือนว่าโดยรวมแล้ว TTL ควรได้รับการเคารพอย่างดี 56% ของเซิร์ฟเวอร์ที่มีสิทธิ์สำหรับโดเมน. com และ. netใช้ BIND ซึ่งเห็นได้ชัดว่าทำงานได้ดีกับมาตรฐาน Cablevision / Optimum (อย่างน้อยในนิวเจอร์ซีย์) ดูเหมือนว่าจะใช้ Nominum CNS ซึ่งเคารพ TTLs เช่นกัน

นี่ไม่ใช่คำตอบสำหรับคำถามของคุณโดยเฉพาะ แต่สิ่งเพิ่มเติมที่ควรพิจารณาในการทดสอบของคุณ:

ตัวเรียกใช้ DNS ที่ถูกล่ามโซ่และ Daemons การแคช

มันไม่ได้เป็นเพียงแค่ผู้กู้ DNS ที่บันทึกแคช บางครั้งผู้คนเรียกสายซ้ำและเพิ่มเวลา ไม่ว่าเรื่องนี้ควรจะทำหรือไม่อาจเป็นการสนทนาที่ยืดยาวขึ้นอยู่กับสิ่งที่ผู้คนพยายามแก้ไข ฉันเห็นการเรียกซ้ำ 3 ระดับในศูนย์ข้อมูล recursors แบบผสมสามารถมีผลลัพธ์แบบผสมเนื่องจากการลดลงของ TTL จะไม่ถูกสงวนไว้เสมอไป บันทึกแคชของระบบปฏิบัติการบางรายการ บางระบบยังใช้สิ่งที่ชอบnscd, dnsmasqและวิธีการอื่น ๆ เพื่อลดผลกระทบของปัญหา recursor ท้องถิ่นและเพื่อลดภาระใน recursors ของพวกเขา คุณสมบัติของระบบปฏิบัติการจะแตกต่างกันไปตามรุ่นที่วางจำหน่าย, แคช daemons, รุ่นของ caching daemons, ฯลฯ ...

[แก้ไข]เพื่อย้ำซ้ำนี่ไม่ใช่พฤติกรรมปกติของผู้เรียกซ้ำหรือแคช daemon ฉันจะไม่ทำให้คนที่น่าอับอายขายหน้า แต่อย่างใดอย่างหนึ่งที่พวกเขาคิดว่าเป็น unmaintained แม้ว่าจะมาพร้อมกับลินุกซ์ distros มากมาย

Application DNS Cache

เบราว์เซอร์บางตัวยังบันทึกแคช Java และแอปอื่น ๆ แคช DNS เช่นกัน บางครั้งคุณสามารถกำหนดค่า ttl สูงสุดภายในแอปพลิเคชัน

ผลสุดท้ายสามารถบิดเบือน

รายการด้านบนสามารถเปลี่ยน TTL 15 นาทีเป็น 60+ นาทีหรือนานกว่าได้อย่างง่ายดาย

นี่คือเหตุผลที่ฉันมักแนะนำว่าแอปพลิเคชันหรือเว็บไซต์ควรพิจารณามีหลายโหนดที่ใช้งานอยู่ในการออกแบบการยอมรับความผิดเพื่อให้ลูกค้าสามารถกำหนดได้เร็วขึ้นเมื่อจุดเข้าหนึ่งจุดในไซต์ของคุณล้มเหลวและจัดการปัญหาโดยอัตโนมัติ เมื่อทำได้ Anycastเป็นวิธีการหนึ่งที่บาง บริษัท ใช้ในการทำให้ระบบล้มเหลวค่อนข้างโปร่งใสและไม่พึ่งพาการเปลี่ยนแปลง DNS อย่างมาก นอกจากนี้ยังมีวิธีการปรับสมดุลภาระที่ชาญฉลาดซึ่งสามารถทำได้ใน javascript โดยใช้หลายระเบียน DNS

คำถามเก่า แต่คำตอบใหม่ (2017, 6 ปีต่อมา):

1. ดูเหมือนว่าเซิร์ฟเวอร์ DNS ทั่วโลกเกือบทั้งหมดจะอัปเดตใน 5 นาที
2. Google และ OpenDNS ช่วยให้คุณสามารถล้างระเบียน DNS ด้วยตนเองเพื่อเร่งการอัปเดตการเผยแพร่

ก่อนการทดลองด้านล่างก่อนหน้านี้ฉันได้เปลี่ยน TTL จาก 14400 (วินาที = 4 ชั่วโมง) เป็น 300 (วินาที = 5 นาที) แต่ฉันทำก่อน 2 ชั่วโมงก่อนการทดลองและเนื่องจาก TTL ก่อนหน้านี้เป็น 4 ชั่วโมงฉันไม่แน่ใจว่าการเปลี่ยนแปลงของฉัน คงจะหมดไปแล้วหากเซิร์ฟเวอร์ DNS ไม่มี TTL ขั้นต่ำของตัวเอง

การทดลองของฉัน:

การทดลองที่ 1:

ฉันเปลี่ยนการแปลชื่อเป็น IP (ระเบียน) ในเซิร์ฟเวอร์ที่เชื่อถือแล้วตรวจสอบแล้ว:

• https://www.whatsmydns.net
• https://dnschecker.org

หลังจาก 5 นาที (300 วินาที) ประมาณครึ่งหนึ่งของเซิร์ฟเวอร์ทั่วโลกที่ตรวจสอบโดยไซต์เหล่านั้นได้รับการอัปเดตแล้ว

หลังจาก 7 นาทีข้อมูลทั้งหมดได้รับการอัปเดตยกเว้น 1

การทดลองที่ 2:

Google และ OpenDNS ช่วยให้คุณสามารถล้างแคช DNS ด้วยตนเองสำหรับโดเมนที่ต้องการ ลิงค์:

• ล้างรายการแคช DNS ของ Googleสำหรับโดเมนของคุณ: https://developers.google.com/speed/public-dns/cache
• ล้างรายการแคช DNS ของOpenDNSสำหรับโดเมนของคุณ: https://cachecheck.opendns.com/

ฉันอัปเดต A-record อีกอันจากนั้นล้างแคช DNS ของ Google ทันที พวกเขามี captcha ที่ทำให้ฉัน "คลิกที่ช่องสี่เหลี่ยมทั้งหมดที่มีสัญลักษณ์" 3 ครั้งดังนั้นใช้เวลา 1-2 นาทีก่อนที่ฉันจะสามารถทำการล้างได้

หลังจาก 4 นาทีมีเพียง 1 เซิร์ฟเวอร์ DNS ที่ตรวจสอบโดยไซต์เหล่านั้นที่มีที่อยู่ IP เก่า คนอื่น ๆ ทั้งหมดได้รับการปรับปรุง

ดังนั้นการล้างแคช DNS ของ Google และบังคับให้ตรวจสอบเซิร์ฟเวอร์ที่มีสิทธิ์อีกครั้งดูเหมือนจะเร่งการเผยแพร่ DNS ทั่วโลกซึ่งอาจเป็นการกระตุ้นการอัปเดตแคชทั่วทั้งเซิร์ฟเวอร์ของโลก

อย่างไรก็ตามแม้ไม่มี Google ฟลัชก็ปรากฏว่าการแพร่กระจายเป็นนาทีไม่กี่ชั่วโมงหรือวัน