[Dnsmasq-discuss] [PATCH] Accept /32 and /0 as valid CIDR prefixes for rev-server directive
simon at thekelleys.org.uk
Sun Feb 19 18:03:48 GMT 2017
-----BEGIN PGP SIGNED MESSAGE-----
On 15/02/17 22:46, Olivier Gayot wrote:
> 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 ?
It would certainly be OK, and if you could also then do number three,
I'd be happy to have that patch too.
> Kind regards,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Dnsmasq-discuss