Custom TTL for DNS

[ignoramous]

Let users decide on TTLs for DNS reqs.

Potentially avoid network round trips, thereby reducing latencies.

Save on resources otherwise expended by making DoH or DNSCrypt requests.

[4-FLOSS-Free-Libre-Open-Source-Software]

Custom TTL for DNS for response from app to rethinkdns ? or the TTL of saving time DNS answers withing rethinkdns cache?

lib pdnsd does have the most savings as it have a two layer cache, memory and offline disk that can be even reused after device restart, helping and speedup bootstrap DoH/dnscrypt and can do prefetching on soon to expire cache entries, it's for example bundled within orbot.

lib unbound does even support stale DNS answers if upstream DNS is unreachable/unresponsive/down.

[ignoramous]

This issue is for RethinkDNS to set custom TTL on response and not host its own cache.

Hosting a persistent cache, if useful (like with libunbound stale responses), could be implemented as well... Should probably create a separate issue for this.

[4-FLOSS-Free-Libre-Open-Source-Software]

For answers from both OrBots DNSPort and Socks5 Resolve #284, the default should be zero TTL 0 to prevent any caching for protection. According to Tor, how it is warning its user if you try to enable any DNS caching options:

[warn] The CacheDNS option is deprecated, and will most likely be removed in a future version of Tor. Client-side DNS caching enables a wide variety of route-capture attacks. If a single bad exit node lies to you about an IP address, caching that address would make you visit an address of the attacker's choice every time you connected to your destination.

[ignoramous]

libunbound does even support stale DNS answers if upstream DNS is unreachable/unresponsive/down.

Implemented and enabled optionally via the UI settings DNS Booster, which should release in v054: https://github.com/celzero/firestack/commit/5a907637d0149d9f82225d7e373524ca2408f663

Save on resources otherwise expended by making DoH or DNSCrypt requests.

Coalescing requests (sending at most one request per query name, when multiple requests for the same query name are in-flight): https://github.com/celzero/firestack/commit/2ef1e2f1e5ddaac69afa738fe299216f5ffe0b02

lib pdnsd does have the most savings as it have a two layer cache, memory and offline disk that can be even reused after device restart

No writing to disk, as in our experiments we have found that saving cache responses for too long breaks a bunch of websites that move around IPs.

can do prefetching on soon to expire cache entries,

Prefetching is expensive, especially in scenarios where the device may be woken up from idle. Too much effort to do it right.

---

As for user-provided custom ttl, we may not implement it as it adds needless complexity for the end user? Might as well stick with a custom expiring strategy (we right now have a probabilistic strategy where most used cache items are kept longer but also randomly might be subject to deletion, which I think works better than letting users bet on some fixed TTL).

Thoughts?

(barring any more inputs from existing users, I expect to close this FR on next review).

[steinland1994]

Hi,

since you asked for user input, I thought I'd share my two cents, even if I do not know a lot about programming and have to rely on Wikipedia.

I am strongly in favor for giving users such options.

Caching to disk:

I think this would be a very valuable feature, mostly because of the "Block when DNS is bypassed" feature of the firewall.

E.g. I noticed that my mail client kept failing to fetch mails because ever so often Rethink forgot about the associated DNS record. Also it'd be interesting to have a record which domains used to be associated with which IP, so instead of outright deleting old entries, time-stamping and only returning the newest one might open up interesting options and insight.

Some websites frequently changing their IP doesn't seem like a too large problem to me for several reasons:

• Most importantly, if the entry in non-volatile storage is clearly too old, it can still be ignored.
• If a domain switches to a new IP, there is a good chance the service still remains available at the old IP for some time. Many ISPs are guilty of enforcing very high minimum TTLs on their default DNS and many clients cache IPs for a long time.
• Combined with the majority of services rarely changing their IPs and IPv6 finally getting noticed, only very few services should break because of DNS records which are hours, days or even weeks old.
• Services which do break can be dealt with to some non-insignificant degree: If a cached entry is too old, respond to a query of it with a very short TTL and update it once a new value is available from upstream. Another option is checking if an app successfully connects to an IP a very old DNS entry was served to. And in extreme cases there could be a UI widget which lists apps very old DNS entries were served to with a "This App just broke" button next to it, and then simply increment a Morris counter marking how aggressively a certain domain can be cached.
• My guess is that most domains changing their IP frequently would do so on a schedule. If old entries are available, one could make an informed decision about when an entry from disk is most likely too old (half the longest non-outlier period between IP changes)
• While writing to disk is expensive, it should still be cheaper than using the network, and reading from disk is much much less expensive and will cause barely any degradation
• Since checking the disk every time would be expensive, moderately large cuckoo filters could help (or maybe the DB already has a solution for that?)
• DNS bypass blocking becomes much more useful with a disk cache and could possibly even be extended with a reverse DNS lookup
• A large disk library is very resilient and could bridge DNS issues. Also, if only DNSSEC entries are cached into such a library, it'd be a security feature.

Regarding enforced minimum (+maximum) TTLs:

To some degree it enables the user to enforce sane defaults if there are otherwise none.

But most importantly it allows the user to customize his experience. When I used Invizible I used a 16h minimum TTL, because it got me through the day and I never noticed any problems specific to my usage (your firewall is to kill for, tho, ... now if you added the ability to route selected apps through a VPN and/or Tor and added support to forward certain TLDs to certain DNS servers + captive portal support + multiple DNSCrypt servers and Relay fail over ...)

hand,

A

[ignoramous]

Thanks. I see this feature as important, but only see it as useful for powerusers. Today, Rethink's built-in DNS caching is pretty nifty anyway that most wouldn't feel the need to save DNS responses to disk (although I understand the allure of it).

Coding these features comes with a cost; not just in terms of code, but also in terms of bugs and maintenance: And this makes future changes harder than necessary. That said, this feature request is open because we want to impl this once we get other important tasks, features, and bugs sorted.