Paul Vixie wrote:

> Ray Bellis wrote:
>
> On 21/09/2018 20:12, Dan York wrote:
>
>
> I do think this is a path we need to go.  We need *something* like
> CNAME at the apex.  Either CNAME itself or something that works in the
> same way but might have a different name.
>
> [...]
>
> i think that makes HTTP as fast in terms of round trips as SRV is.
>
>
>    Also, the presence of the Port field in an SRV record is incompatible
>    with the "Same Origin" security policy enforced by web browsers and
>    in practise the load-balancing / fallback capabilities of the SRV
>    record are not widely used either, ...
>
> so use "0" for the port number, and don't include more than one SRV RR.
>
>
>
> there's no benefit to accompany the cost of this proposal compared to re-use
> of existing code points which are already broadly implemented.
>
>
>
So, the counter-arguments (or better, facts) are:

   - The existing code points (SRV etc), for whatever reason, are not being
   used (fact)
   - Providing Ray's "http" solution, enforces the equivalent of "use '0'
   for the port number", implicitly (fact)
   - The cost is extremely low, i.e. adding the new code point to authority
   servers with no new logic or RDATA format required (argument or fact)

IMHO, opposing http on the basis of extremely marginal development cost and
no operational cost (as a differential comparison to SRV), and otherwise on
the vague assertion that the browser folks won't use it, isn't helpful.

At worst, it gets adopted and fails to make significant deployment.

At best, it gets adopted and deployed and used with significant uptake,
especially in the CDN vendor space, and everybody wins.

It's a lot better than ANAME, and I think we do a disservice to ourselves
as a DNS community, if we do anything other than put our collective support
into it, preferably unanimously.

I see getting http adopted and deployed, and fixing the single major
web-specific deficiency in DNS, as critical to attempting to head off DoH,
which is the biggest bugbear at the moment.

Brian
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to