I too think the SRV route is far better. I've always thought it was an architectural mistake to be looking up hostnames when what you wanted was a service. SRV records have priority, weighting, and the ability to specify a port, all of which are useful. Since the owner name for a service whose URL would be at a zone origin is *not* at the zone origin, ordinary CNAME is still possible if you want to have the SRV in the control of the CDN.
ENAME does not have a good transition mechanism for DNSSEC. If you do not know the new algorithm(s), you will not be able to validate, and a zone signed with an earlier algorithm will not work either as the synthesized CNAME will not validate. ENAME can thus not be used with DNSSEC until there is sufficient adoption of the new algorithms by the installed base of resolvers. Anything which requires DNSSEC validator changes is a transition disaster that will become totally untenable if DNSSEC is ever widely deployed (in the "millions of zones signed" sense). That level of deployment has not yet occurred, but nevertheless I think that DNSSEC validation process changes should be held to the very strictest standards and only be contemplated for dire problems. This is *not* a dire problem! I think we should encourage the use of SRV in HTTP 2.0. We can also recommend that if people are contemplating ever needing to use a CDN, then they shouldn't publish URLs with names at zone cuts. /Bob _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
