On Tue, Feb 14, 2017 at 03:17:54PM +0000, Simon Kelley wrote:
> That's an improvement, but I tend to agree that /0 doesn't make much
> sense. If we're going to patch this, it seems to make more sense to
> reject anything other that /32 /24 /16 or /8.
> The ideal solution would be to accept any prefix length and generate
> the (up to) 256 --server equivalents that it corresponds to. If
> you're going to have syntactic sugar, it may as well work for you.
That would be fantastic! I guess that would be up to 128 though.
However it sounds like a much bigger change than what I came up with. It
will add some complexity.
To summerize, after reading your answer and rob0's answer, I think that
there are three things that can be addressed:
- The first one being that /32 is not considered a valid value in the
rev-server directive. And it would really be useful if it were. (That
was the purpose of my patch in the first place).
- The second one being that values considered invalid (or at least not
considered valid) in the rev-server directive are implicitly converted
to /16. And I think they should be rejected instead (0 included).
Besides, /55555 is also currently converted to /16 without notice.
- And the last thing being a possible improvement: accepting any CIDR in
the range [1; 32]. And indeed we would need to generate multiple
server directives accordingly.
If you agree with the above, Simon, I think that I can quickly come up
with two patches to address the first two issues. Would that be okay for
you as a first step ?
Dnsmasq-discuss mailing list