---
canonical: https://koalavps.com/th/guides-self-host-dns-resolver-on-a-vps/
language: th
generated: 2026-10-21T13:34:18.852Z
---

[หน้าแรก](https://koalavps.com/th/) / [สำรวจ](https://koalavps.com/th/resources/) /  บันทึกภาคสนาม KoalaVPS

บันทึกภาคสนาม KoalaVPS

# ตัวแปลงชื่อสำหรับอุปกรณ์ของคุณ ไม่ใช่ตัวขยายแบบเปิด

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

[ค้นหา VPS ของคุณ](https://koalavps.com/th/vps/)

## ในเอกสารนี้

[เลือกบทบาท](https://koalavps.com/th/guides-self-host-dns-resolver-on-a-vps/#section-1)[เก็บเป็นส่วนตัว](https://koalavps.com/th/guides-self-host-dns-resolver-on-a-vps/#section-2)[กำหนดนโยบายการบันทึกเหตุการณ์](https://koalavps.com/th/guides-self-host-dns-resolver-on-a-vps/#section-3)[ทดสอบมากกว่าหนึ่งชื่อ](https://koalavps.com/th/guides-self-host-dns-resolver-on-a-vps/#section-4)[พิสูจน์ว่าคนแปลกหน้าไม่สามารถสอบถามได้](https://koalavps.com/th/guides-self-host-dns-resolver-on-a-vps/#section-5)[รักษาการอ้างสิทธิ์ DNS ที่เข้ารหัสไว้ให้แม่นยำ](https://koalavps.com/th/guides-self-host-dns-resolver-on-a-vps/#section-6)[เลือกห่วงโซ่ตัวแปลงชื่อก่อนเปิดพอร์ต](https://koalavps.com/th/guides-self-host-dns-resolver-on-a-vps/#section-7)[จุดเริ่มต้นของ Unbound แบบ loopback](https://koalavps.com/th/guides-self-host-dns-resolver-on-a-vps/#section-8)[เรียกใช้รายการตรวจสอบการยอมรับจากสองเครือข่าย](https://koalavps.com/th/guides-self-host-dns-resolver-on-a-vps/#section-9)[วินิจฉัยการหมดเวลา ลูป และความล้มเหลวในการตรวจสอบความถูกต้อง](https://koalavps.com/th/guides-self-host-dns-resolver-on-a-vps/#section-10)[ฐานความรู้](https://koalavps.com/th/resources/)

## เลือกบทบาท

ตัวแก้ไขแบบเรียกซ้ำเช่น Unbound และอินเทอร์เฟซกรองเช่น AdGuard Home แก้ปัญหาที่เกี่ยวข้องแต่แตกต่างกัน ตัดสินใจว่าบริการจะเรียกซ้ำเองหรือส่งต่อไปยังต้นทาง และเข้าใจว่าฝ่ายใดจะเห็นคำค้นหา

## เก็บเป็นส่วนตัว

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

## กำหนดนโยบายการบันทึกเหตุการณ์

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

## ทดสอบมากกว่าหนึ่งชื่อ

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

## พิสูจน์ว่าคนแปลกหน้าไม่สามารถสอบถามได้

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

- รันตัวตรวจสอบการกำหนดค่าก่อนนำการเปลี่ยนแปลงไปใช้

- ทดสอบไคลเอนต์ที่ได้รับอนุญาตและไคลเอนต์ที่ถูกปฏิเสธ

- เก็บการวินิจฉัยคำขอแบบละเอียดไว้ชั่วคราว

```
unbound-checkconf
```

เอกสารอย่างเป็นทางการ: [การกำหนดค่าการควบคุมการเข้าถึงแบบไม่จำกัด](https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html)

## รักษาการอ้างสิทธิ์ DNS ที่เข้ารหัสไว้ให้แม่นยำ

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

## เลือกห่วงโซ่ตัวแปลงชื่อก่อนเปิดพอร์ต

การออกแบบส่วนตัวที่มีประโยชน์คือไคลเอนต์ VPN ที่สอบถาม AdGuard Home โดย AdGuard ส่งต่อไปยัง Unbound บน loopback จากนั้น Unbound ทำการเรียกซ้ำซ้อน (recursion) ส่วน AdGuard เพิ่มการกรองและอินเทอร์เฟซการจัดการ หรือใช้เฉพาะ Unbound สำหรับสแตกที่เล็กกว่า กำหนดที่อยู่/พอร์ตที่แตกต่างกันให้แต่ละ listener และวาดทิศทางการส่งต่อ: การส่ง Unbound กลับไปยัง AdGuard จะสร้างลูป ตัดสินใจว่าไคลเอนต์ส่วนตัวใดอาจใช้บริการก่อนเผยแพร่สิ่งใด

- ปิดพอร์ต TCP และ UDP ขาเข้าสาธารณะ 53 ไว้ เว้นแต่มีนโยบายไคลเอนต์ที่ได้รับอนุญาตเป็นการเฉพาะ

- กำหนดกฎการเข้าถึงแยกกันสำหรับอินเทอร์เฟซการกรองและตัวรับฟัง DNS

- ตรวจสอบความเป็นเจ้าของพอร์ตก่อนติดตั้ง ตัวแก้ไขระบบที่มีอยู่แล้วอาจผูกกับที่อยู่ที่ต้องการไว้แล้ว

เอกสารอย่างเป็นทางการ: [การตั้งค่า AdGuard Home](https://github.com/AdguardTeam/AdGuardHome/wiki/Getting-Started)

## จุดเริ่มต้นของ Unbound แบบ loopback

บนระบบที่ติดตั้ง Unbound ไว้แล้ว ส่วนย่อยต่อไปนี้แสดงตัวอย่างแบ็กเอนด์ที่เข้าถึงได้เฉพาะบนโฮสต์ ให้ผสานเข้ากับการกำหนดค่าของดิสทริบิวชันแทนการเขียนทับการตั้งค่าแพ็กเกจหรือการจัดการ trust-anchor พอร์ตสูงช่วยให้ฟรอนต์เอนด์ DNS อื่นใช้พอร์ต 53 ได้ ตรวจสอบไฟล์ที่มีผลสมบูรณ์แล้วโหลดใหม่ผ่านตัวจัดการบริการที่ติดตั้งไว้ ไคลเอนต์ระยะไกลต้องมีทันเนลหรือฟรอนต์เอนด์ที่ควบคุมแยกต่างหาก ส่วนย่อยนี้จงใจไม่สร้างตัวแปลงชื่อสาธารณะ

```
server:
interface: 127.0.0.1
port: 5335
access-control: 127.0.0.0/8 allow
access-control: 0.0.0.0/0 refuse
access-control: ::0/0 refuse

# Validate the complete installed configuration:
unbound-checkconf
```

เอกสารอย่างเป็นทางการ: [เอกสารอ้างอิงการกำหนดค่า Unbound](https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html)

## เรียกใช้รายการตรวจสอบการยอมรับจากสองเครือข่าย

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

- การวินิจฉัยในเครื่อง: dig @127.0.0.1 -p 5335 example.org A

- ตรวจสอบการเข้าถึงทั้ง UDP และ TCP รวมถึงตัวรับฟัง IPv6

- ยืนยันข้อยกเว้นการกรองและบันทึกเฉพาะข้อมูลวินิจฉัยที่จำเป็นจริงๆ

## วินิจฉัยการหมดเวลา ลูป และความล้มเหลวในการตรวจสอบความถูกต้อง

การหมดเวลาที่ฟรอนต์เอนด์ขณะแบ็กเอนด์ภายในทำงานปกติบ่งชี้ถึงที่อยู่ฟรอนต์เอนด์ ไฟร์วอลล์ หรือเป้าหมายการส่งต่อ คำถามที่ส่งถึงตัวเองซ้ำ ๆ บ่งชี้ถึงลูป ความล้มเหลวของ DNSSEC ในวงกว้างอาจเกี่ยวข้องกับเวลาระบบที่ไม่ถูกต้องหรือการบำรุงรักษา trust anchor แก้ไขสาเหตุแทนที่จะปล่อยให้การตรวจสอบถูกปิดใช้งาน หากเฉพาะการตอบกลับขนาดใหญ่ล้มเหลว ให้ตรวจสอบ TCP fallback และเส้นทางเครือข่าย เก็บการบันทึกคำถามไว้ชั่วคราว และทดสอบการรีสตาร์ทและการกู้คืนการกำหนดค่าก่อนทำให้ตัวแก้ไขเป็นสิ่งที่ทุกอุปกรณ์ต้องพึ่งพา

สำรวจต่อ

## อ่านต่อ

[เครือข่าย ### เครือข่ายควรอธิบายตัวเองได้ ทำความเข้าใจตัวเลือกในภูมิภาคนอร์ดิก ความแตกต่างระหว่างความเร็วพอร์ตและปริมาณงานจริง และหลักฐานที่เครือข่ายโฮสติ้งควรเผยแพร่…](https://koalavps.com/th/network/)[กฎหมาย ### นโยบายความเป็นส่วนตัว — เก็บข้อมูลน้อยลง เหตุผลชัดเจน ทำความเข้าใจบันทึกบัญชี การชำระเงิน และทางเทคนิค เหตุใดจึงอาจจำเป็น และคำถามใดที่ควรถามเกี่ยวกับการเข้าถึงและการเก็บรักษา นโยบายที…](https://koalavps.com/th/privacy/)[คู่มือ ### อุโมงค์ส่วนตัวที่มีวัตถุประสงค์ชัดเจน WireGuard สามารถเชื่อมต่ออุปกรณ์ของคุณเข้ากับเซิร์ฟเวอร์หรือเครือข่ายส่วนตัวได้ ประโยชน์ของมันขึ้นอยู่กับการกำหนดเส้นทางที่ถูกต้อง…](https://koalavps.com/th/guides-wireguard-vpn-on-a-vps/)

กำหนดค่าโครงสร้างพื้นฐานของคุณ

## ควบคุมด้วยตัวคุณเอง ติดตั้งตามเงื่อนไขของคุณ

ไม่มีเอกสารยืนยันตัวตน เข้าถึงผู้ดูแลระบบเต็มรูปแบบ การเรียกเก็บเงินแบบคริปโตโดยกำเนิด

[เลือกการกำหนดค่า](https://koalavps.com/th/vps/)