fix: cap TTL to 10s in legacy unicast responses - #504
Merged
Merged
Conversation
Problem: RFC 6762 §6.7 requires the records in a legacy unicast response to carry a TTL no greater than 10 seconds, since legacy resolvers cache them without the mDNS cache-coherency mechanisms. Responses went out with the records' true TTLs (120s for host records, 4500s for PTR/TXT). Fix: Fold the TTL cap into the existing per-record pass that clears cache-flush bits, renaming clear_cache_flush_bits() to update_records_for_legacy_unicast(). Add the LEGACY_UNICAST_MAX_TTL constant and assert the cap in test_legacy_unicast_response. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes: #496 , the second problem.
Implement this part in RFC 6762 §6.7:
The resource record TTL given in a legacy unicast response SHOULD NOT be greater than ten seconds, even if the true TTL of the Multicast DNS resource record is higher. This is because Multicast DNS responders that fully participate in the protocol use the cache coherency mechanisms described in Section 10, "Resource Record TTL Values and Cache Coherency", to update and invalidate stale data. Were unicast responses sent to legacy resolvers to use the same high TTLs, these legacy resolvers, which do not implement these cache coherency mechanisms, could retain stale cached resource record data long after it is no longer valid.