Wildcard Subdomain คืออะไร ตั้งค่า DNS ให้รองรับ *.domain.com

Wildcard Subdomain คือการตั้งค่า DNS ที่ให้ทุก Subdomain ภายใต้โดเมนของคุณชี้ไปยัง Server เดียวกัน ด้วย Record แบบ *.domain.com แทนที่จะต้องสร้าง DNS Record ทีละ Subdomain ใช้กันมากใน SaaS Platform, Multi-tenant Web App และระบบที่ต้องการสร้าง Subdomain แบบ Dynamic

Wildcard DNS Record คืออะไร

ในระบบ DNS ดอกจันทร์ (*) คือ Wildcard Character ที่แทนที่ "ทุกชื่อที่เป็นไปได้" เมื่อตั้ง *.domain.com ชี้ไปที่ IP Address หนึ่ง จะหมายความว่าทุก Subdomain ที่ยังไม่มี Record เฉพาะ จะถูก Resolve ไปยัง IP นั้นโดยอัตโนมัติ

ตัวอย่าง: ถ้าตั้ง *.example.com → 1.2.3.4 แล้ว blog.example.com, shop.example.com, any123.example.com จะชี้ไปที่ IP เดียวกันทั้งหมด

วิธีตั้งค่า Wildcard DNS Record

ตั้งค่าผ่าน DirectAdmin

1. ล็อกอิน DirectAdmin → DNS Management
2. คลิก Add Record
3. ที่ช่อง Name ใส่ * (ดอกจันทร์อย่างเดียว)
4. เลือก Type เป็น A (สำหรับ IPv4) หรือ CNAME
5. ใส่ IP หรือ Hostname ปลายทาง
6. คลิก Add

ตัวอย่าง DNS Records

ตั้งค่า Wildcard DNS Record (*) ทีละขั้น พร้อมตัวอย่าง

ขั้นตอนต่อไปนี้อธิบายการสร้าง Wildcard Record ตั้งแต่ต้นจนใช้งานได้จริง สมมติว่าโดเมนของคุณคือ example.com และต้องการให้ทุก Subdomain ชี้ไปยัง Server ที่มี IP 203.0.113.10

1. ตรวจ Nameserver ก่อน: โดเมนต้องชี้มาที่ DNS Zone ที่คุณควบคุมได้ (เช่น Nameserver ของ AsiaGB หรือ DirectAdmin) ถ้าโดเมนยังใช้ DNS ของผู้ให้บริการเดิม การเพิ่ม Record จะไม่มีผล
2. เปิด DNS Zone: เข้าหน้าจัดการ DNS แล้วเลือกโดเมน example.com
3. เพิ่ม A Record แบบ Wildcard: ตั้งช่อง Name เป็น * Type เป็น A และ Value เป็น 203.0.113.10 ระบบ DNS ส่วนใหญ่จะเติม .example.com ต่อท้ายให้อัตโนมัติ กลายเป็น *.example.com
4. ตั้ง TTL ให้เหมาะสม: ช่วงทดสอบควรตั้ง TTL ต่ำ เช่น 300 วินาที (5 นาที) เพื่อให้แก้ไขแล้วเห็นผลเร็ว เมื่อมั่นใจแล้วค่อยเพิ่มเป็น 3600 วินาที
5. บันทึกและรอ Propagation: หลังบันทึก DNS ต้องใช้เวลากระจายตาม TTL ของ Record เดิม โดยทั่วไปไม่กี่นาทีถึงไม่กี่ชั่วโมง
6. ทดสอบด้วยคำสั่ง dig หรือ nslookup: ลองสุ่มชื่อ Subdomain ที่ไม่เคยสร้างมาก่อน ถ้า Resolve ได้ IP ที่ตั้งไว้ แปลว่า Wildcard ทำงานถูกต้อง

ตัวอย่างการทดสอบและผลลัพธ์ที่ควรได้:

ใช้งานจริงเมื่อไหร่ (Multi-tenant SaaS, User Subdomains)

Wildcard Subdomain เหมาะกับสถานการณ์ที่ คุณไม่รู้ล่วงหน้าว่าจะมี Subdomain ชื่ออะไรบ้าง หรือมีจำนวนมากเกินกว่าจะมานั่งสร้างทีละตัว ตัวอย่างที่พบบ่อยที่สุดในระบบจริง

Multi-tenant SaaS

แอปพลิเคชันแบบ SaaS ที่ให้ลูกค้าแต่ละรายมี Workspace ของตัวเอง มักใช้ Subdomain แยกตามลูกค้า เช่น acme.app.com, globex.app.com เมื่อมีลูกค้าใหม่สมัคร ระบบสร้าง Subdomain ให้ทันทีโดยไม่ต้องแก้ DNS — Wildcard Record *.app.com รองรับทุกชื่อที่จะเกิดขึ้นในอนาคต ส่วน Application อ่านค่า Subdomain จาก HTTP Host Header แล้ว Route ไปยังข้อมูลของลูกค้าที่ถูกต้อง

User Subdomains และ Vanity URL

แพลตฟอร์มที่ให้ผู้ใช้สร้างหน้าเว็บหรือ Profile ของตัวเอง เช่น username.platform.com ใช้ Wildcard เพื่อให้ผู้ใช้ทุกคนได้ Subdomain ของตัวเองทันทีที่สมัคร โดยไม่ต้องรอ Admin มาเพิ่ม DNS

Preview และ Staging อัตโนมัติ

ระบบ CI/CD ที่สร้าง Preview Environment ต่อ Branch หรือต่อ Pull Request เช่น pr-482.preview.com ใช้ Wildcard เพื่อให้ทุก Deploy ได้ URL ทันทีโดยไม่ต้องจัดการ DNS รายตัว ทำให้ทีมพัฒนาเปิดดูผลงานแต่ละเวอร์ชันได้สะดวก

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

กรณีใช้งาน Wildcard Subdomain

Wildcard Subdomain กับ Wildcard SSL Certificate

Wildcard DNS Record และ Wildcard SSL Certificate ทำงานคู่กันได้ดี SSL Certificate แบบ Wildcard (*.domain.com) ครอบคลุมทุก Subdomain ชั้นแรก เช่น blog.domain.com, shop.domain.com แต่ ไม่ครอบคลุม Sub-subdomain เช่น test.blog.domain.com

ถ้าต้องการครอบคลุม Sub-subdomain ต้องใช้ SSL หลายใบหรือ Multi-domain Wildcard Certificate

Wildcard Subdomain + Wildcard SSL ใช้คู่กัน

ในการใช้งานจริง Wildcard DNS Record และ Wildcard SSL Certificate มักถูกตั้งคู่กันเสมอ เพราะถ้ามีแค่ Wildcard DNS แต่ไม่มี SSL ที่ครอบคลุมทุก Subdomain ผู้ใช้จะเจอคำเตือน "Your connection is not private" ทุกครั้งที่เข้า Subdomain ใหม่ ลำดับการตั้งค่าที่แนะนำมีดังนี้

1. ตั้ง Wildcard DNS Record *.example.com ชี้ไปยัง Server ก่อน (ตามขั้นตอนด้านบน)
2. ออก Wildcard SSL Certificate สำหรับ *.example.com โดยทั่วไปต้องยืนยันความเป็นเจ้าของผ่าน DNS Validation (เพิ่ม TXT Record ชั่วคราว) ซึ่งเป็นวิธีที่ CA ส่วนใหญ่บังคับสำหรับ Wildcard เพราะ HTTP Validation ทำกับทุก Subdomain พร้อมกันไม่ได้
3. ติดตั้ง Certificate บน Web Server แล้วตั้งให้ใช้กับทุก Virtual Host ที่ Route จาก Wildcard

*หมายเหตุ: Wildcard SSL บางใบรวม Root Domain (example.com) ให้ด้วยในรูปแบบ SAN แต่ไม่ใช่ทุกใบ ควรตรวจรายการ Subject Alternative Name ของ Certificate ก่อนนำไปใช้งานจริง

ข้อดีของการใช้ทั้งสองอย่างคู่กันคือ เมื่อมี Subdomain ใหม่เกิดขึ้น ระบบของคุณจะรองรับได้ทันทีทั้งในระดับการชี้ปลายทาง (DNS) และในระดับความปลอดภัยของการเชื่อมต่อ (SSL) โดยไม่ต้องออกใบรับรองใหม่หรือแก้ค่าใดเพิ่ม ผู้ใช้ที่เข้าเว็บผ่าน Subdomain ใดก็ตามจะเห็นกุญแจล็อกสีเขียวและเชื่อมต่อแบบเข้ารหัสได้ทันที ซึ่งช่วยสร้างความน่าเชื่อถือให้กับบริการของคุณ ทั้งนี้ควรตั้งให้เว็บเซิร์ฟเวอร์บังคับ HTTPS และ Redirect จาก HTTP ไป HTTPS เสมอ เพื่อไม่ให้มี Subdomain ใดเปิดผ่านการเชื่อมต่อที่ไม่ปลอดภัยหลุดรอดไป

ข้อควรระวังและข้อจำกัด

• ไม่รองรับ Sub-subdomain: *.example.com ไม่ครอบคลุม a.b.example.com
• Security Risk: ทุก Subdomain ที่ผู้ไม่หวังดีพิมพ์จะถูก Resolve มายัง Server คุณ ต้องมี Firewall และ Rate Limiting
• Email ไม่ใช้ Wildcard: MX Record ต้องตั้งแยกสำหรับแต่ละโดเมน Wildcard MX ไม่รองรับในบาง Mail System
• Search Engine: Google อาจ Index Subdomain ที่ไม่ต้องการ ควรตั้ง robots.txt หรือ noindex ให้ Subdomain ที่ไม่ต้องการ

ข้อควรระวัง (ความปลอดภัยและ Catch-all ที่ไม่ตั้งใจ)

ความสะดวกของ Wildcard มาพร้อมความเสี่ยงที่ต้องเข้าใจก่อนนำไปใช้บนระบบ Production จุดสำคัญที่หลายคนมองข้ามคือ Wildcard ทำให้เกิด "Catch-all" โดยไม่ตั้งใจ — ทุกชื่อที่ใครก็ตามพิมพ์เข้ามาจะถูกส่งมาที่ Server ของคุณ แม้จะเป็นชื่อที่คุณไม่เคยตั้งใจให้มีอยู่

Subdomain Takeover และ Phishing

ถ้า Server ตอบทุก Subdomain โดยไม่ตรวจสอบ ผู้ไม่หวังดีอาจใช้ Subdomain แปลกๆ ภายใต้แบรนด์ของคุณ เช่น login-secure.example.com เพื่อทำหน้า Phishing ที่ดูน่าเชื่อถือเพราะอยู่ใต้โดเมนจริง ทางป้องกันคือให้ Application Reject ทุก Host ที่ไม่อยู่ใน Allowlist และส่งคืน 404 หรือ Redirect ไปหน้าหลัก

Cookie Scope รั่วข้าม Subdomain

ถ้าตั้ง Cookie ด้วย Domain .example.com Cookie นั้นจะถูกส่งไปทุก Subdomain รวมถึง Subdomain ของลูกค้ารายอื่นในระบบ Multi-tenant ซึ่งอาจทำให้ Session หรือ Token รั่วข้ามกัน ควรจำกัด Scope ของ Cookie ให้เฉพาะ Subdomain ที่จำเป็นเท่านั้น

การ Monitor และ Log

• เปิด Log ระดับ Host: บันทึกว่ามีการเข้าถึง Subdomain ใดบ้าง เพื่อจับ Subdomain ที่ไม่คาดคิด
• Rate Limiting: จำกัดจำนวน Request ต่อ IP เพราะ Wildcard เปิดช่องให้ยิงชื่อ Subdomain แบบสุ่มได้ไม่จำกัด
• แยก Environment: อย่าใช้ Wildcard เดียวครอบทั้ง Production และ Staging — ควรแยก Zone หรือแยกโดเมน
• noindex สำหรับ Subdomain ที่ไม่ต้องการ: ตั้ง X-Robots-Tag: noindex หรือ robots.txt ให้ Subdomain ภายในเพื่อกัน Search Engine เก็บข้อมูลที่ไม่ควรเปิดเผย

คำถามที่พบบ่อย (FAQ)

Wildcard Subdomain ต่างจากการสร้าง Subdomain ปกติอย่างไร?

การสร้าง Subdomain ปกติคือการเพิ่ม DNS Record ทีละชื่อ (blog.example.com, shop.example.com) ส่วน Wildcard ใช้ Record เดียว *.example.com รองรับทุกชื่อที่ยังไม่มี Record เฉพาะ เหมาะเมื่อมี Subdomain จำนวนมากหรือสร้างแบบ Dynamic ตอน Runtime

Wildcard Record รองรับ Sub-subdomain เช่น a.b.example.com ไหม?

ไม่รองรับ *.example.com ครอบเฉพาะ Subdomain ชั้นเดียว ถ้าต้องการให้ a.b.example.com ทำงาน ต้องเพิ่ม Record *.b.example.com แยกต่างหาก

ใช้ Wildcard กับ Email (MX) ได้หรือไม่?

ไม่แนะนำ Wildcard MX ไม่ได้รองรับในทุก Mail System และทำให้เกิดปัญหาการรับเมลที่คาดเดายาก ควรตั้ง MX Record เฉพาะสำหรับโดเมนหรือ Subdomain ที่ต้องการรับอีเมลจริงเท่านั้น

ต้องตั้ง TTL เท่าไหร่สำหรับ Wildcard Record?

ช่วงทดสอบใช้ TTL ต่ำ เช่น 300 วินาที เพื่อให้แก้ไขเห็นผลเร็ว เมื่อระบบเสถียรแล้วเพิ่มเป็น 3600 วินาทีหรือมากกว่า เพื่อลดภาระการ Query และเพิ่มความเร็วการ Resolve