Comment 14 for bug 1382190

On 22 October 2014 23:19, Gavin Panella <email address hidden> wrote:
> On 22 October 2014 22:03, Graham Binns <email address hidden> wrote:
>> This works perfectly:
>
> Awesome, that's great. Sort of brain-dump follows:
>
> How does this work for networks that don't line up with IPv4 octets? For
> example, for a dynamic range that covers 192.168.0.0/23, would we need
> to write the following?
>
> $GENERATE 1-254 $.0.168.192.in-addr.arpa. IN PTR no-name-yet-$.maas.
> $GENERATE 1-254 $.1.168.192.in-addr.arpa. IN PTR no-name-yet-$.maas.
>
> A /16 would need 256 lines.

If I'm reading [1] right (and I may not be; it's late), we could do
something like this:

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

But a quick check of that on my local MAAS suggests it doesn't work.
I'll dig further tomorrow.

> Is this expanded macro-like within BIND, or is it compiled into a rule?
> It may make a difference to performance.

AFAICT, it's expanded rather than compiled into a rule.

> I assume we'll do this only for IPv4? If it's compiled to a rule, we
> /could/ do it for IPv6 too, but that may be a slope down which we don't
> want to slip. Ultimately we want to steer people towards reserving IP
> addresses via MAAS's API.

True. That said, if we fix this for v6 too it means that some very
nasty hacks in charms can be canned, and that's not a terrible thing
for our users. If it's easy to do, I say we might as well be
consistent. If v6 causes (as I suspect it will) considerable headaches
here, then we'll stick with v4 and push for everyone to use APIs as
they should be doing.

> Is this enough to satisfy RabbitMQ? Some services like to make sure that
> they can round-trip through DNS, i.e. that the PTR record resolves to a
> name that then resolves back to the starting address.

I haven't checked that out yet, but it's a good point. We could always
use $GENERATE to generate the forward zone too, though, if your first
point doesn't make that entirely onerous.

> We could choose the prefix to encourage people to reserve addresses. For
> example, "dynamic-$", "anon-$", "temporary-$", or "do-not-use-$", in
> order of severity. Unfortunately this is bikeshed territory, so I'm
> going to put myself out of the running by voting for
> "do-not-rely-on-this-you-get-to-keep-the-pieces-and-give-me-one-million-dollars-$".

"use-this-at-your-peril-$.maas".