I want to retain dynamic control of the apex, but not break standard handling of other RRs (NS, MX).
A domain name (exampleA.net) is controlled by the domain owner (via the domain registrar). The website shall be placed in exampleB.net cloud.
I want to use dynamic addressing (not calling it CNAME at this point), so the system doesn't stall waiting for the manual update of "A"s in the registrar records.
A complete "NS" zone delegation is not applicable.
The logical, simple configuration, which is invalid:
@ CNAME exampleB.net. www CNAME exampleB.net. @ MX mx @ NS ns0 ; ...setting the SOA, A's
"Can't do, breaches RFC"
CNAME per the RFC 2181 simply forbids you multiple RRs, barring you to use apex-CNAMEs, because of SOA and NS.
The "dns error" rfc 1912 calls this practice "often attempted by inexperienced administrators".
Well, I doubt that was true even in 1996, it was just the need for a "dynamic" RR (which CNAME is believed to be, but it's not, for these very reasons).
In fact, it's a fundamental flaw of the domain-naming-system. Besides the inception of the holy apex, it really messes up the www.appendectomy. I'm not taking the "canonical no" for an answer here.
it can be accomplished using a preprocessor such as m4 on your host files.
Real World Issues
BIND with file-based zones will complain and fail a zonecheck if you try this. But using the DLZ will pass and work, as described. Other DNS software might or might not accept this, or they use some special types (ANAME, ALIAS) for this.
Still, if you manage to pull this off, you have been warned.
The headache starts when queries of any types for exampleA.net will sometimes get resolved as CNAME exampleB.net. instead of the configured record.
That might work, will usually fail, or worse, for example in some MTAs lead to the change/redelivery of mail@exampleA.net to mail@exampleB.net
Instead of a compliant failure, the recommended workaround is, by setting (delegating) the RR into the CNAME'd record itself.
If you also manage the particular sub-system, you can "pipe" it:
exampleB.net. MX mx.exampleB.net.
or you can "bounce it back":
; pointing the apex CNAME to a more specific exampleA.exampleB.net. exampleA.exampleB.net. MX mx.exampleA.net.
That's a hotfix at best, doesn't solve the dynamics and leaves the zone exposed to stale configurations and migration booby traps.