non-octet boundaries

[Mathias Körber]

> -----Original Message-----
> From: kcd at daimlerchrysler.com [mailto:kcd at daimlerchrysler.com]
> Since this method requires less new zones to be defined/created,=20
> it is more
> suited to larger address spaces, especially if the PTR targets follow =
a
> last-octet-based naming convention which would allow the=20
> $GENERATE directive
> to be used.

In case you don't want to use $GENERATE, there is an old tool of
mine (called gencidrzone) in the contrib/misc/ subdirectory of the
BIND-8 distribution (bind-contrib.tar.gz), which (given a netblock as =
argument)
	a) created an includefile for the ISP to include into their
	   parent zone (will need some editing to add nameservers etc)
	b) a templae zonefile (including lots of instructions)
	   for the customer.

That tool will need some updating sometime soon, but should be able
to help you get things right. It does make some assumptions and
prefers one specific style of the RFC2317 naming conventions..

>=20
> Note that in *neither* case should you be defining the /24=20
> reverse zone, e.g.
> 3.2.1.in-addr.arpa, as master on your server. That zone is=20
> delegated to your
> provider's server -- if you also define it on yours, then this is a
> "rogue" copy of the zone, which could potentially propagate bogus =
data. It
> makes more sense to just be a slave for that zone from your provider.

More proplematic than propagating bogus data is the fact that he would =
likely
mask out his 'neighbours' in the same /24 block from his own view and =
thus may
have problems communicating to them.

Mathias