> On 20 Jun 2018, at 8:56 am, Paul Vixie <p...@redbarn.org> 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 <d...@virtualized.org> > Sent: 2018-06-19 - 18:44 > To: Ray Bellis <r...@bellis.me.uk> > Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex > >> On Jun 19, 2018, at 2:03 PM, Ray Bellis <r...@bellis.me.uk> 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 >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
