On Tue, Feb 14, 2017 at 7:17 AM, Simon Kelley <si...@thekelleys.org.uk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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.

+1 on accepting any size netmask universally. I am perpetually getting
/48s... or /56s... or /60s or /61s, /62s or /63 and prefix splitting
in shell to generate the appropriate things for rev-server, etc, is a
PITA. I'm sitting here trying to remember which one of these two broke
with different sized netmasks....

synth-domain=ula.taht.net,fd32:7d58:8d63::/64,ula-
rev-server=fd32:7d58:8d63::/48,fd32:7d58:8d63::1

And I did look at the code for both and was too dumb to figure out how
to apply the technique universally.


>
> Cheers,
>
> Simon.
>
>
>
> On 13/02/17 23:31, olivier.ga...@sigexec.com wrote:
>> From: Olivier Gayot <olivier.ga...@sigexec.com>
>>
>> [ excerpt from the man page ] The rev-server directive provides a
>> syntactic sugar to make specifying address-to-name queries easier.
>> For example --rev-server=1.2.3.0/24,192.168.0.1 is exactly
>> equivalent to --server=/3.2.1.in-addr.arpa/192.168.0.1
>>
>> It is not mentioned in the man page but specifying anything but /8
>> or /24 as the CIDR prefix has the same effect as specifying /16.
>>
>> It is not a big deal for subnets on non-octet boundaries since
>> they cannot be represented using a single in-addr.arpa address.
>> However, it is unconvenient for /32 and /0 prefixes while their
>> analogous server directives behave as expected. E.g. the following
>> server directives work as expected:
>>
>> 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
>>
>> 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.
>>
>> Signed-off-by: Olivier Gayot <olivier.ga...@sigexec.com> ---
>> src/option.c | 31 +++++++++++++++++++++---------- 1 file changed,
>> 21 insertions(+), 10 deletions(-)
>>
>> diff --git a/src/option.c b/src/option.c index 4a5ef5f..eeca3d6
>> 100644 --- a/src/option.c +++ b/src/option.c @@ -850,19 +850,30 @@
>> char *parse_server(char *arg, union mysockaddr *addr, union
>> mysockaddr *source_a static struct server *add_rev4(struct in_addr
>> addr, int msize) { struct server *serv = opt_malloc(sizeof(struct
>> server)); -  in_addr_t  a = ntohl(addr.s_addr) >> 8; +  in_addr_t
>> a = ntohl(addr.s_addr); char *p;
>>
>> memset(serv, 0, sizeof(struct server)); -  p = serv->domain =
>> opt_malloc(25); /* strlen("xxx.yyy.zzz.in-addr.arpa")+1 */ - -  if
>> (msize == 24) -    p += sprintf(p, "%d.", a & 0xff); -  a = a >>
>> 8; -  if (msize != 8) -    p += sprintf(p, "%d.", a & 0xff); -  a =
>> a >> 8; -  p += sprintf(p, "%d.in-addr.arpa", a & 0xff); +  p =
>> serv->domain = opt_malloc(29); /*
>> strlen("xxx.yyy.zzz.ttt.in-addr.arpa")+1 */ + +  switch (msize) +
>> { +    case 32: +      p += sprintf(p, "%d.", a & 0xff); +      /*
>> fall through */ +    case 24: +      p += sprintf(p, "%d.", (a >>
>> 8) & 0xff); +      /* fall through */ +    default: +    case 16: +
>> p += sprintf(p, "%d.", (a >> 16) & 0xff); +      /* fall through
>> */ +    case 8: +      p += sprintf(p, "%d.in-addr.arpa", (a >> 24)
>> & 0xff); +      break; +    case 0: +      p += sprintf(p,
>> "in-addr.arpa"); +    }
>>
>> serv->flags = SERV_HAS_DOMAIN; serv->next = daemon->servers;
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQIcBAEBCAAGBQJYox+hAAoJEBXN2mrhkTWiBSUQAJQxq6yD3Tcw/39On0QcLcfy
> aZTerALrzgrwlpyH4yVWeztrA3pFK1uVLIhnQP161zR+NJRI5Bo0J7tAOElETm3k
> QQ0HEu16skPHdmzlmbR1MMLoVKn4myh6hDm5iFSAf+jsCpItAzYo5Cy9/oAz3PNU
> Hp1SKxYNwrcSTw5FQrLpNuhZxbqvkA5KiU3URcnzv3mW2YbMzcjrULL7hF7xfN0t
> 2iwI8shObm/3FMDux7jX1wuRPQALWokaXFhAyOTDUVBONavA4W/PxS+8VvV4noi4
> dFh6FMhJYPggUh7v02PTOoPtSuvaLNGt1vgWeHt1sqTXEo6rVsft085fKwH1uONw
> SGWrGhnFaVDewHeEoB46K6qg7LYSoLa1cgv8li8QJ9ZTSiFC7ZqIWsXBQ5oqlGzr
> 0iR6jo1yqISvwyek8nogsgNWI4zx/mmC1AXhR/OjE8Y/3MA87rhpY+t/U2ZJug5e
> f611DvKCl4iQuL/EyWY7hCIK7XCHi4ACx7sosN21zgL2/ToLshaF7i3rcYC6F/Bx
> 5GGgv6x6WiXWRMk82YiqcEphnOdphsWen4ZMHTdlBIzZ1EXpD5XwhDHTzzmD3SlT
> oNjwPR1Gmkt1yXxLSvvr6mp7XFRDQOJMWDHvmfroH4p2hcxyB/2dSbhLjrfri0nL
> WsjDDAhdIM1aHokLmLqi
> =mtD9
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

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

Reply via email to