why not work "dig @localhost ..... axfr"

[Frank Peters]

In article <000901bf24d3$026472a0$1e747ca4 at dacom.net>, HeePok Lee wrote:
>Nov  2 09:33:56 ns1 named[29664]: ftp.bora.net has CNAME and other data
>(invalid)
>Nov  2 09:33:56 ns1 named[29664]: Prm/boranet/db.bora:639:ftp.bora.co.kr:
>CNAME and OTHER data error
>Nov  2 09:33:57 ns1 named[29664]: master zone "bora.co.kr" (IN) rejected due
>to errors (serial 1999101501)

It appears that this same server is primary for bora.net and secondary
for bora.co.kr, correct?  If not then you may need to post the full
named.conf and zone files because something strange is happening.

>And I have zone file about bora.net like this.
>.
>.
>ftp     120     IN      CNAME   ftp.bora.net.
>ftp     120     IN      MX 10   zero.dacom.co.kr.

There are two problems with this.  The first problem (and the one in
the first error message above) is that the same host has both a CNAME
record and an MX record.  This is illegal.  If a host has a CNAME
record then it must have no other records (the other records should be
associated with the host name that the CNAME points two).

But, unless I'm misunderstanding your configuration, you appear to have
another problem.  It looks like you have a CNAME for ftp.bora.net
pointing to back to ftp.bora.net.  Surely this is a typo and you
intended the CNAME to point to some other host?

According to the second error message, you have the same flaw (CNAME
and other data) for the host ftp.bora.co.kr.

The server is refusing to be authoritative for these zones because of
the errors.  Which is why your axfr is failing...it only works if the
server is authoritative and your server refuses to be authoritative
because of configuration errors in the zone file.

>.
>When I work with BIND 8.2.1, never happened like this problem.
>I got this problem after upgraded BIND 8.2.2.

Newer versions of BIND are becoming more and more careful about these
sorts of configuration errors.  I would have thought that 8.2.1 would
have behaved the same, but perhaps some aspect of the check was
tightened up.

At any rate, the ultimate problem is configuration errors.  Older
releases simply failed to detect them or were willing to ignore them.

-- 
Frank Peters - Manager, UNIX Systems - Mississippi State University
  "I can't give you brains, but I can give you a diploma."
				-- The Wizard of OZ