>> 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. 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). > What might be rather surprising is that we can fit a complex DNS > transaction into one request packet, for example, to resolve > http://www.example.com/ we might want to do the following lookups: > > www.example.com ? A > www.example.com ? AAAA > _http._tcp.www.example.com ? SRV > _http._tcp.www.example.com ? POLICY > > Although the DNS protocol allows for multiple queries per request, > this doesn't quite work because there is no way to specify which > response code matches which query. So the simplest approach turns out > to be to encode these as four separate DNS queries. But even with that > overhead, we can fit all four queries above plus a MAC and a key > identifier into one 1400 byte request packet. > > > The nice thing about this is that it means support for the secure DNS > actually reduces the load on the server. Instead of making at least > two separate queries (A, AAAA) there is a single query. Since the > crypto overhead is negligible (its all symmetric key), this is almost > certainly a net win as most servers are I/O and transaction bound > rather than CPU bound. Either with DTLS, QUIC or something else, that would be a sound design to have. Rubens _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
