TTL คืออะไร ตั้งค่าอย่างไรให้ DNS Propagation เร็วขึ้น

TTL หรือ Time To Live คือค่าตัวเลข (หน่วยวินาที) ที่บอกว่า DNS Resolver ทั่วโลกควรเก็บ Cache ของ DNS Record นั้นไว้นานเท่าไหร่ก่อนจะถามข้อมูลใหม่จาก Authoritative DNS Server ค่านี้ส่งผลโดยตรงต่อความเร็วของ DNS Propagation และเป็นหนึ่งในสิ่งแรกที่ควรปรับก่อนโอน Hosting หรือเปลี่ยน IP Address

TTL ทำงานอย่างไร (DNS Caching ที่ Resolver)

เมื่อผู้ใช้พิมพ์ example.com ในเบราว์เซอร์ DNS Resolver ของ ISP หรือเซิร์ฟเวอร์ใกล้เคียงจะค้นหาข้อมูล IP Address ถ้ามี Cache อยู่แล้วและยัง TTL ไม่หมดอายุ จะตอบกลับจาก Cache ทันที ถ้า TTL หมดอายุจึงจะไปถาม Authoritative DNS ใหม่

ตัวอย่าง: ถ้า TTL = 3600 (1 ชั่วโมง) และ DNS Resolver เพิ่งดึงข้อมูลมา Resolver นั้นจะรอ 1 ชั่วโมงก่อนถามอีก แม้คุณเปลี่ยน IP แล้ว ผู้ใช้ที่ Cache อยู่ก็ยังเห็น IP เก่านาน 1 ชั่วโมง

หัวใจสำคัญที่ต้องเข้าใจคือ TTL ไม่ได้นับถอยหลังจาก Authoritative DNS Server ของคุณ แต่นับถอยหลังแยกกันที่ DNS Resolver แต่ละตัวทั่วโลก ในชีวิตจริง DNS Query ที่ส่งจากเครื่องผู้ใช้จะผ่านลำดับชั้นของ Cache หลายระดับ ได้แก่ Cache ในเบราว์เซอร์เอง, Cache ในระบบปฏิบัติการ (OS Resolver / stub resolver), และที่สำคัญที่สุดคือ Recursive Resolver ของ ISP หรือผู้ให้บริการ Public DNS อย่าง 1.1.1.1 หรือ 8.8.8.8 ซึ่งให้บริการผู้ใช้หลายล้านคนพร้อมกัน

เมื่อ Recursive Resolver ของ ISP ดึง Record ของคุณไป Cache มันจะเริ่มนับถอยหลัง TTL ของตัวเอง สมมติผู้ใช้ A เข้าเว็บตอน 10:00 น. ทำให้ Resolver Cache ค่าไว้ด้วย TTL 3600 วินาที ต่อมาผู้ใช้ B (ใช้ ISP เดียวกัน) เข้าเว็บตอน 10:30 น. จะได้คำตอบจาก Cache ทันทีโดยไม่ถาม Authoritative DNS เลย และ Cache นั้นจะอยู่จนถึง 11:00 น. จึงหมดอายุ นี่คือเหตุผลที่การเปลี่ยน DNS ไม่ได้มีผลทันทีกับทุกคน เพราะแต่ละ Resolver เริ่มนับ TTL คนละเวลากัน ทำให้ช่วงเวลาที่ผู้ใช้ทั่วโลกเห็น IP ใหม่ "ทยอยอัปเดต" กระจายตัวออกไปไม่พร้อมกัน

นอกจากนี้ Recursive Resolver บางตัวอาจตั้งค่า cap สูงสุด (maximum cache TTL) ของตัวเอง เช่นจำกัดไม่ให้ Cache เกิน 24 ชั่วโมงแม้คุณตั้ง TTL ไว้สูงกว่านั้น และบางตัวก็มี minimum TTL ที่บังคับ Cache อย่างน้อยไม่กี่วินาทีเพื่อลดภาระ Query นี่คือเหตุผลที่ TTL ที่คุณตั้งเป็นเพียง "คำแนะนำ" ให้ Resolver ไม่ใช่คำสั่งบังคับเด็ดขาด

ค่า TTL มาตรฐานสำหรับแต่ละ Record Type

ค่า TTL ที่เหมาะกับแต่ละ Record

การเลือกค่า TTL ไม่มีสูตรตายตัวที่ใช้ได้กับทุก Record เพราะแต่ละ Record มีลักษณะการเปลี่ยนแปลงและความเสี่ยงต่างกัน หลักคิดง่ายๆ คือ: Record ที่ "เปลี่ยนบ่อยหรือมีโอกาสต้องเปลี่ยนฉุกเฉิน" ควรตั้ง TTL ต่ำ ส่วน Record ที่ "นิ่งมากและแทบไม่เปลี่ยน" ตั้ง TTL สูงได้เพื่อลดภาระและเพิ่มความเสถียร ตารางด้านล่างสรุปค่าที่แนะนำพร้อมเหตุผลเชิงปฏิบัติ

ข้อสังเกตเชิงปฏิบัติ: หลายคนเข้าใจผิดว่าควรตั้ง TTL ต่ำไว้ตลอดเพื่อ "เผื่อเปลี่ยน" แต่นั่นทำให้ Resolver ต้องถาม Authoritative DNS บ่อยเกินจำเป็น เพิ่ม Latency ในการโหลดหน้าเว็บครั้งแรกของผู้ใช้ และเพิ่มความเสี่ยงเว็บล่มถ้า DNS Server มีปัญหาชั่วคราว วิธีที่ถูกต้องคือ "ตั้งสูงเป็น Default แล้วลดเฉพาะตอนวางแผนเปลี่ยน" ไม่ใช่ตั้งต่ำค้างไว้

TTL กับ DNSSEC: ความสัมพันธ์ที่ควรรู้

DNSSEC (Domain Name System Security Extensions) เป็นชั้นความปลอดภัยที่เพิ่มลายเซ็นดิจิทัลให้กับ DNS Record เพื่อป้องกันการโจมตีแบบ DNS Spoofing หรือ Cache Poisoning เมื่อเปิดใช้งาน DNSSEC ค่า TTL จะมีความสำคัญมากขึ้นกว่าปกติ เพราะลายเซ็นดิจิทัล (RRSIG) แต่ละชุดมีอายุการใช้งาน (Signature Validity Period) ที่ต้องสัมพันธ์กับ TTL ของ Record

หลักการสำคัญที่ควรทราบคือ TTL ของ DNSSEC Record ไม่ควรสูงกว่าครึ่งหนึ่งของ Signature Validity Period มิฉะนั้น Resolver อาจถือ Cache ที่มี RRSIG หมดอายุค้างไว้ ทำให้ผู้ใช้เห็นข้อผิดพลาด SERVFAIL หรือ BOGUS โดยไม่มีสาเหตุที่ชัดเจน สำหรับผู้ให้บริการ DNS ส่วนใหญ่ Signature Validity Period ถูกตั้งไว้ที่ 14–30 วัน ดังนั้น TTL ของ Record หลักควรไม่เกิน 7–15 วัน (604800 วินาที)

นอกจากนี้เมื่อจะต่ออายุหรือเปลี่ยน DNSKEY (คีย์ DNSSEC หลัก) ต้องลด TTL ของ DNSKEY Record ล่วงหน้าด้วย เช่นเดียวกับที่ลด TTL ก่อนย้าย Hosting ทั่วไป เพื่อให้การเปลี่ยนคีย์ทำได้รวดเร็วโดยไม่มีช่วง Validation Error ยาวนาน AsiaGB รองรับ DNSSEC บน Domain ทุกโดเมนที่จดผ่านระบบ ช่วยเพิ่มความน่าเชื่อถือให้กับโดเมนของคุณโดยไม่ต้องตั้งค่าเองจากศูนย์

TTL กับ CDN และ Reverse Proxy

เมื่อใช้ CDN (Content Delivery Network) เช่น Cloudflare, AWS CloudFront หรือ Fastly ทิศทางการจัดการ Cache จะซับซ้อนขึ้น เพราะนอกจาก DNS Cache ที่ Resolver แล้ว CDN ยังมี Cache ของตัวเองในระดับ Edge Node ที่กระจายอยู่ทั่วโลกอีกชั้นหนึ่ง

จุดที่มักสับสนคือ TTL ใน DNS Record และ TTL ของ CDN Cache เป็นคนละอย่างกันโดยสิ้นเชิง DNS TTL บอก Resolver ว่าต้อง Query IP ของ CDN Edge ใหม่เมื่อไหร่ ในขณะที่ CDN Cache TTL (ที่ตั้งผ่าน Cache-Control header หรือ CDN Dashboard) บอก Edge Node ว่าต้อง Pull เนื้อหาจาก Origin Server ใหม่เมื่อไหร่ สองค่านี้ทำงานคู่ขนานกันและต้องวางแผนแยกกัน

สถานการณ์ที่ต้องระวังคือเมื่อโอนย้ายจาก CDN หนึ่งไปอีก CDN หนึ่ง หรือปิดใช้งาน CDN แล้วชี้ตรงไป Origin Server ขั้นตอนที่ถูกต้องคือ ลด DNS TTL ล่วงหน้า 24–48 ชั่วโมงก่อน รอให้ Cache เก่าหมดอายุ แล้วจึงเปลี่ยน CNAME หรือ A Record ไปยังปลายทางใหม่ ถ้าข้ามขั้นตอนนี้ ผู้ใช้บางส่วนอาจยังเข้าถึง Edge Node เก่าต่อไปอีกหลายชั่วโมงซึ่งอาจให้เนื้อหาที่ไม่ถูกต้องหรือ Error 5xx

# ตรวจสอบ TTL ที่ Resolver เห็น vs TTL ที่ CDN บอก
# คำสั่ง dig พร้อม trace เพื่อดู CNAME chain:
dig +trace example.com A

# ดู Response Header ของ CDN (Cache-Control และ Age):
curl -I https://example.com | grep -i 'cache\|age\|x-cache'

CDN บางตัวอย่าง Cloudflare มีฟีเจอร์ "Override DNS TTL" ที่บังคับให้ Browser Cache นาน 4 ชั่วโมง โดยไม่คำนึงถึงค่า DNS TTL ที่ตั้งไว้ ถ้าใช้ฟีเจอร์นี้อยู่ ต้องปิดก่อนเมื่อวางแผนเปลี่ยน IP หรือย้ายโฮสต์

DNS TTL กับ Email Deliverability

ค่า TTL ของ Record ที่เกี่ยวกับอีเมล ได้แก่ MX, SPF (TXT), DKIM (TXT), และ DMARC (TXT) ส่งผลโดยตรงต่อ Email Deliverability หรือความสามารถในการส่งอีเมลให้ถึงกล่องจดหมายปลายทางได้สำเร็จ เมื่อ Mail Server ของผู้รับต้องการตรวจสอบว่าอีเมลมาจากแหล่งที่น่าเชื่อถือจริงหรือไม่ มันจะ Query DNS เพื่อดู SPF, DKIM และ DMARC ของโดเมนผู้ส่ง

ถ้า TTL ของ Record เหล่านี้ต่ำเกินไปและเพิ่งถูก Update ไม่นาน Mail Server ที่ Cache ค่าเก่าไว้อาจตรวจสอบด้วยข้อมูลเก่าที่ยังไม่อัปเดต ส่งผลให้อีเมลถูกปฏิเสธหรือตกไปยังโฟลเดอร์ Spam ชั่วคราว สถานการณ์นี้พบบ่อยเมื่อเปลี่ยนผู้ให้บริการอีเมล (เช่น จาก Hosting Mail ไปยัง Google Workspace) โดยไม่ได้วางแผน TTL ไว้ล่วงหน้า

แนวปฏิบัติที่ดีที่สุดเมื่อเปลี่ยนผู้ให้บริการอีเมลคือ ลด TTL ของ MX, SPF, และ DKIM ล่วงหน้า 48 ชั่วโมง จากนั้นตั้งค่าระบบใหม่ให้เสร็จสมบูรณ์รวมถึง DKIM Key ของผู้ให้บริการใหม่ เปลี่ยน MX Record ไปชี้ที่ใหม่ รอให้ Propagate แล้วทดสอบการรับส่งอีเมลก่อนลบ Record เก่าออก ขั้นตอนนี้ช่วยลดความเสี่ยงอีเมลตกหล่นระหว่างการเปลี่ยนผ่านได้อย่างมาก

ลด TTL ก่อนย้าย Server / DNS อย่างไร

การลด TTL ล่วงหน้าก่อนโอน Hosting คือ Best Practice สำคัญ เพราะช่วยให้เมื่อเปลี่ยน IP แล้ว ทุกคนเห็น IP ใหม่ได้เร็วที่สุด

1. ลด TTL ล่วงหน้า 24–48 ชั่วโมง: เข้า DNS Management แล้วลด TTL ของ A Record ลงเหลือ 300 (5 นาที)
2. รอให้ TTL เก่าหมดอายุ: ถ้า TTL เดิมเป็น 3600 ต้องรอ 1 ชั่วโมงก่อน Cache ทั่วโลกจะเอา TTL ใหม่ไปใช้
3. โอน Hosting และเปลี่ยน IP: ดำเนินการโอน Hosting ตามปกติ
4. ตรวจสอบ Propagation: ใช้ dnschecker.org ดูว่า DNS ทั่วโลกเห็น IP ใหม่แล้วหรือยัง
5. เพิ่ม TTL กลับ: หลังโอนเสร็จเรียบร้อย เพิ่ม TTL กลับเป็น 3600 หรือ 86400

วิธีดู TTL ปัจจุบันของโดเมน

ตรวจสอบด้วย Command Line

ในผลลัพธ์ของ dig จะเห็นตัวเลขระหว่าง Domain และ Record Type เช่น example.com. 3600 IN A 1.2.3.4 ตัวเลข 3600 คือ TTL ที่เหลืออยู่ใน Cache

ตรวจสอบผ่านเว็บไซต์

• dnschecker.org — ดู TTL จาก DNS Server หลายประเทศพร้อมกัน
• mxtoolbox.com/DNSLookup.aspx — ดู Records ทั้งหมดรวม TTL
• whatsmydns.net — ตรวจ Propagation ทั่วโลก

ปัญหาที่พบบ่อยเกี่ยวกับ TTL

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

เปลี่ยน Record แล้วยังเห็นค่าเก่า

นี่คือปัญหาอันดับหนึ่ง หลังแก้ A Record หรือเปลี่ยน IP แล้วเข้าเว็บยังเด้งไปที่เดิม สาเหตุเกือบทั้งหมดคือ Cache ยังไม่หมดอายุ — ทั้งที่ Resolver ของ ISP และที่เครื่องของคุณเอง ลองตรวจด้วย dig example.com A แล้วดูตัวเลข TTL ที่เหลือ ถ้าตัวเลขนั้นค่อยๆ ลดลงทุกครั้งที่ query แสดงว่ากำลังนับถอยหลังอยู่ ต้องรอจนถึง 0 จึงจะดึงค่าใหม่ วิธีบรรเทาฝั่งเครื่องตัวเองคือ flush DNS cache: macOS ใช้ sudo dscacheutil -flushcache, Windows ใช้ ipconfig /flushdns แต่จำไว้ว่าการ flush ที่เครื่องตัวเองไม่ได้ล้าง Cache ของ ISP Resolver ที่ผู้ใช้คนอื่นใช้อยู่

Negative Caching (NXDOMAIN ถูก Cache)

หลายคนไม่รู้ว่า "การไม่มี Record" ก็ถูก Cache เช่นกัน เรียกว่า Negative Caching เมื่อ Resolver ถามหา Record ที่ยังไม่มีอยู่ (เช่นคุณยังไม่ได้สร้าง subdomain) มันจะได้คำตอบ NXDOMAIN กลับมาและ Cache คำตอบ "ไม่มี" นี้ไว้ตามค่าใน SOA Record (ฟิลด์ minimum / negative TTL) ผลคือถ้าคุณเข้าเว็บ subdomain ก่อนจะสร้าง Record เสร็จ แล้วค่อยมาสร้าง Record ทีหลัง คุณอาจยังเจอ error ว่าไม่พบโดเมนต่อไปอีกระยะหนึ่งจนกว่า Negative Cache จะหมดอายุ ทางแก้คือ "อย่าเพิ่งเข้าเว็บ/ทดสอบก่อนสร้าง Record ให้ครบ" และตั้งค่า negative TTL ใน SOA ให้ไม่สูงเกินไป (ทั่วไป 300–3600 วินาที)

ลด TTL แล้วแต่ยังเปลี่ยนช้า

เคสที่พบบ่อยคือลด TTL เป็น 300 แล้วเปลี่ยน IP "ทันที" โดยไม่รอ ปัญหาคือ Resolver ทั่วโลกยังถือ Cache เก่าที่มี TTL 3600 อยู่ การลด TTL จะมีผลก็ต่อเมื่อ Cache รอบเก่า (ที่ยังเป็น 3600) หมดอายุไปก่อน แล้ว Resolver ดึงค่า TTL ใหม่ (300) มาใช้ ดังนั้นต้องลด TTL ล่วงหน้าอย่างน้อยเท่ากับค่า TTL เดิม (เช่น 1 ชั่วโมง) ก่อนจะเริ่มเปลี่ยน IP จริง มิฉะนั้นการลด TTL จะไม่ช่วยอะไรในรอบแรก

ตั้ง TTL ไม่ตรงกันระหว่าง Record คู่

เมื่อย้ายบริการที่มีหลาย Record เกี่ยวข้อง (เช่น A Record ของเว็บ + MX ของ Email + TXT สำหรับ SPF) ควรตรวจให้ทุก Record ที่เกี่ยวกับการย้ายถูกลด TTL พร้อมกัน ถ้าลดแค่ A Record แต่ลืม MX อาจเกิดสถานการณ์ที่เว็บชี้ Server ใหม่แล้วแต่ Email ยังวิ่งไป Server เก่าอยู่หลายชั่วโมง ทำให้อีเมลตกหล่นช่วงเปลี่ยนผ่าน

ค่า TTL ที่ไม่ควรตั้ง

• TTL = 0: บาง DNS Software ถือว่า "ไม่ Cache" แต่บางตัวตีความต่างกัน อาจทำให้ Resolver บางตัวไม่ยอมรับ
• TTL ต่ำตลอดเวลา (เช่น 60–300): DNS Server ต้องถาม Authoritative DNS บ่อยมาก เพิ่ม Load และ Latency
• TTL สูงมาก (เกิน 86400): ถ้าต้องการเปลี่ยน IP ฉุกเฉิน จะรอนาน

คำถามที่พบบ่อยเกี่ยวกับ TTL

TTL ของ DNS ตั้งเท่าไหร่ดี?

สำหรับการใช้งานทั่วไปที่ Record ไม่เปลี่ยนบ่อย แนะนำ 3600 วินาที (1 ชั่วโมง) เป็นค่าเริ่มต้น ส่วน Record ที่นิ่งมากอย่าง NS ตั้ง 86400 (24 ชั่วโมง) ได้ และให้ลดลงเหลือ 300 วินาที (5 นาที) เฉพาะช่วง 24–48 ชั่วโมงก่อนวางแผนเปลี่ยน IP หรือย้าย Server เท่านั้น ไม่ควรตั้งต่ำค้างไว้ตลอดเพราะจะเพิ่มภาระและ Latency โดยไม่จำเป็น

เปลี่ยน DNS แล้วนานแค่ไหนถึงจะมีผลทั่วโลก?

ขึ้นอยู่กับค่า TTL เดิมก่อนเปลี่ยนเป็นหลัก ถ้า TTL เดิมเป็น 3600 ในทางทฤษฎีอาจต้องรอถึง 1 ชั่วโมงให้ Cache ทุกที่หมดอายุ แต่ในทางปฏิบัติ Resolver ส่วนใหญ่ทยอยอัปเดตภายในเวลาดังกล่าว บางครั้งอาจนานกว่าเล็กน้อยเพราะ Resolver บางตัวไม่เคารพ TTL อย่างเคร่งครัด หรือมีการ Cache เพิ่มเติมในเครื่องผู้ใช้

ลด TTL ก่อนย้าย Server ต้องลดล่วงหน้านานเท่าไหร่?

ควรลด TTL ล่วงหน้าอย่างน้อยเท่ากับค่า TTL เดิมที่ตั้งไว้ ถ้าเดิมเป็น 3600 ให้ลดเป็น 300 ล่วงหน้าอย่างน้อย 1 ชั่วโมง (แนะนำเผื่อ 24–48 ชั่วโมงเพื่อความปลอดภัย) เพื่อให้ Resolver ทั่วโลกดึงค่า TTL ใหม่ที่ต่ำลงไปใช้ก่อน แล้วจึงค่อยเปลี่ยน IP จริง

TTL = 0 หมายความว่าอะไร ตั้งได้ไหม?

TTL = 0 ตามทฤษฎีหมายถึง "ห้าม Cache เลย" ทุก Query ต้องถาม Authoritative DNS ใหม่เสมอ แต่ไม่แนะนำให้ใช้ในงานจริง เพราะ Resolver แต่ละตัวตีความต่างกัน บางตัวอาจปฏิเสธ Record หรือบังคับ minimum TTL ของตัวเองแทน และทำให้ DNS Server รับภาระหนักมาก ควรใช้ค่าต่ำสุดที่ปลอดภัยอย่าง 60–300 วินาทีในกรณีจำเป็นจริงๆ แทน