Re: The state of DNS support, was Deprecating SPF
Andrew Sullivan <[email protected]>
| Newsgroups | gmane.ietf.dnsext |
|---|---|
| Message-ID | <[email protected]> |
On Sun, Aug 25, 2013 at 04:21:33PM -0700, David Conrad wrote: > > I suspect this won't matter. People's minds are made up. Actually, mine isn't. That's an interesting example. What would be helpful to me is an understanding (and I really don't have any) of why you think the analogy actually shows we ought to move to type-99 instead ot sticking with type-16. As I understand the http/1.0 vs /1.1 trade-off, the 1.0 server suffered latency disadvantages as opposed to 1.1. Therefore, there was an automatic incentive to support 1.1 as soon as possible, even if no client supported it, because for any client that supported it there was an automatic advantage in latency. At the same time, there was an incentive for every client to support 1.1, because if the server did there was a latency advantage. And because of the signalling available by virtue of the header, http sessions could downgrade without starting all over. I'm completely prepared to be corrected on any of this, since I wasn't involved and when it was an issue I was only remotely involved in the effects (i.e. I was an http enthusiast as someone who thought the web was cool, but I was a philosophy student. I thought smarter people than I would fix it, and they did). The proposal in the SPF case doesn't seem to match this. Because DNS is connectionless, we don't have a way to downgrade depending on what the querying agent says it can do. The counter-examples -- DNAME and DNSSEC are the obvious cases -- actually show what a big deal this is. So the transition strategy in this case involves every actor either paying a cost up front with no direct benefit, or else a strategy that prefers the pre-transition state with the desired state a second-best alternative. This seems like a significant difference to me. What did I miss? Best, A -- Andrew Sullivan [email protected] _______________________________________________ dnsext mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsext