Re: [Dnsmasq-discuss] CNAME trouble with no AAAA

[Petr Mensik]

Hi Dominick,

more below

On 10/17/19 3:41 AM, Dominick C. Pastore wrote:

Hello,

I'm having a bit of a problem with the "cname" option in Dnsmasq. I have some configuration options 
like these in dnsmasq.conf, where "host1" and "host2" have IPv4 addresses from DHCP:

domain=philadelphia.example.com
local=/philadelphia.example.com/
cname=git.example.com,host1.philadelphia.example.com
cname=nas.example.com,host2.philadelphia.example.com

This works well for A lookups on git.example.com and nas.example.com, but the 
cname options are ignored for  lookups. I think this is by design, since 
the man page says the target of a cname must be known or it will be ignored. 
(Although, maybe this is unintentional in this case? It does seem like a bit of 
a bug for a name to *sometimes* be a CNAME, depending on the request type.) 
Unfortunately, it's causing problems when the  queries are forwarded 
upstream, but I'm not sure how to fix it since these servers don't have IPv6 
addresses.

For some background:

The goal is to provide something like split-horizon DNS. Host1 and host2 reside 
behind NAT. On public DNS, philadelphia.example.com resolves to their public 
address, with git.example.com and nas.example.com both being CNAMEs to that 
name. But within the LAN, git.example.com and nas.example.com should be CNAMEs 
to their local names.
Is there any reason you want CNAME used? I think they unnecessary 
complicate the setup without obvious advantage. Just provide directly 
either local or public addresses for those names. Why is CNAME used?


The problem is, some clients cache their DNS requests. When these clients send 
a  request, it gets forwarded upstream and they end up caching the public 
CNAME record. Then, they use the (incorrect) cached CNAME for A requests, too.

Is there a good way to solve this?
Just make sure client's DNS cache is flushed after connection type 
change. That is important for split-horizon.


Thanks,
Nick

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



--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973


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

Re: [Dnsmasq-discuss] (PATCH) catch up

[Petr Mensik]

Hello Simon,

I would like to remind issue with TCP and recreated interfaces. Original
thread [1], my GitHub branch [2]. Modified a bit since last time, not
sure whether it is better to attach all those patches. Checkout of
branch would be easier for me.

I would like also non-recursive queries commented or solved [3], with
patch [4] message next.

For me, modern git hosting services make it much more simple to manage
waiting tasks. Easy to get back to them once there is enough time again.
They allow merging by single click, tagging issues into different
categories or importance. Saving time in different tasks. I have found
request for public clone [5]. Do you have any opinion for it?

Pull requests ability with comments to them would be greatly
appreciated. Makes also packager work easier, because they can link
issues in distribution to upstream issues. Would you consider creating
your clone? You have got already commits on GitHub :)

Cheers,
Petr

1.
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q3/013114.html
2. https://github.com/InfrastructureServices/dnsmasq/tree/master-bz1721668
3.
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q2/013010.html
4.
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q2/013013.html
5.
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q2/009520.html

On 9/30/19 4:51 PM, Simon Kelley wrote:
> Now would be a good time to tell me all the stuff I should be dealing with.
> 
> 
> 
> Simon
> 
> On 24/09/2019 06:54, Geert Stappers wrote:
>> On Thu, Jan 03, 2019 at 08:12:43PM +, Simon Kelley wrote:
>>> Prodding me is fine, and has done the trick here.
>>
>> :-)
>>
>>
>>> In general, I'm way behind my inbox, and struggling to catch up. Moving
>>> house is not helping :(
>>>
>>> I will try and get to everything in the end, but I won't be offended is
>>> people remind me.
>>
>> What would be a reasonable interval time?
>>
>>
>>> Cheers,
>>> Simon.
>>
>>
>> Regards
>> Geert Stappers
>>
>>
>> ___
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss@lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

Re: [Dnsmasq-discuss] [PATCH v2] Change dhcp_release to use default address when no IP subnet matches

[Petr Mensik]

Hi Brian and Simon,

I have one objection here. I think the tool should never end without
sending the request or showing some error. There is still one case left,
where it would do nothing and still exit without error. I admit it would
be rare, as IPv4 address has to be missing on given device. Anyway, I
think showing error and returning error code does not hurt.

Patch attached.

Cheers,
Petr

On 8/30/19 10:22 PM, Simon Kelley wrote:
> That looks fine. Patch applied.
> 
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> On 28/08/2019 21:13, haleyb@gmail.com wrote:
>> From: Brian Haley 
>>
>> Currently, dhcp_release will only send a 'fake' release
>> when the address given is in the same subnet as an IP
>> on the interface that was given.
>>
>> This doesn't work in an environment where dnsmasq is
>> managing leases for remote subnets via a DHCP relay, as
>> running dhcp_release locally will just cause it to
>> silently exit without doing anything, leaving the lease
>> in the database.
>>
>> Change it to use the default IP on the interface, as the
>> dnsmasq source code at src/dhcp.c does, if no matching subnet
>> IP is found, as a fall-back.  This fixes an issue we are
>> seeing in certain Openstack deployments where we are using
>> dnsmasq to provision baremetal systems in a datacenter.
>>
>> While using Dbus might have seemed like an obvious solution,
>> because of our extensive use of network namespaces (which
>> Dbus doesn't support), this seemed like a better solution
>> than creating system.d policy files for each dnsmasq we
>> might spawn and using --enable-dbus=$id in order to isolate
>> messages to specific dnsmasq instances.
>>
>> Signed-off-by: Brian Haley 
>> ---
>>  contrib/lease-tools/dhcp_release.c | 12 +---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/contrib/lease-tools/dhcp_release.c 
>> b/contrib/lease-tools/dhcp_release.c
>> index 59883d4..c866cd9 100644
>> --- a/contrib/lease-tools/dhcp_release.c
>> +++ b/contrib/lease-tools/dhcp_release.c
>> @@ -178,7 +178,7 @@ static int is_same_net(struct in_addr a, struct in_addr 
>> b, struct in_addr mask)
>>return (a.s_addr & mask.s_addr) == (b.s_addr & mask.s_addr);
>>  }
>>  
>> -static struct in_addr find_interface(struct in_addr client, int fd, 
>> unsigned int index)
>> +static struct in_addr find_interface(struct in_addr client, int fd, 
>> unsigned int index, int ifrfd, struct ifreq *ifr)
>>  {
>>struct sockaddr_nl addr;
>>struct nlmsghdr *h;
>> @@ -218,7 +218,13 @@ static struct in_addr find_interface(struct in_addr 
>> client, int fd, unsigned int
>>  
>>for (h = (struct nlmsghdr *)iov.iov_base; NLMSG_OK(h, (size_t)len); h 
>> = NLMSG_NEXT(h, len))
>>  if (h->nlmsg_type == NLMSG_DONE)
>> -  exit(0);
>> +  {
>> +/* No match found, return first address as src/dhcp.c code does */
>> +ifr->ifr_addr.sa_family = AF_INET;
>> +if (ioctl(ifrfd, SIOCGIFADDR, ifr) != -1)
>> +  return ((struct sockaddr_in *)>ifr_addr)->sin_addr;
>> +exit(0);
>> +  }
>>  else if (h->nlmsg_type == RTM_NEWADDR)
>>{
>>  struct ifaddrmsg *ifa = NLMSG_DATA(h);  
>> @@ -285,7 +291,7 @@ int main(int argc, char **argv)
>>  }
>>
>>lease.s_addr = inet_addr(argv[2]);
>> -  server = find_interface(lease, nl, if_nametoindex(argv[1]));
>> +  server = find_interface(lease, nl, if_nametoindex(argv[1]), fd, );
>>
>>memset(, 0, sizeof(packet));
>>   
>>
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
>From 8fda4b4620ca2b23152ca805d14c7cde1083fe31 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Tue, 1 Oct 2019 16:08:28 +0200
Subject: [PATCH] Report error on dhcp_release

If no IPv4 address is present on given interface, the tool would not
send any request. It would not report any error at the same time. Report
error if request send failed.

Signed-off-by: Petr Mensik 
---
 contrib/lease-tools/dhcp_release.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/contrib/lease-tools/dhcp_release.c b/contrib/lease-tools/dhcp_release.c
index c866cd9..30e77c6 100644
--- a/co

Re: [Dnsmasq-discuss] [patch] empty empty lines

[Petr Mensik]

Hi John,

dnsmasq is quite interesting piece of software. It is used by lot
different kind of projects. I think noone objected dnsmasq isn't useful
or Simon does not work on it.

But as with everything, there is always some space for improvements.
There is no reason why Simon should stop working on project just because
we have seen some issues.

Though Simon has specific code style that is unusual on different
project. It is his decision, okay with that. Just keep the codebase
consistent.

When I am against forced reformatting like someone here suggested, I
think some easy checks might be done before commiting changes. For
example, git diff would show in red whitespaces on lines without
anything else or after code before end of line. These are not nice and I
would like them removed.

I think we all understand this is open source project. We are just
trying to make code more readable and nicer. We also offer helping hands.

Are you sure we should stop that?

Cheers,
Petr

On 9/15/19 6:32 PM, john doe wrote:
> On 9/15/2019 5:45 PM, Geert Stappers wrote:
>> On Sun, Sep 08, 2019 at 02:25:18PM +0200, Geert Stappers wrote:
>>> On Sun, Sep 08, 2019 at 02:17:23PM +0200, Geert Stappers wrote:
 Made empty lines that had only spaces or tabs truely empty
 with `sed --in-place -e 's/^[ \t]*$//' src/*.c`
>>>
>>> | $ sed --in-place -e 's/^[ \t]*$//' src/*.c
>>> | $ git diff | wc
>>> |   21648   76730  597015
>>>
>>> 597015 is to big for the current settings of the mailing list.
>>>
>>>
>>> So please use the previous posting as commit message.
>>>
>>
>> Or "copy and paste"  this
>>
>> sed --in-place -e 's/^[ \t]*$//' src/*.c
>> git add src/*.c
>> git commit --author "Geert Stappers " -m "empty empty 
>> lines
>>
>> Made empty lines that had only spaces or tabs truely empty
>> with \`sed --in-place -e 's/^[ \t]*$//' src/*.c\`."
>>
>> ___
> 
> Please do stop, has Simon and other has pointed out, there are no
> reasons for Simon to change his way of working especially given the
> outstanding work he is doing with the project.
> 
> --
> John Doe
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

Re: [Dnsmasq-discuss] [BUG] [PATCH] RA are sent too fast and slows down the machine

[Petr Mensik]

Yes, it seems originating system is auto configuring interface on behalf
own RA. I have modified the test to include ip monitor output. It
receives autoconfiguration few seconds after bridge interface comes up.

Don't know how much is involved fact network namespace is used on a
bridge, it should not matter. A bit suspicious is STALE router just
before autoconfiguration. I doubt it is related, but Avahi is trying
mdns on that interfaces. Of course, Network Manager is touching it also.

Since it is custom interface created in namespace, any other host cannot
send RA to it. So I am positive it autoconfigures itself, at least on my
Fedora 29. Has same results when only bridge is used and when loopback
is also used.

14:32:22.711> 2: simbrinet6 fc58:a22:180d:7800::1/64 scope global
...
14:32:25.289> fe80::6887:6dff:fe07:6f54 dev simbr lladdr
6a:87:6d:07:6f:54 router STALE
14:32:25.293> prefix fc58:a22:180d:7800::/64dev simbr onlink autoconf
valid 1800 preferred 1800
14:32:27.317> 2: simbrinet6
fc58:a22:180d:7800:6887:6dff:fe07:6f54/64 scope global dynamic mngtmpaddr
14:32:27.318> valid_lft 1798sec preferred_lft 1798sec

Cheers,
Petr

On 8/30/19 11:26 PM, Simon Kelley wrote:
> This is useful information, but what I don't understand, is where the
> flooding comes from. Sure, this confusion means that unsolicted ra will
> run every time there's a "new address" event, even if the new address
> isn't on the expected interface, but I can't see how it generates more
> "new address events" and therefore a flood of packets.
> 
> 
> Unless, the originating system receives _its_own_ RA and that generates
> a "new address" event?
> 
> Simon.
> 
> 
> 
> On 28/08/2019 20:38, Petr Mensik wrote:
>> Hi,
>>
>> I have found what is going on.
>>
>> That RA seems to be switching between dynamically assigned address and
>> manually assigned address. It is just wrong to assume there is one
>> address on physical interface, especially in IPv6 world.
>>
>> It seems my patch (attached), checking just subnet and not caring for
>> exact address inside, fixes advertisement floods. But I am not sure
>> whether it also does not stop announces for new dynamic addresses as it
>> should. It might help to use valid parameter to distinguish between
>> static address and dynamic. I am unsure if it is required for both or
>> just dynamic one?
>>
>> I am sure it would send once for newly created interface. I think it
>> should be enough, right?
>>
>> Some notes from debugging:
>>
>> Breakpoint 1, construct_worker (scope=, flags=> out>, preferred=, valid=1800,
>> vparam=0x7ffc9afc2b60, if_index=2, prefix=64, local=0xa6dda4) at
>> dhcp6.c:685
>> 2: /x *local = {__in6_u = {__u6_addr8 = {0xfc, 0x58, 0xa, 0x22, 0x18,
>> 0xd, 0x78, 0x0, 0x8, 0x21, 0xd1, 0xff, 0xfe, 0x74, 0xec,
>>   0x2a}, __u6_addr16 = {0x58fc, 0x220a, 0xd18, 0x78, 0x2108, 0xffd1,
>> 0x74fe, 0x2aec}, __u6_addr32 = {0x220a58fc, 0x780d18,
>>   0xffd12108, 0x2aec74fe}}}
>>
>> Breakpoint 1, construct_worker (scope=, flags=> out>, preferred=, valid=-1,
>> vparam=0x7ffc9afc2b60, if_index=2, prefix=64, local=0xa6ddec) at
>> dhcp6.c:685
>> 685  ra_start_unsolicited(param->now, template);
>> 2: /x *local = {__in6_u = {__u6_addr8 = {0xfc, 0x58, 0xa, 0x22, 0x18,
>> 0xd, 0x78, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1},
>> __u6_addr16 = {0x58fc, 0x220a, 0xd18, 0x78, 0x0, 0x0, 0x0, 0x100},
>> __u6_addr32 = {0x220a58fc, 0x780d18, 0x0, 0x100}}}
>>
>> Cooperative ip link:
>> 2: simbr:  mtu 1500 qdisc noqueue state
>> UP group default qlen 1000
>> link/ether 0a:21:d1:74:ec:2a brd ff:ff:ff:ff:ff:ff
>> inet 172.30.16.1/24 scope global simbr
>>valid_lft forever preferred_lft forever
>> inet6 fc58:a22:180d:7800:821:d1ff:fe74:ec2a/64 scope global dynamic
>> mngtmpaddr
>>valid_lft 1699sec preferred_lft 1699sec
>> inet6 fc58:a22:180d:7800::1/64 scope global
>>valid_lft forever preferred_lft forever
>> inet6 fe80::821:d1ff:fe74:ec2a/64 scope link
>>valid_lft forever preferred_lft forever
>>
>>
>> Regards,
>> Petr
>>
>> On 8/27/19 10:42 PM, Maarten de Vries wrote:
>>> Hey,
>>>
>>> I haven't dug very deep yet, but I can comment on the intent of the
>>> particular commit: without it, dnsmasq didn't do any unsolicited RAs on
>>> interfaces that are created after dnsmasq was started. It definitely
>>> should do unsolicited RAs on those interfaces too, although obviously
>>> not quite so many so often. I'm not sure 

Re: [Dnsmasq-discuss] [BUG] [PATCH] RA are sent too fast and slows down the machine

[Petr Mensik]

Hi,

I have found what is going on.

That RA seems to be switching between dynamically assigned address and
manually assigned address. It is just wrong to assume there is one
address on physical interface, especially in IPv6 world.

It seems my patch (attached), checking just subnet and not caring for
exact address inside, fixes advertisement floods. But I am not sure
whether it also does not stop announces for new dynamic addresses as it
should. It might help to use valid parameter to distinguish between
static address and dynamic. I am unsure if it is required for both or
just dynamic one?

I am sure it would send once for newly created interface. I think it
should be enough, right?

Some notes from debugging:

Breakpoint 1, construct_worker (scope=, flags=, preferred=, valid=1800,
vparam=0x7ffc9afc2b60, if_index=2, prefix=64, local=0xa6dda4) at
dhcp6.c:685
2: /x *local = {__in6_u = {__u6_addr8 = {0xfc, 0x58, 0xa, 0x22, 0x18,
0xd, 0x78, 0x0, 0x8, 0x21, 0xd1, 0xff, 0xfe, 0x74, 0xec,
  0x2a}, __u6_addr16 = {0x58fc, 0x220a, 0xd18, 0x78, 0x2108, 0xffd1,
0x74fe, 0x2aec}, __u6_addr32 = {0x220a58fc, 0x780d18,
  0xffd12108, 0x2aec74fe}}}

Breakpoint 1, construct_worker (scope=, flags=, preferred=, valid=-1,
vparam=0x7ffc9afc2b60, if_index=2, prefix=64, local=0xa6ddec) at
dhcp6.c:685
685 ra_start_unsolicited(param->now, template);
2: /x *local = {__in6_u = {__u6_addr8 = {0xfc, 0x58, 0xa, 0x22, 0x18,
0xd, 0x78, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1},
__u6_addr16 = {0x58fc, 0x220a, 0xd18, 0x78, 0x0, 0x0, 0x0, 0x100},
__u6_addr32 = {0x220a58fc, 0x780d18, 0x0, 0x100}}}

Cooperative ip link:
2: simbr:  mtu 1500 qdisc noqueue state
UP group default qlen 1000
link/ether 0a:21:d1:74:ec:2a brd ff:ff:ff:ff:ff:ff
inet 172.30.16.1/24 scope global simbr
   valid_lft forever preferred_lft forever
inet6 fc58:a22:180d:7800:821:d1ff:fe74:ec2a/64 scope global dynamic
mngtmpaddr
   valid_lft 1699sec preferred_lft 1699sec
inet6 fc58:a22:180d:7800::1/64 scope global
   valid_lft forever preferred_lft forever
inet6 fe80::821:d1ff:fe74:ec2a/64 scope link
   valid_lft forever preferred_lft forever


Regards,
Petr

On 8/27/19 10:42 PM, Maarten de Vries wrote:
> Hey,
> 
> I haven't dug very deep yet, but I can comment on the intent of the
> particular commit: without it, dnsmasq didn't do any unsolicited RAs on
> interfaces that are created after dnsmasq was started. It definitely
> should do unsolicited RAs on those interfaces too, although obviously
> not quite so many so often. I'm not sure why that happens. Note that the
> commit didn't introduce the fast RAs, it only enabled unsolicited RAs
> (including fast) for newly created interfaces too.
> 
> I wonder why this happens in those test cases and at-least one Raspberry
> Pi, but not on my server. Is there any information you could provide to
> pinpoint when exactly this bug triggers and when not? For example: what
> happens if the virtual interface is created before dnsmasq starts? Does
> it also trigger on bridge interfaces (which is what I personally tested
> the commit with) for you?
> 
> I will attempt to investigate too, but I'm somewhat swamped for time so
> I can't promise fast results.
> 
> Kinds regards,
> 
> Maarten
> 
> 
> On 27-08-2019 10:45, Iain Lane wrote:
>> On Wed, Aug 21, 2019 at 08:59:07PM +0200, Petr Mensik wrote:
>>> Hi Simon and Maarten,
>>>
>>> we discovered when playing with NetworkManager-ci [1], that lastest
>>> release is somehow broken. Test running dnsmasq are quite slow on latest
>>> release.
>>>
>>> I have created repeatable started script that reproduces it. Then used
>>> git bisect to find when it was broken. It seems fast sending were
>>> intentional in commit 0a496f059c1e9 [2], but maybe way it affects the
>>> system were underestimated. It is significant for systems that hit such
>>> issue. I think it has to be fixed to slow it down to short time
>>> interval, not endless loop. Reported as Fedora bug [3].
>> Thanks for this Petr. Would you be able to share the script you've used,
>> so that perhaps an upstream developer could recreate the bug?
>>
>> Mainly I wanted to chime in and say that (in addition to the other
>> instance referenced), we found this in the NetworkManager testsuite in
>> Ubuntu. I didn't come up with a nice reproducer at the time, but we did
>> identify the same commit and we've reverted it in Ubuntu. I posted on
>> the ML back then but we didn't get much traction and I didn't follow up
>> very aggressively.
>>
>>   
>> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q4/012709.html
>>
>>
>>   
>> https://launchpadlibrarian.net/405377161/dnsmas

Re: [Dnsmasq-discuss] [BUG] RA are sent too fast and slows down the machine

[Petr Mensik]

Hi Vladislav,

No, I am talking about different issue, commit already released in
latest release. It was introduced by commit [1]. I have no proper fix
for it yet, but revert offending commit.

I think you were mentioning issue is have different reproducer for [2],
TCP no longer listened on interface after recreation. I have working fix
to that too [3], applied already in Fedora. Only feedback so far was
issue with [1], sounds good. Original issue with the same address is
already fixed. But my Thunderbird does not display it well, maybe others
have also issues with it. That is why I started creating pull requests
to myself...

1.
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=0a496f059c1e9d75c33cce4c1211d58422ba4f62
2.
https://github.com/InfrastructureServices/dnsmasq-tests/blob/master/bz1728701.sh
3. https://github.com/InfrastructureServices/dnsmasq/pull/1

On 8/28/19 1:25 PM, Vladislav Grishenko wrote:
> Hi, Petr,
> 
> Just worrying, isn't this bug a side effect of previous interface-related 
> binding patch we're talking about?
> If yes, since it's not in upstream, it can be quite tricky to reproduce it on 
> vanilla sources.
> 
> Best Regards, Vladislav Grishenko
> 
> -Original Message-
> From: Dnsmasq-discuss  On 
> Behalf Of Petr Mensik
> Sent: Wednesday, August 28, 2019 12:11 PM
> To: dnsmasq-discuss@lists.thekelleys.org.uk
> Subject: Re: [Dnsmasq-discuss] [BUG] RA are sent too fast and slows down the 
> machine
> 
> Hi Iain,
> 
> of course. I am sorry, forgot to add a link as intended[1]. Used base report 
> from Network Manager tester report. I added it to Fedora bug mentioned, but 
> forgot to add script itself. At least to me, it produces tens of RA announces.
> 
> Regards,
> Petr
> 
> [1]
> https://github.com/InfrastructureServices/dnsmasq-tests/blob/master/bz1739797.sh
> 
> On 8/27/19 10:45 AM, Iain Lane wrote:
>> On Wed, Aug 21, 2019 at 08:59:07PM +0200, Petr Mensik wrote:
>>> Hi Simon and Maarten,
>>>
>>> we discovered when playing with NetworkManager-ci [1], that lastest 
>>> release is somehow broken. Test running dnsmasq are quite slow on 
>>> latest release.
>>>
>>> I have created repeatable started script that reproduces it. Then 
>>> used git bisect to find when it was broken. It seems fast sending 
>>> were intentional in commit 0a496f059c1e9 [2], but maybe way it 
>>> affects the system were underestimated. It is significant for systems 
>>> that hit such issue. I think it has to be fixed to slow it down to 
>>> short time interval, not endless loop. Reported as Fedora bug [3].
>>
>> Thanks for this Petr. Would you be able to share the script you've 
>> used, so that perhaps an upstream developer could recreate the bug?
>>
>> Mainly I wanted to chime in and say that (in addition to the other 
>> instance referenced), we found this in the NetworkManager testsuite in 
>> Ubuntu. I didn't come up with a nice reproducer at the time, but we 
>> did identify the same commit and we've reverted it in Ubuntu. I posted 
>> on the ML back then but we didn't get much traction and I didn't 
>> follow up very aggressively.
>>
>>   
>> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q4/012709
>> .html
>>
>>   
>> https://launchpadlibrarian.net/405377161/dnsmasq_2.80-1_2.80-1ubuntu1.diff.gz
>>   (the commit ID referenced in the changelog there seems or from
>>   somewhere else, it's the same patch)
>>
>> Cheers,
>>

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

Re: [Dnsmasq-discuss] Best way to handle dual-wans with dnsmasq (John Knight)

[Petr Mensik]

Hi John,

we are using kind of hack for similar purpose in dnssec-trigger package.
If udhcpc serves domain or search directives for resolv.conf, they can
be used to redirect just those domains to management servers. It can
work centrally managed. But requires special handling of search domains,
that is not usually done. Do not know whether udhcpc is capable such
configuration.

You would have to ask administrator to add some domain name into DHCP
offered. I doubt you can configure dnsmasq to query both servers. It
usually picks one fastest and stick to it until it responds. If the
management server does not provide full DNS resolver, it would not work.
How would it respond to addresses it does not know? NXDomain means
authoritative reply, no such domain exist. You should not ask other
server to confirm or deny that information. Is that management DNS
service dnsmasq based as well? Every other server requires some 'zone'
concept, that organizes names into domains and subdomains. Just dnsmasq
does not care and can serve whatever name it chooses.

I think some rule to distinguish management names and normal traffic has
to be made first.

Regards,
Petr

On 8/26/19 7:28 PM, John Knight wrote:
> Hi Petr,
> 
> I think what you are suggesting is to use server entry to define the IP 
> Addresss corresponding to the domain name of the dns server on the management 
> interface.  Unfortunately, in my case we use udhcpc to learn of the upstream 
> dns server;s IP address.  There is no domain name for the management 
> server... only an IP address.  The only thing I will know is that the 
> xx.xx.xx.xx IP address I learned via udhcpc is on the management wan 
> interface... I won't know its domain name.   So for any given dns request 
> dnsmasq gets, dnsmasq will potentially need to query both wans (data and 
> management) to resolve the IP address.  Is this possible to do?  It will NOT 
> have a domain name to direct it to the right wan to query.
> 
> Thanks,
> 
> John
> 
> 
> From: John Knight
> Sent: Monday, August 26, 2019 10:07 AM
> To: dnsmasq-discuss@lists.thekelleys.org.uk
> Subject: Re: Best way to handle dual-wans with dnsmasq (John Knight)
> 
> Hi Petr,
> 
> In my situation with dual-wans, I am not too concerned about management 
> network being accessible to  all users, so using a single dnsmasq is 
> acceptable.  I am using dnsmasq to serve dhcp and dns requests on the data 
> network, but it only needs to support dns requests on the management network.
> 
> What I have tried so far is to add the nameserver entries for both wans to 
> resolv.conf.  However, I am seeing dns queries only go to the data wan... 
> they are not going to the management wan.   How does dnsmasq know that 
> nameserver xx.xx.xx.xx is on management wan, and nameserver yy.yy.yy.yy is on 
> data wan... and how does dnsmasq know to query both wans for any given dns 
> request?  I think what I had hoped is that dnsmasq would first query dns 
> server upstream on the data wan, then if it did not resolve the address, it 
> would then try to query the dns server on the management wan.
> 
> I know there is a listen address which I presume is somehow used to in 
> essence route the request to a given wan, but I am not sure.  I think what I 
> really need is an example on how to do this.
> 
> Thanks for your help with this.
> 
> John
> __ 
> Confidential This e-mail and any files transmitted with it are the property 
> of Belkin International, Inc. and/or its affiliates, are confidential, and 
> are intended solely for the use of the individual or entity to whom this 
> e-mail is addressed. If you are not one of the named recipients or otherwise 
> have reason to believe that you have received this e-mail in error, please 
> notify the sender and delete this message immediately from your computer. Any 
> other use, retention, dissemination, forwarding, printing or copying of this 
> e-mail is strictly prohibited. Pour la version fran?aise: 
> http://www.belkin.com/email-notice/French.html F?r die deutsche ?bersetzung: 
> http://www.belkin.com/email-notice/German.html 
> __
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

Re: [Dnsmasq-discuss] [BUG] RA are sent too fast and slows down the machine

[Petr Mensik]

Hi Iain,

of course. I am sorry, forgot to add a link as intended[1]. Used base
report from Network Manager tester report. I added it to Fedora bug
mentioned, but forgot to add script itself. At least to me, it produces
tens of RA announces.

Regards,
Petr

[1]
https://github.com/InfrastructureServices/dnsmasq-tests/blob/master/bz1739797.sh

On 8/27/19 10:45 AM, Iain Lane wrote:
> On Wed, Aug 21, 2019 at 08:59:07PM +0200, Petr Mensik wrote:
>> Hi Simon and Maarten,
>>
>> we discovered when playing with NetworkManager-ci [1], that lastest
>> release is somehow broken. Test running dnsmasq are quite slow on latest
>> release.
>>
>> I have created repeatable started script that reproduces it. Then used
>> git bisect to find when it was broken. It seems fast sending were
>> intentional in commit 0a496f059c1e9 [2], but maybe way it affects the
>> system were underestimated. It is significant for systems that hit such
>> issue. I think it has to be fixed to slow it down to short time
>> interval, not endless loop. Reported as Fedora bug [3].
> 
> Thanks for this Petr. Would you be able to share the script you've used,
> so that perhaps an upstream developer could recreate the bug?
> 
> Mainly I wanted to chime in and say that (in addition to the other
> instance referenced), we found this in the NetworkManager testsuite in
> Ubuntu. I didn't come up with a nice reproducer at the time, but we did
> identify the same commit and we've reverted it in Ubuntu. I posted on
> the ML back then but we didn't get much traction and I didn't follow up
> very aggressively.
> 
>   http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q4/012709.html
> 
>   
> https://launchpadlibrarian.net/405377161/dnsmasq_2.80-1_2.80-1ubuntu1.diff.gz
>   (the commit ID referenced in the changelog there seems or from
>   somewhere else, it's the same patch)
> 
> Cheers,
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973



signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Best way to handle dual-wans with dnsmasq

[Petr Mensik]

Hi John,

unless you want too much work, I would suggest using separate domain for
management names. If you are not afraid management network would be
accessible to all users, just use --server=/mgmt.example.net/1.2.3.4 and
--server=5.6.7.8 for normal names (or just read /etc/resolv.conf for
them). If names are not in separate domain, I doubt there is good
solution. using --server/host-mgmt-1.XY/1.2.3.4 may work, but I think
you should ask administrators to create easier system in such case :)

I think I have understood it right, your dnsmasq is just dns proxy for
both networks and does not serve any DHCP or DNS to those networks, right?

On 8/26/19 4:58 AM, John Knight wrote:
> Hi,
> 
> I have a system that has two WAN interfaces... one WAN is used for 
> management, and the other WAN is used for normal internet access.  Each WAN 
> has its own DNS and DHCP Servers upstream.  The DNS Server on the Management 
> WAN will serve out IP addresses for the management sites, while the other WAN 
> will use public DNS Servers to resolve IP addresses for DNS queries.
> 
> I am interested in knowing best practice in how to configure dnsmasq for 
> these dual-wan situations?   Do I need to run two dnsmasq processes or can a 
> single dnsmasq process handle multiple WANs?  The management processes 
> running on the system will use eth0.10 (VLAN 10) to access the management 
> WAN, while normal user traffic will use eth0 (untagged) interface to get to 
> the internet.
> 
> Does anyone have a sample configuration on how to configure this?
> 
> Thanks in advance,
> 
> John
> 
> __ 
> Confidential This e-mail and any files transmitted with it are the property 
> of Belkin International, Inc. and/or its affiliates, are confidential, and 
> are intended solely for the use of the individual or entity to whom this 
> e-mail is addressed. If you are not one of the named recipients or otherwise 
> have reason to believe that you have received this e-mail in error, please 
> notify the sender and delete this message immediately from your computer. Any 
> other use, retention, dissemination, forwarding, printing or copying of this 
> e-mail is strictly prohibited. Pour la version française: 
> http://www.belkin.com/email-notice/French.html Für die deutsche Übersetzung: 
> http://www.belkin.com/email-notice/German.html 
> __
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

Re: [Dnsmasq-discuss] is dnsmasq shared by all ports

[Petr Mensik]

Hi Gordon,

depends on your configuration, which you forgot to provide.
What is in /etc/resolv.conf for example? What flags/configuration are
both instances using?

I would quess 127.0.0.1 might be in resolv.conf. That would mean hosts.2
instance would query hosts.1 instance. That might or might not be
desired. Please share more details how you configuration looks like.

Cheers,
Petr

On 8/25/19 2:55 AM, Gordon Shawn wrote:
> I'm running two dnsmasqs daemons one on port 53 another one on port 5333,
> both set cache-size=8192, are these two dnsmasq processes sharing the same
> cache or they're totally independent as far as cache goes?
> 
> each dnsmasq also calls different host files, i.e. /etc/hosts.1(for port
> 53) and /etc/hosts.2(for port 5333), they do share a /etc/hosts though. I
> noticed clients using 5333 port sometimes get IP from /etc/hosts.1.
> 
> so the question is, can I run two dnsmasq processes on different ports
> totally independently?
> 
> Thanks,
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

[Dnsmasq-discuss] [BUG] RA are sent too fast and slows down the machine

[Petr Mensik]

Hi Simon and Maarten,

we discovered when playing with NetworkManager-ci [1], that lastest
release is somehow broken. Test running dnsmasq are quite slow on latest
release.

I have created repeatable started script that reproduces it. Then used
git bisect to find when it was broken. It seems fast sending were
intentional in commit 0a496f059c1e9 [2], but maybe way it affects the
system were underestimated. It is significant for systems that hit such
issue. I think it has to be fixed to slow it down to short time
interval, not endless loop. Reported as Fedora bug [3].

1. https://github.com/NetworkManager/NetworkManager-ci
2.
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=0a496f059c1e9d75c33cce4c1211d58422ba4f62
3. https://bugzilla.redhat.com/show_bug.cgi?id=1739797

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

Re: [Dnsmasq-discuss] Web interface for DNSmasq

[Petr Mensik]

Hi Robert,

it might be useful to know you use cases. What parts of dnsmasq you need
and what parts you do not. For example libvirt has its own machinery to
edit hosts in xml file and generate dnsmasq config files. Hosts could be
separate files. Leases could also be provided by script. If you need
mostly mapping from names to ip and mac addresses, there might be some
existing solutions.

I do not know any web tool myself however. I would just generate config
parts from template.

Regards,
Petr

On 8/7/19 11:29 PM, Robert Shelton (NexusNet) wrote:
> I am looking for a web interface for DNSmasq. I found and successfully
> installed webmin only to discover that the DNSmasq module appears to be
> old and currently unavailable. Can anyone point me to a solution - need
> not be webmin, although that looks like a nice/useful admin tool that
> I'd be happy to use for DNS admin.
> 
> Thanks,
> 
> Robert
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

Re: [Dnsmasq-discuss] Issue with SO_BINDTODEVICE for dhcp

[Petr Mensik]

Hi Martin,

I think it would make more sense to not derive intended behaviour from
number of interfaces but allow desired behaviour to be specified explicitly.

If machines want to reuse the same address multiple times on different
interfaces, they may want explicit configuration of BINDTODEVICE
enabled. Default configuration may stay auto detection to keep backward
compatibility, but would allow configuring it without surprises.

On the other hand, it seems to me binding just to single device is
limitation of current code more that well thought requirement. More below.

After experience with TCP socket on interfaces, I think it should log
changes in listening sockets. It is nightmare to debug that in debugger.

Regards,
Petr

On 7/5/19 12:55 PM, Martin Wilck wrote:
> I've just found a strange issue with dnsmasq's dhcp server, which I
> believe is caused by the commit 9380ba7 "Set SO_BINDTODEVICE on DHCP
> sockets when doing DHCP on one interface".
> 
> I was running a single instance dnsmasq for on various local interfaces
> on my system. At the same time, I was running libvirt managed networks,
> which spawn a separate dnsmasq instance for every network created.
> (That's the way it has to be with libvirt). The configuration of the
> first, multiple-interface instance was done with "listen-address" and
> "bind-dynamic"; the listen addresses were 127.0.0.1 plus one address on
> every VLAN on this server.
> 
> Anyway, the above-mentioned commit causes strange behavior for the
> multi-interface dnsmasq instance. SO_BINDTODEVICE will be used if and
> only if exactly one of the configured interfaces is up when dnsmasq is
> started. In this case, if other interfaces are brought up later, dhcp
> queries via these new interfaces don't work, because the dhcp socket is
> bound to the first interface only. If at the time of dnsmasq startup,
> either 0 or >= 2 interfaces are up, dhcp queries work just fine from
> any interface, including those brought up later.
> 
> While this is certainly a corner case, it strongly violates the
> principle of least surprise - the status at the time of dnsmasq startup
> has an effect on whether freshly brought-up interfaces will be serviced
> later. Especially with "bind-dynamic", my expectation was that
> dynamically added interfaces would be served.

They would be, but only for DNS queries. Handling of DHCP sockets is
different, they always use SO_REUSEPORT. Only DHCP would bind to device.
DNS code is intentionally binding just one time to single address. DHCP
socket on contrary would bind to ANY address and bind it to device.

It would require multiple sockets for DHCP on each interface it listens
on. It has now just single socket globally, so listener would have to be
moved from dhcp_init/make_fd to something reacting to newaddress. Like
create_bound_listeners(0) for example? But where would be stored socket
bound to each device? daemon->dhcpfd cannot be bound to multiple interfaces.

I think possible solution would be to move socket itself into struct
irec, to daemon->interfaces. There is parameter dhcp_ok, which is
checked only in whichdevice. It is computed again on every
enumerate_interfaces after each change. It only checks whether there is
(dhcp) single device. Instead, it could create listener socket for each
interface served and bind to it.

I think current state is needed, because bigger rewrite was never done
to dhcp sockets. Without it, it has to be just single socket. structure
listener (used in dns and tftp) does not use SO_REUSEPORT, so there has
to be just single listener on single address. DHCP socket needs the
opposite, binding to every interface enabled separately.
> 
> According to the bug report that motivated the mentioned patch (
> http://codeha.us/openstack/msg09684.html), such a mixture of multi-
> interface and single-interface instances would be doomed to fail
> anyway, because of the issues related to receiving DHCP unicast
> packets. Thus perhaps this configuration should be generally forbidden
> - but I, for one, have not observed the reported unicast-packet issues
> (failing dhcp requests or renewals) up to now.
> 
> Would it perhaps be possible to re-run the SO_BINDTODEVICE logic in the
> newaddress() code path, and dynamically bind/undbind the socket if the
> number of dhcp interfaces changed between 1 and something else?
> 
> Regards,
> Martin
> 
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

Re: [Dnsmasq-discuss] [PATCH] Issues with TCP queries on recreated interfaces.

[Petr Mensik]

Hi,
because there is more patches, I created a pull request in my fork on
github [1]. I think it is somehow more handy than attachments here. I
think all of them are already sent. Attaching complete set here again in
one place. Also made Fedora bug #1728701 [2].

We need a fix because we are hitting this issue in OpenStack a lot. I
would like to include fix and would like it to be the same way on
upstream. If there is different way to fix it, please say so.

Any more opinions on patches 4 and 5?

1. https://github.com/InfrastructureServices/dnsmasq/pull/1
2. https://bugzilla.redhat.com/show_bug.cgi?id=1728701

On 7/10/19 1:34 PM, Vladislav Grishenko wrote:
> Hi Petr,
> 
>> Not tested this specific case, but I think it should be handled correctly, 
>> unlike previous code. Because it now compares also interface index, it will 
>> mark existing entry as found only if interface index also match. If it does 
>> not, new entry is created with correct index instead.
> 
> Checked, unfortunately interface index comparison breaks the things.
> If there's 2+ interface with same address on startup, no error is happen, 
> single TCP and multiple UDP (unlike before) sockets are created, on any of 
> such interface shutdown - thins single TCP socket is closed (unlike before), 
> so there are noting listens on TCP:53 after that.
> If there's only one interface on startup - single TCP sockets are 
> created, on subsequent interface up with the same address - bind error raised 
> and only UDP socket is created additionally (unlike before).

Fixed now.
> 
> At the moment, dnsmasq logic expects single TCP/UDP socket per address even 
> for multiple interfaces.
> For example, comment in iface_allowed() states that:
>   /* check whether the interface IP has been added already
>* we call this routine multiple times */
> So, I'm afraid, seems proposed changes does not play well with that.
> How do you think, can it be solved too?
> Reproduction this case is quite easy, just need to create dummy interface 
> with same address (different netmask) and up/down it.
> 
>> Ok, I forgot to follow style on 3rd patch. Attached fixed formatting and 
>> removed debug log on interface removal.
> 
> Thanks,  fyi sed -r 's/[ ]{8}/\t/' is missed too.
> 
>> I think that is better to state explicitly return value is not used.
> 
> I think that would be better to rip it off from functional patch, and let it 
> be as separate full patch for all prettyprint_* instances not just for some 
> selected.
> At the other hand, with no __attribute__((warn_unused_result)) it will not 
> generate warning anyway.

I changed only things related to changes I did. We sometime run Coverity
scans on the codebase, and such issues arise there. So I make it the way
no new issues are discovered by my changes.

On the other hand, maybe it should print complete address with port as
well. Precise information does not hurt, even when port would be a bit
repeating. Now it includes also port. These are just debug information
after all, no need for them to be shortest possible.
> 
> Best Regards, Vladislav Grishenko
> 
> -Original Message-
> From: Petr Mensik  
> Sent: Wednesday, July 10, 2019 3:01 PM
> To: Vladislav Grishenko ; 
> dnsmasq-discuss@lists.thekelleys.org.uk
> Subject: Re: [Dnsmasq-discuss] [PATCH] Issues with TCP queries on recreated 
> interfaces.
> 
> Hi Vladislav
> 
> On 7/9/19 10:00 PM, Vladislav Grishenko wrote:
>> Hi Petr,
>>
>> Regarding 0002-Compare-address-and-interface-index-for-allowed-inte.patch, 
>> does it support case with different valid interfaces with the same address?
>> For example:
>>  eth0 192.168.1.1/24
>>  tun0 192.168.1.1./16 (created/destroyed dynamically)
> 
> Not tested this specific case, but I think it should be handled correctly, 
> unlike previous code. Because it now compares also interface index, it will 
> mark existing entry as found only if interface index also match. If it does 
> not, new entry is created with correct index instead.
> It should work, unlike previous code, it should keep both interface addresses 
> stored separately.
> 
> If tun0 is often destroyed and recreated, number of interfaces records might 
> grow. That is reason for patch #3, which removes dropped interfaces after 
> creating new ones.
>>
>> Regarding appearance, seems newly added code doesn’t fully follow dnsmasq 
>> code style in several places:
>> * indentation (should be ident ==2 spaces, 8 spaces == \t)
>> * brackets on the same code lines
> Ok, I forgot to follow style on 3rd patch. Attached fixed formatting and 
> removed debug log on interface removal.
>> * function args on the next line are not aligned with the fir

Re: [Dnsmasq-discuss] Wildcard in interface names

[Petr Mensik]

Yes, according to code, wildcard is matched in no-dhcp-interface as well.

On 7/25/19 1:33 AM, Art Greenberg wrote:
> The man page states that an asterisk (*) can be used as a wildcard with the 
> --interface and --except-interface options. Does this also apply to 
> --no-dhcp-interface?
> 
> Thanks.
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

Re: [Dnsmasq-discuss] [PATCH] Issues with TCP queries on recreated interfaces.

[Petr Mensik]

Hi Vladislav,

I think I found usable solution for duplicate addresses. I think there
is many list of interfaces without clear distinction between them. For
example, daemon->int_names contains all addresses quite similar to
daemon->interfaces. And there is also if_names and if_addrs. I were able
just decipher interfaces is always made from real interface names found
on system. No wildcards are used.

Anyway, made two new patches on top of previous. First includes address
in listener structure and check existing addresses before creating new
address. If there is already such listener, note it is used more times.
If one interface stops listening, do not stop listening yet until all
listeners end.

Because address includes family, patch 5 removes duplicate family. Made
that separate because it kind of cover what is important change.

Cheers,

Petr

On 7/11/19 12:23 PM, Petr Mensik wrote:
> Oh, tested it and confirm it breaks the same IP addreses listeners. If
> the same address is used, second address listener is not created
> successfully. It reports:
> 
> dnsmasq: failed to create listening socket for 10.129.1.1: Address
> already in use
> 
> When the first one is destroyed, second one cannot take over it.
> Unfortunately, it seems interfaces list works as unique addresses at the
> same time.
> 
> One possible solution is socket option SO_REUSEPORT, which would allow
> binding multiple times to the same address. However, it seems its
> support is not very portable, at least on stack overflow article. It
> might create more problem than it solves. I think its usage should be
> configurable. Not a good solution.
> 
> There is also secondary list in daemon->if_addrs, which maybe should be
> used instead to create real listeners. Now it creates listeners for
> explicitly given addresses without interface name.
> 
> Unless TCP queries should stop checking interface indexes, list of
> current indexes is required somewhere. I think daemon->interfaces is the
> best list for it. But when creating listeners, just single should be
> created for a shared address. Current structures do not allow such
> sharing AFAIK. Either irec should be only one for single physical
> interface and should have address records for each address nested.
> 
> I am looking on possible solutions. I do not have any good solution yet.
> I doubt it can be solved with as little changes as I used before.
> 
> 1.
> https://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t
> 
> On 7/10/19 1:34 PM, Vladislav Grishenko wrote:
>> Hi Petr,
>>
>>> Not tested this specific case, but I think it should be handled correctly, 
>>> unlike previous code. Because it now compares also interface index, it will 
>>> mark existing entry as found only if interface index also match. If it does 
>>> not, new entry is created with correct index instead.
>>
>> Checked, unfortunately interface index comparison breaks the things.
>> If there's 2+ interface with same address on startup, no error is happen, 
>> single TCP and multiple UDP (unlike before) sockets are created, on any of 
>> such interface shutdown - thins single TCP socket is closed (unlike before), 
>> so there are noting listens on TCP:53 after that.
>> If there's only one interface on startup - single TCP sockets are 
>> created, on subsequent interface up with the same address - bind error 
>> raised and only UDP socket is created additionally (unlike before).
>>
>> At the moment, dnsmasq logic expects single TCP/UDP socket per address even 
>> for multiple interfaces.
>> For example, comment in iface_allowed() states that:
>>  /* check whether the interface IP has been added already
>>   * we call this routine multiple times */
>> So, I'm afraid, seems proposed changes does not play well with that.
>> How do you think, can it be solved too?
>> Reproduction this case is quite easy, just need to create dummy interface 
>> with same address (different netmask) and up/down it.
>>
>>> Ok, I forgot to follow style on 3rd patch. Attached fixed formatting and 
>>> removed debug log on interface removal.
>>
>> Thanks,  fyi sed -r 's/[ ]{8}/\t/' is missed too.
>>
>>> I think that is better to state explicitly return value is not used.
>>
>> I think that would be better to rip it off from functional patch, and let it 
>> be as separate full patch for all prettyprint_* instances not just for some 
>> selected.
>> At the other hand, with no __attribute__((warn_unused_result)) it will not 
>> generate warning anyway.
>>
>> Best Regards, Vladislav Grishenko
>>
&g

Re: [Dnsmasq-discuss] [PATCH] Issues with TCP queries on recreated interfaces.

[Petr Mensik]

Oh, tested it and confirm it breaks the same IP addreses listeners. If
the same address is used, second address listener is not created
successfully. It reports:

dnsmasq: failed to create listening socket for 10.129.1.1: Address
already in use

When the first one is destroyed, second one cannot take over it.
Unfortunately, it seems interfaces list works as unique addresses at the
same time.

One possible solution is socket option SO_REUSEPORT, which would allow
binding multiple times to the same address. However, it seems its
support is not very portable, at least on stack overflow article. It
might create more problem than it solves. I think its usage should be
configurable. Not a good solution.

There is also secondary list in daemon->if_addrs, which maybe should be
used instead to create real listeners. Now it creates listeners for
explicitly given addresses without interface name.

Unless TCP queries should stop checking interface indexes, list of
current indexes is required somewhere. I think daemon->interfaces is the
best list for it. But when creating listeners, just single should be
created for a shared address. Current structures do not allow such
sharing AFAIK. Either irec should be only one for single physical
interface and should have address records for each address nested.

I am looking on possible solutions. I do not have any good solution yet.
I doubt it can be solved with as little changes as I used before.

1.
https://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t

On 7/10/19 1:34 PM, Vladislav Grishenko wrote:
> Hi Petr,
> 
>> Not tested this specific case, but I think it should be handled correctly, 
>> unlike previous code. Because it now compares also interface index, it will 
>> mark existing entry as found only if interface index also match. If it does 
>> not, new entry is created with correct index instead.
> 
> Checked, unfortunately interface index comparison breaks the things.
> If there's 2+ interface with same address on startup, no error is happen, 
> single TCP and multiple UDP (unlike before) sockets are created, on any of 
> such interface shutdown - thins single TCP socket is closed (unlike before), 
> so there are noting listens on TCP:53 after that.
> If there's only one interface on startup - single TCP sockets are 
> created, on subsequent interface up with the same address - bind error raised 
> and only UDP socket is created additionally (unlike before).
> 
> At the moment, dnsmasq logic expects single TCP/UDP socket per address even 
> for multiple interfaces.
> For example, comment in iface_allowed() states that:
>   /* check whether the interface IP has been added already
>* we call this routine multiple times */
> So, I'm afraid, seems proposed changes does not play well with that.
> How do you think, can it be solved too?
> Reproduction this case is quite easy, just need to create dummy interface 
> with same address (different netmask) and up/down it.
> 
>> Ok, I forgot to follow style on 3rd patch. Attached fixed formatting and 
>> removed debug log on interface removal.
> 
> Thanks,  fyi sed -r 's/[ ]{8}/\t/' is missed too.
> 
>> I think that is better to state explicitly return value is not used.
> 
> I think that would be better to rip it off from functional patch, and let it 
> be as separate full patch for all prettyprint_* instances not just for some 
> selected.
> At the other hand, with no __attribute__((warn_unused_result)) it will not 
> generate warning anyway.
> 
> Best Regards, Vladislav Grishenko
> 
> -Original Message-
> From: Petr Mensik  
> Sent: Wednesday, July 10, 2019 3:01 PM
> To: Vladislav Grishenko ; 
> dnsmasq-discuss@lists.thekelleys.org.uk
> Subject: Re: [Dnsmasq-discuss] [PATCH] Issues with TCP queries on recreated 
> interfaces.
> 
> Hi Vladislav
> 
> On 7/9/19 10:00 PM, Vladislav Grishenko wrote:
>> Hi Petr,
>>
>> Regarding 0002-Compare-address-and-interface-index-for-allowed-inte.patch, 
>> does it support case with different valid interfaces with the same address?
>> For example:
>>  eth0 192.168.1.1/24
>>  tun0 192.168.1.1./16 (created/destroyed dynamically)
> 
> Not tested this specific case, but I think it should be handled correctly, 
> unlike previous code. Because it now compares also interface index, it will 
> mark existing entry as found only if interface index also match. If it does 
> not, new entry is created with correct index instead.
> It should work, unlike previous code, it should keep both interface addresses 
> stored separately.
> 
> If tun0 is often destroyed and recreated, number of interfaces records might 
> grow. That is reason for patch #3, which remove

Re: [Dnsmasq-discuss] [PATCH] Issues with TCP queries on recreated interfaces.

[Petr Mensik]

Hi Vladislav

On 7/9/19 10:00 PM, Vladislav Grishenko wrote:
> Hi Petr,
> 
> Regarding 0002-Compare-address-and-interface-index-for-allowed-inte.patch, 
> does it support case with different valid interfaces with the same address?
> For example:
>   eth0 192.168.1.1/24
>   tun0 192.168.1.1./16 (created/destroyed dynamically)

Not tested this specific case, but I think it should be handled
correctly, unlike previous code. Because it now compares also interface
index, it will mark existing entry as found only if interface index also
match. If it does not, new entry is created with correct index instead.
It should work, unlike previous code, it should keep both interface
addresses stored separately.

If tun0 is often destroyed and recreated, number of interfaces records
might grow. That is reason for patch #3, which removes dropped
interfaces after creating new ones.
> 
> Regarding appearance, seems newly added code doesn’t fully follow dnsmasq 
> code style in several places:
> * indentation (should be ident ==2 spaces, 8 spaces == \t)
> * brackets on the same code lines
Ok, I forgot to follow style on 3rd patch. Attached fixed formatting and
removed debug log on interface removal.
> * function args on the next line are not aligned with the first argument
> * prettyprint_addr() result is forcibly ignored with (void) unlike other 
> places
I think that is better to state explicitly return value is not used.
> 
> Best Regards, Vladislav Grishenko
> 
> -Original Message-
> From: Dnsmasq-discuss  On 
> Behalf Of Petr Mensik
> Sent: Tuesday, July 9, 2019 5:31 PM
> To: dnsmasq-discuss@lists.thekelleys.org.uk
> Subject: [Dnsmasq-discuss] [PATCH] Issues with TCP queries on recreated 
> interfaces.
> 
> Hello Simon and others,
> 
> we have discovered issues with TCP DNS query on dnsmasq, when running in 
> bind-dynamic or bind-interfaces mode. dnsmasq scans automatically new 
> interfaces or do that on new query in second case. However, because used 
> speedup comparing only IP adresses in iface_allowed function, it never gets 
> updated index of an interface.
> 
> In case where named interface is destroyed and created again, that drops TCP 
> queries on that interface. They are checked for incoming interface number. If 
> such number is not found in interfaces list, query is denied.
> 
> Luckily, there was a bug in checking, hiding this problem from usual 
> configuration. If IPv6 address is enabled on the new device, new iface entry 
> would be created, because scope_id of sockaddr_in6 does not match previous. 
> That makes even IPv4 queries succeed.
> 
> Bug on bugzilla [1] is partly private.
> 
> I propose three changes. First is just helper to log what happens with 
> listeners on bind-dynamic configuration.
> 
> Second is the most important. Create new interface every time index changes. 
> Also test address family of incoming TCP query when checking allowed clients.
> 
> Third is cleanup of unused interfaces. On some virtual machines hosts, 
> interfaces may often be created and destroyed. It might have negative effect 
> on walking trough interfaces list. I think listeners should be garbage 
> collected also on bind-interfaces configuration. But for now, release memory 
> for unused interfaces at least for bind-dynamic.
> 
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1721668
> --
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemen...@redhat.com  PGP: 65C6C973
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
From 46a77df93b9e5b04f84a031aede0954c0641fe10 Mon Sep 17 00:00:00 2001
From: Petr Mensik 
Date: Tue, 9 Jul 2019 14:05:59 +0200
Subject: [PATCH 3/3] Cleanup interfaces no longer available

Clean addresses and interfaces not found after enumerate. Free unused
records to speed up checking active interfaces and reduce used memory.
---
 src/network.c | 32 ++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/src/network.c b/src/network.c
index f487617..44bb757 100644
--- a/src/network.c
+++ b/src/network.c
@@ -533,7 +533,30 @@ static int iface_allowed_v4(struct in_addr local, int if_index, char *label,
 
   return iface_allowed((struct iface_param *)vparam, if_index, label, , netmask, prefix, 0);
 }
-   
+
+/*
+ * Clean old interfaces no longer found.
+ */
+static void clean_interfaces()
+{
+  struct irec *iface;
+  struct irec **up = >interfaces;
+
+  for (iface = *up; iface; iface = *up)
+  {
+if (!iface->found && !iface->done)
+  {
+*up = iface->next;
+free(iface->name);
+free(iface);
+  }
+else
+  {
+up = >next;
+  }
+  }
+}
+
 int enumerate_interfaces(int reset)
 {
   static struc

Re: [Dnsmasq-discuss] NXDOMAIN on exisiting A record

[Petr Mensik]

Hello Alex,

I would try removing all-servers and clear-on-reload statements away. I
would use just one server for testing, retesting all of them for the
same behaviour. When you do not know which server is used, it is hard to
debug better.

I think dots in server=/.X/ are not necessary and maybe even misleading.
Try it without them, just server=/X/ip

I think one second timeout is too short. Just use only localhost in
/etc/resolv.conf and debug what happens with dnsmasq. Record what
queries are sent to dnsmasq and what dnsmasq forwards to configured servers.

Note I discovered already requests without recursion desired bit set are
forwarded always, do not serve any local records. But that should not be
the issue. Try dig +rec and dig +norec to rule it out.

Regards,
Petr

On 7/7/19 10:28 PM, Alex Litvak wrote:
> (luck of sleep, fixing some mistakes in text)
> 
> Hello everyone,
> 
> I run consul services on my network where services are registered with
> .service.consul when they start.  All containers and bare metal
> hosts are running dnsmasq 2.80.
> I noticed that if I restart one of the containers, one of the hosts
> continue failing to resolve the service name.  I assume that dnsmasq is
> a culprit because:
> 
> 1. I can resolve service xyz.service.consul against standard dns servers
> with dig.
> 2. Dnsmasq listening on 127.0.0.1 is the first line in the resolve.conf
> and when I run tcpdump against port 53 on interface lo I see it returns
> NXDOMAIN on each A record query for service in question.
> 3. If I restart dnsmasq everything is back to normal again.  Even more
> weird, if I send SIGHUP to dnsmasq, which only causes a reread of
> /etc/hosts file, everything is back to normal as far as service
> resolution goes.
> 
> I have this problem only happening  on some hosts without the pattern I
> can recognize.  For example I have two nodes with the same config, os,
> kernel version, dnsmasq version, etc ... and one of them has the problem
> 100% after service xyz.service.consul restart and the other is not.
> 
> Where do I start troubleshooting? Any ideas are welcome.
> 
> Here is a standard dnsmasq confugration.
> 
> port=53
> domain-needed
> bogus-priv
> interface=lo
> listen-address=127.0.0.1
> no-dhcp-interface=127.0.0.1
> #bind-interfaces
> no-resolv
> all-servers
> dns-forward-max=500
> 
> # If you don't want dnsmasq to read /etc/hosts, uncomment the
> # following line.
> #no-hosts
> # or if you want it to read another file, as well as /etc/hosts, use
> # this.
> #addn-hosts=/etc/banner_add_hosts
> 
> #log-queries=extra
> #log-facility=/var/log/dnsmasq.log
> log-async=25
> 
> # Set the cachesize here.
> cache-size=1
> min-cache-ttl=5
> #neg-ttl=3600
> 
> # If you want to disable negative caching, uncomment this.
> #no-negcache
> 
> # For debugging purposes, log each DNS query as it passes through
> # dnsmasq.
> #log-queries
> clear-on-reload
> 
> server=10.0.48.12
> server=10.0.48.11
> server=10.0.21.63
> server=10.0.21.61
> 
> server=/.la.consul/10.0.73.43
> server=/.la.consul/10.0.73.40
> server=/.la.consul/10.0.73.28
> server=/.chi-pbx.consul/10.1.73.1
> server=/.chi-pbx.consul/10.1.73.2
> server=/.chi-pbx.consul/10.1.73.3
> server=/.consul/10.0.73.43
> server=/.consul/10.0.73.40
> server=/.consul/10.0.73.28
> 
> Resolver config
> 
> search ''
> options  timeout:1 attempts:1
> nameserver 127.0.0.1
> nameserver 10.0.48.11
> nameserver 10.0.48.12
> nameserver 10.0.21.63
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

Re: [Dnsmasq-discuss] REFUSED PTR queries without recursion desired

[Petr Mensik]

Hi Chiang,

I discovered the same issue and even posted patch on 2019-04-12 [1].
Queries without RD flag are always forwarded to "upstream" server, not
answered locally. REFUSED is usually given by server dnsmasq points to,
dnsmasq is just passing it to you. It should be fixed, but no reply for
it yet.

But I think it should work on authoritative interface, but it has to be
different interface used for normal dns cache.

1.
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q2/013013.html

On 7/9/19 12:24 PM, Chiang Fong Lee wrote:
> Hello,
> 
> I’m having some trouble getting dnsmasq to respond to PTR queries without 
> recursion desired, even when authoritative mode is enabled.
> 
> Given the following config:
> domain-needed
> bogus-priv
> no-resolv
> no-hosts
> port=10053
> server=/example.com/
> log-queries
> host-record=host1.example.com,10.2.3.4
> 
> Observed results:
> Query host1.example.com A (with recursion) - NOERROR, returns answer
> Query host1.example.com A (without recursion) - REFUSED
> Query 4.3.2.10.in-addr.arpa PTR (with recursion) - NOERROR, returns answer
> Query 4.3.2.10.in-addr.arpa PTR (without recursion) - REFUSED
> 
> Given the above config, plus the following two lines to enable authoritative 
> mode:
> auth-server=ns1.example.com
> auth-zone=example.com,10.0.0.0/8
> 
> Observed results:
> Query host1.example.com A (with recursion) - NOERROR, returns answer
> Query host1.example.com A (without recursion) - NOERROR, returns answer
> Query 4.3.2.10.in-addr.arpa PTR (with recursion) - NOERROR, returns answer
> Query 4.3.2.10.in-addr.arpa PTR (without recursion) - REFUSED
> 
> Expected results:
> Enabling auth mode for the zone, and specifying the subnet, would result in 
> the last PTR query being accepted instead of refused.
> 
> The log lines seen when the REFUSED occurs are:
> dnsmasq_1  | Jul  9 09:42:06 dnsmasq[1]: query[PTR] 4.3.2.10.in-addr.arpa 
> from 172.19.0.1
> dnsmasq_1  | Jul  9 09:42:06 dnsmasq[1]: config error is REFUSED
> 
> Version info:
> Dnsmasq version 2.80  Copyright (c) 2000-2018 Simon Kelley
> Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 
> no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify dumpfile
> 
> I was looking through the source and I’m guessing that PTR queries don’t ever 
> trigger the auth zone path, since the query ends in “in-addr.arpa” instead of 
> the auth-zone domain like “example.com”. Once it reaches the regular 
> answer_request path, it immediately returns since the RD flag is not set, 
> without checking host-records, and proceeds to forward the query instead.
> 
> Is this intended behaviour? The 2.79 CHANGELOG states that this 
> always-SERVFAIL (or forward, in 2.80) behaviour for queries without recursion 
> desired should always happen “UNLESS acting as an authoritative DNS server”, 
> without a caveat that it only works for non-reverse DNS queries.
> 
> Thanks,
> Chiang Fong
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

[Dnsmasq-discuss] [PATCH] Issues with TCP queries on recreated interfaces.

[Petr Mensik]

Hello Simon and others,

we have discovered issues with TCP DNS query on dnsmasq, when running in
bind-dynamic or bind-interfaces mode. dnsmasq scans automatically new
interfaces or do that on new query in second case. However, because used
speedup comparing only IP adresses in iface_allowed function, it never
gets updated index of an interface.

In case where named interface is destroyed and created again, that drops
TCP queries on that interface. They are checked for incoming interface
number. If such number is not found in interfaces list, query is denied.

Luckily, there was a bug in checking, hiding this problem from usual
configuration. If IPv6 address is enabled on the new device, new iface
entry would be created, because scope_id of sockaddr_in6 does not match
previous. That makes even IPv4 queries succeed.

Bug on bugzilla [1] is partly private.

I propose three changes. First is just helper to log what happens with
listeners on bind-dynamic configuration.

Second is the most important. Create new interface every time index
changes. Also test address family of incoming TCP query when checking
allowed clients.

Third is cleanup of unused interfaces. On some virtual machines hosts,
interfaces may often be created and destroyed. It might have negative
effect on walking trough interfaces list. I think listeners should be
garbage collected also on bind-interfaces configuration. But for now,
release memory for unused interfaces at least for bind-dynamic.

1. https://bugzilla.redhat.com/show_bug.cgi?id=1721668
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
From c9cc7aa2fb5463626bf6795531390ca3f2d2752b Mon Sep 17 00:00:00 2001
From: Petr Mensik 
Date: Tue, 9 Jul 2019 14:05:59 +0200
Subject: [PATCH 3/3] Cleanup interfaces no longer available

Clean addresses and interfaces not found after enumerate. Free unused
records to speed up checking active interfaces and reduce used memory.
---
 src/network.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/src/network.c b/src/network.c
index f487617..5a37f61 100644
--- a/src/network.c
+++ b/src/network.c
@@ -533,7 +533,29 @@ static int iface_allowed_v4(struct in_addr local, int if_index, char *label,
 
   return iface_allowed((struct iface_param *)vparam, if_index, label, , netmask, prefix, 0);
 }
-   
+
+/*
+ * Clean old interfaces no longer found.
+ */
+static void clean_interfaces()
+{
+  struct irec *iface;
+  struct irec **up = >interfaces;
+
+  for (iface = *up; iface; iface = *up)
+{
+  if (!iface->found && !iface->done) {
+*up = iface->next;
+	my_syslog(LOG_DEBUG, _("dropping interface %s(#%d) family %d"),
+	 iface->name, iface->index, iface->addr.sa.sa_family);
+	free(iface->name);
+	free(iface);
+  } else {
+	up = >next;
+	  }
+}
+}
+
 int enumerate_interfaces(int reset)
 {
   static struct addrlist *spare = NULL;
@@ -631,6 +653,7 @@ int enumerate_interfaces(int reset)
 	 in OPT_CLEVERBIND mode, that at listener will just disappear after
 	 a call to enumerate_interfaces, this is checked OK on all calls. */
   struct listener *l, *tmp, **up;
+  int freed = 0;
   
   for (up = >listeners, l = daemon->listeners; l; l = tmp)
 	{
@@ -660,10 +683,14 @@ int enumerate_interfaces(int reset)
 		close(l->tftpfd);
 	  
 	  free(l);
+	  freed = 1;
 	}
 	}
+
+  if (freed)
+	clean_interfaces();
 }
-  
+
   errno = errsave;
   spare = param.spare;
 
-- 
2.20.1

From e3a22a2ad93c518507cd1b41fabbf0c1160daef1 Mon Sep 17 00:00:00 2001
From: Petr Mensik 
Date: Wed, 3 Jul 2019 17:02:16 +0200
Subject: [PATCH 2/3] Compare address and interface index for allowed interface

If interface is recreated with the same address but different index, it
would not change any other parameter.

Test also address family on incoming TCP queries.
---
 src/dnsmasq.c | 3 ++-
 src/network.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index 704475f..939e69e 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -1792,7 +1792,8 @@ static void check_dns_listeners(time_t now)
 		addr.addr4 = tcp_addr.in.sin_addr;
 		  
 		  for (iface = daemon->interfaces; iface; iface = iface->next)
-		if (iface->index == if_index)
+		if (iface->index == if_index &&
+		iface->addr.sa.sa_family == tcp_addr.sa.sa_family)
 		  break;
 		  
 		  if (!iface && !loopback_exception(listener->tcpfd, tcp_addr.sa.sa_family, , intr_name))
diff --git a/src/network.c b/src/network.c
index 1fe25f7..f487617 100644
--- a/src/network.c
+++ b/src/network.c
@@ -388,10 +388,11 @@ static int iface_allowed(struct iface_param *param, int if_index, char *label,
   /* check whether the interface IP has been added already 
  

Re: [Dnsmasq-discuss] Authoritative zone and no recursion replies

[Petr Mensik]

Notes below

On 3/7/19 6:09 PM, Simon Kelley wrote:
> On 15/02/2019 12:54, Petr Mensik wrote:
>> Hi everyone.
>>
>> I think it is handy to be able to delegate some suffix from internal
>> domain, lets say example.com provided by BIND or any bigger server. But
>> recursive servers do not set recursive queries on normal delegation.
>> Delegation is when I just add line into zone file:
>>
>> $ORIGIN example.com.
>> dnsmasq-private IN A 10.0.0.53
>> private IN NS dnsmasq-private
>>
>> Then query to xy.private.example.com would be forwarded to dnsmasq. It
>> is great this can be configured by dynamic update of a zone. No change
>> of configuration is necessary. It requires dnsmasq to be accessible by
>> recursive resolvers. Great for trusted network configuration.
>>
>> Unfortunately, dnsmasq does not cooperate very well with them. Recursive
>> servers use queries without recursion desired flag set. Dnsmasq tends to
>> refuse it or servfail if any forwarder is configured. For each host it
>> reads from /etc/hosts or configured from DHCP, I think it would be nice
>> to respond also without recursion to every host from hosts. The same way
>> for DHCP assigned names. AFAIK it is denied to disallow cache probing.
>> What is point to deny provided names without recursion set, when it
>> gracefully offers it when recursion is desired?
>>
>> compare when at least one server is set:
>> dig +rec mydnsmasqhost
>> dig +norec mydnsmasqhost
>>
>> where mydnsmasqhost is hostname which obtained address from dnsmasq.
>>
>> It just makes delegation from big resolvers difficult. Without auth-zone
>> with common prefix, it would not work. Is there a good reason for it? If
>> domain is set, it would be easy to create delegation without need to
>> auth-zone set.
>>
>> My example would work if --auth-zone=private.example.com would be used.
>> While it is better, why should not --domain private.example.com be
>> sufficient? It would be quite useful for VM configuration, because
>> current libvirt does not support adding auth-zone to dnsmasq
>> configuration file.
>>
>> Any comments welcome.
>>
>> Have a nice day,
>> Petr
>>
> 
> The behaviour in receiving a query without RD set changed in
> 
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=4139298d287eb5c57f4aa53c459cb02fc5be2495
> 
> which doesn't directly help you, but does need to be taken into account.
> 
> If I understand you correctly, you want the behaviour to change if the
> query can be answered from configured (/etc/hosts and so on) data,
> whilst keeping the same behaviour for answers which came from upstream,
> but are merely cached.
> 
> To answer the question "What is point to deny provided names without
> recursion set, when it gracefully offers it when recursion is desired?"
> The aim is to avoid a client being able to tell the difference between
> an answer coming from the dnsmasq cache, and one coming from upstream.
> If RD is set, it will get an answer, either from upstream, or from the
> cache. It can't tell the difference. The original behaviour with RD
> _unset_ was to either answer from the cache, or fail (not sending
> upstream), allowing the client to deduce the contents of the cache. That
> was changed to always SERVFAIL, and then the latest change is to always
> forward upstream. The reason given for this is to allow dig +trace to
> operate through dnsmasq.
Always forwarding upstream seems very wrong to me. If I receive query
without rd bit set, it is asking me for authoritative contents OR
direction where should I ask.

I understand dnsmasq does not really undestands zones, it cannot direct
me to NS of authoritative server. But IF queried bit IS provided by
dnsmasq, then it MUST respond with data. That is purpose of that bit,
that is reason it is in queries. I admit cache snooping could be bad,
but I am not confident it such behaviour should not be configurable. In
the first place, queries from untrusted networks should be blocked at all.

I think it is useful for admin to be able look inside cache for
remaining timeouts. I think it would be nice, if localhost queries
without rd were accepted by default and it was possible specify somehow,
who should be able to do that.
> 
> It seems that actually just ignoring the RD bit i) disallows cache
> snooping, ii) allows dig +trace to operate. Maybe that should be the
> behaviour?
No, I do not think so. I think proper delegation reply should be
generated instead. In this case, it might help, if all names NOT
provided by dnsmasq were forwarded upstream for proper delegation, but
dnsmasq served data should be answered by dnsmasq without delegation.

Cheers,
Petr

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

Re: [Dnsmasq-discuss] Strategies for DNS and DHCP backup

[Petr Mensik]

Never tried it myself, but if you synchronize configuration from primary
to secondary server, it might work somehow together.

Consider setting dhcp-authoritative on primary instance, but make sure
it is not there on secondary. You may want to use different dhcp-range,
so dynamically allocated hosts do not overlap.

Dns on secondary should use server=primary-ip as first server, other
servers configured after that. Use strict-order to be sure. dnsmasq
should be able to notice that server is down and use another address, so
hostnames should stay more or less synchronized.

I think proper configuration would require dhcpd from ISC, which has
some support for failover.

On 4/6/19 1:10 PM, john doe wrote:
> On 4/5/2019 10:54 PM, Chris Green wrote:
>> I run dnsmasq on a Raspberry Pi to provide DHCP and DNS services on my
>> home network.  I often spend quite long periods away from home and I'd
>> like to have a way of providing some sort of backup if the Raspberry
>> Pi dies for any reason.
>>
>> Recently the Pi has died a couple of times so I set up a second Pi
>> with the same dnsmasq configuration file but without it set to run
>> from /etc/init.d so that I could ssh into my network and start it
>> manually.  This worked OK when I had to use it recently but it does
>> require that I notice something is wrong which I may not do when I'm
>> away.
>>
>> Is there a straightforward way of having a secondary DHCP and DNS
>> server on a LAN?
>>
> 
> Thanks to Google:
> 
> https://www.reddit.com/r/pihole/comments/99xmei/two_piholes_with_dhcp_enabled_on_1_network_as/
> 
> https://github.com/jiasir/dnsmasq-ha
> 
> The above could help you getting up 'dhcp failover'.
> For DNS you would need to use zone transfer.
> 
> --
> John Doe
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

Re: [Dnsmasq-discuss] [PATCH] auth-server without interface

[Petr Mensik]

Hi Simon,

thanks, but actually, not that much. Sorry I was busy in different projects.

This change now broken my configuration, because this no longer accepts
the same combination of parameters without fatal error. Could it be made
as warning instead? It do not think it should be fatal, soa is
initialized to good enough value, contact and primary server are not
mandatory for normal operation.

Patch changing it to warning included.

On 3/7/19 6:12 PM, Simon Kelley wrote:
> On 15/02/2019 12:09, Petr Mensik wrote:
>> Hi!
>>
>> I was playing a bit with auth-vm and auth-server together with virtual
>> machine manager. I think it might be useful to omit interface in
>> auth-server at all, just change name reported by auth-vm zones on normal
>> dns port.
>>
>> Libvirt uses dnsmasq as DHCP and DNS server on each virtual network
>> configured. It listens just on one interface excluding loopback (virbr0
>> for example). If I specify its interface, it stops responding normal
>> recursive queries on it. I think there is no good reason to demand it.
>> Anyway, current manual page indicates it is optional...
>>
>> Regards,
>> Petr
>>
> 
> It was made optional in this commit.
> 
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=08933475abd0580cff747e3d1e0db3865207a200
> 
> 
> Does that adddress the use-case you describe?
> 
> 
> Cheers,
> 
> Simon.
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
From 24ff470a21741ccea8dc5747f7d11454fb9f4851 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Fri, 12 Apr 2019 16:14:15 +0200
Subject: [PATCH] Accept auth-zone without auth-server

Do not fail hard if auth-zone is provided but auth-zone is not.
It is recommended and prints just warning now, but can still work
without it.
---
 src/dnsmasq.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index e6140b7..704475f 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -218,11 +218,6 @@ int main (int argc, char **argv)
 die(_("asynchronous logging is not available under Android"), NULL, EC_BADCONF);
 #endif
 
-#ifndef HAVE_AUTH
-  if (daemon->auth_zones)
-die(_("authoritative DNS not available: set HAVE_AUTH in src/config.h"), NULL, EC_BADCONF);
-#endif
-
 #ifndef HAVE_LOOP
   if (option_bool(OPT_LOOP_DETECT))
 die(_("loop detection not available: set HAVE_LOOP in src/config.h"), NULL, EC_BADCONF);
@@ -233,16 +228,13 @@ int main (int argc, char **argv)
 die(_("Ubus not available: set HAVE_UBUS in src/config.h"), NULL, EC_BADCONF);
 #endif
   
-  if (daemon->max_port < daemon->min_port)
-die(_("max_port cannot be smaller than min_port"), NULL, EC_BADCONF);
-
   now = dnsmasq_time();
 
   if (daemon->auth_zones)
 {
-  if (!daemon->authserver)
-	die(_("--auth-server required when an auth zone is defined."), NULL, EC_BADCONF);
-
+#ifndef HAVE_AUTH
+  die(_("authoritative DNS not available: set HAVE_AUTH in src/config.h"), NULL, EC_BADCONF);
+#else
   /* Create a serial at startup if not configured. */
 #ifdef HAVE_BROKEN_RTC
   if (daemon->soa_sn == 0)
@@ -250,9 +242,13 @@ int main (int argc, char **argv)
 #else
   if (daemon->soa_sn == 0)
 	daemon->soa_sn = now;
+#endif
 #endif
 }
-  
+
+  if (daemon->max_port < daemon->min_port)
+die(_("max_port cannot be smaller than min_port"), NULL, EC_BADCONF);
+
 #ifdef HAVE_DHCP6
   if (daemon->dhcp6)
 {
@@ -864,6 +860,11 @@ int main (int argc, char **argv)
 }
 #endif
 
+#ifdef HAVE_AUTH
+  if (daemon->auth_zones &&!daemon->authserver)
+my_syslog(LOG_WARNING, _("--auth-server recommended when an auth zone is defined."));
+#endif
+
   if (log_err != 0)
 my_syslog(LOG_WARNING, _("warning: failed to change owner of %s: %s"), 
 	  daemon->log_file, strerror(log_err));
-- 
2.20.1

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

Re: [Dnsmasq-discuss] [PATCH] dnsmasq interaction with nonrecursive requests

[Petr Mensik]

I have prepared patch that allows again queries to dnsmasq without rd
bit set. It allows queries to locally defined names even without rd bit,
but stil refuses queries to cached remote records.

I think this is important issue, could it be reviewed?

On 4/12/19 11:29 AM, Petr Mensik wrote:
> Hi,
> 
> I was checking latest dnsmasq reponses to non-recursive queries. It
> seems strange, it does not work as it should. Originally, I was checking
> NXDOMAIN issue, reported on Fedora bug #1647464.
> 
> But this issue seems important, it makes difficult to use dnsmasq with
> bigger resolvers like bind or unbound. It does skip even local defined
> hosts, which I think should be responded always even without recursion
> bit set.
> 
> This was tested first on released dnsmasq 2.80 in Fedora rawhide, then
> on git compilation with version v2.80-53-g343b7b4. Both seems to be
> incorrect.
> 
> # grep -w qeos-1 /etc/hosts
> 172.16.36.1qeos-1
> 
> # dig @127.0.0.1 +norec qeos-1
> 
> ; <<>> DiG 9.11.5-P4-RedHat-9.11.5-13.P4.fc31 <<>> @127.0.0.1 +norec qeos-1
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50085
> ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;qeos-1.  IN  A
> 
> ;; AUTHORITY SECTION:
> . 498600  IN  NS  b.root-servers.net.
> . 498600  IN  NS  m.root-servers.net.
> . 498600  IN  NS  e.root-servers.net.
> . 498600  IN  NS  f.root-servers.net.
> . 498600  IN  NS  k.root-servers.net.
> . 498600  IN  NS  l.root-servers.net.
> . 498600  IN  NS  c.root-servers.net.
> . 498600  IN  NS  d.root-servers.net.
> . 498600  IN  NS  i.root-servers.net.
> . 498600  IN  NS  g.root-servers.net.
> . 498600  IN  NS  a.root-servers.net.
> . 498600  IN  NS  h.root-servers.net.
> . 498600  IN  NS  j.root-servers.net.
> 
> ;; ADDITIONAL SECTION:
> e.root-servers.net.   153695  IN  A   192.203.230.10
> e.root-servers.net.   153695  IN  2001:500:a8::e
> h.root-servers.net.   153695  IN  A   198.97.190.53
> h.root-servers.net.   153695  IN  2001:500:1::53
> l.root-servers.net.   585734  IN  A   199.7.83.42
> l.root-servers.net.   153695  IN  2001:500:9f::42
> i.root-servers.net.   585699  IN  A   192.36.148.17
> i.root-servers.net.   153695  IN  2001:7fe::53
> a.root-servers.net.   597264  IN  A   198.41.0.4
> a.root-servers.net.   597264  IN  2001:503:ba3e::2:30
> d.root-servers.net.   153695  IN  A   199.7.91.13
> d.root-servers.net.   153695  IN  2001:500:2d::d
> c.root-servers.net.   153695  IN  A   192.33.4.12
> c.root-servers.net.   153695  IN  2001:500:2::c
> b.root-servers.net.   585695  IN  A   199.9.14.201
> b.root-servers.net.   153695  IN  2001:500:200::b
> j.root-servers.net.   153695  IN  A   192.58.128.30
> j.root-servers.net.   153695  IN  2001:503:c27::2:30
> k.root-servers.net.   586670  IN  A   193.0.14.129
> k.root-servers.net.   153695  IN  2001:7fd::1
> g.root-servers.net.   153695  IN  A   192.112.36.4
> g.root-servers.net.   153695  IN  2001:500:12::d0d
> m.root-servers.net.   153695  IN  A   202.12.27.33
> m.root-servers.net.   153695  IN  2001:dc3::35
> f.root-servers.net.   153695  IN  A   192.5.5.241
> f.root-servers.net.   153695  IN  2001:500:2f::f
> 
> # dig @127.0.0.1 +rec qeos-1
> ; <<>> DiG 9.11.5-P4-RedHat-9.11.5-13.P4.fc31 <<>> @127.0.0.1 +rec qeos-1
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50355
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;qeos-1.  IN  A
> 
> ;; ANSWER SECTION:
> qeos-1.   0   IN  A   172.16.36.1
> 
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Pá dub 12 05:23:57 EDT 2019
> ;; MSG SIZE  rcvd: 51
> 
> 1. https://b

[Dnsmasq-discuss] dnsmasq interaction with nonrecursive requests

[Petr Mensik]

Hi,

I was checking latest dnsmasq reponses to non-recursive queries. It
seems strange, it does not work as it should. Originally, I was checking
NXDOMAIN issue, reported on Fedora bug #1647464.

But this issue seems important, it makes difficult to use dnsmasq with
bigger resolvers like bind or unbound. It does skip even local defined
hosts, which I think should be responded always even without recursion
bit set.

This was tested first on released dnsmasq 2.80 in Fedora rawhide, then
on git compilation with version v2.80-53-g343b7b4. Both seems to be
incorrect.

# grep -w qeos-1 /etc/hosts
172.16.36.1qeos-1

# dig @127.0.0.1 +norec qeos-1

; <<>> DiG 9.11.5-P4-RedHat-9.11.5-13.P4.fc31 <<>> @127.0.0.1 +norec qeos-1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50085
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;qeos-1.IN  A

;; AUTHORITY SECTION:
.   498600  IN  NS  b.root-servers.net.
.   498600  IN  NS  m.root-servers.net.
.   498600  IN  NS  e.root-servers.net.
.   498600  IN  NS  f.root-servers.net.
.   498600  IN  NS  k.root-servers.net.
.   498600  IN  NS  l.root-servers.net.
.   498600  IN  NS  c.root-servers.net.
.   498600  IN  NS  d.root-servers.net.
.   498600  IN  NS  i.root-servers.net.
.   498600  IN  NS  g.root-servers.net.
.   498600  IN  NS  a.root-servers.net.
.   498600  IN  NS  h.root-servers.net.
.   498600  IN  NS  j.root-servers.net.

;; ADDITIONAL SECTION:
e.root-servers.net. 153695  IN  A   192.203.230.10
e.root-servers.net. 153695  IN  2001:500:a8::e
h.root-servers.net. 153695  IN  A   198.97.190.53
h.root-servers.net. 153695  IN  2001:500:1::53
l.root-servers.net. 585734  IN  A   199.7.83.42
l.root-servers.net. 153695  IN  2001:500:9f::42
i.root-servers.net. 585699  IN  A   192.36.148.17
i.root-servers.net. 153695  IN  2001:7fe::53
a.root-servers.net. 597264  IN  A   198.41.0.4
a.root-servers.net. 597264  IN  2001:503:ba3e::2:30
d.root-servers.net. 153695  IN  A   199.7.91.13
d.root-servers.net. 153695  IN  2001:500:2d::d
c.root-servers.net. 153695  IN  A   192.33.4.12
c.root-servers.net. 153695  IN  2001:500:2::c
b.root-servers.net. 585695  IN  A   199.9.14.201
b.root-servers.net. 153695  IN  2001:500:200::b
j.root-servers.net. 153695  IN  A   192.58.128.30
j.root-servers.net. 153695  IN  2001:503:c27::2:30
k.root-servers.net. 586670  IN  A   193.0.14.129
k.root-servers.net. 153695  IN  2001:7fd::1
g.root-servers.net. 153695  IN  A   192.112.36.4
g.root-servers.net. 153695  IN  2001:500:12::d0d
m.root-servers.net. 153695  IN  A   202.12.27.33
m.root-servers.net. 153695  IN  2001:dc3::35
f.root-servers.net. 153695  IN  A   192.5.5.241
f.root-servers.net. 153695  IN  2001:500:2f::f

# dig @127.0.0.1 +rec qeos-1
; <<>> DiG 9.11.5-P4-RedHat-9.11.5-13.P4.fc31 <<>> @127.0.0.1 +rec qeos-1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50355
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;qeos-1.IN  A

;; ANSWER SECTION:
qeos-1. 0   IN  A   172.16.36.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Pá dub 12 05:23:57 EDT 2019
;; MSG SIZE  rcvd: 51

1. https://bugzilla.redhat.com/show_bug.cgi?id=1647464

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

[Dnsmasq-discuss] Authoritative zone and no recursion replies

[Petr Mensik]

Hi everyone.

I think it is handy to be able to delegate some suffix from internal
domain, lets say example.com provided by BIND or any bigger server. But
recursive servers do not set recursive queries on normal delegation.
Delegation is when I just add line into zone file:

$ORIGIN example.com.
dnsmasq-private IN A 10.0.0.53
private IN NS dnsmasq-private

Then query to xy.private.example.com would be forwarded to dnsmasq. It
is great this can be configured by dynamic update of a zone. No change
of configuration is necessary. It requires dnsmasq to be accessible by
recursive resolvers. Great for trusted network configuration.

Unfortunately, dnsmasq does not cooperate very well with them. Recursive
servers use queries without recursion desired flag set. Dnsmasq tends to
refuse it or servfail if any forwarder is configured. For each host it
reads from /etc/hosts or configured from DHCP, I think it would be nice
to respond also without recursion to every host from hosts. The same way
for DHCP assigned names. AFAIK it is denied to disallow cache probing.
What is point to deny provided names without recursion set, when it
gracefully offers it when recursion is desired?

compare when at least one server is set:
dig +rec mydnsmasqhost
dig +norec mydnsmasqhost

where mydnsmasqhost is hostname which obtained address from dnsmasq.

It just makes delegation from big resolvers difficult. Without auth-zone
with common prefix, it would not work. Is there a good reason for it? If
domain is set, it would be easy to create delegation without need to
auth-zone set.

My example would work if --auth-zone=private.example.com would be used.
While it is better, why should not --domain private.example.com be
sufficient? It would be quite useful for VM configuration, because
current libvirt does not support adding auth-zone to dnsmasq
configuration file.

Any comments welcome.

Have a nice day,
Petr

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

Re: [Dnsmasq-discuss] dry run mode

[Petr Mensik]

I think tools from contrib/lease-tools might help you with that. It
makes dnsmasq to release some lease on demand. If you shut down VM, it
can be used to free its former lease.

I think also d-bus API can be used for the same thing, it might be more
reliable.

On 2/11/19 9:43 PM, Graeme Peterson wrote:
> Hi all. Happy 2019!
> 
> A bit of an odd question: Is there any way to run dnsmasq in some kind
> of standalone test or dry-run mode without being connected to
> actual/virtual networks, where I could define subnets and IP ranges,
> somehow issue requests for IPs on subnets, and then use those IPs in my
> VM deployment tests that require static IPs, releasing them when done or
> when their lease expires?
> 
> EXPLANATION
> ===
> 
> I work in a test team on a product that does a lot of virtual network
> configuration for various deployed VMs. Some of the testing uses dhcp
> for the VMs' interfaces, so far so good. Some tests need to exercise
> static IP configuration. I need a way to manage the allocation of static
> IPs on all the test VMs in our automation. Hard coding the values is
> cumbersome, error prone, and we run out of IPs in most /24 subnets
> pretty quickly if we make sure every test deployment has a unique static
> IP.
> 
> So I got to thinking. I could write some kind of static IP allocator
> that would respond to requests on a per-subnet basis, release the IPs
> back into a pool of some kind when the test is done with them, maybe
> have a timeout to auto-release the IPs in case the release is missed,...
> 
> 
> Hang on. Sounds like dhcp. Which brings me to my above question, and
> this email.
> 
> Thank you,
> Graeme
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

[Dnsmasq-discuss] [PATCH] auth-server without interface

[Petr Mensik]

Hi!

I was playing a bit with auth-vm and auth-server together with virtual
machine manager. I think it might be useful to omit interface in
auth-server at all, just change name reported by auth-vm zones on normal
dns port.

Libvirt uses dnsmasq as DHCP and DNS server on each virtual network
configured. It listens just on one interface excluding loopback (virbr0
for example). If I specify its interface, it stops responding normal
recursive queries on it. I think there is no good reason to demand it.
Anyway, current manual page indicates it is optional...

Regards,
Petr

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

Re: [Dnsmasq-discuss] Determine wireless SSID

[Petr Mensik]

Hi Donald,

it is kind of possible. But usually there is another way to solve your
situation.

First of all, you want to assign guests different addresses. Why would
you want that? I think you want to separate them from internal network.
Good design. However, that means they should be coming from different
network device. Just need to map device request is coming from to
different range and tag.

Or maybe better, have separate instances listening just on given
interface. For example have guest network have VLAN 1, internal VLAN 2.
Run dnsmasq with bind-interfaces, interface=eth0.1 and so on.
Another instance with interface=eth0.2, etc. It would separate
physically guests from home users, would allow firewall separation as
well. Possibly just one direction.

It would not be simple setup I am afraid. Requires a lot of
configuration outside dnsmasq. I guess you are looking for some simple
configuration. I am afraid I do not know simpler setup.

Is this somehow simplified in OpenWRT for example?

Cheers,
Petr

On 1/11/19 10:58 PM, Donald Muller wrote:
> This is probably not possible but I thought I would ask.
> 
> Is it possible for DNSMASQ to determine the SSID for a DHCP request? I would 
> like to be able to assign different values for devices using the guest 
> network. DNSMASQ is running on my QNAP NAS while I have a Netgear wireless 
> router providing the wireless connectivity.
> 
> Thanks
> 
> -
> "Everyone is entitled to his own opinion, but not to his own facts." - Daniel 
> Patrick Moynihan
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

[Dnsmasq-discuss] [PATCH] Re: dhcp-boot & dhcp-reply-delay optional tag fixes

[Petr Mensik]

Hi Kevin et al,

sure, your fix is correct one. I just found one more place where tags
were required. Your pointer handling is not as hopeless as you are
saying. :)

Sorry for inconvenience caused by my change. I miss some tests that
would discover it, have to write them someday soon.

Petr
On 12/14/18 3:17 PM, Kevin Darbyshire-Bryant wrote:
> Hi Simon et al,
> 
> It looks like Petr’s "Free config file values on parsing errors” commit 
> turned the optional tags on dhcp-boot & dhcp-reply-delay to non-optional.
> 
> Attached is a patch that fixes it according to my testing but my ‘c’ and 
> pointer handling is somewhat hopeless so could do with a proper sanity check, 
> i.e. I don’t trust myself :-)
> 
> Cheers,
> 
> Kevin D-B
> 
> 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
>From 668b45c29c38d440c8fce4bc994c56910adc3919 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Fri, 14 Dec 2018 17:03:08 +0100
Subject: [PATCH] Fix required tags in few places

Some locations were incorrectly changed to require always tags, else
dnsmasq will not start. Fix dhcp-boot, dhcp-reply-delay and pxe-prompt.
---
 src/option.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/option.c b/src/option.c
index 4627969..e32a8e8 100644
--- a/src/option.c
+++ b/src/option.c
@@ -3432,7 +3432,7 @@ static int one_opt(int option, char *arg, char *errstr, char *gen_err, int comma
   {
 	struct dhcp_netid *id = dhcp_tags();
 	
-	if (!id)
+	if (!arg)
 	  {
 	ret_err(gen_err);
 	  }
@@ -3483,7 +3483,7 @@ static int one_opt(int option, char *arg, char *errstr, char *gen_err, int comma
   {
 	struct dhcp_netid *id = dhcp_tags();
 	
-	if (!id)
+	if (!arg)
 	  {
 	ret_err(gen_err);
 	  }
@@ -3513,7 +3513,7 @@ static int one_opt(int option, char *arg, char *errstr, char *gen_err, int comma
 	 new->opt = 10; /* PXE_MENU_PROMPT */
 	 new->netid = dhcp_tags();
 	 
-	 if (!new->netid)
+	 if (!arg)
 	   {
 	 dhcp_opt_free(new);
 	 ret_err(gen_err);
-- 
2.14.5

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

Re: [Dnsmasq-discuss] DNS query random ports [PATCH]

[Petr Mensik]

Hi Simon,

I am sure this is already an old issue. I forgot to mark patch presence
in subject. I proposed a way to fallback to kernel assigned outgoing
ports. Is it unacceptable? Have you even noticed the patches? Could you
check if they could be used?

I think any new deployments of dnsmasq would have working random ports
generation built into kernel. Disadvantage of current code is it does
not follow sysctl net.ipv4.ip_local_port_range configured in kernel.

Cheers,
Petr

On 8/21/18 11:24 PM, Simon Kelley wrote:
> On 10/08/18 13:37, Petr Menšík wrote:
>> Hello,
>>
>> we discovered our dnsmasq  were using also privileged source ports when
>> sending queries. Interesting enough, it has right to do it, because it
>> has to listen also on privileged port. It never drops such privilege.
>>
>> It was fixed in commit [1]. But my question is, why is there even custom
>> generator or random ports, when OS can do it itself? And usually far
>> better? So I dug a bit into it and came with patch, that would use
>> random ports from OS by default.
>>
>> When I tested it, I got the same results when skipping bind() call on
>> random ports at all. Is there some reason, why dnsmasq does not follow
>> OS policy for source outgoing port and choses its own range by itself?
>>
>> 1.
>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=baf553db0cdb50707ddab464fb3eff7786ea576c
>>
> 
> The random port code was added to dnsmasq in response to the Kaminsky
> Birthday attack paper, which was in 2009. At that point, there were
> still people seriously running routers (and therefore dnsmasq) on Linux
> 2.0 kernels. As best I remember, I did it the way I did because I
> couldn't be sure that all the platforms dnsmasq would run on would
> allocate sufficiently random ports: RFC6056 was still more than a year
> in the future.
> 
> 
> I'm sure that code could be simplified now.
> 
> Simon.
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

[Dnsmasq-discuss] Stumped

[Petr Mensik]

Hi Peter,

did you check what "pkg-config --libs nettle hogweed" returns in your
environment? If you want to prefer your own libraries, I think the
simplest way is to remove nettle-devel package, unless you want to build
your own package. Environment variables PKG_CONFIG_LIBDIR and
PKG_CONFIG_PATH may help you. Visit man pkg-config. It should include -L
flag with path in --libs, if installed to non-standard path.

Cheers,
Petr

On 10/31/2018 04:21 AM, Peter Nehem wrote:
> Hello All,
>  I'm stumped I've been trying to compile dnsmasq for Centos 7.5 because
> the version for Centos 7.5 doesn't have any of the extra features turned
> on, namely dnssec and several others. But I keep getting this error
> message no matter what I do:
> 
> ccache gcc -Wall -W -O2   -DVERSION='"2.76"' -I/usr/include/dbus-1.0
> -I/usr/lib64/dbus-1.0/include   -I/usr/local/include    -c
> dnssec.c   
> dnssec.c: In function ‘dnsmasq_ecdsa_verify’:
> dnssec.c:266:36: error: ‘nettle_secp_256r1’ undeclared (first use in
> this function)
>     nettle_ecc_point_init(key_256, _secp_256r1);
>     ^
> dnssec.c:266:36: note: each undeclared identifier is reported only once
> for each function it appears in
> dnssec.c:279:36: error: ‘nettle_secp_384r1’ undeclared (first use in
> this function)
>     nettle_ecc_point_init(key_384, _secp_384r1);
>     ^
> make[1]: *** [/mnt/sdb1/dnsmasq-2.76/Makefile:157: dnssec.o] Error 1
> make[1]: Leaving directory '/mnt/sdb1/dnsmasq-2.76/src'
> make: *** [Makefile:83: all] Error 2
> 
> I have gotten it in every version I've tried to compile. I've tried
> dnsmasq-master, dnsmasq-2.80, most recent snapshot, dnsmasq-2.76. I
> tried having it read from openssl-1.1.1 that I have complied for nginx,
> but that didn't work, so I recompiled Nettle-3.4 ( I used this for the
> configure line: ./configure --enable-fat --enable-gcov
> --disable-documentation --disable-arm-neon
> --with-include-path=/opt/openssl/include/openssl ) Took a few tried to
> finally get it to compile but I got it to use the files from
> openssl-1.1.1 so that Nettle would be up to the task.
> 
>  For each try I had to copy dbus.h from my includes folder because it
> will error out and it seems to like it right in the main folder, I've
> also tried copying the whole dbus folder from includes to the src
> folder, for 2.80 I copied the nettle includes into src because it
> couldn't find that as well.
> 
> These are the changes I did to config.h each time I tried to compile:
> This was for 2.7
> 
> #define DEFLEASE 86400 /* default lease time, 1 hour */
> #define CHUSER "dnsmasq"
> #define CHGRP "dnsmasq"
> 
> #define HAVE_LUASCRIPT */
> #define HAVE_DBUS */
> #define HAVE_IDN */
> #define HAVE_CONNTRACK */
> #define HAVE_DNSSEC */
> 
> #define LEASEFILE "/var/lib/dnsmasq/dnsmasq.leases"
> 
> For 2.8
> #define HAVE_LUASCRIPT
> #define HAVE_DBUS
> #define HAVE_IDN
> #define HAVE_LIBIDN2
> #define HAVE_CONNTRACK
> #define HAVE_DNSSEC
> 
> In the makefile I chg Lua to 5.3 because Centos only has 5.1 and I added
> this for 2.8 LIBS  = -L/usr/local/lib64 - this time I didn't copy over
> the nettle includes:
> 
> crypto.c: In function ‘dnsmasq_ecdsa_verify’:
> crypto.c:297:36: error: ‘nettle_secp_256r1’ undeclared (first use in
> this function)
>     nettle_ecc_point_init(key_256, _secp_256r1);
>     ^
> crypto.c:297:36: note: each undeclared identifier is reported only once
> for each function it appears in
> crypto.c:310:36: error: ‘nettle_secp_384r1’ undeclared (first use in
> this function)
>     nettle_ecc_point_init(key_384, _secp_384r1);
>     ^
> make[1]: *** [/mnt/sdb1/dnsmasq-2.80/Makefile:161: crypto.o] Error 1
> make[1]: Leaving directory '/mnt/sdb1/dnsmasq-2.80/src'
> make: *** [Makefile:86: all] Error 2
> 
> This is line 297: nettle_ecc_point_init(key_256, _secp_256r1);
> This is line 310: nettle_ecc_point_init(key_384, _secp_384r1);
> 
> I looked through openssl to try and see how the defined this and I can't
> remember where it was at
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973



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

Re: [Dnsmasq-discuss] Asigning IP DHCP IP by device type.

[Petr Mensik]

I think dhcp-option, dhcp-vendorclass, dhcp-mac, dhcp-match and using
tags is what you are looking for. I am afraid dnsmasq does not document
what kind of devices send what parameters. It should be somehow simple
to identify iOS, it might be more difficult with androids. I think they
all present hostname beginning with android-*. Never tried to use it
myself however. dhcp-range can be different for different tags.

On 10/28/2018 01:58 PM, Ramses wrote:
> Hi everybody,
> 
> I have a doubt and I can't found a solution...
> 
> Does anybody know, and can day me, if there is any way to configure DNSMasq 
> to asign IP depending if device type that requests the IP?
> 
> I want to define various IP Ranges to asign the IP depending, by example, if 
> the request came from smartphones (Android / IOS) or others.
> 
> 
> Regards,
> 
> Ramsés
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

Re: [Dnsmasq-discuss] DHCP Logging

[Petr Mensik]

Hi Tony,

I think dhcp-script can be used to log any information related to dhcp
assignments in custom format. I think basic dhcp request informations is
logged even without log-dhcp. Have you checked syslog or journalctl?

Example from libvirt instance:
DHCPOFFER(virbr0) 192.168.122.161 52:54:00:4b:aa:67

Is that enough? Is something important missing?

On 10/28/2018 03:15 AM, Tony White wrote:
> Hi folks,
>  I am hoping I have missed the option to log all
> dhcp assignments.
>   The only one I have found id --log-dhcp which seems
> to log a lot more than time,date,ipaddress, mac address
> and lease time etc.
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

[Dnsmasq-discuss] [PATCH] Free config file values on parsing errors.

[Petr Mensik]

Hi again.

This time I have a little bit more controversal patches. But I think
still useful. They fixes memory leaks that might occur in some cases.
Most dnsmasq errors is fatal, so it does not matter. But some are not.
Some parts are reloaded on SIGHUP signal, so it might leak more than once.

Some example when it changes the failures. Use dhcp-options file with
this content:

tag:error,vendor:redhat
option:ntp-server,1.2.3.4.5
option6:ntp-server,[:::]

Is not fatal and dnsmasq will start. On each reload command, it would
leak some memory. I validated it using valgrind --leak-check=full
dnsmasq -d. This patch fixes it. It introduces something that might be
considered constructor and destructor of selected structures. What do
you think of it?

Comments are welcome.

Cheers,
Petr
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
From 55ecb0728dbd19ef3412be2dc70d2ed9dd6ecc5e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Thu, 16 Aug 2018 15:48:00 +0200
Subject: [PATCH 1/2] More fixes free options

Free resources on failed config file parsing.
Make sure one_opt will free allocated memory on failed parsing.
All unsaved memory is freed on syntax error in options.
---
 src/option.c | 360 ++-
 1 file changed, 257 insertions(+), 103 deletions(-)

diff --git a/src/option.c b/src/option.c
index 56ef945..547d36e 100644
--- a/src/option.c
+++ b/src/option.c
@@ -759,6 +759,7 @@ static void do_usage(void)
 }
 
 #define ret_err(x) do { strcpy(errstr, (x)); return 0; } while (0)
+#define ret_err_free(x,m) do { strcpy(errstr, (x)); free((m)); return 0; } while (0)
 
 static char *parse_mysockaddr(char *arg, union mysockaddr *addr) 
 {
@@ -904,6 +905,8 @@ static struct server *add_rev4(struct in_addr addr, int msize)
   p += sprintf(p, "%d.", (a >> 24) & 0xff);
   break;
 default:
+  free(serv->domain);
+  free(serv);
   return NULL;
 }
 
@@ -1069,7 +1072,7 @@ static int parse_dhcp_opt(char *errstr, char *arg, int flags)
   if (is6)
 {
   if (new->flags & (DHOPT_VENDOR | DHOPT_ENCAPSULATE))
-	ret_err(_("unsupported encapsulation for IPv6 option"));
+	ret_err_free(_("unsupported encapsulation for IPv6 option"), new);
   
   if (opt_len == 0 &&
 	  !(new->flags & DHOPT_RFC3925))
@@ -1083,7 +1086,7 @@ static int parse_dhcp_opt(char *errstr, char *arg, int flags)
   
   /* option may be missing with rfc3925 match */
   if (!option_ok)
-ret_err(_("bad dhcp-option"));
+ret_err_free(_("bad dhcp-option"), new);
   
   if (comma)
 {
@@ -1151,10 +1154,10 @@ static int parse_dhcp_opt(char *errstr, char *arg, int flags)
 	  is_string = is_dec = is_hex = 0;
 	  
 	  if (!is6 && (!is_addr || dots == 0))
-	ret_err(_("bad IP address"));
+	ret_err_free(_("bad IP address"), new);
 
 	   if (is6 && !is_addr6)
-	 ret_err(_("bad IPv6 address"));
+	 ret_err_free(_("bad IPv6 address"), new);
 	}
   /* or names */
   else if (opt_len & (OT_NAME | OT_RFC1035_NAME | OT_CSTRING))
@@ -1247,7 +1250,10 @@ static int parse_dhcp_opt(char *errstr, char *arg, int flags)
 	  comma = split(cp);
 	  slash = split_chr(cp, '/');
 	  if (!inet_pton(AF_INET, cp, ))
-		ret_err(_("bad IPv4 address"));
+{
+  free(new->val);
+		  ret_err_free(_("bad IPv4 address"), new);
+}
 	  if (!slash)
 		{
 		  memcpy(op, , INADDRSZ);
@@ -1292,8 +1298,9 @@ static int parse_dhcp_opt(char *errstr, char *arg, int flags)
 		  op += IN6ADDRSZ;
 		  continue;
 		}
-	  
-	  ret_err(_("bad IPv6 address"));
+
+  free(new->val);
+	  ret_err_free(_("bad IPv6 address"), new);
 	} 
 	  new->len = op - new->val;
 	}
@@ -1320,7 +1327,7 @@ static int parse_dhcp_opt(char *errstr, char *arg, int flags)
 		  if (strcmp (arg, ".") != 0)
 		{
 		  if (!(dom = canonicalise_opt(arg)))
-			ret_err(_("bad domain in dhcp-option"));
+			ret_err_free(_("bad domain in dhcp-option"), new);
 			
 		  domlen = strlen(dom) + 2;
 		}
@@ -1414,7 +1421,7 @@ static int parse_dhcp_opt(char *errstr, char *arg, int flags)
 		{
 		  char *dom = canonicalise_opt(arg);
 		  if (!dom)
-		ret_err(_("bad domain in dhcp-option"));
+		ret_err_free(_("bad domain in dhcp-option"), new);
 				  
 		  newp = opt_malloc(len + strlen(dom) + 2);
 		  
@@ -1452,14 +1459,14 @@ static int parse_dhcp_opt(char *errstr, char *arg, int flags)
   ((new->len > 255) || 
   (new->len > 253 && (new->flags & (DHOPT_VENDOR | DHOPT_ENCAPSULATE))) ||
(new->len > 250 && (new->flags & DHOPT_RFC3925
-ret_err(_("dhcp-option too long"));
+ret_err_free(_("dhcp-option too long"), new);
   
   if (flags == DHOPT_MATCH)
 {
   if ((new->flags & (DHOPT_ENCAPSULATE | DHOPT_VENDOR)) ||
 	  !new->netid ||
 	  new->netid->next)
-	ret_err(_("illegal dhcp-match"));
+	ret_err_free(_("illegal 

Re: [Dnsmasq-discuss] [PATCH] Free config file values on parsing errors.

[Petr Mensik]

Additional patch that reduces some repeating parts.

On 10/25/2018 10:36 AM, Petr Mensik wrote:
> Hi again.
> 
> This time I have a little bit more controversal patches. But I think
> still useful. They fixes memory leaks that might occur in some cases.
> Most dnsmasq errors is fatal, so it does not matter. But some are not.
> Some parts are reloaded on SIGHUP signal, so it might leak more than once.
> 
> Some example when it changes the failures. Use dhcp-options file with
> this content:
> 
> tag:error,vendor:redhat
> option:ntp-server,1.2.3.4.5
> option6:ntp-server,[:::]
> 
> Is not fatal and dnsmasq will start. On each reload command, it would
> leak some memory. I validated it using valgrind --leak-check=full
> dnsmasq -d. This patch fixes it. It introduces something that might be
> considered constructor and destructor of selected structures. What do
> you think of it?
> 
> Comments are welcome. Another patch would be sent short after, they are
> too big together to require moderator attention.
> 
> Cheers,
> Petr
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
>From ae3837cabc7e7b2fbd2d875f403a3f26a4d81422 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Thu, 16 Aug 2018 18:10:25 +0200
Subject: [PATCH 2/2] Reduce repeating code parsing tags

DHCP parameters often can have optional tags before it. Reduce repeated
parsing of it, use dhcp_tags() to parse and free if unsuccessful.
Make sure null pointer will not crash free function.
Free also errors in dhcp-range.
---
 src/option.c | 326 +++
 1 file changed, 171 insertions(+), 155 deletions(-)

diff --git a/src/option.c b/src/option.c
index 547d36e..66847fb 100644
--- a/src/option.c
+++ b/src/option.c
@@ -577,14 +577,15 @@ static void *opt_malloc(size_t size)
   return ret;
 }
 
-static char *opt_string_alloc(char *cp)
+static char *opt_string_alloc(const char *cp)
 {
   char *ret = NULL;
+  size_t len;
   
-  if (cp && strlen(cp) != 0)
+  if (cp && (len = strlen(cp)) != 0)
 {
-  ret = opt_malloc(strlen(cp)+1);
-  strcpy(ret, cp); 
+  ret = opt_malloc(len+1);
+  memcpy(ret, cp, len+1); 
   
   /* restore hidden metachars */
   unhide_metas(ret);
@@ -760,6 +761,7 @@ static void do_usage(void)
 
 #define ret_err(x) do { strcpy(errstr, (x)); return 0; } while (0)
 #define ret_err_free(x,m) do { strcpy(errstr, (x)); free((m)); return 0; } while (0)
+#define goto_err(x) do { strcpy(errstr, (x)); goto on_error; } while (0)
 
 static char *parse_mysockaddr(char *arg, union mysockaddr *addr) 
 {
@@ -961,6 +963,97 @@ static char *set_prefix(char *arg)
return arg;
 }
 
+static struct dhcp_netid *
+dhcp_netid_create(const char *net, struct dhcp_netid *next)
+{
+  struct dhcp_netid *tt;
+  tt = opt_malloc(sizeof (struct dhcp_netid));
+  tt->net = opt_string_alloc(net);
+  tt->next = next;
+  return tt;
+}
+
+static void dhcp_netid_free(struct dhcp_netid *nid)
+{
+  while (nid)
+{
+  struct dhcp_netid *tmp = nid;
+  nid = nid->next;
+  free(tmp->net);
+  free(tmp);
+}
+}
+
+/* Parse one or more tag:s before parameters.
+ * Moves arg to the end of tags. */
+static struct dhcp_netid * dhcp_tags(char **arg)
+{
+  struct dhcp_netid *id = NULL;
+
+  while (is_tag_prefix(*arg))
+{
+  char *comma = split(*arg);
+  id = dhcp_netid_create((*arg)+4, id);
+  *arg = comma;
+};
+  if (!*arg)
+{
+  dhcp_netid_free(id);
+  id = NULL;
+}
+  return id;
+}
+
+static void dhcp_netid_list_free(struct dhcp_netid_list *netid)
+{
+  while (netid)
+{
+  struct dhcp_netid_list *tmplist = netid;
+  netid = netid->next;
+  dhcp_netid_free(tmplist->list);
+  free(tmplist);
+}
+}
+
+static void dhcp_config_free(struct dhcp_config *config)
+{
+  if (config)
+{
+  struct hwaddr_config *hwaddr = config->hwaddr;
+  while (hwaddr)
+{
+	  struct hwaddr_config *tmp = hwaddr;
+  hwaddr = hwaddr->next;
+	  free(tmp);
+}
+  dhcp_netid_list_free(config->netid);
+  if (config->flags & CONFIG_CLID)
+free(config->clid);
+  free(config);
+}
+}
+
+static void dhcp_context_free(struct dhcp_context *ctx)
+{
+  if (ctx)
+{
+  dhcp_netid_free(ctx->filter);
+  free(ctx->netid.net);
+  free(ctx->template_interface);
+  free(ctx);
+}
+}
+
+static void dhcp_opt_free(struct dhcp_opt *opt)
+{
+  if (opt->flags & DHOPT_VENDOR)
+free(opt->u.vendor_class);
+  dhcp_netid_free(opt->netid);
+  free(opt->val)

Re: [Dnsmasq-discuss] [PATCH] Simplify options flags

[Petr Mensik]

Thanks!

On 10/24/2018 11:39 PM, Simon Kelley wrote:
> On 24/10/2018 16:25, Petr Mensik wrote:
>> Hi!
>>
>> I have not managed it until dnsmasq 2.80 were out, but anyway. I have
>> some proposal to simplify handling of options bits. Static analysis
>> complains on compiler dead-code optimization. I propose having array
>> instead. It adds few defines. But it allows adding any bits to defines
>> and moving OPT_LAST. It will resize itself as required.
>>
>> It might be possible to change unsigned int to unsigned long. It would
>> use 64 bit numbers on x86_64 machines. But I guess it might not be worth
>> that optimization.
>>
>> Chances to get it merged?
>>
>>
> 
> Merged as is. a definite improvement.
> 
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973



signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] [PATCH] Simplify options flags

[Petr Mensik]

Hi!

I have not managed it until dnsmasq 2.80 were out, but anyway. I have
some proposal to simplify handling of options bits. Static analysis
complains on compiler dead-code optimization. I propose having array
instead. It adds few defines. But it allows adding any bits to defines
and moving OPT_LAST. It will resize itself as required.

It might be possible to change unsigned int to unsigned long. It would
use 64 bit numbers on x86_64 machines. But I guess it might not be worth
that optimization.

Chances to get it merged?
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
From 2a698e8e5162c2e2272a638354bb0e3bbebb4b02 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Mon, 20 Aug 2018 19:56:47 +0200
Subject: [PATCH] Simplify options bits

Do not rely on dead code elimination, use array instead.
Make options bits derived from size and count. Use size of option bits
and last supported bit in computation. No new change would be required
when new options are added. Just change OPT_LAST constant.
---
 src/dnsmasq.h | 11 +++
 src/option.c  | 10 ++
 2 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index e2d5626..f8803f5 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -200,9 +200,6 @@ struct event_desc {
 #define EC_MISC5
 #define EC_INIT_OFFSET 10
 
-/* Trust the compiler dead-code eliminator */
-#define option_bool(x) (((x) < 32) ? daemon->options & (1u << (x)) : daemon->options2 & (1u << ((x) - 32)))
-
 #define OPT_BOGUSPRIV  0
 #define OPT_FILTER 1
 #define OPT_LOG2
@@ -264,6 +261,12 @@ struct event_desc {
 #define OPT_UBUS   58
 #define OPT_LAST   59
 
+#define OPTION_BITS (sizeof(unsigned int)*8)
+#define OPTION_SIZE ( (OPT_LAST/OPTION_BITS)+((OPT_LAST%OPTION_BITS)!=0) )
+#define option_var(x) (daemon->options[(x) / OPTION_BITS])
+#define option_val(x) ((1u) << ((x) % OPTION_BITS))
+#define option_bool(x) (option_var(x) & option_val(x))
+
 /* extra flags for my_syslog, we use a couple of facilities since they are known 
not to occupy the same bits as priorities, no matter how syslog.h is set up. */
 #define MS_TFTP   LOG_USER
@@ -978,7 +981,7 @@ extern struct daemon {
  config file arguments. All set (including defaults)
  in option.c */
 
-  unsigned int options, options2;
+  unsigned int options[OPTION_SIZE];
   struct resolvc default_resolv, *resolv_files;
   time_t last_resolv;
   char *servers_file;
diff --git a/src/option.c b/src/option.c
index 66847fb..8198757 100644
--- a/src/option.c
+++ b/src/option.c
@@ -1583,18 +1583,12 @@ on_error:
 
 void set_option_bool(unsigned int opt)
 {
-  if (opt < 32)
-daemon->options |= 1u << opt;
-  else
-daemon->options2 |= 1u << (opt - 32);
+  option_var(opt) |= option_val(opt);
 }
 
 void reset_option_bool(unsigned int opt)
 {
-  if (opt < 32)
-daemon->options &= ~(1u << opt);
-  else
-daemon->options2 &= ~(1u << (opt - 32));
+  option_var(opt) &= ~(option_val(opt));
 }
 
 static void server_list_free(struct server *list)
-- 
2.14.4

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

Re: [Dnsmasq-discuss] multiple soa

[Petr Mensik]

Second soa in one zone cannot be added. One zone has one soa. Can you
please share relevant configuration parts?

On 10/09/2018 11:46 AM, Алексей Кузнецов wrote:
> Hello, i set zone with soa record and its work fine. I want add second soa
> zone but dnsmasq say dublicate options in config. How to add second soa?
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

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

[Dnsmasq-discuss] [PATCH] Various fixes detected by static analysis

[Petr Mensik]

Hi Simon and all others,

I have tried running dnsmasq under coverity, static analysis tool. It
found some warnings. I have fixed some things. Most obvious error was
inconsistent handling of buffer length of interface names. Buffer size
is IFNAMSIZ long, that is 16 bytes. But if interface should have
terminating zero, max. useable length is 15. Sometimes, buffer size is
16+1, sometimes only 16. Sometimes name might be sent to the kernel
unterminated. According to [1] it cannot be longer in Linux.

I have created shared simple function that will always terminate string.
And few little improvements around. What do you think?

It complains a lot about returns from one_opt in option.c. I can make
patch that will deallocate memory before returning error. In some cases,
i think option parsing does not have to be fatal. Would you accept fixes
that will free memory before return? I think in some cases option
parsing can be used for files that can be reread multiple times when
running.

1.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/?id=f236da93df5be85409c24f03683e3d8c54fac72b
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
From a6c3fe2f00468b7e135d5c51df1b8391c2f28733 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Wed, 15 Aug 2018 18:17:00 +0200
Subject: [PATCH 1/3] Fix lengths of interface names

Use helper function similar to copy correctly limited names into
buffers.
---
 src/bpf.c |  2 +-
 src/dhcp-common.c |  5 -
 src/dhcp.c|  9 -
 src/dnsmasq.h |  1 +
 src/log.c |  2 +-
 src/netlink.c |  5 +
 src/network.c | 12 ++--
 src/option.c  |  9 -
 src/rfc2131.c | 10 +-
 src/tftp.c|  2 +-
 src/util.c| 13 -
 11 files changed, 44 insertions(+), 26 deletions(-)

diff --git a/src/bpf.c b/src/bpf.c
index 49a11bf..ff66d6d 100644
--- a/src/bpf.c
+++ b/src/bpf.c
@@ -169,7 +169,7 @@ int iface_enumerate(int family, void *parm, int (*callback)())
 	  struct in6_ifreq ifr6;
 
 	  memset(, 0, sizeof(ifr6));
-	  strncpy(ifr6.ifr_name, addrs->ifa_name, sizeof(ifr6.ifr_name));
+	  safe_strncpy(ifr6.ifr_name, addrs->ifa_name, sizeof(ifr6.ifr_name));
 	  
 	  ifr6.ifr_addr = *((struct sockaddr_in6 *) addrs->ifa_addr);
 	  if (fd != -1 && ioctl(fd, SIOCGIFAFLAG_IN6, ) != -1)
diff --git a/src/dhcp-common.c b/src/dhcp-common.c
index 8ff0f0d..78c1d9b 100644
--- a/src/dhcp-common.c
+++ b/src/dhcp-common.c
@@ -485,8 +485,11 @@ char *whichdevice(void)
  
 void  bindtodevice(char *device, int fd)
 {
+  size_t len = strlen(device)+1;
+  if (len > IFNAMSIZ)
+len = IFNAMSIZ;
   /* only allowed by root. */
-  if (setsockopt(fd, SOL_SOCKET, SO_BINDTODEVICE, device, IFNAMSIZ) == -1 &&
+  if (setsockopt(fd, SOL_SOCKET, SO_BINDTODEVICE, device, len) == -1 &&
   errno != EPERM)
 die(_("failed to set SO_BINDTODEVICE on DHCP socket: %s"), NULL, EC_BADNET);
 }
diff --git a/src/dhcp.c b/src/dhcp.c
index 4d29525..f8d323b 100644
--- a/src/dhcp.c
+++ b/src/dhcp.c
@@ -232,7 +232,7 @@ void dhcp_packet(time_t now, int pxe_fd)
   
 #ifdef HAVE_LINUX_NETWORK
   /* ARP fiddling uses original interface even if we pretend to use a different one. */
-  strncpy(arp_req.arp_dev, ifr.ifr_name, 16);
+  safe_strncpy(arp_req.arp_dev, ifr.ifr_name, sizeof(arp_req.arp_dev));
 #endif 
 
   /* If the interface on which the DHCP request was received is an
@@ -255,7 +255,7 @@ void dhcp_packet(time_t now, int pxe_fd)
 	  }
 	else 
 	  {
-		strncpy(ifr.ifr_name,  bridge->iface, IF_NAMESIZE);
+		safe_strncpy(ifr.ifr_name,  bridge->iface, sizeof(ifr.ifr_name));
 		break;
 	  }
 	  }
@@ -279,7 +279,7 @@ void dhcp_packet(time_t now, int pxe_fd)
   is_relay_reply = 1; 
   iov.iov_len = sz;
 #ifdef HAVE_LINUX_NETWORK
-  strncpy(arp_req.arp_dev, ifr.ifr_name, 16);
+  safe_strncpy(arp_req.arp_dev, ifr.ifr_name, sizeof(arp_req.arp_dev));
 #endif 
 }
   else
@@ -988,8 +988,7 @@ char *host_from_dns(struct in_addr addr)
   if (!legal_hostname(hostname))
 	return NULL;
   
-  strncpy(daemon->dhcp_buff, hostname, 256);
-  daemon->dhcp_buff[255] = 0;
+  safe_strncpy(daemon->dhcp_buff, hostname, 256);
   strip_hostname(daemon->dhcp_buff);
 
   return daemon->dhcp_buff;
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 4cf12bf..b260f8a 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -1237,6 +1237,7 @@ int legal_hostname(char *name);
 char *canonicalise(char *in, int *nomem);
 unsigned char *do_rfc1035_name(unsigned char *p, char *sval, char *limit);
 void *safe_malloc(size_t size);
+void safe_strncpy(char *dest, const char *src, size_t size);
 void safe_pipe(int *fd, int read_noblock);
 void *whine_malloc(size_t size);
 int sa_len(union mysockaddr *addr);
diff --git a/src/log.c b/src/log.c
index dae8a75..d0d4780 100644
--- a/src/log.c
+++ b/src/log.c
@@ -232,7 +232,7 @@ 

Re: [Dnsmasq-discuss] Per client dns spoof?

[Petr Mensik]

Hi Dax,

I do not know any way to reply with different addresses based on source IPs. 
But I think you can use different technique, just have them ask to different 
dnsmasq instance that contains that blacklist. You can use DNAT to redirect 
their requests to dnsmasq on different IP. That would provide blocked names and 
forward other request to the first one.

You can also provide them different DNS address based on their client-id or 
MAC. Just set a tag for their devices. Then use something like:
dhcp-option=tag:children,option:dns-server,10.0.0.2

Where dnsmasq is listening on 10.0.0.2 is filtering hosts you have chosen.

I assume you are able to start more than one dnsmasq instance on your device. 
You have to use --bind-interfaces or --bind-dynamic with --interface for it to 
work.

Your children would hate you for that however. You may make them feel like 
outsiders that cannot do all their friends can. They may visit worse sites when 
looking for workaround. But I guess you have considered it.

Good luck,
Petr

--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973


- Original Message -
From: "Dax Kelson" 
To: dnsmasq-discuss@lists.thekelleys.org.uk
Sent: Wednesday, April 26, 2017 5:51:34 PM
Subject: [Dnsmasq-discuss] Per client dns spoof?

I use dnsmasq to do dhcp and DNS for the internal lan and DNS domain at my 
house. 

I use dhcp-host to make static IP reservations fo most of the devices in my 
house. 

For a couple of devices (some devices my kids use), I would like to block 
YouTube by making various YouTube hostnames resolve to 127.0.0.1. All other 
devices should be able access YouTube normally. 

Can I accomplish this with dnsmasq? Something like a per dhcp-host addn-hosts 
file? 

I can certainly update the latest version if needed. 

Thanks, 
Dax Kelson 

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

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

Re: [Dnsmasq-discuss] [PATCH] Logging of dhcp_script output

[Petr Mensik]

Thank you for accepting that patches. I agree that some garbage is far more 
likely to appear in dhcp-script mode.
I would myself welcome error log from wrong formatted lease file as well. If I 
understand it well, that file will be overwritten after the first lease 
created. If it contains wrong data, just log an error, but do not terminate.

It should not surprise administrator that just disabled IPv6 support. Error 
message would be logged once at startup until the first lease is created. Then 
file will be rewritten without any IPv6 leases, because they were skipped 
during the reading. I would accept one error message as notification some 
leases are gone forever.

I will have to ask whether failure to start on database corruption is 
considered a problem. It was silently ignoring all problems before. Now it 
fails to start the service completely if any error occurs. I think it relied on 
auto recovery with empty leases in the same way as with plain file. I think 
there should be a way to override default behavior. I will check for more 
opinions and get back with results.

Thank you Simon.

Cheers,
Petr


--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973


- Original Message -
From: "Simon Kelley" <si...@thekelleys.org.uk>
To: "Petr Mensik" <pemen...@redhat.com>
Cc: dnsmasq-discuss@lists.thekelleys.org.uk
Sent: Sunday, April 23, 2017 3:14:08 PM
Subject: Re: [Dnsmasq-discuss] [PATCH] Logging of dhcp_script output

OK, there's a little subtlety here that needs to be taken into account.


The lease file format was not originally designed to be extensible, so
the code takes advantage (sort of) of the fact that lines which are
associated with IPv6 leases make no sense to older versions of dnsmasq
or even current versions compiled without IPv6 support.

The order of lines when the file is written is always

IPv4 leases
duid 
IPv6 leases

(I think duid may not get written in some cases - doesn't matter for the
sake of this argument.)

Therefore the behaviour of silently giving up when an unrecognisable
line is encountered is a feature, not a bug, as it allows old or
non-IPv6 dnsmasq binaries to work with newer lease files - they get the
IPv4 leases and ignore the rest.

Since the main problem you're trying to solve is unexpected error
messages from the script, the solution to this is to keep the old
behaviour when reading from a file, but the new behaviour when running
the script init command.

Given that we're only checking when using the init script, I think
die()ing is the best thing to do when parsing fails.

I've moved your patch on to do that, and to check ferror() on the
stream, to catch IO-errors.

Again, any new  bugs are mine :)

Cheers,

Simon.


On 19/04/17 19:14, Petr Mensik wrote:
> Hi Simon,
> 
> I like your changes. New shorter log is definitely helpful, separate log 
> section helps. The only bug I found is red white space highlight in the patch.
> 
> However I did yet another fix for remaining dhcp-script init action.
> It completely ignored any error in structure and silently skipped the rest of 
> database. If there was any message in stdin of init script, it just died 
> silently.
> The only thing that were visible was SIGPIPE from dhcp-script, because it did 
> not read whole database, if that signal was logged at all.
> My new patch handles garbage in leases database. If the line is wrong, it 
> logs part of wrong line and skips the rest of init.
> I thought about die in that case. I think it would be better for backward 
> compatibility to start with empty leases as before.
> 
> --
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemen...@redhat.com  PGP: 65C6C973
> 
> - Original Message -
> From: "Simon Kelley" <si...@thekelleys.org.uk>
> To: dnsmasq-discuss@lists.thekelleys.org.uk
> Sent: Sunday, April 16, 2017 9:29:21 PM
> Subject: Re: [Dnsmasq-discuss] [PATCH] Logging of dhcp_script output
> 
> I like this. Yes, I know you can do it with shell magic, but this is
> easier and what I would expect to happen.
> 
> I've changed the patch quite a lot:
> 
> 1) Don't go to large effort to report "never happen" errors from pipe(),
> just silently handle them in the same way as fork()
> 
> 2) Don't do any of this when the -d debug flag is in effect, as it's
> already defined that the script gets stdin, stdout and stderr from the
> dnsmasq process in that case.
> 
> 3) Expand the subject-based logging that already exists, DHCP stuff
> comes from dnsmasq-dhcp, script output comes from dhcp-script. That
> avoids the wordy preamble to every line otherwise.
> 
> 4) Pull the copy-to-log code out of the loop wait()ing for processes to
> die, it makes more sense to iterate until the descriptors close,

Re: [Dnsmasq-discuss] [PATCH] Logging of dhcp_script output

[Petr Mensik]

Hi Simon,

I like your changes. New shorter log is definitely helpful, separate log 
section helps. The only bug I found is red white space highlight in the patch.

However I did yet another fix for remaining dhcp-script init action.
It completely ignored any error in structure and silently skipped the rest of 
database. If there was any message in stdin of init script, it just died 
silently.
The only thing that were visible was SIGPIPE from dhcp-script, because it did 
not read whole database, if that signal was logged at all.
My new patch handles garbage in leases database. If the line is wrong, it logs 
part of wrong line and skips the rest of init.
I thought about die in that case. I think it would be better for backward 
compatibility to start with empty leases as before.

--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

- Original Message -
From: "Simon Kelley" <si...@thekelleys.org.uk>
To: dnsmasq-discuss@lists.thekelleys.org.uk
Sent: Sunday, April 16, 2017 9:29:21 PM
Subject: Re: [Dnsmasq-discuss] [PATCH] Logging of dhcp_script output

I like this. Yes, I know you can do it with shell magic, but this is
easier and what I would expect to happen.

I've changed the patch quite a lot:

1) Don't go to large effort to report "never happen" errors from pipe(),
just silently handle them in the same way as fork()

2) Don't do any of this when the -d debug flag is in effect, as it's
already defined that the script gets stdin, stdout and stderr from the
dnsmasq process in that case.

3) Expand the subject-based logging that already exists, DHCP stuff
comes from dnsmasq-dhcp, script output comes from dhcp-script. That
avoids the wordy preamble to every line otherwise.

4) Pull the copy-to-log code out of the loop wait()ing for processes to
die, it makes more sense to iterate until the descriptors close, then
reap child processes.

5) Rationalise conditional compilation stuff. There may be more of that
in a subsequent commit.

6) Update the man page to reflect new reality (!)

Any remaining bugs are mine, but Petr please check that I didn't break
things.


Cheers,

Simon.



On 24/03/17 17:38, Petr Mensik wrote:
> Hi!
> 
> Some guys using dnsmasq in virtual machines and OpenStack use custom 
> dhcp_script to manage leases of clients.
> However they complain if there is anything wrong with them, then are just 
> told broken pipe and no information.
> 
> We understand it should not produce any output under normal operation. But it 
> would be really helpful if at least anything was visible in logs. Especially 
> for errors happening under rare circumstances.
> I have prepared patch to forward events from helper. It prevents SIGPIPE 
> receiving if script does write anything. And logs it from dnsmasq.
> It seems very handy to me.
> 
> It was not simple to forward it to main log. I would like opinions if it is 
> useful or dangerous.
> Do you consider it worth merging Simon?
> 
> Best Regards,
> Petr
> --
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemen...@redhat.com  PGP: 65C6C973
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
From cf2831d52884452f039e05cc16f6562cbe6db650 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= <pemen...@redhat.com>
Date: Wed, 19 Apr 2017 19:32:54 +0200
Subject: [PATCH] Verify leases database format, log errors if present.

---
 src/lease.c | 110 +++-
 1 file changed, 65 insertions(+), 45 deletions(-)

diff --git a/src/lease.c b/src/lease.c
index fc6cbe9..77da638 100644
--- a/src/lease.c
+++ b/src/lease.c
@@ -21,67 +21,38 @@
 static struct dhcp_lease *leases = NULL, *old_leases = NULL;
 static int dns_dirty, file_dirty, leases_left;
 
-void lease_init(time_t now)
+static int read_leases(time_t now, FILE *leasestream)
 {
   unsigned long ei;
   struct all_addr addr;
   struct dhcp_lease *lease;
   int clid_len, hw_len, hw_type;
-  FILE *leasestream;
-  
-  leases_left = daemon->dhcp_max;
-  
-  if (option_bool(OPT_LEASE_RO))
-{
-  /* run " init" once to get the
-	 initial state of the database. If leasefile-ro is
-	 set without a script, we just do without any 
-	 lease database. */
-#ifdef HAVE_SCRIPT
-  if (daemon->lease_change_command)
-	{
-	  strcpy(daemon->dhcp_buff, daemon->lease_change_command);
-	  strcat(daemon->dhcp_buff, " init");
-	  leasestream = popen(daemon->dhcp_buff, "r");
-	

Re: [Dnsmasq-discuss] FW: Cachesize

[Petr Mensik]

Hi Nathan.

If you hit a cache limit of 1 quite often, are you sure dnsmasq is still 
the best choice for that server? I think dnsmasq focuses on small home routers 
and end networks. Have you considered other caching resolver, unbound for 
example? I think if this limit is not enough, maybe your network is not small 
enough. There is limit for some reason. I hope full cache does not mean 
recursion will stop working, but I did not validate that assumption.

I think main DNS resolvers of ISP network should use something more heavy than 
dnsmasq.
How many end hosts are using that server?
Do you require dnsmasq specific features?

Cheers,
Petr

--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973


- Original Message -
From: "Nathan Downes" 
To: dnsmasq-discuss@lists.thekelleys.org.uk
Sent: Monday, April 10, 2017 10:41:24 AM
Subject: [Dnsmasq-discuss] FW: Cachesize



Hi, 



I understand this is hardcoded to a limit of 1 but we use it for a small 
ISP network and quite often reach this, is it possible to make it 25000 in next 
release? Everyone has the choice at loading what to set it to, so I can’t see 
how this would cause issues. I would prefer to just use available packages than 
have to compile my own to adjust this and always have to remember the 
modification. 



Thanks, 



Nathan 

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

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

Re: [Dnsmasq-discuss] [PATCH] Logging of dhcp_script output

[Petr Mensik]

Well yes, you can redirect output to any file you want. It is not configurable 
however. And it cannot reuse any logging configuration you already have. You 
cannot use journalctl to list errors for example. You have to create place for 
dnsmasq to write that log and rotate it in regular intervals.

This solution is good for debugging your new script for the first time. It does 
not seem to good solution, if you want to log any problems in your long running 
service. Dnsmasq is used by libvirt for example, to provide DNS and DHCP on 
virtual subnet.

--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973


- Original Message -
From: "Alex Xu" <alex_y...@yahoo.ca>
To: dnsmasq-discuss@lists.thekelleys.org.uk
Sent: Friday, March 24, 2017 7:19:04 PM
Subject: Re: [Dnsmasq-discuss] [PATCH] Logging of dhcp_script output

On Fri, 24 Mar 2017 13:38:17 -0400 (EDT)
Petr Mensik <pemen...@redhat.com> wrote:

> Hi!
> 
> Some guys using dnsmasq in virtual machines and OpenStack use custom
> dhcp_script to manage leases of clients. However they complain if
> there is anything wrong with them, then are just told broken pipe and
> no information.
> 
> We understand it should not produce any output under normal
> operation. But it would be really helpful if at least anything was
> visible in logs. Especially for errors happening under rare
> circumstances. I have prepared patch to forward events from helper.
> It prevents SIGPIPE receiving if script does write anything. And logs
> it from dnsmasq. It seems very handy to me.
> 
> It was not simple to forward it to main log. I would like opinions if
> it is useful or dangerous. Do you consider it worth merging Simon?
> 
> Best Regards,
> Petr
> --
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemen...@redhat.com  PGP: 65C6C973
> 

you could also just put "exec >/var/log/whatever 2>&1" at the start of
your script. hell, you can even do "exec > >(logger) 2>&1" if you want.

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

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

[Dnsmasq-discuss] [PATCH] Logging of dhcp_script output

[Petr Mensik]

Hi!

Some guys using dnsmasq in virtual machines and OpenStack use custom 
dhcp_script to manage leases of clients.
However they complain if there is anything wrong with them, then are just told 
broken pipe and no information.

We understand it should not produce any output under normal operation. But it 
would be really helpful if at least anything was visible in logs. Especially 
for errors happening under rare circumstances.
I have prepared patch to forward events from helper. It prevents SIGPIPE 
receiving if script does write anything. And logs it from dnsmasq.
It seems very handy to me.

It was not simple to forward it to main log. I would like opinions if it is 
useful or dangerous.
Do you consider it worth merging Simon?

Best Regards,
Petr
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

From a7b740b12525b085efcab5d9c8a8260df2ae33dd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Fri, 24 Mar 2017 18:23:53 +0100
Subject: [PATCH] Log output of dhcp_script called from handler

---
 src/dnsmasq.c | 13 
 src/dnsmasq.h | 49 +++---
 src/helper.c  | 63 ---
 3 files changed, 98 insertions(+), 27 deletions(-)

diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index d2cc7cc..e2e42bf 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -1315,6 +1315,19 @@ static void async_event(int pipe, time_t now)
 		  daemon->lease_change_command, strerror(ev.data));
 	break;
 
+#if defined(HAVE_SCRIPT) && defined(HAVE_DHCP)
+  case EVENT_SCRIPT_ERR:
+	if (ev.data != 0)
+	  my_syslog(LOG_ERR, _("dhcp-script output: %s: %s"),
+strerror(ev.data), msg ? msg : "");
+else
+	  my_syslog(LOG_DEBUG, _("dhcp-script output: %s"),
+msg ? msg : "");
+free(msg);
+	msg = NULL;
+	break;
+#endif
+
 	/* necessary for fatal errors in helper */
   case EVENT_USER_ERR:
   case EVENT_DIE:
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 6b44e53..f51ae3b 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -145,30 +145,31 @@ struct event_desc {
   int event, data, msg_sz;
 };
 
-#define EVENT_RELOAD1
-#define EVENT_DUMP  2
-#define EVENT_ALARM 3
-#define EVENT_TERM  4
-#define EVENT_CHILD 5
-#define EVENT_REOPEN6
-#define EVENT_EXITED7
-#define EVENT_KILLED8
-#define EVENT_EXEC_ERR  9
-#define EVENT_PIPE_ERR  10
-#define EVENT_USER_ERR  11
-#define EVENT_CAP_ERR   12
-#define EVENT_PIDFILE   13
-#define EVENT_HUSER_ERR 14
-#define EVENT_GROUP_ERR 15
-#define EVENT_DIE   16
-#define EVENT_LOG_ERR   17
-#define EVENT_FORK_ERR  18
-#define EVENT_LUA_ERR   19
-#define EVENT_TFTP_ERR  20
-#define EVENT_INIT  21
-#define EVENT_NEWADDR   22
-#define EVENT_NEWROUTE  23
-#define EVENT_TIME_ERR  24
+#define EVENT_RELOAD 1
+#define EVENT_DUMP   2
+#define EVENT_ALARM  3
+#define EVENT_TERM   4
+#define EVENT_CHILD  5
+#define EVENT_REOPEN 6
+#define EVENT_EXITED 7
+#define EVENT_KILLED 8
+#define EVENT_EXEC_ERR   9
+#define EVENT_PIPE_ERR   10
+#define EVENT_USER_ERR   11
+#define EVENT_CAP_ERR12
+#define EVENT_PIDFILE13
+#define EVENT_HUSER_ERR  14
+#define EVENT_GROUP_ERR  15
+#define EVENT_DIE16
+#define EVENT_LOG_ERR17
+#define EVENT_FORK_ERR   18
+#define EVENT_LUA_ERR19
+#define EVENT_TFTP_ERR   20
+#define EVENT_INIT   21
+#define EVENT_NEWADDR22
+#define EVENT_NEWROUTE   23
+#define EVENT_TIME_ERR   24
+#define EVENT_SCRIPT_ERR 25
 
 /* Exit codes. */
 #define EC_GOOD0
diff --git a/src/helper.c b/src/helper.c
index 2b8164b..b777f77 100644
--- a/src/helper.c
+++ b/src/helper.c
@@ -14,6 +14,7 @@
along with this program.  If not, see .
 */
 
+#include 
 #include "dnsmasq.h"
 
 #ifdef HAVE_SCRIPT
@@ -77,6 +78,33 @@ struct script_data
 static struct script_data *buf = NULL;
 static size_t bytes_in_buf = 0, buf_size = 0;
 
+/* Send output of script to main process, line by line. */
+static int
+helper_stdin_resend(int event_fd, int outfd)
+{
+  FILE *fp;
+  size_t len;
+
+  fp = fdopen(outfd, "r");
+  if (!fp)
+return 0;
+  while (fgets(daemon->packet, daemon->packet_buff_sz, fp))
+{
+  /* do not include new lines, log will append them */
+  len = strlen(daemon->packet);
+  if (len > 0)
+{
+  --len;
+  if (daemon->packet[len] == '\n')
+daemon->packet[len] = 0;
+}
+  send_event(event_fd, EVENT_SCRIPT_ERR, 0, daemon->packet);
+}
+  fclose(fp);
+  return 1;
+}
+
+
 int create_helper(int event_fd, int err_fd, uid_t uid, gid_t gid, long max_fd)
 {
   pid_t pid;
@@ -135,7 +163,7 @@ int create_helper(int event_fd, int err_fd, uid_t uid, gid_t gid, long max_fd)
 	max_fd != STDIN_FILENO && max_fd != pipefd[0] && 
 	max_fd != event_fd && max_fd != err_fd)
   close(max_fd);
-  
+

Re: [Dnsmasq-discuss] What's the easiest way to add some names to default dnsmasq in debian/ubuntu?

[Petr Mensik]

Hi Chris,

I think you create some file, for exaqmple 
/etc/NetworkManager/dnsmasq.d/hosts.conf, containing 
addn-hosts=/etc/hosts.dnsmasq.
Then you would have to create hosts.dnsmasq with hosts(5) format. Place odin 
there.

1.2.3.4   odin

You could use some hook to NetworkManager to use create special file only for 
selected network. But I never did something like that, I cannot help you with 
that.

But I think you should try to ask LAN administrator to configure DNS and DHCP 
so that you do not have to invent something yourself.
Maybe there is a name already that you do not know about.

Cheers,
Petr
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

- Original Message -
From: "Chris Green" 
To: dnsmasq-discuss@lists.thekelleys.org.uk
Sent: Friday, March 3, 2017 4:49:59 PM
Subject: [Dnsmasq-discuss] What's the easiest way to add some names to default 
dnsmasq in debian/ubuntu?

In Ubuntu systems (and maybe debian, not sure about this) dnsmasq is
run my NetworkManager to provide local DNS, the process shows up as:-

nobody1470  1022  0 15:01 ?00:00:00 /usr/sbin/dnsmasq 
--no-resolv --keep-in-foreground --no-hosts --bind-interfaces 
--pid-file=/var/run/NetworkManager/dnsmasq.pid --listen-address=127.0.1.1 
--cache-size=0 --conf-file=/dev/null --proxy-dnssec 
--enable-dbus=org.freedesktop.NetworkManager.dnsmasq 
--conf-dir=/etc/NetworkManager/dnsmasq.d

Is there any easy way to get it to recognise some local names?  I have
(in particular) a BeagleBone black on one LAN I use and it would be
really handy to be able to call it 'odin' rather than have to find its
IP address every time.

DHCP for the LAN is provided by a router which, sadly, doesn't seem to
know about local names.

Ideally 'odin' should only be present when it actually *is* present
(i.e. when I'm connected to the specific LAN where it exists), but
this isn't absolutely necessary.
 
-- 
Chris Green

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

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

Re: [Dnsmasq-discuss] Support of labels in --interface

[Petr Mensik]

I think it is automatic if there is already IP from the same subnet on that 
interface.

$ ip a add 192.168.122.1/24 dev virbr0
# no secondary flag yet, first address of 192.168.122.0/24
$ ip a add 192.168.122.254/24 dev virbr0 label virbr0:1
# secondary flag present, it is second address of 192.168.122.0/24 on that 
device
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

- Original Message -
From: "Simon Kelley" <si...@thekelleys.org.uk>
To: dnsmasq-disc...@thekelleys.org.uk
Sent: Friday, February 17, 2017 1:16:59 PM
Subject: Re: [Dnsmasq-discuss] Support of labels in --interface

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 15/02/17 17:38, Petr Mensik wrote:
> Hi!

> Let's say my configuration is: 4: virbr0:
> <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
> group default qlen 1000 link/ether 52:54:00:2b:ee:d3 brd
> ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope
> global virbr0 valid_lft forever preferred_lft forever inet
> 192.168.122.254/24 scope global secondary virbr0:1 valid_lft
> forever preferred_lft forever
> 

Quick question from the lazy: how do you set the "secondary" flag on
the second address?

ip addr add  dev virbr0 label virbr0:1

doesn't seem to.

Dunno if it matters, just want to replicate this exactly


Cheers,

Simon.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYpum7AAoJEBXN2mrhkTWi74gP/A1nDuRres/jwNlJBBa1Ooa1
GFS3gGsMTxlZpank4bsH9MUnezzLMwkTa/F3Pz2jztnVzGwSplmZqtqFQErYaLWR
wyJXGGeNNlRt/u2dChLMWTO/qyf2AVfa+Ght66npzwJ0laVVkBishPHDcCKPhLIY
Rv5+WSsgqFgUwMFpjj8xj0WJJU7iNjCG4G9dwlmHu9kElwnW9xiL9dC6dDZuLOrd
GHlDodp7c5L5R7UQkvnfmlLWCOgz6/21Z1LkLBlsDyjpQcX+e7G5shb7r2UEEX0o
5RX2+3utnyGAGysiaVF9logiGCN7Hx/dBhvwtrvdcDSxa944GavLtHVSftuwIGZG
RDZIMea2DixSJUuOjGJ0MIfLg6IeoigSGIlNgLP++EupOz6fqxT2iJbaQ0M4Mqtm
H6haQkMT7Xj5OUfdfptXmR89idQRoPP7WIGU8CPQrs70vLpdGwKoF7nbT3KqeVpK
C+9CvHAxFKtWoElIzVPn7Oa2Zz/alXBBXdIfRg5TEP0QrJZCgPBixZ9Yy5F2fVxE
fP88SazdH7Yq6HDlS6KfPPq6N+0IklD0Y6GoBcchxxPpJpKFCkhXAS8EKFb04QLg
ZgPOzu73LFmed9YAXSFggR+eMmxN2M5ImPidiW8/xLCvHgtvn3/EOEi3VcU2gOS6
wczS9ivnbdarmpyPP4i/
=8wXW
-END PGP SIGNATURE-

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

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

Re: [Dnsmasq-discuss] Dnsmasq domain configuration

[Petr Mensik]

Hi,

I think you should use --domain local parameter. It will tell your clients to 
use common dns domain and would resolve such names in dnsmasq.
Where are your DNS data stored? Do you use /etc/hosts for them? Do you have 
there fqdn with unqualified aliases?

--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973


- Original Message -
From: crist...@studioautoservice.it
To: dnsmasq-disc...@thekelleys.org.uk
Sent: Saturday, January 28, 2017 12:28:51 PM
Subject: Re: [Dnsmasq-discuss] Dnsmasq domain configuration

Solved adding fqdn to etc/host in the Ubuntu server. 


Il 28 gen 2017 11:48, crist...@studioautoservice.it ha scritto: 



I do apologize. Further investigation took me to my Windows XP clients that 
seems to append to every host request the local domain ( we are dismissing a 
Windows domain but the machine are still joined). 
So if I ping testhost XP will add Autoservice.locale to the request. 
I tried adding local=Autoservice.local to dnsmasq.conf but didn't work. 
I hope that after unjoined the client will work as expected. 
Thanks anyway. 


Il 27 gen 2017 20:59, crist...@studioautoservice.it ha scritto: 



Hi everyone, 
I'm trying to make dnsmasq work in my small office. 
It's installed on Ubuntu machine. 
Everything seems ok I can resolve host names of the other PC's. 
The only thing I'd like to fix now is that I have to put a dot at the end of 
the host name otherwise it will not be resolved. 
So basically if I ping 'testhost' it fail if I ping 'testhost.' It will work. 
There must me something about domain name but I need some help. 
Thanks in advance. 




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

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