เวลาแฝง DNS ต่ำเป็นกุญแจสำคัญในการท่องอินเทอร์เน็ตที่รวดเร็ว เพื่อลดขนาดให้เหลือน้อยที่สุด สิ่งสำคัญคือต้องเลือกเซิร์ฟเวอร์ DNS อย่างระมัดระวังและ
นี่คือสาเหตุที่เดิมที DNS ได้รับการออกแบบให้เป็นโปรโตคอลที่สามารถแคชได้สูง ผู้ดูแลระบบโซนจะตั้งเวลาถ่ายทอดสด (TTL) สำหรับแต่ละรายการ และผู้แก้ไขจะใช้ข้อมูลนี้เมื่อจัดเก็บรายการในหน่วยความจำเพื่อหลีกเลี่ยงการรับส่งข้อมูลที่ไม่จำเป็น
การแคชมีประสิทธิภาพหรือไม่? เมื่อสองสามปีก่อน งานวิจัยเล็กๆ น้อยๆ ของฉันแสดงให้เห็นว่ามันไม่สมบูรณ์แบบ มาดูสถานะปัจจุบันกันดีกว่า
เพื่อรวบรวมข้อมูลที่ฉันแพตช์
ชุดข้อมูลผลลัพธ์ประกอบด้วยบันทึก 1 รายการ (ชื่อ, qtype, TTL, การประทับเวลา) นี่คือการกระจาย TTL โดยรวม (แกน X คือ TTL ในหน่วยวินาที):
นอกเหนือจากการเพิ่มขึ้นเล็กน้อยที่ 86 (ส่วนใหญ่เป็นสำหรับบันทึก SOA) ก็ค่อนข้างชัดเจนว่า TTL อยู่ในช่วงต่ำ มาดูกันดีกว่า:
โอเค TTL ที่มากกว่า 1 ชั่วโมงไม่มีนัยสำคัญทางสถิติ จากนั้นมาเน้นที่ช่วง 0−3600:
TTL ส่วนใหญ่อยู่ที่ 0 ถึง 15 นาที:
ส่วนใหญ่มาจาก 0 ถึง 5 นาที:
มันไม่ค่อยดีนัก
การกระจายสะสมทำให้ปัญหาชัดเจนยิ่งขึ้น:
ครึ่งหนึ่งของการตอบสนอง DNS มี TTL 1 นาทีหรือน้อยกว่า และสามในสี่มี TTL 5 นาทีหรือน้อยกว่า
แต่เดี๋ยวก่อน มันแย่กว่านั้นจริงๆ ท้ายที่สุดนี่คือ TTL จากเซิร์ฟเวอร์ที่เชื่อถือได้ อย่างไรก็ตาม ตัวแก้ไขไคลเอ็นต์ (เช่น เราเตอร์ แคชในเครื่อง) ได้รับ TTL จากตัวแก้ไขอัปสตรีม และจะลดลงทุกวินาที
ดังนั้นลูกค้าจึงสามารถใช้แต่ละรายการโดยเฉลี่ยครึ่งหนึ่งของ TTL ดั้งเดิมก่อนที่จะส่งคำขอใหม่
บางที TTL ที่ต่ำมากเหล่านี้อาจใช้ได้กับคำขอที่ผิดปกติเท่านั้น ไม่ใช่เว็บไซต์และ API ยอดนิยมใช่ไหม มาดูกันดีกว่า:
แกน X คือ TTL แกน Y คือความนิยมในการค้นหา
น่าเสียดายที่ข้อความค้นหาที่ได้รับความนิยมสูงสุดนั้นเป็นข้อความที่แย่ที่สุดในการแคชเช่นกัน
มาซูมเข้ากัน:
คำตัดสิน: มันแย่จริงๆ เมื่อก่อนมันแย่อยู่แล้ว แต่มันแย่ลงไปอีก การแคช DNS แทบไม่มีประโยชน์เลย เนื่องจากมีคนใช้ DNS Resolver ของ ISP น้อยลง (ด้วยเหตุผลที่ดี) เวลาแฝงที่เพิ่มขึ้นจึงเห็นได้ชัดเจนยิ่งขึ้น
การแคช DNS มีประโยชน์เฉพาะกับเนื้อหาที่ไม่มีใครเข้าชมเท่านั้น
โปรดทราบว่าซอฟต์แวร์อาจ
ทำไมเป็นเช่นนั้น
เหตุใดระเบียน DNS จึงถูกตั้งค่าเป็น TTL ต่ำเช่นนี้
- โหลดบาลานเซอร์แบบเดิมยังคงมีการตั้งค่าเริ่มต้น
- มีความเชื่อผิดๆ ว่าการปรับสมดุลโหลด DNS ขึ้นอยู่กับ TTL (สิ่งนี้ไม่เป็นความจริง - ตั้งแต่สมัยของ Netscape Navigator ไคลเอนต์ได้เลือกที่อยู่ IP แบบสุ่มจากชุด RR และลองใช้อันอื่นอย่างโปร่งใสหากไม่สามารถเชื่อมต่อได้)
- ผู้ดูแลระบบต้องการใช้การเปลี่ยนแปลงทันที ดังนั้นจึงง่ายต่อการวางแผน
- ผู้ดูแลระบบเซิร์ฟเวอร์ DNS หรือโหลดบาลานเซอร์มองว่างานของเขาเป็นการปรับใช้การกำหนดค่าที่ผู้ใช้ร้องขออย่างมีประสิทธิภาพ และไม่เพิ่มความเร็วให้กับไซต์และบริการ
- TTL ต่ำช่วยให้คุณอุ่นใจได้
- ในตอนแรกผู้คนตั้งค่า TTL ต่ำสำหรับการทดสอบแล้วลืมเปลี่ยน
ฉันไม่ได้รวม "เฟลโอเวอร์" ไว้ในรายการเพราะมีความเกี่ยวข้องน้อยลงเรื่อยๆ หากคุณต้องการเปลี่ยนเส้นทางผู้ใช้ไปยังเครือข่ายอื่นเพียงเพื่อแสดงหน้าข้อผิดพลาดเมื่อทุกอย่างเสียหายโดยสิ้นเชิง อาจยอมรับความล่าช้าได้มากกว่า 1 นาทีได้
นอกจากนี้ TTL หนึ่งนาทีหมายความว่าหากเซิร์ฟเวอร์ DNS ที่เชื่อถือได้ถูกบล็อกนานกว่า 1 นาที จะไม่มีใครสามารถเข้าถึงบริการที่ต้องพึ่งพาได้ และความซ้ำซ้อนจะไม่ช่วยอะไรหากสาเหตุมาจากข้อผิดพลาดในการกำหนดค่าหรือการแฮ็ก ในทางกลับกัน ด้วย TTL ที่สมเหตุสมผล ไคลเอนต์จำนวนมากจะยังคงใช้การกำหนดค่าก่อนหน้าต่อไปและไม่เคยสังเกตเห็นสิ่งใดเลย
บริการ CDN และตัวจัดสรรภาระงานมักถูกตำหนิสำหรับ TTL ต่ำ โดยเฉพาะอย่างยิ่งเมื่อรวม CNAME กับ TTL ต่ำ และบันทึกที่มี TTL ต่ำ (แต่เป็นอิสระ) เท่าๆ กัน:
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
เมื่อใดก็ตามที่ CNAME หรือระเบียน A ใดๆ หมดอายุ จะต้องส่งคำขอใหม่ ทั้งสองมี TTL 30 วินาที แต่ก็ไม่เหมือนกัน TTL เฉลี่ยจริงจะอยู่ที่ 15 วินาที
แต่เดี๋ยวก่อน! มันเลวร้ายยิ่งกว่านั้นอีก รีโซลเวอร์บางตัวทำงานแย่มากในสถานการณ์นี้โดยมี TTL ต่ำสองตัวที่เกี่ยวข้องกัน:
$ เจาะ raw.githubusercontent.com @ 4.2.2.2 raw.githubusercontent.com 1 ใน CNAME github.map.fastly.net github.map.fastly.net 1 ใน 151.101.16.133
ตัวแก้ไขระดับ 3 อาจทำงานบน BIND หากคุณยังคงส่งคำขอนี้ TTL เท่ากับ 1 จะถูกส่งคืนเสมอ โดยพื้นฐานแล้ว raw.githubusercontent.com
ไม่เคยถูกแคช
นี่เป็นอีกตัวอย่างหนึ่งของสถานการณ์ดังกล่าวซึ่งมีโดเมนที่ได้รับความนิยมมาก:
$ drill detectportal.firefox.com @1.1.1.1 detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net. detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net. detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net. a1089.dscd.akamai.net. 10 IN A 104.123.50.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
อย่างน้อยสามระเบียน CNAME อ๋อ. อันหนึ่งมี TTL ที่ดี แต่ก็ไร้ประโยชน์โดยสิ้นเชิง CNAME อื่นๆ มี TTL เริ่มต้น 60 วินาที แต่สำหรับโดเมน akamai.net
TTL สูงสุดคือ 20 วินาทีและไม่มีรายการใดอยู่ในเฟส
แล้วโดเมนที่สำรวจอุปกรณ์ Apple อย่างต่อเนื่องล่ะ?
$ drill 1-courier.push.apple.com @4.2.2.2 1-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net. 1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net. gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
ปัญหาเดียวกันกับ Firefox และ TTL ส่วนใหญ่จะค้างอยู่ที่ 1 วินาทีเมื่อใช้รีโซลเวอร์ระดับ 3
ดรอปบ็อกซ์?
$ เจาะ client.dropbox.com @ 8.8.8.8 client.dropbox.com 7 ใน CNAME client.dropbox-dns.com ลูกค้า dropbox-dns.com 59 ใน A 162.125.67.3 $ เจาะ client.dropbox.com @4.2.2.2 client.dropbox.com 1 ใน CNAME client.dropbox-dns.com ลูกค้า dropbox-dns.com 1 ใน 162.125.64.3
ในการบันทึก safebrowsing.googleapis.com
ค่า TTL คือ 60 วินาที เช่น โดเมน Facebook และขอย้ำอีกครั้งจากมุมมองของลูกค้า ค่าเหล่านี้จะลดลงครึ่งหนึ่ง
แล้วการตั้งค่า TTL ขั้นต่ำล่ะ?
โดยใช้ชื่อ ประเภทคำขอ TTL และการประทับเวลาที่เก็บไว้แต่แรก ฉันเขียนสคริปต์เพื่อจำลองคำขอ 1,5 ล้านคำขอที่ส่งผ่านตัวแก้ไขแคช เพื่อประมาณปริมาณคำขอที่ไม่จำเป็นที่ส่งเนื่องจากรายการแคชหมดอายุ
47,4% ของคำขอเกิดขึ้นหลังจากบันทึกที่มีอยู่หมดอายุแล้ว ซึ่งถือว่าสูงเกินสมควร
หากตั้งค่า TTL ขั้นต่ำจะมีผลกระทบต่อการแคชอย่างไร
แกน X คือค่า TTL ขั้นต่ำ ระเบียนที่มี TTL ต้นทางสูงกว่าค่านี้จะไม่ได้รับผลกระทบ
แกน Y คือเปอร์เซ็นต์ของคำขอจากไคลเอ็นต์ที่มีรายการแคชไว้แล้ว แต่หมดอายุแล้วและกำลังสร้างคำขอใหม่
ส่วนแบ่งของคำขอ “พิเศษ” ลดลงจาก 47% เป็น 36% เพียงตั้งค่า TTL ขั้นต่ำเป็น 5 นาที เมื่อตั้งค่า TTL ขั้นต่ำเป็น 15 นาที จำนวนคำขอเหล่านี้จะลดลงเหลือ 29% TTL ขั้นต่ำ 1 ชั่วโมงจะลดเหลือ 17% ความแตกต่างที่สำคัญ!
ลองไม่เปลี่ยนแปลงอะไรในฝั่งเซิร์ฟเวอร์ แต่ตั้งค่า TTL ขั้นต่ำในแคช DNS ไคลเอนต์ (เราเตอร์, ตัวแก้ไขในเครื่อง) แทน
จำนวนคำขอที่ต้องการลดลงจาก 47% เป็น 34% โดยมี TTL ขั้นต่ำ 5 นาที เป็น 25% ในเวลาขั้นต่ำ 15 นาที และเหลือ 13% ในเวลาขั้นต่ำ 1 ชั่วโมง บางที 40 นาทีก็อาจเหมาะสมที่สุด
การเปลี่ยนแปลงเล็กๆ น้อยๆ นี้มีผลกระทบอย่างมาก
ผลที่ตามมาคืออะไร?
แน่นอนว่าบริการสามารถย้ายไปยังผู้ให้บริการคลาวด์รายใหม่ เซิร์ฟเวอร์ใหม่ เครือข่ายใหม่ โดยกำหนดให้ไคลเอ็นต์ต้องใช้บันทึก DNS ล่าสุด และ TTL ที่ค่อนข้างเล็กช่วยให้การเปลี่ยนแปลงดังกล่าวเป็นไปอย่างราบรื่นและมองไม่เห็น แต่ด้วยการเปลี่ยนไปใช้โครงสร้างพื้นฐานใหม่ ไม่มีใครคาดหวังให้ลูกค้าย้ายไปยังบันทึก DNS ใหม่ภายใน 1 นาที 5 นาที หรือ 15 นาที การตั้งค่า TTL ขั้นต่ำเป็น 40 นาที แทนที่จะเป็น 5 นาที จะไม่ป้องกันผู้ใช้จากการเข้าถึงบริการ
อย่างไรก็ตาม วิธีนี้จะช่วยลดเวลาแฝงได้อย่างมาก และปรับปรุงความเป็นส่วนตัวและความน่าเชื่อถือโดยการหลีกเลี่ยงคำขอที่ไม่จำเป็น
แน่นอนว่า RFC บอกว่าต้องปฏิบัติตาม TTL อย่างเคร่งครัด แต่ความจริงก็คือระบบ DNS นั้นไม่มีประสิทธิภาพมากเกินไป
หากคุณกำลังทำงานกับเซิร์ฟเวอร์ DNS ที่เชื่อถือได้ โปรดตรวจสอบ TTL ของคุณ คุณต้องการค่าที่ต่ำจนน่าขันจริงๆเหรอ?
แน่นอนว่ามีเหตุผลที่ดีในการตั้งค่า TTL ขนาดเล็กสำหรับบันทึก DNS แต่ไม่ใช่สำหรับ 75% ของการรับส่งข้อมูล DNS ที่แทบไม่มีการเปลี่ยนแปลง
และหากคุณจำเป็นต้องใช้ TTL ต่ำสำหรับ DNS ด้วยเหตุผลบางประการ ในเวลาเดียวกัน ตรวจสอบให้แน่ใจว่าไซต์ของคุณไม่ได้เปิดใช้งานแคช ด้วยเหตุผลเดียวกัน
หากคุณมีแคช DNS ในเครื่องทำงานอยู่ เช่น
ที่มา: will.com