rejected due to CNAME and OTHER data error

[David R. Kirk]

> > The errors are correct - you need to decide what you are doing with
> > this zone, as the zone data that you have included below contradicts
> > many BIND rules that BIND 8.2.3 enforces very strictly, and it's not
> > clear what you are trying to do with that zone at all.
>
> I still don't understand, what's wrong with it? It's not one zone just
> for testing, it's one of some thousand zones mainly for .de-domains.
> Most presences are hosted at our servers, so we don't need CNAMEs. But
> some customer want to use the services of dyndns.org, so one or more
> subdomains are CNAMEed to the correspondig subdomain of dyndns.org.

OK ... the zone you presented is miabdo.de, as far as I can tell.

The first error that the system should be seeing is that a CNAME record has
been set up for the domain itself; BIND 8.2.3 does not allow this.  You'd
have to use an A record here, and not a CNAME.

The other errors are due to the fact that once you have set up a CNAME
record for a host, NO OTHER RRs can be set for that host.  Once you CNAMEd
the domain miabdo.de, all of the other records (the NS records, the MX
records, etc.) are nullified.

That's the source of your errors.  Now, on to your other question ...

> So, if someone resolves the domain name, it will resolv first .de at the
> root-nameservers, miabdo.de at dns.denic.de, and then ns.cnm.de, looking
> for an a or cname-Record. While it's working the same way with
> subdomains e.g. config.variomedia.de CNAMEed to vm2.variomedia.de,
> what's the problem with miabdo.de to miabdo.dyndns.org? Because it
> CNAMEs to an external source? How else can I configure the above
> described requirements?

BIND 8.2.3 explicitly denies the condition that you are trying to employ - a
CNAME should not be set up for the domain itself, because in doing so, it
nullifies all other resource records that are set up against it.  It has
never been correct, BIND 8.2.3 simply did the right thing in rejecting the
zone instead of allowing  it as had been done previously.

In the case of a subdomain, you can break the entire zone by doing this
wrong, but the use of the CNAME as applied to the first-level domain (as
opposed to TLD (e.g. .de) essentially breaks the entire zone, as it
effectively kills your ability to apply any resource records if it is
allowed.

I'd guess that if they wanted to have dyndns.org handle their DNS, they'd
just want the zones delegated outright to the dyndns.org name servers, as
opposed to the setup that you have proposed.

Perhaps I'm mistaken, but I'm pretty sure my logic is correct here.

Best regards,

dave