
Mục lục bài viết 9 phần
DNS mã hóa bảo vệ truy vấn trên đường truyền nhưng đồng thời thay đổi transport, connection lifecycle, cache và khả năng quan sát của hệ thống mạng. Một test plan tốt phải đo trải nghiệm phân giải tên lẫn tác động tới policy, không chỉ xác nhận cổng dịch vụ mở.
Bài viết giúp bạn
- Câu hỏi kỹ thuật cần trả lời
- Topology và điểm đo
- Biến số phải kiểm soát
Câu hỏi kỹ thuật cần trả lời
#Lab cần xác định resolver trả lời đúng, transport được xác thực đúng, latency ở cold/warm state, cache hoạt động như dự kiến và policy doanh nghiệp có còn thực thi được. “Có mã hóa” không đồng nghĩa resolver đáng tin cậy hoặc ứng dụng tuân thủ resolver được tổ chức chỉ định.
DoH chạy trên HTTP, DoT trên TLS và DoQ trên QUIC; mỗi cơ chế có handshake, multiplexing và recovery khác nhau. Không so sánh bằng một truy vấn duy nhất khi connection/cache state không đồng nhất.
Topology và điểm đo
#Đặt client generator, enterprise resolver/forwarder, recursive resolver, authoritative zone có kiểm soát, impairment node và capture ở hai trust boundary. Dùng zone riêng để tạo NXDOMAIN, DNSSEC, CNAME chain, response lớn và TTL có chủ đích.
Thu packet ở client edge và resolver side; với encrypted transport, kết hợp log/metric endpoint thay vì cố suy luận nội dung từ pcap. Nếu có proxy/SWG/firewall, ghi rõ nơi TLS/HTTP/QUIC được cho phép hoặc kiểm soát.

Biến số phải kiểm soát
#Khóa resolver/software version, address family, DNSSEC mode, EDNS size, cache TTL, HTTP version, TLS/QUIC version, certificate trust, connection reuse và client concurrency. Flush cache có kiểm soát cho cold-cache; không trộn kết quả hit và miss.
Traffic profile gồm tên phổ biến/duy nhất, positive/NXDOMAIN, response nhỏ/lớn, query type và tỷ lệ cache hit. Với DoH/DoQ, ghi số request trên mỗi connection; handshake cost sẽ bị che nếu chỉ đo connection tái sử dụng.
KPI và bằng chứng
#Đo resolution success, response correctness, total lookup time, handshake time, time-to-first-response, query rate, timeout, retry, cache hit và tài nguyên resolver. Báo percentile, không chỉ average; tail latency quan trọng khi resolver chịu burst.
Pcap chứng minh endpoint/transport/timing; resolver log chứng minh query/rcode/cache; certificate và cấu hình chứng minh trust/policy. Với DNSSEC, xác nhận validation result thay vì chỉ thấy AD bit từ một điểm không tin cậy.
Ma trận transport và search intent
#- Profile: Do53 UDP/TCP · Điều cần kiểm chứng: Baseline và truncation/fallback · KPI chính: Lookup time, retry
- Profile: DoT · Điều cần kiểm chứng: TLS trust và reuse · KPI chính: Handshake, p95
- Profile: DoH HTTP/2/3 · Điều cần kiểm chứng: Multiplexing, proxy policy · KPI chính: Success, stream error
- Profile: DoQ · Điều cần kiểm chứng: QUIC loss recovery/migration · KPI chính: Tail latency, timeout
- Profile: DNSSEC · Điều cần kiểm chứng: Validation đúng/sai · KPI chính: RCODE, validation
- Profile: Cache miss burst · Điều cần kiểm chứng: Resolver/upstream capacity · KPI chính: QPS, CPU, p99
- Profile: NXDOMAIN flood hợp lệ · Điều cần kiểm chứng: Negative caching · KPI chính: Upstream query rate
Test plan chức năng và tải
#Xác nhận positive, NXDOMAIN, SERVFAIL, CNAME, DNSSEC valid/bogus và response lớn trước khi tạo tải. Chạy cold connection/cold cache, warm connection/cold cache và warm cả hai; mỗi trạng thái trả lời một câu hỏi khác nhau.
Tăng concurrency/QPS theo bước, giữ distribution ổn định và theo dõi saturation. Chèn latency, jitter, loss ở đường client–resolver và resolver–upstream riêng để định vị nguyên nhân. Thử IPv4/IPv6 độc lập nếu production dùng dual-stack.
Failure, fallback và policy
#Ngắt resolver, làm certificate hết hạn trong lab, chặn UDP/443 hoặc QUIC, tạo path MTU nhỏ và làm authoritative chậm. Quan sát client fail-fast, retry, fallback hay chuyển resolver ngoài policy. Fallback sang plaintext có thể tăng availability nhưng phá yêu cầu bảo mật.
Policy test cần kiểm tra bootstrap resolver, canary/domain control nếu nền tảng sử dụng, allowlist resolver và log/audit. Không giả định firewall có thể phân loại mọi DoH dựa trên port 443; kết luận phải gắn với tính năng/phiên bản và kiến trúc giải mã được phê duyệt.

Runbook thực hành
#- Chốt transport, resolver và trust boundary.
- Dựng authoritative zone/test records.
- Khóa cache, DNSSEC và connection state.
- Chạy functional matrix.
- Đo cold/warm và tăng tải theo bước.
- Chèn impairment từng đoạn.
- Thử resolver/certificate/transport failure.
- Lưu pcap, resolver log, config và verdict.
Giới hạn kết luận
#Kết quả phụ thuộc client implementation, resolver, HTTP/QUIC stack, network path và cache state. Một trình duyệt có thể có policy khác hệ điều hành; không suy rộng từ một client sang toàn bộ fleet.
Mã hóa bảo vệ nội dung truy vấn trên đường truyền nhưng không loại bỏ metadata và không thay thế governance của resolver. Privacy/security claim phải bám đúng threat model.
Khái niệm cần nhớ
- DUT / SUT
- Thiết bị hoặc toàn bộ hệ thống đang là đối tượng của bài kiểm thử.
- Steady state
- Giai đoạn tải đã ổn định và đủ điều kiện để lấy số liệu đại diện.
- Pass / fail
- Kết luận dựa trên ngưỡng đã thống nhất, luôn đi cùng topology, cấu hình và điều kiện đo.
TÀI LIỆU ĐỐI CHIẾUTài liệu tham khảo4 nguồn +
Nội dung được biên soạn độc lập, theo hướng vendor-neutral và đối chiếu các tài liệu gốc dưới đây. Tính năng sản phẩm cần được kiểm tra lại theo phiên bản đang sử dụng.
NetVali ưu tiên nguồn tiêu chuẩn và tài liệu chính thức; phân biệt khuyến nghị triển khai với yêu cầu của tiêu chuẩn; không công bố thông số sản phẩm chưa gắn với phiên bản và điều kiện đo.
