[Dnsmasq-discuss] [PATCH] Accept /32 and /0 as valid CIDR prefixes for rev-server directive
Olivier Gayot
olivier.gayot at sigexec.com
Wed Feb 15 21:48:26 GMT 2017
On Tue, Feb 14, 2017 at 08:16:02AM -0600, /dev/rob0 wrote:
> On Tue, Feb 14, 2017 at 12:31:21AM +0100, olivier.gayot at sigexec.com wrote:
> >
> > server=/42.10.168.192.in-addr.arpa/1.2.3.4
> > server=/in-addr.arpa/1.2.3.4
> >
> > but the following do not:
> >
> > rev-server=192.168.10.42/32,1.2.3.4
> > rev-server=192.168.10.42/0,1.2.3.4
>
> The second is a bad example, and to my mind it should not work,
> because x.x.x.x/0 is not a valid CIDR expression unless each x=0.
> Did you try "rev-server=0.0.0.0/0,1.2.3.4"? From the patch I am
> supposing you did and got 0.0.in-addr.arpa as the zone?
>
You are right, the example is inappropriate. Only 0.0.0.0/0 should be
considered valid as you mentioned.
And yes, I tried with this value and it indeed gives 0.0.in-addr.arpa as
a result.
> > and, in practice, they behave the same as:
> >
> > server=/168.192.in-addr.arpa/1.2.3.4
> > server=/168.192.in-addr.arpa/1.2.3.4
> >
> > This strange behaviour is fixed by accepting /32 and /0 CIDR
> > prefixes as valid values. Any other value will still be
> > considered the same as /16.
>
> A /0 zone is very strange and likely to break most reverse address
> resolution, but a /32 zone is not unusual at all; I run 8 /32
> in-addr.arpa zones for my /29 netblock.
You are right again. Having multiple /32 in order to manage subnets with
prefixes greater than /24 is most useful and this is a reason why I came
with this patch. I made the decision to change the behaviour of /0 to
make the model complete but it is definitely something that can be
reverted back to the old behaviour.
More information about the Dnsmasq-discuss
mailing list