เมื่อต้องการชี้โดเมนหรือ subdomain ไปยังปลายทาง ไม่ว่าจะเป็นเซิร์ฟเวอร์ของตัวเอง บริการ cloud หรือ CDN คำถามที่พบเจอเกือบทุกครั้งคือ "ควรใช้ A Record หรือ CNAME?" DNS Record สองประเภทนี้ดูเหมือนทำงานคล้ายกัน แต่มีความแตกต่างพื้นฐานที่สำคัญทั้งในแง่เทคนิค ความยืดหยุ่น และข้อจำกัด บทความนี้อธิบายอย่างละเอียดว่าแต่ละ record ทำงานอย่างไร ต่างกันตรงไหน และควรเลือกใช้อะไรในสถานการณ์แบบไหน
A Record คืออะไร
A Record (Address Record) คือ DNS Record พื้นฐานที่สุดประเภทหนึ่ง ทำหน้าที่แมปชื่อโดเมนหรือ hostname ไปยัง IPv4 Address โดยตรง เมื่อ browser ของผู้ใช้ต้องการเข้าถึง example.com มันจะถาม DNS resolver ว่า "IP ของ example.com คือเลขอะไร" และ A Record จะตอบว่าเป็น IP นั้นๆ
รูปแบบ A Record มาตรฐาน:
example.com. 300 IN A 203.0.113.10 www.example.com. 300 IN A 203.0.113.10
ในตัวอย่างนี้ทั้ง example.com และ www.example.com ชี้ไปที่ IP เดียวกัน การตั้งค่าแบบนี้ทำงานได้ดีเมื่อ IP ของเซิร์ฟเวอร์คงที่ไม่เปลี่ยนแปลง แต่ถ้า IP เปลี่ยน จะต้องแก้ A Record ทุกชื่อที่ชี้ไปยัง IP นั้น
นอกจาก A Record แบบปกติแล้ว ยังมี AAAA Record ซึ่งเป็นเวอร์ชัน IPv6 ทำงานหลักการเดียวกัน แต่เก็บ IPv6 Address แทน (เช่น 2001:db8::1) ในระบบที่รองรับ IPv6 ควรมีทั้ง A และ AAAA Records คู่กัน
CNAME Record คืออะไร
CNAME Record (Canonical Name Record) ต่างจาก A Record ตรงที่มันไม่ได้ชี้ไปยัง IP Address โดยตรง แต่ชี้ชื่อโดเมนหนึ่งไปยังชื่อโดเมนอีกชื่อหนึ่ง และให้ DNS resolver ทำการค้นหา IP ต่อจากชื่อที่ชี้ไปนั้นอีกที
รูปแบบ CNAME Record มาตรฐาน:
www.example.com. 300 IN CNAME example.com. blog.example.com. 300 IN CNAME example.com. shop.example.com. 300 IN CNAME myshop.shopify.com.
เมื่อ resolver ค้นหา www.example.com และพบ CNAME ที่ชี้ไป example.com มันจะทำการ lookup example.com อีกครั้งเพื่อหา IP จริง กระบวนการนี้เรียกว่า CNAME chasing และเกิดขึ้นโดยอัตโนมัติ
ประโยชน์หลักของ CNAME คือความยืดหยุ่น ถ้า example.com เปลี่ยน IP คุณแก้แค่ A Record ของ example.com เพียงจุดเดียว ทุก CNAME ที่ชี้มาก็จะได้ IP ใหม่โดยอัตโนมัติ
ความแตกต่างหลักระหว่าง A Record กับ CNAME
เพื่อให้เห็นภาพชัดขึ้น ตารางด้านล่างสรุปความแตกต่างสำคัญระหว่าง A Record และ CNAME:
| คุณสมบัติ | A Record | CNAME Record |
|---|---|---|
| ปลายทาง | IPv4 Address (เช่น 203.0.113.10) | Hostname อื่น (เช่น example.com) |
| ใช้ที่ Root Domain ได้ | ได้ (แนะนำสำหรับ @) | ไม่ได้ (ยกเว้น CNAME Flattening) |
| DNS Lookup | 1 ขั้น (ตรงถึง IP ทันที) | 2+ ขั้น (CNAME → hostname → IP) |
| ความยืดหยุ่นเมื่อ IP เปลี่ยน | ต้องแก้ทุก A Record ที่ใช้ IP นั้น | แก้ที่ target เดียว ทุก CNAME อัพเดตเอง |
| ใช้ร่วมกับ Record อื่น | ได้ (ร่วมกับ MX, TXT ฯลฯ) | ไม่ได้ (ต้องอยู่คนเดียวในชื่อนั้น) |
| เหมาะกับ | Root domain, เซิร์ฟเวอร์ IP คงที่ | Subdomain, บริการ cloud, CDN |
ข้อจำกัดสำคัญของ CNAME ที่ต้องรู้
CNAME มีข้อจำกัดที่กำหนดโดย DNS standard (RFC 1034) ซึ่งนักพัฒนาและผู้ดูแลระบบมักพลาดบ่อย:
1. ห้ามใช้ CNAME ที่ Root Domain (Apex Domain)
Root domain หรือ Apex domain คือโดเมนหลักโดยไม่มี subdomain เช่น example.com (ตรงข้ามกับ www.example.com) ตาม RFC กำหนดว่า Record ที่ชื่อโดเมนมี CNAME จะต้องไม่มี Record ประเภทอื่นเลยในชื่อเดียวกัน แต่ root domain ต้องมี SOA และ NS Records อยู่เสมอตาม DNS standard ดังนั้นการใส่ CNAME ที่ root domain จึงขัดแย้งกับ standard และ DNS server หลายตัวจะปฏิเสธหรือทำงานผิดพลาด
# ✅ ถูกต้อง @ IN A 203.0.113.10 www IN CNAME example.com. # ❌ ผิด — ห้ามทำ @ IN CNAME something.cdn.com. ; ขัดกับ SOA/NS ที่ต้องมี
2. CNAME ต้องอยู่คนเดียวในชื่อนั้น
ชื่อโดเมนที่มี CNAME จะต้องไม่มี Record ประเภทอื่นร่วมด้วยเลย (ยกเว้น DNSSEC records บางประเภท) ซึ่งหมายความว่าถ้า subdomain ใดมี CNAME อยู่แล้ว จะไม่สามารถเพิ่ม MX Record ให้ subdomain นั้นรับอีเมลได้ ต้องใช้ชื่อ subdomain แยกต่างหากสำหรับ mail แทน
# ❌ ผิด — mail.example.com ไม่สามารถมีทั้ง CNAME และ MX mail.example.com. IN CNAME mailserver.provider.com. mail.example.com. IN MX 10 mail.provider.com. ; ใส่ไม่ได้ # ✅ ถูกต้อง — แยก subdomain ออกจากกัน webmail.example.com. IN CNAME mailserver.provider.com. example.com. IN MX 10 mail.provider.com.
เมื่อไหรควรใช้ A Record
A Record เหมาะสมที่สุดในสถานการณ์เหล่านี้:
- Root domain (@ หรือ example.com) — เป็น record เดียวที่ใช้ได้อย่างถูกต้องตาม standard ที่ root เสมอ (ยกเว้นใช้ ALIAS/CNAME Flattening)
- เซิร์ฟเวอร์ที่มี IP คงที่และไม่เปลี่ยนบ่อย — VPS หรือ Dedicated Server ที่รู้ IP แน่นอน
- ชื่อโดเมนที่ต้องมี MX หรือ TXT Records ร่วมด้วย — ถ้าจำเป็นต้องมี record หลายประเภทในชื่อเดียวกัน ต้องใช้ A Record
- DNS ง่ายๆ ที่ต้องการ lookup น้อยที่สุด — A Record ให้ความเร็ว lookup สูงสุดเพราะไม่มีขั้นตอนเพิ่มเติม
# ตัวอย่างการตั้งค่า A Record สำหรับ server ของตัวเอง @ 3600 IN A 203.0.113.10 www 3600 IN A 203.0.113.10 mail 3600 IN A 203.0.113.20 ftp 3600 IN A 203.0.113.10
เมื่อไหรควรใช้ CNAME
CNAME เหมาะที่สุดในกรณีต่อไปนี้:
- ชี้ subdomain ไปยังบริการ cloud ที่ IP อาจเปลี่ยน — เช่น AWS, GCP, Azure, Heroku, Vercel ซึ่งมักให้ hostname แทน IP เพราะ IP ของ cloud เปลี่ยนตาม load balancer
- www subdomain ที่ต้องการ sync กับ root —
www.example.com CNAME example.comให้ www ติดตาม root เสมอโดยไม่ต้องแก้ทั้งสอง - ชี้ subdomain หลายตัวไปยัง target เดียว — เช่น blog, shop, app ทั้งหมดชี้ไปยัง CDN hostname เดียวกัน เมื่อ CDN เปลี่ยน IP แก้ที่เดียวพอ
- Verification TXT กับ CNAME challenges — บริการบางอย่างเช่น Google Search Console, SSL provider ขอให้สร้าง CNAME เฉพาะสำหรับ domain ownership verification
# ตัวอย่างการตั้งค่า CNAME สำหรับบริการ cloud www 300 IN CNAME example.com. blog 300 IN CNAME mysite.netlify.app. shop 300 IN CNAME stores.example-ecom.com. _dmarc 300 IN CNAME dmarc-verify.provider.com. ; สำหรับ verification
CNAME Flattening และ ALIAS Record — ทางออกสำหรับ Root Domain
ปัญหาที่ CNAME ใช้ที่ root domain ไม่ได้มักเกิดขึ้นเมื่อต้องชี้ root domain ไปยัง CDN หรือบริการ cloud ที่ให้ hostname แทน IP โซลูชันคือฟีเจอร์พิเศษที่ DNS provider บางรายรองรับ ได้แก่:
CNAME Flattening (Cloudflare, NS1)
Cloudflare รองรับการใส่ CNAME ที่ root domain ผ่าน dashboard ในทางเทคนิค Cloudflare จะ resolve CNAME ที่ server-side และส่ง A Record กลับมาให้ client แทน ทำให้ใช้งานได้โดยไม่ผิด standard
ALIAS Record (Route53, DNSimple, Namecheap)
บาง DNS provider เสนอ record ประเภท ALIAS หรือ ANAME ซึ่งทำงานเหมือน CNAME แต่สามารถใช้ที่ root domain ได้ เพราะ provider จะ resolve ให้กลายเป็น A Record ก่อนที่จะส่งให้ client
# Cloudflare — ใส่ CNAME ที่ root ผ่าน dashboard ได้เลย @ CNAME myapp.vercel.app. ; Cloudflare จัดการ flatten ให้ # Route53 — ใช้ ALIAS @ ALIAS myapp.elb.amazonaws.com. ; เฉพาะ Route53
เคล็ดลับ: ถ้าใช้ Cloudflare เป็น nameserver สามารถใส่ CNAME ที่ root domain ได้เลยผ่าน dashboard โดยไม่ต้องกังวลเรื่อง RFC violation เพราะ Cloudflare จัดการ flatten ให้ที่ edge ก่อนส่งกลับ client วิธีนี้เหมาะมากสำหรับการชี้ root domain ไปยัง Vercel, Netlify หรือ GitHub Pages
กรณีตัวอย่างการใช้งานจริง
เพื่อให้เห็นภาพการใช้งานจริง ต่อไปนี้คือ DNS Zone สมมติสำหรับเว็บไซต์ธุรกิจทั่วไปที่ใช้ทั้ง A Record และ CNAME อย่างถูกต้อง:
; DNS Zone สำหรับ example.co.th ; Root domain ใช้ A Record @ 3600 IN A 203.0.113.10 ; www ใช้ CNAME ชี้กลับ root www 300 IN CNAME example.co.th. ; Mail server ใช้ A Record (ต้องมี MX ด้วย) mail 3600 IN A 203.0.113.20 @ 3600 IN MX 10 mail.example.co.th. ; Subdomain สำหรับบริการ cloud ใช้ CNAME blog 300 IN CNAME mysite.netlify.app. shop 300 IN CNAME exampleshop.myshopify.com. ; Static assets บน CDN cdn 300 IN CNAME cdn-endpoint.cloudfront.net. ; Verification สำหรับ SSL (ACME DNS-01 ใช้ TXT Record ไม่ใช่ CNAME ไปยัง letsencrypt.org) _acme-challenge 300 IN TXT "ACME_DNS01_VALIDATION_TOKEN"
สังเกตว่า root domain และ mail ใช้ A Record เพราะ mail ต้องการ MX ด้วย ส่วน subdomain ที่ชี้ไปบริการ cloud ใช้ CNAME เพราะ IP อาจเปลี่ยนและไม่มี record ประเภทอื่นร่วม รายการ _acme-challenge ใช้ TXT Record (ไม่ใช่ CNAME) บรรจุ token ที่ได้รับจาก ACME DNS-01 challenge ระหว่างการออก SSL certificate
ค่า TTL ที่เหมาะสมสำหรับแต่ละประเภท
TTL (Time to Live) กำหนดว่า DNS resolver จะ cache ค่านั้นไว้นานแค่ไหนก่อนจะถามใหม่ การตั้ง TTL ผิดส่งผลต่อทั้งความเร็ว DNS lookup และความเร็วในการ propagate การเปลี่ยนแปลง:
- A Record ที่ IP คงที่: 3600–86400 วินาที (1–24 ชั่วโมง) ค่า TTL สูงลด DNS query ได้มาก
- A Record ที่ IP อาจเปลี่ยน: 300–600 วินาที (5–10 นาที) เพื่อให้ propagate เร็วเมื่อต้องแก้
- CNAME ที่ชี้ไป cloud service: 300–900 วินาที ควร sync กับ TTL ของ target
- ก่อน migration หรือเปลี่ยน IP: ลด TTL ลงเหลือ 60–300 วินาที ล่วงหน้า 24–48 ชั่วโมง เพื่อให้ cache เก่าหมดอายุเร็วเมื่อถึงเวลาเปลี่ยน
; ตัวอย่าง TTL ที่เหมาะสม @ 86400 IN A 203.0.113.10 ; IP คงที่ — TTL 1 วัน www 300 IN CNAME example.co.th. ; TTL ต่ำ — ยืดหยุ่น blog 300 IN CNAME mysite.netlify.app. ; ตาม cloud TTL
หลังแก้ Record แล้ว อย่าเพิ่งเชื่อว่าทุกที่เห็นค่าใหม่ทันที — ตรวจด้วย DNS Propagation Checker ของ dnsxray.com ว่า Resolver แต่ละเจ้า (Google, Cloudflare รวมถึง 3BB ในไทย) คืนค่า A/CNAME ตัวใหม่ครบหรือยัง จะได้รู้ว่า Cache เก่าหมดจริงเมื่อไหร่
คำถามที่พบบ่อย (FAQ)
CNAME กับ A Record ต่างกันอย่างไรในทางเทคนิค
A Record ชี้ชื่อโดเมนไปยัง IP Address โดยตรง เช่น example.com → 203.0.113.10 ส่วน CNAME ชี้ชื่อโดเมนไปยังชื่อโดเมนอื่น เช่น www.example.com → example.com เมื่อ DNS resolver ค้นหา CNAME จะต้องทำการ lookup ซ้ำอีกครั้งเพื่อหา IP ของ target ทำให้มี latency เพิ่มเล็กน้อยแต่มีความยืดหยุ่นสูงกว่าเมื่อ IP เปลี่ยน
ทำไมถึงไม่ควรใส่ CNAME ที่ root domain (apex domain)
ตาม DNS standard (RFC 1034) โดเมนที่มี CNAME จะต้องไม่มี record ประเภทอื่นเลยในชื่อเดียวกัน แต่ root domain ต้องมี SOA และ NS records อยู่เสมอ ซึ่งขัดกัน DNS resolver หลายตัวจะปฏิเสธหรือทำงานผิดพลาด ทางออกคือใช้ A Record ที่ root แล้วใช้ CNAME ที่ subdomain (www) แทน หรือหาก provider รองรับ CNAME Flattening / ALIAS Record ก็ใช้ได้
จะใช้ CNAME หรือ A Record เมื่อชี้ไป Cloudflare
ขึ้นอยู่กับว่าต้องการชี้ที่ระดับไหน ถ้าต้องการชี้ subdomain เช่น www หรือ blog ไปยัง Cloudflare ให้ใช้ CNAME ชี้ไปที่ hostname ที่ Cloudflare กำหนด แต่ถ้าต้องการชี้ root domain ให้ใช้ A Record ชี้ไปยัง IP ของ Cloudflare โดยตรง Cloudflare เองก็รองรับ CNAME Flattening ที่ root ทำให้สามารถใส่ CNAME ที่ @ ได้ผ่าน dashboard ของ Cloudflare
CNAME ทำให้เว็บโหลดช้าลงจริงไหม
CNAME เพิ่ม DNS lookup อีก 1 ขั้น (resolver ต้องค้น target ซ้ำ) ซึ่งในทางทฤษฎีช้ากว่า A Record เล็กน้อย แต่ในทางปฏิบัติ DNS response ถูก cache โดย TTL ทั้งของ CNAME และ target ดังนั้นหลังการ lookup ครั้งแรก การเข้าถึงครั้งถัดไปจะเร็วเท่ากัน ผลต่อ user จริงแทบวัดไม่ได้ถ้า TTL ตั้งไว้เหมาะสม
จดโดเมนกับ AsiaGB ราคาย่อมเยา
จดโดเมน .com .net .co.th พร้อม DNS Management ครบชุด WHOIS Privacy ฟรี
จดโดเมน