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