Comment 19 for bug 1382190

Ah, so, the light of day: $GENERATE is only useful for networks with an address range > /24 — i.e. up to 255 addresses. After that it breaks down, because:

$GENERATE 1-254 $.$.0.10.in-addr.arpa. IN PTR no-name-yet-$.$.maas.

Only generates 255 addresses; it's not recursive. You just get

10.10.0.10.in-addr.arpa. 300 IN PTR no-name-yet-10-10.maas.
100.100.0.10.in-addr.arpa. 300 IN PTR no-name-yet-100-100.maas.
101.101.0.10.in-addr.arpa. 300 IN PTR no-name-yet-101-101.maas.
102.102.0.10.in-addr.arpa. 300 IN PTR no-name-yet-102-102.maas.
103.103.0.10.in-addr.arpa. 300 IN PTR no-name-yet-103-103.maas.
104.104.0.10.in-addr.arpa. 300 IN PTR no-name-yet-104-104.maas.
105.105.0.10.in-addr.arpa. 300 IN PTR no-name-yet-105-105.maas.

Etc.

Which means that for a /16 we'd need 256 $GENERATEs; for a /8, 65536 of them. That's… suboptimal.

Options:

 1. We could say "We'll generate PTR records for /24 dynamic ranges only."
     Advantages: Pretty easy to do
     Disadvantages: We're forcing users into a particular configuration.
 2. We limit the dynamic range to /16 for IPv4 (similar to before when we enforced a /16 network).
     Advantages: 256 lines isn't the *worst*, performance wise, so we could probably get away with it.
     Disadvantages: We still have to write those 256 lines on every deployment.
 3. We add the PTR record when we parse the DHCP lease
     Advantages: No bloat; pretty much as we already do now for static IPs.
     Disadvantages: Noticeable lag between the node acquiring a lease and getting a PTR.

None of these options is lovely.