Recommendations for DNSprotection enhancements foradguard（2） #6004
Description
"I've used AI for the translation below, so please forgive any inaccuracies."
Subject: Proposal: Enhancing AdGuard's DNS Protection through Advanced Caching and TTL Management
I've noticed that some features in the AdGuard Android app might be redundant or underutilized. However, their existence actually lays the groundwork for a more robust DNS protection system. I'd like to explain my suggestions for strengthening AdGuard's DNS capabilities.
- Rethinking "DNS Response Timeouts"
Currently, the concepts of "Valid Response Timeout" and "Invalid Response Timeout" should be fundamentally tied to DNS TTL (Time to Live).
The Mechanism: Instead of just timing out, we should manipulate the TTL to determine validity. This is a common practice in DNS services to ensure effectiveness and reduce query volume.
Valid Responses: This applies to both blocked responses and normal/whitelisted responses. By extending the TTL of blocked domains (e.g., to 18000 seconds), we can significantly reduce redundant queries.
Invalid Responses: This targets SERVFAIL and other DNS error codes. When such a response occurs, the domain should be tagged temporarily. During this period, requests for this domain should be "fast-forwarded" or blocked immediately until the invalid timeout expires or a valid response is received.
- The Core: "DNS Cache Management List"
This is the foundation that makes the above timeouts work. Currently, AdGuard lacks a persistent DNS response cache.
The Gap: Features like "Blocked TTL" are useless without a cache. On Android, apps frequently re-query DNS; if AdGuard doesn't cache the response locally, the TTL setting has no effect.
The Solution: We need a "DNS Cache Management List." This goes beyond simple logging; it actively caches DNS responses (IPv4, IPv6, TTL).
The Benefit: By managing these responses, we reduce pressure on upstream servers and mitigate timeout issues caused by excessive queries. A cache size of 1000-2000 entries would be sufficient for a single device.
- Analysis of Current Features
SERVFAIL Handling: The current "SERVFAIL response" feature helps diagnose DNS issues but is incomplete. It should be upgraded to the "Invalid Response Timeout" mechanism mentioned above to handle various DNS errors, not just timeouts.
Blocked TTL: As stated, this is ineffective without a cache. It should be upgraded to manage both normal and blocked responses. For example:
Blocked Domains: TTL set to 18000 (5 hours).
Normal Domains: TTL rewriting logic (e.g., rewrite <10min TTL to 30min, <2hr to 2hr; leave >2hr or <5min unchanged).
DNS Cache Size: Currently, this setting seems ineffective. Even when set to 2000, I still experience SERVFAIL issues on my mobile WiFi (using DNSCrypt). If the cache worked properly, these failures would be rare. This feature must be linked to the "DNS Cache List" to be useful.
- Advanced Mechanisms & Workflow
To further enhance performance, I suggest considering:
Asynchronous Updates: When a cached response reaches 15%-50% of its TTL, refresh it in the background.
Auto-Cleanup: A "No-Trigger Auto-Delete" function (e.g., delete entries not triggered in 24 hours) to keep the cache list clean.
- The Proposed Workflow
Essentially, AdGuard should act as a local DNS server for the device. The processing flow would be:
Check Local Cache: If found and TTL valid, return the response immediately.
Cache Miss/Expired: Check filtering rules.
Rule Matched: Block the request, cache the response with a long TTL, and return it.
No Rule Match: Send the query upstream, receive the response, rewrite the TTL if necessary, cache it, and return it.
This approach not only leverages DNS capabilities fully but also reduces both DNS queries and rule-checking overhead. For rule updates, refer to the logic in suggestion #5972.