ເວລາແຝງ DNS ຕ່ຳແມ່ນກຸນແຈສຳຄັນໃນການທ່ອງອິນເຕີເນັດໄວ. ເພື່ອຫຼຸດຜ່ອນມັນ, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະລະມັດລະວັງເລືອກເຄື່ອງແມ່ຂ່າຍ DNS ແລະ Relays ທີ່ບໍ່ເປີດເຜີຍຊື່. ແຕ່ຂັ້ນຕອນທໍາອິດແມ່ນເພື່ອກໍາຈັດການສອບຖາມທີ່ບໍ່ມີປະໂຫຍດ.

ນີ້ແມ່ນເຫດຜົນທີ່ວ່າ DNS ໄດ້ຖືກອອກແບບໃນເບື້ອງຕົ້ນເປັນໂປໂຕຄອນທີ່ສາມາດເກັບໄດ້ສູງ. ຜູ້ບໍລິຫານເຂດກໍານົດເວລາທີ່ຈະດໍາລົງຊີວິດ (TTL) ສໍາລັບການປ້ອນຂໍ້ມູນສ່ວນບຸກຄົນ, ແລະຜູ້ແກ້ໄຂໃຊ້ຂໍ້ມູນນີ້ໃນເວລາທີ່ເກັບຮັກສາລາຍການຢູ່ໃນຫນ່ວຍຄວາມຈໍາເພື່ອຫຼີກເວັ້ນການຈະລາຈອນທີ່ບໍ່ຈໍາເປັນ.

ແຄດມີຜົນບໍ? ສອງສາມປີກ່ອນ, ການຄົ້ນຄວ້ານ້ອຍໆຂອງຂ້ອຍສະແດງໃຫ້ເຫັນວ່າມັນບໍ່ສົມບູນແບບ. ໃຫ້​ເຮົາ​ມາ​ເບິ່ງ​ສະພາບ​ການ​ໃນ​ປະຈຸ​ບັນ.

ເພື່ອເກັບກໍາຂໍ້ມູນຂ້າພະເຈົ້າ patched ເຊີບເວີ DNS ທີ່ເຂົ້າລະຫັດໄວ້ ເພື່ອບັນທຶກຄ່າ TTL ສໍາລັບການຕອບສະຫນອງ. ມັນຖືກກໍານົດເປັນ TTL ຕໍາ່ສຸດທີ່ບັນທຶກຂອງມັນສໍາລັບແຕ່ລະຄໍາຮ້ອງຂໍທີ່ເຂົ້າມາ. ນີ້ເຮັດໃຫ້ສະພາບລວມທີ່ດີຂອງການແຈກຢາຍ TTL ຂອງການຈະລາຈອນທີ່ແທ້ຈິງ, ແລະຍັງຄໍານຶງເຖິງຄວາມນິຍົມຂອງຄໍາຮ້ອງຂໍສ່ວນບຸກຄົນ. ເຊີບເວີເວີຊັ່ນ patched ເຮັດວຽກເປັນເວລາຫຼາຍຊົ່ວໂມງ.

ຊຸດຂໍ້ມູນຜົນໄດ້ຮັບປະກອບດ້ວຍ 1 ບັນທຶກ (ຊື່, qtype, TTL, timestamp). ນີ້ແມ່ນການແຈກຢາຍ TTL ໂດຍລວມ (X-axis ແມ່ນ TTL ໃນວິນາທີ):

ນອກເຫນືອຈາກການຫຼຸດລົງເລັກນ້ອຍຢູ່ທີ່ 86 (ສ່ວນຫຼາຍແມ່ນສໍາລັບບັນທຶກ SOA), ມັນຂ້ອນຂ້າງຊັດເຈນວ່າ TTLs ຢູ່ໃນລະດັບຕໍ່າ. ລອງເບິ່ງໃກ້ໆ:

ຕົກລົງ, TTLs ຫຼາຍກວ່າ 1 ຊົ່ວໂມງແມ່ນບໍ່ມີຄວາມສໍາຄັນທາງສະຖິຕິ. ຈາກນັ້ນໃຫ້ເຮົາສຸມໃສ່ໄລຍະ 0–3600:

TTL ສ່ວນຫຼາຍແມ່ນມາຈາກ 0 ຫາ 15 ນາທີ:

ສ່ວນຫຼາຍແມ່ນມາຈາກ 0 ຫາ 5 ນາທີ:

ມັນບໍ່ດີຫຼາຍ.

ການແຈກຢາຍສະສົມເຮັດໃຫ້ບັນຫາທີ່ເຫັນໄດ້ຊັດເຈນຂຶ້ນ:

ເຄິ່ງຫນຶ່ງຂອງການຕອບ DNS ມີ TTL ຂອງ 1 ນາທີຫຼືຫນ້ອຍກວ່າ, ແລະສາມສ່ວນສີ່ມີ TTL ຂອງ 5 ນາທີຫຼືຫນ້ອຍກວ່າ.

ແຕ່ລໍຖ້າ, ມັນຮ້າຍແຮງກວ່າເກົ່າ. ຫຼັງຈາກທີ່ທັງຫມົດ, ນີ້ແມ່ນ TTL ຈາກເຄື່ອງແມ່ຂ່າຍທີ່ມີອໍານາດ. ແນວໃດກໍ່ຕາມ, ຕົວແກ້ໄຂລູກຄ້າ (ເຊັ່ນ: routers, local caches) ໄດ້ຮັບ TTL ຈາກຕົວແກ້ໄຂຂັ້ນຕົ້ນ, ແລະມັນຫຼຸດລົງທຸກໆວິນາທີ.

ດັ່ງນັ້ນ, ລູກຄ້າສາມາດນໍາໃຊ້ແຕ່ລະລາຍການສໍາລັບ, ໂດຍສະເລ່ຍ, ເຄິ່ງຫນຶ່ງຂອງ TTL ຕົ້ນສະບັບກ່ອນທີ່ຈະສົ່ງຄໍາຮ້ອງຂໍໃຫມ່.

ບາງທີ TTL ທີ່ຕໍ່າຫຼາຍເຫຼົ່ານີ້ພຽງແຕ່ນໍາໃຊ້ກັບການຮ້ອງຂໍທີ່ຜິດປົກກະຕິແລະບໍ່ແມ່ນເວັບໄຊທ໌ທີ່ນິຍົມແລະ API? ມາເບິ່ງກັນເລີຍ:

ແກນ X ແມ່ນ TTL, ແກນ Y ແມ່ນຄວາມນິຍົມແບບສອບຖາມ.

ແຕ່ຫນ້າເສຍດາຍ, ຄໍາຖາມທີ່ນິຍົມຫຼາຍທີ່ສຸດແມ່ນຍັງຮ້າຍແຮງທີ່ສຸດທີ່ຈະ cache.

ມາຊູມເຂົ້າ:

ຄໍາຕັດສິນ: ມັນບໍ່ດີແທ້ໆ. ມັນບໍ່ດີກ່ອນ, ແຕ່ມັນຮ້າຍແຮງກວ່າເກົ່າ. DNS caching ໄດ້ກາຍເປັນເກືອບບໍ່ມີປະໂຫຍດ. ຍ້ອນວ່າປະຊາຊົນຫນ້ອຍໃຊ້ຕົວແກ້ໄຂ DNS ຂອງ ISP ຂອງພວກເຂົາ (ສໍາລັບເຫດຜົນທີ່ດີ), ການເພີ່ມຂຶ້ນຂອງການ latency ກາຍເປັນທີ່ສັງເກດເຫັນຫຼາຍ.

DNS caching ໄດ້ກາຍເປັນປະໂຫຍດພຽງແຕ່ສໍາລັບເນື້ອຫາທີ່ບໍ່ມີໃຜໄປຢ້ຽມຢາມ.

ກະລຸນາຮັບຊາບວ່າຊອບແວອາດຈະ ໃນວິທີທີ່ແຕກຕ່າງກັນ ຕີຄວາມຫມາຍ TTL ຕ່ໍາ.

ເປັນຫຍັງມັນຈຶ່ງ?

ເປັນຫຍັງບັນທຶກ DNS ຈຶ່ງຖືກຕັ້ງເປັນ TTL ຕໍ່າດັ່ງກ່າວ?

• ຕົວດຸ່ນດ່ຽງການໂຫຼດແບບເກົ່າຖືກປະໄວ້ດ້ວຍການຕັ້ງຄ່າເລີ່ມຕົ້ນ.
• ມີ myths ວ່າການດຸ່ນດ່ຽງການໂຫຼດ DNS ແມ່ນຂຶ້ນກັບ TTL (ນີ້ບໍ່ແມ່ນຄວາມຈິງ - ນັບຕັ້ງແຕ່ມື້ຂອງ Netscape Navigator, ລູກຄ້າໄດ້ເລືອກທີ່ຢູ່ IP ແບບສຸ່ມຈາກຊຸດຂອງ RRs ແລະພະຍາຍາມຢ່າງໂປ່ງໃສຖ້າພວກເຂົາບໍ່ສາມາດເຊື່ອມຕໍ່ໄດ້)
• ຜູ້ເບິ່ງແຍງລະບົບຕ້ອງການໃຊ້ການປ່ຽນແປງໃນທັນທີ, ສະນັ້ນມັນງ່າຍຂຶ້ນໃນການວາງແຜນ.
• ຜູ້ເບິ່ງແຍງລະບົບເຊີບເວີ DNS ຫຼືຕົວດຸ່ນດ່ຽງການໂຫຼດເຫັນວ່າວຽກງານຂອງລາວເປັນການປະຕິບັດການຕັ້ງຄ່າທີ່ຜູ້ໃຊ້ຮ້ອງຂໍຢ່າງມີປະສິດທິພາບ, ແລະບໍ່ເລັ່ງເວັບໄຊທ໌ແລະການບໍລິການ.
• TTL ຕ່ຳໃຫ້ເຈົ້າສະຫງົບໃຈ.
• ປະຊາຊົນໃນເບື້ອງຕົ້ນກໍານົດ TTLs ຕ່ໍາສໍາລັບການທົດສອບແລະຫຼັງຈາກນັ້ນລືມທີ່ຈະປ່ຽນໃຫ້ເຂົາເຈົ້າ.

ຂ້າພະເຈົ້າບໍ່ໄດ້ລວມເອົາ "failover" ໃນບັນຊີລາຍຊື່ເນື່ອງຈາກວ່າມັນໄດ້ກາຍເປັນຫນ້ອຍແລະຫນ້ອຍທີ່ກ່ຽວຂ້ອງ. ຖ້າທ່ານຕ້ອງການໂອນຜູ້ໃຊ້ໄປຫາເຄືອຂ່າຍອື່ນພຽງແຕ່ສະແດງຫນ້າຂໍ້ຜິດພາດໃນເວລາທີ່ທຸກສິ່ງທຸກຢ່າງອື່ນໄດ້ແຕກ, ການຊັກຊ້າຫຼາຍກວ່າ 1 ນາທີແມ່ນອາດຈະຍອມຮັບໄດ້.

ນອກຈາກນັ້ນ, TTL ຫນຶ່ງນາທີຫມາຍຄວາມວ່າຖ້າເຄື່ອງແມ່ຂ່າຍ DNS ທີ່ຖືກບລັອກເປັນເວລາຫຼາຍກວ່າ 1 ນາທີ, ບໍ່ມີໃຜຈະສາມາດເຂົ້າເຖິງການບໍລິການທີ່ຂຶ້ນກັບ. ແລະການຊໍ້າຊ້ອນຈະບໍ່ຊ່ວຍໄດ້ຖ້າສາເຫດແມ່ນຄວາມຜິດພາດໃນການຕັ້ງຄ່າ ຫຼືການແຮັກ. ໃນທາງກົງກັນຂ້າມ, ດ້ວຍ TTL ທີ່ສົມເຫດສົມຜົນ, ລູກຄ້າຫຼາຍຄົນຈະສືບຕໍ່ນໍາໃຊ້ການຕັ້ງຄ່າທີ່ຜ່ານມາແລະບໍ່ເຄີຍສັງເກດເຫັນຫຍັງເລີຍ.

ການບໍລິການ CDN ແລະການດຸ່ນດ່ຽງການໂຫຼດແມ່ນສ່ວນໃຫຍ່ທີ່ຈະຕໍານິຕິຕຽນສໍາລັບ TTLs ຕ່ໍາ, ໂດຍສະເພາະໃນເວລາທີ່ພວກເຂົາສົມທົບ CNAMEs ກັບ TTLs ຕ່ໍາແລະບັນທຶກທີ່ມີ 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 ຕ່ໍາທີ່ກ່ຽວຂ້ອງ:

$drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 ໃນ CNAME github.map.fastly.net. github.map.fastly.net. 1 ໃນ A 151.101.16.133

ຕົວແກ້ໄຂ Level3 ອາດຈະເຮັດວຽກຢູ່ໃນ 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 ທີ່ເຫມາະສົມ, ແຕ່ມັນບໍ່ມີປະໂຫຍດຢ່າງສົມບູນ. CNAMEs ອື່ນໆມີ 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.

Dropbox?

$drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 ໃນ CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN A 162.125.67.3 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com. 1 ໃນ CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 ໃນ A 162.125.64.3

ໃນ​ການ​ບັນ​ທຶກ​ການ​ safebrowsing.googleapis.com ມູນຄ່າ TTL ແມ່ນ 60 ວິນາທີ, ເຊັ່ນໂດເມນຂອງເຟສບຸກ. ແລະ, ອີກເທື່ອຫນຶ່ງ, ຈາກທັດສະນະຂອງລູກຄ້າ, ມູນຄ່າເຫຼົ່ານີ້ຖືກຫຼຸດລົງເຄິ່ງຫນຶ່ງ.

ແນວໃດກ່ຽວກັບການກໍານົດ TTL ຕໍາ່ສຸດ?

ການນໍາໃຊ້ຊື່, ປະເພດຄໍາຮ້ອງຂໍ, TTL, ແລະເວລາເກັບຮັກສາໄວ້ໃນຕອນຕົ້ນ, ຂ້າພະເຈົ້າໄດ້ຂຽນສະຄິບເພື່ອຈໍາລອງ 1,5 ລ້ານຄໍາຮ້ອງຂໍຜ່ານຕົວແກ້ໄຂຖານຄວາມຈໍາເພື່ອຄາດຄະເນປະລິມານຄໍາຮ້ອງຂໍທີ່ບໍ່ຈໍາເປັນທີ່ສົ່ງເນື່ອງຈາກການເຂົ້າ cache ຫມົດອາຍຸ.

47,4% ຂອງການຮ້ອງຂໍໄດ້ຖືກເຮັດຫຼັງຈາກບັນທຶກທີ່ມີຢູ່ແລ້ວຫມົດອາຍຸ. ນີ້ແມ່ນສູງທີ່ບໍ່ສົມເຫດສົມຜົນ.

ຈະເປັນແນວໃດຜົນກະທົບຕໍ່ການເກັບຂໍ້ມູນຖ້າ TTL ຕໍາ່ສຸດທີ່ຖືກກໍານົດ?

ແກນ X ແມ່ນຄ່າ TTL ຕໍ່າສຸດ. ບັນທຶກທີ່ມີແຫຼ່ງ TTL ຂ້າງເທິງຄ່ານີ້ບໍ່ໄດ້ຮັບຜົນກະທົບ.

ແກນ Y ແມ່ນເປີເຊັນຂອງການຮ້ອງຂໍຈາກລູກຄ້າທີ່ມີການເຂົ້າຖານຄວາມຈໍາແລ້ວ, ແຕ່ມັນຫມົດອາຍຸແລະກໍາລັງເຮັດການຮ້ອງຂໍໃຫມ່.

ສ່ວນແບ່ງຂອງການຮ້ອງຂໍ "ພິເສດ" ແມ່ນຫຼຸດລົງຈາກ 47% ເປັນ 36% ໂດຍພຽງແຕ່ກໍານົດ TTL ຕໍາ່ສຸດທີ່ 5 ນາທີ. ໂດຍກໍານົດ TTL ຕໍາ່ສຸດທີ່ 15 ນາທີ, ຈໍານວນຄໍາຮ້ອງຂໍເຫຼົ່ານີ້ຫຼຸດລົງເຖິງ 29%. TTL ຕໍາ່ສຸດທີ່ 1 ຊົ່ວໂມງເຮັດໃຫ້ພວກເຂົາຫຼຸດລົງເຖິງ 17%. ຄວາມ​ແຕກ​ຕ່າງ​ທີ່​ສໍາ​ຄັນ​!

ແນວໃດກ່ຽວກັບການບໍ່ປ່ຽນແປງສິ່ງໃດໃນດ້ານເຊີຟເວີ, ແຕ່ແທນທີ່ຈະກໍານົດ TTL ຕໍາ່ສຸດທີ່ໃນຖານຄວາມຈໍາ DNS ຂອງລູກຄ້າ (routers, ຕົວແກ້ໄຂທ້ອງຖິ່ນ)?

ຈໍານວນຄໍາຮ້ອງຂໍຫຼຸດລົງຈາກ 47% ເປັນ 34% ດ້ວຍ TTL ຕໍາ່ສຸດທີ່ 5 ນາທີ, ເປັນ 25% ຢ່າງຫນ້ອຍ 15 ນາທີ, ແລະ 13% ຢ່າງຫນ້ອຍ 1 ຊົ່ວໂມງ. ບາງທີ 40 ນາທີແມ່ນດີທີ່ສຸດ.

ຜົນກະທົບຂອງການປ່ຽນແປງຂະຫນາດນ້ອຍນີ້ແມ່ນໃຫຍ່ຫຼວງ.

ຜົນສະທ້ອນແມ່ນຫຍັງ?

ແນ່ນອນ, ການບໍລິການສາມາດຖືກຍ້າຍໄປຢູ່ໃນຜູ້ໃຫ້ບໍລິການຟັງໃຫມ່, ເຄື່ອງແມ່ຂ່າຍໃຫມ່, ເຄືອຂ່າຍໃຫມ່, ຮຽກຮ້ອງໃຫ້ລູກຄ້າໃຊ້ບັນທຶກ DNS ຫຼ້າສຸດ. ແລະ TTL ຂະຫນາດນ້ອຍພໍສົມຄວນຊ່ວຍໃຫ້ການຫັນປ່ຽນດັ່ງກ່າວເປັນໄປໄດ້ຢ່າງຄ່ອງແຄ້ວແລະບໍ່ເຂົ້າໃຈ. ແຕ່ກັບການຫັນປ່ຽນໄປສູ່ໂຄງສ້າງພື້ນຖານໃຫມ່, ບໍ່ມີໃຜຄາດຫວັງວ່າລູກຄ້າຈະຍ້າຍໄປຫາບັນທຶກ DNS ໃຫມ່ພາຍໃນ 1 ນາທີ, 5 ນາທີ, ຫຼື 15 ນາທີ. ການຕັ້ງຄ່າ TTL ຕໍາ່ສຸດທີ່ 40 ນາທີແທນທີ່ຈະເປັນ 5 ນາທີຈະບໍ່ປ້ອງກັນຜູ້ໃຊ້ຈາກການເຂົ້າເຖິງການບໍລິການ.

ຢ່າງໃດກໍ່ຕາມ, ນີ້ຈະຫຼຸດຜ່ອນຄວາມລ່າຊ້າຢ່າງຫຼວງຫຼາຍແລະປັບປຸງຄວາມເປັນສ່ວນຕົວແລະຄວາມຫນ້າເຊື່ອຖືໂດຍການຫຼີກເວັ້ນການຮ້ອງຂໍທີ່ບໍ່ຈໍາເປັນ.

ແນ່ນອນ, RFCs ເວົ້າວ່າ TTL ຕ້ອງໄດ້ຮັບການປະຕິບັດຕາມຢ່າງເຂັ້ມງວດ. ແຕ່ຄວາມເປັນຈິງແມ່ນວ່າລະບົບ DNS ໄດ້ກາຍເປັນຄວາມບໍ່ມີປະສິດທິພາບເກີນໄປ.

ຖ້າທ່ານກໍາລັງເຮັດວຽກກັບເຄື່ອງແມ່ຂ່າຍ DNS ທີ່ມີອໍານາດ, ກະລຸນາກວດເບິ່ງ TTLs ຂອງທ່ານ. ເຈົ້າຕ້ອງການຄຸນຄ່າທີ່ຕໍ່າທີ່ຂີ້ຄ້ານແທ້ໆບໍ?

ແນ່ນອນ, ມີເຫດຜົນທີ່ດີທີ່ຈະກໍານົດ TTLs ຂະຫນາດນ້ອຍສໍາລັບບັນທຶກ DNS. ແຕ່ບໍ່ແມ່ນສໍາລັບ 75% ຂອງການຈະລາຈອນ DNS ທີ່ຍັງຄົງບໍ່ປ່ຽນແປງ.

ແລະຖ້າສໍາລັບເຫດຜົນບາງຢ່າງທີ່ເຈົ້າຕ້ອງໃຊ້ TTL ຕ່ໍາສໍາລັບ DNS, ໃນເວລາດຽວກັນໃຫ້ແນ່ໃຈວ່າເວັບໄຊທ໌ຂອງທ່ານບໍ່ໄດ້ເປີດໃຊ້ cache. ສໍາລັບເຫດຜົນດຽວກັນ.

ຖ້າທ່ານມີແຄດ DNS ທ້ອງຖິ່ນທີ່ເຮັດວຽກ, ເຊັ່ນ: dnscrypt-proxyເຊິ່ງອະນຸຍາດໃຫ້ທ່ານຕັ້ງ TTL ຕໍາ່ສຸດທີ່, ໃຊ້ຟັງຊັນນີ້. ນີ້ແມ່ນດີ. ບໍ່ມີຫຍັງທີ່ບໍ່ດີຈະເກີດຂຶ້ນ. ຕັ້ງ TTL ຕໍາ່ສຸດທີ່ປະມານ 40 ນາທີ (2400 ວິນາທີ) ແລະ 1 ຊົ່ວໂມງ. ຂ້ອນຂ້າງເປັນຂອບເຂດທີ່ສົມເຫດສົມຜົນ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com