You can measure when to stop publishing A/AAAA records with HTTP by pointing the HTTP record at a different address. Clients that are HTTP record aware will use one address and legacy clients will use the other address.
Mark -- Mark Andrews > On 6 Nov 2018, at 05:16, Tony Finch <[email protected]> wrote: > > Joe Abley <[email protected]> wrote: >> On Nov 5, 2018, at 15:35, Måns Nilsson <[email protected]> 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. > > Exactly. > >> A reasonable starting point would be to survey the existing >> implementations and ideally get the enterprise DNS providers responsible >> to join in. > > I've had informal chats with people from a number of big DNS providers. > > * One or two big DNS providers see better interop as beneficial to > themselves as well as their customers. (I guess if two DNS providers > can get a customers to pay both of them then everyone is happy!) > > * Standardization is a tempting opportunity to rationalize services and > reduce technical debt. > > * Dynamic on-demand ANAME substitution is difficult to do with reliably > good performance at scale. > > * Frequent UPDATEs are not something you want at large scale. > > * One CDN said they wouldn't do general ANAME, only their existing > vertically-integrated setup where the CDN controls the (notional) > target. > > So it's a mixture of great desire to have a solution to the problem, but > the auth-side solutions are unappealing to many key players. My plan was > basically to write a draft that waves its hands vigorously and says, yes! > whatever you are doing can be made to fit ANAME! But that won't work if > the response is, We aren't doing anything like ANAME and we don't want to > do anything like THAT. So I'm feeling less confident that it's going to > get consensus. > >> 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. > > Yes. I kind of feel in a weird superposition of states, believing both > Evan's skepticism, and Ray's optimism. > > I'm not sure what Web browser feature deployment timescales are like now. > Picking a random example, from https://caniuse.com/#feat=flexbox it looks > like full flexbox support started appearing in 2012 and it's now at about > 96% availability (most of the gap being due to IE). > > But for ANAME we're also concerned about other HTTP clients, especially > dozens of programming-language-specific libraries and long-term-support > enterpriseware with much slower deployment timescales. And ANAME is also > useful for ssh clients, though they don't have such a large userbase, but > ssh is very relevant to Tim's comments in his presentation about on-demand > compute services. > > Which implies that even if HTTP records become a thing, there will be a > period of years during which zone admins will also have to provision > address records for backwards compatibility. What we have seen again and > again in this kind of situation is that operators will react with, What > benefit do I get from the effort to learn this new thing and the extra > work to support it? For HTTP records I fear the practical benefits in the > short term will be zero. > > Or maybe there are ways to get positive benefits. If ANAME stalls I'm > inclined to implement auto-provisioning of address records driven by HTTP > records instead, as a non-standard short-term backwards compatibility > stop-gap. > > Tony. > -- > f.anthony.n.finch <[email protected]> http://dotat.at/ > Biscay: Cyclonic, becoming westerly later, 5 to 7, increasing gale 8 or severe > gale 9 for a time in south. Moderate or rough, occasionally very rough in > south. Rain or thundery showers. Good, occasionally poor. > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
