On Tue, Jun 19, 2018 at 11:24 AM, Ray Bellis <r...@bellis.me.uk> wrote:
> On 19/06/2018 15:43, tjw ietf wrote:
>
> > I find it personally appalling we can spend so many cycles injecting
> > dns into http but we can’t be bothered to fix what end users want.
>
> It's the HTTP folks that are putting most of those cycles into DNS into
> HTTP.
>
> It's also their intransigence re: SRV which has caused the CNAME at the
> Apex issue. CNAME was *never* the right answer for doing application
> level indirection in HTTP space.
>
SRV has enough limitations that the risk/reward for adding it into the DNS
lookup chain made it hard to swallow for many HTTP/browser folks.
The most recent proposal on this front for an ALTSVC DNS record:
https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02
adds value well beyond what SRV does and seems much more likely to
get interest/traction from browsers from discussions.
Although it is more annoying for users than just CNAME'ign the apex,
the ALTSVC DNS record would solve the problem for the HTTP case
where there's the most practival issues today. The ALTSVC DNS record
approach also has minimal camel impact on the DNS side as it
doesn't require special handling by resolvers or authorities.
I think we should seriously consider seeing if we the ALTSVC DNS
record case covers enough of the use-cases of ANAME that we can
abandon ANAME and focus effort there instead? Having multiple
mechanisms solutions to the same problem means we may not
get critical implementation mass on any of them.
Erik
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
