DNS คืออะไร? อธิบายการทำงาน + ประเภท DNS Record ฉบับเข้าใจง่าย (2026) | Southern Whale

ลองนึกภาพว่าคุณเพิ่งซื้อโดเมนใหม่ ตั้งค่าเว็บเสร็จเรียบร้อย กดเข้าเว็บตัวเอง… แต่ขึ้นว่า “This site can’t be reached” ทั้งที่เซิร์ฟเวอร์ก็ยังออนไลน์อยู่ดี ๆ — หรืออีกสถานการณ์ที่เจอบ่อยกว่า: คุณย้ายโฮสต์ใหม่ แก้ค่าเสร็จแล้ว แต่เพื่อนบอกว่ายังเห็นเว็บเก่าอยู่เลย ทั้งที่คุณเห็นเว็บใหม่แล้ว ปัญหาทั้งสองอย่างนี้มีต้นตอเดียวกัน นั่นคือ DNS

DNS เป็นหนึ่งในระบบที่ “ทำงานเงียบ ๆ อยู่เบื้องหลัง” ของอินเทอร์เน็ตทั้งโลก ทุกครั้งที่คุณพิมพ์ชื่อเว็บลงเบราว์เซอร์ เปิดแอป สั่งอีเมล หรือแม้แต่กดดูคลิป TikTok — เบื้องหลังมีการ “ถาม DNS” เกิดขึ้นนับสิบครั้งโดยที่คุณไม่รู้ตัว และเมื่อ DNS มีปัญหา เว็บทั้งเว็บก็ล่มได้ในพริบตา (เหตุการณ์เว็บใหญ่ระดับโลกล่มหลายครั้งในช่วงไม่กี่ปีมานี้ ต้นเหตุก็คือ DNS config ผิดพลาดนี่แหละ)

บทความนี้จะพาคุณเข้าใจ DNS แบบครบวงจร — ตั้งแต่ “DNS คืออะไร” แบบเห็นภาพ, การทำงานทีละขั้นจาก resolver ไป root ไป TLD ไป authoritative, ประเภท DNS record ทุกตัวที่คุณต้องรู้พร้อมตารางและตัวอย่างจริง, เรื่อง nameserver, TTL และ DNS propagation, ไปจนถึงวิธีตั้งค่า DNS ตอนทำเว็บใหม่/ย้ายโฮสต์/ตั้งอีเมล และการแก้ปัญหา DNS ที่พบบ่อย — เขียนแบบที่คนไม่ใช่สาย IT ก็อ่านรู้เรื่อง แต่คนสายเทคก็ใช้เป็นเอกสารอ้างอิงได้

DNS คืออะไร? สมุดโทรศัพท์ของอินเทอร์เน็ต

DNS (Domain Name System) คือระบบที่ทำหน้าที่ “แปลชื่อโดเมนที่คนอ่านง่าย ให้กลายเป็นเลข IP address ที่เครื่องคอมพิวเตอร์เข้าใจ” พูดง่าย ๆ คือมันคือ สมุดโทรศัพท์ของอินเทอร์เน็ต — คุณจำชื่อเพื่อนได้ว่า “สมชาย” แต่โทรศัพท์ต้องใช้เบอร์ 08x-xxx-xxxx ในการต่อสาย DNS ก็ทำหน้าที่เปิดสมุดให้ว่าชื่อนี้ตรงกับเบอร์ไหน

ในโลกอินเทอร์เน็ต มนุษย์จำชื่อเว็บอย่าง southernwhale.com ได้ง่าย แต่เครื่องเซิร์ฟเวอร์ไม่ได้คุยกันด้วยชื่อ — มันคุยกันด้วย IP address เช่น 104.21.x.x (IPv4) หรือ 2606:4700:xxxx:: (IPv6) หน้าที่ของ DNS คือเป็นตัวกลางที่บอกว่า “ชื่อ southernwhale.com อยู่ที่ IP นี้นะ” เพื่อให้เบราว์เซอร์รู้ว่าต้องไปต่อสายกับเซิร์ฟเวอร์เครื่องไหน

เหตุผลที่เราต้องมี DNS แทนที่จะจำ IP กันตรง ๆ มีอยู่หลายข้อ:

• มนุษย์จำชื่อได้ดีกว่าจำตัวเลข — google.com ง่ายกว่า 142.250.x.x มาก
• IP เปลี่ยนได้ แต่ชื่อโดเมนไม่ต้องเปลี่ยน — ถ้าคุณย้ายเว็บไปเซิร์ฟเวอร์ใหม่ (IP ใหม่) คุณแค่แก้ที่ DNS ครั้งเดียว ผู้ใช้ยังพิมพ์ชื่อเดิมได้
• หนึ่งชื่อชี้ได้หลาย IP — เว็บใหญ่ ๆ กระจายโหลดไปหลายเซิร์ฟเวอร์ผ่าน DNS ได้
• บริการต่าง ๆ บนโดเมนเดียว — เว็บ, อีเมล, subdomain ทั้งหมดจัดการผ่าน DNS ของโดเมนเดียวกัน

จุดที่หลายคนเข้าใจผิดคือคิดว่า DNS เก็บแค่ “IP ของเว็บ” จริง ๆ แล้ว DNS เก็บข้อมูลหลายชนิดมากกว่านั้น ทั้ง IP ของเว็บ, เซิร์ฟเวอร์อีเมล, ข้อมูลยืนยันตัวตน, และ config ของบริการต่าง ๆ — ทั้งหมดนี้เก็บในรูปแบบที่เรียกว่า DNS Record ซึ่งเราจะลงรายละเอียดในหัวข้อถัด ๆ ไป

DNS ทำงานยังไง? เส้นทางจาก resolver → root → TLD → authoritative

ทีนี้มาดูส่วนที่สนุกที่สุด — เวลาคุณพิมพ์ southernwhale.com แล้วกด Enter เกิดอะไรขึ้นบ้างใน 0.1 วินาทีนั้น? คำตอบคือมีการ “ถามต่อกันเป็นทอด ๆ” ผ่านเซิร์ฟเวอร์ 4 ประเภท เรียกกระบวนการนี้ว่า DNS Resolution ลองดูตามขั้นตอนนี้

1. เบราว์เซอร์ถาม DNS Resolver — เครื่องคุณ (ผ่าน ISP หรือ DNS อย่าง 1.1.1.1 / 8.8.8.8) ทำหน้าที่เป็น Recursive Resolver หรือ “ตัวกลางที่อาสาไปหาคำตอบให้” ถ้า resolver เคยถามชื่อนี้มาก่อนและยังอยู่ใน cache มันจะตอบกลับทันที (จบเลย ไม่ต้องไปต่อ)
2. Resolver ถาม Root Server — ถ้าไม่มีใน cache resolver จะเริ่มไล่ถามจากบนสุด คือ Root Nameserver (มี 13 ชุดหลักทั่วโลก ใช้ชื่อ a.root-servers.net ถึง m.) root จะไม่รู้คำตอบสุดท้าย แต่จะบอกว่า “สำหรับ .com ไปถามที่ TLD server ของ .com นะ”
3. Resolver ถาม TLD Server — TLD (Top-Level Domain) Nameserver คือเซิร์ฟเวอร์ที่ดูแลนามสกุลโดเมน เช่น .com, .net, .org, .th, .co.th มันจะบอกว่า “โดเมน southernwhale.com ใช้ authoritative nameserver อยู่ที่ไหน” (เช่น ชี้ไป Cloudflare หรือผู้ให้บริการ DNS ของคุณ)
4. Resolver ถาม Authoritative Nameserver — นี่คือเซิร์ฟเวอร์ที่ “เก็บคำตอบจริง” ของโดเมนคุณ มันจะตอบกลับมาว่า southernwhale.com = IP เท่านี้ resolver ก็เอาคำตอบนี้ส่งกลับให้เบราว์เซอร์ และเก็บ cache ไว้ตาม TTL ที่กำหนด

เพื่อให้เห็นภาพชัดขึ้น ลองเทียบกับการ “หาบ้านเพื่อน” ที่คุณไม่รู้ที่อยู่: คุณถามคนที่ปากซอยใหญ่ (root) เขาบอกให้ไปถามที่ป้อมยาม (TLD) ป้อมยามบอกให้ไปถามที่บ้านหัวหน้าหมู่บ้าน (authoritative) แล้วหัวหน้าหมู่บ้านบอกบ้านเลขที่จริง (IP) — ครั้งหน้าคุณจำได้แล้ว ไม่ต้องถามใหม่ทั้งหมด (cache)

เกร็ดสำคัญ: ขั้นตอนทั้งหมดนี้เกิดขึ้นภายในไม่กี่ ms เพราะ resolver ส่วนใหญ่มี cache ของ TLD และ root อยู่แล้ว ในทางปฏิบัติการ query แรกอาจใช้ 20-120ms แต่ query ถัด ๆ มาที่อยู่ใน cache แล้วจะเร็วระดับ <5ms — และนี่คือเหตุผลที่ DNS ที่เร็วมีผลต่อ TTFB และความเร็วเว็บโดยรวม (อ่านเพิ่มเรื่อง TTFB และการเพิ่มความเร็ว server response)

ความเข้าใจเรื่องการทำงานแบบเป็นทอด ๆ นี้สำคัญมาก เพราะมันอธิบายได้ว่าทำไม “การเปลี่ยน DNS ถึงไม่ได้เห็นผลทันที” — เพราะแต่ละจุดในเส้นทางนี้มี cache ของตัวเอง ซึ่งเราจะพูดถึงในหัวข้อ TTL และ propagation

ประเภทของ DNS Record: A, AAAA, CNAME, MX, TXT, NS, SOA

หัวใจของการตั้งค่า DNS คือการเข้าใจ DNS Record แต่ละชนิด — มันคือ “บรรทัดข้อมูล” ที่บอกว่าชื่อไหนชี้ไปไหน หรือเก็บข้อมูลอะไร เวลาคุณเข้าหน้า DNS management ของผู้ให้บริการ คุณจะเห็น record เหล่านี้เรียงกันเป็นตาราง มาดูทีละตัวพร้อมตัวอย่างจริง

Record	ทำหน้าที่อะไร	ตัวอย่างค่า	ใช้เมื่อไหร่
A	ชี้ชื่อโดเมนไปยัง IPv4	@ → 104.21.45.12	ชี้เว็บ/subdomain ไปเซิร์ฟเวอร์
AAAA	ชี้ชื่อโดเมนไปยัง IPv6	@ → 2606:4700::6815	รองรับ IPv6 (ควรมีคู่กับ A)
CNAME	ชี้ชื่อหนึ่งไปยังอีกชื่อหนึ่ง (alias)	www → southernwhale.com	subdomain ที่ตามชื่ออื่น
MX	ระบุเซิร์ฟเวอร์รับอีเมลของโดเมน	@ → mx.google.com (priority 1)	ตั้งอีเมลโดเมน (เช่น Google Workspace)
TXT	เก็บข้อความ/ข้อมูลยืนยัน	v=spf1 include:_spf.google.com ~all	SPF, DKIM, DMARC, ยืนยันโดเมน
NS	ระบุ authoritative nameserver ของโดเมน	ns1.cloudflare.com	กำหนดว่าใครดูแล DNS โดเมนนี้
SOA	เก็บข้อมูลควบคุมหลักของ zone	serial, refresh, TTL ฯลฯ	มีอัตโนมัติ 1 record ต่อโดเมน

มาดูรายละเอียดที่ใช้บ่อยกัน:

A และ AAAA Record — ชี้ชื่อไปยัง IP

A record เป็น record พื้นฐานที่สุด ทำหน้าที่ชี้ชื่อโดเมนไปยัง IPv4 address เช่น southernwhale.com → 104.21.45.12 ส่วน AAAA record (อ่านว่า “ควอด-เอ”) ทำหน้าที่เดียวกันแต่ชี้ไป IPv6 address ในปี 2026 การมี AAAA record คู่กับ A เป็นเรื่องที่ควรทำ เพราะผู้ใช้มือถือและ ISP จำนวนมากใช้ IPv6 แล้ว — ถ้าไม่มี AAAA ผู้ใช้กลุ่มนี้จะถูกบังคับให้ fallback กลับไป IPv4 ซึ่งช้ากว่าเล็กน้อย

CNAME Record — ชื่อเล่นที่ชี้ไปชื่อจริง

CNAME (Canonical Name) คือการสร้าง “ชื่อเล่น” ที่ชี้ไปอีกชื่อหนึ่ง แทนที่จะชี้ไป IP ตรง ๆ เคสที่เจอบ่อยที่สุดคือ www.southernwhale.com → southernwhale.com เพื่อให้ทั้งแบบมี www และไม่มี www เข้าเว็บเดียวกันได้ ข้อดีคือถ้า IP ของชื่อหลักเปลี่ยน CNAME จะตามอัตโนมัติ ข้อควรระวัง: ห้ามใช้ CNAME ที่ root domain (@) ในระบบ DNS แบบดั้งเดิม — ต้องใช้ A record หรือฟีเจอร์ “CNAME flattening” ของผู้ให้บริการอย่าง Cloudflare แทน

MX Record — เซิร์ฟเวอร์รับอีเมล

MX (Mail Exchange) บอกว่าอีเมลที่ส่งมาที่ @southernwhale.com ต้องวิ่งไปที่เซิร์ฟเวอร์ไหน MX record มี priority (เลขยิ่งน้อยยิ่งสำคัญก่อน) เพื่อทำ failover เช่น ถ้าใช้ Google Workspace คุณจะตั้ง MX ชี้ไป smtp.google.com ตามที่ Google กำหนด จุดที่คนพลาดบ่อย: MX กับ A เป็นคนละเรื่องกัน — เว็บเข้าได้ไม่ได้แปลว่าอีเมลใช้ได้ ต้องตั้ง MX แยกต่างหาก

TXT Record — ข้อความและการยืนยันตัวตน

TXT record เก็บข้อความอิสระ ใช้งานหลักในยุคนี้คือ ความปลอดภัยของอีเมล ได้แก่:

• SPF — บอกว่าเซิร์ฟเวอร์ไหนมีสิทธิ์ส่งอีเมลในนามโดเมนคุณ
• DKIM — ลายเซ็นดิจิทัลที่พิสูจน์ว่าอีเมลไม่ถูกแก้ไขระหว่างทาง
• DMARC — นโยบายว่าจะทำยังไงกับอีเมลที่ไม่ผ่าน SPF/DKIM
• Domain verification — ใช้ยืนยันความเป็นเจ้าของโดเมนกับ Google Search Console, Google Workspace, Facebook ฯลฯ

NS และ SOA Record — โครงสร้างของ zone

NS (Nameserver) record บอกว่า authoritative nameserver ของโดเมนนี้คือใคร เช่น ถ้าคุณใช้ Cloudflare มันจะเป็น nia.ns.cloudflare.com ส่วน SOA (Start of Authority) เป็น record พิเศษที่มีหนึ่งเดียวต่อ zone เก็บข้อมูลควบคุมหลัก เช่น serial number (เวอร์ชันของ zone), ค่า refresh, retry และ minimum TTL — ปกติระบบสร้างให้อัตโนมัติ คุณไม่ต้องแก้เอง

Nameserver คืออะไร? และต่างจาก DNS record อย่างไร

จุดที่สับสนที่สุดสำหรับมือใหม่คือความต่างระหว่าง nameserver กับ DNS record — ลองเข้าใจแบบนี้: nameserver คือ “ที่อยู่ของสมุดโทรศัพท์” ส่วน DNS record คือ “หน้าในสมุดที่มีข้อมูลจริง”

เวลาคุณซื้อโดเมนจากผู้ให้บริการ (registrar) เช่น GoDaddy, Namecheap, หรือผู้ให้บริการในไทย คุณต้องบอกว่า “ใครเป็นคนดูแล DNS ของโดเมนนี้” — นั่นคือการตั้งค่า nameserver ที่ระดับ registrar เช่น ถ้าคุณย้าย DNS มาให้ Cloudflare ดูแล คุณจะตั้ง nameserver เป็น xxx.ns.cloudflare.com และ yyy.ns.cloudflare.com

หลังจากนั้น การจัดการ record รายตัว (A, MX, TXT, …) จะทำที่ฝั่ง nameserver ที่คุณเลือก ไม่ใช่ที่ registrar อีกต่อไป นี่คือสาเหตุที่หลายคนแก้ DNS แล้วไม่เห็นผล — เพราะไปแก้ผิดที่ (แก้ที่ registrar ทั้งที่ nameserver ชี้ไป Cloudflare ไปแล้ว)

สรุปลำดับชั้นให้เห็นภาพ:

1. Registrar — ที่ที่คุณซื้อ/ต่ออายุโดเมน และตั้งค่า nameserver
2. Nameserver / DNS provider — ที่ที่เก็บ DNS record จริง (Cloudflare, Route 53, โฮสต์ของคุณ ฯลฯ)
3. DNS record — ข้อมูลรายตัวที่ชี้ชื่อไป IP หรือบริการต่าง ๆ

หลายคนเลือกย้าย nameserver ไป Cloudflare เพราะได้ฟรีทั้ง DNS ที่เร็ว, การจัดการ record ที่ใช้ง่าย, และฟีเจอร์ความปลอดภัยเพิ่มเติม — ถ้าสนใจรายละเอียดเชิงลึก เราเขียนไว้แล้วใน คู่มือ Cloudflare ฉบับสมบูรณ์

TTL และ DNS Propagation: ทำไมแก้ DNS แล้วไม่เห็นผลทันที

นี่คือหัวข้อที่ตอบคำถามยอดฮิต — “ทำไมย้ายโฮสต์/แก้ DNS แล้วเพื่อนยังเห็นเว็บเก่า แต่ผมเห็นเว็บใหม่แล้ว?” คำตอบอยู่ที่สองคำ: TTL และ DNS propagation

TTL (Time To Live) คือค่าที่บอกว่า “ให้ resolver จำคำตอบนี้ไว้นานกี่วินาทีก่อนจะถามใหม่” หน่วยเป็นวินาที เช่น TTL = 3600 หมายถึง cache ไว้ 1 ชั่วโมง ถ้าคุณตั้ง TTL สูง (เช่น 86400 = 1 วัน) เว็บจะเร็วขึ้นเพราะ resolver ไม่ต้องถามบ่อย แต่เวลาแก้ค่าจะกว่าจะอัปเดตทั่วถึงต้องรอนานกว่า

DNS Propagation คือกระบวนการที่การเปลี่ยนแปลง DNS “กระจาย” ไปทั่วโลก เพราะ resolver แต่ละตัวทั่วโลกมี cache ของตัวเองที่หมดอายุไม่พร้อมกัน บางที่ cache เพิ่งหมด เห็นค่าใหม่แล้ว บางที่ cache ยังเหลือ เห็นค่าเก่าอยู่ — จึงเป็นที่มาของอาการ “บางคนเห็นเว็บใหม่ บางคนเห็นเว็บเก่า” ในช่วงเปลี่ยนผ่าน

เคล็ดลับการจัดการ TTL ให้ราบรื่นเวลาจะย้ายโฮสต์:

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

โดยทั่วไป DNS propagation ใช้เวลาประมาณ ~ไม่กี่นาทีถึง 48 ชั่วโมง (กรณีเปลี่ยน nameserver ทั้งชุดมักนานกว่าการแก้ record เดี่ยว) อย่าเพิ่งตกใจถ้ายังไม่อัปเดตทันที — ตรวจสอบได้ด้วยเครื่องมือเช็ก propagation หลายภูมิภาคพร้อมกัน หรือคำสั่ง nslookup / dig ในเครื่องตัวเอง

ตั้งค่า DNS ตอนทำเว็บ ย้ายโฮสต์ และตั้งอีเมล (Step-by-Step)

ทีนี้มาลงมือจริง 3 สถานการณ์ที่เจอบ่อยที่สุดในงานทำเว็บ

กรณี 1: ทำเว็บใหม่ ชี้โดเมนไปเซิร์ฟเวอร์

1. หา IP address ของเซิร์ฟเวอร์/โฮสต์ที่จะใช้ (โฮสต์ส่วนใหญ่ระบุไว้ในหน้า dashboard)
2. เข้า DNS management ของ nameserver ที่ดูแลโดเมน (เช่น Cloudflare)
3. สร้าง A record: @ → IP เซิร์ฟเวอร์
4. สร้าง CNAME record: www → @ (หรือ A record ชี้ IP เดียวกัน) เพื่อให้ทั้งมี/ไม่มี www ใช้ได้
5. ถ้ามี IPv6 ให้เพิ่ม AAAA record ด้วย
6. รอ propagation แล้วทดสอบเข้าเว็บทั้ง domain.com และ www.domain.com

ถ้าเป็นเว็บ WordPress การตั้งค่า DNS เป็นแค่ก้าวแรก — ยังมีเรื่องการเลือกโฮสต์ที่เหมาะและการเซ็ตอัปที่ถูกต้อง อ่านต่อได้ใน คู่มือ WordPress hosting ปี 2026

กรณี 2: ย้ายโฮสต์เก่าไปโฮสต์ใหม่

1. อย่าเพิ่งยกเลิกโฮสต์เก่า — เปิดทิ้งไว้จนกว่า propagation จะเสร็จ
2. ลด TTL ของ record ที่เกี่ยวข้องลงเหลือ 300 ล่วงหน้า (ตามที่อธิบายในหัวข้อ TTL)
3. ตั้งเว็บบนโฮสต์ใหม่ให้เสร็จและทดสอบผ่าน IP หรือ staging ก่อน
4. แก้ A/AAAA record ชี้ไป IP ของโฮสต์ใหม่
5. ตรวจสอบ propagation ทั้งจากหลายภูมิภาค รอจนนิ่ง แล้วค่อยปิดโฮสต์เก่า
6. อย่าลืมตรวจ MX record ว่ายังชี้เซิร์ฟเวอร์อีเมลที่ถูกต้อง (การย้ายเว็บไม่ควรกระทบอีเมล ถ้าตั้งถูก)

กรณี 3: ตั้งอีเมลโดเมน (เช่น Google Workspace)

1. เพิ่ม MX record ตามค่าที่ผู้ให้บริการอีเมลกำหนด (พร้อม priority)
2. เพิ่ม TXT record สำหรับ SPF เช่น v=spf1 include:_spf.google.com ~all
3. เพิ่ม TXT record สำหรับ DKIM (ค่าจะ generate มาจาก dashboard ผู้ให้บริการ)
4. เพิ่ม TXT record สำหรับ DMARC เช่น _dmarc → v=DMARC1; p=quarantine; ...
5. เพิ่ม TXT verification record เพื่อยืนยันความเป็นเจ้าของโดเมน
6. รอ propagation แล้วทดสอบส่ง-รับอีเมลทั้งสองทาง

คำเตือนสำคัญ: การตั้งค่า MX/SPF/DKIM ผิดทำให้อีเมลเข้า spam หรือส่งไม่ออกได้ง่ายมาก ถ้าไม่แน่ใจ ให้ทำตามคู่มือของผู้ให้บริการแบบเป๊ะ ๆ และอย่ามี SPF record ซ้ำซ้อนหลายอันในโดเมนเดียว (อนุญาตให้มี SPF เพียง record เดียว)

DNS กับความเร็วและความปลอดภัย: Cloudflare, DNSSEC, DNS-over-HTTPS

DNS ไม่ได้มีผลแค่ “เข้าเว็บได้/ไม่ได้” แต่ยังมีผลต่อ ความเร็ว และ ความปลอดภัย อย่างมีนัยสำคัญ

ในแง่ ความเร็ว — resolver ที่เร็วและมีเครือข่ายกระจายทั่วโลก (anycast) ช่วยลดเวลาในการตอบ DNS query ลงได้มาก DNS สาธารณะอย่าง Cloudflare (1.1.1.1) และ Google (8.8.8.8) มัก resolve ได้เร็วและเสถียรกว่า DNS ของ ISP บางราย และถ้าคุณใช้ Cloudflare เป็น authoritative nameserver ด้วย DNS query ของเว็บคุณจะถูกตอบจาก POP ที่ใกล้ผู้ใช้ที่สุด — มีผลต่อ TTFB และ Core Web Vitals โดยตรง (อ่านเพิ่ม คู่มือ Core Web Vitals ในมุมของ server response)

ในแง่ ความปลอดภัย มีสามเทคโนโลยีที่ควรรู้จัก:

• DNSSEC (DNS Security Extensions) — เพิ่ม “ลายเซ็นดิจิทัล” ให้ DNS response เพื่อป้องกันการปลอมแปลงคำตอบ (DNS spoofing / cache poisoning) ที่อาจ redirect ผู้ใช้ไปเว็บปลอม เปิดใช้ได้ง่ายในผู้ให้บริการสมัยใหม่ส่วนใหญ่ด้วยการกดสวิตช์เดียว
• DNS-over-HTTPS (DoH) และ DNS-over-TLS (DoT) — เข้ารหัสการ query DNS ไม่ให้ ISP หรือคนกลางมาดักดูว่าคุณเข้าเว็บอะไร ปกป้องความเป็นส่วนตัว เบราว์เซอร์สมัยใหม่รองรับ DoH แล้ว
• DNS Filtering — ใช้ DNS บล็อกโดเมนอันตราย/มัลแวร์ เช่น 1.1.1.1 for Families ที่กรอง content อันตรายให้อัตโนมัติ

สำหรับเจ้าของเว็บ การเปิด DNSSEC และใช้ DNS provider ที่มี DDoS protection ระดับ DNS เป็นการป้องกันชั้นพื้นฐานที่ควรทำตั้งแต่วันแรก — เพราะการโจมตีจำนวนมากเริ่มที่ชั้น DNS ก่อนถึง origin server ด้วยซ้ำ

แก้ปัญหา DNS ที่พบบ่อย พร้อมวิธีตรวจสอบ

ปิดท้ายด้วยเช็กลิสต์อาการและวิธีแก้ที่เจอบ่อยที่สุดในงานจริง

อาการ	สาเหตุที่เป็นไปได้	วิธีตรวจ/แก้
เว็บเข้าไม่ได้หลังตั้งค่าใหม่	propagation ยังไม่เสร็จ	รอ + เช็กด้วย dig/เครื่องมือ propagation
บางคนเห็นเว็บเก่า บางคนเห็นใหม่	cache TTL ยังไม่หมดทุกที่	รอจน TTL เดิมหมด, ครั้งหน้าลด TTL ก่อนแก้
เว็บเข้าได้แต่ส่งอีเมลไม่ออก	MX/SPF ผิดหรือไม่มี	ตรวจ MX record + SPF ให้ตรงผู้ให้บริการ
www เข้าได้ แต่ไม่มี www เข้าไม่ได้	ขาด A/CNAME ของ root	เพิ่ม record ให้ครบทั้งสองแบบ
DNS_PROBE_FINISHED_NXDOMAIN	ชื่อโดเมนไม่มี record/ตั้ง nameserver ผิด	ตรวจ NS ที่ registrar + record ที่ provider
อีเมลเข้า spam ตลอด	ขาด DKIM/DMARC	ตั้ง SPF + DKIM + DMARC ให้ครบ

เครื่องมือตรวจสอบ DNS ที่ควรมีติดมือ:

• คำสั่ง nslookup domain.com — ดู IP ที่ resolve ได้แบบเร็ว ๆ บน Windows/Mac/Linux
• คำสั่ง dig domain.com A / dig domain.com MX — ละเอียดกว่า เห็น TTL และ record ทุกชนิด
• เครื่องมือเช็ก propagation หลายภูมิภาค — ดูว่าค่าใหม่กระจายถึงไหนแล้วทั่วโลก
• Google Admin Toolbox / MXToolbox — ตรวจ MX, SPF, DKIM, DMARC, DNSSEC ในที่เดียว

ขั้นตอนดีบักที่เราใช้เสมอเวลาเจอปัญหา DNS คือ “ไล่จากบนลงล่าง”: ตรวจ NS ที่ registrar ก่อนว่าชี้ provider ถูกไหม → เข้า provider ดูว่า record ที่ควรมีครบและถูกต้องไหม → ใช้ dig เช็กว่าค่าจริงที่ resolve ได้ตรงกับที่ตั้งไว้ไหม → ถ้าตรงแล้วแต่ยังไม่เห็นผล แปลว่าเป็นเรื่อง propagation/TTL ให้รอ

ที่ Southern Whale เราดูแลเรื่อง DNS, การย้ายโฮสต์, การตั้งอีเมลโดเมน และการเชื่อมต่อ Cloudflare ให้ลูกค้า SME ทั่วภาคใต้แบบครบจบในที่เดียว — ไม่ต้องกังวลว่าจะตั้งผิดจนเว็บล่มหรืออีเมลเข้า spam ถ้าคุณกำลังจะทำเว็บใหม่หรือย้ายโฮสต์แล้วไม่อยากเสี่ยงเอง ปรึกษาทีม บริการพัฒนาเว็บไซต์ของ Southern Whale ได้เลย เราเซ็ตอัป DNS ให้ถูกต้องตั้งแต่วันแรกพร้อมเอกสารส่งมอบครบถ้วน

FAQ คำถามที่พบบ่อยเรื่อง DNS

Q: DNS คืออะไรแบบสั้นที่สุด? A: ระบบที่แปลงชื่อโดเมน (เช่น southernwhale.com) ให้เป็น IP address ที่เครื่องเข้าใจ เปรียบเหมือนสมุดโทรศัพท์ของอินเทอร์เน็ต

Q: เปลี่ยน DNS แล้วกี่นาทีถึงจะเห็นผล? A: ตั้งแต่ไม่กี่นาทีถึง 48 ชั่วโมง ขึ้นกับ TTL เดิมและชนิดการเปลี่ยน — การแก้ record เดี่ยวเร็วกว่าการเปลี่ยน nameserver ทั้งชุด

Q: ควรใช้ DNS ของ ISP หรือ 1.1.1.1 / 8.8.8.8 ดี? A: DNS สาธารณะอย่าง 1.1.1.1 และ 8.8.8.8 มักเร็วและเสถียรกว่า รวมถึงมีฟีเจอร์ความปลอดภัยและความเป็นส่วนตัวมากกว่า

Q: A record กับ CNAME ต่างกันยังไง? A: A record ชี้ไป IP โดยตรง ส่วน CNAME ชี้ไป “ชื่ออื่น” ที่ค่อยไปชี้ IP อีกที — ห้ามใช้ CNAME ที่ root domain นอกจากผู้ให้บริการรองรับ CNAME flattening

Q: ต้องเปิด DNSSEC ไหม? A: ควรเปิดถ้าผู้ให้บริการรองรับ เพราะช่วยป้องกันการปลอมแปลงคำตอบ DNS ที่อาจ redirect ผู้ใช้ไปเว็บปลอม โดยแทบไม่มีข้อเสีย

สรุป

DNS คือ “สมุดโทรศัพท์ของอินเทอร์เน็ต” ที่ทำงานเงียบ ๆ อยู่เบื้องหลังทุกการเข้าเว็บ ทุกอีเมล และทุกบริการออนไลน์ — เข้าใจมันแล้วคุณจะเซ็ตเว็บ ย้ายโฮสต์ และตั้งอีเมลได้อย่างมั่นใจ ไม่ต้องเดา

สิ่งที่ควรจำติดตัว: DNS resolution เดินจาก resolver → root → TLD → authoritative; record แต่ละชนิด (A, AAAA, CNAME, MX, TXT, NS, SOA) มีหน้าที่ต่างกัน; nameserver คือที่อยู่ของสมุด ส่วน record คือข้อมูลในสมุด; และเรื่อง TTL/propagation คือเหตุผลที่แก้ DNS แล้วไม่เห็นผลทันที — วางแผน TTL ล่วงหน้าจะช่วยให้การย้ายราบรื่น สุดท้าย อย่าลืมเสริมความเร็วและความปลอดภัยด้วย DNS provider ที่ดีและ DNSSEC

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