On Tue, Feb 14, 2017 at 08:16:02AM -0600, /dev/rob0 wrote:
> On Tue, Feb 14, 2017 at 12:31:21AM +0100, olivier.ga...@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.

_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to