เมื่อคุณเปลี่ยน Nameserver ของโดเมน ไม่ว่าจะเป็นการย้ายโฮสติ้ง ตั้ง DNS ใหม่ หรือชี้โดเมนไปยังเซิร์ฟเวอร์ใหม่ สิ่งที่หลายคนสงสัยคือ "ต้องรอนานแค่ไหนถึงจะใช้งานได้?" คำตอบอยู่ที่กระบวนการที่เรียกว่า DNS Propagation ซึ่งเป็นการกระจาย DNS record ใหม่ออกไปยัง Resolver ทั่วโลก บทความนี้จะอธิบายว่ากระบวนการนี้ทำงานอย่างไร ใช้เวลานานแค่ไหน และวิธีเช็คสถานะว่า propagate ครบแล้วหรือยังด้วยเครื่องมือฟรีและคำสั่ง Terminal
DNS Propagation คืออะไร ทำงานอย่างไร
DNS (Domain Name System) คือระบบแปลงชื่อโดเมน เช่น example.com ให้เป็น IP Address ที่เซิร์ฟเวอร์จริงใช้งาน เมื่อคุณพิมพ์ URL ใน Browser คอมพิวเตอร์จะถาม DNS Resolver (มักเป็นของ ISP หรือ Google 8.8.8.8 / Cloudflare 1.1.1.1) ว่า IP ของโดเมนนั้นคือเท่าไร
Resolver ไม่ได้ query ต้นทาง (Authoritative Nameserver) ทุกครั้ง แต่จะ cache คำตอบไว้ในช่วงเวลาที่กำหนดโดยค่า TTL (Time to Live) ของ DNS record นั้น เมื่อคุณเปลี่ยน Nameserver หรือ DNS record ข้อมูลใหม่จะถูกบันทึกที่ Authoritative Nameserver ของโดเมนของคุณทันที แต่ Resolver ทั่วโลกยังคง cache ข้อมูลเก่าไว้จนกว่า TTL จะหมดอายุ — กระบวนการที่ resolver แต่ละตัวทยอย flush cache และ query ข้อมูลใหม่นี้แหละที่เรียกว่า DNS Propagation
ดังนั้น propagation ไม่ใช่การ "push" ข้อมูลออกไปจากส่วนกลาง แต่เป็นการที่ resolver แต่ละตัวทั่วโลก "ดึง" ข้อมูลใหม่มาเองเมื่อ cache หมดอายุ — นี่คือเหตุผลที่แต่ละคนอาจเห็น DNS ที่ต่างกันได้ในช่วงเปลี่ยนผ่าน
ใช้เวลานานแค่ไหน — ตัวเลขจริงที่ควรรู้
ระยะเวลา DNS Propagation ขึ้นอยู่กับหลายปัจจัย แต่ตัวเลขที่พบบ่อยในทางปฏิบัติมีดังนี้:
| สถานการณ์ | ระยะเวลาโดยทั่วไป | ระยะเวลาสูงสุด |
|---|---|---|
| เปลี่ยน Nameserver (TTL เดิมสูง) | 12–24 ชั่วโมง | 48–72 ชั่วโมง |
| เปลี่ยน Nameserver (ลด TTL ล่วงหน้าแล้ว) | 1–4 ชั่วโมง | 12 ชั่วโมง |
| แก้ A Record (TTL = 3600) | 1–2 ชั่วโมง | 6 ชั่วโมง |
| แก้ A Record (TTL = 300) | 5–10 นาที | 30 นาที |
| แก้ MX Record | 1–4 ชั่วโมง | 24 ชั่วโมง |
| แก้ TXT / CNAME Record | 15 นาที – 2 ชั่วโมง | 24 ชั่วโมง |
ข้อมูลข้างต้นเป็นค่าเฉลี่ย บาง ISP หรือ resolver บางตัวอาจใช้เวลานานกว่านี้หากมีปัญหา cache หรือ configuration พิเศษ ส่วน resolver ที่ใช้ TTL แบบ minimum (เช่น Cloudflare 1.1.1.1 ที่ honor TTL ค่อนข้างตรง) มักเร็วกว่า ISP ทั่วไปที่บางครั้ง override TTL ด้วยค่าสูงกว่าเพื่อลด load
ปัจจัยที่ส่งผลต่อความเร็ว DNS Propagation
การเข้าใจปัจจัยเหล่านี้จะช่วยให้วางแผนการเปลี่ยน DNS ได้ดียิ่งขึ้น:
- TTL ของ DNS Record เดิม — ค่าที่สำคัญที่สุด ถ้า TTL เดิมเป็น 86400 (1 วัน) Resolver จะไม่ query ใหม่จนกว่าจะผ่าน 24 ชั่วโมงนับจากที่ query ล่าสุด ยิ่ง TTL สูง ยิ่งรอนาน
- การลด TTL ล่วงหน้า — ถ้าลด TTL เป็น 300–600 วินาทีไว้ก่อนเปลี่ยน resolver จะเริ่ม flush cache และดึง record ใหม่เร็วมากหลังการเปลี่ยน
- ISP ของผู้ใช้ — ISP บางเจ้า (โดยเฉพาะในประเทศที่มี internet infrastructure เก่า) cache DNS ในเวลานานกว่าที่ TTL กำหนด ทำให้ผู้ใช้ ISP นั้นเห็น DNS เดิมนานกว่าคนอื่น
- ตำแหน่งทางภูมิศาสตร์ — resolver ในภูมิภาคที่ไกลจาก Authoritative Nameserver อาจต้องผ่าน hop มากกว่า แต่ผลต่อ propagation จริงๆ น้อยกว่า TTL มาก
- ประเภทของ Record ที่เปลี่ยน — การเปลี่ยน Nameserver (NS record) ต้องรอให้ registry (เช่น Verisign สำหรับ .com) อัปเดตข้อมูลในระบบก่อน ซึ่งปกติใช้เวลา 15–60 นาทีแล้วจึงเริ่ม propagate ขณะที่การเปลี่ยน A record บน Authoritative Nameserver เดิมมีผลทันที
- Negative Cache — ถ้า Resolver เคย query และได้ NXDOMAIN (ไม่มี record) ไว้ก่อน จะ cache ผลลบนั้นไว้ด้วย (ตาม negative TTL ใน SOA record) ทำให้แม้จะเพิ่ม record แล้ว บาง resolver ยังเห็น "ไม่มี" อยู่อีกสักพัก
วิธีลด TTL ล่วงหน้าก่อนเปลี่ยน Nameserver
นี่คือขั้นตอนที่ผู้เชี่ยวชาญใช้เพื่อลด downtime ให้น้อยที่สุดเมื่อต้องย้ายโฮสติ้งหรือเปลี่ยน Nameserver:
ขั้นตอนที่ 1 — ตรวจ TTL ปัจจุบัน
dig yourdomain.com NS dig yourdomain.com A
ดูค่า TTL ในคอลัมน์ที่ 2 ของผลลัพธ์ ถ้า TTL เป็น 86400 หรือ 43200 แปลว่าต้องลดก่อนล่วงหน้า 1–2 วัน
ขั้นตอนที่ 2 — ลด TTL ล่วงหน้า 24–48 ชั่วโมง
เข้าไปที่ DNS Management panel ของ Registrar หรือ DNS provider ปัจจุบัน แล้วลด TTL ของ A Record, AAAA Record, MX Record และ CNAME ที่สำคัญให้เหลือ 300–600 วินาที รอให้ TTL เดิมหมดอายุ (ต้องรอเท่ากับค่า TTL เดิม ถ้า TTL เดิม = 86400 ต้องรอ 24 ชั่วโมงหลังลด TTL)
ขั้นตอนที่ 3 — เปลี่ยน Nameserver
หลังจากที่ TTL ต่ำมีผลแล้ว ค่อยเปลี่ยน Nameserver ในหน้า Registrar ของโดเมน
ขั้นตอนที่ 4 — เพิ่ม TTL กลับหลัง propagate ครบ
เมื่อยืนยันได้ว่า propagate ครบทั่วโลกแล้ว ให้เพิ่ม TTL กลับเป็น 3600–86400 เพื่อประสิทธิภาพ (TTL ต่ำทำให้ DNS query ถี่ขึ้น ใช้ทรัพยากรมากกว่า)
เครื่องมือเช็ค DNS Propagation ออนไลน์ฟรี
มีเครื่องมือหลายตัวที่ช่วยให้คุณเห็นสถานะ DNS จาก Location ต่างๆ ทั่วโลกได้พร้อมกัน:
- whatsmydns.net — แสดงผล DNS record (A, AAAA, MX, NS, CNAME, TXT) จาก ~100 location ทั่วโลก เห็นได้ชัดว่าจุดไหน propagate แล้ว จุดไหนยังเห็นค่าเดิม
- dnschecker.org — คล้ายกัน แต่มี UI ที่แสดง flag ประเทศให้เห็นชัดเจน แนะนำสำหรับผู้ใช้ทั่วไปที่ไม่คุ้นกับ Terminal
- mxtoolbox.com — เหมาะสำหรับตรวจ MX Record และ email-related DNS โดยเฉพาะ มีฟีเจอร์ blacklist check ด้วย
- intodns.com — ตรวจ DNS configuration ครบวงจร รายงาน warning และ error ในการตั้งค่า DNS ที่ไม่ถูกต้อง
- Google Admin Toolbox dig — toolbox.googleapps.com/apps/dig/ เหมาะสำหรับตรวจแบบ query ตรงจาก Google Infrastructure
เช็ค DNS Propagation ด้วย Command Line
สำหรับผู้ที่ต้องการความแม่นยำและต้องการ query จาก DNS server ที่กำหนดเองได้ การใช้ Terminal เป็นวิธีที่ดีที่สุด
คำสั่ง dig (Linux / macOS)
ตรวจ A Record จาก Google DNS:
dig @8.8.8.8 yourdomain.com A
ตรวจ NS Record (Nameserver) ว่าอัปเดตแล้วหรือยัง:
dig @8.8.8.8 yourdomain.com NS
ตรวจ MX Record สำหรับ Email:
dig @1.1.1.1 yourdomain.com MX
ดู TTL ที่เหลืออยู่ (ค่าในคอลัมน์ที่ 2 ของ ANSWER SECTION):
dig @8.8.8.8 yourdomain.com A +noall +answer
ตรวจ Authoritative Nameserver โดยตรง (ข้าม cache ทุก resolver):
# ดู Authoritative NS ของโดเมน dig yourdomain.com NS +short # Query โดยตรงจาก Authoritative NS dig @ns1.your-nameserver.com yourdomain.com A
คำสั่ง nslookup (Windows / macOS / Linux)
# ตรวจ A Record จาก Cloudflare DNS nslookup yourdomain.com 1.1.1.1 # ตรวจ NS Record nslookup -type=NS yourdomain.com 8.8.8.8 # ตรวจ MX Record nslookup -type=MX yourdomain.com 8.8.8.8
ตรวจจาก DNS Server หลายตัวพร้อมกัน
เปรียบเทียบผลจาก resolver ต่างๆ เพื่อดูว่า propagate ครบทุกที่หรือยัง:
# Google dig @8.8.8.8 yourdomain.com A +short # Cloudflare dig @1.1.1.1 yourdomain.com A +short # OpenDNS dig @208.67.222.222 yourdomain.com A +short # True / AIS (ทดสอบฝั่ง ISP ไทย) dig @203.113.65.100 yourdomain.com A +short
ถ้าทุก resolver ตอบ IP เดิม แสดงว่า propagation เสร็จสมบูรณ์แล้ว
เคล็ดลับมือโปร: ก่อนเปลี่ยน Nameserver ทุกครั้ง ให้รัน dig yourdomain.com NS +short และจดค่า TTL ปัจจุบันไว้ก่อน แล้วลด TTL ให้เหลือ 300 วินาที (5 นาที) รอให้ครบเวลาเท่ากับ TTL เดิม จากนั้นค่อยเปลี่ยน Nameserver — วิธีนี้ทำให้ propagate เสร็จภายใน 5–30 นาที แทนที่จะรอ 24–48 ชั่วโมง และลด downtime ได้เกือบเป็นศูนย์
สัญญาณที่บอกว่า DNS Propagation เสร็จแล้ว
หลังเปลี่ยน Nameserver หรือ DNS Record ให้ตรวจสัญญาณเหล่านี้เพื่อยืนยัน:
- whatsmydns.net แสดงสีเขียวทุก location — ทุก resolver ที่ตรวจได้รับ record ใหม่แล้ว
- dig query ให้ IP ใหม่จากทุก DNS server ที่ทดสอบ — ไม่มี resolver ที่ยังตอบ IP เก่า
- เว็บโหลดได้จากทุก device และทุก network — รวมถึงเครือข่ายมือถือ (ใช้ DNS ของ ISP ไม่ใช่ Wi-Fi บ้าน)
- SSL Certificate ออกได้สำเร็จ — ถ้าใช้ Let's Encrypt หรือ CA ที่ทำ domain validation ผ่าน DNS การที่ cert ออกได้แปลว่า DNS แก้ถูกแล้ว
- Email ส่ง-รับได้ปกติ — ยืนยัน MX record propagate เรียบร้อยแล้ว (ทดสอบโดยส่ง email ไปยัง address นั้นจาก Gmail หรือ Outlook)
ปัญหาที่พบบ่อยและวิธีแก้
แม้ propagation จะเสร็จสมบูรณ์แล้วแต่ผู้ใช้บางคนยังเข้าเว็บไม่ได้ มักเกิดจากสาเหตุเหล่านี้:
Browser Cache ล้าง DNS ค้างอยู่
ทั้ง Chrome และ OS มี DNS cache ของตัวเอง วิธีล้าง:
# macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder # Windows ipconfig /flushdns # Chrome browser (พิมพ์ใน address bar) chrome://net-internals/#dns
Router Cache ในบ้าน/ออฟฟิศ
Router บางรุ่น cache DNS ไว้เองแยกจาก OS ให้ลอง restart router หรือเชื่อมต่อผ่าน mobile data แทน Wi-Fi เพื่อทดสอบ
ISP Override TTL
ISP บางเจ้า (โดยเฉพาะ ISP ไทยบางราย) ตั้ง minimum TTL สำหรับ cache ของตัวเองที่สูงกว่าที่ record กำหนด ทำให้ผู้ใช้ ISP นั้นรอนานกว่า วิธีแก้ระยะสั้นคือแนะนำผู้ใช้ให้เปลี่ยน DNS server เป็น 8.8.8.8 หรือ 1.1.1.1 ชั่วคราว
Negative TTL จาก SOA Record
ถ้าเคยมี record แล้ว delete ไป Resolver บางตัว cache NXDOMAIN ไว้ตาม negative TTL ใน SOA record ตรวจด้วย:
dig yourdomain.com SOA +short
ค่าตัวสุดท้ายใน SOA คือ Negative TTL (วินาที) ต้องรอจนกว่าจะครบ
Glue Record ไม่อัปเดต
ถ้า Nameserver ใช้ subdomain ของโดเมนตัวเอง เช่น ns1.yourdomain.com ต้องตั้ง Glue Record ที่ Registrar ด้วย ไม่เช่นนั้นจะเกิด circular dependency ทำให้ resolve ไม่ได้เลย
คำถามที่พบบ่อย (FAQ)
DNS Propagation ใช้เวลานานแค่ไหน
โดยทั่วไป DNS Propagation ใช้เวลาระหว่าง 24–48 ชั่วโมง แต่ส่วนใหญ่จะเสร็จภายใน 4–8 ชั่วโมง ปัจจัยที่กำหนดคือค่า TTL ของ DNS record เดิม ยิ่ง TTL สูง resolver ยิ่งรอนานกว่าจะ query ใหม่ หากต้องการเร่ง propagation ให้ลด TTL ล่วงหน้าก่อนเปลี่ยน Nameserver อย่างน้อย 24–48 ชั่วโมง
เช็ค DNS Propagation ได้จากที่ไหนบ้าง
สามารถเช็คได้หลายวิธี ได้แก่ เว็บไซต์ whatsmydns.net และ dnschecker.org ที่แสดงผล DNS จากหลายประเทศพร้อมกัน หรือใช้คำสั่ง dig ใน Terminal เช่น dig @8.8.8.8 yourdomain.com NS และ nslookup yourdomain.com 8.8.8.8 บน Windows สามารถระบุ DNS server ต่างๆ เพื่อดูว่า propagate ไปถึงที่นั้นหรือยัง
ทำไม DNS Propagation บางจุดเสร็จแล้วแต่บางจุดยังไม่เสร็จ
เพราะ resolver แต่ละตัวทั่วโลกมี cache ของตัวเองและ refresh ในเวลาที่ต่างกัน ขึ้นอยู่กับ TTL ของ record ที่ cache ไว้ก่อนหน้า ISP ในแต่ละประเทศอาจเคย query ในช่วงเวลาต่างกัน ทำให้ TTL หมดอายุไม่พร้อมกัน นี่คือปรากฏการณ์ปกติของ DNS ซึ่งเป็นระบบกระจายศูนย์ (distributed) ไม่มีการ invalidate cache แบบกลางเหมือน CDN
ลด TTL ก่อนเปลี่ยน Nameserver จำเป็นหรือไม่
จำเป็นมากหากต้องการลด downtime ให้น้อยที่สุด แนวทางที่ดีคือลด TTL ของ A record และ NS record ให้เหลือ 300–600 วินาที (5–10 นาที) ล่วงหน้าอย่างน้อย 24–48 ชั่วโมงก่อนวันเปลี่ยน Nameserver เพื่อให้ resolver ทั่วโลก flush cache เร็วขึ้นหลังเปลี่ยน เมื่อ propagate ครบแล้วจึงเพิ่ม TTL กลับเป็นค่าปกติ (3600–86400)
จดโดเมนกับ AsiaGB ราคาย่อมเยา
จดโดเมน .com .net .co.th พร้อม DNS Management ครบชุด WHOIS Privacy ฟรี
จดโดเมน