esoteric $GENERATE problem fixed in 8.2.3-REL (?)

[ray at doubleclick.net]

Hey all ...

Some time ago, I posted to the list asking why $GENERATE was not
working properly for "shared" reverse zones in my environment; I had a
master nameserver running 8.2.2-P5, and many slaves running the same
(8.2.2-P5). On the master, I had many reverse zones (*.in-addr.arpa.)
mapped to the same zonefile via symbolic links, and I was doing the
same thing for some forward zones.

In the zonefiles, all records were fully-qualified, and during BIND
startup and zone-transfers, BIND on the master would process the
"shared" zonefile (probably multiple times), discard appropriate
records to produce the per-zone structures for normal operations and
for transfer to the slaves ... this worked great (still does) to allow
multiple domains, say example.com, example.net, and example.org to
build off a single zonefile (say db.example) where the zone data only
differs by the TLD (com/net/org). Another example: db.10, db.192.168,
db.172.16, db.172.17, are all symlinked to one zonefile "db.reverse".
This saves lots of effort in my environment, since we typically will
just register .[com|net|org] for any new project to prevent domain
squatting, etc.

ok, I realize this "nonstandard" practice is not encouraged by ISC or
Nominum but it has worked fine for the most part.

Now the problem with using $GENERATE ... in the forward "shared"
zonefiles this worked "as advertised", e.g. if I had a zonefile called
db.example, and had a $GENERATE statement, when BIND parsed the munged
zonefile out into example.com, example.net, example.org zones, the
$GENERATE macro was/is interpreted correctly. HOWEVER when I tried to
do the same thing in a "shared" reverse zone, the $GENERATE'd RRsets
were only known to the master, and those RRsets were not parsed/AXFR
out to any of the secondaries. I was trying to setup entries for all
DHCP addresses in particular; I could lookup say dhcp-100.example.com
and get A response correctly of e.g. 192.168.1.100, but a PTR query
for "100.1.168.192.in-addr.arpa" did not return "dhcp-100.example.com"
*except* when query was against the master nameserver (but not
slaves).

I received a response from someone at Nominum, saying they were "sure"
that if I just broke the munged reverse zonefile out into individual
zonefiles (1 for each defined zone in named.conf, e.g. the "typical"
way) this strange issue with $GENERATE'd RRsets not being AXFR'd would
go away ... but there was no real explanation as the the "true" cause
of the problem (?)

Anyway to cut to the chase ... after upgrading my master to 8.2.3-REL,
all the $GENERATE macros in my "munged" reverse zonefiles are properly
parsed, and the RRsets are now seen by the secondaries (some of which
are still running 8.2.2-P5). So it was purely an issue with 8.2.2* not
correctly parsing $GENERATE in certain situations, which has since
been fixed.

Well, just posting in case anyone out there saw this in their own shop
(unlikely, I know ... but I'd appreciate finding this post in the
bind-users archive if I had the same issue :)

--
Ray