SERVICE ASSURANCE

Kiểm thử DNS resolver cache: TTL, negative caching và serve-stale

26/8/2026 · 16 phút đọc

Client qua recursive resolver tới authoritative DNS với cache và điểm đo TTL
Mục lục bài viết 10 phần

1. Câu hỏi kiểm thử cần trả lời 2. Topology và điều kiện đo 3. Biến số phải kiểm soát 4. KPI và bằng chứng đầu ra 5. Ma trận cache và lỗi 6. Test plan theo từng pha 7. Serve-stale không đồng nghĩa dữ liệu đúng 8. Runbook thực hành 9. Giới hạn kết luận

ĐỌC NHANH

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

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

Câu hỏi kiểm thử cần trả lời

#

Cần biết resolver trả dữ liệu nào trước, tại và sau khi TTL hết; khi nào nó hỏi lại authoritative; và phản ứng ra sao với NXDOMAIN, NODATA, timeout, SERVFAIL hoặc DNSSEC validation failure. “Độ trễ thấp” không đủ nếu câu trả lời sai freshness policy.

Định nghĩa trước expected answer cho từng mốc thời gian và từng RCODE. Tách yêu cầu tiêu chuẩn khỏi chính sách tùy chọn như prefetch, cache minimum/maximum TTL và serve-stale.

02

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

#

Lab gồm client generator, recursive resolver DUT, authoritative server điều khiển được và network emulator ở đường upstream. Capture ở client–resolver và resolver–authoritative; thu resolver cache statistics, query log, authoritative query log và resource telemetry.

Dùng zone riêng với A/AAAA/CNAME, record không tồn tại và DNSSEC nếu cần. Đồng bộ clock hoặc ghi offset; thay zone bằng quy trình có timestamp. Bypass OS/browser cache hoặc đo riêng lớp cache đó để không gán nhầm hành vi cho resolver.

Minh họa kỹ thuật: Topology và điều kiện đo
Minh họa kỹ thuật: Topology và điều kiện đo
03

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

#

Khóa resolver/version, cache size, positive/negative TTL policy, prefetch, serve-stale, failure recheck timer và DNSSEC validation. Với zone, ghi serial, TTL của RRset, SOA TTL/MINIMUM, delegation và thời điểm publish.

Traffic profile cần có QNAME popularity, QTYPE mix, client count, query rate, EDNS size và transport UDP/TCP/DoT/DoH nếu liên quan. Với mạng, thay RTT, jitter, packet loss, bandwidth và authoritative availability từng biến một.

04

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

#

KPI · Cách đo · Bằng chứng Cache hit ratio · Hit/(hit+miss) · Resolver counter/log Response latency · p50/p95/p99 theo trạng thái · Client histogram Upstream query rate · QPS tới authoritative · Authoritative log Freshness · Answer/TTL theo timeline · Pcap + zone history Negative-cache duration · NXDOMAIN/NODATA giữ bao lâu · Query timeline Stale window · Thời gian và điều kiện trả stale · Answer + failure log Recovery · Upstream phục hồi → dữ liệu mới · Timestamp đối chiếu

Báo RCODE và EDE nếu có; không gom timeout, SERVFAIL và NXDOMAIN. Lưu packet capture để chứng minh TTL quan sát được, nhưng nhớ rằng TTL trên wire có thể đã giảm theo tuổi cache.

05

Ma trận cache và lỗi

#

Trạng thái · Kỳ vọng kiểm chứng · Rủi ro Positive TTL còn hạn · Cache hit · Query upstream thừa TTL vừa hết · Refresh đúng policy · Stampede NXDOMAIN · Negative caching đúng SOA · Giữ lỗi quá lâu NODATA · Phân biệt với NXDOMAIN · Sai semantics Timeout upstream · Stale hoặc failure theo policy · Dữ liệu cũ im lặng DNSSEC bogus · Validation failure caching · Bỏ qua validation Authoritative phục hồi · Refresh và hội tụ · Stale kéo dài

Thêm hot-name burst ở thời điểm expiry để phát hiện cache stampede. Lặp với cold cache và warm cache; hai trạng thái này không được so lẫn.

06

Test plan theo từng pha

#

Pha functional đi qua positive, CNAME chain, NODATA và NXDOMAIN. Pha TTL thay record ở authoritative rồi query trước/sát/sau expiry. Pha load tăng client và query rate với popularity distribution đã chốt; theo dõi hit ratio, upstream amplification và CPU/memory.

Pha failure tạo timeout, packet loss, SERVFAIL và authoritative outage. Bật/tắt serve-stale trong các run riêng, sau đó phục hồi upstream để đo refresh. Pha soak theo dõi cache eviction, memory pressure và log/counter rollover.

07

Serve-stale không đồng nghĩa dữ liệu đúng

#

RFC 8767 cho phép resolver dùng dữ liệu đã hết hạn để tăng khả năng phục hồi khi không refresh được. Đây là lựa chọn availability có đánh đổi freshness, không phải xác nhận dữ liệu vẫn đúng. Báo rõ stale answer được dùng trong điều kiện nào, kéo dài bao lâu và có tín hiệu EDE hay log nào cho vận hành.

Negative caching cũng cần tách NXDOMAIN/NODATA khỏi resolution failure. RFC 9520 cập nhật yêu cầu cache một số failure để giảm truy vấn lặp; triển khai và timer cụ thể vẫn phải xác minh theo resolver/version.

Minh họa kiểm chứng: Serve-stale không đồng nghĩa dữ liệu đúng
Minh họa kiểm chứng: Serve-stale không đồng nghĩa dữ liệu đúng
08

Runbook thực hành

#
  • [ ] Chốt zone, RRset, TTL, SOA và resolver policy.
  • [ ] Xóa cache có kiểm soát; ghi trạng thái cold/warm.
  • [ ] Đồng bộ clock; bật capture và log hai phía.
  • [ ] Chạy positive, NODATA, NXDOMAIN và CNAME baseline.
  • [ ] Thay record; query trước, tại và sau expiry.
  • [ ] Tạo hot-name burst quanh expiry.
  • [ ] Tiêm timeout, loss, SERVFAIL và outage riêng.
  • [ ] Kiểm tra stale answer và recovery sau upstream trở lại.
  • [ ] Lưu config, zone history, pcap, log và raw metrics.
09

Giới hạn kết luận

#

Kết quả phụ thuộc resolver/version, cache policy, zone data, DNSSEC, client behavior và traffic distribution. Một cache hit ratio cao không chứng minh freshness hoặc resiliency; QPS thấp có thể do negative answer bị giữ quá lâu.

Không suy rộng kết quả UDP sang DoH/DoT hoặc hệ thống có cache nhiều tầng. Nếu dùng anycast authoritative hay nhiều resolver node, cần thêm consistency, routing và state isolation vào test plan.

10

Khái niệm cần nhớ

#
  • TTL: Thời gian RRset có thể được cache.
  • Negative caching: Cache câu trả lời tên hoặc dữ liệu không tồn tại.
  • NXDOMAIN: Tên miền được hỏi không tồn tại.
  • NODATA: Tên tồn tại nhưng không có RRset được hỏi.
  • Serve-stale: Trả dữ liệu hết hạn khi không thể refresh theo policy.
  • Cache stampede: Nhiều truy vấn upstream đồng thời khi mục cache hết hạn.
  • EDE: Extended DNS Error bổ sung ngữ cảnh lỗi.
THUẬT NGỮ NHANH

Khái niệm cần nhớ

Baseline
Dải giá trị bình thường được thu đủ lâu để làm mốc so sánh và đặt ngưỡng.
SLA
Cam kết chất lượng dịch vụ gắn với KPI, phạm vi, thời gian và cách đo cụ thể.
Active test
Phép đo dùng traffic tổng hợp được tạo có chủ đích giữa các điểm kiểm tra.
TÀI LIỆU ĐỐI CHIẾUTài liệu tham khảo5 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