CNAME Definition
Kevin Darcy
kcd at daimlerchrysler.com
Fri Feb 23 22:54:39 UTC 2001
Okay, you're right. For a complete and thorough remediation of the "CNAME and other data" rule violation, you'd have to duplicate
*all* records of interest which can be legally duplicated; this might include MX records, etc. in addition to just A records. I stand
corrected.
- Kevin
Erik Aronesty wrote:
> A CNAME to external domain cannot be replaced with an "A record". This is so obvious/stupid that I'm not going to detail exactly why.
>
> - ERik
>
> -----Original Message-----
> From: Kevin Darcy [SMTP:kcd at daimlerchrysler.com]
> Sent: Wednesday, February 14, 2001 6:52 PM
> To: BIND Users Mailing List
> Subject: Re: CNAME Definition
>
> Just don't do it. Add an A record instead.
>
> - Kevin
>
> digest at cihost.com wrote:
>
> > So what is the proper way to define a CNAME zone for such an entry?
> >
> > Thanks,
> > Digest
> >
> > >RFC1034 3.6.2:
> > >
> > >"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."
> > >
> > >In your example, its not rejecting the 'foreign' CNAMES, its rejecting the
> > >@ CNAME, as you have the myownjunk.com record containing a CNAME RR but
> > >also SOA and NS RR's, which is verboten.
> > >
> > >This has (as you can see) always been a violation of the RFC's as well.
> > >
> > >D
> > >
> > >At 3:03 PM -0600 2/3/01, asenec at senechalle.net wrote:
> > >>We just upgraded to 8.2.3-REL from 8.2.2-P7,
> > >>in response to the recent, CERT advisory and
> > >>find that CNAME's with a zone construct of the
> > >>form below no longer resolve. I find nothing
> > >>in RFC-1035 which would specifically prohibit
> > >>such a construct, but I do note that some
> > >>foreign registeries, such as deNIC, are now
> > >>rejecting domains with such CNAME definition.
> > >>
> > >>$ORIGIN com.
> > >>myownjunk IN SOA ns.theaccount.com. hostmaster.theaccount.com. (
> > >> 2001020312 86400 7200 3600000 172800 )
> > >> IN NS ns.theaccount.com
> > >> IN NS ns2.theaccount.com
> > >> IN CNAME asenec.com.
> > >>$ORIGIN myownjunk.com.
> > >>mail IN CNAME mail.asenec.com.
> > >>ftp IN CNAME ftp.asenec.com.
> > >>www IN CNAME www.asenec.com.
> > >>
> > >>Simply omitting the 'IN CNAME asenec.com.' record
> > >>enables resolution of mail/ftp/www.myownjunk.com,
> > >>but with 8.2.3-REL it seems impossible to resolve
> > >>myownjunk.com when it is defined as a CNAME.
> > >>Is it no longer possible to define a second-level
> > >>domain as a CNAME? If so, is there some RFC which
> > >>declares doing so as illegal?
> > >>
> > >>Annette
> > >>
> > >>--
> > >>+---------------------+-----------------------------------------+
> > >>| dredd at megacity.org | "Conan! What is best in life?" |
> > >>| Derek J. Balling | "To crush your enemies, see them |
> > >>| | driven before you, and to hear the |
> > >>| | lamentation of their women!" |
> > >>+---------------------+-----------------------------------------+
More information about the bind-users
mailing list