DNS คืออะไร? คู่มือตั้งค่าโดเมนชี้ไปที่ VPS สำหรับมือใหม่

DNS คืออะไร และเหตุใดโดเมนของคุณจึงยังเข้าถึง VPS ไม่ได้

DNS (domain name system) ทำหน้าที่แปลงชื่ออย่าง example.com ให้เป็นที่อยู่ IP (internet protocol) เช่น 203.0.113.10 เบราว์เซอร์ไม่สามารถเชื่อมต่อกับชื่อได้โดยตรง แต่จะเชื่อมต่อกับที่อยู่ ดังนั้นการโหลดหน้าเว็บทุกครั้งจึงเริ่มต้นด้วยการสอบถาม DNS และรอรับคำตอบ หากคุณเพิ่งซื้อโดเมนและ VPS ของคุณเอง แล้วไม่มีอะไรโหลดขึ้นมา เป็นไปได้ว่าเกิดจากหนึ่งในสองกรณีนี้: ยังไม่มี record เชื่อมโยงชื่อเข้ากับที่อยู่เซิร์ฟเวอร์ของคุณ หรือมี record แล้วแต่ระบบในเส้นทางเครือข่ายยังคงส่งคำตอบเก่าออกมา

ทั้งสองสถานการณ์ถือเป็นเรื่องปกติและไม่ได้หมายความว่าระบบเสียหาย ส่วนต่างๆ ด้านล่างนี้จะเรียงลำดับตามขั้นตอนที่คุณจะได้พบ เริ่มจากส่วนที่ทำให้เสียเวลามากที่สุด นั่นคือแผงควบคุม (control panel) ใดที่เป็นผู้เก็บ record ของคุณอยู่จริง

การตรวจสอบทุกรายการในที่นี้ใช้ dig ซึ่งไม่ได้ถูกติดตั้งมาเป็นค่าเริ่มต้นบนเครื่อง Ubuntu หรือ Debian ที่เพิ่งติดตั้งใหม่

sudo apt update && sudo apt install -y bind9-dnsutils

Registrar, nameservers และ DNS host: ควรแก้ไขที่จุดไหน

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

• Registrar คือบริษัทที่คุณซื้อโดเมนมา หน้าที่สำคัญคือการมอบอำนาจ (delegation): ทำหน้าที่แจ้ง registry ที่ดูแล TLD (top-level domain หรือส่วน .com) ของคุณว่า nameservers ใดที่มีอำนาจตัดสินใจ (authoritative) สำหรับโดเมนของคุณ
• Authoritative nameservers คือเซิร์ฟเวอร์ที่เก็บระเบียนข้อมูลจริงสำหรับ zone ของคุณ โดย zone คือโดเมนของคุณและชื่อย่อยทั้งหมดภายใต้โดเมนนั้น
• DNS host คือผู้ที่ดูแล nameservers เหล่านั้น อาจเป็น registrar เอง, ผู้ให้บริการรายอื่น หรือ bind9 ที่รันอยู่บนเซิร์ฟเวอร์ของคุณเอง

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

ตรวจสอบว่าในขณะนี้โลกกำลังสอบถามข้อมูลจากที่ใด:

dig example.com NS +short
dig +trace example.com

คำสั่งแรกจะแสดง nameservers ที่ตอบกลับสำหรับโดเมนของคุณในปัจจุบัน ส่วนคำสั่งที่สองจะไล่ลำดับจาก root servers และแสดงข้อมูลการส่งต่อ (referral) ที่ TLD servers แจกจ่ายออกมา ซึ่งก็คือการมอบอำนาจที่ registrar ของคุณเป็นผู้ควบคุม หาก nameservers เหล่านั้นเป็นของผู้ให้บริการที่คุณไม่รู้จัก แสดงว่าผู้ให้บริการรายนั้นคือเจ้าของแผงควบคุมที่คุณต้องเข้าไปแก้ไข

เส้นทางการสืบค้นข้อมูล

กระบวนการนี้เกี่ยวข้องกับ 4 ฝ่าย โดยแต่ละฝ่ายจะเก็บสำเนาข้อมูลที่ได้รับไว้

1. stub resolver บนเครื่องของคุณ: มันไม่ได้ทำหน้าที่ค้นหาด้วยตัวเอง แต่จะสอบถามไปยังเซิร์ฟเวอร์ที่กำหนดไว้เพียงแห่งเดียวและเชื่อถือคำตอบนั้น บน Ubuntu นั้น /etc/resolv.conf มักจะเป็น symlink ไปยัง /run/systemd/resolve/stub-resolv.conf และระบุถึง 127.0.0.53 ซึ่งก็คือ systemd-resolved ที่ทำงานอยู่ภายในเครื่องพร้อมกับแคชของตัวเอง
2. recursive resolver: คือตัวแก้ไขที่ดำเนินการโดย ISP (ผู้ให้บริการอินเทอร์เน็ต) ของคุณ หรือบริการสาธารณะอย่าง 1.1.1.1 หรือตัวที่คุณติดตั้งใช้งานเอง มันทำหน้าที่ค้นหาคำตอบจริง ๆ
3. root และ TLD servers: recursive resolver จะสอบถามไปยัง root server ซึ่งไม่ได้เก็บที่อยู่ของคุณไว้ แต่จะส่งต่อ (referral) ไปยังเซิร์ฟเวอร์ .com จากนั้นเซิร์ฟเวอร์เหล่านั้นจะส่งต่อคุณไปยัง nameserver ของคุณอีกทอดหนึ่ง
4. authoritative nameserver: ไม่สอบถามใครทั้งสิ้น มันจะตอบกลับจากข้อมูลใน zone ของคุณและระบุว่าคำตอบนั้นเป็นข้อมูลที่เชื่อถือได้ (authoritative)

dig +trace example.com จะแสดงให้คุณเห็นกระบวนการนี้ เนื่องจากมันเริ่มต้นที่ root โดยตรงและแสดงผลการส่งต่อแต่ละขั้นตอนแทนการสอบถามจากแคช นี่เป็นวิธีที่เร็วที่สุดในการตรวจสอบว่าการมอบหมายสิทธิ์ (delegation) และ zone นั้นตรงกันหรือไม่

ระเบียน DNS ที่สำคัญเมื่อคุณใช้งานเซิร์ฟเวอร์

• A: การจับคู่ชื่อกับที่อยู่ IPv4 example.com. A 203.0.113.10 นี่คือระเบียนที่ชี้โดเมนของคุณไปยัง VPS
• AAAA: การจับคู่ชื่อกับที่อยู่ IPv6 เช่น 2001:db8::10 ให้ประกาศใช้เฉพาะเมื่อบริการของคุณฟังการเชื่อมต่อบนที่อยู่นั้นจริงเท่านั้น ไคลเอนต์บนเครือข่าย IPv6 จะพยายามใช้คำตอบจาก AAAA ก่อน ดังนั้นที่อยู่ที่ไม่มีการตอบรับจะทำให้การเข้าถึงทุกครั้งเกิดความล่าช้า
• CNAME: นามแฝงจากชื่อหนึ่งไปยังอีกชื่อหนึ่ง www.example.com. CNAME example.com. จะส่งผู้เข้าชมจาก www ไปยังปลายทางที่โดเมนหลักชี้ไป ระเบียน CNAME ไม่สามารถวางไว้ที่ apex (โดเมนหลัก example.com) ได้ เนื่องจาก apex ต้องมีระเบียน SOA (start of authority) และ NS ของตนเอง และ CNAME ไม่อนุญาตให้ใช้ชื่อซ้ำกับระเบียนประเภทอื่น ผู้ให้บริการมักมีวิธีแก้ปัญหาโดยใช้ชื่อเรียกเช่น ALIAS, ANAME หรือ CNAME flattening
• MX: ปลายทางสำหรับการส่งอีเมลของโดเมน ระเบียนนี้ประกอบด้วยชื่อโฮสต์และตัวเลขลำดับความสำคัญ โดยจะพยายามส่งไปยังหมายเลขที่ต่ำกว่าก่อน MX ต้องชี้ไปยังชื่อที่มีระเบียนที่อยู่ (A หรือ AAAA) การชี้ MX ไปยัง CNAME ถือว่าไม่ถูกต้อง และเซิร์ฟเวอร์ผู้ส่งบางแห่งจะปฏิเสธการเชื่อมต่อ
• TXT: ข้อความอิสระ ใช้สำหรับยืนยันตัวตนและกำหนดนโยบาย ระเบียนการตรวจสอบอีเมล (SPF, DKIM, DMARC) จะอยู่ในนี้ รวมถึงโทเค็น ACME (automatic certificate management environment) ที่ใช้สำหรับออกใบรับรองแบบ wildcard
• NS: ระบุว่า nameserver ใดเป็นผู้ดูแลโซน ข้อมูลชุดที่ตัดสินว่าโลกภายนอกต้องสอบถามที่ใดจะอยู่ใน parent zone ซึ่งมาจากข้อมูลการมอบหมาย (delegation) ของผู้รับจดทะเบียนโดเมน ไม่ใช่ข้อมูลภายในโซนของคุณเอง

รายละเอียดสองประการที่มักทำให้เกิดความสับสนมากกว่าประเภทของระเบียน ชื่อที่ลงท้ายด้วยจุดถือเป็นชื่อสัมบูรณ์ (absolute) ดังนั้น www.example.com. จึงหมายถึงชื่อนั้นโดยตรงและไม่มีส่วนอื่นต่อท้าย แผงควบคุมส่วนใหญ่คาดหวังชื่อสัมพัทธ์ (relative) และจะเติมชื่อโดเมนให้คุณโดยอัตโนมัติ ดังนั้นการพิมพ์ www.example.com ลงในช่องชื่อจะทำให้ได้ www.example.com.example.com ซึ่งไม่สามารถแก้ไขชื่อ (resolve) ได้ รายละเอียดอีกประการคือ @ ซึ่งในเกือบทุกแผงควบคุมหมายถึง apex: คือตัวโดเมนเองโดยไม่มี subdomain ใดๆ

ชี้ A record ไปยัง VPS ของคุณ

ขั้นแรก ให้ดูที่อยู่ IP ที่อินเทอร์เน็ตมองเห็นเซิร์ฟเวอร์ของคุณ:

curl -4 https://ifconfig.me
ip -brief -4 address show

จากนั้นสร้าง record หนึ่งรายการที่ผู้ให้บริการ DNS ของคุณ: กำหนดประเภทเป็น A, ชื่อเป็น @, ค่าเป็นที่อยู่ IP ดังกล่าว และตั้งค่า TTL (time to live) เป็น 300 เพิ่ม record ที่สองสำหรับ www โดยอาจเป็น A อีกรายการที่ชี้ไปยังที่อยู่เดียวกัน หรือใช้ CNAME ที่ชี้ไปยัง apex domain

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

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

คำสั่งแรกใช้เส้นทางปกติของเครื่องคุณ ซึ่งรวมถึงการอ่านจากแคช คำสั่งที่สองข้ามแคชในเครื่องและสอบถามไปยัง public recursive resolver ส่วนคำสั่งที่สามสอบถามไปยัง authoritative nameserver ของคุณโดยตรง ดังนั้นคำตอบที่ได้จึงเป็นข้อมูลล่าสุดโดยไม่มีแคชใดๆ ในเส้นทาง เมื่อคำสั่งที่สามส่งคืนที่อยู่ IP ของคุณแต่คำสั่งแรกยังไม่แสดงผล แสดงว่า DNS ของคุณถูกกำหนดค่าถูกต้องแล้ว และคุณเพียงแค่ต้องรอให้แคชของข้อมูลเก่าหมดอายุลงเท่านั้น

การแก้ไขปัญหาเมื่อการ resolve ไม่ทำงาน

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

curl -I http://example.com

curl: (6) Could not resolve host: example.com หมายถึงปัญหาที่ DNS ส่วน curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused ไม่ใช่ปัญหาจาก DNS เนื่องจากชื่อโดเมนถูก resolve เรียบร้อยและแพ็กเก็ตส่งไปถึงปลายทางแล้ว ปัญหาจึงอยู่ที่ไม่มีบริการใดรอรับการเชื่อมต่ออยู่ที่พอร์ตนั้น คำขอที่ค้างและหมดเวลา (timeout) มักหมายความว่าไฟร์วอลล์ทิ้งแพ็กเก็ตไปโดยไม่แจ้งเตือนแทนที่จะปฏิเสธการเชื่อมต่อ ในจุดนี้ DNS จะไม่ใช่ประเด็นหลักอีกต่อไป และจะเป็นหน้าที่ของ พอร์ตและซ็อกเก็ตที่เปิดรอรับการเชื่อมต่อ รวมถึง กฎไฟร์วอลล์ ufw บน VPS ของคุณ เมื่อการเชื่อมต่อสำเร็จแล้ว ขั้นตอนที่เหลือของการโหลดหน้าเว็บจะเป็น การทำงานของ HTTP

เหตุใดเบราว์เซอร์จึงยังแสดงโฮสต์เก่า

ไม่มีการแพร่กระจายข้อมูล (propagation) ใดๆ เกิดขึ้น ไม่มีเซิร์ฟเวอร์ใดผลักดันการเปลี่ยนแปลงของคุณออกไปหาผู้อื่น Nameserver ที่เป็น authoritative ของคุณจะถือค่าใหม่ทันทีที่คุณบันทึก และสำเนาของคำตอบเดิมที่ถูกแคชไว้จะยังคงมีผลจนกว่าตัวจับเวลาของมันจะหมดลง ตัวจับเวลานั้นคือ TTL (หน่วยเป็นวินาที) ซึ่งเป็นค่าที่ระบุมาพร้อมกับเรคคอร์ดตอนที่ถูกส่งออกไป

สำเนาเหล่านี้อาศัยอยู่ในหลายจุดมากกว่าที่คุณคาดคิด ได้แก่ แคชระยะสั้นของเบราว์เซอร์เอง, stub resolver บนเครื่อง, recursive resolver ที่เครือข่ายนั้นใช้งาน และ resolver ใดๆ ที่ VPN ติดตั้งไว้บนเครื่องไคลเอนต์ แต่ละจุดจะเก็บสำเนาไว้จนกว่าจะครบ TTL ที่ได้รับมา คนสองคนบนสองเครือข่ายอาจเห็นคำตอบที่ต่างกันเป็นเวลาหลายชั่วโมง และเครื่องทั้งสองเครื่องก็กำลังทำงานอย่างถูกต้อง

ตรวจสอบการนับถอยหลังเทียบกับ caching resolver:

dig @1.1.1.1 example.com +noall +answer

ให้รันคำสั่งนี้สองครั้งโดยเว้นระยะห่างกันไม่กี่วินาที ค่า TTL ในคำตอบจะลดลง เมื่อถึงศูนย์ resolver จะทิ้งเรคคอร์ดนั้นและสอบถามไปยัง nameserver ของคุณอีกครั้ง

มีแคชอีกประเภทหนึ่งที่แทบไม่มีใครคำนึงถึง นั่นคือคำตอบที่เป็นค่าว่าง (negative answers) เมื่อ resolver ได้รับแจ้งว่าไม่มีชื่อนั้นอยู่ มันจะแคชค่า NXDOMAIN นั้นไว้ด้วย ตามเวลาที่กำหนดไว้ในฟิลด์สุดท้ายของเรคคอร์ด SOA ในโซนของคุณ

dig example.com SOA +short

ตัวเลขสุดท้ายในบรรทัดนั้นคือ negative TTL ซึ่งมักจะเป็น 3600 ดังนั้นการค้นหา staging.example.com ก่อนที่คุณจะสร้างมันขึ้นมา อาจทำให้เรคคอร์ดนั้นถูกซ่อนจากคุณไปอีกหนึ่งชั่วโมงเต็มหลังจากที่คุณสร้างมันขึ้นมาแล้ว ให้สร้างเรคคอร์ดก่อนแล้วค่อยค้นหา

การเปลี่ยน nameserver นั้นช้ากว่าการเปลี่ยนเรคคอร์ด และเหตุผลเป็นเรื่องของกลไก เรคคอร์ดการมอบหมาย (delegation records) ในโซน .com จะถูกส่งด้วย TTL 172800 วินาที ซึ่งเท่ากับสองวัน ดังนั้น resolver ที่แคช nameserver เก่าของคุณไว้ อาจยังคงสอบถามไปยัง nameserver เดิมได้นานถึงขนาดนั้น นี่คือที่มาของคำแนะนำที่ว่า "ให้รอสูงสุด 48 ชั่วโมง" ซึ่งใช้กับการเปลี่ยน nameserver เท่านั้น ไม่ใช่การแก้ไขเรคคอร์ดทั่วไป

วางแผนการย้ายระบบโดยอิงตาม TTL แทนที่จะฝืนมัน:

1. ลดค่า TTL ของเรคคอร์ดลงเหลือ 300 แล้วบันทึก
2. รอให้เกินระยะเวลาของ TTL เดิม เพื่อให้สำเนาที่แคชไว้ซึ่งมีค่าเก่าหมดอายุลงทั้งหมด
3. เปลี่ยนที่อยู่ (address)
4. เมื่อทราฟฟิกย้ายมาแล้ว ให้ปรับ TTL กลับเป็น 3600 หรือสูงกว่า เพราะ TTL ที่ต่ำหมายความว่า resolver ทุกตัวจะสอบถามมายัง nameserver ของคุณบ่อยขึ้นมาก

วิธีล้างข้อมูลที่เครื่องของคุณถืออยู่:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics จะแสดงส่วนของแคชพร้อมตัวนับ hit และ miss ดังนั้นทันทีที่ล้างแคช การค้นหาครั้งถัดไปจะแสดงเป็น miss เบราว์เซอร์มีแคชแยกต่างหาก ซึ่งหมายความว่า Chrome อาจยังใช้คำตอบเก่าหลังจากแคชของระบบถูกล้างไปแล้ว ให้ล้างแคชของเบราว์เซอร์ที่ chrome://net-internals/#dns ตรวจสอบ /etc/hosts ด้วย เพราะบรรทัดที่ค้างอยู่ในนั้นจะมีความสำคัญเหนือกว่า DNS บนเครื่องนั้นๆ และเฉพาะบนเครื่องนั้นเท่านั้น getent hosts example.com จะแสดงคำตอบที่ระบบจะใช้งานจริง ซึ่งรวมถึง /etc/hosts ด้วย

Wildcard certificates ได้รับการยืนยันด้วย TXT record

CA (certificate authority) จะตรวจสอบสิทธิ์การควบคุมชื่อโดเมนก่อนออกใบรับรองให้ การทำ HTTP-01 challenge จะเป็นการให้บริการไฟล์ผ่านพอร์ต 80 บน hostname นั้นโดยตรง ซึ่งใช้ได้ดีกับชื่อโดเมนเดียว แต่ wildcard certificate ครอบคลุมถึง *.example.com ซึ่งเป็นชุดของ hostname ที่ไม่จำกัดจำนวนและ CA ไม่สามารถดึงไฟล์จาก hostname เหล่านั้นได้ ดังนั้น Let's Encrypt จึงออก wildcard certificate ผ่าน DNS-01 challenge เท่านั้น คุณต้องเผยแพร่ TXT record ที่ _acme-challenge.example.com โดยบรรจุ token ที่ CA มอบให้ และการควบคุมโซน DNS นั้นถือเป็นหลักฐานการยืนยันสิทธิ์

กระบวนการนี้ทำให้ผู้ให้บริการ DNS ของคุณกลายเป็นส่วนหนึ่งของการต่ออายุใบรับรอง Certbot จำเป็นต้องสร้างและลบ TXT record ดังกล่าวในการต่ออายุทุกครั้งโดยที่คุณไม่ต้องดำเนินการเอง จึงจำเป็นต้องมี API และปลั๊กอินที่ตรงกับผู้ให้บริการของคุณ เมื่อการตรวจสอบล้มเหลว ข้อความที่พบบ่อยคือ DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com ซึ่งหมายความว่า CA ได้สอบถามข้อมูลก่อนที่ record จะปรากฏให้เห็น: อาจเป็นเพราะข้อมูลไม่ถูกบันทึก หรือมีการแคชคำตอบที่เป็นค่าว่าง (negative answer) ไว้ ขั้นตอนการดำเนินการทั้งหมดอยู่ใน คู่มือการใช้งาน wildcard certificates ด้วย DNS-01 challenge

เมื่อ VPN เข้าควบคุมตัวแก้ไขชื่อโดเมน (resolver) ของคุณ

โดยปกติแล้วไคลเอนต์ VPN (virtual private network) จะเข้ามาแทนที่ระบบ resolver ของเครื่องในขณะที่เชื่อมต่ออยู่ เนื่องจากหากส่งคำขอค้นหาชื่อโดเมนไปยังเครือข่ายท้องถิ่น เครือข่ายนั้นจะทราบชื่อเว็บไซต์ทุกแห่งที่คุณเข้าชม พฤติกรรมนี้ถือว่าถูกต้อง แต่ก็อาจเกิดความล้มเหลวได้ในสองกรณี

หากอุโมงค์เชื่อมต่อสำเร็จแต่ไม่สามารถแก้ไขชื่อโดเมนได้ในขณะที่การเข้าถึงผ่าน IP address ยังคงใช้งานได้ แสดงว่า resolver ที่ไคลเอนต์ติดตั้งไว้ไม่สามารถเข้าถึงได้จากภายในอุโมงค์นั้น คำสั่ง ping 1.1.1.1 ทำงานสำเร็จ แต่ curl https://example.com กลับคืนค่าเป็น curl: (6) Could not resolve host: example.com ในทางกลับกัน หากอุโมงค์เชื่อมต่อสำเร็จแต่การค้นหาชื่อโดเมนยังคงส่งไปยังเครือข่ายท้องถิ่นที่คุณใช้งานอยู่ ทราฟฟิกของคุณจะถูกส่งผ่านอุโมงค์ แต่ resolver ท้องถิ่นจะยังคงเห็นชื่อโดเมนทุกชื่อที่คุณร้องขอ

resolvectl status

คำสั่งดังกล่าวจะแสดง resolver ที่ใช้งานอยู่สำหรับแต่ละลิงก์ เพื่อให้คุณตรวจสอบได้ว่าอุโมงค์ได้ติดตั้ง resolver ตัวใดและเป็นตัวที่คุณต้องการหรือไม่ อุโมงค์ WireGuard จะตั้งค่าส่วนนี้จากบรรทัด DNS = ในไฟล์กำหนดค่าของไคลเอนต์ และเนื้อหา การแก้ไขปัญหา DNS เมื่อ WireGuard เข้าควบคุม resolver จะครอบคลุมรายละเอียดเกี่ยวกับกรณีของ systemd-resolved และ resolvconf ไว้โดยละเอียด

รหัสตอบกลับและความหมายของแต่ละรหัส

• NXDOMAIN: เซิร์ฟเวอร์ที่มีอำนาจหน้าที่ (authoritative server) ระบุว่าไม่มีชื่อโดเมนนี้อยู่ ให้ตรวจสอบการสะกด ตรวจสอบว่ามีการใส่ suffix ของโดเมนซ้ำหรือไม่ และตรวจสอบว่าคุณได้แก้ไข zone ที่ delegation ชี้ไปอย่างถูกต้องแล้ว
• NOERROR พร้อมกับ ANSWER SECTION ที่ว่างเปล่า: ชื่อโดเมนมีอยู่จริง แต่ไม่มีระเบียน (record) ประเภทที่คุณร้องขอ ตัวอย่างเช่น การร้องขอ AAAA ในขณะที่มีเพียง A จะส่งผลเช่นนี้
• SERVFAIL: ตัวแก้ไข (resolver) พยายามแล้วแต่ไม่สามารถหาคำตอบได้ สาเหตุทั่วไปมี 2 ประการ คือเซิร์ฟเวอร์ที่มีอำนาจหน้าที่ไม่ตอบกลับ และการตรวจสอบความถูกต้องของ DNSSEC (domain name system security extensions) ล้มเหลว ให้ทดสอบด้วย dig @1.1.1.1 example.com A +cd ซึ่งจะเป็นการปิดการตรวจสอบความถูกต้อง หากได้รับคำตอบเมื่อใช้ +cd และ SERVFAIL โดยไม่ใช้การตรวจสอบ แสดงว่าปัญหาอยู่ที่ลายเซ็นดิจิทัล ซึ่งมักเกิดขึ้นหลังจากการย้าย nameserver ในขณะที่ฝั่ง parent ยังคงเผยแพร่ระเบียน DS (delegation signer) ชุดเก่าอยู่
• REFUSED: เซิร์ฟเวอร์ที่คุณสอบถามจะไม่ตอบคำถามนั้น โดยปกติเป็นเพราะคุณชี้ dig ไปยังเซิร์ฟเวอร์ที่มีอำนาจหน้าที่สำหรับโดเมนที่เซิร์ฟเวอร์นั้นไม่ได้ดูแล
• ;; connection timed out; no servers could be reached: dig ไม่สามารถติดต่อ resolver ได้ นี่เป็นปัญหาด้านเครือข่ายหรือปัญหาที่ตัว resolver ฝั่งคุณเอง ดังนั้นจึงไม่ใช่ปัญหาที่ตัวโดเมน

ping: example.com: Temporary failure in name resolution เป็นความล้มเหลวประเภทเดียวกันที่รายงานโดย glibc แทนที่จะเป็น dig

คุณควรใช้งาน nameserver บน VPS ของคุณเองหรือไม่

คุณสามารถทำได้ bind9, knot หรือ nsd จะทำหน้าที่ให้บริการ zone จากเซิร์ฟเวอร์ของคุณ ซึ่งจะช่วยให้คุณเรียนรู้เรื่อง DNS ได้มากกว่าการใช้แผงควบคุมใดๆ อย่างไรก็ตาม ข้อโต้แย้งในเรื่องนี้เป็นประเด็นในทางปฏิบัติ โดเมนควรมี nameserver อย่างน้อยสองแห่งที่อยู่บนเครือข่ายแยกจากกัน ดังนั้นการใช้ VPS เพียงเครื่องเดียวจึงกลายเป็นจุดที่อาจทำให้ทุกบริการบนโดเมนล่มได้ รวมถึงอีเมลด้วย nameserver ที่ตั้งชื่ออยู่ภายในโดเมนที่ตนเองให้บริการจำเป็นต้องมี glue records ที่ผู้รับจดทะเบียนโดเมน ซึ่งก็คือที่อยู่ของ ns1.example.com ที่ถูกเก็บไว้ใน parent zone เพราะหากไม่มีสิ่งนี้ การค้นหาข้อมูลจะไม่สามารถเริ่มต้นได้ เมื่อ resolver ไม่สามารถเข้าถึง nameserver ของคุณได้ มันจะไม่เปลี่ยนไปเรียกเว็บไซต์ของคุณแทน แต่โดเมนทั้งหมดจะหายไปสำหรับผู้ใช้นั้น การใช้บริการ DNS แบบโฮสต์ที่มี API จึงเป็นทางเลือกที่มีความเสี่ยงต่ำกว่าสำหรับคนส่วนใหญ่ ส่วนการรัน caching resolver บน VPS เพื่อใช้งานภายในเครื่องของคุณเองนั้นเป็นงานที่แตกต่างออกไป และมีความรับผิดชอบที่น้อยกว่ามาก

FAQ

ทำไมการเปลี่ยนแปลง DNS ของฉันจึงยังไม่มีผล

ไม่มีการแพร่กระจายข้อมูลใดๆ ทั้งสิ้น Nameserver ที่เป็น authoritative จะเก็บค่าใหม่ทันทีที่คุณบันทึก และ resolver ทุกตัวที่เคยสอบถามไปก่อนหน้านี้จะเก็บข้อมูลในแคชไว้จนกว่าค่า TTL ที่ได้รับมาจะหมดอายุ ให้สอบถามไปยัง authoritative server โดยตรงด้วย dig @ns1.your-dns-host.net example.com A +short หากคำสั่งนั้นส่งคืนที่อยู่ใหม่ แสดงว่าการเปลี่ยนแปลงมีผลแล้ว และสิ่งที่เหลืออยู่ทั้งหมดเป็นเพียงเรื่องของแคช หากคุณเปลี่ยน nameserver แทนที่จะเปลี่ยนเฉพาะ record ให้คาดการณ์ว่าอาจใช้เวลานานกว่านั้นมาก เนื่องจากข้อมูลการมอบหมายสิทธิ์ (delegation) จาก TLD มักมีค่า TTL สูงถึงสองวัน

ฉันจะตรวจสอบได้อย่างไรว่าโดเมนของฉันใช้ nameserver ใดอยู่จริง

dig example.com NS +short จะแสดง nameserver ที่ตอบกลับสำหรับโดเมนนั้นในปัจจุบัน และ dig +trace example.com จะแสดงลำดับการอ้างอิงจาก root รวมถึงข้อมูลการมอบหมายสิทธิ์ที่เซิร์ฟเวอร์ TLD ส่งออกมา หากชื่อเหล่านั้นไม่ใช่ผู้ให้บริการที่คุณกำลังแก้ไขผ่านแผงควบคุม นั่นคือจุดที่เกิดข้อผิดพลาด ให้คุณแก้ไข record ที่ผู้ให้บริการซึ่งระบุไว้ใน delegation หรือเปลี่ยนการตั้งค่า delegation ที่ผู้รับจดทะเบียนโดเมนของคุณให้ชี้ไปยังที่ที่คุณต้องการ

โดเมนของฉัน resolve ได้แล้ว แต่เว็บไซต์ยังโหลดไม่ขึ้น ต้องทำอย่างไรต่อ

งานของ DNS สิ้นสุดลงทันทีที่ dig example.com A +short ส่งคืนที่อยู่เซิร์ฟเวอร์ของคุณ หลังจากนั้นปัญหาจะอยู่ที่การเชื่อมต่อ หาก curl -I http://example.com ส่งคืนค่า Connection refused หมายความว่าไม่มีบริการใดกำลังรอรับการเชื่อมต่อที่พอร์ตนั้น หากคำขอค้างจนหมดเวลา (timeout) หมายความว่า firewall ได้ทิ้งแพ็กเก็ตนั้นไป ให้ตรวจสอบว่าเว็บเซิร์ฟเวอร์ของคุณกำลังทำงานและผูกอยู่กับ public address แล้ว จากนั้นจึงตรวจสอบ firewall บนเซิร์ฟเวอร์และ firewall ของเครือข่ายแยกต่างหากในแผงควบคุมของผู้ให้บริการของคุณ

ทำไมฉันถึงใส่ CNAME ที่ root domain ไม่ได้

CNAME ระบุว่าชื่อหนึ่งเป็นนามแฝงของอีกชื่อหนึ่ง และชื่อที่มี CNAME จะไม่ได้รับอนุญาตให้มี record อื่นใดอีก root domain ของคุณจำเป็นต้องมี SOA และ NS record เพื่อให้ดำรงสถานะเป็น zone ได้ จึงไม่สามารถเป็น CNAME ได้เช่นกัน ให้ใช้ record ประเภท A เพื่อเก็บที่อยู่ไว้ที่ root หรือใช้ฟีเจอร์ของผู้ให้บริการที่เรียกว่า ALIAS, ANAME หรือ CNAME flattening ซึ่งจะทำหน้าที่จัดเก็บชื่อและตอบกลับคำถามด้วยที่อยู่ที่ชื่อนั้น resolve ได้ในปัจจุบัน