DNS หาที่อยู่ได้อย่างไร? การสอบถามแบบเรียกซ้ำ เซิร์ฟเวอร์ที่มีอำนาจ TTL และแคช

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

บทความนี้ใช้โฮสต์ห้องสมุดสมมติ www.library.example เพื่อสำรวจความสัมพันธ์ระหว่างการแปลงชื่อกับแคช ชื่อตัวอย่างและตารางเวลาสร้างขึ้นเพื่ออธิบาย ไม่ได้วัดคำตอบจากบริการจริง เป้าหมายคือแยกกระบวนการที่ DNS บอกที่อยู่ เหตุที่มองเห็นการเปลี่ยนแปลงล่าช้า และความล้มเหลวหลังแปลงชื่อสำเร็จ

1. DNS มีคำตอบหลายชนิดสำหรับแต่ละชื่อ

DNS ให้ข้อมูลที่เชื่อมโยงกับชื่อโดเมนเป็นระเบียนแต่ละชนิด A หมายถึงที่อยู่ IPv4 และ AAAA หมายถึงที่อยู่ IPv6 โดยชื่อหนึ่งอาจมีหลายที่อยู่ CNAME เป็นชื่อแฝงที่ชี้ไปยังชื่ออื่น MX ระบุเซิร์ฟเวอร์รับอีเมล และ NS ระบุเนมเซิร์ฟเวอร์ที่มีอำนาจสำหรับโซนนั้น ดังนั้นแม้สอบถามชื่อเดียวกัน คำตอบก็เปลี่ยนไปได้เมื่อขอระเบียนต่างชนิด

ตามคำอธิบายระเบียน DNS ของ Cloudflare ค่าของ CNAME ไม่ใช่ที่อยู่ IP แต่เป็นอีกชื่อหนึ่ง หากต้องการที่อยู่ อาจต้องแปลงชื่อนั้นต่อไป นอกจากนี้ ชื่อโฮสต์ที่ DNS จัดการใน https://www.library.example/books คือ www.library.example ไม่ใช่การลงทะเบียนพาธ /books หรือเนื้อหาหน้าเว็บใน DNS การตั้ง CNAME ไม่ได้สร้าง HTTP redirect ที่เปลี่ยนที่อยู่ในแถบที่อยู่ของเบราว์เซอร์โดยอัตโนมัติ

2. ตัวแก้ชื่อแบบเรียกซ้ำค้นหาเซิร์ฟเวอร์ที่มีอำนาจอย่างไร

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

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

3. TTL คือเวลาที่เหลือในแคช ไม่ใช่นาฬิกาของทั้งโลก

TTL ของระเบียนเป็นข้อมูลอายุแคชที่ส่งมาในหน่วยวินาที สำหรับคำตอบจากแคชตามปกติ เวลาที่เหลือจะลดลงระหว่างที่เก็บข้อมูล เช่น หากตัวแก้ชื่อเก็บที่อยู่พร้อม TTL 300 วินาทีเมื่อเวลา 10:00 เมื่อตอบจากข้อมูลชุดเดิมเวลา 10:02 TTL ที่เหลือจะประมาณ 180 วินาที ตารางต่อไปสมมติตัวแก้ชื่อเพียงตัวเดียวที่ไม่สอบถามซ้ำ ไม่รีเฟรชล่วงหน้า และไม่ให้คำตอบที่หมดอายุแล้ว

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

4. เวลาที่ควรลด TTL และแคชของคำตอบว่า “ไม่มี”

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

NXDOMAIN ซึ่งบอกว่าไม่มีชื่อนั้น และ NODATA ซึ่งบอกว่าชื่อมีอยู่แต่ไม่มีระเบียนชนิดที่ขอ ก็เก็บในแคชได้ มาตรฐานแคชคำตอบเชิงลบ RFC 2308 กำหนดให้ใช้ค่าที่น้อยกว่าระหว่าง TTL ของระเบียน SOA จากเซิร์ฟเวอร์ที่มีอำนาจ กับค่า MINIMUM ใน SOA เป็นอายุแคชของคำตอบเชิงลบ ดังนั้นแม้เพิ่งเพิ่มโฮสต์ที่เดิมไม่มี คำตอบเก่าว่า “ไม่มี” ก็อาจยังเหลืออยู่ การดูเพียง TTL ของระเบียน A ใหม่แล้วคิดว่าคำตอบนั้นมีอายุเท่ากัน จะทำให้พลาดสาเหตุ

5. ตรวจโดยใช้ชื่อ ชนิด และเซิร์ฟเวอร์เดิม

บันทึกการตรวจควรระบุชื่อที่สอบถามอย่างครบถ้วน ชนิดเช่น A หรือ AAAA เซิร์ฟเวอร์ DNS ที่ถาม และเวลาไว้ด้วย ในสภาพแวดล้อมที่ติดตั้ง dig สามารถระบุชื่อและชนิด เช่น dig example.com A เมื่อตรวจปัญหาจริง ให้แทน example.com ด้วยโฮสต์ที่ต้องการตรวจ คำสั่งนี้เป็นตัวอย่างขั้นตอน ไม่ใช่บันทึกว่าได้รันจริงหรือวัดเวลาตอบในบทความนี้

ดูสถานะของคำตอบ พร้อมชื่อ ชนิด ค่า และ TTL ใน ANSWER เมื่อส่งคำถามเดิมไปยังตัวแก้ชื่อเดิมอีกครั้ง ให้ดูว่า TTL ลดลงหรือไม่ แต่ไม่ควรตัดสินทันทีว่าเป็นข้อผิดพลาดหากค่าเพิ่มขึ้น อาจมีการรีเฟรชล่วงหน้า หรือโหนดแคชอีกโหนดหนึ่งเป็นผู้ตอบ การบันทึกผล A และ AAAA แยกกันช่วยให้ระบุได้ง่ายขึ้นว่าที่อยู่ตระกูลใดแตกต่าง

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

6. แยกข้อผิดพลาด DNS ข้อผิดพลาดการเชื่อมต่อ และข้อยกเว้น

NXDOMAIN คือคำตอบว่าไม่มีชื่อ ส่วน NODATA คือกรณีที่ไม่มีระเบียนชนิดที่ขอ ตรงกันข้าม SERVFAIL เป็นความล้มเหลวที่เซิร์ฟเวอร์ประมวลผลคำถามไม่ได้ และการหมดเวลารอเป็นการสังเกตว่าไม่ได้รับคำตอบภายในเวลาที่กำหนด ไม่ควรตีความทั้งหมดว่า “โดเมนถูกลบ” ก่อนอื่นควรเก็บว่ามีรหัสตอบกลับหรือไม่ และถามเซิร์ฟเวอร์ใด เพื่อกำหนดสิ่งที่จะตรวจต่อไป

การยังเห็นคำตอบเดิมหลัง TTL ผ่านไป ไม่ใช่การฝ่าฝืนกฎเสมอไป วิธี serve-stale ใน RFC 8767 กำหนดแนวทางใช้ข้อมูลหมดอายุเพื่อเพิ่มความพร้อมใช้งานในกรณียกเว้นที่รีเฟรชจากเซิร์ฟเวอร์ที่มีอำนาจไม่ได้ ไม่ได้หมายความว่าตัวแก้ชื่อทุกตัวใช้การตั้งค่าเดียวกัน ดังนั้นแทนที่จะฟันธงเวลาเห็นการเปลี่ยนแปลงจาก TTL ค่าเดียว ควรตรวจพฤติกรรมของตัวแก้ชื่อที่ใช้จริง

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