DNS — An Underrated Part of Your Digital Identity

Hầu hết người dùng coi DNS như một chi tiết kỹ thuật chạy ngầm. Internet mở, các trang web tải – điều đó có nghĩa là mọi thứ đã được cấu hình đúng. Đó là lý do tại sao nhiều người chỉ thiết lập Google Public DNS (8.8.8.8) hoặc Cloudflare (1.1.1.1) một lần, hoặc thậm chí để nguyên các cài đặt tự động nhận được từ nhà cung cấp và không bao giờ bận tâm đến nó nữa. Cách tiếp cận này hoàn toàn phù hợp cho việc sử dụng internet thông thường. Nhưng khi nói đến proxy, trình duyệt chống phát hiện, tự động hóa, thu thập dữ liệu web hoặc nghiên cứu an ninh thông tin, DNS không còn là một cài đặt thứ yếu nữa. Nó trở thành một phần của danh tính trực tuyến của bạn.

Cần nhớ rằng DNS là một trong những cơ chế lâu đời nhất của internet. Nền tảng của nó được đặt ra từ đầu những năm 1980 (các RFC quan trọng 1034 và 1035 có từ năm 1987), khi mà vấn đề bảo mật và chống gian lận còn chưa được biết đến. Một yêu cầu DNS cổ điển được gửi dưới dạng văn bản thuần túy qua UDP đến cổng 53—có thể nhìn thấy được bởi cả nhà cung cấp dịch vụ internet (ISP) và bất kỳ nút trung gian nào trên đường đi. "Di sản" này đã tạo ra cả những vấn đề hiện đại và những nỗ lực giải quyết chúng, chẳng hạn như DNS mã hóa. Hiểu được bối cảnh giúp chúng ta thấy tại sao việc lựa chọn một trình phân giải lại không chỉ là vấn đề hình thức.

DNS không chỉ đơn thuần là một cuốn danh bạ điện thoại.

DNS thường được mô tả như cuốn danh bạ điện thoại của internet: tên miền được chuyển đổi thành địa chỉ IP, sau đó trình duyệt kết nối với máy chủ chính xác. Giải thích này đúng, nhưng quá đơn giản. Ngày nay, DNS được sử dụng trong cân bằng tải, chọn nút CDN gần nhất, định tuyến, đảm bảo khả năng chịu lỗi và xây dựng hồ sơ người dùng thống kê. Geo-DNS và định tuyến dựa trên độ trễ là những ví dụ điển hình. Cùng một tên miền có thể trả về các địa chỉ IP khác nhau tùy thuộc vào người yêu cầu và vị trí truy cập. Một trang web lớn được lưu trữ trên CDN sẽ trả về một máy chủ biên khi được yêu cầu thông qua máy chủ phân giải của Đức và một máy chủ biên khác thông qua máy chủ phân giải của Mỹ. Các dịch vụ như AWS Route 53 hoặc Cloudflare Load Balancing thực hiện điều này ngay từ đầu: chúng đặt TTL rất ngắn (đôi khi từ 30-60 giây) trên các bản ghi để nhanh chóng chuyển đổi lưu lượng truy cập và duy trì khả năng chịu lỗi. Cơ chế tương tự làm cho một tên miền "bền vững" cũng biến DNS thành tín hiệu thời gian thực về vị trí mà mạng tin rằng máy khách đang ở.

EDNS Client Subnet (ECS, RFC 7871) đáng được đề cập riêng. Đây là một phần mở rộng trong đó trình phân giải chuyển một phần bị cắt bớt của mạng con của máy khách đến máy chủ có thẩm quyền để CDN có thể tìm thấy một nút gần hơn. Nghe có vẻ thuần túy kỹ thuật, nhưng ý nghĩa rất đơn giản: trình phân giải của bạn có thể truyền đạt vị trí địa lý gần đúng của kết nối cho các máy chủ bên ngoài ngay cả trước khi kết nối chính được thiết lập. Các trình phân giải khác nhau hoạt động khác nhau ở đây — chúng ta sẽ quay lại vấn đề này bên dưới.

Đó là lý do tại sao các hệ thống chống gian lận hiện đại không chỉ phân tích địa chỉ IP mà còn cả cách thức phân giải tên miền được thực hiện. Ý tưởng cốt lõi của hệ thống bảo vệ hiện đại rất đơn giản: hệ thống hầu như không bao giờ đưa ra quyết định dựa trên một chỉ số duy nhất. Nó đánh giá sự kết hợp của các tín hiệu và tạo ra điểm rủi ro. Một bản ghi DNS bất thường đơn thuần không chứng minh được điều gì. Nhưng khi thêm vào đó sự không khớp múi giờ (ví dụ: hệ thống báo cáo Europe/Berlin, nhưng ngôn ngữ trình duyệt là en-US), vị trí địa lý IP, dấu vân tay thiết bị (Canvas, WebGL, bộ phông chữ) và các đặc điểm mạng, hồ sơ bắt đầu trông kém tự nhiên hơn. Mỗi chỉ số riêng lẻ đều yếu; sự kết hợp của chúng mới có trọng lượng.

Vì sao DNS công cộng không phải lúc nào cũng là lựa chọn tốt nhất

Google Public DNS và Cloudflare là những dịch vụ tuyệt vời. Chúng nhanh, ổn định và hỗ trợ các giao thức hiện đại: DNSSEC, DNS qua HTTPS và DNS qua TLS. Ví dụ, Cloudflare hoạt động như một mạng anycast ở hàng trăm thành phố, và các bài kiểm tra độc lập luôn xếp hạng trình phân giải của nó nằm trong số những trình phân giải nhanh nhất thế giới. Vấn đề không nằm ở chất lượng của chúng, mà là ở bối cảnh sử dụng.

Một điểm khác biệt tinh tế chính là hành vi với ECS. Google Public DNS gửi một mạng con máy khách bị cắt bớt đến các máy chủ có thẩm quyền (bằng cách xóa các bit ít quan trọng nhất của địa chỉ) để chọn nút CDN chính xác hơn. Cloudflare, trên 1.1.1.1, hoàn toàn không gửi ECS vì lý do bảo mật. Cả hai đều không "tốt" hay "xấu" nếu xét riêng lẻ—nhưng chúng là những câu chuyện khác nhau. Với Google, máy chủ có thẩm quyền nhận được thông tin về vị trí địa lý gần đúng của bạn; với Cloudflare, chúng không nhận được thông tin đó, nhưng việc định tuyến đến CDN có thể kém chính xác hơn. Người dùng thông thường sẽ không nhận thấy điều này. Đối với người đang xây dựng cấu hình mạng nhất quán, đây lại là một tham số khác phù hợp hoặc mâu thuẫn với phần còn lại của bức tranh tổng thể.

Có một lập luận đơn giản hơn. Hầu hết người dùng tại nhà không thay đổi DNS của họ và sử dụng máy chủ của nhà cung cấp dịch vụ Internet (ISP), được gán tự động thông qua DHCP. Do đó, nếu mục tiêu là để xuất hiện như một thuê bao thông thường của một mạng cụ thể, thì DNS của ISP thường là lựa chọn tự nhiên hơn so với máy chủ phân giải công cộng. DNS công cộng 8.8.8.8 hoặc 1.1.1.1 trong trường hợp này là dấu hiệu của cấu hình có chủ đích: chúng được chọn bởi những người đam mê công nghệ, quản trị viên và mạng lưới doanh nghiệp, chứ không phải người dùng thông thường của nhà mạng di động. Điều này không làm cho DNS công cộng trở nên "xấu". Nó chỉ kể một câu chuyện hơi khác về kết nối của bạn.

Tính nhất quán quan trọng hơn tốc độ.

Thuật ngữ "tính nhất quán" ngày càng được sử dụng nhiều trong môi trường chuyên nghiệp. Nó có nghĩa là tất cả các yếu tố của cấu hình mạng đều nhất quán. Nếu một địa chỉ IP thuộc về một nhà mạng di động của Đức, thì việc mong đợi múi giờ Đức (Europe/Berlin), ngôn ngữ hệ thống tiếng Đức hoặc tiếng Anh, và phân giải DNS thông qua cơ sở hạ tầng được kết nối hợp lý với mạng đó, thay vì thông qua một nút anycast định tuyến vật lý yêu cầu đến một lục địa khác, là điều hoàn toàn hợp lý.

Hãy tưởng tượng một sự sai lệch điển hình: địa chỉ IP thuộc về một nhà mạng di động của Đức, múi giờ của trình duyệt là Europe/Berlin, nhưng các yêu cầu DNS lại được gửi đến 8.8.8.8 và thực tế truy cập mạng thông qua điểm hiện diện của Google tại Mỹ, và ngôn ngữ giao diện được đặt là en-US. Bản thân mỗi sự kiện này không đáng báo động. Nhưng khi kết hợp lại, chúng tạo nên một bức tranh khó giải thích bằng hành vi bình thường của một người dùng thực sự. Mỗi sự sai lệch riêng lẻ không nghiêm trọng, nhưng mỗi sự sai lệch mới làm tăng khả năng hồ sơ sẽ xuất hiện bất thường. Tốc độ phân giải gần như không liên quan trong logic này: việc tiết kiệm được 10-20 mili giây không đáng để đánh đổi sự thiếu nhất quán.

Một cách tiếp cận thực tiễn

Việc lựa chọn DNS không nên bắt đầu bằng câu hỏi "máy chủ nào nhanh nhất", mà là câu hỏi "hệ thống này nên hiển thị như thế nào đối với người dùng?". Quyết định sau đó thường được chia nhỏ theo loại máy chủ proxy.

Đối với các máy chủ proxy di động và dân dụng (ISP), việc phân giải tên miền diễn ra tự nhiên nhất thông qua cơ sở hạ tầng của nhà cung cấp tương ứng—hoặc ít nhất là thông qua một trình phân giải có thể truy cập được ở phía bên kia đường hầm, chứ không phải từ máy tính thực của bạn. Nguyên tắc chính ở đây là việc phân giải DNS nên diễn ra thông qua máy chủ proxy, chứ không phải bỏ qua nó. Khi đó, cả vị trí địa lý của yêu cầu và gợi ý ECS (nếu được truyền đi) sẽ khớp với địa chỉ IP của nguồn lưu lượng chính.

Đối với máy chủ trung tâm dữ liệu, tính nhất quán nội bộ của toàn bộ cấu hình quan trọng hơn việc cố gắng mô phỏng kết nối internet tại nhà. Sẽ không ai ngạc nhiên nếu một trung tâm dữ liệu sử dụng, chẳng hạn như Cloudflare hoặc trình phân giải riêng của nó—nhưng nếu toàn bộ hệ thống các nút hoạt động đồng nhất, có thể dự đoán được và không bị rò rỉ, đó đã là một bức tranh ổn định, hoặc, theo một nghĩa tốt, là "nhàm chán". Không có giải pháp chung nào ở đây: câu trả lời đúng không được xác định bởi xếp hạng tốc độ, mà bởi khả năng mà hệ thống phải hỗ trợ.

Rò rỉ DNS và các trình duyệt hiện đại

Rò rỉ DNS thường được hiểu là xảy ra khi các yêu cầu DNS đi theo một đường dẫn khác với lưu lượng truy cập chính. Ví dụ, HTTP đi qua máy chủ proxy, trong khi DNS vẫn được gửi trực tiếp qua nhà cung cấp dịch vụ Internet (ISP) cục bộ. Điều này dẫn đến sự không nhất quán bổ sung: trang web "nhìn thấy" một địa chỉ IP trong kết nối, trong khi máy chủ DNS có thẩm quyền trên đường đi lại thấy một nguồn yêu cầu hoàn toàn khác. Một nguồn rò rỉ điển hình như vậy là vị trí phân giải tên khi làm việc trên SOCKS5. Sự khác biệt có thể nhận thấy ngay cả ở cấp độ curl: lược đồ socks5:// buộc máy khách phải phân giải tên miền cục bộ (và yêu cầu bỏ qua máy chủ proxy), trong khi socks5h:// chuyển tên đến máy chủ proxy, máy chủ này sẽ phân giải tên đó ở phía mình. Logic tương tự cũng xảy ra trong trình duyệt: trong Firefox, điều này được kiểm soát bởi tham số network.proxy.socks_remote_dns. Nếu tham số này bị vô hiệu hóa, các tên miền sẽ được phân giải cục bộ, dẫn đến rò rỉ ngay cả khi đã cấu hình proxy đúng cách. Chi tiết cấu hình nhỏ này hoàn toàn thay đổi nơi DNS của bạn "rò rỉ".

Tình hình trở nên phức tạp hơn bởi thực tế là các trình duyệt hiện đại ngày càng sử dụng DNS qua HTTPS. Firefox trở thành trình duyệt đầu tiên bật DoH theo mặc định vào năm 2020 cho người dùng tại Mỹ; Chrome cũng bổ sung chế độ DNS an toàn trong cùng năm đó. Chrome rất cẩn trọng trong vấn đề này: nó không thay đổi nhà cung cấp DNS của bạn, mà chỉ nâng cấp trình phân giải hiện có lên phiên bản mã hóa nếu nó hỗ trợ DoH. Tuy nhiên, điều này có nhược điểm đối với những người làm việc thông qua máy chủ proxy: nếu trình duyệt tự động chuyển sang điểm cuối DoH của Cloudflare thay vì kết nối thực của bạn, DNS có thể bị rò rỉ, bỏ qua đường hầm, ngay cả khi HTTP được gửi qua proxy. Cuối cùng, trình duyệt không phải là những thứ duy nhất có cơ chế phân giải tên riêng: Android 9 trở lên hỗ trợ DNS riêng tư (DNS qua TLS), Windows 11 hỗ trợ DoH ở cấp độ hệ thống và các ứng dụng riêng lẻ triển khai việc phân giải theo cách riêng của chúng. Do đó, ngày nay, chỉ kiểm tra cài đặt hệ điều hành là chưa đủ; điều quan trọng là phải hiểu cách mỗi ứng dụng hoạt động riêng lẻ. Điều quan trọng nữa là không nên nhầm lẫn rò rỉ DNS với rò rỉ WebRTC: loại thứ hai không tiết lộ tên miền, mà là địa chỉ IP cục bộ và công cộng thông qua STUN — một kênh riêng biệt cũng cần được đóng lại.

Kết luận chính

Công tác chống gian lận đã thay đổi đáng kể trong những năm gần đây. Trước đây, trọng tâm chính là địa chỉ IP và uy tín của nó. Ngày nay, toàn bộ danh tính kỹ thuật số của người dùng được phân tích: trình duyệt, thiết bị, ngôn ngữ, múi giờ, định tuyến, hành vi của trình phân giải, rò rỉ DNS và hàng tá tín hiệu khác. Về cơ bản, đây là một mô hình xác suất kết hợp các đặc điểm yếu thành một đánh giá duy nhất — và việc đưa thêm một sự sai lệch nữa hầu như luôn tốn kém hơn số mili giây tiết kiệm được nhờ trình phân giải nhanh.

Điều này loại bỏ mục đích tìm kiếm "DNS hoàn hảo". Việc xem xét toàn bộ hệ thống sẽ hữu ích hơn nhiều. Hơn nữa, một cấu hình được tối ưu hóa quá mức, không thực tế đôi khi lại trông đáng ngờ hơn một cấu hình chuẩn: người dùng thực tế không hoàn hảo. Một cấu hình tốt không cần phải hoàn hảo – nó nên trông hợp lý và tự nhiên, và các thành phần của nó không nên mâu thuẫn với nhau. Cách tiếp cận này – tập trung vào tính nhất quán hơn là theo đuổi các thông số "tốt nhất" riêng lẻ – thường chứng tỏ tính bền vững cao nhất về lâu dài: danh tiếng được xây dựng theo thời gian, và một hồ sơ duy trì tính nhất quán sẽ giữ được chất lượng tốt nhất.