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 ?

Kind regards,

Olivier

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

Reply via email to