Tiện ích mở rộng bảo mật hệ thống tên miền (DNSSEC) bổ sung tính toàn vẹn và xác thực nguồn gốc cho giao thức DNS vốn ban đầu không có cơ chế bảo vệ. Bằng cách gắn chữ ký số (RRSIG) vào các tập bản ghi tài nguyên, DNSSEC giúp máy chủ phân giải phát hiện kịp thời các hành vi đầu độc bộ nhớ đệm (cache poisoning) và giả mạo địa chỉ truyền tải.

Tuy nhiên, việc thiết kế cơ chế xác thực cho các phản hồi phủ định—chứng minh một tên miền không tồn tại (NXDOMAIN) hoặc một loại bản ghi cụ thể vắng mặt (NODATA)—lại tạo ra một nghịch lý kiến trúc phức tạp. Nhằm bảo vệ khóa ký vùng riêng tư (ZSK) trước nguy cơ máy chủ có thẩm quyền bị xâm nhập, các tiêu chuẩn ban đầu yêu cầu ký ngoại tuyến. Quản trị viên ký toàn bộ vùng trước trên hệ thống cô lập và chỉ phát hành chữ ký tĩnh lên máy chủ công cộng.

Mô hình vận hành này khiến việc ký động tại thời gian thực cho các truy vấn không tồn tại là bất khả thi nếu không lưu khóa bí mật trực tuyến. Nhằm giải quyết bài toán chứng thực tĩnh, IETF đã phát triển bản ghi Next Secure (NSEC) trong RFC 4034. Dù chuẩn xác về mặt toán học, NSEC vô tình mở ra kênh phụ nguy hiểm mang tên DNSSEC Zone Walking, cho phép kẻ tấn công dò quét toàn bộ bề mặt mạng doanh nghiệp chỉ trong chớp mắt.

Nghịch lý từ chối xác thực: Lý do phản hồi phủ định làm lộ cấu trúc DNS

Trong hệ thống DNS thông thường không xác thực, máy chủ có thẩm quyền chỉ đơn thuần trả về cờ tiêu đề với mã phản hồi 3 (NXDOMAIN) khi không tìm thấy địa chỉ. Nhưng với các máy chủ phân giải đệ quy có xác thực, hệ thống cần bằng chứng mật mã bảo đảm rằng kẻ xấu không tự ý giả mạo phản hồi phủ định để ngăn chặn dịch vụ hoạt động.

Việc tạo chữ ký số động cho các truy vấn tùy ý đòi hỏi máy chủ biên phải giữ khóa ký vùng trực tuyến. Ở giai đoạn đầu triển khai DNSSEC, rủi ro lộ khóa riêng tư trên cụm máy chủ phân tán khiến giải pháp này bị từ chối. Vì vậy, RFC 4034 buộc phải dựa vào cơ chế chứng minh phạm vi tĩnh được ký sẵn.

Thay vì xác nhận một tên miền truy vấn cụ thể không tồn tại, máy chủ cung cấp bản ghi chứng thực rằng không có bất kỳ tên miền hợp lệ nào nằm giữa hai mốc tên chuẩn hóa A và B trong bảng chữ cái. Khoảng cách toán học này tuy chứng minh được sự vắng mặt, nhưng lại làm lộ chính xác tên miền của hai mốc biên cho người gửi truy vấn.

Giải phẫu RFC 4034: Cơ chế bản ghi NSEC tạo thành danh sách liên kết ngoài ý muốn

Bản ghi NSEC thực hiện từ chối xác thực bằng cách trỏ trực tiếp đến tên miền chuẩn hóa kế tiếp có trong tệp vùng. Cấu trúc bản ghi bao gồm hai trường chính: Next Domain Name (tên miền tiếp theo) và Type Bit Maps (danh sách loại bản ghi đang hoạt động tại tên miền đó).

;; Ví dụ thứ tự chuẩn hóa trong tệp vùng doanh nghiệp
alpha.example.com.     3600 IN NSEC  billing.example.com.   A RRSIG NSEC
billing.example.com.   3600 IN NSEC  db-cluster.example.com. A RRSIG NSEC
db-cluster.example.com. 3600 IN NSEC  example.com.           A RRSIG NSEC

Các bản ghi này vô tình tạo thành một danh sách liên kết vòng khép kín. Bản ghi NSEC cuối cùng trong bảng chữ cái sẽ trỏ ngược lại đỉnh vùng (example.com.). Mọi tên miền nội bộ đều bị xâu chuỗi vào vòng lặp này.

Thứ tự chuẩn hóa canonical và cơ chế quét vùng tiêu chuẩn

Kẻ tấn công khai thác cấu trúc liên kết này thông qua kỹ thuật quét vùng tự động bằng các truy vấn đệ quy tiêu chuẩn:

  1. Truy vấn khởi đầu: Bộ quét gửi truy vấn bản ghi A cho một tiền tố đứng ngay trước đỉnh vùng, ví dụ 0.example.com.
  2. Trích xuất dải biên: Máy chủ phản hồi NXDOMAIN kèm bản ghi NSEC trải từ đỉnh vùng tới mục đầu tiên: example.com. NSEC admin.example.com.
  3. Tiến bước chuỗi: Bộ quét ghi nhận admin.example.com và lập tức tạo truy vấn kế tiếp: admin0.example.com.
  4. Lặp lại liên tục: Máy chủ trả về khoảng tiếp theo: admin.example.com NSEC api-gateway.example.com.
  5. Hoàn tất chu trình: Tiến trình lặp lại tuần tự cho đến khi bản ghi NSEC trỏ ngược về example.com., báo hiệu 100% tên miền đã bị thu thập trọn vẹn.

Liệt kê tên miền phụ: Dò quét toàn bộ bề mặt tấn công chỉ trong vài phút

Kỹ thuật Zone Walking dễ dàng xuyên thủng các rào cản trinh sát truyền thống. Các công cụ rà soát tên miền phụ thông thường phải dựa vào danh sách từ điển đoán mò, nhật ký minh bạch chứng chỉ (Certificate Transparency) hoặc quét công cụ tìm kiếm, thường bỏ sót máy chủ nội bộ.

Sử dụng các tiện ích mã nguồn mở như ldns-walk với vùng dùng RFC 4034, chuyên viên kiểm thử thâm nhập có thể trích xuất toàn bộ danh mục máy chủ cơ sở dữ liệu nội bộ, bảng điều khiển quản trị, máy chủ thử nghiệm và các cổng truy cập đường hầm bảo mật. Dữ liệu trinh sát này phơi bày quy ước đặt tên và cấu trúc hạ tầng, dọn đường cho các cuộc tấn công có chủ đích.

Thỏa hiệp RFC 5155: Cơ chế từ chối xác thực băm với NSEC3

Trước mối lo ngại rò rỉ dữ liệu, năm 2008 IETF đã phê chuẩn RFC 5155, giới thiệu chuẩn NSEC3 (DNSSEC Hashed Authenticated Denial of Existence).

NSEC3 ra đời với mục tiêu bảo toàn cơ chế từ chối xác thực nhưng ngăn chặn việc đọc trực tiếp tên miền dạng văn bản thô. Thay vì sắp xếp theo chuỗi ký tự thông thường, NSEC3 băm từng tên miền bằng thuật toán SHA-1, kết hợp một chuỗi muối (salt) tùy chọn và lặp lại hàm băm nhiều lần.

;; Cú pháp bản ghi NSEC3: [Thuật toán] [Cờ] [Vòng lặp] [Salt] [Băm kế tiếp] [Loại bản ghi]
2T8A7...example.com. 3600 IN NSEC3 1 0 10 A1B2C3D4 7K9P2... A RRSIG

Các giá trị băm mã hóa base32hex tạo thành một vòng tròn khép kín. Khi nhận truy vấn cho tên miền không tồn tại, máy chủ băm tên miền đó và trả về bản ghi NSEC3 bao phủ khoảng băm tương ứng. Tên miền văn bản rõ không còn xuất hiện trong gói tin mạng.

Bẻ gãy NSEC3: Tấn công từ điển tăng tốc GPU và giải mã Hashcat

Mặc dù NSEC3 ngăn chặn việc dò quét tức thì bằng ldns-walk, giải pháp này lại tạo ra lỗ hổng mật mã ngoại tuyến. Toàn bộ chuỗi băm của vùng vẫn hoàn toàn công khai. Kẻ tấn công có thể truy vấn tuần tự để thu thập đầy đủ các giá trị băm NSEC3.

Sau khi thu thập, kẻ tấn công chuyển hoàn toàn sang trạng thái ngoại tuyến. Do NSEC3 dựa trên SHA-1 với muối cố định, quá trình này biến thành cuộc tấn công từ điển ngoại tuyến:

Tên miền mẫu ("vpn") -> Muối ("A1B2C3D4") -> Băm SHA-1 lặp -> So khớp với chuỗi đã lưu

Các bộ xử lý đồ họa (GPU) hiện đại có thể thực hiện hàng tỷ phép tính SHA-1 mỗi giây. Phần mềm giải mã Hashcat tích hợp sẵn mô-đun tăng tốc chuyên dụng (Mode 8300: DNSSEC NSEC3) được tối ưu hóa cho tác vụ này.

Nền tảng Tốc độ băm (GH/s) Thời gian từ điển 100k tên Thời gian danh sách 10M từ
1x NVIDIA RTX 4090 28.5 GH/s 0.0035 giây 0.35 giây
8x NVIDIA RTX 4090 228.0 GH/s 0.0004 giây 0.04 giây
32x NVIDIA H100 1,120.0 GH/s < 0.0001 giây 0.009 giây

Thực nghiệm cho thấy các cuộc tấn công từ điển nhắm vào chuỗi NSEC3 có thể khôi phục từ 65% đến 85% tên miền thực tế chỉ trong vài giờ, do quản trị viên doanh nghiệp thường sử dụng các tiền tố quen thuộc (mail, vpn, api, auth, jira, dev).

Cạm bẫy từ chối dịch vụ tính toán: Lý do số vòng băm cao làm tê liệt resolver

Nhằm cản trở việc giải mã băm trên GPU, nhiều quản trị viên trước đây đã nâng thông số iterations trong RFC 5155 lên 500, 1000 hoặc thậm chí 2500 vòng lặp SHA-1.

Tuy nhiên, giải pháp này phản tác dụng nghiêm trọng, tạo ra bề mặt tấn công Từ chối Dịch vụ (DoS) bất đối xứng nhắm vào máy chủ phân giải:

  • Bất đối xứng: Máy chủ có thẩm quyền chỉ tính toán NSEC3 một lần khi ký vùng ngoại tuyến.
  • Gánh nặng máy chủ giải: Mọi truy vấn người dùng nhắm vào tên miền không tồn tại buộc máy chủ đệ quy phải tính toán lại toàn bộ chuỗi băm đủ 2500 vòng để xác thực tính toàn vẹn toán học.
  • Khuếch đại tài nguyên: Bằng cách bắn liên tục các truy vấn NXDOMAIN giả mạo tới máy chủ phân giải công cộng, kẻ tấn công chiếm dụng 100% chu kỳ CPU vào các phép tính băm vô nghĩa.

Dưới tải nặng, các máy chủ phân giải cạn kiệt luồng xử lý, độ trễ tăng vọt trên 1500 ms và làm gián đoạn các truy vấn hợp lệ của người dùng.

Gia cố bảo mật theo RFC 9276: Loại bỏ Salt và siết chặt số vòng lặp

Để triệt tiêu nguy cơ DoS tính toán và xóa bỏ ảo tưởng an ninh từ các tham số băm, IETF đã ban hành RFC 9276 (Hướng dẫn thiết lập tham số NSEC3).

RFC 9276 thiết lập các nguyên tắc vận hành nghiêm ngặt:

  1. Số vòng lặp phải bằng 0: Số vòng lặp lớn hơn 0 đem lại hiệu quả bảo vệ không đáng kể trước cụm GPU hiện đại nhưng gây áp lực xử lý khổng lồ lên máy chủ phân giải. Quản trị viên bắt buộc đặt iterations = 0.
  2. Không dùng Salt: Muối động không bảo vệ được các từ khóa từ điển và làm vô hiệu hóa bộ đệm phân giải khi cập nhật vùng. Tiêu chuẩn khuyến nghị để trống muối (ký hiệu -).
  3. Giới hạn kiểm tra tại Resolver: Các phần mềm phân giải hiện đại áp đặt ngưỡng kiểm soát nghiêm ngặt. Nếu vùng trả về bản ghi NSEC3 vượt quá giới hạn vòng lặp cho phép, resolver sẽ đánh dấu vùng không an toàn hoặc trả về SERVFAIL thay vì tiêu tốn tài nguyên CPU.
;; Cấu hình NSEC3 hiện đại khuyến nghị (chuẩn RFC 9276)
;; Thuật toán = 1 (SHA-1), Cờ = 0, Vòng lặp = 0, Salt = -
U5G9E...example.com. 3600 IN NSEC3 1 0 0 - 8F3K2... A RRSIG

Bước tiến mật mã thế hệ mới: NSEC5 và Hàm ngẫu nhiên kiểm chứng được (VRF)

Do NSEC3 không thể ngăn chặn triệt để tấn công từ điển ngoại tuyến, giới nghiên cứu mật mã học và IETF đã phát triển giao thức NSEC5 (Từ chối xác thực DNSSEC với Hàm ngẫu nhiên kiểm chứng được - VRF).

NSEC5 giải quyết triệt để bài toán zone walking bằng cách ứng dụng cấu trúc mật mã bất đối xứng VRF:

  • Máy chủ có thẩm quyền nắm giữ khóa bí mật VRF (sk_vrf).
  • Máy chủ phân giải lưu trữ khóa công khai VRF tương ứng (pk_vrf).
  • Để tính toán giá trị băm của một tên miền, bắt buộc phải có sk_vrf.
  • Để kiểm tra tính hợp lệ của giá trị băm đã tính, chỉ cần dùng pk_vrf.

Kẻ tấn công không sở hữu khóa bí mật nên hoàn toàn không thể tính toán băm ngoại tuyến, khiến các đòn tấn công từ điển GPU trở nên bất khả thi.

Ký trực tuyến đối lập ký ngoại tuyến: Phương pháp tiếp cận "White Lies"

Một giải pháp phòng thủ thay thế đang được các nhà cung cấp DNS biên quy mô lớn triển khai rộng rãi là NSEC bao phủ tối thiểu (Minimal Covering NSEC), thường gọi là "White Lies" (RFC 4470 và RFC 7129).

Thay vì để lộ danh sách liên kết có sẵn, máy chủ ký phản hồi động ngay tại biên:

  1. Khi nhận truy vấn cho charlie.example.com không tồn tại, máy chủ tự động tổng hợp bản ghi NSEC động bao phủ chính xác khoảng (charlie\000.example.com NSEC charlie\001.example.com).
  2. Bản ghi này chứng minh sự vắng mặt của truy vấn cụ thể đó mà không tiết lộ bất kỳ tên miền lân cận nào trong hệ thống.
  3. Kiến trúc này yêu cầu lưu trữ khóa ký trực tuyến tại các trạm PoP, điều mà mô-đun bảo mật phần cứng (HSM) hiện đại đã giải quyết an toàn.

Bảo đảm quyền riêng tư toán học thông qua đánh giá VRF bất đối xứng

NSEC5 duy trì mô hình bảo vệ khóa ký ngoại tuyến truyền thống nhưng vẫn đạt được độ bảo mật quyền riêng tư của giải pháp ký trực tuyến. Kẻ tấn công chỉ nhận được đúng một bằng chứng cho mỗi truy vấn gửi đi. Việc thu thập hàng triệu tên miền phụ đòi hỏi phải gửi hàng triệu yêu cầu mạng trực tiếp, kích hoạt ngay hệ thống phòng vệ tường lửa theo dõi tần suất.

Zone walking do đó bị chuyển hóa từ hành vi đánh cắp dữ liệu ngoại tuyến âm thầm thành cuộc tấn công mạng trực tiếp dễ bị ngăn chặn.

Kiến trúc DNS đệ quy RiceGuard: Ngăn chặn trinh sát cấu trúc vùng

Trong môi trường kết nối đường hầm bảo mật của doanh nghiệp, máy chủ phân giải DNS đệ quy đóng vai trò chốt chặn then chốt giữa thiết bị người dùng và không gian mạng bên ngoài. Nếu máy chủ phân giải xử lý thiếu chọn lọc, hiệu năng hệ thống sẽ bị suy giảm nghiêm trọng.

VPNRice phát triển kiến trúc RiceGuard Lớp 3 nhằm triệt tiêu các nguy cơ do thám DNS và bảo vệ thiết bị đầu cuối:

  • Tối thiểu hóa truy vấn (RFC 7816): Máy chủ RiceGuard lược bỏ các nhãn tên miền thừa trước khi chuyển tiếp lên thượng tầng, chỉ gửi đúng nhãn cần thiết cho chặng ủy quyền hiện tại.
  • Bộ nhớ đệm phản hồi phủ định: Resolver lưu trữ bộ đệm NXDOMAIN (RFC 2308), phục vụ tức thì các truy vấn lặp lại tại chỗ nhằm bảo vệ máy chủ có thẩm quyền.
  • Kiểm soát vòng lặp thuật toán: Tuân thủ chặt chẽ RFC 9276, RiceGuard chủ động hạ ưu tiên hoặc loại bỏ các bản ghi NSEC3 có số vòng lặp bất thường, ngăn ngừa tấn công DoS tính toán CPU.
  • Ngăn chặn rò rỉ DNS: Mọi truy vấn phân giải được dẫn truyền qua đường hầm WireGuard xác thực tới cụm máy chủ nội bộ cô lập, tách biệt địa chỉ IP người dùng. Độc giả có thể kiểm tra trạng thái bảo mật kết nối qua /what-is-my-ip.

Người dùng cần bảo vệ lưu lượng có thể cài đặt ứng dụng tại /download. Chi tiết về mã hóa truyền tải DNS được trình bày tại /news/dnssec-vs-encrypted-dns-authenticity-privacy-architecture, và cơ chế phòng ngừa đo thời gian phản hồi có tại /news/dns-cache-snooping-non-recursive-query-timing-defense.

Kiểm toán thực tiễn và phòng thủ: Phát hiện Zone Walking và tinh chỉnh Resolver

Quản trị viên hệ thống cần chủ động kiểm tra các tên miền công cộng để bảo đảm không để lộ cấu trúc nội bộ thông qua bản ghi NSEC cũ. Việc xác thực đòi hỏi đánh giá tham số vùng và áp dụng chính sách ký chuẩn hóa.

Có thể kiểm tra lỗ hổng RFC 4034 bằng lệnh dig +dnssec example.com NSEC hoặc rà soát tự động với ldns-walk @ns1.example.com example.com. Nếu nhận về danh sách tên miền tuần tự, cần lập tức chuyển dịch sang NSEC3 chuẩn RFC 9276.

Trong BIND 9, thiết lập chính sách bảo mật trong tệp named.conf:

dnssec-policy "hardened-nsec3" {
    keys {
        ksk lifetime 365d algorithm ecdsap256sha256;
        zsk lifetime 60d algorithm ecdsap256sha256;
    };
    nsec3param {
        iterations 0;
        optout no;
        salt-length 0;
    };
};

Đối với Knot DNS (knot.conf), khai báo nsec3-iterations: 0 và nsec3-salt-length: 0 trong phần cấu hình policy. Khi kiểm tra lại bằng lệnh dig +dnssec +multiline nonexistent.example.com A, bản ghi NSEC3 trả về cần hiển thị số vòng lặp 0 và muối trống -. Bằng việc loại bỏ vòng lặp băm và kết hợp máy chủ đệ quy kiên cố, doanh nghiệp triệt tiêu nguy cơ rò rỉ sơ đồ mạng trong khi vẫn duy trì toàn vẹn xác thực DNSSEC.