On 19 Jun 2018, at 17:03, Ray Bellis <r...@bellis.me.uk> wrote: > On 19/06/2018 17:44, Tony Finch wrote: > >> SRV should have been part of the fix (and it was invented early >> enough to be!) but it wasn't a complete fix without support from the >> application protocols. > > AIUI, a large part of the supposed issue with SRV was the inertia of the > installed base of browsers that wouldn't know how to access them. > > Ironically the proposed fix seems to require upgrades to the > installed base of one of the most important network infrastructure > services on the planet. > > Meanwhile, a very large portion of the installed base of web browsers > gets automatically and silently upgraded every month or so...
I think so long as there's a fallback for clients that don't yet have SRV implemented (e.g. publish A/AAAA RRSets at the same owner name as the SRV RRSet, and specify the behaviour by SRV-compliant servers in the event that both are present) this is not a plausible engineering argument. Processing an SRV might require additional DNS lookups to get name -> SRV -> SRV target -> address, but that's a one-time hit per TTL and I think it's a stretch to paint that as definitely a problem. Modelling is required and worst cases remain to be understood. If there are definitive problems it would be good to hear what they are. It has always sounded to me like the problem is "this is not how we did things before". Perhaps the cost of change is not actually in the client, but in the provisioning/client education/product packaging across all web and hosting services? Joe
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
