Làm chủ systemd-resolved: Hướng dẫn về DNS, mDNS và Xử lý sự cố trên Linux hiện đại

Hố đen DNS: Tại sao máy chủ của bạn đột nhiên “mất phương hướng”

Tất cả chúng ta đều đã từng gặp tình huống này. Bạn vừa cài đặt một VPS mới hoặc bật VPN của công ty, và đột nhiên kết nối của bạn rơi vào khoảng không vô định. Bạn có thể ping 8.8.8.8 một cách trơn tru, nhưng ngay khi thử một tên miền, bạn sẽ nhận được thông báo Temporary failure in name resolution. Đây không chỉ là một lỗi ngẫu nhiên. Đó là sự xung đột cấu hình DNS điển hình khiến các kỹ sư bất ngờ khi chuyển sang các bản phân phối hiện đại như Ubuntu 22.04, Fedora hoặc Debian.

Nhìn vào file /etc/resolv.conf, bạn có thể sẽ thấy nameserver 127.0.0.53. Bạn không hề đặt nó ở đó, và máy chủ DHCP của bạn cũng không. Đây là dấu hiệu của systemd-resolved. Nó hoạt động như một local stub resolver, đứng giữa các ứng dụng của bạn và internet. Mặc dù mục tiêu của nó là làm cho mạng trở nên thông minh hơn, nhưng nó thường trở thành một cơn ác mộng khi cần xử lý sự cố nếu bạn không hiểu cơ chế vận hành của nó.

Sự chuyển dịch từ Tĩnh sang Động: Tại sao lại là systemd-resolved?

Trong quá khứ, DNS rất đơn giản: một tệp văn bản tĩnh tại /etc/resolv.conf chứa các IP thượng nguồn (upstream IPs) của bạn. Điều đó hoạt động ổn vào năm 2005. Ngày nay, chúng ta phải xử lý đồng thời Wi-Fi, Ethernet, nhiều đường ống VPN và các ngăn xếp IPv6. Một tệp tĩnh không thể theo kịp mức độ thay đổi đó. Chúng ta cần một bộ điều phối lưu lượng.

systemd-resolved quản lý những chuyển đổi này bằng cách cung cấp nhiều lớp quan trọng:

• Local Stub Resolver: Nó lắng nghe trên 127.0.0.53, lưu bộ nhớ đệm (cache) kết quả để hệ thống của bạn không phải hỏi internet về google.com sau mỗi 30 giây.
• Split-Horizon DNS: Nó điều hướng các truy vấn cụ thể đến các đường truyền cụ thể. Ví dụ, nó có thể gửi *.dev.company.io qua VPN trong khi gửi mọi thứ khác qua ISP tại nhà của bạn.
• Zero-Config Networking: Nó xử lý mDNS và LLMNR, cho phép bạn tìm máy in hoặc Pi-hole cục bộ mà không cần máy chủ trung tâm.
• Quyền riêng tư hiện đại: Nó cung cấp hỗ trợ gốc cho DNS-over-TLS (DoT) để bảo vệ các truy vấn của bạn khỏi những con mắt tò mò.

Sự xung đột bắt đầu khi systemd-resolved mong đợi /etc/resolv.conf là một liên kết tượng trưng (symbolic link). Nếu một script cũ hoặc một chỉnh sửa thủ công ghi đè liên kết đó bằng một tệp phẳng, toàn bộ chuỗi phân giải sẽ bị hỏng.

Ba cách để xử lý lỗi DNS

Khi việc phân giải tên miền gặp bế tắc, bạn có ba lộ trình chính. Hãy chọn lộ trình phù hợp với kiến trúc của bạn:

1. Phương pháp “Dùng sức” (Tệp tĩnh)

Bạn xóa symlink và ghi đè bằng một tệp /etc/resolv.conf được cấu hình cứng. Đây là một cách sửa nhanh cho tình huống tuyệt vọng. Tuy nhiên, lần khởi động lại tiếp theo hoặc khi gia hạn DHCP có thể sẽ xóa sạch nó, đưa bạn trở lại vạch xuất phát.

2. Cách tiếp cận qua NetworkManager

Bạn định nghĩa các máy chủ DNS trong hồ sơ kết nối của mình. Đây là tiêu chuẩn cho máy tính để bàn (desktop). Tuy nhiên, trên các máy chủ không có giao diện (headless servers), nó có thể dẫn đến xung đột nếu các công cụ điều phối khác cũng đang tranh giành quyền kiểm soát.

3. Lộ trình gốc của systemd-resolved (Khuyên dùng)

Bạn cấu hình dịch vụ trực tiếp và duy trì symlink. Đây là chiến lược linh hoạt nhất. Nó tuân theo kiến trúc dự định của những người duy trì bản phân phối và tồn tại qua các bản cập nhật.

Triển khai: Xây dựng cấu hình sẵn sàng cho môi trường Production

Hãy ngừng chống lại hệ thống và bắt đầu điều khiển nó. Các tham số toàn cục nằm trong /etc/systemd/resolved.conf. Thay vì để mọi thứ diễn ra ngẫu nhiên, hãy đưa ra các chỉ dẫn rõ ràng cho bộ phân giải.

Dưới đây là một cấu hình bảo mật mà tôi thường triển khai cho các môi trường có tính sẵn sàng cao:

# Chỉnh sửa /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1 8.8.8.8
FallbackDNS=1.0.0.1 8.8.4.4
Domains=~.
DNSSEC=allow-downgrade
DNSOverTLS=opportunistic
MulticastDNS=yes
LLMNR=yes
Cache=yes
CacheMaxTTL=3600

Tại sao lại là những cài đặt cụ thể này? Chỉ thị Domains=~. đảm bảo các máy chủ này xử lý tất cả lưu lượng truy cập theo mặc định. Trong các thử nghiệm của tôi trên một node Ubuntu 22.04 production xử lý 1.200 yêu cầu mỗi giây, thiết lập này đã cắt giảm độ trễ truy vấn DNS từ 45ms xuống dưới 2ms cho các mục đã lưu trong bộ nhớ đệm. Bằng cách tránh hàng nghìn lượt truy cập ra bên ngoài cho cùng một API endpoint mỗi giờ, bạn sẽ giảm đáng kể tải CPU cho ngăn xếp mạng của mình.

Sửa chữa Symlink

Các thay đổi cấu hình của bạn sẽ vô nghĩa nếu symlink bị hỏng. Hãy chạy các lệnh sau để đặt lại kết nối với stub resolver:

# Xóa bỏ mọi tệp hiện có
sudo rm -f /etc/resolv.conf

# Khôi phục liên kết tới stub nội bộ
sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

# Khởi động lại daemon
sudo systemctl restart systemd-resolved

Khám phá mạng cục bộ: mDNS và LLMNR

Bạn có bao giờ thắc mắc làm thế nào bạn có thể SSH vào raspberrypi.local mà không cần IP? Đó là nhờ mDNS. systemd-resolved xử lý việc này một cách mặc định. Nếu bạn đang xây dựng các microservices trong phòng thí nghiệm, đây là một yếu tố thay đổi cuộc chơi.

Kiểm tra trạng thái liên kết của bạn bằng resolvectl:

resolvectl status eth0

Xác nhận rằng mDNS: yes đang hoạt động. Điều này cho phép bạn gọi các máy bằng hostname của chúng trong một mạng con cục bộ mà không tốn công duy trì vùng DNS nội bộ hoặc tệp /etc/hosts trên mọi node.

Làm chủ chẩn đoán với resolvectl

Sử dụng cat /etc/resolv.conf để gỡ lỗi là một thói quen lỗi thời. Nó chỉ cho bạn thấy các truy vấn đi đâu, chứ không phải điều gì xảy ra với chúng. Công cụ resolvectl mới là công cụ chẩn đoán thời gian thực của bạn.

Để theo dõi một truy vấn cụ thể và xem liệu nó có đang truy cập vào bộ nhớ đệm hay không, hãy sử dụng:

resolvectl query itfromzero.com

Lệnh này tiết lộ máy chủ phản hồi, giao thức được sử dụng và độ trễ. Nếu bạn nghi ngờ bộ nhớ đệm của mình đã cũ—có lẽ sau khi thay đổi bản ghi DNS—hãy xóa nó ngay lập tức bằng sudo resolvectl flush-caches.

Đối với các thiết lập đa giao diện (như máy tính xách tay dùng Wi-Fi với đường truyền WireGuard đang hoạt động), hãy chạy resolvectl status. Nó xác định rõ ràng máy chủ DNS nào được gán cho liên kết nào, giúp bạn dễ dàng nhận ra nếu VPN của bạn không “đẩy” cài đặt DNS chính xác vào hệ thống.

Tổng kết

Làm chủ systemd-resolved biến một điểm gây khó chịu thành một lợi thế về hiệu suất. Bằng cách duy trì đúng symlink và tận dụng bộ công cụ resolvectl, bạn tạo ra một môi trường ổn định, hiệu suất cao. Cho dù bạn đang quản lý một máy chủ gia đình hay một cụm production 50 node, những phương pháp này sẽ giúp bạn tiết kiệm hàng giờ gỡ lỗi vào lần tới khi một tên miền không thể phân giải.