เทคโนโลยีโดย milo อ่าน 11 นาทีเรียบเรียงโดยมี AI ช่วย

เจาะลึก DNS Record ทุกประเภทที่นักพัฒนาต้องรู้: คู่มือตั้งค่าจริง เช็กด้วย dig/nslookup

วันที่เว็บคุณล่มเพราะ DNS ผิดพลาด คุณรู้จัก Record ทุกประเภทที่เขียนอยู่ในหน้าจอหรือไม่ บทความนี้เจาะลึก A, AAAA, CNAME, MX, TXT, NS พร้อมตัวอย่างตั้งค่าจริงและวิธีตรวจสอบด้วย dig และ nslookup

#เทคโนโลยี#Programming#Web#ความรู้#Dev365TH
สารบัญ

เรื่องจริงวันที่เว็บหายไปเพราะ DNS ตัวเดียว

เมื่อปีกลาย ทีมพัฒนาแห่งหนึ่งย้ายเซิร์ฟเวอร์จาก VPS เดิมไปยัง Cloud Provider ใหม่ ทุกอย่างเตรียมพร้อม — โค้ด deploy แล้ว ฐานข้อมูล migrate แล้ว ใบรับรอง SSL ติดตั้งเรียบร้อย แต่เว็บกลับเข้าไม่ได้เป็นชั่วโมง

สาเหตุ? ไม่ใช่โค้ด ไม่ใช่เซิร์ฟเวอร์ แต่เป็น DNS Record ตัวเดียวที่ลืมอัปเดต IP ใหม่

DNS คือระบบตำราโทรศัพท์ของอินเทอร์เน็ต แต่สิ่งที่นักพัฒนาหลายคนมองข้ามคือ — มันไม่ได้มีแค่ "เชื่อมโดเมนกับ IP" อย่างเดียว การเข้าใจ dns record ประเภท ต่างๆ อย่างแท้จริง คือความแตกต่างระหว่างเว็บที่ทำงานสมบูรณ์กับเว็บที่ล่มกลางวัน

บทความนี้เจาะลึกทุกประเภทที่คุณจะเจอในหน้าจัดการ DNS ของ Cloudflare, AWS Route53, หรือ cPanel พร้อมบอกว่าเมื่อไหร่ควรใช้ตัวไหน และจะตรวจสอบได้อย่างไรว่ามันทำงานถูกต้อง

A Record: รากฐานของทุกเว็บไซต์

A Record (Address Record) คือประเภทพื้นฐานที่สุด — มันบอกว่าโดเมนหรือ subdomain นี้ชี้ไปที่ IPv4 Address ไหน

ตัวอย่าง A Record จริง

example.com.    IN A    192.0.2.1
www.example.com. IN A    192.0.2.1
api.example.com. IN A    192.0.2.2

บรรทัดแรกคือ root domain ชี้ไป IP หลัก บรรทัดที่สองคือ www subdomain ชี้ไป IP เดียวกัน ส่วน api ชี้ไป IP อื่นเพราะรันบนเซิร์ฟเวอร์แยก

เมื่อไหร่ใช้ A Record

  • เมื่อคุณรู้ IP ของเซิร์ฟเวอร์โดยตรง (VPS, Dedicated Server)
  • เมื่อต้องการควบคุมการ routing แบบละเอียด เช่น แยก api กับ web ไปคนละเครื่อง
  • เมื่อใช้ Load Balancer ที่มี IP คงที่

ข้อควรระวัง

A Record ใช้ได้เฉพาะ IPv4 เท่านั้น หากเซิร์ฟเวอร์รองรับ IPv6 คุณต้องเพิ่ม AAAA Record คู่กันด้วย ไม่งั้นผู้ใช้ที่อยู่บนเครือข่าย IPv6-only จะเข้าเว็บคุณไม่ได้

AAAA Record: อนาคตที่มาถึงแล้ว

AAAA Record ทำหน้าที่เหมือน A Record ทุกประการ แต่สำหรับ IPv6 Address

example.com.    IN AAAA    2001:db8::1
www.example.com. IN AAAA    2001:db8::1

ทำไมต้องสนใจ IPv6 ในปี 2025

  • อุปกรณ์มือถือจำนวนมากใช้ IPv6 ผ่านเครือข่าย 4G/5G
  • Cloud Provider อย่าง AWS และ GCP มอบหมาย IPv6 ให้โดย default
  • Google และ Facebook เปิดใช้ IPv6 มานานแล้ว

หากคุณใช้ Cloudflare หรือ CDN ส่วนใหญ่จะจัดการ AAAA ให้อัตโนมัติ แต่ถ้าคุณจัดการ DNS เอง อย่าลืมเพิ่ม

CNAME Record: เปลี่ยนชื่อ ไม่เปลี่ยนแอดเดรส

CNAME (Canonical Name) คือการบอกว่า "โดเมนนี้ไปดูที่โดเมนนั้นแทน" มันไม่ได้ชี้ไป IP โดยตรง แต่ชี้ไปอีกโดเมนหนึ่ง แล้วให้ DNS Resolver ไปไขต่อ

blog.example.com.    IN CNAME    example.github.io.
shop.example.com.    IN CNAME    shops.myshopify.com.
app.example.com.     IN CNAME    myapp.herokuapp.com.

กรณีใช้จริงที่พบบ่อย

  1. ใช้บริการ Third-party เช่น GitHub Pages, Shopify, Heroku, Vercel — ผู้ให้บริการเปลี่ยน IP ได้ทุกเมื่อ หากคุณใช้ A Record คุณต้องตามอัปเดตเอง แต่ CNAME จะตามให้อัตโนมัติ
  2. ย้าย subdomain ชั่วคราว เช่น staging.example.com ชี้ไป staging-v2.example.com
  3. จัดการหลายโดเมนใต้แบรนด์เดียวกัน เช่น th.example.com และ en.example.com ชี้ไป app.example.com

กฎเหล็กของ CNAME ที่ต้องจำ

  • ห้ามใช้ CNAME กับ root domain (เช่น example.com) ตามมาตรฐาน DNS เดิม เพราะ root domain ต้องมี SOA และ NS Record อยู่ ไม่สามารถเป็น CNAME ได้พร้อมกัน
  • ปัจจุบัน Cloudflare และบาง Provider แก้ปัญหานี้ด้วย CNAME Flattening (หรือ ALIAS/ANAME Record) ที่ทำงานเหมือน CNAME แต่อยู่บน root domain ได้
  • CNAME ทำให้มี DNS lookup เพิ่มขึ้นหนึ่งรอบ เพราะต้องไปไขโดเมนเป้าหมายต่อ

MX Record: ทางผ่านของอีเมล

MX Record (Mail Exchange) บอกว่าอีเมลที่ส่งถึง @example.com ให้ส่งไปที่เซิร์ฟเวอร์ไหน พร้อมระบุลำดับความสำคัญ (priority) ด้วยตัวเลข

example.com.    IN MX    10    mail1.example.com.
example.com.    IN MX    20    mail2.example.com.
example.com.    IN MX    30    mail3.backup.com.

ลำดับ Priority ทำงานอย่างไร

ตัวเลขยิ่งน้อยยิ่งมีความสำคัญสูง เซิร์ฟเวอร์ส่งเมลจะลองติด mail1 ก่อน (priority 10) หากไม่ตอบจึงไป mail2 (priority 20) และ mail3 (priority 30) ตามลำดับ

ตัวอย่างจริง: ใช้ Google Workspace

example.com.    IN MX    1     aspmx.l.google.com.
example.com.    IN MX    5     alt1.aspmx.l.google.com.
example.com.    IN MX    5     alt2.aspmx.l.google.com.
example.com.    IN MX    10    alt3.aspmx.l.google.com.
example.com.    IN MX    10    alt4.aspmx.l.google.com.

ข้อผิดพลาดที่ทำบ่อย

  • ลืมเพิ่ม MX Record หลังย้ายผู้ให้บริการอีเมล → อีเมลหาย
  • ใส่ IP แทนโดเมนใน MX Record → ไม่ถูกต้องตามมาตรฐาน บางเซิร์ฟเวอร์ปฏิเสธ
  • ลบ MX Record เก่าไม่หมด → เมลถูกส่งไปเซิร์ฟเวอร์เก่าที่ไม่มีอยู่แล้ว

TXT Record: กล่องเก็บข้อความที่ทำได้มากกว่าที่คิด

TXT Record (Text Record) เก็บข้อความอิสระได้สูงสุด 255 ตัวอักษรต่อ string (สามารถต่อหลาย string ได้) ตอนแรกออกแบบมาเก็บบันทึกธรรมดา แต่ปัจจุบันกลายเป็น Record ที่ทำงานหนักที่สุด

การใช้งานหลักของ TXT Record

1. SPF (Sender Policy Framework) — ป้องกันอีเมลปลอม

example.com.    IN TXT    "v=spf1 include:_spf.google.com ~all"

บอกว่าอีเมลจาก @example.com ส่งได้จากเซิร์ฟเวอร์ของ Google เท่านั้น นอกนั้นให้ทำเครื่องหมายว่าน่าสงสัย

2. DKIM — ลายเซ็นดิจิทัลของอีเมล

selector1._domainkey.example.com.    IN TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."

3. DMARC — นโยบายจัดการอีเมลที่ไม่ผ่าน SPF/DKIM

_dmarc.example.com.    IN TXT    "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

4. ยืนยันความเป็นเจ้าของโดเมน

Google Search Console, Let's Encrypt, SSL Provider ต่างๆ จะให้คุณเพิ่ม TXT Record เพื่อพิสูจน์ว่าคุณเป็นเจ้าของโดเมนจริง

example.com.    IN TXT    "google-site-verification=abc123xyz456"

5. ยืนยันตัวตนสำหรับบริการอื่นๆ

  • Apple Developer Domain Verification
  • Microsoft 365
  • Facebook Business Verification
  • Stripe, Slack, Notion และอีกมาก

NS Record: ผู้มีอำนาจตอบคำถาม

NS Record (Name Server) บอกว่าใครเป็นผู้มีอำนาจในการตอบคำถาม DNS ของโดเมนนี้

example.com.    IN NS    ns1.cloudflare.com.
example.com.    IN NS    ns2.cloudflare.com.

ความสำคัญที่มองไม่เห็น

NS Record เป็นจุดเชื่อมระหว่าง Registrar (ผู้จดโดเมน) กับ DNS Provider (ผู้จัดการ Record) เมื่อคุณซื้อโดเมนจาก Namecheap แต่ใช้ DNS ของ Cloudflare คุณต้องตั้ง NS Record ให้ชี้ไป Cloudflare

หาก NS Record ผิด ทุก Record อื่นจะไร้ความหมาย เพราะไม่มีใครรู้ว่าจะไปถามใคร

การใช้ NS Record สำหรับ Subdomain Delegation

internal.example.com.    IN NS    ns1.internal.example.com.
internal.example.com.    IN NS    ns2.internal.example.com.

กรณีนี้คือการมอบหมายให้ subdomain ไปใช้ DNS Server อิสระ มีประโยชน์เมื่อทีมภายในต้องการจัดการ DNS ของตัวเองโดยไม่กระทบโดเมนหลัก

ตารางสรุป: เมื่อไหร่ใช้ Record ประเภทไหน

Record ใช้เมื่อ ตัวอย่างเป้าหมาย
A ชี้โดเมนไป IPv4 ที่รู้จัก VPS, Dedicated Server
AAAA ชี้โดเมนไป IPv6 เซิร์ฟเวอร์ที่รองรับ IPv6
CNAME ชี้ subdomain ไปโดเมนอื่น GitHub Pages, Shopify, Heroku
MX กำหนดเซิร์ฟเวอร์รับอีเมล Google Workspace, Microsoft 365
TXT เก็บข้อความยืนยัน/นโยบาย SPF, DKIM, DMARC, Domain Verification
NS กำหนดผู้จัดการ DNS ย้าย DNS Provider, Subdomain Delegation

ตัวอย่างการตั้งค่า DNS Record แบบเต็มรูปแบบ

สมมติคุณมีเว็บไซต์ myapp.com ที่รันบน VPS ของคุณเอง ใช้ Google Workspace สำหรับอีเมล และมี blog บน Ghost ที่ hosted อยู่ที่อื่น

# Root domain → เซิร์ฟเวอร์หลัก
myapp.com.           IN A      203.0.113.10
myapp.com.           IN AAAA   2001:db8::10

# www → เซิร์ฟเวอร์เดียวกัน
www.myapp.com.        IN A      203.0.113.10
www.myapp.com.        IN AAAA   2001:db8::10

# API → เซิร์ฟเวอร์แยก
api.myapp.com.        IN A      203.0.113.20

# Blog → hosted ที่ Ghost(ใช้ CNAME เพราะ IP เปลี่ยนได้)
blog.myapp.com.       IN CNAME  myapp.ghost.io.

# อีเมล → Google Workspace
myapp.com.            IN MX     1  aspmx.l.google.com.
myapp.com.            IN MX     5  alt1.aspmx.l.google.com.
myapp.com.            IN MX     5  alt2.aspmx.l.google.com.
myapp.com.            IN MX     10 alt3.aspmx.l.google.com.

# ความปลอดภัยอีเมล
myapp.com.            IN TXT    "v=spf1 include:_spf.google.com ~all"
_dmarc.myapp.com.     IN TXT    "v=DMARC1; p=reject; rua=mailto:[email protected]"
google._domainkey.myapp.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0..."

# ยืนยันโดเมนสำหรับ Google Search Console
myapp.com.            IN TXT    "google-site-verification=xyz123abc"

สังเกตว่า root domain ใช้ A/AAAA เพราะเป็นเซิร์ฟเวอร์ของเราเอง ส่วน blog ใช้ CNAME เพราะเป็นบริการ hosted ที่ IP เปลี่ยนได้

DNS Propagation: ทำไมเปลี่ยนแล้วต้องรอ

เมื่อคุณแก้ DNS Record แล้วเว็บยังเข้าไม่ได้ คุณเคยสงสัยไหมว่ามันเกิดอะไรขึ้น

กลไกการทำงาน

DNS ทุก Record มี TTL (Time To Live) กำหนดว่า Resolver ควรเก็บคำตอบไว้นานเท่าไหร่ (เป็นวินาที) เมื่อ Resolver ได้รับคำตอบแล้ว มันจะเก็บในแคชตาม TTL และไม่ถามซ้ำจนกว่า TTL จะหมด

example.com.    3600    IN A    192.0.2.1

ตัวเลข 3600 คือ TTL = 3,600 วินาที = 1 ชั่วโมง หมายความว่า Resolver ทั่วโลกที่เคยถามโดเมนนี้จะเก็บคำตอบเดิมไว้ 1 ชั่วโมง

รอนานแค่ไหนจริงๆ

  • TTL ต่ำ (300 วินาที = 5 นาที): การเปลี่ยนแพร่เร็ว แต่เพิ่มโหลด DNS Query
  • TTL สูง (86400 วินาที = 24 ชั่วโมง): ลดโหลด แต่เปลี่ยนช้า
  • ความเป็นจริง: การเปลี่ยนแพร่กระจายไปทั่วโลกมักใช้เวลา 1-48 ชั่วโมง ขึ้นกับ TTL เดิมและ ISP ของผู้ใช้แต่ละราย

เทคนิคลดเวลารอ

  1. ลด TTL ล่วงหน้า ก่อนย้ายเซิร์ฟเวอร์ 1-2 วัน ลดจาก 3600 เป็น 300 เพื่อให้เมื่อเปลี่ยน IP จริง การอัปเดตแพร่เร็วขึ้น
  2. เก็บเซิร์ฟเวอร์เก่าไว้ทำงาน ระหว่างที่ DNS ยังเปลี่ยน เพื่อให้ผู้ใช้ที่ยังเข้า IP เก่าไม่เจอหน้า error
  3. ใช้ CDN เช่น Cloudflare ที่จัดการ DNS Propagation ให้เร็วกว่าเพราะมีเครือข่าย Anycast ทั่วโลก

เครื่องมือตรวจสอบ DNS: dig และ nslookup

dig: เครื่องมือมาตรฐานของนักพัฒนา

dig (Domain Information Groper) มีให้ใช้บน macOS และ Linux โดย default บน Windows ต้องติดตั้ง BIND tools หรือใช้ผ่าน WSL

คำสั่งพื้นฐาน

# ดู A Record
dig example.com A

# ดู AAAA Record
dig example.com AAAA

# ดู MX Record
dig example.com MX

# ดู TXT Record
dig example.com TXT

# ดู NS Record
dig example.com NS

# ดู CNAME
dig www.example.com CNAME

ผลลัพธ์ที่ควรอ่าน

dig example.com A

;; ANSWER SECTION:
example.com.    3600    IN A    93.184.216.34

ส่วน ANSWER SECTION คือคำตอบที่สำคัญ ตัวเลข 3600 คือ TTL หากคุณเพิ่งเปลี่ยน IP แล้วเห็น TTL ยังสูง แปลว่า Resolver ยังเก็บค่าเดิมอยู่

เทคนิคขั้นสูง

# ถาม DNS Server เฉพาะเจาะจง (ไม่ใช่ของ ISP)
dig @8.8.8.8 example.com A

# ดู DNSSEC validation
dig +dnssec example.com A

# สั้นกระชับ
dig +short example.com A

nslookup: เครื่องมือที่มีทุกเครื่อง

nslookup มีบน Windows, macOS, และ Linux ทุกตัว ใช้ง่ายกว่า dig แต่ข้อมูลน้อยกว่า

# คำสั่งพื้นฐาน
nslookup example.com

# ระบุประเภท Record
nslookup -type=MX example.com
nslookup -type=TXT example.com
nslookup -type=NS example.com

# ระบุ DNS Server
nslookup example.com 8.8.8.8

เครื่องมือออนไลน์ที่แนะนำ

  • dnschecker.org: ตรวจ DNS จากเซิร์ฟเวอร์ทั่วโลกพร้อมกัน เห็นว่า Propagation ไปถึงไหนแล้ว
  • mxtoolbox.com: ตรวจ MX, SPF, DKIM, DMARC ครบ
  • diggui.com: ทดสอบ dig ผ่านเว็บ
  • Google Admin Toolbox: ตรวจ DNS และอีเมล

บทสรุป: DNS Record ไม่ใช่เรื่องน่ากลัว

การเข้าใจ dns record ประเภท ต่างๆ คือทักษะพื้นฐานที่นักพัฒนาทุกคนควรมี ไม่ใช่หน้าที่ของทีม IT อย่างเดียว เพราะเมื่อเว็บมีปัญหา DNS มักเป็นสาเหตุแรกที่ต้องเช็ก

สิ่งสำคัญที่ควรจำ:

  • A/AAAA สำหรับชี้ IP โดยตรง
  • CNAME สำหรับชี้ไปโดเมนอื่น (เหมาะกับบริการ hosted)
  • MX สำหรับอีเมล อย่าลืม SPF/DKIM/DMARC ใน TXT
  • TXT เป็นกล่องเก็บข้อความยืนยันตัวตนและนโยบาย
  • NS กำหนดผู้มีอำนาจจัดการ DNS
  • ลด TTL ล่วงหน้าก่อนย้ายเซิร์ฟเวอร์
  • ใช้ dig และ nslookup ตรวจสอบทุกครั้งหลังเปลี่ยน

ลองเปิด Terminal แล้วพิมพ์ dig โดเมนของคุณดูสิ คุณจะเห็น Record ทุกตัวที่ทำงานอยู่เบื้องหลัง บางทีอาจเจอ Record เก่าที่ลืมลบ หรือพบว่า TTL ตั้งสูงเกินไปจนย้ายเซิร์ฟเวอร์ยาก

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

เนื้อหาที่จัดทำโดยมี AI ช่วยจะมีป้ายกำกับ "เรียบเรียงโดยมี AI ช่วย" เพื่อให้คุณทราบอย่างชัดเจน เราถือว่าความโปร่งใสเรื่องการใช้ AI เป็นสิ่งสำคัญต่อความไว้วางใจของผู้อ่าน

พบข้อมูลที่ไม่ถูกต้องหรือคลาดเคลื่อน?เข้าสู่ระบบเพื่อทักท้วง
บทความนี้เป็นอย่างไร?

ความคิดเห็น (0)

ยังไม่มีความคิดเห็น — มาเป็นคนแรกกันเถอะ!

บทความที่เกี่ยวข้อง

เทคโนโลยีHTTP Status Code คืออะไร? คู่มือทำความเข้าใจรหัสสถานะเว็บไซต์สำหรับมือใหม่เทคโนโลยีHTTPS คืออะไร? ทำความเข้าใจ SSL/TLS และการเข้ารหัสที่ปกป้องเว็บของคุณเทคโนโลยีทำความเข้าใจ IP Address และ Subnet Mask: พื้นฐานเครือข่ายที่นักพัฒนาต้องรู้