Vernon Schryver wrote: >> [Maybe TCPCT could help.] > > I don't see anything in https://tools.ietf.org/html/rfc6013 that reduces > the costs of TCP for DNS.
there is no direct example showing this in RFC 6013, but it's there. let me explain. in TCPCT, there's a cookie pair that can be (opportunistically -- this isn't a requirement) saved after FIN and reused on the next connection. if this cookie pair is presented to a responder who recognizes it (because the responder also saves these in some kind of short term cache) then the responder can re-use the old window size. also, in TCPCT there's room for a payload in the SYN. in practice this means a normal three way handshake for the first connection between an endpoint-pair, but there's a single round trip on any subsequent connection between that endpoint-pair, involving one packet to send the request, and one or more packets to send the response. there's zero cost to a responder for an embryonic tcp connection in tcpct, everything needed between the initial syn and the syn-ack is contained in a cookie pair that the client has to include in its next packet. obviously there's some cost to remembering previous cookies but it's optional and can be managed in the usual LRU way. this is why i was happy to see this solved at the transport level rather than at the dns level -- i think tcp/80 could benefit from zero state cost in responders, and single round trip for request plus multipacket response, too. see also: <http://static.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf>. > Perhaps you mean T/TCP to bypass the TCP > 3-way handshake. no. t/tcp wasn't secure in several important ways. we have to be able to send a multi-packet response with no chance that we're sending it to someone whose source address was spoofed. > ... > > If you can change the software on 21 million open resolvers > to use DNS over T/TCP, why do the the easier thing of closing them? i agree that closing them is the right thing, but for a different reason: there's no use-case for keeping them open in any form. so when i argue for TCPCT i'm arguing for it on the general principle that we'd like a responder to have proof of requester identity before sending a multipacket response. we would not use these powers to make OR ubiquitous. > If you could change their software and want to keep them open, then > you could install RRL and DNS cookies. The problems that RRL has on > resolvers would be solved with DNS cookies. DNS cookies don't need > kernel changes but only changes in DNS client and server software. > https://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03 alas, this feature combination is far more likely to see wide use than TCPCT is. paul
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
