Mark Andrews wrote:
>>> The reason why CNAME is prohibited at a zone apex is described in RFC 1034:
>>
>> 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?
> 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.
> 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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop