Comment 28 for bug 1382190

Using $GENERATE statements, I get the following results:

/16 dynamic range: 10.0.0.1 - 10.0.255.255
 - Reverse Zone: http://paste.ubuntu.com/8721352/
 - Forward Zone: http://paste.ubuntu.com/8721358/

/24 dynamic range: 10.0.0.1 - 10.0.0.255
 - Reverse zone: http://paste.ubuntu.com/8721363/
 - Forward zone: http://paste.ubuntu.com/8721366/

/25 dynamic range: 10.0.0.128 - 10.0.0.255
 - Reverse zone: http://paste.ubuntu.com/8721391/
 - Forward zone: http://paste.ubuntu.com/8721403/

Weird dynamic range: 10.0.0.1 - 10.0.1.33:
 - Reverse zone: http://paste.ubuntu.com/8721501/
 - Forward zone: http://paste.ubuntu.com/8721503/

Note that there's what looks like a weird inefficiency in the /24 (1-255) and others. That's because I'm using netaddr.IPRange() internally to create an IP range to work from, and then converting that into a set of IPNetworks to ensure we get full coverage of weird corner-case networks (and so that I don't have to do all the maths myself). Thing is, .1-.255, although we identify it as a /24 by sight, isn't actually a /24; it's only 254 addresses, so IPRange breaks it down into individual CIDRs rather than just covering it with a /24. It's a weirdness we can live with, I think. For a /16/ we still see only 260-odd $GENERATES as opposed to 65,000 which I'd call an improvement :).