In message <cf9fdbdd.117d1%bob.hal...@nominum.com>, Bob Halley writes: > 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.
No. Your analysis is faulty. ENAME could be used immediately once the authoritative servers for the zone support it. It would just be insecure until validators catch up. ENAME + old algorithm would be illegal and would be enforced by signing code and authoritative servers. > 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! We have already managed two DNSSEC validator change, NSEC -> NSEC + NSEC3 (algorithm bump), and adding DNAME awareness to DNSSEC (type code roll, though we could have done it using a algorithm bump) and the world did not end. If we wanted to do it we could deploy this on multiple implementations before the end of the year. It just requires the will to do it. There is nothing in the proposal that is technically harder than what we are already doing when validating or have already done in terms of transition management. > 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. Nobody is saying don't get SRV support in HTTP 2.0. I would love SRV or even a HTTP record to be support in HTTP 2.0. There is however a need to be able to fully redirect a zone. CNAME cannot be used along side DNAME. There is also a needed for aliasing by type. These needs will come up again. We can deal with them now or deal with them later. > /Bob > > _______________________________________________ > 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
