BIND 8.2.3 Classless Example
Mark.Andrews at nominum.com
Mark.Andrews at nominum.com
Thu Feb 1 09:37:58 UTC 2001
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
More information about the bind-users
mailing list