BIND 8.2.3 Classless Example

[Mark.Andrews at nominum.com]

	Did you ever wonder why 8.2.2 was complaining?

	Looking at your web page you are obviously confused.

	A classless delegatation requires two zones.
	1. containing the CNAME records that point into the other zone.
	   This zone is part of the IN-ADDR.ARPA tree.
	2. the other zone containing the PTR records.
	   This zone may or may not be under IN-ADDR.ARPA.

	There are some other things that can be there depending
	upon the name of the second zone.  The following example
	has two delegations.

	4.168.192.in-addr.arpa:
	@ SOA ns1.isp.com. ...
	  NS ns1.isp.com.
	  NS ns2.isp.com.
	$GENERATE 0-127 $ CNAME $.0/25.4.168.192.in-addr.arpa.
	$GENERATE 128-255 $ CNAME $.128/25.4.168.192.in-addr.arpa.
	0/25 NS ns1.test.com.
	0/25 NS ns2.test.com.
	128/25 NS ns1.example2.com.
	128/25 NS ns1.example2.com.

	0/25.4.168.192.in-addr.arpa:
	@ SOA ns1.test.com. ...
	  NS ns1.test.com.
	  NS ns2.test.com.
	1 PTR one.test.com.
	2 PTR one.test.com.
	3 PTR one.test.com.
	
	128/25.4.168.192.in-addr.arpa:
	@ SOA ns1.example2.com. ...
	  NS ns1.example2.com.
	  NS ns2.example2.com.
	129 PTR for.example2.com.
	130 PTR fif.example2.com.
	131 PTR six.example2.com.

	Mark
	
> I just spent the better part of two days upgrading DNS servers from bind
> 8.2.2 to 8.2.3.  The "classless" subnets caused the most trouble. Seems
> that the order of the RRs is now subject to some rules enforcement. So
> a lot of working tables simply broke.
> 
> 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>.
> 
> On bugs, "ndc reload" doesn't notice when A and PTR records are
> changed.  You'll get the OLD and the NEW PTR records.
> 
> 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/
> 
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com