that depends on the FQDN in question.
For DNS zones, the “SOA” (state of authority) record as well as individual TTLs tell DNS resolvers how long an information retrieved is valid, how long a non-existing information is valid, and much more.
kernel.org’s A record, which contains the IPv4 address(es) this FQDN is served by, has currently set a TTL of 300 seconds (= 5 minutes), so DNS resolvers will not update this information 300 seconds after the first successful DNS query has been made.
$ dig a kernel.org
; <<>> DiG 9.16.6 <<>> a kernel.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18298
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;kernel.org. IN A
;; ANSWER SECTION:
kernel.org. 300 IN A 184.108.40.206 <<<<<
;; Query time: 115 msec
;; SERVER: x#53(x)
;; WHEN: Sa Jul 09 09:42:35 UTC 2022
;; MSG SIZE rcvd: 55
You will see all kind of TTLs in the wild, ranging from seconds to days if not weeks. It is also worth noticing that these can change, should an operator deem such a change necessary.
IPFire’s DNS proxy/resolver does not enforce any custom upper or lower boundaries to TTLs.
If I recall it correctly, overriding TTLs on a domain-basis is not possible. Generally, TTLs can be constrained to certain ranges, but this causes more harm than good.
I suggest you to run
dig a [your DDNS FQDN]
and see which TTL your DDNS provider has set. It should be pretty low, something between 60 and 600 seconds. If not, please get in touch with their support desk.
unbound-control flush_zone .
(the trailing dot is important) on your IPFire machine.
Thanks, and best regards,