> On 20 Jun 2018, at 8:56 am, Paul Vixie <[email protected]> wrote: > > Neither. There were additional data rules to mostly prevent a second lookup, > and even in those days, browsers cached hostname to address mappings. > > Browsers didn't adopt because srv didn't solve geo or topology optimization. > For a design change of this size, more payback was needed. > -- > Paul Vixie >
Which is ridiculous given that it really is a *very* small change. GLB should be able to compute "SRV 0 0 80 <target>” and "SRV 0 0 443 <target>" as easily as they compute "CNAME <target>”. That should be no more than 30 minutes work to add even if you are doing it in assembler. It might even be faster in assembler. It uses all the same mechanisms to figure out the target. > ----- Original Message ----- > From: David Conrad <[email protected]> > Sent: 2018-06-19 - 18:44 > To: Ray Bellis <[email protected]> > Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex > >> On Jun 19, 2018, at 2:03 PM, Ray Bellis <[email protected]> wrote: >>> 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. >> >> I thought the more fundamental problem was the additional latency caused by >> the second lookup since SRV specified domain names as targets. >> >> But maybe I’m misremembering. >> >> Regads, >> -drc >> >> _______________________________________________ >> DNSOP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dnsop > > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
