Adding CNAME for the root domain issue

[Matthew Pounsett]

On 27 April 2016 at 07:40, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:

> On Wed, Apr 27, 2016 at 07:32:48AM -0700,
>  Matthew Pounsett <matt at conundrum.com> wrote
>  a message of 49 lines which said:
>
> > One of these days I'd like to lead a serious lobbying effort against
> > the browser developers at the W3C to have SRV records for HTTP
> > standardized.
>
> I fully agree and, if you're brave enough to propose it to the DNSOP
> working group at IETF, I volunteer for reviewing/etc.
>
> There is a starting point:
>
> https://datatracker.ietf.org/doc/draft-andrews-http-srv/


Unfortunately, the problem is not one that can be easily fixed at the IETF.
   I'll go have a look at Mark's draft, but here's the core problem as I
see it:

RFC 2782 (SRV) says:

Applicability Statement

   In general, it is expected that SRV records will be used by clients
   for applications where the relevant protocol specification indicates
   that clients should use the SRV record. Such specification MUST
   define the symbolic name to be used in the Service field of the SRV
   record as described below. It also MUST include security
   considerations. Service SRV records SHOULD NOT be used in the absence
   of such specification.


This means that SRV records will not (can not) be used for the web until
the HTTP spec says they can.  This requires W3C action.

At the same time, the browser developers, almost without exception, refuse
to implement SRV because they don't like the idea that they might have to
do another DNS lookup prior to displaying a web page.  And they lobby the
W3C pretty hard to not standardize SRV for HTTP.

That's a pretty serious impasse .. and one that I think is only going to be
overcome by an equally strong lobbying movement from the DNS hosting
industry, when we get tired of trying to educate end users on why CNAME at
apex won't work (end users who don't–and shouldn't need to–care), and get
tired of maintaining messy record synthesis processes.

But this is getting way off topic for BIND-users, and should probably be
moved to dns-operations at dns-oarc.net if we want to continue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160427/79a98fcd/attachment.html>