Fairly new IETF Variant discussion

[555]

BNAME/CNAME/DNAME/Variants/Aliasing...

http://ietfreport.isoc.org/cgi-bin/htmlwdiff?f1=../all-ids/draft-yao-dnsext-identical-resolution-01.txt&f2=../all-ids/draft-yao-dnsext-identical-resolution-00.txt

Side by side view:
http://bgp.potaroo.net/cgi-bin/htmldiff?f1=draft-yao-dnsext-identical-resolution-01.txt&f2=draft-yao-dnsext-identical-resolution-00.txt

[555]

3.2. Zone Clone

The proposal of "zone clone" or "dns shadow", is an alternative
solution for a higher level of support than the DNS currently
provides for "alias" behavior across zones. In this scheme, a new
RRtype, SHADOW, is specified; it can exist at a zone apex and can be
used to define "clones" or "shadows" of the zone content so that
records in the zone are reachable via lookups from multiple
delegations. This mechanism varies fundamentally from CNAME/DNAME/
BNAME in that it creates a local copy on each cooperating
authoritative server that has the original zone, reachable by the
names specified in the SHADOW RR. Its scope, then, is the zone as
maintained by an authoritative server rather than a single RRset
(even one corresponding to a delegation).

This scheme has the advantage that it allows a SHADOW zone to be used
in all the same contexts as the canonical or underlying zone,
including contexts where a CNAME or DNAME (or, presumably, a BNAME)
cannot appear, such as in the RDATA of certain RRtypes. Of the
proposed DNS protocol mechanisms, it probably comes closest to the
behavior some have requested as "equivalence," where none of the bundled or SHADOW names is canonical or preferred over the others.
It does implicate an unknown level of effort to implement and
support.