On Sun, Apr 13, 2014 at 12:01 PM, Rubens Kuhl <[email protected]> wrote: >>> What about “Just use QUIC” ? It might have a better future with DNS than >>> DTLS. >> >> QUIC is a replacement for TCP and it has a lot of merit for >> applications where requests can be larger than a packet. >> > > “is a replacement for” is a judgement of suitability. Over the years I heard > some people saying DNS should have used TCP with built-in scalability for > large recursive and authoritative servers, so may be QUIC is quick enough to > allow usage in the DNS world. If people converge on replace TCP with QUIC too > that’s fine, but being useful for TCP is not a factor into using in DNS or > not. > >> If the request will fit into one packet and the number of response >> packets is small enough, the simplest approach is one UDP request >> packet and multiple response packets. That means servers are >> completely stateless and we can use anycast etc. > > Stateless is a good thing, but a bit of state can be tolerated if it’s used > for a high steady request volume. For instance, a Google 8.8.8.8 recursive > server, even just one of the servers, likely keeps requesting Alexa-100 > authoritative servers 24x7 without mercy. Requiring state would be bad, but > allowing state where it justifies would be fine by me.
Well you might have a point... But the people who have the problem with latency are the google who want to shave it to the very minimum possible. And they would be the main constituency for QUIC. > Reverting to TCP due to multiple response packets, like is done today, really > isn’t a good criteria, but query rate would be. Want a less than x queries / > minute ? Do totally stateless. Want more than that ? State is required. We > would get rid of one of the DDoS vectors that exist today (high > amplification attacks from a low number of fast compromised machines). The way I avoid the DDoS attack is to authenticate requests so they only get a response if there is a valid ticket. Amplification attacks are no longer an issue. -- Website: http://hallambaker.com/ _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
