* John Heidemann: > - We've done some studies about memory use for TCP+TLS, with real traces > from several several different types of servers. See > http://www.isi.edu/~johnh/PAPERS/Zhu14a.html for the tech report. > (We'd love comments and feedback!)
Did you attempt to filter out garbage queries from your replay data? Especially for the B root, I expect sources that would never be able to complete a three-way handshake because they use incorrect IP sources addresses. I'm not sure in which direction garbage queries tilt the numbers. The stub resolver performance for classic DNS seems to be too good to be true, partly due to the PlanetLab bias (as youn note)—or it measures RRTs to some local non-recursive cache: many access technologies have RTTs to the first IP hop that exceed 5 ms, and you still have to reach the ISP resolver from there. I wonder if it is possible to obtain better data by triggering a cascade of name resolutions from web browsers and try to tell upstream cache miss rate from local stub cache miss rate. > - the high order bit from the study is that with very conservative > (i.e., short) timeouts, and with TCP+TLS from stub to recursive and > TCP only from recursive to authoritative, we see ~21% greater latency > and 9GB of state at the recursive resolver. You can tweak the numbers > to get different trade-offs if you prefer. > > Both of these are more than current UDP, but both are, I think, > "reasonable". And these numbers are quite impressive because the classic DNS baseline you've established seems a bit rosy to me. In any case, interesting work. Compared to DTLS (or any home-grown protocol), the advantage of TLS over TCP is that we have extensive experience in dealing with various kinds of network anomalies, much of which would likely apply directly to protecting DNS infrastructure. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
