In message <[email protected]>, Masataka Ohta writes: > Mark Andrews wrote: > > >>> The reason why CNAME is prohibited at a zone apex is described in RFC 103 > 4: > >> > >> If we must change something, isn't it easier to allow CNAME at > >> a zone apex than introducing ENAME? > > > > No. They are roughly equally difficult and allowing CNAME at the > > apex still won't solve > > See below. > > > CNAME + MX or CNAME + DNAME or CNAME + TXT > > or CNAME + just about any other type. > > What's wrong with allowing a zone apex have SOA, NS, CNAME but > nothing else? > > > The zone apex has lots of > > data stored at it. > > Nodes, not necessarily zone apex, having lots of their own > data can not have CNAME. So?
I'm saying just allowing CNAME + SOA + NS + DNSKEY doesn't help in the grand scheme of things. It just moves the problem rather than fixing the problem which is two organisations wanting to change data at the same node. The data stored at www.example.net is usually very different to the data stored at example.net. For www.example.net you often don't care about anything other than A and AAAA. The same can not be said for example.net even after you remove SOA, NS and DNSKEY from the evaluation. > > You have to do a DNSSEC algorithm bump. > > No, I don't, because I think DNSSEC must be obsoleted. > > Anyway, special treatment for CNAME in DNSSEC is no > different regardless of whether a node is a zone apex > or not. > > > You have to update recursive servers > > to know about the new CNAME semantics. > > The update is never rely on cached CNAME for SOA or NS query. > > Thus, even without the update, most people won't notice lack > of the update. Most != all. > > You have to have a transition > > strategy. > > First, change name server implementations. Then, declare > that people can use CNAME at zone apex. That's all. > > Masataka Ohta > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
