แก้ไขปัญหา "ความล้มเหลวชั่วคราวในการแก้ไข DNS" ใน Debian 12 ด้วย systemd-resolved

ข้อผิดพลาดนี้Temporary failure in name resolutionหมายความว่าแอปพลิเคชันไม่สามารถแปลงชื่อโฮสต์ เช่น เป็นdeb.debian.orgที่อยู่ IP ได้ ใน Debian 12 (Bookworm) นั้นไม่ได้หมายความว่าsystemd-resolvedเสียโดยอัตโนมัติ Debian 12 ไม่ได้ติดตั้งsystemd-resolvedโดยค่าเริ่มต้น และ DNS อาจได้รับการจัดการโดยตรงโดย NetworkManager, ifupdown, เครื่องมือ DHCP หรือตัวแก้ไขอื่นๆ หากคุณเปิดใช้งานโดยเจตนาsystemd-resolvedวิธีแก้ไขที่เร็วที่สุดคือการระบุว่าเลเยอร์ใดล้มเหลวก่อนที่จะเปลี่ยนการกำหนดค่า

เอกสาร อ้างอิงเชิงปฏิบัติฉบับนี้เน้นที่ระบบที่ใช้ หรือตั้งใจจะใช้ systemd -resolved systemd-resolvedเอกสารประกอบแพ็กเกจ Bookworm ของ Debian ระบุว่าการติดตั้งsystemd-resolvedสวิตช์ จะเปลี่ยน /etc/resolv.confไปใช้การจัดการ systemd-resolved บริการนี้จะให้บริการ DNS stub ในพื้นที่127.0.0.53และรับข้อมูล DNS จากการกำหนดค่าส่วนกลาง การกำหนดค่าเครือข่ายต่อลิงก์ DHCP resolvectlและบริการจัดการเครือข่าย ดูราย ละเอียดเพิ่มเติมได้ ที่หน้าแพ็กเกจ systemd-resolved ของ Debianและคู่มือ systemd-resolved ของ Debian

รายการตรวจสอบการวินิจฉัยอย่างรวดเร็ว

1. ยืนยันว่าปัญหาเกิดจาก DNS ไม่ใช่การเชื่อมต่อโดยทั่วไป

เริ่มจากการทดสอบชื่อโฮสต์ก่อน แล้วจึงทดสอบที่อยู่ IP:

getent ahosts debian.org
ping -c 3 debian.org
ping -c 3 1.1.1.1

หากการค้นหาชื่อโฮสต์ล้มเหลวในขณะที่การทดสอบ IP โดยตรงสำเร็จ โดเมน DNS น่าจะเป็นสาเหตุหลัก หากทั้งสองอย่างล้มเหลว ให้ตรวจสอบอินเทอร์เฟซ เส้นทาง เกตเวย์ VLAN การเชื่อมต่อ Wi-Fi ไฟร์วอลล์ หรือเครือข่ายต้นทางก่อน การเปลี่ยนแปลง DNS ไม่สามารถแก้ไขเส้นทางเริ่มต้นที่หายไปได้

หากต้องการตรวจสอบเส้นทางอย่างแม่นยำยิ่งขึ้น ให้เรียกใช้คำสั่งต่อไปนี้ด้วย:

ip address
ip route

โดยปกติแล้ว คุณควรจะมีที่อยู่บนอินเทอร์เฟซที่คาดหวังไว้และเส้นทางเริ่มต้น ชื่ออินเทอร์เฟซที่แน่นอนอาจจะเป็นenp1s0, ens160, eth0, หรืออย่างอื่นก็ได้

2. ตรวจสอบว่า systemd-resolved กำลังถูกใช้งานอยู่จริงหรือไม่

อย่าคิดว่ามันมีอยู่แล้วเพียงเพราะเครื่องใช้ systemd ตรวจสอบทั้งแพ็กเกจและบริการ:

dpkg -s systemd-resolved 2>/dev/null | grep '^Status'
systemctl status systemd-resolved --no-pager
resolvectl status

หากไม่มีแพ็กเกจดังกล่าว และเครื่องของคุณมีระบบจัดการ DNS อื่นที่ใช้งานได้ การติดตั้งแพ็กเกจนั้นsystemd-resolvedอาจไม่ใช่วิธีแก้ปัญหาที่ถูกต้องเสมอไป หากระบบควรใช้งานแพ็กเกจนั้น และบริการถูกติดตั้งแล้วแต่หยุดทำงาน ให้เปิดใช้งานและเริ่มต้นบริการนั้น:

sudo systemctl enable --now systemd-resolved

หากคำสั่งนั้นล้มเหลว ให้ตรวจสอบบันทึกก่อนที่จะรีสตาร์ทบริการซ้ำๆ:

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

3. ตรวจสอบไฟล์ /etc/resolv.conf ก่อนทำการเปลี่ยนไฟล์

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

ls -l /etc/resolv.conf
cat /etc/resolv.conf

ไฟล์ปกติไม่ได้ผิดเสมอไป NetworkManager หรือตัวจัดการการแก้ไขชื่อโดเมนอื่นๆ อาจเป็นเจ้าของไฟล์นั้นโดยเจตนา อย่างไรก็ตาม หากโฮสต์นี้ถูกออกแบบมาให้ใช้โหมด stub ที่แก้ไขโดย systemd ไฟล์ปกติที่ล้าสมัย ลิงก์สัญลักษณ์ที่ค้างอยู่ หรือไฟล์ที่ชี้ไปยังเนมเซิร์ฟเวอร์ที่ไม่สามารถเข้าถึงได้ อาจทำให้การค้นหาล้มเหลว

คืนค่าลิงก์แบบ stub ที่แนะนำเมื่อต้องการใช้งานโหมด stub

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved
ls -l /etc/resolv.conf
cat /etc/resolv.conf

การเห็นข้อมูลnameserver 127.0.0.53ในไฟล์ stub นั้นเป็นเรื่องปกติ มันคือตัวรับฟังในเครื่อง ไม่ใช่เซิร์ฟเวอร์ DNS ต้นทาง ใช้คำสั่งresolvectl statusเพื่อดูว่า systemd-resolved จะติดต่อเซิร์ฟเวอร์ต้นทางใดบ้าง ความแตกต่างนี้มีบันทึกไว้ในคู่มือ systemd-resolved Bookwormแล้ว

4. ตรวจสอบว่า systemd-resolved มีเซิร์ฟเวอร์ DNS ต้นทางที่ใช้งานได้หรือไม่

วิ่ง:

resolvectl status

ให้เน้นที่ลิงก์ที่ส่งเส้นทางเริ่มต้น (default route) การกำหนดค่าที่ถูกต้องควรแสดงเซิร์ฟเวอร์ DNS อย่างน้อยหนึ่งตัวสำหรับลิงก์นั้น หรือเซิร์ฟเวอร์ DNS ทั่วโลกที่เหมาะสม หากไม่มีเซิร์ฟเวอร์ DNS ที่ใช้งานได้ การแก้ไขลิงก์สัญลักษณ์ (symlink) เพียงอย่างเดียวจะไม่ช่วยอะไร เพราะส่วนเชื่อมต่อภายใน (local stub) ไม่มีที่ใดที่จะส่งคำขอค้นหาได้อย่างมีประโยชน์

คุณสามารถทดสอบตัวแก้ไขได้โดยตรง:

resolvectl query debian.org

คู่มือresolvectl ของ Debian อธิบายถึง , status, query, flush-cachesและคำสั่ง DNS ต่อลิงก์ที่ใช้สำหรับการตรวจสอบและแก้ไขปัญหา

5. หาก NetworkManager เป็นเจ้าของอินเทอร์เฟซ ให้แก้ไข DNS ในโปรไฟล์การเชื่อมต่อ

ในการติดตั้งบนเดสก์ท็อปและระบบ Debian ทั่วไปหลายๆ ระบบ NetworkManager อาจให้ข้อมูล DNS ต่อลิงก์แก่ systemd-resolved ก่อนอื่นให้ระบุโปรไฟล์ที่ใช้งานอยู่และค่า DNS ปัจจุบัน:

nmcli connection show --active
nmcli device show

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

sudo nmcli connection modify "Wired connection 1"   ipv4.ignore-auto-dns yes   ipv4.dns "1.1.1.1 9.9.9.9"
sudo nmcli connection up "Wired connection 1"

แทนที่ชื่อโปรไฟล์และเซิร์ฟเวอร์ DNS ด้วยค่าที่เหมาะสมกับเครือข่ายของคุณ เครือข่ายองค์กร VPN สภาพแวดล้อม Active Directory และการตั้งค่า Split-DNS มักต้องการตัวแก้ไขภายใน DNS สาธารณะอาจทำให้ชื่อโฮสต์ส่วนตัวใช้งานไม่ได้ เอกสาร อ้างอิงการกำหนดค่า อย่างเป็นทางการของ NetworkManager อธิบาย ถึงการทำงานร่วมกับsystemd-resolved.

6. หาก systemd-networkd เป็นเจ้าของอินเทอร์เฟซ ให้กำหนดค่า DNS ต่อลิงก์

สำหรับเซิร์ฟเวอร์ที่ใช้ ให้systemd-networkdใส่การตั้งค่า DNS ใน.networkไฟล์ที่ตรงกันภายใต้/etc/systemd/network/ตัวอย่างง่ายๆ สำหรับเซิร์ฟเวอร์ที่ใช้ DHCP คือ:

[Match]
Name=ens160

[Network]
DHCP=yes
DNS=1.1.1.1
DNS=9.9.9.9
Domains=~.

[DHCPv4]
UseDNS=no

UseDNS=noเรื่องนี้สำคัญเมื่อคุณต้องการละเว้นเซิร์ฟเวอร์ DNS ที่จัดหาโดย DHCP โดยเฉพาะ หากไม่มีการตั้งค่านี้ ระบบจะใช้ DNS ของ DHCP เป็นค่าเริ่มต้นDomains=~.ลิงก์นี้เป็นโดเมนสำหรับการกำหนดเส้นทางเท่านั้นสำหรับรูท DNS ทำให้ลิงก์นั้นเหมาะสมสำหรับการค้นหาที่ไม่ตรงกับโดเมนการกำหนดเส้นทางที่เฉพาะเจาะจงกว่า อย่าเพิ่มลิงก์นี้โดยไม่คิดไตร่ตรองในระบบที่มีการเชื่อมต่อหลายเครือข่ายหรือ VPN ที่ตั้งใจใช้การแยก DNS

sudo systemctl restart systemd-networkd
resolvectl status ens160

ลักษณะการทำงานของDNS=, Domains=, และ DHCP UseDNS=ได้รับการบันทึกไว้ใน คู่มือ systemd.network ของ Debian Bookworm

7. ใช้ไฟล์ global resolved.conf เฉพาะเมื่อคุณต้องการใช้ DNS ทั่วทั้งระบบจริงๆ เท่านั้น

/etc/systemd/resolved.confหรือสามารถใช้ตัวเลือกแบบดรอปอิน/etc/systemd/resolved.conf.d/เพื่อกำหนดเซิร์ฟเวอร์ DNS ของระบบได้ วิธีนี้มีประโยชน์สำหรับนโยบายระดับโฮสต์ แต่มีความแม่นยำน้อยกว่าการกำหนดค่าต่อลิงก์ในเครื่องที่มี VPN อินเทอร์เฟซหลายตัว หรือโซน DNS ส่วนตัว

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

sudo mkdir -p /etc/systemd/resolved.conf.d
sudoedit /etc/systemd/resolved.conf.d/10-dns.conf

ตัวอย่าง:

[Resolve]
DNS=1.1.1.1 9.9.9.9

จากนั้นนำไปใช้:

sudo systemctl restart systemd-resolved
resolvectl status

คู่มือresolved.conf ของ Debianอธิบายว่าDNS=ไฟล์นี้จัดหาเซิร์ฟเวอร์ DNS ของระบบ และการตั้งค่าเพิ่มเติมของผู้ดูแลระบบ/etc/systemd/resolved.conf.d/จะมีลำดับความสำคัญเหนือกว่าการตั้งค่าที่มีลำดับความสำคัญต่ำกว่า

8. ล้างแคชหลังจากแก้ไขการตั้งค่าพื้นฐานเสร็จเรียบร้อยแล้วเท่านั้น

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

sudo resolvectl flush-caches
resolvectl query debian.org

เอกสารของ Systemd เองระบุว่าโดยปกติแคชจะถูกล้างโดยอัตโนมัติเมื่อมีการเปลี่ยนแปลงการกำหนดค่าเครือข่าย ดังนั้นการล้างแคชด้วยตนเองซ้ำๆ จึงไม่ควรเป็นวิธีแก้ไขหลักของคุณ

9. อ่านบันทึกการแก้ไขปัญหาเมื่อปัญหายังคงอยู่

หากresolvectl statusดูแล้วสมเหตุสมผล แต่การสืบค้นยังคงหมดเวลา โปรดตรวจสอบบันทึกการแก้ไข boot-local:

journalctl -u systemd-resolved -b --no-pager
journalctl -u systemd-resolved -b --no-pager | tail -n 50

สังเกตการหมดเวลาของเซิร์ฟเวอร์ซ้ำๆ การเปลี่ยนแปลงเซิร์ฟเวอร์สำรอง ความล้มเหลวในการตรวจสอบ DNSSEC หรือข้อความที่บ่งชี้ว่าคุณสมบัติของโปรโตคอลลดลง ตัวแก้ไขชื่อโดเมนอาจทำงานได้ตามปกติในขณะที่เซิร์ฟเวอร์อัปสตรีมที่กำหนดค่าไว้ไม่สามารถเข้าถึงได้ผ่านไฟร์วอลล์ VPN นโยบายการกำหนดเส้นทาง หรือ ACL เครือข่าย

10. ตรวจสอบเส้นทางการค้นหาทั้งหมด

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

getent ahosts debian.org
resolvectl query debian.org
sudo apt update

getentมีประโยชน์เพราะการค้นหาชื่อโฮสต์ของ glibc เป็นไปตามhosts:บรรทัดใน/etc/nsswitch.conf. หากresolvectl queryสำเร็จแต่getentล้มเหลว ให้ตรวจสอบการกำหนดค่า NSS นั้นคู่มือ nss-resolve ของ Debian อธิบายถึงโมดูลเสริมlibnss-resolveและลำดับที่แนะนำซึ่งสามารถกำหนดเส้นทางการค้นหาชื่อโฮสต์ของ glibc ผ่าน systemd-resolved ในขณะที่ยังคงรักษาตัวเลือกสำรองไว้

อาการทั่วไปและบริเวณที่ควรตรวจสอบมากที่สุด

ใบสั่งซ่อมที่แนะนำ

1. ตรวจสอบว่ามีการเชื่อมต่อเครือข่ายพื้นฐานและเส้นทางเริ่มต้น (default route) อยู่หรือไม่
2. ตรวจสอบว่าsystemd-resolvedอุปกรณ์นี้ถูกออกแบบมาเพื่อจัดการ DNS บนโฮสต์นี้จริง หรือไม่
3. ตรวจสอบsystemd-resolvedสถานะการให้บริการและresolvectl status.
4. ตรวจสอบ/etc/resolv.confความเป็นเจ้าของและโหมดการสร้างลิงก์สัญลักษณ์ก่อนทำการเปลี่ยนแปลง
5. หากต้องการใช้งานในโหมด stub ให้กู้คืนstub-resolv.confลิงก์
6. แก้ไข DNS ต้นทางที่เจ้าของที่แท้จริง: NetworkManager, systemd-networkd, DHCP, VPN หรือการกำหนดค่าการแก้ไขส่วนกลาง
7. ล้างแคชหลังจากแก้ไขการตั้งค่าเสร็จเรียบร้อยแล้วเท่านั้น
8. ตรวจสอบกับresolvectl, getent, และแอปพลิเคชันที่ล้มเหลวในครั้งแรก

หลักการสำคัญคือความเป็นเจ้าของ: /etc/resolv.confsystemd-resolved และตัวจัดการเครือข่ายเป็นส่วนหนึ่งของห่วงโซ่ตัวแก้ไข DNS เดียวกัน การแก้ไขที่ยั่งยืนจะเปลี่ยน DNS ในระดับที่เป็นเจ้าของ แทนที่จะแทนที่ไฟล์ที่สร้างขึ้นครั้งสุดท้ายซ้ำๆ