BIND 9.1.x

[Kevin Darcy]

Maenard_martinez at support.trendmicro.com wrote:

> Mark,
>
> Thanks for the feedback. And thanks for the insights especially with the
> checkzone tool...
>
> I have now removed all CNAME and MX records from both BIND servers. My
> problem is with the primary server, Linux1. I don't understand by this
> statement: " Note white space *is* significant in a master file."

The text you originally showed had a bunch of whitespace before the beginning
of the first line. That would have caused it to be misinterpretd. What you show
now has none of that leading whitespace, so perhaps the point is moot.

> I already followed your advise but I still get an error on Linux1 when I run
> the checkzone tool: "no NS record". These are my current records in Linux1:
>
> second  NS bind-test.second.vmnet.biz.
>         NS x.vmnet.biz.
> bind-test.second A 172.16.0.19
> x       A       172.16.2.12

Well, the only thing I can think of offhand is that you have an
$ORIGIN statement above that part of the zonefile, so that "second" is not
being interpreted as "second.vmnet.biz."; maybe it's being interpreted as
something else.

Why don't you try fully-qualifying and dot-terminating *everything* (all the
names, not the IP addresses, preference values or other non-name fields) until
you get the hang of this whole relative-name thing. If it still doesn't work,
post the *entire* zonefile (assuming it's not huge), or at least the upper part
of it, just as far as the delegation records for "second.vmnet.biz.". Then we
can get an overall picture of what's going on.

If fully-qualifying and dot-terminating all names fixes the problem, then you
can carefully start unqualifying names, in order to make the zone file more
readable.

> Btw, my SOA for Linux2 is bind-test.second.vmnet.biz.

Uh, I think you misunderstand. SOA is a record type with multiple fields in it.
It isn't a straight name-to-name mapping. In your previous message, you didn't
show the SOA record for either of the relevant zones, so Mark may have been
speculating that one or both were missing from their respective zone file(s).
That would be a problem.


- Kevin


> -----Original Message-----
> From: Mark.Andrews at isc.org [mailto:Mark.Andrews at isc.org]
> Sent: Tuesday, February 11, 2003 1:42 PM
> To: Maenard Martinez (TS-PH)
> Cc: bind-users at isc.org
> Subject: Re: BIND 9.1.x
>
> > I am running to Linux boxes both running bind. Here's the situation:
> >
> > a. Linux1 is the primary server for vmnet.biz. It has the following
> records:
> >
> >       second IN NS bind-test.second.vmnet.biz.
> >                IN NS x.vmnet.biz.
> >                MX 5 mail
> > bind-test.second IN A 172.16.0.19
> > x IN A 172.16.2.12
> > mail IN CNAME x
>
>         Well if that is your master file named will be throwing lots
>         of errors.
>
>         If you are trying to delegate second.vmnet.biz then you should
>         have.  Note white space *is* significant in a master file.
>
> second  NS bind-test.second.vmnet.biz.
>         NS x.vmnet.biz.
> bind-test.second A 172.16.0.19
>
>         Note the MX record belongs in the second.vmnet.biz master file.
>         Note MX records can't point to CNAMES.
>
> > b. Linux2 has the delegated zone: second.vmnet.biz. These are the records:
> >
> >       IN NS bind-test
> >       IN NS x.vmnet.biz.
> >                MX 5 mail
> > bind-test IN A 172.16.0.19
> > mail IN CNAME bind-test
>
>         Where is your SOA record?
>         Again MX records can't point to CNAMES.
>
> > All BIND servers have a master entry for each zone on their named.conf
> > files.
> >
> > When I try to perform on nslookup from Linux1 for an A record,
> > bind-test.second.vmnet.biz, it's okay. I guess the record is coming from
> its
> > own database file. But when I try records saved in Linux2, I get SERVFAIL
> > error.
> >
> > What is interesting is that I can delegate domains between a BIND server
> and
> > a Windows DNS server; but I am having problems with BIND-to-BIND
> delegation.
> >
> >
> > What did I miss?
>
>         You failed to examine the error logs.
>         You failed to run named-checkzone.
>
>         You are also running a version of named that is past its
>         "use by" date.