บทความ 10

จากชื่อโดเมนไปถึง Server: DNS, Name Server และ Record ทำงานอย่างไร

ตามเส้นทางตั้งแต่ผู้ใช้พิมพ์ siscorp.co.th ไปจน Browser พบ IP และเชื่อมต่อ Server พร้อมอธิบาย A, AAAA, CNAME, MX, TXT, CAA, TTL, HTTPS และจุดเสี่ยงที่เจ้าของโดเมนต้องป้องกัน

20 นาที เจ้าของเว็บไซต์, ผู้ดูแลระบบ, Marketing และ Tech Lead 2026-07-17

Infographic ภาพรวม

WebBrowser

DNSDNS

IPIP address

TLSHTTPS / TLS

NSA / AAAAMX / TXT

สิ่งที่เกิดในไม่กี่วินาที

ลองเริ่มจากเหตุการณ์ที่คนทำงานพบจริง

ชื่อเว็บไม่ใช่ที่อยู่ของ Server แต่เป็นชื่อที่ DNS ช่วยแปลให้

คนจำชื่อ siscorp.co.th ได้ง่ายกว่าเลข IP แต่ Browser ต้องรู้ว่าจะส่งข้อมูลไปหาเครื่องใด จึงถามระบบ DNS ซึ่งทำหน้าที่คล้ายสารบัญแบบกระจายศูนย์ คำตอบอาจผ่าน cache หลายชั้นก่อนถึงผู้ให้คำตอบตัวจริง หลังได้ IP แล้ว Browser ยังต้องเปิดการเชื่อมต่อ ตรวจใบรับรอง HTTPS และส่งชื่อ host ไปยังปลายทาง จึงจะได้รับหน้าเว็บกลับมา ทุกชั้นมีหน้าที่ต่างกัน และการแก้ผิดจุดอาจทำให้เว็บ อีเมล หรือทั้งโดเมนหยุดทำงานได้

คำที่คุณจะเจอในบทความ

แต่ละคำหมายถึงอะไร และเกี่ยวข้องกับระบบตรงไหน

ไม่ต้องจำทั้งหมดในครั้งเดียว อ่านเพื่อให้รู้หน้าที่คร่าว ๆ ก่อน แล้วค่อยกลับมาเทียบเมื่อเจอคำนั้นในเนื้อหา

Domain Name: ชื่อที่จดทะเบียนเพื่อใช้อ้างอิงบริการ เช่น siscorp.co.th โดยมีวันหมดอายุและผู้ถือสิทธิ์
Registrar: บริษัทที่รับจดและจัดการสิทธิ์โดเมน เช่น ผู้ถือครอง วันหมดอายุ และ Name Server
DNS Resolver: ระบบที่รับคำถามจากอุปกรณ์ผู้ใช้ แล้วค้นหรือใช้ cache เพื่อนำคำตอบ DNS กลับมา
Authoritative DNS: DNS Server ที่ถือข้อมูลต้นฉบับของ Zone และมีอำนาจตอบ Record ของโดเมนนั้น
Name Server (NS): ชื่อ Server ที่ประกาศว่า Authoritative DNS ของโดเมนอยู่ที่ใด มักมีมากกว่าหนึ่งชื่อเพื่อความทนทาน
Record: ข้อมูลหนึ่งรายการใน DNS เช่น ชื่อ www ชี้ไป IP ใด หรือโดเมนนี้รับอีเมลที่ใด
TTL: จำนวนวินาทีที่ Resolver อนุญาตให้เก็บคำตอบไว้ใน cache ก่อนถามใหม่
TLS / HTTPS: การเข้ารหัสการเชื่อมต่อและการตรวจว่า Server แสดงใบรับรองที่ตรงกับชื่อโดเมน

ถ้าคุณไม่ได้ทำงานสายเทคนิค ให้เริ่มจากส่วนนี้

จากชื่อโดเมนไปถึง Server: DNS, Name Server และ Record ทำงานอย่างไร

Registrar ดูแลสิทธิ์ความเป็นเจ้าของโดเมน ส่วน DNS Hosting เก็บ Record และตอบคำถามว่าแต่ละชื่อชี้ไปไหน

Name Server คือรายชื่อ DNS Server ที่มีอำนาจตอบข้อมูลของโดเมน ไม่ใช่ IP ของเว็บไซต์โดยตรง

MX ใช้กำหนด Server รับอีเมล ส่วน A/AAAA/CNAME ใช้กับการหาเส้นทางของชื่อ และ TXT ใช้ยืนยันนโยบายหรือความเป็นเจ้าของ

ป้องกันโดเมนด้วย MFA, Registrar Lock, สิทธิ์ที่จำกัด, DNSSEC เมื่อเหมาะสม และบันทึกการเปลี่ยนแปลง

ภาพขยายความแบบเคลื่อนไหว

ดูความสัมพันธ์ของแต่ละขั้น ก่อนลงรายละเอียด

เลือกแต่ละขั้นเพื่อดูว่าเกิดอะไรขึ้น ต้องตรวจข้อมูลใด และผลจากขั้นหนึ่งส่งต่อไปยังขั้นถัดไปอย่างไร

ขั้น 01 / 06

01 / ใครถือสิทธิ์

เริ่มที่ Registrar แล้วมอบหมายการตอบ DNS ให้ Name Server

เมื่อจด siscorp.co.th ผู้จดไม่ได้ซื้อ Server แต่ได้สิทธิ์ใช้ชื่อในช่วงเวลาหนึ่ง บัญชี Registrar จึงเป็นกุญแจระดับสูง เพราะผู้ที่แก้ Name Server ได้สามารถเปลี่ยนเส้นทางเว็บและอีเมลทั้งโดเมน เราระบุที่ Registrar ว่าโดเมนนี้ให้ Name Server ชุดใดตอบ จากนั้นจึงไปสร้าง Record ใน DNS Hosting ของชุดนั้น การเปลี่ยน Record ในผู้ให้บริการที่ไม่ได้ถูก delegate จะไม่เกิดผล แม้หน้าจอจะแสดงว่าบันทึกสำเร็จ

ประเด็นที่ต้องตรวจให้เห็นหลักฐาน

เปิด MFA ที่ Registrar
ใช้บัญชีบริษัท ไม่ผูกกับบุคคลเดียว
เปิด Registrar/Transfer Lock
ตั้งเตือนวันหมดอายุและต่ออายุอัตโนมัติ

รายละเอียดเชิงลึก

ค่อย ๆ ดูทีละส่วนว่าเกิดอะไรขึ้น และควรเตรียมอย่างไร

เราเริ่มจากผลที่คนใช้งานหรือธุรกิจจะพบ แล้วจึงอธิบายว่าทีมเทคนิคต้องตรวจอะไร มีตัวอย่างแบบไหน และจุดใดไม่ควรปล่อยให้เดาเอง

01 / ใครถือสิทธิ์

เริ่มที่ Registrar แล้วมอบหมายการตอบ DNS ให้ Name Server

เปิด MFA ที่ Registrar
ใช้บัญชีบริษัท ไม่ผูกกับบุคคลเดียว
เปิด Registrar/Transfer Lock
ตั้งเตือนวันหมดอายุและต่ออายุอัตโนมัติ
เก็บรายชื่อ Name Server ปัจจุบัน

02 / เส้นทางคำถาม

Browser ไม่ได้ถาม Server เว็บทันที แต่ค่อย ๆ หาผู้ที่ตอบได้

เมื่อพิมพ์ชื่อ Browser จะตรวจ cache ของตัวเองและระบบปฏิบัติการก่อน หากไม่มีจึงถาม Recursive Resolver ของเครือข่าย Resolver อาจมีคำตอบอยู่แล้ว ถ้าไม่มีก็ถาม Root ว่าใครดูแล .th จากนั้นถามระบบ .th ว่าใครดูแล co.th และตามต่อจนพบ Name Server ของ siscorp.co.th แล้วจึงขอ Record ที่ต้องการ คำตอบถูก cache ตาม TTL จึงเป็นเหตุผลว่าทำไมคนสองคนอาจเห็น IP คนละค่าในช่วงเปลี่ยนระบบ

เส้นทางแบบย่อ

เปิด siscorp.co.th

Browser ถามตัวช่วยค้นหา DNS ก่อน หากยังไม่มีคำตอบ ตัวช่วยจะไล่ถามจากระบบกลางจนพบ Name Server ที่ดูแล siscorp.co.th แล้วอ่าน Record เพื่อได้ IP หลังจากนั้น Browser จึงเชื่อมต่อ ตรวจใบรับรอง HTTPS และขอหน้าเว็บจาก Server

03 / อ่าน Record

แต่ละ Record ตอบคนละคำถาม และ MX ไม่ได้ใช้เปิดหน้าเว็บ

A ชี้ชื่อไป IPv4 และ AAAA ชี้ไป IPv6 ส่วน CNAME บอกว่าชื่อนี้ใช้นามแฝงของชื่ออื่น จึงต้องค้นต่อ ผู้ให้บริการ Cloud บางรายมี Alias/ANAME เพื่อชี้โดเมนหลักไป resource ที่ IP เปลี่ยนได้ MX ระบุชื่อ Mail Server ที่รับอีเมลและมีค่า priority; ค่าต่ำกว่ามักถูกเลือกก่อน TXT เก็บข้อความสำหรับยืนยันบริการ รวมทั้ง SPF, DKIM และ DMARC ที่ช่วยลดการปลอมอีเมล CAA จำกัดว่าผู้ออกใบรับรองรายใดออก TLS Certificate ให้โดเมนได้ Record ต้องแก้ตามหน้าที่ ไม่ควรลบของเดิมเพียงเพราะไม่รู้จัก

ถ้าคุณเป็นคนออกแบบหรือดูแลระบบ

ตามมาตรฐาน DNS ทั่วไป CNAME ไม่ควรใช้ร่วมกับ Record อื่นที่ชื่อเดียวกัน และไม่ใช้ที่ Zone Apex; ผู้ให้บริการ Cloud จึงสร้าง Alias/flattening เป็นความสามารถเฉพาะบริการ

04 / DNS ของอีเมล

MX บอกว่าจะส่งเมลไปไหน ส่วน SPF, DKIM และ DMARC ช่วยบอกว่าเมลใดน่าเชื่อถือ

เมื่อมีคนส่งหา wannapong@siscorp.co.th ระบบผู้ส่งจะถาม MX ของ siscorp.co.th แล้วเชื่อมต่อ Mail Server ตามลำดับ priority แต่การรับได้อย่างเดียวไม่พอสำหรับชื่อเสียงการส่ง SPF ระบุ Server ที่ได้รับอนุญาตให้ส่ง, DKIM ใช้ลายเซ็นดิจิทัลให้ปลายทางตรวจว่าเนื้อหาไม่ถูกแก้ และ DMARC กำหนดนโยบายเมื่อการตรวจไม่ผ่านพร้อมส่งรายงานกลับ การตั้งค่าผิดอาจทำให้อีเมลเข้า Spam หรือถูกผู้ไม่หวังดีปลอมชื่อบริษัทได้

05 / เปลี่ยนระบบ

DNS Propagation ส่วนใหญ่คือ cache เดิมที่ยังไม่หมดอายุ ไม่ใช่ข้อมูลเดินทางช้าแบบไฟล์

ก่อนย้าย Server ให้ลด TTL ล่วงหน้าอย่างน้อยหนึ่งรอบ TTL เดิม เตรียมปลายทางใหม่ให้ตอบทั้งชื่อและ HTTPS แล้วค่อยเปลี่ยน Record ช่วงเปลี่ยนควรเปิดระบบเก่าไว้ เพราะ Resolver บางแห่งยังถือคำตอบเดิม หลังตรวจผู้ใช้และ log แล้วจึงเพิ่ม TTL กลับ การตั้ง TTL ต่ำตลอดไม่ได้ทำให้เว็บเร็วขึ้น แต่เพิ่มจำนวนคำถาม DNS และไม่ได้บังคับให้ cache ที่ผิดมาตรฐานล้างทันที

06 / ป้องกันชื่อธุรกิจ

โดเมนเป็นจุดรวมความไว้วางใจของเว็บ อีเมล และ Certificate

หากบัญชี Registrar หรือ DNS ถูกยึด ผู้โจมตีอาจชี้เว็บไปหน้าปลอม เปลี่ยน MX เพื่อรับอีเมล หรือออก Certificate บางกรณี จึงต้องใช้ MFA ที่ไม่พึ่ง SMS เมื่อทำได้, least privilege, approval สำหรับการเปลี่ยนสำคัญ, audit log และ break-glass account ที่เก็บอย่างปลอดภัย DNSSEC ช่วยให้ Resolver ตรวจลายเซ็นคำตอบและลดการปลอมข้อมูลระหว่างทาง แต่ต้องวางขั้นตอนหมุน key และเปลี่ยนผู้ให้บริการให้ถูก เพราะ chain of trust ที่ขาดจะทำให้โดเมน resolve ไม่ได้

ก่อนนำไปใช้ ลองตรวจทีละข้อนี้

ระบุ Registrar และเจ้าของบัญชี

เปิด MFA และ Registrar Lock

บันทึก Name Server ที่ถูกใช้งาน

ทำบัญชี Record พร้อม owner และเหตุผล

แยก Record เว็บ อีเมล และ verification

ตรวจ SPF, DKIM และ DMARC

วาง TTL ก่อน migration

ทดสอบ DNS จากหลาย Resolver

ตรวจ TLS Certificate หลังเปลี่ยน

เก็บ audit log และแผนกู้บัญชี

แหล่งอ้างอิง