is there no event that shows when the system last did a flush?
There is no such thing as "doing the DNS flush at the prescribed interval". The only time the DNS cache is flushed completely is when someone manually does a /flushdns
.
During normal operation, each DNS record expires individually – each has its own TTL that is defined by the operator of the respective domain and starts counting down when the record is queried from its authoritative server. (For example, two records with a 1h TTL queried 30 minutes apart will also be flushed 30 minutes apart.)
(You can use nslookup -d example.com.
to see the TTL included with a particular record; the DNS cache always starts counting down from this TTL and not from any arbitrary value.)
Also, the ttl in ipconfig /displaydns seems to be counting down much faster than the prescribed ttl set.
The registry key you mention only prescribes a maximum TTL for the Windows built-in cache, not a minimum one – meaning that a received TTL of e.g. 24h would be reduced to 3h, but a TTL of 5min would remain 5 minutes.
(Also, the TTL keeps counting down when the record goes through intermediate caches; e.g. if your upstream DNS server has received and cached a record with a TTL of 3600 seconds, your computer might receive it already counted-down to 1999 seconds.)
so when I set the ttl to 10800 that just means it's a maximum to 10800 not that it'll happen at 10800. But doesn't that mean it will automatically happen at 10800 if it hasn't already?
Most likely the setting only limits the TTL of newly stored entries, not of existing ones, because there is no actual "at 10800" time. As I understand it, each cache entry has its expiry time calculated the moment it is stored. That is, instead of "google.com (TTL 9999)", your cache really holds "google.com (valid until 21:58:44)".
due the the way the flush works, does that then mean there is no global flush command that gets enacted.
There is indeed no global flush command. (Moreover, all of this is not happening through any 'commands' either way – it's all just internal logic within the cache service.)
I mean if that counter gets to 10800 does it not do 'something' thus get recorded in events?
No, it doesn't.
For one, there's no real counter that gets to 10800. Although cache entries are described as having a TTL that "counts down" figuratively, the real implementation is unlikely to have individual timers that count up or down – it is more efficient to only do the expiry check when a cache entry is about to be used instead of doing it proactively.
That is, when a domain name is queried from the cache and found to have already been expired, the service quietly removes it and behaves as if it didn't have anything cached. This is both more efficient (as nothing needs to be "counted down" each second) and more accurate than a flush timer, as it guarantees that an entry will disappear from view the moment it's supposed to.
The service may still have some kind of global 'garbage collect' timer, to occasionally release the memory of entries that have already expired, but it should have no visible effect whatsoever – it is not what makes expired entries disappear; it only cleans out already 'disappeared' entries – so it is neither logged nor timed.
(That is to say: It's a completely different situation from e.g. AD or WINS 'scavenging' or tombstone cleanup, which are explicitly scheduled and logged because they operate on database entries that have already been made persistent, have an influence on replication, etc.)
Finally, not all 'somethings' get recorded in event logs. Recording an event is a deliberate action by the service, not something that simply happens on its own, so the service's internal logic can just do things without recording them, especially when it doesn't touch any database but only manages its own in-memory arrays.