Khi các tiêu chuẩn phân giải tên miền mã hóa như DNS-over-HTTPS (DoH, RFC 8484) và DNS-over-TLS (DoT, RFC 7858) được triển khai rộng rãi, mục tiêu ban đầu là bảo vệ đoạn truyền tải giữa thiết bị đầu cuối và máy chủ phân giải đệ quy. Những giao thức này đã ngăn chặn thành công các tác nhân nghe lén trên Wi-Fi công cộng hoặc nhà cung cấp dịch vụ mạng (ISP) đọc lén truy vấn DNS truyền dưới dạng văn bản thuần qua cổng UDP 53.

Dù vậy, DoH truyền thống lại dẫn tới một nghịch lý bảo mật mới: tập trung toàn bộ dữ liệu giám sát vào tay các nhà cung cấp máy chủ phân giải tập trung. Khi thiết bị gửi yêu cầu DoH tới các dịch vụ phân giải công cộng (như Cloudflare, Google Public DNS hay Quad9), máy chủ phân giải sẽ biết được hai thông tin cực kỳ nhạy cảm cùng một lúc:

  1. Ai đang hỏi: Địa chỉ IP công cộng của thiết bị.
  2. Hỏi điều gì: Chính xác tên miền mà người dùng chuẩn bị truy cập.

Sự tập trung thông tin này thúc đẩy Nhóm Chuyên trách Kỹ thuật Internet (IETF) chuẩn hóa giao thức Oblivious DNS over HTTPS (ODoH, RFC 9230) và khung kiến trúc Oblivious HTTP (OHTTP, RFC 9458). Dù ODoH đưa ra cơ chế thông minh để tách rời địa chỉ IP khỏi nội dung truy vấn, nhiều người vẫn lầm tưởng rằng ODoH có thể thay thế hoàn toàn mạng riêng ảo (VPN).

Phân tích sâu về nguyên lý hoạt động của ODoH sẽ làm sáng tỏ vì sao mô hình proxy hai chặng này giải quyết được vấn đề tại máy chủ phân giải, nhưng lại để lộ toàn bộ lưu lượng web thực tế nếu không có đường hầm bảo vệ ở tầng mạng.

Nguyên lý cấu trúc của Oblivious DoH: Tách rời danh tính và dữ liệu

Nguyên tắc cốt lõi của Oblivious DoH rất rõ ràng: không một thực thể đơn lẻ nào được phép nắm giữ đồng thời cả danh tính người dùng và nội dung truy vấn tên miền.

Để cắt đứt mối liên kết giữa địa chỉ IP máy khách và truy vấn DNS, RFC 9230 thiết lập kiến trúc ba thành phần gồm Máy khách (Client), Máy chủ chuyển tiếp (Relay) và Máy chủ mục tiêu (Target):

[ Thiết bị máy khách ]
         |
         | 1. Gửi truy vấn mã hóa HPKE tới Relay
         v
[ Máy chủ chuyển tiếp ODoH Relay ] (Biết IP máy khách, không thể đọc nội dung)
         |
         | 2. Tách IP máy khách, chuyển tiếp bản mã tới Target
         v
[ Máy chủ mục tiêu ODoH Target ]   (Giải mã truy vấn, thấy tên miền, không biết IP máy khách)
         |
         | 3. Phân giải DNS, mã hóa phản hồi theo ngữ cảnh HPKE
         +-----> Gửi lại cho Relay -----> Gửi về Thiết bị máy khách

1. Mã hóa khóa công khai lai (HPKE)

Trước khi phát đi truy vấn, máy khách lấy cấu hình khóa công khai của máy chủ Target (odohconfig) thông qua kênh phát hiện HTTPS hoặc danh mục ủy thác đáng tin cậy.

Sử dụng thuật toán mã hóa khóa công khai lai (HPKE, RFC 9180), máy khách đóng gói toàn bộ gói tin truy vấn DNS nhị phân bên trong một khóa đối xứng tạm thời được dẫn xuất từ khóa công khai của Target. Gói tin sau đó được gửi tới trạm chuyển tiếp Relay.

2. Vai trò chuyển tiếp vô can (Oblivious Relay)

Máy chủ Relay tiếp nhận bao thư mã hóa thông qua phiên HTTPS tiêu chuẩn. Do Relay không sở hữu khóa riêng tư của Target, nó hoàn toàn không có khả năng giải mã nội dung bên trong.

Relay hoạt động như một đại lý chuyển mạch: nó bóc tách địa chỉ IP nguồn ban đầu khỏi tiêu đề truyền vận, thay thế bằng địa chỉ IP của chính Relay rồi chuyển gói dữ liệu mã hóa tới máy chủ Target.

3. Máy chủ mục tiêu xử lý truy vấn (Target Resolver)

Máy chủ Target tiếp nhận gói dữ liệu từ Relay. Vì gói tin đến từ địa chỉ IP của Relay, Target hoàn toàn không biết nguồn gốc máy khách thực tế ở đâu.

Target dùng khóa riêng của mình để giải mã truy vấn, tiến hành phân giải tên miền từ hệ thống máy chủ có thẩm quyền, mã hóa câu trả lời bằng ngữ cảnh HPKE đã thỏa thuận, rồi gửi ngược lại qua Relay về cho máy khách.

Nhờ chuỗi xử lý tách biệt này: Relay biết bạn là ai nhưng không biết bạn hỏi gì; Target biết bạn hỏi gì nhưng không biết bạn là ai.

Các điểm hạn chế cốt tử của Oblivious DoH

Mặc dù ODoH là bước tiến xuất sắc trong mật mã học dành riêng cho DNS, việc đánh giá toàn diện trên toàn bộ vòng đời kết nối mạng chỉ ra những giới hạn vật lý không thể vượt qua:

1. Kết nối web thực tế vẫn để lộ địa chỉ IP

Truy vấn DNS chỉ là bước chuẩn bị sơ bộ. Sau khi nhận được địa chỉ IP phân giải thành công từ ODoH, hệ điều hành của thiết bị bắt đầu thiết lập kết nối TCP hoặc QUIC trực tiếp tới máy chủ web đích.

Khoảnh khắc kết nối đó diễn ra, thiết bị gửi thẳng các gói tin IP mang địa chỉ IP thật của người dùng tới máy chủ trang web. Đồng thời, nếu trang web đích chưa hỗ trợ Encrypted Client Hello (ECH), trường mở rộng SNI vẫn phát ra dưới dạng văn bản thuần trên mạng nội bộ.

ODoH ngăn chặn máy chủ phân giải DNS lập hồ sơ theo dõi, nhưng trang web đích, các mạng quảng cáo và nhà mạng viễn thông trung gian vẫn nhìn thấy từng gói tin bạn trao đổi.

2. Nguy cơ từ sự thông đồng giữa Relay và Target

Tính bảo mật của chuẩn RFC 9230 phụ thuộc hoàn toàn vào giả định rằng nhà vận hành Relay và Target không cấu kết với nhau.

Nếu Relay và Target thuộc cùng một tập đoàn hạ tầng hoặc chia sẻ nhật ký viễn thông qua các kênh hậu trường, họ có thể dễ dàng đối chiếu mốc thời gian và kích thước gói tin ra vào để tái tạo lại danh tính người dùng.

3. Gia tăng độ trễ và sai lệch định tuyến địa lý

Việc định tuyến truy vấn DNS qua hai thực thể mạng độc lập làm tăng đáng kể thời gian khứ hồi (RTT). Một truy vấn DoH thông thường chỉ mất một chặng mạng; ODoH đòi hỏi hai chặng liên tiếp qua các hệ thống tự trị (AS) khác nhau.

Thêm vào đó, vì máy chủ Target chỉ nhìn thấy IP của Relay, nó không thể dùng tiện ích EDNS Client Subnet (ECS) để tối ưu khoảng cách địa lý mà không vi phạm quyền riêng tư. Do đó, máy chủ tên miền có thể trả về địa chỉ IP của máy chủ CDN gần với Relay thay vì gần với vị trí thực của người dùng, làm giảm tốc độ truyền phát video hoặc tải tệp.

Bảng so sánh kỹ thuật: Các giao thức DNS và Đường hầm Layer 3

Sự khác biệt căn bản nằm giữa cơ chế proxy ở tầng ứng dụng (Layer 7) và sự đóng gói toàn diện ở tầng mạng (Layer 3):

Tiêu chí đánh giá DNS không mã hóa (UDP 53) DoH tiêu chuẩn (RFC 8484) Oblivious DoH (RFC 9230) Đường hầm VPN Layer 3 (RiceGuard)
Bảo vệ trước ISP cục bộ Hoàn toàn công khai Mã hóa (Được ẩn) Mã hóa (Được ẩn) Mã hóa trong đường hầm
Máy chủ biết IP máy khách Có (Thấy IP trực tiếp) Có (Thấy IP trực tiếp) Không (Chỉ thấy IP Relay) Không (Chỉ thấy IP VPN Gateway)
Máy chủ biết nội dung hỏi Có (Văn bản thuần) Có (Lưu trong bộ nhớ) Có (Giải mã xử lý) Chỉ xử lý trên Loopback nội bộ
Bảo vệ lưu lượng web thật Không (Chỉ cho DNS) Không (Chỉ cho DNS) Không (Chỉ cho DNS) Bảo vệ toàn bộ TCP/UDP/ICMP
Trang web đích thấy IP thật Có (Thấy IP thực) Có (Thấy IP thực) Có (Thấy IP thực) Không (Ẩn sau IP VPN Gateway)
Mức độ ảnh hưởng độ trễ Rất thấp (1 RTT UDP) Thấp (1 RTT TLS) Trung bình (2 chặng độc lập) Cực thấp (Định tuyến trực tiếp L3)
Ngăn chặn DPI mạng nội bộ Hoàn toàn không Chỉ ẩn được DNS Chỉ ẩn được DNS Bảo vệ toàn diện gói tin & siêu dữ liệu

Vì sao bảo mật mạng đòi hỏi giải pháp ảo hóa tầng Layer 3

Việc chắp vá sự riêng tư bằng cách ghép nối nhiều giao thức tầng ứng dụng riêng lẻ (như DoH, ODoH và tiện ích mở rộng proxy) tạo ra những lỗ hổng kiến trúc khó lường. Mỗi giao thức chỉ bảo vệ phần dữ liệu của riêng nó, trong khi các gói tin lân cận—như ARP, tiêu đề IP, thông báo lỗi ICMP và các phiên web tiếp theo—vẫn rò rỉ ra mạng vật lý.

Mạng riêng ảo Layer 3 xử lý bài toán quyền riêng tư ngay từ gốc rễ hạ tầng:

  1. Che giấu địa chỉ IP nhất quán: Mọi gói tin rời khỏi thiết bị—từ truy vấn tên miền, đồng bộ ứng dụng chạy ngầm đến tải tệp tin lớn—đều được bọc trong tiêu đề mã hóa mới trỏ duy nhất tới máy chủ VPN Gateway.
  2. Xử lý DNS khép kín tại máy chủ biên: Với kiến trúc hiện đại như RiceGuard, việc phân giải tên miền đệ quy diễn ra trực tiếp trên giao diện loopback nội bộ của cổng thoát VPN. Yêu cầu DNS không bao giờ đi qua trạm trung chuyển trung gian bên ngoài. Truy vấn đệ quy xuất phát từ địa chỉ IP dùng chung của cổng VPN, tách rời danh tính người dùng mà không cần gánh chịu độ trễ của mô hình hai chặng.
  3. Bảo vệ trên toàn hệ thống: Trong khi ODoH yêu cầu từng ứng dụng hoặc trình duyệt phải tự cấu hình hỗ trợ, đường hầm Layer 3 hoạt động ở cấp độ nhân hệ điều hành thông qua giao diện mạng ảo (tun/tap), tự động bảo vệ tất cả ứng dụng, dòng lệnh và dịch vụ nền.

Kiến trúc bảo vệ toàn diện của VPNRice

Các kỹ sư mạng đều thấu hiểu rằng những giao thức như ODoH là thành tựu nghiên cứu giá trị, nhưng bảo mật thực tế đòi hỏi một cấu trúc bảo vệ đồng bộ từ tầng vật lý đến tầng ứng dụng.

Khi kích hoạt VPNRice, người dùng được bảo vệ trong một kiến trúc mạng khép kín:

Tại tầng truyền tải, giao thức RiceGuard độc quyền thiết lập đường hầm mã hóa bảo mật với thuật toán ChaCha20-Poly1305. Nhà mạng cục bộ và các tác nhân trên Wi-Fi chỉ quan sát thấy một luồng dữ liệu UDP đồng nhất hướng tới cụm máy chủ Anycast.

Toàn bộ truy vấn tên miền từ hệ điều hành được tự động gom vào đường hầm và phân giải an toàn bởi hệ thống máy chủ nội bộ không lưu nhật ký của VPNRice. Bằng cách giấu kín địa chỉ IP cho cả giai đoạn phân giải DNS lẫn toàn bộ kết nối web phía sau, VPNRice hiện thực hóa mục tiêu tách biệt danh tính của ODoH trên phạm vi toàn bộ lưu lượng Internet của bạn. Tải VPNRice.