In your letter dated Fri, 03 Jul 2026 06:05:51 -0700 you wrote: >You and Ben suggested basically the same thing, which definitely is an >option. That does require hashing for every request on the server side, >or keeping state of the hashes on the server side for performance >reasons. But in the end, your signal to the client is about the same: >yes it's changed, but it's too large (TC) and so you need to get more >data. > >In the end I chose to put the decision burden on the client rather than >the server, as the server in the end basically always has to say "yes >come back to get more" or "you don't need more" and that response will >always be the same independent of whether the client sends additional >data or not (assuming the TC bit needs to be set).
Some random thoughts: - a client may always send a request over TCP if it expects a large response. The current proposal seems to prevent a client from learning that the server supports this document - client software architecture may have the retry-over-TCP logic deeply embedded for TC. This may make it very unattactive for the client to implement this document. - This document doesn't discuss how a cluster of servers would arrive at the same LARGE value. - Assuming the validity of a DNSSEC signature is relatively long (say one month) then I don't see how to guarantee proper LARGE values without persistently storing them. That would make this draft very unattactive for authoritative servers. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
