Chẩn đoán hành vi DNS hijacking của ISP khi các resolver tiêu chuẩn thất bại

Karthikey Hegde đã phát hiện ra rằng container Podman của anh không thể truy cập vào một trang web cụ thể, mặc dù đã thực hiện các bước khắc phục sự cố tiêu chuẩn. Các truy vấn gửi đến những resolver công cộng lớn như Google và Cloudflare đều trả về một địa chỉ IP thuộc sở hữu của nhà cung cấp dịch vụ Internet (ISP) của anh, trong khi DNS mã hóa lại tiết lộ đúng đích đến. Sự cố này làm nổi bật một lỗ hổng nghiêm trọng đối với những người tự host (self-hosters): việc thay đổi cài đặt máy chủ DNS thường không mang lại sự bảo vệ nào nếu ISP chặn đứng lưu lượng trên cổng 53.

Chuyện gì đã xảy ra

Cuộc điều tra của Hegde bắt đầu khi một dịch vụ trong môi trường cục bộ của anh không phân giải được tên miền. Anh đã thử nghiệm nhiều resolver DNS công cộng, bao gồm 1.1.1.1, 8.8.8.8 và 9.9.9.9. Đáng ngạc nhiên là mọi truy vấn dạng văn bản thuần đều trả về cùng một địa chỉ IP, mà tra cứu WHOIS xác nhận là thuộc về ISP của anh. Khi anh sử dụng điểm cuối DNS over HTTPS (DoH) của Cloudflare, truy vấn trả về địa chỉ IP hợp lệ cho trang web mục tiêu. Sự khác biệt này chứng minh rằng ISP của anh đang tích cực chặn đứng và viết lại các gói tin UDP DNS trên cổng 53, bất kể địa chỉ resolver được chỉ định là gì.

Hành vi này khiến những lời khuyên phổ biến trở nên vô hiệu. Việc hướng dẫn người dùng chuyển sang 1.1.1.1 hoặc 8.8.8.8 giả định rằng ISP sẽ trung thực chuyển tiếp các gói tin đó. Trên thực tế, lưu lượng UDP không được xác thực trên cổng 53 có thể bị chặn bởi bất kỳ thiết bị mạng nào dọc theo đường truyền. Như đã được thảo luận trong các cuộc trao đổi kỹ thuật xoay quanh sự cố, việc chặn UDP DNS là điều đơn giản đối với các nhà vận hành mạng. Thiết bị của ISP chỉ cần bắt lấy gói tin và phản hồi bằng một câu trả lời giả mạo, tạo cảm giác như thể resolver được yêu cầu đã cung cấp dữ liệu sai.

Chi tiết chính

• Các truy vấn DNS dạng văn bản thuần trên cổng 53 thiếu cơ chế xác thực, cho phép ISP dễ dàng chặn và viết lại phản hồi.
• Nhiều resolver công cộng trả về cùng một địa chỉ IP sai gợi ý có một điểm chặn duy nhất, chứ không phải lỗi độc lập từ các resolver.
• DNS over HTTPS (DoH) và DNS over TLS (DoT) mã hóa các truy vấn, ngăn chặn việc sửa đổi trong quá trình truyền tải bởi các mạng trung gian.
• Sự không khớp giữa kết quả DNS văn bản thuần và DNS mã hóa đòi hỏi phải xác minh qua WHOIS để phân biệt giữa hành vi can thiệp và vị trí địa lý của CDN.
• Tính đến tháng 11 năm 2026, chỉ khoảng 7,1% các tên miền được đánh giá có chữ ký DNSSEC hợp lệ, hạn chế phạm vi phát hiện.
• Các resolver đệ quy tự host như Unbound cũng dễ bị tổn thương nếu chúng chuyển tiếp truy vấn qua UDP dạng văn bản thuần trên cổng 53.

Bối cảnh

Phân giải DNS truyền thống dựa vào cổng UDP 53, một giao thức được thiết kế cho tốc độ hơn là bảo mật. Nó không xác minh danh tính của bên phản hồi hay tính toàn vẹn của dữ liệu. Khi bạn cấu hình thiết bị để sử dụng một máy chủ DNS cụ thể, hệ điều hành của bạn gửi yêu cầu đến địa chỉ IP đó. Tuy nhiên, nếu không có mã hóa, bất kỳ router hoặc tường lửa nào giữa thiết bị của bạn và resolver dự kiến đều có thể đọc truy vấn và chèn một câu trả lời giả. Điều này được gọi là DNS hijacking hoặc spoofing.

Các giao thức DNS mã hóa như DoH và DoT bọc các truy vấn này trong TLS, tương tự như cách HTTPS bảo vệ duyệt web. Điều này ngăn các nhà vận hành mạng nhìn thấy hoặc thay đổi nội dung của truy vấn. Tuy nhiên, mức độ áp dụng chưa phổ biến. Nhiều cấu hình tự host vẫn dựa vào chuyển tiếp dạng văn bản thuần vì tính đơn giản hoặc tương thích. Ngoài ra, DNSSEC thêm một lớp xác thực mật mã để đảm bảo tính toàn vẹn dữ liệu, nhưng nó yêu cầu cả chủ sở hữu tên miền ký các bản ghi và resolver xác thực chúng. Với chỉ một tỷ lệ nhỏ các tên miền hỗ trợ DNSSEC, đây vẫn là một lá chắn chưa hoàn chỉnh chống lại hành vi hijacking.

Tại sao điều này quan trọng

Đối với các đội ngũ chạy phần mềm tự host, phân giải DNS đáng tin cậy là nền tảng. Nếu ISP của bạn hijack DNS, các dịch vụ nội bộ của bạn có thể không kết nối được với các API bên ngoài, kho lưu trữ gói tin hoặc máy chủ cập nhật. Nghiêm trọng hơn, bạn có thể bị dẫn đến các máy chủ độc hại do kẻ chặn đứng kiểm soát. Mặc dù các ISP thường tuyên bố đây là để lọc hoặc cache, nhưng sự thiếu minh bạch có nghĩa là bạn không thể tin tưởng vào định tuyến. Các công cụ giám sát tiêu chuẩn có thể báo cáo dịch vụ là "xuống" (down) khi chúng chỉ đơn giản là không thể truy cập do phân giải DNS sai, dẫn đến lãng phí thời gian khắc phục sự cố.

Hơn nữa, việc phụ thuộc vào các resolver công cộng mà không mã hóa tạo ra cảm giác an toàn giả tạo. Quản trị viên hệ thống thường giả định rằng việc trỏ tường lửa hoặc router của họ đến 1.1.1.1 sẽ bảo mật lưu lượng DNS của họ. Sự cố này chứng minh giả định đó là sai. Nếu ISP của bạn đủ quyết liệt để chặn lưu lượng cổng 53 trên toàn cầu, lựa chọn resolver upstream của bạn là không liên quan trừ khi bạn thực thi mã hóa ở rìa mạng của mình. Điều này ảnh hưởng đến mọi thứ, từ điều phối container đến các tác vụ cron đơn giản fetch dữ liệu bên ngoài.

Bạn có thể làm gì

• Kiểm tra hành vi hijacking bằng cách so sánh kết quả dig dạng văn bản thuần với một điểm cuối DoH như của Cloudflare cho một tên miền đang gặp lỗi.
• Xác minh quyền sở hữu các địa chỉ IP đáng ngờ bằng cách tra cứu WHOIS để xác nhận xem chúng có thuộc về ISP của bạn hay không.
• Triển khai DNS over HTTPS hoặc DNS over TLS trên resolver cục bộ của bạn, chẳng hạn như cấu hình AdGuard Home với dnscrypt-proxy.
• Tránh sử dụng cổng 5353 cho các proxy DNS mã hóa để ngăn xung đột với các dịch vụ multicast DNS như Avahi.
• Cấu hình Unbound để chuyển tiếp truy vấn qua TLS bằng cách chỉ định forward-tls-upstream: yes và cung cấp một bundle CA.
• Sử dụng các công cụ như OONI để thực hiện đo lường độc lập nếu bạn nghi ngờ có sự can thiệp mạng rộng hơn ngoài DNS.