Philip Homburg <[email protected]> writes: > - 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
One other thought, that I hadn't documented and shouldn't be in this document, is that really smart resolvers would know what types of requests to make over UDP vs TCP. But, there is nothing wrong with actually fixing your above point by indicating the NN bit even in a TCP response so the client knows it could try UDP next time. Smart clients would probably choose a UDP/NN query until the DNSSEC expiration time and then may even auto-fallback (fall-forward?) to TCP. > - 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. So the NN response could trump that though? I'll defer to the resolver authors to describe how hard it would be to implement the cache lookup deep within TC bit handling or to fail out and return the (old) cached data instead of opening a TCP connection. > - This document doesn't discuss how a cluster of servers would arrive at > the same LARGE value. It deliberately avoids implementation specific decisions of how to craft LARGE identifiers for that reason. We could include some standard mechanisms, for example, but I don't think it needs interoperable standardization -- it becomes authoritative server specific which I think is a benefit (not a detriment). > - 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. You only need to store the 16-bit identifier and only for large records. But yes, there is definitely a resource hit on the server side one way or another which does make it potentially unattractive. Or a calculation on the fly that requires no storage but a CPU hit. There are a number of games that could be played to make this easier though (for DNSKEYs: sum(all_keyids)). That being said, having all DNS requests arrive over TCP (or worse, one UDP followed by one TCP) seems also like an unattractive option. -- Wes Hardaker Google _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
