555
17th August 2010, 11:44 AM
http://www.ietf.org/id/draft-yao-dnsext-identical-resolution-01.txt
It was recognized as part of the original specification of the DNS
that a host can have many names; in fact this expectation predates
the DNS, referring to the earlier specification of host names. In
the simplest case for "aliases", Internet users need these multiple
names to be resolved to the same IP address by a DNS server. The
CNAME record [RFC1034], where "CNAME" is an abbreviation for
"Canonical Name", is a way to designate aliases of the "real" or
canonical name of a host. In some cases, CNAME can be used to
produce the necessary association a bundle of variant domain names.
But the CNAME only maps itself, not its descendants; in fact it is
defined to not have descendants, as it is the only name at a node in
the DNS tree and can't exist at the same name as delegation. In the
case of IDN variants, however, it is often desirable that the name
map both itself and its descendants.
________________________________________________________________________
The advantage of BNAME is that it would enable a class of "aliasing"
behavior that some operators find desirable, particularly in
preference to some of the provisioning overhead they describe having
to deploy to support potentially large numbers of "bundles" of
variants at multiple levels of the DNS tree. The disadvantage is
that it may not provide the behavior people really want while
requiring the time and resources to code and deploy any new DNS
facility.
Alternatively, a proposal has been made that would leave CNAME as
already specified, but eliminating the constraint that a CNAME must
be alone at a node in the DNS tree. This would avoid any coding and
deployment overhead associated with new RRtypes, while obtaining the
desired behavior. Concerns expressed about it, however, include the
possible (but not yet specified) effort required for backwards
compatibility to avoid harm to implementations that expect, and use,
the old behavior.
It was recognized as part of the original specification of the DNS
that a host can have many names; in fact this expectation predates
the DNS, referring to the earlier specification of host names. In
the simplest case for "aliases", Internet users need these multiple
names to be resolved to the same IP address by a DNS server. The
CNAME record [RFC1034], where "CNAME" is an abbreviation for
"Canonical Name", is a way to designate aliases of the "real" or
canonical name of a host. In some cases, CNAME can be used to
produce the necessary association a bundle of variant domain names.
But the CNAME only maps itself, not its descendants; in fact it is
defined to not have descendants, as it is the only name at a node in
the DNS tree and can't exist at the same name as delegation. In the
case of IDN variants, however, it is often desirable that the name
map both itself and its descendants.
________________________________________________________________________
The advantage of BNAME is that it would enable a class of "aliasing"
behavior that some operators find desirable, particularly in
preference to some of the provisioning overhead they describe having
to deploy to support potentially large numbers of "bundles" of
variants at multiple levels of the DNS tree. The disadvantage is
that it may not provide the behavior people really want while
requiring the time and resources to code and deploy any new DNS
facility.
Alternatively, a proposal has been made that would leave CNAME as
already specified, but eliminating the constraint that a CNAME must
be alone at a node in the DNS tree. This would avoid any coding and
deployment overhead associated with new RRtypes, while obtaining the
desired behavior. Concerns expressed about it, however, include the
possible (but not yet specified) effort required for backwards
compatibility to avoid harm to implementations that expect, and use,
the old behavior.