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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1382190
Title:
LXCs assigned IPs by MAAS DHCP lack DNS PTR entries
To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1382190/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
