Add response TTL settings about aardvark-dns

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

[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 ?