THAI DATA CLOUD
Domainname Manual

ทำความเข้าใจ TTL และวางแผนย้าย DNS ไม่ให้เว็บล่ม

เข้าใจว่า TTL ของ DNS ทำงานอย่างไร แล้ววางแผนลด TTL ล่วงหน้า สลับ Record และตรวจผลด้วย dig เพื่อย้ายเว็บหรืออีเมลไปเซิร์ฟเวอร์ใหม่โดยไม่มีช่วงล่ม

โดย ทีมงาน THAI DATA CLOUD อัปเดต อ่าน 8 นาที เข้าชม 3 ครั้ง

แชร์FacebookXLINELinkedIn
TTL — ทำความเข้าใจ TTL และวางแผนย้าย DNS ไม่ให้เว็บล่ม
ทำความเข้าใจ TTL และวางแผนย้าย DNS ไม่ให้เว็บล่ม

คำตอบสั้น ๆ: เข้าใจว่า TTL ของ DNS ทำงานอย่างไร แล้ววางแผนลด TTL ล่วงหน้า สลับ Record และตรวจผลด้วย dig เพื่อย้ายเว็บหรืออีเมลไปเซิร์ฟเวอร์ใหม่โดยไม่มีช่วงล่ม

คู่มือนี้อธิบาย TTL ทีละขั้นตอน พร้อมคำสั่งที่ใช้ได้จริงและปัญหาที่พบบ่อย

TTL (Time To Live) คือเวลาเป็นวินาทีที่ DNS Resolver เช่นของผู้ให้บริการอินเทอร์เน็ตหรือ 8.8.8.8 ได้รับอนุญาตให้จำคำตอบของ Record ไว้ก่อนจะถามใหม่ ถ้า A Record ของเว็บมี TTL 86400 (1 วัน) แล้วคุณเปลี่ยน IP ผู้ใช้บางส่วนอาจยังถูกพาไปเซิร์ฟเวอร์เก่านานถึง 1 วัน อาการ "DNS ยังไม่อัปเดต" ที่หลายคนเรียกว่ารอ Propagate จริง ๆ แล้วก็คือการรอ Cache หมดอายุตาม TTL นี่เอง

ข่าวดีคือเรารู้ล่วงหน้าได้ว่าจะต้องรอนานแค่ไหน และลดเวลารอได้ด้วยการลด TTL ก่อนย้าย บทความนี้เป็นแผนย้ายที่ใช้ได้ทั้งการย้ายเว็บ ย้ายอีเมล หรือเปลี่ยนผู้ให้บริการ DNS

สิ่งที่ต้องเตรียม

  • สิทธิ์แก้ไข DNS Zone ปัจจุบันของโดเมน
  • เซิร์ฟเวอร์ใหม่ที่ติดตั้งเว็บหรืออีเมลเสร็จแล้ว หรืออย่างน้อยพร้อมทดสอบ
  • เครื่องที่มีคำสั่ง dig (Linux, macOS) หรือ nslookup (Windows) ดูพื้นฐานได้ที่ ตรวจสอบ DNS ด้วย nslookup และ dig
  • เวลาอย่างน้อย 2 วันก่อนวันย้ายจริง

TTL ที่ควรรู้จัก

ค่า TTLเท่ากับใช้เมื่อ
3005 นาทีช่วงก่อนและระหว่างย้าย
36001 ชั่วโมงค่าปกติที่สมดุลสำหรับเว็บทั่วไป
14400-864004 ชั่วโมงถึง 1 วันRecord ที่แทบไม่เปลี่ยน เช่น MX ที่ใช้มานาน

TTL ต่ำเกินไปตลอดเวลาไม่มีประโยชน์ เพราะทำให้ Resolver ถามบ่อยขึ้น เว็บตอบช้าลงเล็กน้อยในครั้งแรกของแต่ละผู้ใช้ จึงควรลดเฉพาะช่วงย้าย

หมายเหตุ: การเปลี่ยน Name Server ที่ผู้รับจดโดเมนต่างจากการเปลี่ยน Record ค่า TTL ของ NS ที่ระดับ Registry (เช่นของ .com มักเป็น 172800 วินาที หรือ 2 วัน) ถูกกำหนดโดย Registry คุณแก้ไม่ได้ ดังนั้นถ้าจะย้ายผู้ให้บริการ DNS ให้สร้าง Zone ที่ใหม่ให้เหมือนที่เดิมทุก Record ก่อน และคง Zone เดิมไว้อย่างน้อย 2-3 วันหลังเปลี่ยน

ขั้นตอนที่ 1: สำรวจ Record ปัจจุบันและ TTL เดิม

ถาม Name Server ต้นทางโดยตรงเพื่อดูค่า TTL จริง

dig +short NS example.com
dig @ns1.example-dns.net example.com A +noall +answer
dig @ns1.example-dns.net www.example.com A +noall +answer
dig @ns1.example-dns.net example.com MX +noall +answer

ผลลัพธ์จะมีรูปแบบนี้ ตัวเลขคอลัมน์ที่สองคือ TTL

example.com.   86400   IN   A   198.51.100.20

จดทุก Record ที่เกี่ยวข้องไว้ รวมถึง TXT ของ SPF และ DKIM, CNAME ของบริการภายนอก และ Subdomain ที่ใช้งาน ส่งออกเป็นไฟล์หรือถ่ายภาพหน้าจอเก็บไว้เป็นข้อมูลสำรองก่อนแก้ไขอะไร

ขั้นตอนที่ 2: ลด TTL ล่วงหน้า

แก้ TTL ของ Record ที่จะเปลี่ยนเป็น 300 ก่อนวันย้ายอย่างน้อยเท่ากับค่า TTL เดิม ถ้า TTL เดิมคือ 86400 ต้องลดก่อนอย่างน้อย 24 ชั่วโมง เผื่อไว้เป็น 48 ชั่วโมงจะปลอดภัยกว่า เหตุผลคือ Resolver ที่จำค่าเดิมไว้จะยังจำ TTL 86400 จนหมดรอบ จึงจะเห็นค่า 300 ใหม่

ยังไม่ต้องเปลี่ยน IP ในขั้นนี้ เปลี่ยนเฉพาะ TTL

ขั้นตอนที่ 3: ทดสอบเซิร์ฟเวอร์ใหม่โดยไม่ต้องแก้ DNS

ใช้ Hosts File บังคับให้เฉพาะเครื่องของคุณมองโดเมนเป็น IP ใหม่ แล้วทดสอบเว็บ ฟอร์ม การ Login และ SSL ให้ครบ วิธีแก้บน macOS ดู แก้ไข Hosts File บน macOS บน Linux แก้ไฟล์ /etc/hosts บน Windows แก้ C:\Windows\System32\drivers\etc\hosts ด้วย Notepad ที่เปิดแบบ Run as administrator

203.0.113.10   example.com www.example.com

หรือทดสอบจากคอมมานด์ไลน์โดยไม่แตะ Hosts File

curl -sI --resolve example.com:443:203.0.113.10 https://example.com

ทดสอบเสร็จแล้วอย่าลืมลบบรรทัดใน Hosts File ออก

ขั้นตอนที่ 4: สลับ Record ในวันย้าย

  1. เลือกช่วงที่มีผู้ใช้น้อย
  2. ถ้าเว็บมีข้อมูลเปลี่ยนตลอด (ร้านค้า ฟอร์ม สมาชิก) ให้ปิดการแก้ไขชั่วคราวหรือเปิดโหมด Maintenance ที่เซิร์ฟเวอร์เก่า แล้วซิงก์ฐานข้อมูลรอบสุดท้ายไปเซิร์ฟเวอร์ใหม่ ดูแนวทางที่ ย้าย WordPress ไปโฮสต์ใหม่
  3. แก้ A Record (และ AAAA ถ้ามี) ของ example.com และ www เป็น IP ใหม่
  4. เปิดเซิร์ฟเวอร์เก่าทิ้งไว้ อย่างน้อย 2-3 วัน เพื่อรองรับผู้ใช้ที่ Resolver ยังจำค่าเก่า

ขั้นตอนที่ 5: ย้ายอีเมล ต้องระวังเป็นพิเศษ

อีเมลต่างจากเว็บตรงที่ถ้าส่งไปผิดที่ จะไปค้างในกล่องของเซิร์ฟเวอร์เก่า ไม่ได้หายแต่ผู้ใช้ไม่เห็น ให้สร้างกล่องอีเมลที่ปลายทางให้ครบก่อนสลับ MX หลังสลับให้เก็บเซิร์ฟเวอร์เก่าไว้รับอีเมลที่ค้างและดึงข้อมูลย้ายตามมาอีกครั้ง และอัปเดต SPF ให้รวม IP ของเซิร์ฟเวอร์ใหม่ ดู ตั้งค่า SPF, DKIM และ DMARC

ตรวจสอบผลลัพธ์

dig @ns1.example-dns.net example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answer

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

ขั้นตอนที่ 6: คืนค่า TTL

เมื่อทุกอย่างทำงานบนเซิร์ฟเวอร์ใหม่ได้ 1-2 วัน ให้ตั้ง TTL กลับเป็น 3600 หรือค่าที่เหมาะสม

ปัญหาที่พบบ่อย

ลด TTL แล้วแต่ผู้ใช้บางคนยังเห็นเว็บเก่าหลายชั่วโมง

ลด TTL ช้าเกินไป (ไม่ถึงรอบ TTL เดิม) หรือเครื่องผู้ใช้และเบราว์เซอร์มี Cache ของตัวเอง ให้ผู้ใช้ล้าง DNS Cache เช่นบน Windows ใช้ ipconfig /flushdns บน macOS ใช้ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Subdomain หรือบริการเล็ก ๆ หยุดทำงานหลังย้าย Name Server

ลืมสร้าง Record บางตัวใน Zone ใหม่ เช่น CNAME ของระบบภายนอกหรือ TXT ยืนยันโดเมน เปรียบเทียบกับรายการที่จดไว้ในขั้นตอนที่ 1 ประเภท Record ต่าง ๆ ดูได้ที่ ประเภทของ DNS Record

เพิ่ม Record ใหม่แล้วยังค้นหาไม่เจอนานผิดปกติ

อาจเป็น Negative Cache คือ Resolver จำไว้ว่าชื่อนั้น "ไม่มี" ตามค่า Minimum TTL ใน SOA Record ถ้าเคยค้นชื่อนั้นก่อนสร้าง ให้รอครบเวลาดังกล่าว ดูค่าได้จาก dig example.com SOA +short ตัวเลขตัวสุดท้ายคือค่านี้

หากทำตามขั้นตอนแล้วยังติดปัญหา สามารถติดต่อทีมงานซัพพอร์ตของ THAI DATA CLOUD ได้ที่ https://thaidata.cloud/contact/ โดยแจ้งชื่อโดเมน สิ่งที่ทำไปแล้ว และข้อความ Error ที่พบ เพื่อให้ทีมงานตรวจสอบได้รวดเร็วขึ้น

อ่านเพิ่มเติมเกี่ยวกับ TTL

แชร์FacebookXLINELinkedIn

มีคำถามเรื่องบริการ? ติดต่อทีมงาน