BIND 8.2.3 Classless Example

[Mathias Körber]

> The essential answer is that ALL the CNAME RRs have to come first
> in a given zone file.  Then all the PTRs, with each "Classless"
> subnet anchored by an $ORIGIN.  I've pasted a functioanl example
> into a page at <http://www.digipro.com/Papers/bind-8.2.3.shtml>.

Hmm. May I ask why you think it necessary to publish CNAME records for
PTRs if you put the PTRs into the same zone anyway? You could just
publish the PTR record at the non-classless level if you manage the
parent domain anyway.

The CNAME 'trick'/method is intended for cases where you need to delegate
parts of a block to another authority.


> 
> On bugs, "ndc reload" doesn't notice when A and PTR records are
> changed.  You'll get the OLD and the NEW PTR records.

Did you change the serial number of the zone?
Could you elaborate or show an actual example?

> 
> Edward Siewick
> DigiPro Digital Productions
> Arlington, Virginia, USA
> 
> 
> In article <959fo8$e17 at pub3.rc.vix.com>,
>   Sam.Wilson at ed.ac.uk (Sam Wilson) wrote:
> > In article <957rm1$nmh at pub3.rc.vix.com>, Bob Fillmore
> <fillmore at home.com> wrote:
> >
> > > We noticed this also, except for glue MX records.
> > > We defined glue MX records for subdomains so that mail will still go
> through,
> > > even though the DNS for the subdomain may be down.  We had to remove
> these
> > > records
> > > to allow the zone file to load for 8.2.3, so I guess we will now
> have to
> > become
> > > secondary
> > > for all of our subdomains to achieve the same result, correct?
> > > (I know, it's probably a good idea anyway, and we will do this.)
> > >
> > >    - Bob
> > >
> > >
> > > "Cinense, Mark" wrote:
> > >
> > > > I just installed Bind 8.2.3 on my Sun Netra T1 and after starting
> named, I
> > > > get this in my messages log.
> > > >
> > > > Jan 29 14:11:57 ns5 named[8755]: zone: sandia.gov/IN: non-glue
> record below
> > > > bottom of zone: limerock.mdl.sandia.gov/CNAME
> > > >
> > > > This is actually affecting my reverse zone files as well.  Does
> anyone know
> > > > how I can fix this?
> > > >
> > > > Mark
> >
> > We were also bitten by this but noticed that it only seems to happen
> at
> > server startup - on 'ndc reload' or 'ndc reload <zone>' the zone is
> > accepted.  For example on restart we see:
> >
> > Jan 31 02:00:04 cancer named[11268]: zone: ed.ac.uk/IN: non-glue
> record
> > below bottom of zone: old.inf.ed.ac.uk/CNAME
> > Jan 31 02:00:04 cancer named[11268]: zone: ed.ac.uk/IN: non-glue
> record
> > below bottom of zone: www.inf.ed.ac.uk/CNAME
> > Jan 31 02:00:04 cancer named[11268]: zone: ed.ac.uk/IN: non-glue
> record at
> > bottom of zone: epcc.ed.ac.uk/MX
> > Jan 31 02:00:04 cancer named[11268]: zone: ed.ac.uk/IN: non-glue
> record
> > below bottom of zone: www.sms.ed.ac.uk/CNAME
> > Jan 31 02:00:04 cancer named[11268]: master zone "ed.ac.uk" (IN)
> rejected
> > due to errors (serial 2001013000)
> >
> > but on "ndc reload" we get:
> >
> > Jan 31 10:08:28 cancer named[11271]: master zone "ed.ac.uk" (IN)
> loaded
> > (serial 2001013000)
> >
> > The zone file had not been edited in the mean time (and the errors
> were
> > real - hangover data from zones which had been delegated).
> >
> > cc:ed to bind-bugs because it looks like a bug... :-)
> >
> > --
> > Sam Wilson
> > Network Services Division, Computing Services
> > The University of Edinburgh
> > Edinburgh, Scotland, UK
> >
> >
> 
> 
> Sent via Deja.com
> http://www.deja.com/
>