Hệ thống tên miền (DNS) đóng vai trò nền tảng điều hướng trên internet, chuyển đổi tên miền dạng chữ sang địa chỉ IP đích. Suốt nhiều thập kỷ, giao thức truyền tải chủ đạo cho các truy vấn DNS là UDP qua cổng 53. Mặc dù UDP giảm thiểu độ trễ nhờ loại bỏ bước bắt tay ba bước, thiết kế không kết nối của giao thức này lại tạo ra điểm yếu cố hữu: giả mạo địa chỉ IP nguồn. Tin tặc liên tục lợi dụng máy chủ phân giải đệ quy và máy chủ tên miền có thẩm quyền để phát động các đợt tấn công từ chối dịch vụ phân tán (DDoS) phản xạ khuếch đại và đầu độc bộ nhớ đệm ngoài luồng. RFC 7873 ("Domain Name System (DNS) Cookies") cùng bản chuẩn hóa cập nhật RFC 9018 ("Interoperable Domain Name System (DNS) Server Cookies") đã thiết lập một cơ chế mật mã nhẹ, không lưu trạng thái trong phần mở rộng EDNS(0) nhằm xác thực tính hai chiều giữa máy trạm và máy chủ DNS.

Truy vấn UDP thông thường (Dễ bị giả mạo nguồn):
Kẻ tấn công (Giả mạo IP nạn nhân) ─── Truy vấn ───> Máy chủ DNS
Nạn nhân <────── Gói tin phản hồi khuếch đại ────── Máy chủ DNS

Truy vấn bảo vệ bằng DNS Cookie (RFC 7873 / RFC 9018):
Máy trạm ─────── Truy vấn + Client Cookie (8B) ──────> Máy chủ DNS
Máy trạm <── Phản hồi + Client Cookie + Server Cookie ── Máy chủ DNS
(Xác minh danh tính hai chiều; gói tin giả mạo bị loại bỏ hoặc giới hạn)

Khủng hoảng khuếch đại UDP: Vì sao DNS truyền thống thiếu an toàn

Các gói tin truy vấn DNS tiêu chuẩn truyền qua UDP không chứa bằng chứng xác thực danh tính người gửi. Khi máy chủ tên miền tiếp nhận yêu cầu, hệ thống chỉ kiểm tra trường địa chỉ nguồn trong tiêu đề gói tin IP. Vì UDP không thực hiện quy trình kiểm tra khả năng định tuyến hai chiều trước khi gửi dữ liệu, kẻ tấn công có thể dễ dàng phát các gói tin truy vấn chứa địa chỉ IP nguồn giả mạo trỏ về nạn nhân mục tiêu.

Giao vận không trạng thái và giả mạo địa chỉ IP nguồn

Sự chênh lệch kích thước giữa gói truy vấn ngắn và gói phản hồi mật mã đồ sộ tạo ra hệ số khuếch đại lưu lượng rất cao. Một yêu cầu chỉ 64 byte hỏi bản ghi ANY, tập bản ghi DNSSEC (RRSIG và DNSKEY) hoặc bản ghi TXT dung lượng lớn thường tạo ra gói phản hồi vượt quá 3.000 byte. Khi các nhà mạng trung gian không áp dụng cơ chế lọc địa chỉ nguồn (BCP 38 / RFC 2827), kẻ tấn công làm tràn băng thông của nạn nhân bằng cách điều hướng luồng phản hồi từ hàng ngàn máy chủ phân giải mở.

Các cuộc tấn công đầu độc bộ nhớ đệm ngoài luồng cũng khai thác triệt để lỗ hổng này. Bằng cách dự đoán mã định danh giao dịch (Transaction ID) và cổng nguồn UDP, kẻ tấn công có thể gửi các bản ghi giả mạo vào bộ nhớ đệm trước khi câu trả lời thực sự từ máy chủ có thẩm quyền kịp gửi về. DNSSEC giúp xác minh tính toàn vẹn của nội dung nhưng không thể xác thực máy trạm gửi yêu cầu cũng như không ngăn được tình trạng lạm dụng phản xạ khuếch đại.

Chi phí và sự mong manh của giới hạn tốc độ phản hồi RRL

Để kiềm chế các đợt tấn công phản xạ, các nhà vận hành máy chủ đã triển khai cơ chế Giới hạn tốc độ phản hồi (RRL). RRL thống kê lưu lượng theo tiền tố IP của máy trạm (/24 đối với IPv4 hoặc /56 đối với IPv6), sau đó loại bỏ hoặc cắt ngắn (TC=1) các phản hồi vượt quá ngưỡng tần suất cho phép.

Mặc dù RRL giảm bớt tổng lưu lượng tấn công, giải pháp này phát sinh nhiều nhược điểm vận hành:

  • Máy trạm nằm sau cổng chuyển đổi địa chỉ mạng của nhà mạng (CGNAT) dùng chung tiền tố IP với các thiết bị nhiễm mã độc, dẫn đến việc bị đánh rơi gói tin hợp lệ.
  • Máy chủ buộc máy trạm chuyển sang giao thức TCP, làm tăng độ trễ mạng do bắt tay ba bước và tiêu tốn tài nguyên quản lý socket của nhân hệ điều hành.
  • Các máy chủ phân giải đệ quy lưu lượng lớn dễ kích hoạt nhầm ngưỡng giới hạn, gây gián đoạn kết nối hàng loạt cho các ứng dụng người dùng.

DNS Cookies xử lý triệt để bài toán này bằng cách cung cấp bằng chứng định tuyến hai chiều mà không đòi hỏi máy chủ phải duy trì bảng trạng thái kết nối phức tạp.

RFC 7873 tích hợp trường nhận diện mật mã vào Cơ chế mở rộng cho DNS (EDNS(0), RFC 6891) dưới mã tùy chọn Option Code 10.

+-------------------------------+-------------------------------+
|       OPTION-CODE (10)        |     OPTION-LENGTH (16-40)     |
+-------------------------------+-------------------------------+
|                    Client Cookie (8 Octet)                    |
+---------------------------------------------------------------+
|                    Server Cookie (8-32 Octet)                 |
+---------------------------------------------------------------+

Giao thức vận hành theo quy trình trao đổi hai bước giữa máy trạm DNS (trình phân giải stub hoặc đệ quy) và máy chủ DNS (máy chủ đệ quy hoặc có thẩm quyền).

Client Cookie là một chuỗi giả ngẫu nhiên 8 byte do máy trạm khởi tạo. Chuỗi này phải khó đoán đối với các bên theo dõi ngoài luồng nhưng có thể tính toán lại một cách nhất quán cho một địa chỉ máy chủ cụ thể trong một khoảng thời gian nhất định:

$$\text{Client Cookie} = \text{PRF-64}(\text{Client IP}, \text{Server IP}, \text{Client Secret})$$

Khóa bí mật của máy trạm chứa 128 bit entropy mật mã được lưu trên bộ nhớ RAM. Việc định kỳ luân chuyển khóa này (thông thường mỗi 24 giờ) sẽ vô hiệu hóa các cookie cũ mà không cần ghi vào bộ nhớ lưu trữ cố định. Việc ràng buộc cả IP máy trạm lẫn IP máy chủ ngăn chặn việc kẻ tấn công lấy cắp cookie để phát lại sang máy chủ khác.

Khi máy chủ tên miền tiếp nhận truy vấn chứa Client Cookie, quy trình xác thực diễn ra như sau:

  1. Truy vấn khởi đầu: Máy trạm chỉ gửi Client Cookie 8 byte của mình. Độ dài trường tùy chọn Option Length bằng 8.
  2. Tính toán tại máy chủ: Máy chủ nhận biết đây là lượt khởi tạo, tiến hành tạo một Server Cookie gắn liền với Client Cookie, địa chỉ IP của máy trạm và khóa bí mật nội bộ của máy chủ.
  3. Phản hồi kèm Cookie kép: Máy chủ đính kèm cả Client Cookie lẫn Server Cookie vừa tạo vào bản ghi EDNS(0) OPT trong gói tin phản hồi.
  4. Lưu đệm tại máy trạm: Máy trạm kiểm tra tính khớp nối của Client Cookie nhận về, sau đó lưu Server Cookie vào bộ nhớ đệm liên kết với IP của máy chủ.
  5. Các truy vấn kế tiếp: Mọi truy vấn tiếp theo sẽ gửi đồng thời cả hai cookie (tổng độ dài 16 đến 40 byte). Máy chủ chỉ cần tính toán lại chuỗi băm để xác thực máy trạm ngay lập tức.

Vì kẻ tấn công giả mạo IP không thể nhận được gói tin phản hồi từ máy chủ, chúng không thể thu thập được Server Cookie hợp lệ, từ đó vô hiệu hóa hoàn toàn kỹ thuật tấn công khuếch đại.

Trước khi RFC 9018 ra đời, định dạng cấu trúc bên trong của Server Cookie do từng nhà phát triển tự quyết định. Trong các hệ thống hạ tầng mạng Anycast chạy song song nhiều phần mềm DNS khác nhau (như BIND, NSD, Knot DNS hay PowerDNS), sự bất đồng bộ định dạng khiến các nút mạng không thể hiểu cookie do phần mềm khác tạo ra.

RFC 9018 đã khắc phục nhược điểm này bằng cách quy chuẩn hóa định dạng Server Cookie cố định 16 octet.

+---------------+---------------+-------------------------------+
| Version (0x01)|       Reserved (0x000000)                     |
+---------------+---------------+-------------------------------+
|                      Timestamp (4 Octet)                      |
+---------------------------------------------------------------+
|                      Hash (8 Octet)                           |
+---------------------------------------------------------------+

Các trường thông tin bao gồm:

  • Version (1 octet): Định danh phiên bản công thức tính toán; cố định ở giá trị 0x01.
  • Reserved (3 octet): Thiết lập giá trị 0x000000 khi truyền đi và bỏ qua khi tiếp nhận.
  • Timestamp (4 octet): Số nguyên không dấu 32-bit ghi lại mốc thời gian UNIX epoch tính theo giây.
  • Hash (8 octet): Chuỗi mã xác thực mật mã rút gọn 64-bit.

Cấu trúc SipHash-2-4 và chuỗi băm 64-bit rút gọn

RFC 9018 chuẩn hóa hàm giả ngẫu nhiên SipHash-2-4 để tạo trường Hash 8 byte. Thuật toán SipHash-2-4 nổi tiếng với tốc độ xử lý vượt trội trên dữ liệu đầu vào ngắn, khả năng chống tấn công băm xung đột (hash-flooding) và tối ưu hóa xử lý trên kiến trúc vi xử lý 64-bit.

Giá trị băm được tính toán theo biểu thức:

$$\text{Hash} = \text{SipHash-2-4}(\text{Server Secret}, \text{Client Cookie} ,|, \text{Version} ,|, \text{Reserved} ,|, \text{Timestamp} ,|, \text{Client IP})$$

Máy chủ thực hiện hai bước kiểm tra an toàn:

  1. Kiểm tra độ tươi của mốc thời gian: Xác nhận chênh lệch $|T_{\text{hiện tại}} - T_{\text{cookie}}| \le 3600 \text{ giây}$. Cửa sổ 1 giờ này giúp mạng hấp thụ độ trễ đường truyền và lệch xung đồng hồ, đồng thời ngăn ngừa nguy cơ phát lại gói tin cũ.
  2. Kiểm tra chữ ký mật mã: Tính toán lại giá trị SipHash-2-4 bằng khóa bí mật đang hoạt động và so sánh với trường Hash nhận được trong thời gian thực thi cố định (constant time).

Khi truy vấn hợp lệ, máy chủ miễn trừ áp dụng các hạn chế của cơ chế RRL và phản hồi toàn bộ dữ liệu theo kích thước bộ đệm EDNS đã thỏa thuận.

Xử lý định tuyến Anycast và luân chuyển khóa bí mật

Hạ tầng DNS hiện đại vận hành trên nền tảng BGP Anycast, phát quảng bá một dải IP từ hàng trăm điểm kết nối biên (PoP) trên khắp thế giới. Định tuyến mạng có thể chuyển hướng các gói tin kế tiếp sang một nút vật lý khác trong cùng một phiên làm việc.

Để duy trì tính liên tục của quá trình xác thực, tất cả các nút máy chủ trong cụm Anycast bắt buộc phải đồng bộ khóa bí mật chung. Quản trị viên cấu hình cơ chế khóa đối xứng kép:

  • Khóa chính ($K_{\text{active}}$): Sử dụng để tạo Server Cookie mới trong các phản hồi gửi đi và xác thực các cookie gửi đến.
  • Khóa phụ ($K_{\text{previous}}$): Duy trì trong giai đoạn chuyển đổi khóa (từ 2 đến 24 giờ) để tiếp tục chấp nhận các cookie được tạo từ phiên bản khóa trước đó.

Khi thực hiện luân chuyển khóa, khóa mới được đưa vào hệ thống dưới dạng khóa tương lai, sau đó kích hoạt thành khóa chính và chuyển khóa cũ xuống làm khóa phụ. Quy trình này bảo đảm các truy vấn của người dùng không bao giờ bị gián đoạn giữa các nút Anycast.

Xử lý sự cố BADCOOKIE và cơ chế tương thích ngược

Trong trường hợp máy chủ gặp phải một truy vấn chứa Server Cookie hết hạn, sai định dạng hoặc không hợp lệ, quy trình khôi phục theo RFC 7873 sẽ được kích hoạt:

  1. Ngăn chặn phản xạ: Máy chủ từ chối trả về tập dữ liệu trả lời hoàn chỉnh.
  2. Phát tín hiệu lỗi: Tạo gói tin phản hồi rỗng chứa mã lỗi RCODE=9 (BADCOOKIE) và giữ nguyên mã định danh giao dịch.
  3. Cung cấp Cookie mới: Đính kèm một bản ghi EDNS(0) OPT chứa Client Cookie cũ của máy trạm cùng một Server Cookie mới được tạo hợp lệ.
  4. Gửi lại truy vấn: Máy trạm nhận diện mã BADCOOKIE, cập nhật cookie mới vào bộ nhớ đệm và phát lại yêu cầu ban đầu.

Nếu thiết bị tường lửa trung gian vô tình cắt bỏ các tùy chọn EDNS(0), máy trạm sẽ nhận biết việc thiếu vắng cookie trong phản hồi và tự động quay về chế độ truy vấn DNS tiêu chuẩn, bảo đảm kết nối thông suốt.

Tích hợp cùng RiceGuard: Kiến trúc DNS Zero-Trust và bảo vệ lưu lượng ra

Hệ thống mạng an toàn RiceGuard trong ứng dụng VPNRice kết hợp chặt chẽ cơ chế DNS Cookies từ thiết bị đầu cuối cho đến các máy chủ phân giải biên nhằm xây dựng mô hình mạng Zero-Trust toàn diện.

Kiến trúc DNS Zero-Trust của RiceGuard:
Thiết bị người dùng (Ứng dụng VPNRice)
  │
  ├── Đường hầm mã hóa WireGuard / IPsec (ChaCha20-Poly1305 / AES-256-GCM)
  ▼
Nút biên Anycast RiceGuard
  │  - Xác thực RFC 9018 Server Cookies trên mọi gói tin UDP
  │  - Loại bỏ các đợt thăm dò phản xạ giả mạo trước khi vào lõi
  │  - Đồng bộ khóa SipHash-2-4 trên toàn mạng lưới Anycast toàn cầu
  ▼
Cụm phân giải đệ quy kiên cố hóa
  │  - Tự động bổ sung Client Cookie khi truy vấn máy chủ gốc và TLD
  │  - Xác thực Server Cookie trên các luồng phản hồi từ máy chủ ngoài
  │  - Kiểm tra chữ ký mật mã DNSSEC nghiêm ngặt
  ▼
Hạ tầng máy chủ tên miền internet
  1. Bảo vệ đường hầm khép kín: Mọi truy vấn từ thiết bị người dùng đều được đóng gói trong đường hầm WireGuard hoặc IPsec chuyển thẳng về cụm Anycast chuyên dụng của RiceGuard, ngăn chặn nguy cơ nghe lén trên mạng Wi-Fi công cộng và nhà mạng viễn thông.
  2. Lá chắn cổng biên: Giao diện tiếp nhận Anycast thực thi nghiêm ngặt Server Cookie theo RFC 9018 đối với các luồng UDP. Gói tin giả mạo bị chặn đứng hoặc đưa vào diện kiểm soát, giữ cho hạ tầng luôn ổn định.
  3. An toàn tầng đệ quy: Khi tìm kiếm bản ghi từ máy chủ gốc (Root) và máy chủ tên miền cấp cao nhất (TLD), hệ thống RiceGuard chủ động gắn Client Cookie và kiểm tra Server Cookie trả về, bảo vệ kho đệm đệ quy trước các kỹ thuật tấn công chèn bản ghi độc hại.

Sự kết hợp giữa mã hóa đường truyền và xác thực giao vận DNS Cookies mang lại khả năng định tuyến đáng tin cậy và liền mạch trên mọi môi trường kết nối.

Kiểm tra thực tế: Xác thực DNS Cookies bằng lệnh Dig

Quản trị viên hệ thống có thể dễ dàng kiểm tra tính tương thích của máy chủ với chuẩn DNS Cookies thông qua công cụ dig.

Các phiên bản dig hiện đại tự động đính kèm Client Cookie khi gửi truy vấn:

# Gửi truy vấn kiểm tra cookie đến máy chủ Anycast
dig @1.1.1.1 vpnrice.com +cookie

Kết quả phản hồi hiển thị trường COOKIE trong khối OPT PSEUDOSECTION:

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 5a8e2b109c3d4f8a 01000000672c8410d9f82e14a7c3b901 (good)
;; QUESTION SECTION:
;vpnrice.com.			IN	A

;; ANSWER SECTION:
vpnrice.com.		300	IN	A	104.21.48.12

Giải thích chi tiết:

  • 5a8e2b109c3d4f8a là Client Cookie 8 byte do máy trạm tạo ra.
  • 01000000672c8410d9f82e14a7c3b901 là Server Cookie 16 byte chuẩn RFC 9018:
    • Phiên bản: 01
    • Trường dự phòng: 000000
    • Mốc thời gian: 672c8410 (dạng thập lục phân)
    • Giá trị băm: d9f82e14a7c3b901 (kết quả thuật toán SipHash-2-4)
  • Trạng thái (good) xác nhận quá trình thẩm tra mật mã đã thành công mỹ mãn.

Quản trị viên có thể thử nghiệm khả năng phòng vệ bằng cách cố ý gửi đi một Server Cookie bị hỏng:

# Truyền Server Cookie giả mạo dài 16 byte
dig @1.1.1.1 vpnrice.com +cookie=5a8e2b109c3d4f8a0100000000000000ffffffffffffffff

Máy chủ tên miền đạt chuẩn RFC 9018 sẽ trả về trạng thái status: BADCOOKIE, không gửi kèm bản ghi địa chỉ và đính kèm một Server Cookie mới trong bản ghi OPT để máy trạm tự cập nhật ngay lập tức.

DNS Cookies là giải pháp xuất sắc giải quyết xung đột giữa tốc độ truyền tải của UDP và yêu cầu xác thực nguồn nghiêm ngặt. Việc ứng dụng rộng rãi chuẩn RFC 7873 và RFC 9018 trên toàn bộ hạ tầng đệ quy và có thẩm quyền giúp triệt tiêu nguy cơ tấn công khuếch đại lưu lượng ở mức độ giao vận mạng.

Để bảo vệ lưu lượng truy cập và trải nghiệm kết nối qua hệ thống máy chủ Anycast kiên cố hỗ trợ đầy đủ các chuẩn xác thực mới, Tải VPNRice.