On Nov 5, 2018, at 15:35, Måns Nilsson <mansa...@besserwisser.org> wrote:
>> I think a resolver-side or client-side alternative (like the various >> web-specific record types we have been discussing) is defintely soemthing >> we should aim for in the long term, but that isn't what this work is >> about. > > IMNSHO _any_ work on "fixing CNAMES at apex" that gets traction is > a spanner in the works for what we seem to agree is a better solution. > A interim fix will be deployed and stall every attempt at DTRT. I think you are both right. First, pragmatically speaking, there is clearly demand for something that can do "CNAME at apex". DNS companies sell it, people buy it. It already exists, but in as many flavours as there are providers that support it, so interop is difficult. Having multiple providers is good; interop makes that easier. Maybe there's work that the IETF could do here, but I would suggest that a solution that nobody implements is not much use. A reasonable starting point would be to survey the existing implementations and ideally get the enterprise DNS providers responsible to join in. Second, what is the longer-term solution that seems least likely to cause painful intestinal cramping and bleeding eyes? I agree that if we want a clean answer we should be looking at the clients, not the authority servers. We have application-specific records like this for mail; I think we can confidently call MX a good solution for that problem. We decided that creating an unbounded set of application-specific RRTYPEs for this (each with their own semantics, each implemented separately) was idiotic, and and hence SRV. Let's not abandon that thinking unless we really have to. Various people have expressed dubious arguments against the use of SRV for this. I don't think the answer to that is to create something functionally identical with a different name and somehow expect to be able to trick people with sleight of hand. I think the answer is to document the use-cases and dispassionately assess each of the arguments and work out whether they are real. My suspicion is that for a significant proportion of the problem space SRV is quite sufficient, and that in pragmatic terms we're really only talking about something like three client-side codebases that would need to implement it before we could call it universally-deployed. But I could be wrong and maybe there really is a convincing reason to design something HTTP-specific. Either way, I think we need to show our working here, and by "we" I mean web people and DNS people who are prepared to work together. So for what it's worth, this is what I think we should be doing: 1. Make the existing, proprietary, non-interoperable dumpster fire better if we can (maybe we can't; the way to tell is whether the enterprise DNS people are interested); 2. Find a client-side solution to this, and try really hard not to invent something new that is really just SRV with a hat and a false moustache. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
