DNS của bạn đang bị rò rỉ (Và ai cũng có thể theo dõi)
Chắc hẳn bạn đã dành hàng giờ để gia cố tường lửa, thay đổi SSH key và cấu hình WireGuard. Tuy nhiên, có thể bạn vẫn đang bỏ qua lỗ hổng cơ bản nhất trong hệ thống của mình: DNS. Trong nhiều thập kỷ, các truy vấn DNS đã được truyền đi khắp internet dưới dạng văn bản thuần (plain text) thông qua cổng UDP 53. Điều này có nghĩa là bất kỳ ai nằm giữa máy chủ Linux của bạn và bộ phân giải (resolver) — cho dù đó là ISP hay quản trị viên Wi-Fi công cộng — đều biết chính xác bạn đang truy cập tên miền nào.
Thực tế là ngay cả khi dùng HTTPS, quá trình bắt tay (handshake) DNS ban đầu của bạn vẫn hoàn toàn công khai. Siêu dữ liệu (metadata) này cho phép các nhà cung cấp xây dựng hồ sơ hoạt động của bạn một cách chính xác đến đáng sợ. Sau 6 tháng vận hành môi trường thực tế với tính năng mã hóa toàn phần, tôi nhận thấy rằng bảo mật DNS không chỉ là một tính năng riêng tư “có thì tốt”. Nó còn là về tính toàn vẹn của dữ liệu. Nếu bạn quan tâm đến bảo mật Linux hiện đại, đây là thiết lập mà bạn không nên bỏ qua.
Chọn “lá chắn”: DoT hay DoH?
Mã hóa DNS có hai phương thức chính. Cả hai đều bọc các truy vấn của bạn trong một lớp TLS, nhưng cách chúng xử lý lưu lượng thực tế lại rất khác nhau. Dưới đây là phân tích dựa trên thử nghiệm của tôi.
DNS over TLS (DoT)
DoT sử dụng một cổng riêng biệt (TCP 853). Nó khá minh bạch và dễ dàng cho các quản trị viên mạng theo dõi hoặc điều phối lưu lượng. Đây cũng là lựa chọn mặc định cho systemd-resolved. Tuy nhiên, vì sử dụng một cổng đặc thù, một tường lửa khắt khe có thể chặn nó chỉ với một quy tắc duy nhất. Tôi sử dụng phương thức này chủ yếu cho các máy chủ backend nơi tôi có quyền kiểm soát biên mạng.
DNS over HTTPS (DoH)
DoH ẩn các truy vấn của bạn bên trong lưu lượng HTTPS tiêu chuẩn trên cổng 443. Với bất kỳ người quan sát nào, các yêu cầu DNS của bạn trông giống như việc duyệt web thông thường. Điều này biến nó thành công cụ tối thượng để vượt qua sự kiểm duyệt hoặc các bộ lọc nghiêm ngặt của doanh nghiệp. Sự đánh đổi? Việc triển khai ở cấp độ hệ điều hành sẽ phức tạp hơn một chút, thường yêu cầu một proxy cục bộ như cloudflared.
Qua nửa năm trải nghiệm, dữ liệu của tôi cho thấy DoT là lựa chọn tối ưu cho hạ tầng máy chủ. Còn đối với máy trạm hoặc máy chủ nằm trong các mạng “độc hại”, DoH là cách duy nhất đáng tin cậy để giữ bí mật thói quen truy cập.
Kích hoạt DNS over TLS với systemd-resolved
Nếu bạn đang sử dụng Ubuntu 22.04, Fedora hoặc Debian, bạn đã có sẵn systemd-resolved. Đây là con đường đơn giản nhất. Dưới đây là cách tôi cấu hình hệ thống của mình để sử dụng Cloudflare và Google làm các upstream resolver mã hóa.
1. Chỉnh sửa cấu hình
Mở file cấu hình của bạn:
sudo nano /etc/systemd/resolved.confCập nhật phần [Resolve]. Đừng chỉ thêm một địa chỉ IP; hãy sử dụng nhiều nhà cung cấp để đảm bảo tính dự phòng.
[Resolve]
DNS=1.1.1.1 8.8.8.8 1.0.0.1 8.8.4.4
FallbackDNS=9.9.9.9
DNSOverTLS=yes
DNSSEC=yes2. Áp dụng và Kiểm tra
Khởi động lại dịch vụ để áp dụng các cài đặt mới:
sudo systemctl restart systemd-resolvedBây giờ, hãy kiểm tra trạng thái. Bạn không chỉ tìm dòng “active” — mà hãy tìm cờ mã hóa:
resolvectl statusTìm dòng +DNSOverTLS dưới interface đang hoạt động của bạn. Nếu nó xuất hiện, mọi truy vấn từ hệ thống hiện đã được mã hóa trước khi truyền đi.
Triển khai DNS over HTTPS với Cloudflared
Khi cổng 853 bị chặn, tôi chuyển sang sử dụng proxy cục bộ. cloudflared (từ Cloudflare) đóng vai trò là cầu nối giữa các ứng dụng cục bộ của bạn và DoH endpoint.
1. Tải file thực thi (Binary)
Đối với các hệ thống dựa trên Debian, hãy tải phiên bản mới nhất:
wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared-linux-amd64.deb2. Cấu hình Proxy
Tạo file cấu hình của bạn:
sudo mkdir -p /etc/cloudflared
sudo nano /etc/cloudflared/config.yamlTrỏ nó tới các DoH endpoint:
proxy-dns: true
proxy-dns-port: 5053
proxy-dns-upstream:
- https://1.1.1.1/dns-query
- https://1.0.0.1/dns-query3. Tự động hóa Dịch vụ
Cài đặt nó như một dịch vụ hệ thống để nó tự khởi chạy khi khởi động lại máy:
sudo cloudflared service install
sudo systemctl start cloudflared
sudo systemctl enable cloudflaredCuối cùng, hãy đặt DNS hệ thống thành 127.0.0.1 trong phần cài đặt mạng hoặc trong resolved.conf. Lưu lượng của bạn hiện sẽ đi qua proxy cục bộ tại cổng 5053 và ra ngoài web thông qua cổng 443.
Kiểm tra thực tế (Smoke Test): Nó có thực sự hoạt động?
Đừng bao giờ tin tưởng hoàn toàn vào thông báo trạng thái. Sai lầm lớn nhất là mặc định rằng mình đã an toàn trong khi hệ thống vẫn âm thầm quay về sử dụng cổng 53. Bạn cần xác nhận rằng không có lưu lượng văn bản thuần nào bị rò rỉ.
Chạy tcpdump ở một terminal để theo dõi rò rỉ:
sudo tcpdump -ni any port 53Bây giờ, hãy kích hoạt một truy vấn ở terminal thứ hai: dig google.com. Nếu tcpdump không hiển thị gì, quá trình mã hóa của bạn đã ổn định. Nếu bạn thấy văn bản chạy liên tục, hệ thống của bạn vẫn đang để lộ các truy vấn ở dạng văn bản thuần.
Ưu điểm, Nhược điểm và Độ trễ
Nửa năm vận hành thực tế đã bộc lộ một vài đặc điểm mà bạn nên chuẩn bị trước:
- “Cơn ác mộng” Captive Portal: Wi-Fi tại sân bay và khách sạn thường chiếm quyền điều khiển (hijack) DNS để hiển thị trang đăng nhập. Nếu DoT được đặt ở chế độ bắt buộc (Hard), bạn sẽ không thể kết nối. Tôi thường đặt một alias để nhanh chóng chuyển
DNSOverTLSsang chế độ ‘opportunistic’ (linh hoạt) khi đi du lịch. - “Thuế” độ trễ: Quá trình bắt tay TLS không hề miễn phí. Tôi đã đo được mức tăng trung bình từ 12ms đến 18ms cho truy vấn đầu tiên. Tuy nhiên, khi kết nối đã được duy trì và lưu trong bộ nhớ đệm (cached) cục bộ, tốc độ cảm nhận được hoàn toàn tương đương with DNS tiêu chuẩn.
- Dự phòng là yếu tố then chốt: Đừng chỉ dựa vào một nhà cung cấp duy nhất. Tôi đã từng gặp sự cố gián đoạn 45 phút khi DoH của Cloudflare không thể truy cập từ node Frankfurt của mình. Nhờ có phương án dự phòng Quad9 (9.9.9.9), các dịch vụ của tôi vẫn hoạt động mà không bị rớt bất kỳ truy vấn nào.
Sự an tâm khi biết rằng ISP không thu thập siêu dữ liệu của mình để phục vụ cho mảng quảng cáo xứng đáng với mọi khó khăn nhỏ gặp phải. Nếu bạn quản lý các máy chủ xử lý dữ liệu nhạy cảm, DNS mã hóa không còn là một thứ xa xỉ — đó là một yêu cầu bắt buộc.
Lời kết
Trong môi trường hiện nay, DNS văn bản thuần là một rủi ro bảo mật. Cho dù bạn chọn sự đơn giản nguyên bản của DoT hay khả năng ẩn mình của DoH, bạn đang lấp đầy một lỗ hổng lớn trong hệ phòng thủ của máy chủ. Hãy bắt đầu bằng cách thử nghiệm trên một máy dev duy nhất, xác minh bằng tcpdump và sau đó triển khai cho toàn bộ hệ thống của bạn. Bạn trong tương lai sẽ cảm ơn chính mình vì lớp giáp bảo vệ bổ sung này.
