ข้อผิดพลาดในการค้นหา DNS ของ Debian 12: ซ่อมแซม systemd-resolved

หาก Debian 12 แสดงข้อความ “Temporary failure in name resolution” ให้ตรวจสอบบริการ resolver, /etc/resolv.confลิงก์ และเซิร์ฟเวอร์ DNS ที่แสดงตามresolvectlลำดับ การรีสตาร์ทบริการจะช่วยได้เฉพาะเมื่อบริการหยุดทำงานเท่านั้น ลิงก์เสียหรือเซิร์ฟเวอร์ต้นทางที่ไม่สามารถเข้าถึงได้ต้องใช้วิธีแก้ไขอื่น

คำแนะนำเหล่านี้ใช้ได้กับระบบ Debian 12 (Bookworm) ที่กำหนดค่าให้ใช้ ตัวแก้ไข DNS systemd-resolvedDebian ได้แยกตัวแก้ไข DNS นั้นออกเป็นแพ็กเกจแยกต่างหากและไม่ได้กำหนดให้เป็นค่าเริ่มต้น ดังที่อธิบายไว้ในบันทึกการเผยแพร่ Debian 12หากการติดตั้งของคุณใช้ตัวจัดการ DNS อื่น ให้ใช้ตัวจัดการนั้นเป็นหลักแทนที่จะบังคับใช้การตั้งค่าเหล่านี้กับมัน

1. ระบุจุดที่การแก้ไขชื่อล้มเหลว

เริ่มต้นด้วยการกำหนดเส้นทางเครือข่ายและการค้นหาชื่อโฮสต์ รันคำสั่งเหล่านี้ในเครื่องหรือในเทอร์มินัลที่จะเปิดค้างไว้หากมีการเปลี่ยนแปลงเครือข่าย:

ip -br address
ip route
ping -c 2 1.1.1.1
resolvectl status
resolvectl query debian.org
getent ahosts debian.org

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

resolvectl statusแสดงเซิร์ฟเวอร์ DNS และโดเมนที่กำหนดไว้ทั่วโลกหรือสำหรับแต่ละอินเทอร์เฟซresolvectl queryทดสอบตัวแก้ไขชื่อโฮสต์ของ systemd และgetent ahostsทดสอบเส้นทางการค้นหาชื่อโฮสต์ที่แอปพลิเคชัน Linux ใช้กันทั่วไป ความแตกต่างนี้ช่วยในการแยกแยะสาเหตุของปัญหา

2. ตรวจสอบให้แน่ใจว่าได้ติดตั้งและเปิดใช้งาน systemd-resolved แล้ว

ใน Debian 12 การมีอยู่ของ systemd ไม่ได้หมายความว่าแพ็คเกจ resolver แยกต่างหากจะได้รับการติดตั้งเสมอไป ตรวจสอบแพ็คเกจและหน่วยก่อนทำการเปลี่ยนแปลงไฟล์ DNS ใดๆ:

dpkg-query -W -f='${Status}\n' systemd-resolved
systemctl status systemd-resolved --no-pager

หากติดตั้งแพ็กเกจแล้วแต่บริการไม่ทำงาน ให้เริ่มบริการและเปิดใช้งานสำหรับการบูตครั้งต่อไป:

sudo systemctl enable --now systemd-resolved
systemctl is-active systemd-resolved

คำสั่งสุดท้ายควรรายงานผลลัพธ์activeหากอุปกรณ์ทำงานล้มเหลว ให้ตรวจสอบข้อความแสดงข้อผิดพลาดจริงแทนที่จะรีสตาร์ทอุปกรณ์ซ้ำๆ:

journalctl -u systemd-resolved -b --no-pager -n 60

หากไม่พบแพ็กเกจ ให้ติดตั้งsudo apt install systemd-resolvedหลังจากที่คุณมีสิทธิ์เข้าถึงคลังแพ็กเกจแล้วเท่านั้น การติดตั้ง/etc/resolv.confแพ็กเกจนี้จะเปลี่ยนการควบคุมของระบบ ดังนั้นโปรดตรวจสอบการตั้งค่า NetworkManager, VPN หรือ static DNS ก่อน เอกสารของ Debian ได้ระบุการเปลี่ยนแปลงแพ็กเกจนี้ไว้ในบันทึกการอัปเกรด Bookwormแล้ว

3. ซ่อมแซมลิงก์ตัวแก้ไขเฉพาะในกรณีที่ลิงก์นั้นผิดพลาดเท่านั้น

ตัวจัดการพอร์ต มาตรฐานsystemd-resolvedจะรับฟังที่พอร์ต127.0.0.53. ไฟล์ที่แนะนำสำหรับการใช้งานร่วมกันคือ/run/systemd/resolve/stub-resolv.confซึ่งสามารถเชื่อมโยงได้จาก/etc/resolv.conf. ตรวจสอบโหมดปัจจุบันของคุณก่อน:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf
resolvectl status

การเชื่อมโยงไป/run/systemd/resolve/resolv.confยังก็เป็นโหมดที่รองรับเช่นกัน แต่โปรแกรมที่ใช้โหมดนี้จะติดต่อ DNS ต้นทางโดยตรงแทนที่จะใช้ stub ในเครื่อง อย่าบอกว่าลิงก์นั้นเสียเพียงเพราะมันแตกต่างออกไปคู่มือบริการ systemd-resolved ของ Debian อธิบายโหมดที่รองรับไว้

หากคุณตั้งใจใช้ stub ในเครื่อง บริการกำลังทำงานอยู่ ตัวรับฟัง stub ถูกเปิดใช้งาน และ stub ที่มีอยู่/etc/resolv.confหายไป ค้างอยู่ หรือชี้ไปยังตัวแก้ไขที่ล้าสมัย ให้กู้คืนลิงก์ที่แนะนำ ก่อนอื่นให้สำรองไฟล์หรือลิงก์ที่มีอยู่ ข้ามขั้นตอนการคัดลอกหากไม่มีไฟล์อยู่:

sudo cp -a /etc/resolv.conf /etc/resolv.conf.dns-backup
sudo ln -sfn /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
cat /etc/resolv.conf

อย่าใช้งานการแทนที่นั้นบนโฮสต์ที่มีบริการอื่นจัดการอยู่แล้ว การเพิ่มรายการ /etc/resolv.confในเครื่องnameserver 127.0.0.53ยังต้องมีตัวรับฟังแบบ stub ที่ใช้งานได้ การเขียนที่อยู่เพียงอย่างเดียวไม่ได้สร้างบริการ DNS บนเครื่องระยะไกล ให้คงวิธีการเข้าถึงที่สองไว้ก่อนที่จะแก้ไขการตั้งค่าตัวแก้ไข

4. แก้ไขปัญหาเซิร์ฟเวอร์ DNS ต้นทางที่หายไปหรือไม่สามารถเข้าถึงได้

เมื่อresolvectl statusไม่พบเซิร์ฟเวอร์ DNS ต้นทางที่เหมาะสม หรือเซิร์ฟเวอร์ที่กำหนดค่าไว้ไม่สามารถเข้าถึงได้ ให้แก้ไขแหล่งที่มาของการกำหนดค่านั้น การตั้งค่า DNS แบบไดนามิกอาจมาจาก DHCP, NetworkManager, systemd-networkd หรือ VPN ตรวจสอบว่าอินเทอร์เฟซใดเป็นตัวนำเส้นทางเริ่มต้น และเซิร์ฟเวอร์ DNS ใดเป็นของอินเทอร์เฟซนั้น

สำหรับการทดสอบวินิจฉัยเบื้องต้นบนเครือข่ายที่อนุญาตให้ใช้ DNS สาธารณะ ให้กำหนดตัวแก้ไข DNS สาธารณะที่รู้จักให้กับอินเทอร์เฟซนั้น แทนที่ens33ด้วยอินเทอร์เฟซจริงจากip -br address:

sudo resolvectl dns ens33 1.1.1.1 1.0.0.1
resolvectl query debian.org

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

ด้วย NetworkManager คุณสามารถตรวจสอบการเชื่อมต่อที่ใช้งานอยู่nmcli connection show --activeและปรับการตั้งค่า DNS หรือพฤติกรรม DHCP ของการเชื่อมต่อดังกล่าวได้ ส่วนด้วย systemd-networkd ให้ใส่DNS=การตั้งค่าที่ต้องการลงใน.networkไฟล์ที่เกี่ยวข้อง แล้วทำการรีโหลดหรือกำหนดค่าเครือข่ายใหม่ในเวลาที่เหมาะสม โปรดดูคู่มือ systemd.network ของ Debianและคู่มือการกำหนดค่า NetworkManager ของ Debianการเชื่อมต่ออินเทอร์เฟซที่ได้รับการจัดการใหม่สามารถขัดจังหวะเซสชัน SSH ได้

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

5. ล้างแคชและตรวจสอบว่าเส้นทางการค้นหาทั้งสองทำงานได้ถูกต้อง

หลังจากแก้ไขบริการ ลิงก์ตัวแก้ไข หรือการกำหนดค่าต้นทางแล้ว ให้ล้างคำตอบที่แคชไว้และทดสอบอีกครั้ง:

sudo resolvectl flush-caches
resolvectl query debian.org
getent ahosts debian.org
resolvectl status

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

หากresolvectl queryสำเร็จแต่getentยังคงล้มเหลว ให้ตรวจสอบgrep "^hosts:" /etc/nsswitch.confและยืนยันว่าโมดูล NSS ที่เหมาะสมdnsหรือติดตั้งแล้วresolveอยู่ในเส้นทางการค้นหา หากทั้งสองอย่างยังคงล้มเหลว ให้ตรวจสอบบันทึกการแก้ไขและข้อจำกัดของไฟร์วอลล์ใดๆ เกี่ยวกับการรับส่งข้อมูล DNS จากนั้นทดสอบโดยใช้ที่อยู่ DNS ขององค์กร เราเตอร์ หรือผู้ให้บริการจริง การค้นหาที่สำเร็จเพียงครั้งเดียวไม่เพียงพอ: ทำซ้ำการตรวจสอบหลังจากเชื่อมต่อใหม่และหลังจากรีบูตเพื่อตรวจสอบการแก้ไขอย่างถาวร