เวลาย้ายเว็บไปเครื่องใหม่ เราอาจเตรียมบริการไว้ครบแล้ว เปลี่ยน IP ในหน้า DNS และเปิดจากเครื่องตัวเองได้ แต่คนที่อยู่อีกเครือข่ายยังเห็นเว็บเก่าอยู่ อาการนี้ทำให้ไม่แน่ใจว่าค่าที่แก้ยังไม่ถูกนำไปใช้หรือมีระบบใดค้างอยู่ระหว่างทาง
คำตอบจาก DNS ไม่ได้ถูกส่งตรงจากหน้าจัดการโดเมนถึงทุกเครื่องพร้อมกัน ระหว่างนั้นมีทั้ง server ที่รับผิดชอบข้อมูลของ zone และ resolver ที่เก็บคำตอบไว้ให้ผู้ใช้กลุ่มหนึ่ง รวมถึงทางค้นชื่อที่อุปกรณ์เลือกใช้
ก่อนสรุปว่าต้องรออีกกี่ชั่วโมง จึงควรดูว่าคำตอบที่ต่างกันมาจากจุดใดครับ เพราะการรอ cache หมดกับการแก้ข้อมูลผิด zone ต้องทำคนละอย่าง
Authoritative name server เป็นจุดที่รับผิดชอบข้อมูลของ zone นั้น ส่วน recursive resolver ทำหน้าที่หาคำตอบให้ client และอาจตอบจากข้อมูลที่เก็บไว้ การถามผ่าน resolver จึงไม่ได้แปลว่ามันไปอ่าน authoritative ใหม่ทุกครั้ง
ผู้ให้บริการจดโดเมนกับผู้ให้บริการ DNS อาจเป็นคนละรายด้วย การแก้ A record ในแผงหนึ่งจะไม่มีผลกับผู้ใช้ตามที่หวัง หาก delegation ของโดเมนยังชี้ไปยัง name server อีกชุด การเห็นค่าถูกในหน้าจัดการจึงเป็นเพียงหลักฐานว่าแก้ในบัญชีนั้นแล้ว
หาก zone มี authoritative หลายตัว ต้องตรวจว่าข้อมูลที่เกี่ยวข้องตรงกัน ไม่เลือกถามเพียงตัวที่ตอบถูกแล้วถือว่าทุกคำตอบถูกหมด เพราะ resolver ของผู้ใช้ไม่ได้มีหน้าที่เลือกตัวเดียวกับที่เราใช้ตรวจเสมอ
TTL ของ record ใช้ควบคุมระยะที่ข้อมูลถูกนำไปใช้จาก cache ตามกติกา DNS โดยคิดเป็นวินาที Resolver ที่รับคำตอบคนละเวลาก็มีอายุคงเหลือต่างกัน การเปลี่ยนค่าใหม่จึงไม่ได้ส่งสัญญาณไปลบสำเนาเดิมทุกแห่งทันที
สมมติ resolver หนึ่งรับคำตอบเก่าที่มี TTL หนึ่งชั่วโมงไว้ก่อนเปลี่ยน IP แล้วเราเพิ่งลด TTL เหลือห้านาทีพร้อมการย้าย ค่าห้านาทีใหม่นั้นไม่ได้ย้อนกลับไปลดอายุของคำตอบเก่าที่ resolver รับไปแล้ว ตัวเลขนี้เป็นตัวอย่างอธิบายลำดับเวลา ไม่ใช่ผลตรวจโดเมนใด
ถ้าต้องการลดช่วงที่สองปลายทางอยู่พร้อมกัน จึงควรวางการลด TTL ล่วงหน้าให้พ้นอายุคำตอบเดิมก่อนจุดย้ายตามแผน และยังต้องเตรียมบริการเก่าไว้ตามความเสี่ยงของงาน ไม่ใช้ TTL ใหม่เป็นเหตุให้ปิดเครื่องเก่าทันที
ในทางปฏิบัติ resolver ยังมีนโยบายประกอบ เช่น serve-stale ที่อาจใช้ข้อมูลหมดอายุเมื่อรีเฟรชจาก authoritative ไม่ได้ตามเงื่อนไข การอ่าน TTL จึงช่วยวางแผนและหาหลักฐาน แต่ไม่ใช่คำสัญญาว่าครบเวลานั้นแล้วทุก client ต้องเปลี่ยนเหมือนกันหมด
ปัญหาอีกแบบเกิดตอนเพิ่งเพิ่มชื่อใหม่ หลังจากมีคนหรือระบบถามชื่อนั้นไปแล้วและได้คำตอบว่าไม่มี DNS มี negative caching สำหรับคำตอบลักษณะนี้ ไม่ได้เก็บเฉพาะ IP ที่หาเจอ
NXDOMAIN กับการมีชื่อแต่ไม่มี record ชนิดที่ถามมีความหมายต่างกัน จึงควรอ่านรหัสตอบและชนิดข้อมูลประกอบ ไม่เห็นช่อง answer ว่างแล้วสรุปว่าโดเมนทั้งหมดไม่มีอยู่ กรณีหนึ่งอาจไม่มี AAAA แต่ยังมี A สำหรับชื่อเดียวกัน
อายุ negative cache เกี่ยวข้องกับข้อมูล SOA ตามกติกาที่ใช้ ไม่ได้ถูกกำหนดจาก TTL ของ A record ที่เพิ่งสร้างเพียงอย่างเดียว ดังนั้นการลด TTL ของ record ใหม่อย่างเดียวอาจไม่แก้ช่วงที่ resolver ยังจำคำตอบว่าไม่พบอยู่
ก่อนเทียบผลควรจดชื่อเต็มที่ถาม ชนิด A หรือ AAAA และ resolver ที่ใช้ พร้อมเวลาตรวจ ถ้ามี CNAME ก็ต้องตามว่าชื่อปลายทางคืนข้อมูลอะไรด้วย ไม่เทียบ IP จากชื่อหนึ่งกับชื่ออีกชุดที่คล้ายกันแล้วคิดว่า DNS ส่งค่าผิด
เริ่มจาก delegation และ authoritative ที่รับผิดชอบจริง แล้วค่อยเทียบ resolver ของเครือข่ายที่มีปัญหากับจุดตรวจอื่น การถาม authoritative โดยตรงช่วยแยกว่าข้อมูลต้นทางพร้อมหรือยัง แต่ไม่ได้จำลอง cache ที่ผู้ใช้กำลังเจอ
เครื่องมืออย่าง dig ช่วยระบุ server ที่ถามและดูรายละเอียดคำตอบได้ แต่ต้องอ่าน output ทั้งชุดตามคำถาม การเห็น IP ใหม่จาก resolver สาธารณะรายหนึ่งเป็นหลักฐานเฉพาะทางนั้น ยังใช้รับรอง resolver ขององค์กรหรืออุปกรณ์ที่ใช้ DNS อีกนโยบายไม่ได้
หาก browser เปิดใช้ DNS ผ่านบริการเฉพาะของตัวเอง การตรวจจากระบบปฏิบัติการก็อาจไปคนละ resolver ควรดูเส้นทางที่ client ใช้จริง ไม่รีบล้าง cache ทั้งเครื่องโดยยังไม่รู้ว่าชั้นที่ตอบเก่าอยู่ที่ใด
DNS จบที่การหาที่อยู่ตามชื่อ ไม่ได้ควบคุมอายุของ HTTP cache หรือบังคับให้ connection เดิมที่เปิดอยู่ย้ายทันที หากที่อยู่ใหม่ถูกต้องแต่ยังเห็นหน้าเดิม ควรตามต่อถึง CDN reverse proxy และฉบับแอปที่ตอบด้วย
ในงานที่มีทั้งชื่อ www และชื่อหลัก ต้องตรวจตามเส้นทาง redirect ด้วย หน้าหนึ่งอาจเปิดที่ IP ใหม่แล้วส่งต่อไปอีกชื่อที่ยังตั้งต่างกัน การดูเพียงคำตอบแรกจึงอาจพลาดสาเหตุที่ผู้ใช้กลับไปบริการเก่า
การคงปลายทางเก่าในช่วงย้ายยังต้องคิดเรื่องข้อมูลเขียน หากสองปลายทางรับการแก้ข้อมูลโดยไม่มีกติกากลาง อาจเกิดข้อมูลคนละฉบับแม้หน้าเว็บทั้งสองเปิดได้ แผน DNS จึงต้องทำร่วมกับวิธีส่งต่อคำขอและแหล่งข้อมูลที่ใช้งานจริง
ชุดตรวจควรแสดงว่าทุก authoritative ที่เกี่ยวข้องตอบตามแผนแล้ว resolver ตัวอย่างเปลี่ยนอย่างไร และปลายทางทั้งสองดูแลคำขอระหว่างย้ายได้หรือไม่ ควรระบุเครือข่ายกับเวลาของแต่ละผลไว้ เพื่อไม่เอาผลเมื่อวานมาตอบปัญหาวันนี้
ถ้าจะทดลอง TTL หรือ negative cache ให้ใช้ชื่อทดสอบที่แยกจากบริการหลัก พร้อมเก็บค่าก่อนเปลี่ยน ไม่ควรสร้างชื่อผิดบนระบบจริงเพื่อดูว่าคนอื่นจะรอนานเท่าไร การทดสอบต้องช่วยอธิบายชั้นที่ค้างโดยไม่สร้างปัญหาเพิ่มให้ผู้ใช้
การเปลี่ยน DNS เป็นการปรับข้อมูลที่มีสำเนาอยู่หลายจุด ไม่ใช่การสั่งทุกเครื่องเปลี่ยนปลายทางพร้อมกัน เมื่อแยก authoritative resolver TTL และ negative cache ได้ เราจะรู้ว่าควรแก้ข้อมูล รออายุคำตอบ หรือตามปัญหาต่อที่ HTTP และบริการ แผนย้ายจึงอาศัยหลักฐานจากเส้นทางจริงแทนการนับเวลาจากปุ่มบันทึกเพียงจุดเดียว