In message <20140518163140.gb27...@solar.andreasschulze.de>, Andreas Schulze wr
ites:
> Mark Andrews:
> > domain ENAME domain {0|1} [type list of included / excluded types]
> > (0 == include, 1 == exclude)
>
> Mark,
>
> I currently don't see, why ENAME will be usefull. Could you (or other)
> clarify in which scenario ENAME would be helpfull?
>
> Or what like to ask:
> How has my problem to look like that this solution will help?
>
> Andreas
The reason why CNAME is prohibited at a zone apex is described in RFC 1034:
"The domain system provides such a feature using the canonical name
(CNAME) RR. A CNAME RR identifies its owner name as an alias, and
specifies the corresponding canonical name in the RDATA section of the
RR. If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different. This rule also insures that a cached CNAME can be
used without checking with an authoritative server for other RR types."
Named probibits CNAME and other data when loading zones because of
this and because we had too many "bug" reports where people only
wanted CNAME to only be followed when there wasn't a type already
there. Making it fail at load time rather than run time got rid
of the later compliants replacing them with "why can't we have a
CNAME at the apex", but then it was just a matter of referring them
to RFC 1034.
ENAME lets a resolver know whether a particular type is covered by
its alias functionality or not. This avoids the issues cause by
having CNAME and other data as described above .
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
