DNS ส่วนตัวสำหรับเครือข่าย VPS: ทำงานอย่างไรและเมื่อใดที่คุณต้องใช้

คุณเปิดเซิร์ฟเวอร์เครื่องที่สาม ต้องการให้เครื่องต่าง ๆ ติดต่อกันด้วยชื่อแทนที่จะเป็น IP แล้วค้นหาคำว่า "private DNS VPS" ผลลัพธ์สามรายการปรากฏขึ้นและไม่ตรงกัน รายการหนึ่งคือการตั้งค่า Android ที่เข้ารหัสการค้นหาของโทรศัพท์ อีกรายการคือคู่มือ cPanel สำหรับตั้งชื่อเนมเซิร์ฟเวอร์ให้เป็นแบรนด์ของโดเมน และอีกรายการคือเอกสารของ AWS เกี่ยวกับ private hosted zones เมื่อวันที่ 20 กรกฎาคม 2026 Cloudflare เปิดให้ใช้งาน Internal DNS ทั่วไปแล้ว และอธิบายว่าเป็น "บางครั้งเรียกอีกอย่างว่า DNS ส่วนตัว" ดังนั้นตอนนี้ความสับสนจึงมาจากผู้ให้บริการโครงสร้างพื้นฐานด้วย

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

TL;DR (สรุปย่อ)

• "DNS ส่วนตัว" หมายถึงระบบที่ไม่เกี่ยวข้องกันอย่างน้อยสามระบบ ได้แก่ โซน DNS ภายในสำหรับเครือข่ายเซิร์ฟเวอร์ ฟีเจอร์การเข้ารหัส DNS-over-TLS ของ Android และเนมเซิร์ฟเวอร์แบรนด์ของ cPanel บทความนี้ใช้คำนี้ในความหมายแรก นั่นคือโซน DNS ภายในสำหรับเครือข่าย VPS
• โซน DNS ส่วนตัวของ VPS คือเนมสเปซภายในที่จำกัดขอบเขตอยู่ในเครือข่าย ซึ่งจับคู่ชื่อโฮสต์อย่าง db.internal.example.com ไปยัง IP ส่วนตัว เรกคอร์ดของโซนนี้จะไม่ถูกเผยแพร่ใน DNS สาธารณะ
• สำหรับเซิร์ฟเวอร์ไม่กี่เครื่องที่มี IP คงที่ /etc/hosts ก็เพียงพอจริง ๆ เซิร์ฟเวอร์ DNS ภายในจะเริ่มคุ้มค่าเมื่อจำนวนเครื่องเพิ่มขึ้น IP เปลี่ยนบ่อย หรือบริการต่าง ๆ ต้องการการแปลงชื่อที่เชื่อถือได้
• สำหรับเครือข่าย VPS ที่ใช้งานจริงส่วนใหญ่ ให้ใช้ซับโดเมนที่คุณเป็นเจ้าของ เช่น internal.example.com. ให้ใช้เนมสเปซ .internal เฉพาะกับระบบที่แยกออกมาต่างหาก ซึ่งยอมรับได้ทั้งการชนกันของชื่อข้ามเครือข่าย การจัดการใบรับรองด้วย CA ส่วนตัว และการจัดการ DNSSEC แบบพิเศษ และหลีกเลี่ยง .local ซึ่ง mDNS สงวนไว้

สิ่งที่บทความนี้ไม่ครอบคลุม

บทความนี้จำกัดอยู่ที่ความหมายด้านเครือข่าย VPS ของ DNS ส่วนตัวเท่านั้น ไม่ครอบคลุมการใช้งานฝั่งผู้บริโภคและแบรนด์โฮสติ้งที่ไม่เกี่ยวข้อง ได้แก่

• การตั้งค่า DNS ส่วนตัวหรือ DNS-over-TLS ของ Android บนโทรศัพท์
• การตั้งค่าเนมเซิร์ฟเวอร์ส่วนตัวของ cPanel สำหรับแบรนด์โฮสติ้ง
• คู่มือการติดตั้งแบบเต็มของ BIND 9, Unbound, dnsmasq หรือ CoreDNS การนำไปใช้ในบทความนี้อยู่ในระดับอ้างอิงเท่านั้น ไม่ใช่การตั้งค่าแบบทีละขั้นตอน
• รีโซลเวอร์เข้ารหัสสำหรับผู้บริโภคอย่าง 1.1.1.1 หรือ NextDNS นอกเหนือจากการแยกให้ชัดจากความหมายด้านเครือข่าย

"DNS ส่วนตัว" หมายถึงอะไรกันแน่

"DNS ส่วนตัว" ไม่ใช่ระบบเดียว แต่หมายถึงระบบที่ไม่เกี่ยวข้องกันอย่างน้อยสามอย่าง ได้แก่ โซน DNS ที่จำกัดอยู่ในเครือข่ายซึ่งแปลงชื่อโฮสต์ภายในของเครือข่าย VPS หรือ VPC ฟีเจอร์การเข้ารหัส DNS-over-TLS ของ Android และเนมเซิร์ฟเวอร์ผู้มีอำนาจที่ปรับแบรนด์เองของ cPanel บทความนี้กล่าวถึงอย่างแรก คือโซนภายในที่เซิร์ฟเวอร์ของคุณสอบถามเพื่อค้นหากันและกัน ยังมีการใช้แบบหลวม ๆ อย่างที่สี่ด้วย นั่นคือรีโซลเวอร์สาธารณะแบบเข้ารหัสที่ทำการตลาดว่าเป็น "ส่วนตัว"

ความหมายทั้งสี่มีเพียงชื่อที่เหมือนกัน นอกนั้นไม่มีอะไรเหมือนกันเลย

การประกาศเปิดให้ใช้งานทั่วไปของ Internal DNS จาก Cloudflare เป็นตัวอย่างแบบมีผู้ดูแลที่เป็นปัจจุบันของความหมายแรก และเป็นเหตุผลหนึ่งที่ทำให้ความสับสนนี้ปรากฏชัดขึ้น นั่นคือผู้ให้บริการโครงสร้างพื้นฐานเริ่มใช้คำว่า "DNS ส่วนตัว" แทน DNS ภายในในข้อความเปิดตัวของตน ระบบที่อธิบายไว้ ซึ่งประกอบด้วย Gateway Resolver คู่กับ Internal Authoritative DNS สำหรับลูกค้า Enterprise ก็คือระบบประเภทเดียวกับที่คุณสร้างเองบนกลุ่ม VPS เพียงแต่มีผู้ดูแลให้

ข้อสรุปของส่วนนี้: ระบบหลัก ๆ ที่ถูกเรียกว่า "DNS ส่วนตัว" มีเพียงชื่อเรียกที่เหมือนกัน ไม่ใช่หน้าที่ ควรระบุความหมายให้ชัดก่อนทำตามคู่มือการตั้งค่าใด ๆ

DNS ส่วนตัวทำงานอย่างไรบนเครือข่าย VPS

โซน DNS ส่วนตัวของ VPS คือเนมสเปซที่จำกัดขอบเขตในเครือข่าย ให้บริการโดยรีโซลเวอร์ที่เซิร์ฟเวอร์ของคุณถูกตั้งค่าให้ใช้งาน โซนนี้จับคู่ชื่อโฮสต์ภายในอย่าง db.internal.example.com ไปยัง IP ส่วนตัวในช่วงที่คุณควบคุมเอง เรกคอร์ดเหล่านี้ไม่ถูกเผยแพร่ใน DNS สาธารณะ แม้ว่าคำสั่งค้นหาอาจเดินทางผ่านอุโมงค์ส่วนตัวหรือ control plane ของ DNS แบบมีผู้ดูแลก่อนถึงรีโซลเวอร์ก็ตาม การแยกส่วนนี้คือแก่นของความต่างระหว่าง DNS ส่วนตัวกับ DNS สาธารณะ นั่นคือโปรโตคอลเหมือนกัน แต่การมองเห็นโซนและขอบเขตการเข้าถึงต่างกัน

มีสามส่วนที่ทำงานร่วมกัน เซิร์ฟเวอร์ผู้มีอำนาจหรือแหล่งข้อมูลโซนเก็บโซนภายในและเรกคอร์ดของมัน รีโซลเวอร์ตอบคำสั่งค้นหาที่เซิร์ฟเวอร์ของคุณส่งไป และเรกคอร์ด A กับ AAAA ของโซนจับคู่ชื่อโฮสต์ภายในกับที่อยู่ส่วนตัว ดังนั้น app.internal.example.com จะชี้ไปยังชั้นแอปพลิเคชัน และ db.internal.example.com จะชี้ไปยังฐานข้อมูล เรกคอร์ดประเภทอื่นสามารถให้ชื่อแทนหรือข้อมูลบริการได้ เมื่อโซนและเส้นทางของรีโซลเวอร์ถูกตั้งค่าอย่างถูกต้อง รีโซลเวอร์จะตอบคำสั่งค้นหาภายในในเครื่องแทนที่จะส่งต่อไปยังรากของ DNS สาธารณะ

แพลตฟอร์มคลาวด์กำหนดขอบเขตเรื่องนี้ไว้ที่เครือข่ายแทนที่จะเป็นตัวเครื่อง ซึ่งเป็นแบบจำลองอ้างอิงที่มีประโยชน์ private hosted zones ของ AWS Route 53 จะทำงานได้ก็ต่อเมื่อ VPC ตั้งค่าทั้ง enableDnsHostnames และ enableDnsSupport เป็น true และรีโซลเวอร์จะตอบจากโซนส่วนตัวให้กับทุก VPC ที่คุณเชื่อมโยงไว้กับโซนนั้น โซนส่วนตัวของ Google Cloud จะจำกัดขอบเขตอยู่ที่เครือข่าย VPC ที่ได้รับอนุญาต และใน ลำดับการแปลงชื่อมาตรฐานของ VPC โซนเหล่านี้จะถูกตรวจสอบก่อน DNS สาธารณะ เว้นแต่จะมีนโยบายเซิร์ฟเวอร์ขาออกมาเปลี่ยนเส้นทาง ให้อ่านสิ่งเหล่านี้เป็นตัวอย่างของรูปแบบ ไม่ใช่คู่มือเฉพาะแพลตฟอร์ม เพราะเซิร์ฟเวอร์ DNS ภายในที่คุณดูแลเองก็คือแนวคิดเดียวกัน เพียงแต่รันบน VPS ของคุณเอง

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

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

เมื่อใดที่เครือข่าย VPS ของคุณต้องใช้ DNS ส่วนตัวจริง ๆ

สำหรับเซิร์ฟเวอร์แบบคงที่สองหรือสามเครื่อง /etc/hosts ก็เพียงพอจริง ๆ เซิร์ฟเวอร์ DNS ภายในจะเริ่มคุ้มค่าเมื่อจำนวนเครื่องเพิ่มขึ้น IP เปลี่ยนเป็นประจำ หรือแอปพลิเคชันต้องการการค้นหาบริการที่เชื่อถือได้ ตัวกระตุ้นที่แท้จริงคือความซับซ้อนในการดำเนินงาน ไม่ใช่จำนวนเซิร์ฟเวอร์ที่ตายตัว

/etc/hosts คือแผนที่แบบคงที่ที่จับคู่ชื่อโฮสต์กับ IP ซึ่งมีอยู่แล้วในเครื่อง Linux ทุกเครื่อง มันไม่ต้องใช้เดมอนหรือไฟล์โซน แต่สำเนาที่ล้าสมัยหรือไม่ตรงกันคือรูปแบบความล้มเหลวที่เกิดขึ้นจริง ให้เพิ่ม IP ส่วนตัวของแต่ละเซิร์ฟเวอร์ลงในไฟล์ รักษาให้สำเนาต่าง ๆ ตรงกัน แล้วเครื่องต่าง ๆ ก็จะหากันเจอด้วยชื่อ สำหรับกลุ่มเครื่องที่เล็กและคงที่ นี่คือคำตอบที่ถูกต้อง ส่วนการหันไปใช้ BIND 9 แทนก็เพียงเพิ่มเดมอนที่ต้องดูแลโดยไม่ได้อะไรกลับมา

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

ข้อสรุปของส่วนนี้: ตัวกระตุ้นคืออัตราการเปลี่ยนแปลงในการดำเนินงาน ไม่ใช่จำนวนเซิร์ฟเวอร์ กลุ่มเครื่องสิบเครื่องที่นิ่งสนิทก็อยู่ได้ด้วย /etc/hosts ได้ ส่วนกลุ่มสามเครื่องที่สร้างใหม่ทุกคืนน่าจะไม่ควรทำเช่นนั้น

พัฒนาบน Linux VPS พร้อมสิทธิ์รูท, NVMe และพลัง AMD EPYC

ดูแพ็กเกจ Linux

ควรใช้เซิร์ฟเวอร์ DNS ตัวไหน: BIND 9, Unbound, dnsmasq หรือ CoreDNS

เลือกตามรูปแบบของกลุ่มเครื่องที่คุณมี dnsmasq เหมาะกับเครือข่ายเล็กที่ต้องการ DNS แบบเบา และหากจำเป็นก็ได้ DHCP จากเดมอนเดียวกัน Unbound เป็นรีโซลเวอร์แบบเรียกซ้ำที่กะทัดรัดและตรวจสอบ DNSSEC ได้ อีกทั้งยังตอบโซนภายในขนาดย่อมได้ด้วย BIND 9 ให้ความสามารถทั้งแบบผู้มีอำนาจและแบบเรียกซ้ำอย่างครอบคลุม พร้อมพื้นที่การตั้งค่าที่กว้างที่สุด ส่วน CoreDNS เหมาะกับกลุ่มเครื่องที่ใช้คอนเทนเนอร์และ Kubernetes ซึ่ง DNS เป็นส่วนหนึ่งของการค้นหาบริการ

ตรรกะการเลือกนั้นสั้น หากคุณต้องการรีโซลเวอร์เล็ก ๆ ที่อาศัยไฟล์แบบ hosts หรือคุณแจกสัญญาเช่า DHCP อยู่แล้ว dnsmasq จะช่วยลดชิ้นส่วนที่ต้องดูแลลงหนึ่งชิ้น หากคุณต้องการเพียงรีโซลเวอร์ที่ตรวจสอบและส่งต่อออกไปข้างนอก พร้อมตอบโซนภายในขนาดย่อม Unbound ก็ให้ชุดความสามารถที่แคบกว่านั้นได้โดยไม่ต้องติดตั้ง BIND 9 เต็มรูปแบบ หากคุณต้องการการควบคุมแบบผู้มีอำนาจอย่างเต็มที่ การมอบสิทธิ์ และคลังเอกสารที่ใหญ่ที่สุดไว้พึ่งพาตอนตีสาม BIND 9 ก็ยังเป็นตัวเลือกที่ปลอดภัย แม้พื้นที่การตั้งค่าจะกว้างกว่า และหาก DNS เป็นส่วนหนึ่งของสแตกการค้นหาบริการบนคอนเทนเนอร์หรือ Kubernetes อยู่แล้ว CoreDNS ก็เข้ากับตรงนั้นพอดี หลักคร่าว ๆ คือให้รันสิ่งที่เล็กที่สุดที่ครอบคลุมรูปแบบของกลุ่มเครื่องคุณ

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

ควรตั้งชื่อโดเมนภายในอย่างไร: .internal, .local หรือซับโดเมน

สำหรับเครือข่าย VPS ที่ใช้งานจริงส่วนใหญ่ ให้ใช้ซับโดเมนที่คุณเป็นเจ้าของ เช่น internal.example.com. ให้ใช้เนมสเปซ .internal เฉพาะกับระบบที่แยกออกมาต่างหาก ซึ่งยอมรับได้ทั้งการชนกันของชื่อข้ามเครือข่าย การจัดการใบรับรองด้วย CA ส่วนตัว และการจัดการ DNSSEC แบบพิเศษ และหลีกเลี่ยง .local ซึ่ง mDNS สงวนไว้

ปัญหาของ .local นั้นเป็นรูปธรรม RFC 6762 กำหนดให้ชื่อที่ลงท้ายด้วย .local ได้รับการจัดการเป็นพิเศษสำหรับ Multicast DNS ดังนั้นโซนแบบยูนิคาสต์ของ BIND 9 หรือ Unbound ที่ใช้คำต่อท้ายเดียวกันอาจขัดแย้งกับพฤติกรรม mDNS บนอุปกรณ์ Apple และระบบอื่นที่เปิดใช้ mDNS ให้ใช้เนมสเปซอื่นแทนการพึ่งพาวิธีแก้เฉพาะไคลเอนต์

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

คณะกรรมการของ ICANN สงวน .internal ไว้อย่างถาวร จากการมอบสิทธิ์ในรากของ DNS สาธารณะเมื่อเดือนกรกฎาคม 2024 ตามข้อเสนอแนะก่อนหน้านี้ของ SSAC ชื่อที่อยู่ภายใต้ TLD นี้จะไม่ถูกแปลงผ่าน DNS ระดับโลกโดยการออกแบบ ซึ่งมาพร้อมข้อแลกเปลี่ยน ได้แก่ ชื่อ .internal ไม่ได้ไม่ซ้ำกันทั่วโลก ผู้ออกใบรับรองสาธารณะไม่ได้ถูกคาดหวังให้ออกใบรับรองให้กับชื่อเหล่านี้ และรีโซลเวอร์ที่ตรวจสอบ DNSSEC โดยอาศัย trust anchor ระดับโลกจะแปลงชื่อเหล่านี้ไม่สำเร็จ หากคุณต้องใช้ HTTPS บน .internal ให้วางแผนเดินระบบ CA ส่วนตัวเอาไว้

ตรงนี้ต้องแยกสองเรื่องออกจากกัน การสงวนของ ICANN นั้นถือเป็นที่สิ้นสุด ส่วนอีกเรื่องหนึ่งคือ Internet-Draft ที่ยังใช้งานอยู่ draft-davies-internal-tld-06ซึ่งเผยแพร่เมื่อวันที่ 6 พฤษภาคม 2026 เพื่อบันทึกรายละเอียดของเนมสเปซนี้และเปรียบเทียบกับการกำหนดที่อยู่แบบส่วนตัวตาม RFC 1918 เอกสารนี้ยังคงเป็น Internet-Draft ที่อยู่ระหว่างดำเนินการ ไม่ใช่ RFC ที่เผยแพร่แล้ว ดังนั้นให้อธิบาย .internal ว่าเป็น TLD สำหรับใช้งานส่วนตัวที่ ICANN สงวนไว้ ไม่ใช่มาตรฐานของ IETF

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

ข้อสรุปของส่วนนี้: การตัดสินใจเรื่องเนมสเปซนั้นอยู่กับเราไปนาน ซับโดเมนที่คุณควบคุมเองคือค่าเริ่มต้นสำหรับสภาพแวดล้อมการใช้งานจริงส่วนใหญ่ เพราะรักษาความไม่ซ้ำกันทั่วโลกและใช้กับ PKI สาธารณะได้ ส่วน .internal ให้ใช้เมื่อเนมสเปซส่วนตัวแบบแยกออกมาเหมาะกว่า และคุณยอมรับข้อแลกเปลี่ยนเรื่อง DNSSEC ใบรับรอง และการชนกันของชื่อได้

Split-Horizon DNS และข้อผิดพลาดที่ทำให้มันพัง

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

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

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

ยังมีหลุมพรางอีกสามอย่างที่มองข้ามได้ง่าย รีโซลเวอร์สำรองที่ตั้งค่าไว้บนโฮสต์หรือคอนเทนเนอร์อาจเลี่ยงการแบ่งนี้ได้ และขึ้นอยู่กับการนำรีโซลเวอร์ไปใช้งาน มันอาจถูกสอบถามหลังหมดเวลารอหรือสอบถามพร้อมกันไปเลย คำตอบจึงแตกต่างกันได้ คอนเทนเนอร์บนบริดจ์เริ่มต้นของ Docker จะได้รับสำเนาการตั้งค่า DNS ของโฮสต์ตอนเริ่มทำงาน ส่วนคอนเทนเนอร์บนเครือข่ายที่สร้างเองจะสอบถามรีโซลเวอร์ในตัวของ Docker ที่ 127.0.0.11 รีโซลเวอร์ตัวนั้นจะส่งต่อการค้นหาภายนอกไปยังเซิร์ฟเวอร์ DNS ที่ตั้งค่าไว้สำหรับโฮสต์หรือคอนเทนเนอร์ ดังนั้นพฤติกรรมของ split-DNS จึงขึ้นอยู่กับการตั้งค่าของ Docker และโฮสต์ ไม่ใช่เพียงไฟล์รีโซลเวอร์ของคอนเทนเนอร์เท่านั้น หากบริการภายในอยู่หลังรีเวิร์สพร็อกซีอย่าง ผู้จัดการพร็อกซี่ Nginx การตรวจสอบใบรับรองอาจล้มเหลวเมื่อใบรับรองไม่ครอบคลุมชื่อโฮสต์ที่ร้องขอ หรือเมื่อไคลเอนต์ไม่ไว้ใจ CA ที่ออกใบรับรองนั้น การใช้ใบรับรองคนละใบสำหรับภายในเพียงอย่างเดียวไม่ถือเป็นข้อผิดพลาดในตัวมันเอง สิ่งเหล่านี้คือช่องโหว่ของการตั้งค่า ไม่ใช่บั๊กของเครื่องมือ

ไคลเอนต์ระยะไกลก็อาจเจอความล้มเหลวแบบเดียวกันได้ เมื่อ VPN ที่โฮสต์เอง ไม่ได้ผลักหรือกำหนดเส้นทางคำสั่งค้นหา DNS ไปยังรีโซลเวอร์ภายในที่ตั้งใจไว้

ยังมีมิติด้านความปลอดภัยด้วย หากชื่อโฮสต์ภายในและ IP ส่วนตัวรั่วไหลเข้าไปในเรกคอร์ด DNS สาธารณะ ก็เท่ากับคุณเปิดเผยส่วนหนึ่งของผังการตั้งชื่อและการกำหนดที่อยู่ภายในให้ใครก็ตามที่ค้นหา split-horizon มีอยู่ส่วนหนึ่งก็เพื่อเก็บแผนผังนั้นไว้ภายใน และโซนสาธารณะที่ตั้งค่าผิดก็ทำลายสิ่งนั้นไปอย่างเงียบ ๆ

ข้อสรุปของส่วนนี้: ความล้มเหลวของ split-horizon คือกับดักของการตั้งค่า ไม่ใช่ข้อบกพร่องของเครื่องมือ ความถูกต้องขึ้นอยู่กับวินัยในการตั้งชื่อ การรู้ว่าไคลเอนต์แต่ละตัวสอบถามรีโซลเวอร์ตัวไหนจริง ๆ และการกำหนดขอบเขตโซนให้เหมาะสม ไม่ได้ขึ้นอยู่กับการตั้งค่าใดค่าหนึ่งเพียงอย่างเดียว

อ่าน

วิธีชี้โดเมนไปยัง VPS: คู่มือฉบับย่อ

บทสรุป: การเลือกการออกแบบ DNS ส่วนตัวที่เหมาะสม

ตอนนี้คุณระบุได้แล้วว่าคุณหมายถึงระบบ "DNS ส่วนตัว" แบบไหนกันแน่ สำหรับเครือข่าย VPS มันคือโซน DNS ภายใน ไม่ใช่การตั้งค่า DNS-over-TLS ของ Android และไม่ใช่เนมเซิร์ฟเวอร์ผู้มีอำนาจแบบมีแบรนด์ หากกลุ่มเครื่องของคุณเล็กและคงที่ /etc/hosts ก็ยังเป็นทางเลือกที่มีเหตุผลรองรับได้ แต่ถ้าไม่ใช่ ให้ใช้ซับโดเมนที่คุณเป็นเจ้าของเป็นเนมสเปซเริ่มต้น เลือกเซิร์ฟเวอร์ DNS ที่เล็กที่สุดเท่าที่เหมาะกับกลุ่มเครื่องของคุณ และกำหนดเรื่องการเข้าถึง ความซ้ำซ้อนสำรอง และขอบเขตโซนภายในเทียบกับสาธารณะให้ชัดเจน ส่วน .internal ให้ใช้เฉพาะเมื่อเนมสเปซแบบแยกออกมาเหมาะกว่า และคุณยอมรับข้อแลกเปลี่ยนเรื่องใบรับรอง DNSSEC และการชนกันของชื่อได้

คำถามที่พบบ่อย