Repository navigation
RFC 6762/10.4 Cache Flush on Failure Indication #1413
Description
Is there a mechanism to indicate to Zeroconf/AsyncZeroconf or ServiceBrowser/AsyncServiceBrowser that a cache entry might be stale, based on application level failures on connecting to advertised services?
https://datatracker.ietf.org/doc/html/rfc6762#section-10.4
The software implementing the Multicast DNS resource record cache
should provide a mechanism so that clients detecting stale rdata can
inform the cache.
When the cache receives this hint that it should reconfirm some
record, it MUST issue two or more queries for the resource record in
dispute. If no response is received within ten seconds, then, even
though its TTL may indicate that it is not yet due to expire, that
record SHOULD be promptly flushed from the cache.
So it looks like an optional feature according to the RFC, but would be nice to have (if it's not there already, I'm new to this library).
Activity
bdraco commentedon Sep 24, 2024
This isn't implemented, but a PR to do so would be welcome
lenard-mosys commentedon Sep 25, 2024
Cool! I can't promise anything, but I might try if I find the time. Anyway, I think the rough outline of such a feature would be:
ZeroconfandAsyncZeroconfthat requests this reconfirmation of a given cache record. Doesn't return anything, semantically it just "pokes" the cache.Zeroconfare notified similarly as if the resource was flushed due to TTL expiration (I assume that browsers get aServiceStateChange.Removed, not sure if they get any other metadata, or if they need to).For naming I could think of these options:
reconfirm, stolen from this avahi PR: Reconfirm avahi/avahi#229,indicate_failure, to mirror the RFC section title.bdraco commentedon May 21, 2026
@bluetoothbot implement