On Tue, Jul 12, 2016 at 11:03 AM, John R Levine <jo...@taugh.com> wrote: >>> The reason to use TCP framing is so that you can send multiple DNS >>> requests >>> in a single http request and get back multiple answers. Recent messages >>> here suggest that's of considerable interest, and if you're only sending >>> one >>> request, the two bytes of TCP length are tiny compared to the http >>> headers. > > >> Maybe I'm still missing something - so you pack multiple DNS requests in >> single HTTP request, answer#1 takes 5s, answer#2 timeouts, the rest is >> answered from cache. How do you send back the fast answers first without >> blocking when you have just a single HTTP request outstanding? > > > The obvious way would be to send chunked http responses as the answers come > back. See section 4 of RFC 7230. The DNS responses don't have to be in > order.
Great, so you get a couple of queries from DNS/TCP stream and batch them into HTTP request, now you get additional query but your HTTP connection is already blocked and you have to start a new one or wait. After all this is just an optimisation game, perhaps I'm foolish to pursue it, but (for me) it's important to define the requirements before we end up with a long tail of weak implementations. > I don't think anyone sees DNS over http as a general replacement for > ordinary DNS. I see two plausible scenarios: > > * The most likely is javascript apps that want to look up SRV or NAPTR or > something, but can only make http/s requests back to the place the js files > came from. > > * The other is an application that wants to make it hord to observce its DNS > queries, so it uses https to a trusted proxy. > > This should be fine for both of those. > > R's, > John I hope these would be the cases, I thought about search engine results page pushing resolved addresses (secured) for search results ahead of time, but using packed DNS wire format for this is not terribly great. It looks like the motivation is to get around DNS firewalls and filters, which implies deploying a scattered set of "open" resolvers similar to dnscrypt to get around IP blocking. Performance should matter in this case. Marek _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
