Re: [Dnsmasq-discuss] Reading the dhcp.leases file

[Reddeiah Raju Konduru]

Sorry wrong Thread.

On Tue, Feb 14, 2017 at 10:48 AM, Reddeiah Raju Konduru 
wrote:

> Hi Simon,
>
> Thanks for the DHCP Client-ID's patch.
>
> - Raju
>
>
>
> On Tue, Feb 14, 2017 at 7:10 AM, Simon Kelley 
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Albert's suggestions are good, and you can't reliably read the leases
>> file - in gets modified by delete-and-rewrite, so if the timing is
>> wrong, you'll see an incomplete write.
>>
>> DHCP script gets all the information needed to maintain a database
>> equivalent to the leases file, using whatever engine you prefer.
>>
>>
>>
>> Cheers,
>>
>> Simon.
>>
>>
>> On 12/02/17 05:53, Albert ARIBAUD wrote:
>> > Hi Sam,
>> >
>> > Le Sat, 11 Feb 2017 16:06:55 -0600 Sam Weber 
>> > a écrit:
>> >
>> >> In our system, when a change occurs to the DNS entries we want
>> >> dnsmasq to respond to, we scan the directory of active entries
>> >> and then grep the dhcp.leases file to see if the entry exists
>> >> there.  If the entry is not found in the leases file, we omit it.
>> >> Once the scan and check is completed, we write a new hosts file
>> >> and then send SIGHUP to dnsmasq so it knows to read the new file.
>> >> This works well most of the time.  Sometimes, however, a
>> >> perfectly valid entry is not found in the dhcp.leases file so we
>> >> incorrectly omit the entry from the dnsmasq hosts file.  We can
>> >> see that the leases file gets written very often in our system,
>> >> and we think that sometimes we must be reading the leases file
>> >> whilst dnsmasq is writing it, resulting in our reading the file
>> >> when a value of interest has not yet been written.  Is this idea
>> >> of our sometimes reading an incomplete leases file a possibility?
>> >> Is there a workaround other than reading the leases file several
>> >> times?
>> >
>> > Not sure I understand your problem right, so I'll rephrase it and
>> > let you tell me if that's what you do and want to happen:
>> >
>> > - you have a list of names associated with IP addresses;
>> >
>> > - you want to filter this list, keeping only the entries where the
>> > IP address is currently being leased;
>> >
>> > - you want the filtered list to be used by dnsmasq in its name
>> > resolution process.
>> >
>> > - you want the list to be kept up to date with the current leases.
>> >
>> > - IOW, you want DHCP clients that get an IP which appears in your
>> > list one to be assigned the corresponding name in the DNS, and you
>> > want the DNS to NOT map names in this list if the corresponding IP
>> > is not leased right now.
>> >
>> > Is that it?
>> >
>> > If so, /maybe/ dhcp-script is what you need or at least can help
>> > you detect when you need to run your update, as it would give you a
>> > sign that the leases just changed.
>> >
>> > But it seems to me what you are doing is not really different from
>> > what dnsmasq already does (i.e. reflexting DHCP names into the DNS)
>> > when the MAC-to-IP mapping is done with static leases and each
>> > dhcp-host line specifies a name.
>> >
>> > If this is indeed what you are doing, then maybe you can achieve
>> > that with options dhcp-hostsfile and dhcp-ignore-names.
>> >
>> > You'd use dhcp-hostsfile to point to your list written as a list
>> > of dhcp-host options, minus the "dhcp-host=" prefix.
>> >
>> > You'd specify dhcp-ignore-names to make sure no host can overrule
>> > your list and choose its own name in its DHCP requests.
>> >
>> > You would then only have to tell dnsmasq whenever your list changes
>> > by sending it SIGHUP, but you would not have to care about DHCP
>> > leases being granted or released, as that is automatically
>> > reflected in the DNS part of dnsmasq.
>> >
>> > HTH (again, IIUC)
>> >
>> > Amicalement,
>> >
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2.0.22 (GNU/Linux)
>>
>> iQIcBAEBCAAGBQJYox3bAAoJEBXN2mrhkTWiO7gP/0fTR+9xbNPupk1pDBbE/Y90
>> 5XQ5/LnS++uqhfUYBL8UPzjqk+l1PpKKb3nvTlGGQ/Ul68UsZ968awQbvZQgFy0l
>> 5WxrLyzTHnKLKzksII2ZKOGjOZ/fvU3+USHyPo6hgfKSQbCfV9+LyW3vYLBGfFMW
>> n84r6mCzeUSLTOAwzXk813x7z5suHaNs3Rhc0lxHUTI/Lim4Lvg9oJE6yKAP3pqY
>> YE7BhOvtIbGKx3JGrWoy6EyAvSzirci2b5Kol+gJ+rCi7TvTqUP5BdvLY0QLYdbY
>> BS7l4xxR8DWNJCrgwa+VMnEMeYIlSZ9vlkWBnGiw++ksI0M4K9C3kWAmIM0/Anfv
>> fBNGtjV4SsOlpydBbuQmizkZQty3NiWo1XqcGlPOS/0YVQhrLqyTBFmCbovLs0LU
>> v43Iqj2z01XcP+znD/FDlY41kgC3UHJPKR/1RhL966Yz7ZkHyl9d4unV2B69OLCE
>> gjN3HahWa8j9RJ7Y8rXmJeUbN7UPnZWuWUwR0dgid6qUMfnlo3EQniBbbNQW6Fso
>> EpB9N2R2npTs3cTitAJiE536Y+0jv0ICsX7GJUaWLxGGhqKmDxBQrF8V0sX1pO2g
>> 5it7PWOY1cNONqG05QXlSsf83IMogOPlajEok6vKcsUSg/oy38HqH29UiW/fOr8N
>> WSvLT3mkikRqFv9hkCXZ
>> =Qo5a
>> -END PGP SIGNATURE-
>>
>> ___
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss@lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
>
>
>
> --
> Thanks & Regards,
>
> Reddeiah Raju Konduru
> +918095133903 

Re: [Dnsmasq-discuss] Reading the dhcp.leases file

[Reddeiah Raju Konduru]

Hi Simon,

Thanks for the DHCP Client-ID's patch.

- Raju



On Tue, Feb 14, 2017 at 7:10 AM, Simon Kelley 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Albert's suggestions are good, and you can't reliably read the leases
> file - in gets modified by delete-and-rewrite, so if the timing is
> wrong, you'll see an incomplete write.
>
> DHCP script gets all the information needed to maintain a database
> equivalent to the leases file, using whatever engine you prefer.
>
>
>
> Cheers,
>
> Simon.
>
>
> On 12/02/17 05:53, Albert ARIBAUD wrote:
> > Hi Sam,
> >
> > Le Sat, 11 Feb 2017 16:06:55 -0600 Sam Weber 
> > a écrit:
> >
> >> In our system, when a change occurs to the DNS entries we want
> >> dnsmasq to respond to, we scan the directory of active entries
> >> and then grep the dhcp.leases file to see if the entry exists
> >> there.  If the entry is not found in the leases file, we omit it.
> >> Once the scan and check is completed, we write a new hosts file
> >> and then send SIGHUP to dnsmasq so it knows to read the new file.
> >> This works well most of the time.  Sometimes, however, a
> >> perfectly valid entry is not found in the dhcp.leases file so we
> >> incorrectly omit the entry from the dnsmasq hosts file.  We can
> >> see that the leases file gets written very often in our system,
> >> and we think that sometimes we must be reading the leases file
> >> whilst dnsmasq is writing it, resulting in our reading the file
> >> when a value of interest has not yet been written.  Is this idea
> >> of our sometimes reading an incomplete leases file a possibility?
> >> Is there a workaround other than reading the leases file several
> >> times?
> >
> > Not sure I understand your problem right, so I'll rephrase it and
> > let you tell me if that's what you do and want to happen:
> >
> > - you have a list of names associated with IP addresses;
> >
> > - you want to filter this list, keeping only the entries where the
> > IP address is currently being leased;
> >
> > - you want the filtered list to be used by dnsmasq in its name
> > resolution process.
> >
> > - you want the list to be kept up to date with the current leases.
> >
> > - IOW, you want DHCP clients that get an IP which appears in your
> > list one to be assigned the corresponding name in the DNS, and you
> > want the DNS to NOT map names in this list if the corresponding IP
> > is not leased right now.
> >
> > Is that it?
> >
> > If so, /maybe/ dhcp-script is what you need or at least can help
> > you detect when you need to run your update, as it would give you a
> > sign that the leases just changed.
> >
> > But it seems to me what you are doing is not really different from
> > what dnsmasq already does (i.e. reflexting DHCP names into the DNS)
> > when the MAC-to-IP mapping is done with static leases and each
> > dhcp-host line specifies a name.
> >
> > If this is indeed what you are doing, then maybe you can achieve
> > that with options dhcp-hostsfile and dhcp-ignore-names.
> >
> > You'd use dhcp-hostsfile to point to your list written as a list
> > of dhcp-host options, minus the "dhcp-host=" prefix.
> >
> > You'd specify dhcp-ignore-names to make sure no host can overrule
> > your list and choose its own name in its DHCP requests.
> >
> > You would then only have to tell dnsmasq whenever your list changes
> > by sending it SIGHUP, but you would not have to care about DHCP
> > leases being granted or released, as that is automatically
> > reflected in the DNS part of dnsmasq.
> >
> > HTH (again, IIUC)
> >
> > Amicalement,
> >
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQIcBAEBCAAGBQJYox3bAAoJEBXN2mrhkTWiO7gP/0fTR+9xbNPupk1pDBbE/Y90
> 5XQ5/LnS++uqhfUYBL8UPzjqk+l1PpKKb3nvTlGGQ/Ul68UsZ968awQbvZQgFy0l
> 5WxrLyzTHnKLKzksII2ZKOGjOZ/fvU3+USHyPo6hgfKSQbCfV9+LyW3vYLBGfFMW
> n84r6mCzeUSLTOAwzXk813x7z5suHaNs3Rhc0lxHUTI/Lim4Lvg9oJE6yKAP3pqY
> YE7BhOvtIbGKx3JGrWoy6EyAvSzirci2b5Kol+gJ+rCi7TvTqUP5BdvLY0QLYdbY
> BS7l4xxR8DWNJCrgwa+VMnEMeYIlSZ9vlkWBnGiw++ksI0M4K9C3kWAmIM0/Anfv
> fBNGtjV4SsOlpydBbuQmizkZQty3NiWo1XqcGlPOS/0YVQhrLqyTBFmCbovLs0LU
> v43Iqj2z01XcP+znD/FDlY41kgC3UHJPKR/1RhL966Yz7ZkHyl9d4unV2B69OLCE
> gjN3HahWa8j9RJ7Y8rXmJeUbN7UPnZWuWUwR0dgid6qUMfnlo3EQniBbbNQW6Fso
> EpB9N2R2npTs3cTitAJiE536Y+0jv0ICsX7GJUaWLxGGhqKmDxBQrF8V0sX1pO2g
> 5it7PWOY1cNONqG05QXlSsf83IMogOPlajEok6vKcsUSg/oy38HqH29UiW/fOr8N
> WSvLT3mkikRqFv9hkCXZ
> =Qo5a
> -END PGP SIGNATURE-
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>



-- 
Thanks & Regards,

Reddeiah Raju Konduru
+918095133903
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Reading the dhcp.leases file

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Albert's suggestions are good, and you can't reliably read the leases
file - in gets modified by delete-and-rewrite, so if the timing is
wrong, you'll see an incomplete write.

DHCP script gets all the information needed to maintain a database
equivalent to the leases file, using whatever engine you prefer.



Cheers,

Simon.


On 12/02/17 05:53, Albert ARIBAUD wrote:
> Hi Sam,
> 
> Le Sat, 11 Feb 2017 16:06:55 -0600 Sam Weber 
> a écrit:
> 
>> In our system, when a change occurs to the DNS entries we want 
>> dnsmasq to respond to, we scan the directory of active entries
>> and then grep the dhcp.leases file to see if the entry exists
>> there.  If the entry is not found in the leases file, we omit it.
>> Once the scan and check is completed, we write a new hosts file
>> and then send SIGHUP to dnsmasq so it knows to read the new file.
>> This works well most of the time.  Sometimes, however, a
>> perfectly valid entry is not found in the dhcp.leases file so we
>> incorrectly omit the entry from the dnsmasq hosts file.  We can
>> see that the leases file gets written very often in our system,
>> and we think that sometimes we must be reading the leases file
>> whilst dnsmasq is writing it, resulting in our reading the file
>> when a value of interest has not yet been written.  Is this idea
>> of our sometimes reading an incomplete leases file a possibility?
>> Is there a workaround other than reading the leases file several
>> times?
> 
> Not sure I understand your problem right, so I'll rephrase it and
> let you tell me if that's what you do and want to happen:
> 
> - you have a list of names associated with IP addresses;
> 
> - you want to filter this list, keeping only the entries where the
> IP address is currently being leased;
> 
> - you want the filtered list to be used by dnsmasq in its name 
> resolution process.
> 
> - you want the list to be kept up to date with the current leases.
> 
> - IOW, you want DHCP clients that get an IP which appears in your 
> list one to be assigned the corresponding name in the DNS, and you 
> want the DNS to NOT map names in this list if the corresponding IP
> is not leased right now.
> 
> Is that it?
> 
> If so, /maybe/ dhcp-script is what you need or at least can help
> you detect when you need to run your update, as it would give you a
> sign that the leases just changed.
> 
> But it seems to me what you are doing is not really different from 
> what dnsmasq already does (i.e. reflexting DHCP names into the DNS)
> when the MAC-to-IP mapping is done with static leases and each
> dhcp-host line specifies a name.
> 
> If this is indeed what you are doing, then maybe you can achieve
> that with options dhcp-hostsfile and dhcp-ignore-names.
> 
> You'd use dhcp-hostsfile to point to your list written as a list
> of dhcp-host options, minus the "dhcp-host=" prefix.
> 
> You'd specify dhcp-ignore-names to make sure no host can overrule
> your list and choose its own name in its DHCP requests.
> 
> You would then only have to tell dnsmasq whenever your list changes
> by sending it SIGHUP, but you would not have to care about DHCP
> leases being granted or released, as that is automatically
> reflected in the DNS part of dnsmasq.
> 
> HTH (again, IIUC)
> 
> Amicalement,
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYox3bAAoJEBXN2mrhkTWiO7gP/0fTR+9xbNPupk1pDBbE/Y90
5XQ5/LnS++uqhfUYBL8UPzjqk+l1PpKKb3nvTlGGQ/Ul68UsZ968awQbvZQgFy0l
5WxrLyzTHnKLKzksII2ZKOGjOZ/fvU3+USHyPo6hgfKSQbCfV9+LyW3vYLBGfFMW
n84r6mCzeUSLTOAwzXk813x7z5suHaNs3Rhc0lxHUTI/Lim4Lvg9oJE6yKAP3pqY
YE7BhOvtIbGKx3JGrWoy6EyAvSzirci2b5Kol+gJ+rCi7TvTqUP5BdvLY0QLYdbY
BS7l4xxR8DWNJCrgwa+VMnEMeYIlSZ9vlkWBnGiw++ksI0M4K9C3kWAmIM0/Anfv
fBNGtjV4SsOlpydBbuQmizkZQty3NiWo1XqcGlPOS/0YVQhrLqyTBFmCbovLs0LU
v43Iqj2z01XcP+znD/FDlY41kgC3UHJPKR/1RhL966Yz7ZkHyl9d4unV2B69OLCE
gjN3HahWa8j9RJ7Y8rXmJeUbN7UPnZWuWUwR0dgid6qUMfnlo3EQniBbbNQW6Fso
EpB9N2R2npTs3cTitAJiE536Y+0jv0ICsX7GJUaWLxGGhqKmDxBQrF8V0sX1pO2g
5it7PWOY1cNONqG05QXlSsf83IMogOPlajEok6vKcsUSg/oy38HqH29UiW/fOr8N
WSvLT3mkikRqFv9hkCXZ
=Qo5a
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] client-identifier in server reply

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=88a77a78ad27ad
c3ed87b7ee603643d26cb896ee

There's a link that produces a patch file.


Cheers,

Simon.


On 13/02/17 22:18, Reddeiah Raju Konduru wrote:
> Hi Simon,
> 
> Can I get the access to patch? If not possible let me know when
> 2.77 will be available to public?
> 
> Thanks, Raju
> 
> 
> On Sat, Feb 11, 2017 at 9:05 AM, Simon Kelley
> > wrote:
> 
> On 10/02/17 01:22, Reddeiah Raju Konduru wrote:
>> Hi,
>> 
>> I am using dnsmasq 2.72. In dhclient after setting client
>> identifier to device mac address, I could see client-identifier
>> option in DISCOVER and REQUEST messages. But dhcp server(dnsmasq)
>> not setting client identifier option in OFFER and ACK replies.
>> 
>> As per RFC 6842 Section 3, If client is sending client-identifier
>> server also MUST include this option in reply.
>> 
>> Is this feature implemented in dnsmasq?
>> 
> 
> No, it's not implemented, but it should be, four years after the
> RFC.
> 
> 
> I just committed a patch to the git repo. It will be in 2.77.
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
>  
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss 
> 
> 
> 
> 
> 
> -- Thanks & Regards,
> 
> Reddeiah Raju Konduru +918095133903
> 
> 
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYox0tAAoJEBXN2mrhkTWiX5AQAKkDTaE8QPAZ7OHpHpxDYlzh
MC2cm3+WnUFjDfEM+NgiX458jY+Vz0rVd+wVTQZimQUv+1SbBSLFMNtWs2fuMqB7
lK/rdNNh1kimWe43DW6Z5xQahG44lcvE2uImni2MsYms0nOHoyEEaP4E53I0xyMr
paNiHls7RQfY/0zvdSQDvojOEe9ql1hltOYL5wL2U6htwswYZFmCzS0JLj1jd2dq
tegWxP4c9PUFT0roTUloNpapzqGM+6ZMU7YkfJ1jr/9XXfCXsy5rXSjXZlIONTSH
E8KQE8dVNDvbbGJlrgw+6495273FpiL+m0CDM5VH9uy0RB1kBFcohpBs2ZkDty0T
NYe8/5WMPjwwsO9Pq9BUQPQJ6c/ilACOBl6OrYUWB0uoIOK8jK+PLMx5LVVNSVME
fIVK20p7PFdIIcdefUdFKgSkjps0ADWQCmdjBtmeBAsyCvvfb6zU2ko1m24RcKQU
ikXPSjfLOWEoHDKcO8/rMgIIjM0AEj/h9JbKpzQsK7qooUM9Ro5cX+fb7dVbEB16
PbuzhS4aYefLr8zFief9rPLVwINAwtKyRk4V3VoP6HVCVL4i60SlclVlaKZ/NmpN
s1V+ZD0FZ6lb9jNsIbM9PauQOD4wOVu1ILwN+mnmzgikL/X14fLlNZYIekQrCQwD
gc9usyn0Z5YIkVdbVurn
=tzEi
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] [PATCH] Accept /32 and /0 as valid CIDR prefixes for rev-server directive

[Simon Kelley]

-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.


Cheers,

Simon.



On 13/02/17 23:31, olivier.ga...@sigexec.com wrote:
> From: Olivier Gayot 
> 
> [ 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  --- 
> 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

Re: [Dnsmasq-discuss] [PATCH] Accept /32 and /0 as valid CIDR prefixes for rev-server directive

[/dev/rob0]

On Tue, Feb 14, 2017 at 12:31:21AM +0100, olivier.ga...@sigexec.com wrote:
> [ 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

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?

> 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.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

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