SECURITY VALIDATION

Kiểm thử DNS mã hóa DoH và DoQ: bootstrap, cache, fallback và policy leakage

15/9/2026 · 16 phút

Minh họa DNS mã hóa qua hai đường transport tới resolver trong phòng lab mạng.
Mục lục bài viết 9 phần

DoH và DoQ bảo vệ truy vấn DNS trên đường truyền nhưng không tự bảo đảm resolver đúng, policy được giữ hay client không âm thầm quay về DNS thường. Một test plan có giá trị phải quan sát đồng thời client, recursive resolver và mạng, đồng thời tách cold cache, warm cache, bootstrap và từng failure mode.

ĐỌC NHANH

Bài viết giúp bạn

  • DoH và DoQ cần trả lời câu hỏi nào?
  • Topology và điều kiện đo
  • Biến số phải kiểm soát
Tùy chỉnh đọc
01

DoH và DoQ cần trả lời câu hỏi nào?

#

RFC 8484 định nghĩa DNS over HTTPS; RFC 9250 định nghĩa DNS over Dedicated QUIC Connections. Cả hai bảo vệ DNS message bằng transport đã mã hóa, nhưng privacy còn phụ thuộc resolver, logging, endpoint discovery và metadata mạng. “Không đọc được payload trên pcap” chỉ chứng minh một phần.

Bài đo cần trả lời bốn câu: client dùng đúng resolver không; câu trả lời có đúng policy/split horizon không; lỗi transport có tạo fallback ngoài ý muốn không; và hiệu năng/recovery có đạt SLO không. Với endpoint doanh nghiệp, phải chốt browser/OS/app nào được phép tự chọn resolver và cấu hình nào do quản trị áp đặt.

02

Topology và điều kiện đo

#

Topology tối thiểu gồm client, DNS policy/endpoint management, network emulator, DoH/DoQ resolver, authoritative DNS lab và một resolver DNS thường dành cho negative test. Đặt capture ở client egress và phía resolver; gắn query ID logic bằng qname duy nhất vì encryption làm mất khả năng nối trực tiếp DNS transaction trên đường đi.

Authoritative zone lab nên có A/AAAA, CNAME chain, NXDOMAIN, DNSSEC valid/bogus, TTL ngắn/dài và split view. Khóa resolver build, client version, trust store, bootstrap address, HTTP proxy, VPN và clock. Chạy cold cache và warm cache thành hai pha riêng.

Minh họa khái niệm: client, policy, bộ mô phỏng mạng và resolver trong bài kiểm DoH/DoQ; nhánh màu cam biểu thị đường fallback cần kiểm soát.
Minh họa khái niệm: client, policy, bộ mô phỏng mạng và resolver trong bài kiểm DoH/DoQ; nhánh màu cam biểu thị đường fallback cần kiểm soát.
03

Biến số phải kiểm soát

#

Với DoH, khóa HTTP version, connection reuse, request method, content type, proxy và stream concurrency. Với DoQ, khóa QUIC version, ALPN (doq), connection ID, address migration, idle timeout và UDP reachability. TLS certificate, SNI, trust chain và session resumption phải được ghi cùng run.

Biến DNS gồm TTL, negative cache, DNSSEC validation, ECS nếu có, response size, truncation và authoritative delay. Biến mạng gồm latency, jitter, packet loss, reordering, MTU, UDP block, TCP block và TLS interception. Đặc biệt phải phân biệt fail-open sang resolver khác với retry cùng resolver qua transport khác.

04

KPI và bằng chứng đầu ra

#

Đo resolution success, answer correctness, DNSSEC outcome, time-to-first-answer, p50/p95/p99, handshake rate, connection reuse, queries/connection, retry, fallback rate, cache hit behavior và recovery time. Báo riêng cold/warm; không lấy cache hit để che handshake hoặc authoritative latency.

  • KPI: Resolver selection · Điểm đo: Client + resolver log · Bằng chứng: Endpoint, SNI/ALPN, policy ID
  • KPI: Answer correctness · Điểm đo: Authoritative + client · Bằng chứng: RRset, TTL, DNSSEC status
  • KPI: Fallback leakage · Điểm đo: Egress capture · Bằng chứng: UDP/TCP 53 hoặc resolver ngoài policy
  • KPI: Tail latency · Điểm đo: Client timestamp · Bằng chứng: p50/p95/p99 theo cold/warm
  • KPI: Cache behavior · Điểm đo: Resolver + authoritative · Bằng chứng: Upstream query count, age/TTL
  • KPI: Recovery · Điểm đo: Fault timeline · Bằng chứng: Success/latency trở về baseline
  • KPI: Transport loss · Điểm đo: Network + endpoint · Bằng chứng: QUIC loss/recovery, TCP retransmission và timeout
05

Ma trận quyết định DoH, DoQ và DNS thường

#

Không có transport tốt nhất cho mọi topology. DoH thường đi qua hạ tầng HTTP/proxy thuận lợi nhưng có thể trộn với web traffic; DoQ dùng QUIC chuyên dụng, giảm head-of-line giữa transaction nhưng phụ thuộc UDP và policy firewall. DNS thường vẫn cần trong một số bootstrap/legacy path, song phải được thiết kế rõ chứ không phát sinh âm thầm.

  • Điều kiện: Baseline · DoH: HTTPS thành công · DoQ: QUIC thành công · Câu hỏi pass/fail: Đúng resolver, đúng answer
  • Điều kiện: UDP bị chặn · DoH: HTTP/2 vẫn có thể hoạt động; HTTP/3 chịu ảnh hưởng · DoQ: Thất bại/retry · Câu hỏi pass/fail: Có fallback đúng policy?
  • Điều kiện: Proxy bắt buộc · DoH: Kiểm CONNECT/policy · DoQ: Thường không đi proxy HTTP · Câu hỏi pass/fail: Client báo lỗi hay bypass?
  • Điều kiện: Split DNS · DoH: Resolver nội bộ · DoQ: Resolver nội bộ · Câu hỏi pass/fail: Private name có rò ra ngoài?
  • Điều kiện: Certificate lỗi · DoH: TLS fail · DoQ: TLS fail · Câu hỏi pass/fail: Không bỏ xác thực/fallback mù
  • Điều kiện: Resolver quá tải · DoH: HTTP error/timeout · DoQ: QUIC error/timeout · Câu hỏi pass/fail: Backoff, SLO và fail mode đúng
06

Test plan theo từng pha

#

Pha A xây ground truth bằng zone lab và DNS thường nội bộ. Pha B bật DoH, xác minh certificate, resolver selection, cold/warm cache và concurrent query. Pha C bật DoQ với cùng dataset. Pha D chèn lỗi từng lớp: bootstrap, DNSSEC, TLS, HTTP, UDP/QUIC, resolver và authoritative.

Pha E kiểm policy leakage: private qname, captive portal, VPN up/down, proxy và resolver discovery. Pha F chạy tải tăng dần, burst và sustained; đo queue, CPU, connection count, loss và tail latency. Cuối cùng gỡ impairment, xác minh connection/cache không giữ trạng thái lỗi và so với baseline.

07

Checklist nghiệm thu và runbook

#
  • Chốt client/OS/browser/app và cơ chế quản trị resolver.
  • Ghi endpoint, certificate, SNI, ALPN, HTTP/QUIC version và trust store.
  • Dùng qname duy nhất để nối client, resolver và authoritative log.
  • Tách cold cache, warm cache, positive, negative và DNSSEC bogus.
  • Chặn riêng UDP 853 cho DoQ (hoặc cổng đã thỏa thuận), TCP 443 cho DoH qua HTTP/2, UDP 443 cho DoH qua HTTP/3 và UDP/TCP 53; không nhầm DoH qua HTTP/3 với DoQ.
  • Kiểm split DNS khi VPN chuyển trạng thái và khi resolver nội bộ mất.
  • Tạo response lớn, CNAME chain, delay và resolver overload.
  • Báo latency phân vị, error mix, fallback và leakage; không chỉ average.
  • Lưu pcap đã mã hóa, endpoint logs, policy snapshot và raw result.
  • Diễn tập rollback mà không để client giữ resolver/cache sai.
Minh họa các lớp cần chèn lỗi: bootstrap, xác thực, transport, cache và resolver. Hình không biểu diễn số liệu đo thực tế.
Minh họa các lớp cần chèn lỗi: bootstrap, xác thực, transport, cache và resolver. Hình không biểu diễn số liệu đo thực tế.
08

Giới hạn của kết luận

#

Trong topology stub–recursive của bài này, DoH/DoQ mã hóa hop client–resolver, không tự mã hóa mọi xử lý sau resolver và không chứng minh resolver không lưu log. Kết quả của một browser không đại diện OS resolver, agent bảo mật hoặc ứng dụng nhúng. CDN anycast và đường internet cũng làm kết quả theo vị trí thay đổi.

RFC mô tả protocol, không đặt SLO hay chính sách fallback của tổ chức. Pass/fail phải gắn với security policy, privacy requirement và traffic profile đã thống nhất. RFC 8310 được dẫn để tham khảo khái niệm strict/opportunistic privacy của DoT/DTLS, không thay thế đặc tả DoH hoặc DoQ. Không gọi transport “an toàn hơn” nếu chưa kiểm trust, resolver governance, logging và bypass.

09

Khái niệm cần nhớ

#
  • DoH: DNS message truyền qua HTTPS theo RFC 8484.
  • DoQ: DNS trên kết nối QUIC chuyên dụng theo RFC 9250.
  • Bootstrap: cách client tìm địa chỉ endpoint resolver trước khi dùng DNS mã hóa.
  • Split DNS: cùng tên có thể trả kết quả khác theo miền mạng/policy.
  • Fallback leakage: truy vấn quay về đường không được phép khi transport chính lỗi.
  • Cold cache: resolver/client chưa có bản ghi dùng lại.
  • ALPN: cơ chế thương lượng application protocol trong TLS.
THUẬT NGỮ NHANH

Khái niệm cần nhớ

Security efficacy
Mức độ phát hiện hoặc ngăn chặn đúng nội dung kiểm thử trong phạm vi đã xác định.
Goodput
Lưu lượng ứng dụng hữu ích tới đích, không tính phần truyền lại hoặc overhead không tạo giá trị.
False positive
Lưu lượng hợp lệ bị nhận diện hoặc xử lý nhầm như một mối đe dọa.
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.

Nguyên tắc biên tập

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.

Thông số và khả năng sản phẩm có thể thay đổi theo phiên bản. Hãy đối chiếu tài liệu chính thức trước khi xây dựng cấu hình hoặc tiêu chí nghiệm thu.
BẮT ĐẦU TỪ BÀI TOÁN

Cần chuyển kiến thức thành test plan?

Chia sẻ mục tiêu, topology và ràng buộc kỹ thuật. NetVali sẽ cùng bạn xác định bài đo phù hợp.

Trao đổi yêu cầu kỹ thuật