Add response TTL settings

[computator]

In #312 the response TTL was reduced drastically, but even 60 seconds is too long if it's being used for load balancing. I would like to be able to configure the TTL to something more like 5 seconds or even turn it off entirely.

[flouthoc]

Making it configurable sounds good, but problem is that then config has to be propagated through podman or some environment variable since users don't directly call aardvark-dns. @Luap99 WDYT ?

[oliversalzburg]

I stumbled over all the TTL-related issues in aardvark-dns yesterday and am trying to make sense of the story. What was the original idea behind a 24 hour TTL for an information that is potentially different on every lookup? This is the state Debian consumers will probably have to deal with for the next couple of years. There's nothing more recent than 1.4.0 on the roadmap as far as I can tell.

The solution, to drop the TTL to one minute in 1.6.0, is another poor choice IMHO. The fact that "normal resolvers" wouldn't cache this information at all even came up in the discussion. Yet, it was decided to continue on this path. The motivation for this isn't entirely clear to me. Trying to solve performance issues here seems like very premature optimization and the approach just introduces new issues. This behavior must be in the control of the user.

dnsmasq provides a --local-ttl option, for which the documentation says (emphasis mine):

When replying with information from /etc/hosts or configuration or the DHCP leases file dnsmasq by default sets the time-to-live field to zero, meaning that the requester should not itself cache the information. This is the correct thing to do in almost all situations. This option allows a time-to-live (in seconds) to be given for these replies. This will reduce the load on the server at the expense of clients using stale data under some circumstances.

If anything, setting a non-zero TTL on aardvark-dns responses should be the challenge here, not fighting stale DNS caches.

[Luap99]

Let's just set to 0, I do not see a strong reason why it would need to be cached.

[WintersMichael]

I know I'm new around these parts, but IMO it would make sense to keep this machinery in place with a default of 0 and allow people to configure it if they prefer the reduced load. (In some scenarios, even a cache of 1s would be a dramatic reduction.)

I agree that 60s is way too long, so we could close this issue by just changing the default and leave the config option for a future change.

[Luap99]

Yes the problem is we do not have config file for aardvark-dns today, and if you (ab)use containers.conf we still would need a way to pass the option alone for podman -> netavark -> aardvark-dns so nothing easy.

I was just looking for some easy fixes and looking at dig's reported query time I see 0 or 1 msec reported so I don't think there is a measurable overhead in normal scenarios. Of course if your application does thousands of these lookups per second then sure but at this point just fix you application to not do so many lookups.

[WintersMichael]

That would mean basically hardcoding a non-zero TTL into the app, which is certainly doable but not supported by most common (non-bespoke) apps.

That said, the number of users that care about Podman networking load is probably pretty small and we can always bring this back later if we decide on a config method. I wasn't sure how we felt about putting more config in containers.conf, which is what I would have done.