On Jun 12, 2008, at 6:25 AM, Gervase Markham wrote: > Is there a particular reason that DNS is a better mechanism than HTTP, > in your view? Or is that an implementation detail?
The DNS occurred to me because it's already used for carrying domain names, and also because I've been doing DNS for a long time, so it's a comfortable tool for me. HTTP would work as long as the queries were for specific domain names. However, you would miss taking advantage of all the work DNS server implementors have done to make DNS lookups really fast. Also, I suspect the overhead of an HTTP request is substantially higher than the overhead of a DNS request when you think about all the groovy headers that normally get stuffed into HTTP, particularly if you want to use SSL. With DNSSEC, the DNSSEC server signs a zone once and then just answers you with the signed data when you ask for it. Whereas with HTTPS the HTTP server has to re-sign the data for every query. Also if you use DNS you get to take advantage of peoples' DNS caches to reduce the load on your server. If you use HTTPS, your server is going to see every query from every client. > An assemble-and-cache-the-data-from-DNS scheme would be an > order of magnitude more complex. That really wasn't what I had in mind. What I had in mind was more of a lazy evaluation scheme, where you look the data up when you need it, and if the lookup fails you fail safe (that is, treat the domains as if they are not equivalent). I don't think either scheme is really all that complex, but I admit that I probably don't know what the issues are. I guess you're trying to avoid the possibility of the lookup failing, which makes sense, but if you have good anycast coverage I don't think that's a real issue - if the DNS isn't working, the page fetch would have failed. Please let me know if there's anything I can do to help. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
