Tweak cache settings

[IngmarStein]

I think the current cache settings of cache 600 could be changed a bit to address this issue:

HA queries for AAAA records whenever a hostname is used in an integration: https://community.home-assistant.io/t/disable-all-these-useless-aaaa-requests/729016. In IPv4-only networks, it receives NODATA responses mostly without SOA records which are then only cached for 5 seconds. If there are several integrations which frequently poll data (e.g. to submit PV production data to a wallbox), this quickly adds up.

In order to mitigate that, one could set a minimum TTL value, e.g. of 300 seconds:

cache 600 {
    success 9984 600 300
    denial 9984 600 300
    prefetch 10
    serve_stale
    servfail 10
}

Btw, what is the reason for reducing the maximum TTL to 600? The defaults are 3600 for NOERROR responses and 1800 for NXDOMAIN.

[agners]

In IPv4-only networks, it receives NODATA responses mostly without SOA records which are then only cached for 5 seconds.
[...]
In order to mitigate that, one could set a minimum TTL value, e.g. of 300 seconds:

Hm, are we working around a Core issue here? What is the typical behavior of resolvers in this case?

I am not against tweaking CoreDNS behavior for Core specific behavior, but I think we should be aware why we need to deviate from what is otherwise a seemingly fine default for other CoreDNS users.

Otherwise we'll run into the same issue you run with your next question:

Btw, what is the reason for reducing the maximum TTL to 600? The defaults are 3600 for NOERROR responses and 1800 for NXDOMAIN.

I am not aware of any specific reason for this setting.

Looking at the git history this started off with very short caching settings in #12, and got relaxed to todays value in #48.

Also it seems the fallback config has no maximum TTL, whereas the tempio one has. I think this is an unintended difference too. Since I don't know the exact reasons I am ok going default on all of those settings.

[IngmarStein]

Hm, are we working around a Core issue here? What is the typical behavior of resolvers in this case?

I don't know. Afaict, Core is a dual-stack application which follows the Happy Eyeballs algorithm and requests AAAA and A records in parallel when resolving hostnames. This is just suboptimal in IPv4-only home networks where the responses are always NODATA or NXDOMAIN.

There are options to disable that like the no-aaaa option in /etc/resolv.conf:

no-aaaa (since glibc 2.36)
Sets RES_NOAAAA in _res.options, which suppresses
AAAA queries made by the stub resolver, including
AAAA lookups triggered by NSS-based interfaces such
as getaddrinfo(3). Only DNS lookups are affected:
IPv6 data in hosts(5) is still used, getaddrinfo(3)
with AI_PASSIVE will still produce IPv6 addresses,
and configured IPv6 name servers are still used.
To produce correct Name Error (NXDOMAIN) results,
AAAA queries are translated to A queries. This
option is intended preliminary for diagnostic
purposes, to rule out that AAAA DNS queries have
adverse impact. It is incompatible with EDNS0
usage and DNSSEC validation by applications.

But that seems like it might have unintended side-effects and I haven't tested it myself.

I am not aware of any specific reason for this setting.

Thanks for the code archology! Neither PR provides an explanation for setting the maximum TTLs and it might be unintentional given their titles "Offload config handling to plugin" and "Cleanup config".

Going back to the default sounds like a reasonable plan.