เวลาแฝง DNS ต่ำเป็นกุญแจสำคัญในการท่องอินเทอร์เน็ตที่รวดเร็ว เพื่อลดขนาดให้เหลือน้อยที่สุด สิ่งสำคัญคือต้องเลือกเซิร์ฟเวอร์ DNS อย่างระมัดระวังและ . แต่ขั้นตอนแรกคือกำจัดคำค้นหาที่ไม่มีประโยชน์
นี่คือสาเหตุที่เดิมที DNS ได้รับการออกแบบให้เป็นโปรโตคอลที่สามารถแคชได้สูง ผู้ดูแลระบบโซนจะตั้งเวลาถ่ายทอดสด (TTL) สำหรับแต่ละรายการ และผู้แก้ไขจะใช้ข้อมูลนี้เมื่อจัดเก็บรายการในหน่วยความจำเพื่อหลีกเลี่ยงการรับส่งข้อมูลที่ไม่จำเป็น
การแคชมีประสิทธิภาพหรือไม่? เมื่อสองสามปีก่อน งานวิจัยเล็กๆ น้อยๆ ของฉันแสดงให้เห็นว่ามันไม่สมบูรณ์แบบ มาดูสถานะปัจจุบันกันดีกว่า
เพื่อรวบรวมข้อมูลที่ฉันแพตช์ เพื่อบันทึกค่า TTL สำหรับการตอบกลับ ซึ่งถูกกำหนดให้เป็น TTL ขั้นต่ำของบันทึกสำหรับคำขอที่เข้ามาแต่ละรายการ ซึ่งให้ภาพรวมที่ดีของการกระจาย TTL ของการเข้าชมจริง และยังคำนึงถึงความนิยมของคำขอแต่ละรายการด้วย เซิร์ฟเวอร์เวอร์ชันแพตช์ใช้งานได้หลายชั่วโมง
Результирующий набор данных состоит из 1 583 579 записей (name, qtype, TTL, timestamp). Вот общее распределение 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 มีประโยชน์เฉพาะกับเนื้อหาที่ไม่มีใครเข้าชมเท่านั้น
โปรดทราบว่าซอฟต์แวร์อาจ интерпретировать низкие TTL.
ทำไมเป็นเช่นนั้น
เหตุใดระเบียน DNS จึงถูกตั้งค่าเป็น TTL ต่ำเช่นนี้
- โหลดบาลานเซอร์แบบเดิมยังคงมีการตั้งค่าเริ่มต้น
- มีความเชื่อผิดๆ ว่าการปรับสมดุลโหลด DNS ขึ้นอยู่กับ TTL (สิ่งนี้ไม่เป็นความจริง - ตั้งแต่สมัยของ Netscape Navigator ไคลเอนต์ได้เลือกที่อยู่ IP แบบสุ่มจากชุด RR และลองใช้อันอื่นอย่างโปร่งใสหากไม่สามารถเชื่อมต่อได้)
- ผู้ดูแลระบบต้องการใช้การเปลี่ยนแปลงทันที ดังนั้นจึงง่ายต่อการวางแผน
- ผู้ดูแลระบบเซิร์ฟเวอร์ DNS หรือโหลดบาลานเซอร์มองว่างานของเขาเป็นการปรับใช้การกำหนดค่าที่ผู้ใช้ร้องขออย่างมีประสิทธิภาพ และไม่เพิ่มความเร็วให้กับไซต์และบริการ
- TTL ต่ำช่วยให้คุณอุ่นใจได้
- ในตอนแรกผู้คนตั้งค่า TTL ต่ำสำหรับการทดสอบแล้วลืมเปลี่ยน
ฉันไม่ได้รวม "เฟลโอเวอร์" ไว้ในรายการเพราะมีความเกี่ยวข้องน้อยลงเรื่อยๆ หากคุณต้องการเปลี่ยนเส้นทางผู้ใช้ไปยังเครือข่ายอื่นเพียงเพื่อแสดงหน้าข้อผิดพลาดเมื่อทุกอย่างเสียหายโดยสิ้นเชิง อาจยอมรับความล่าช้าได้มากกว่า 1 นาทีได้
นอกจากนี้ TTL หนึ่งนาทีหมายความว่าหากเซิร์ฟเวอร์ DNS ที่เชื่อถือได้ถูกบล็อกนานกว่า 1 นาที จะไม่มีใครสามารถเข้าถึงบริการที่ต้องพึ่งพาได้ และความซ้ำซ้อนจะไม่ช่วยอะไรหากสาเหตุมาจากข้อผิดพลาดในการกำหนดค่าหรือการแฮ็ก ในทางกลับกัน ด้วย TTL ที่สมเหตุสมผล ไคลเอนต์จำนวนมากจะยังคงใช้การกำหนดค่าก่อนหน้าต่อไปและไม่เคยสังเกตเห็นสิ่งใดเลย
В низких TTL в значительной степени виноваты cервисы CDN и балансировщики нагрузки, особенно когда они объединяют 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 секунде при использовании резолвера Level3.
ดรอปบ็อกซ์?
$ เจาะ 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 ในเครื่องทำงานอยู่ เช่น ซึ่งให้คุณตั้งค่า TTL ขั้นต่ำได้ ให้ใช้ฟังก์ชันนี้ นี่เป็นเรื่องปกติ จะไม่มีอะไรเลวร้ายเกิดขึ้น ตั้งค่า TTL ขั้นต่ำเป็นประมาณ 40 นาที (2400 วินาที) และ 1 ชั่วโมง ค่อนข้างเป็นช่วงที่เหมาะสม
ที่มา: will.com