
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.
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
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.
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.

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.
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
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
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.
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.

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.
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.
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.
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.
