วิธีแก้ไขการค้นหา DNS ที่ช้า

การค้นหา DNS ที่ช้าทำให้เกิดความล่าช้าที่ไม่จำเป็นก่อนที่เบราว์เซอร์ของคุณจะเริ่มโหลดหน้าเว็บ การแก้ไข DNS ทั่วไปใช้เวลา 20–120 มิลลิวินาที แต่ DNS ที่กำหนดค่าผิดหรือทำงานไม่ดีสามารถผลักดันให้เกิน 100 มิลลิวินาที — บางครั้งเข้าสู่ดินแดนหลายวินาที เวลาในการค้นหา DNS ส่งผลโดยตรงต่อเวลาในการรับไบต์แรก (TTFB) ซึ่งเป็นเมตริก Core Web Vitals การวิจัยของ Google แสดงให้เห็นว่าความน่าจะเป็นในการเด้งเพิ่มขึ้นจาก 32% ที่ 3 วินาทีเป็น 90% ที่ 5 วินาทีในการโหลดหน้า ข่าวดี: สาเหตุส่วนใหญ่สามารถวินิจฉัยและแก้ไขได้ง่าย.

สารบัญ

1. สาเหตุของ DNS ช้า
2. ขั้นตอนที่ 1: วินิจฉัยปัญหา
3. ขั้นตอนที่ 2: รีสตาร์ทฮาร์ดแวร์ของคุณ
4. ขั้นตอนที่ 3: เปลี่ยนไปใช้ผู้ให้บริการ DNS ที่เร็วกว่า
5. ขั้นตอนที่ 4: ล้างแคช DNS ของคุณ
6. ขั้นตอนที่ 5: แก้ไขความล่าช้าของการย้อนกลับ IPv6
7. ขั้นตอนที่ 6: ตรวจสอบ VPN, Antivirus & Ghost Adapters
8. ขั้นตอนที่ 7: กำหนดค่า DNS ผ่าน HTTPS (DoH)
9. ขั้นตอนที่ 8: รันเซิร์ฟเวอร์แคช DNS ในเครื่อง
10. ขั้นตอนที่ 9: แก้ไขปัญหา DNS ที่เฉพาะเจาะจงกับเบราว์เซอร์
11. ขั้นตอนที่ 10: ปรับปรุงบันทึก DNS (เจ้าของเว็บไซต์)
12. ขั้นตอนที่ 11: ลดโดเมนของบุคคลที่สาม (เจ้าของเว็บไซต์)
13. ขั้นตอนที่ 12: ใช้การดึงข้อมูลล่วงหน้า DNS (นักพัฒนาเว็บ)
14. ตารางการแก้ไขปัญหาอ้างอิงด่วน

สาเหตุของ DNS ช้า

ปัจจัยหลายอย่างที่มีส่วนทำให้เกิดความล่าช้าของ DNS:

• เซิร์ฟเวอร์ DNS ที่ให้บริการโดย ISP ช้า — ตัวแก้ไขค่าเริ่มต้นจาก ISP ของคุณมักจะช้ากว่าทางเลือกสาธารณะอย่างมาก DNS ฟรีจากผู้รับจดทะเบียนเช่น GoDaddy และ Namecheap ก็มักจะช้าเช่นกัน.
• ระยะทางทางภูมิศาสตร์ — ยิ่งเซิร์ฟเวอร์ DNS อยู่ไกลจากคุณมากเท่าใด การเดินทางไปกลับก็จะยิ่งนานขึ้นเท่านั้น.
• ความล่าช้าของการย้อนกลับ IPv6 — ระบบปฏิบัติการสมัยใหม่ให้ความสำคัญกับการค้นหา IPv6 (AAAA) หาก ISP ของคุณมีการสนับสนุน IPv6 ที่ไม่ดี อุปกรณ์ของคุณจะหยุดทำงานนานถึง 5 วินาทีก่อนที่จะย้อนกลับไปยัง IPv4.
• บันทึก DNS ที่มากเกินไป — บันทึก A, CNAME และ TXT ที่ไม่ได้ใช้งานหรือเก่าจะเพิ่มภาระให้กับการค้นหา.
• การเชื่อมโยง CNAME — การเปลี่ยนเส้นทางหลายครั้ง (CNAME → CNAME → บันทึก A) บังคับให้ค้นหาตามลำดับซึ่งเพิ่มความล่าช้า.
• ไม่มีการแคช DNS — หากไม่มีการแคช คำค้นหา DNS เดียวกันจะทำซ้ำทุกครั้งที่โหลดหน้า.
• เซิร์ฟเวอร์ชื่อที่มีภาระมากเกินไป — ผู้ให้บริการโฮสติ้งที่มีเซิร์ฟเวอร์ชื่อที่จัดเตรียมไว้น้อยเกินไปทำให้เกิดความล่าช้า.
• ความแออัดของเครือข่ายและการกำหนดเส้นทางที่ไม่เหมาะสม — แม้แต่เซิร์ฟเวอร์ที่อยู่ใกล้เคียงก็อาจช้าได้หากเส้นทางไปถึงนั้นแออัด.
• การแทรกแซง VPN และพร็อกซี — VPN จะกำหนดเส้นทาง DNS ผ่านเซิร์ฟเวอร์ของตนเอง ซึ่งอาจช้ากว่า บางตัวรั่วไหลคำค้นหา DNS ออกนอกอุโมงค์.
• อะแดปเตอร์เครือข่ายผี — อะแดปเตอร์ผีจากซอฟต์แวร์ VPN เครื่องเสมือน หรือ Docker มีการกำหนดค่า DNS ที่ค้างซึ่งรบกวนการแก้ไข.
• การกรอง DNS ของ Antivirus/firewall — ซอฟต์แวร์รักษาความปลอดภัยบางตัว (Norton, Kaspersky, Bitdefender) สกัดกั้นคำค้นหา DNS เพิ่มความล่าช้า.
• การแทนที่ DNS ระดับเบราว์เซอร์ — Chrome, Firefox และ Edge สามารถแทนที่การตั้งค่า DNS ของระบบปฏิบัติการของคุณอย่างเงียบๆ ด้วยการกำหนดค่า DNS ผ่าน HTTPS (DoH) ในตัวของพวกเขาเอง.
• โดเมนของบุคคลที่สามมากเกินไป — แต่ละโดเมนที่ไม่ซ้ำกันที่เว็บไซต์ของคุณโหลดต้องการการค้นหา DNS แยกต่างหากซึ่งเพิ่มเวลาในการโหลดหน้าเว็บทั้งหมด.
• ไม่มีการกำหนดค่า DNS รอง — หากไม่มีเซิร์ฟเวอร์ DNS สำรอง ระบบจะหยุดรอการหมดเวลาหากเซิร์ฟเวอร์หลักล่มหรือช้า.

ขั้นตอนที่ 1: วินิจฉัยปัญหา

ก่อนจะแก้ไขอะไร ให้ยืนยันว่า DNS เป็นคอขวดจริงๆ.

การใช้ dig (Linux/macOS)

การ คำสั่ง dig เป็นเครื่องมือหลักในการวัดเวลาในการตอบสนองของ DNS:

1. สอบถามเซิร์ฟเวอร์ DNS เฉพาะและตรวจสอบเวลาในการตอบสนอง
dig example.com @8.8.8.8

2. การติดตามแบบเต็มแสดงความล่าช้าของแต่ละฮอป
dig example.com +trace

ผลลัพธ์ประกอบด้วย เวลาในการค้นหา ฟิลด์ (เช่น 34 มิลลิวินาที) หากเกิน 100 มิลลิวินาที ชั้น DNS เป็นปัญหาด้านประสิทธิภาพ ในอุดมคติแล้ว ควรตั้งเป้าให้ต่ำกว่า 50 มิลลิวินาที.

การใช้ nslookup (Windows)

สำหรับผู้ใช้ Windows, nslookup เป็นเครื่องมือวินิจฉัย DNS เริ่มต้น:

1. การค้นหา DNS พื้นฐาน
nslookup example.com

2. สอบถามเซิร์ฟเวอร์ DNS เฉพาะ
nslookup example.com 8.8.8.8

3. ตรวจสอบเซิร์ฟเวอร์ชื่อสำหรับโดเมน
nslookup -type=ns example.com

หาก nslookup ส่งคืนผลลัพธ์อย่างรวดเร็วแต่การท่องเว็บรู้สึกช้า ปัญหาน่าจะเป็น DNS ระดับเบราว์เซอร์ การย้อนกลับ IPv6 หรือการแทรกแซง VPN — ไม่ใช่เซิร์ฟเวอร์ DNS เอง.

การใช้ ping และ traceroute

ทดสอบความล่าช้าของเครือข่ายดิบไปยังเซิร์ฟเวอร์ DNS ของคุณเพื่อแยกปัญหาเครือข่ายออกจากปัญหาแอปพลิเคชัน DNS:

1. Linux/macOS
ping -c 3 8.8.8.8
traceroute 8.8.8.8

2. Windows
ping 8.8.8.8
tracert 8.8.8.8

หาก ping แสดงความล่าช้าสูงแต่ คำสั่ง dig ไปยังเซิร์ฟเวอร์เดียวกันช้าเป็นสัดส่วน ปัญหาคือระยะทางเครือข่าย ไม่ใช่เซิร์ฟเวอร์ DNS เอง.

เครื่องมือวัดประสิทธิภาพ DNS

• GRC DNS Benchmark — ยูทิลิตี้ Windows ที่ทดสอบเซิร์ฟเวอร์ DNS หลายสิบเซิร์ฟเวอร์และจัดอันดับตามความเร็วจากตำแหน่งของคุณ แนะนำอย่างยิ่งสำหรับการค้นหาตัวแก้ไขที่เร็วที่สุดสำหรับเครือข่ายเฉพาะของคุณ.
• Namebench — เครื่องมือที่ Google เป็นเจ้าของที่ค้นหาเซิร์ฟเวอร์ DNS ที่เร็วที่สุดที่มีให้สำหรับคอมพิวเตอร์ของคุณ.
• DNSPerf — เครื่องมือโอเพ่นซอร์สสำหรับวัดประสิทธิภาพเซิร์ฟเวอร์ DNS ที่มีอำนาจภายใต้โหลด.
• dnsdiag (dnsping, dnstraceroute, dnseval) — ชุดเครื่องมือ Python สำหรับการวัด DNS ติดตั้งผ่าน pip3 install dnsdiag.
• dnsspeedtest.site — เครื่องมือที่ใช้เบราว์เซอร์ที่วัดประสิทธิภาพผู้ให้บริการ DNS กว่า 20 รายโดยใช้ DNS ผ่าน HTTPS โดยไม่ต้องติดตั้งซอฟต์แวร์.

ขั้นตอนที่ 2: รีสตาร์ทฮาร์ดแวร์ของคุณ

การแก้ไขที่ง่ายที่สุดที่มักถูกมองข้าม การรีสตาร์ทเราเตอร์ของคุณจะล้างแคช DNS ภายในและสามารถแก้ไขปัญหาการกำหนดเส้นทางได้ เราเตอร์ ISP หลายตัวมีตัวส่งต่อ DNS ในตัวที่อาจมีภาระมากเกินไปหรือค้างเมื่อเวลาผ่านไป.

• ถอดปลั๊กเราเตอร์ของคุณเป็นเวลา 30 วินาที จากนั้นเสียบกลับเข้าไปใหม่.
• รีสตาร์ทพีซี โทรศัพท์ หรือแท็บเล็ตของคุณ.
• หากใช้โมเด็มแยกต่างหาก ให้รีสตาร์ทด้วย.

สิ่งนี้จะล้างข้อบกพร่องชั่วคราวและบังคับให้มีการเชื่อมต่อ DNS ใหม่ ลองทำสิ่งนี้ก่อนการแก้ไขอื่นๆ.

ขั้นตอนที่ 3: เปลี่ยนไปใช้ผู้ให้บริการ DNS ที่เร็วกว่า

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

หมายเหตุเกี่ยวกับ Cloudflare กับ Google: การวิจัยโดย ThousandEyes พบว่า Cloudflare ให้การแก้ไข DNS เทียบเท่ากับเซิร์ฟเวอร์ ISP (เฉลี่ย 23.4 มิลลิวินาที) ในขณะที่ Google เฉลี่ย 48.8 มิลลิวินาที อย่างไรก็ตาม การสนับสนุน EDNS Client Subnet ของ Google สามารถปรับปรุงอัตราการเข้าชมแคชของ CDN ได้ เลือกตามลำดับความสำคัญของคุณ: ความเร็วดิบ (Cloudflare) หรือการเพิ่มประสิทธิภาพ CDN (Google).

วิธีเปลี่ยน DNS บน Windows

เปิดการตั้งค่า → เครือข่ายและอินเทอร์เน็ต → อีเทอร์เน็ต (หรือ Wi-Fi) คลิกแก้ไขถัดจากการกำหนดเซิร์ฟเวอร์ DNS สลับเป็นคู่มือ เปิดใช้งาน IPv4 และป้อนที่อยู่ DNS ที่คุณต้องการ.

อีกทางหนึ่ง ผ่าน Command Prompt:

netsh interface ip add dns name=”Ethernet” addr=1.1.1.1 index=1
netsh interface ip add dns name=”Ethernet” addr=1.0.0.1 index=2

วิธีเปลี่ยน DNS บน macOS/Linux

บน macOS ไปที่การตั้งค่าระบบ → เครือข่าย → การเชื่อมต่อของคุณ → DNS และเพิ่ม IP ของตัวแก้ไข บน Linux แก้ไข /etc/resolv.conf หรือกำหนดค่าผ่านตัวจัดการเครือข่ายของคุณ:

1. Linux: แก้ไข /etc/resolv.conf
sudo nano /etc/resolv.conf

2. เพิ่มบรรทัดเหล่านี้:
nameserver 1.1.1.1
nameserver 1.0.0.1

เปลี่ยน DNS บนเราเตอร์ของคุณ

สำหรับการเปลี่ยนแปลงทั่วทั้งเครือข่าย ให้ปรับปรุงการตั้งค่า DNS ในแผงผู้ดูแลระบบของเราเตอร์ของคุณ (โดยปกติที่ 192.168.1.1 หรือ 192.168.0.1) สิ่งนี้มีผลกับอุปกรณ์ทั้งหมดบนเครือข่าย — คุณกำหนดค่าเพียงครั้งเดียวแทนที่จะเป็นทุกอุปกรณ์.

ขั้นตอนที่ 4: ล้างแคช DNS ของคุณ

รายการแคชที่ค้างหรือเสียหายอาจทำให้การแก้ไขล้มเหลวหรือเปลี่ยนเส้นทางไปยัง IP ที่ไม่ถูกต้อง การล้างบังคับให้มีการค้นหาใหม่:

อย่าลืมแคชระดับเบราว์เซอร์ ใน Chrome ไปที่ chrome://net-internals/#dns และคลิก “ล้างแคชโฮสต์” ใน Firefox แคช DNS จะถูกล้างเมื่อคุณรีสตาร์ทเบราว์เซอร์หรือสามารถล้างได้ผ่าน about:networking#dns.

ขั้นตอนที่ 5: แก้ไขความล่าช้าของการย้อนกลับ IPv6

นี่เป็นหนึ่งในสาเหตุที่ซ่อนอยู่ทั่วไปของ DNS ช้าที่คู่มือมาตรฐานมองข้าม ระบบปฏิบัติการสมัยใหม่ให้ความสำคัญกับการค้นหา IPv6 (AAAA) มากกว่า IPv4 หาก ISP ของคุณมีการสนับสนุน IPv6 ที่ไม่ดีหรือไม่มีเลย อุปกรณ์ของคุณจะรอการตอบกลับ IPv6 นานถึง 5 วินาทีก่อนที่จะย้อนกลับไปยัง IPv4 สิ่งนี้เกิดขึ้นทุกการเชื่อมต่อใหม่.

วิธีวินิจฉัย

1. ทดสอบการเชื่อมต่อ IPv6
ping -6 google.com

2. หากหมดเวลาหรือใช้เวลาหลายวินาที IPv6 คือปัญหา
3. เปรียบเทียบกับ IPv4:
ping -4 google.com

วิธีแก้ไข

ตัวเลือกที่ 1: ปิดใช้งาน IPv6 บนอะแดปเตอร์เครือข่าย (หาก ISP ของคุณไม่รองรับ)

• Windows: คุณสมบัติอะแดปเตอร์เครือข่าย → ยกเลิกการเลือก “Internet Protocol Version 6 (TCP/IPv6)”
• Linux: เพิ่ม net.ipv6.conf.all.disable_ipv6 = 1 เป็น /etc/sysctl.conf
• macOS: การตั้งค่าระบบ → เครือข่าย → การเชื่อมต่อของคุณ → TCP/IP → กำหนดค่า IPv6 → ลิงก์เฉพาะท้องถิ่น

ตัวเลือกที่ 2: ให้ความสำคัญกับ IPv4 โดยไม่ต้องปิดใช้งาน IPv6 อย่างสมบูรณ์ — บน Linux แก้ไข /etc/gai.conf และยกเลิกการแสดงความคิดเห็น precedence ::ffff:0:0/96 100.

ขั้นตอนที่ 6: ตรวจสอบ VPN, Antivirus & Ghost Adapters

การแทรกแซง DNS ของ VPN และ Proxy

VPN มักจะกำหนดเส้นทาง DNS ผ่านเซิร์ฟเวอร์ของตนเอง ซึ่งอาจช้ากว่าตัวแก้ไขในเครื่องของคุณ VPN บางตัวยังรั่วไหลคำค้นหา DNS ออกนอกอุโมงค์ ทำให้เกิดพฤติกรรมที่ไม่สอดคล้องกัน ในการวินิจฉัย:

• เยี่ยมชม dnsleaktest.com ในขณะที่เชื่อมต่อกับ VPN ของคุณเพื่อตรวจสอบการรั่วไหลของ DNS.
• ตัดการเชื่อมต่อ VPN ชั่วคราวและทดสอบความเร็ว DNS หากเร็วกว่าโดยไม่มี VPN DNS ของ VPN ของคุณคือคอขวด.
• VPN หลายตัวอนุญาตให้คุณกำหนดค่าเซิร์ฟเวอร์ DNS ที่กำหนดเอง — ใช้ Cloudflare หรือ Google แทน DNS ของผู้ให้บริการ VPN.

การกรอง DNS ของ Antivirus / Firewall

ซอฟต์แวร์ป้องกันไวรัสบางตัว (Norton, Kaspersky, Bitdefender) สกัดกั้นและกรองคำค้นหา DNS เพิ่มความล่าช้า ไฟร์วอลล์รักษาความปลอดภัยยังสามารถบล็อกหรือควบคุมการรับส่งข้อมูล DNS ไปยังเซิร์ฟเวอร์ที่ไม่รู้จักได้อีกด้วย ในการทดสอบ:

• ปิดการป้องกันเว็บป้องกันไวรัสของคุณชั่วคราวและทดสอบความเร็ว DNS.
• ตรวจสอบกฎไฟร์วอลล์ของคุณสำหรับการบล็อกที่เกี่ยวข้องกับ DNS (พอร์ตขาออก 53 หรือ 853).
• หาก DNS เร็วขึ้นเมื่อปิดใช้งานแอนตี้ไวรัส ให้เพิ่มข้อยกเว้นสำหรับเซิร์ฟเวอร์ DNS ที่คุณต้องการ.

อะแดปเตอร์เครือข่ายผี

อะแดปเตอร์เครือข่ายเก่าหรือผีจากซอฟต์แวร์ VPN เครื่องเสมือน (VMware, VirtualBox) หรือ Docker สามารถเก็บการกำหนดค่า DNS ที่ค้างซึ่งรบกวนการแก้ไขได้ Windows มีแนวโน้มที่จะเกิดปัญหานี้เป็นพิเศษ.

แก้ไขบน Windows:

1. แสดงอุปกรณ์ที่ซ่อนอยู่ในตัวจัดการอุปกรณ์
2. เปิด CMD ในฐานะผู้ดูแลระบบ:
set devmgr_show_nonpresent_devices=1
devmgmt.msc

3. ในตัวจัดการอุปกรณ์: ดู → แสดงอุปกรณ์ที่ซ่อนอยู่
4. ภายใต้อะแดปเตอร์เครือข่าย ให้ลบอะแดปเตอร์ที่เป็นสีเทา/ผี

ขั้นตอนที่ 7: กำหนดค่า DNS ผ่าน HTTPS (DoH)

DNS ผ่าน HTTPS (DoH) เข้ารหัสคำค้นหา DNS ภายใน HTTPS ป้องกันการสอดแนมของ ISP การปลอมแปลง DNS และการโจมตีแบบคนกลาง อย่างไรก็ตาม อาจทำให้เกิดปัญหาได้หากกำหนดค่าผิด.

ประโยชน์

• เข้ารหัสการรับส่งข้อมูล DNS — ISP และผู้ดูแลระบบเครือข่ายไม่สามารถดูคำค้นหา DNS ของคุณได้.
• ป้องกันการปลอมแปลง DNS และการโจมตีด้วยการวางยาพิษในแคช.
• ใช้พอร์ต 443 (HTTPS มาตรฐาน) ดังนั้นจึงไม่ค่อยถูกบล็อกโดยไฟร์วอลล์.

ปัญหาที่อาจเกิดขึ้น

• เพิ่มความล่าช้า: การจับมือ HTTPS/TLS เพิ่มภาระในครั้งแรกที่เชื่อมต่อ คำค้นหาครั้งต่อไปจะเร็วขึ้นเนื่องจากการใช้การเชื่อมต่อซ้ำ.
• ขัดแย้งกับตัวกรอง DNS ในเครื่อง: DoH จะข้าม Pi-hole เซิร์ฟเวอร์ DNS ในเครื่อง และการควบคุมโดยผู้ปกครอง.
• ความขัดแย้งของ VPN: DoH สามารถกำหนดเส้นทาง DNS ออกนอกอุโมงค์ VPN หากไม่ได้กำหนดค่าอย่างถูกต้อง.
• ปัญหา DNS แยก: สภาพแวดล้อมขององค์กรที่ใช้ DNS ภายในสำหรับทรัพยากรในเครื่องอาจพังเมื่อเปิดใช้งาน DoH.
• การแทนที่เบราว์เซอร์: Chrome, Firefox และ Edge มี DoH ในตัวที่สามารถแทนที่การตั้งค่า DNS ของระบบปฏิบัติการของคุณได้อย่างเงียบๆ.

วิธีเปิดใช้งาน DoH

Windows 11: การตั้งค่า → เครือข่าย → อีเทอร์เน็ต/ไวไฟ → DNS → ตั้งค่า “การเข้ารหัส DNS ที่ต้องการ” เป็น “เข้ารหัสเท่านั้น (DNS ผ่าน HTTPS)” หรือ “เข้ารหัสที่ต้องการ อนุญาตให้ไม่เข้ารหัส”

Chrome/Edge: การตั้งค่า → ความเป็นส่วนตัว → “ใช้ DNS ที่ปลอดภัย” → เลือกผู้ให้บริการ (Cloudflare, Google ฯลฯ).

Firefox: การตั้งค่า → ความเป็นส่วนตัวและความปลอดภัย → “เปิดใช้งาน DNS ผ่าน HTTPS” → เลือกผู้ให้บริการ Firefox ตั้งค่าเริ่มต้นเป็น Cloudflare สำหรับผู้ใช้ในสหรัฐอเมริกา.

วิธีปิดใช้งาน DoH (เมื่อแก้ไขปัญหา)

• วินโดวส์ 11: เปลี่ยนการเข้ารหัส DNS กลับไปเป็น “ไม่เข้ารหัสเท่านั้น”
• โครม/เอดจ์: สลับ “ใช้ DNS ที่ปลอดภัย” เป็น ปิด.
• ไฟร์ฟอกซ์: ตั้งค่าเป็น “ปิด” หรือพิมพ์ about:config และตั้งค่า network.trr.mode = 5.

DNS over TLS (DoT) vs DoH

DoT เป็นทางเลือกที่เข้ารหัส DNS บนพอร์ตเฉพาะ (853) แทนที่จะผสมกับการจราจร HTTPS บนพอร์ต 443 DoT ง่ายต่อการระบุและบล็อก/จัดการบนเครือข่ายองค์กร DoH ผสมผสานกับการจราจรเว็บปกติ ทำให้ยากต่อการกรอง สำหรับผู้ใช้ที่บ้าน ทั้งสองใช้ได้ สำหรับผู้ดูแลเครือข่ายที่ต้องการการมองเห็น DoT มักจะเป็นที่นิยม.

ขั้นตอนที่ 8: รันเซิร์ฟเวอร์แคช DNS ในเครื่อง

สำหรับผู้ใช้ที่มีความรู้และผู้ดูแลเครือข่าย การรันตัวแก้ไข DNS แคชในเครื่องจะกำจัดการเดินทางไปกลับทั้งหมดสำหรับการค้นหาซ้ำ แทนที่จะเข้าถึงเซิร์ฟเวอร์ DNS ระยะไกลทุกครั้ง แคชในเครื่องของคุณจะตอบสนองทันที.

ตัวเลือกยอดนิยม

• Unbound — ตัวแก้ไข DNS ที่ตรวจสอบความถูกต้อง, ทำซ้ำ, และแคช ป้องกันไม่ให้เซิร์ฟเวอร์ DNS สาธารณะเดียวมีบันทึกทั้งหมดของคุณ รองรับ DoT สำหรับการเข้ารหัสต้นน้ำ.
• dnsmasq — ตัวส่งต่อ DNS น้ำหนักเบาและเซิร์ฟเวอร์ DHCP ตั้งค่าง่ายบนเราเตอร์ลินุกซ์.
• Pi-hole — ตัวบล็อกโฆษณาทั่วทั้งเครือข่ายที่ทำหน้าที่เป็นแคช DNS ด้วย บล็อกโฆษณาและตัวติดตามในระดับ DNS ลดการค้นหา DNS บุคคลที่สามสำหรับอุปกรณ์ทั้งหมด.

การตั้งค่าอย่างรวดเร็ว: Unbound บนลินุกซ์

# ติดตั้ง Unbound
sudo apt install unbound

# การตั้งค่าพื้นฐาน: /etc/unbound/unbound.conf
server:
    interface: 127.0.0.1
    port: 53
    access-control: 127.0.0.0/8 allow
    cache-min-ttl: 300
    cache-max-ttl: 86400
    prefetch: yes

# ส่งต่อไปยัง Cloudflare ผ่าน TLS
forward-zone:
    name: “.”
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853
    forward-addr: 1.0.0.1@853

# เริ่มและเปิดใช้งาน
sudo systemctl enable unbound
sudo systemctl start unbound

# ตั้งค่าระบบของคุณให้ใช้ตัวแก้ไขในเครื่อง
# แก้ไข /etc/resolv.conf:
nameserver 127.0.0.1

ด้วย prefetch: yes, Unbound จะรีเฟรชบันทึกที่เข้าถึงบ่อยก่อนที่จะหมดอายุ ดังนั้นคุณแทบจะไม่เคยพบกับการพลาดแคชเย็น.

ขั้นตอนที่ 9: แก้ไขปัญหา DNS ที่เฉพาะเจาะจงกับเบราว์เซอร์

เบราว์เซอร์มีพฤติกรรม DNS ของตัวเองที่สามารถแทนที่การตั้งค่า OS ของคุณ:

โครม / เอดจ์

• “Secure DNS” (DoH) ในตัวสามารถแทนที่ DNS ระดับ OS ตรวจสอบ: การตั้งค่า → ความเป็นส่วนตัว → “ใช้ DNS ที่ปลอดภัย”
• โครมมีแคช DNS ของตัวเอง ล้างที่ chrome://net-internals/#dns → “ล้างแคชโฮสต์”
• นอกจากนี้ยังล้างกลุ่มซ็อกเก็ต: chrome://net-internals/#sockets → “ล้างกลุ่มซ็อกเก็ต”

ไฟร์ฟอกซ์

• ไฟร์ฟอกซ์มี Trusted Recursive Resolver (TRR) ของตัวเองที่ตั้งค่าเริ่มต้นเป็น Cloudflare DoH สำหรับผู้ใช้ในสหรัฐฯ ซึ่งจะข้ามการตั้งค่า DNS ของ OS ของคุณโดยสิ้นเชิง.
• ตรวจสอบสถานะ: about:networking#dns เพื่อดูรายการ DNS ที่แคชไว้และตัวแก้ไขที่ใช้งานอยู่.
• เพื่อปิด TRR: การตั้งค่า → ความเป็นส่วนตัวและความปลอดภัย → DNS ผ่าน HTTPS → ปิด.
• เพื่อบังคับปิดผ่านการตั้งค่า: about:config → ตั้งค่า network.trr.mode เป็น 5.

เบราว์เซอร์ทั้งหมด

• ส่วนขยาย (ตัวบล็อกโฆษณา, เครื่องมือความเป็นส่วนตัว) สามารถสกัดกั้นและเปลี่ยนเส้นทาง DNS ทดสอบในโหมดไม่ระบุตัวตน/ส่วนตัวโดยปิดใช้งานส่วนขยาย.
• หาก DNS ทำงานผ่าน คำสั่ง dig หรือ nslookup แต่เบราว์เซอร์ช้า ปัญหาอยู่ที่ระดับเบราว์เซอร์ — ไม่ใช่ DNS ของระบบ.

ขั้นตอนที่ 10: ปรับปรุงบันทึก DNS (เจ้าของเว็บไซต์)

หากคุณจัดการเว็บไซต์และ DNS ของมันช้าสำหรับผู้เยี่ยมชม การปรับแต่งเหล่านี้ใช้ได้:

ลดและล้างบันทึก

ลบบันทึก A, CNAME, TXT, และ MX ที่ไม่ได้ใช้ ทุกบันทึกเพิ่มเติมเพิ่มภาระในระหว่างการแก้ไข ตรวจสอบไฟล์โซน DNS ของคุณทุกไตรมาส.

กำจัดการเชื่อมโยง CNAME

แทนที่จะเป็น CNAME → CNAME → บันทึก A ให้ชี้โดเมนไปยัง IP สุดท้ายผ่านบันทึก A ผู้ให้บริการ DNS หลายรายยังรองรับ การแบน CNAME (เรียกอีกอย่างว่าบันทึก ALIAS) ซึ่งแก้ไขการเชื่อมโยงที่ฝั่งเซิร์ฟเวอร์และส่งคืน IP ในการค้นหาเดียว.

ตั้งค่าค่า TTL ที่เหมาะสม

• บันทึกที่เสถียร: ใช้ TTL ที่สูงกว่า (3600–86400 วินาที) เพื่อเพิ่มประโยชน์การแคชสูงสุด.
• บันทึกที่เปลี่ยนบ่อย: ใช้ TTL 300–600 วินาที (5–10 นาที).
• หลีกเลี่ยงการตั้งค่า TTL เป็น 86400 (24 ชั่วโมง) เว้นแต่บันทึกจะไม่เปลี่ยนแปลงเลย เนื่องจากจะทำให้การเผยแพร่การอัปเดตล่าช้า.

ข้อพิจารณา DNSSEC

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

ใช้ผู้ให้บริการ DNS ระดับพรีเมียม / CDN

DNS ฟรีจากผู้จดทะเบียนโดเมนมักจะช้า ผู้ให้บริการ DNS ระดับพรีเมียม (Cloudflare, AWS Route 53, Dyn, DNS Made Easy) มีโครงสร้างพื้นฐาน anycast ที่กระจายทั่วโลกขนาดใหญ่ที่ออกแบบมาเพื่อตอบสนองความหน่วงต่ำ CDN เช่น Cloudflare หรือ Akamai มีโครงสร้างพื้นฐาน DNS ของตัวเองพร้อมจุดแสดงที่กระจายทั่วโลก ลดเวลาในการค้นหาสำหรับผู้ใช้ทั่วโลก.

ขั้นตอนที่ 11: ลดโดเมนของบุคคลที่สาม (เจ้าของเว็บไซต์)

แต่ละโดเมนบุคคลที่สามที่ไม่ซ้ำกันที่เว็บไซต์ของคุณโหลดต้องการการค้นหา DNS แยกต่างหาก สิ่งเหล่านี้เพิ่มขึ้นอย่างรวดเร็ว — เว็บไซต์ที่โหลดทรัพยากรจาก 7 โดเมนภายนอกสามารถสะสมเวลากว่า 1 วินาทีของ DNS เพียงอย่างเดียว.

วิธีลด

• ตรวจสอบทรัพยากรภายนอก: ใช้เครื่องมือพัฒนาเบราว์เซอร์ (แท็บเครือข่าย) หรือ WebPageTest เพื่อระบุทุกโดเมนที่ไม่ซ้ำกันที่เว็บไซต์ของคุณเรียก.
• โฮสต์เองเมื่อเป็นไปได้: ดาวน์โหลดฟอนต์, สคริปต์, และทรัพย์สินบุคคลที่สามและโฮสต์บนเซิร์ฟเวอร์ต้นทางหรือ CDN ของคุณ สิ่งนี้กำจัดการค้นหา DNS ของพวกเขาโดยสิ้นเชิง.
• รวมโดเมน CDN: ใช้โดเมนย่อย CDN เดียวแทนหลายโฮสต์ภายนอก.
• ลบปลั๊กอินและตัวติดตามที่ไม่ได้ใช้: ปลั๊กอินแต่ละตัวที่โหลด JavaScript ภายนอกเพิ่มการค้นหา DNS อย่างน้อยหนึ่งครั้งพร้อมกับสคริปต์เอง.

เลื่อนการโหลด JavaScript ที่ไม่สำคัญ

JavaScript บุคคลที่สามมักจะโหลดโดเมนภายนอกเพิ่มเติม การเลื่อนการโหลด JS ที่ไม่สำคัญจะทำให้การค้นหา DNS เหล่านั้นล่าช้าจนกว่าหน้าหลักจะเรนเดอร์:

<!– Defer non-critical third-party scripts –>
<script src=”https://analytics.example.com/tracker.js” defer></script>

<!– Async for scripts that don’t depend on page load order –>
<script src=”https://ads.example.com/ad.js” async></script>

การใช้ เลื่อน หรือ async ป้องกันไม่ให้สคริปต์เหล่านี้บล็อกการเรนเดอร์หน้าหลักในขณะที่ยังคงโหลดพวกมัน การค้นหา DNS สำหรับโดเมนเหล่านี้ยังคงเกิดขึ้น แต่พวกมันไม่บล็อกผู้ใช้จากการดูเนื้อหาอีกต่อไป.

ขั้นตอนที่ 12: ใช้การดึงข้อมูลล่วงหน้า DNS (นักพัฒนาเว็บ)

เบราว์เซอร์สมัยใหม่รองรับ dns-prefetch และ preconnect คำแนะนำทรัพยากรที่แก้ไข DNS สำหรับโดเมนบุคคลที่สามก่อนที่ผู้ใช้จะต้องการ:

<!– DNS prefetch for non-critical third-party domains –>
<link rel=”dns-prefetch” href=”https://fonts.googleapis.com”>
<link rel=”dns-prefetch” href=”https://analytics.example.com”>

<!– Preconnect for critical third-party domains (DNS + TCP + TLS) –>
<link rel=”preconnect” href=”https://cdn.example.com”>
<link rel=”preconnect” href=”https://api.example.com”>

ใช้ preconnect สำหรับการเชื่อมต่อที่สำคัญที่สุดของคุณ (มันจัดการ DNS + TCP + TLS) และ dns-prefetch สำหรับทุกอย่างอื่น Preconnect สามารถประหยัด 100–500 มิลลิวินาทีต่อการเชื่อมต่อ ในขณะที่ DNS prefetch ประหยัด 20–120 มิลลิวินาที อย่าใช้ preconnect มากเกินไป — แต่ละอันเปิดการเชื่อมต่อที่ใช้ทรัพยากร.

ตารางการแก้ไขปัญหาอ้างอิงด่วน