Re: [Dnsmasq-discuss] dnsmasq to provide public DNS service

[T o n g]

On Wed, 06 Jul 2016 08:43:56 -0500, /dev/rob0 wrote:

>> > Nobody should do that indeed, because it is a very bad idea: your
>> > machine may then serve as an amplifier for DDoS attacks.
>> 
>> I'm more interested to know how to do that than actually provide the
>> DNS service. BTW, on to that thought, how the ISP or Google's DNS
>> server able to avoid being an amplifier for DDoS attacks?
> 
> Having some familiarity with this, I can address this question, while
> staying out of Albert's way as he valiantly tried to address the Big
> Picture. :)

Oh, thanks a lot for your detailed explanation. 

That's exactly the kind of info I need. We all know that "anything could 
happen". Once I asked how to use sendmail as the mail server so people 
can send me emails to me, to my account of my own domain, and the 
response was overwhelmingly: DON"T, then followed by "anything could 
happen", without explaining what actually could happen ---

Your detailed explanation really helped me understand the situation and 
complexity of the issue. 

> Dnsmasq is a wonderful piece of software which does a very nice job at
> meeting the needs of most small, simple sites.  I do not think it's well
> suited for ISP use, and especially not for use as an open resolver.

This is only for my personal use, and I'll turn it off once I'm done. 
I.e., I care more about *can* it be done part, not much on the part of 
"*should* it be done".

thanks again



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

Re: [Dnsmasq-discuss] dnsmasq to provide public DNS service

[T o n g]

On Tue, 05 Jul 2016 18:55:59 +0200, Albert ARIBAUD wrote:

> Hi Tong,
> 
> Le Tue, 5 Jul 2016 00:42:25 + (UTC)
> T o n g  a écrit:
> 
>> > 1) Does your dnsmasq host have access to the Internet?
>> > 
>> > 2) Have you configured your Internet access so that DNS requests
>> > incoming from the outside are routed to your dnsmasq host?
>> 
>> Yeah, those "out-side" factors, I know how to control, and they are
>> working fine. For example, I have use `listen-address=192.168.1.1`
>> before to provide DNS service for my own home network, and it works
>> fine.
> 
> Yes, listening to a LAN address allows serving client on the LAN. But
> this does absolutely not mean that conditions 1 and 2 above are met and
> that clients from the Net can be served.
> 
>> This box I'm configuring, it has its own public IP, not on 192.168.x.x.
>> The SSH, DNS, etc ports are open to the would as well.
> 
> This piece of information raises a lot of questions. Could you please
> anwer by 'yes' or 'no' to the following?
> 
> 1. Does the "box" you are referring to run the dnsmasq you are trying to
> configure?

Yes, the "box" is what I referred as the machine that I run the dnsmasq 
and trying to configure. This is the only thing I'm talking about so far. 
Nothing else. 

> 2. Is this box also the gateway from your LAN to the Internet?

No.

> 3. Does it hace two network interfaces, one facing the Internet and one
> facing the LAN?

No. 

Once again, the box I'm configuring, is a dedicated servers from the 
hosting company, and I have full (remote) control of it and have 
installed the latest Ubuntu into it. it has its own realy public IP. The 
SSH, DNS, etc ports are open to the would as well.

>> Oh, should I listen to its Gateway IP instead of 0.0.0.0?
> 
> You should not specifiy listen-address *at all* unless you want your
> dnsmasq to serve *only* your LAN or to serve *only* the Net.
> 
> You should not even specify any interface= option.

OK. So how dnsmasq decides whether to serve local host, or local network 
(LAN) or the general public (WAN)? If is it not listen-address, then what 
it is? 

>> The outside world is not involved yet -- I haven't been able to make
>> itself work first.
> 
> Before making dnsmasq work with clients from outside your LAN, you need
> to verify that your "box" meets conditions 1 and 2 above.
> 
> Let's start with condition 1. You can check it by running a traceroute
> from your "box" to some known internet host (e.g. google.com). What does
> such a traceroute print out?

What do you need the traceroute print out for? 

Can the dnsmasq be used as DNS server not only to local host, or local 
network, but also the general public as well or not? If yes, what would 
the configuration be? 

Does dnsmasq comes with that feature (serving the local network or the 
general public) out of box? Else what kind of alternation need to be made 
to the configuration file? 



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

Re: [Dnsmasq-discuss] dhcp-range broke in 2.76

[Matthew Keeler]

Yes, I have other dhcp-ranges for other types of hosts, I just also had a
static one where all my static leases got lumped into. So the dhcp server
should still run. All my other ranges were not experiencing parsing issues
after the upgrade so I didn’t mention them before.

-- 
Matthew Keeler

On July 6, 2016 at 12:16:30, Albert ARIBAUD (albert.arib...@free.fr) wrote:

Hi again Matthew,

Le Wed, 6 Jul 2016 08:54:55 -0700
Matthew Keeler  a écrit:

> Thank you Albert. I guess where I was going wrong was thinking that
> the static lease addresses referenced in a dhcp-host config needed to
> fall within another configured dhcp-range. So I guess I should just
> be able to remove that line from my configuration and have the same
> behavior as before (the first 128 ips in my subnet not being
> dynamically allocated but needing dhcp-host configurations).

You will need the dhcp-range option, as it is the one which enables
the DHCP server.

If you don't need dynamic allocation, but cannot use the 'static'
keyword, then you can set the dynamic range within the 128 address
range for which you have dhcp-host lines defined. Basically, it will
make dnsmasq reject or ignore any requests not in the ones statically
defined.

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

Re: [Dnsmasq-discuss] dhcp-range broke in 2.76

[Matthew Keeler]

Thank you Albert. I guess where I was going wrong was thinking that the
static lease addresses referenced in a dhcp-host config needed to fall
within another configured dhcp-range. So I guess I should just be able to
remove that line from my configuration and have the same behavior as before
(the first 128 ips in my subnet not being dynamically allocated but needing
dhcp-host configurations).

-- 
Matthew Keeler

On July 6, 2016 at 11:45:44, Albert ARIBAUD (albert.arib...@free.fr) wrote:

Hi Matthew,

Le Wed, 6 Jul 2016 10:31:05 -0400
Matthew Keeler  a écrit:

> I have been using dnsmasq for a while on my local network with
> several dhcp ranges specified. One of them no longer parses in v2.76
> although it did in v2.75.
>
> dhcp-range=10.3.2.1,10.3.2.127,static,255.255.254.0,infinite
>
> It looks like it is now no longer valid to have a start and end ipv4
> address with the static mode where this was allowed previously. Was
> this an intentional removal? My understanding (which may be
> incorrect) was that to have a ip range reserved for dhcp reservations
> required having the dhcp range specified and the dhcp-hosts specified
> to ips that fall within that range. Then that range would have the
> static mode to prevent auto assignment of ips to other unknown hosts.
>
> If this is intended behavior and not a bug, how can I allocate an IP
> range for DHCP reservations? I think something like the following
> should work to produce the same results although it is a rather ugly
> solution as it requires adding tags in many, many places.
>
> dhcp-range=tag:reserved,10.3.2.1,10.3.2.127,255.255.254.0,infinite
> dhcp-host=00:01:02:03:04:05,set:reserved,10.3.2.7,myhost

What do you mean by "reservations"? Static leases? For that you need
nothing more than a dhcp-host= line mapping the MAC or DUID to a static
IPv4 address, for each static lease you want.

The static keyword in dhcp-range= tells dnsmasq to not do dynamic
allocation, so basically a range is useless (as far as allocation is
concerned) if you specify static.

I personally define my dhcp-range= line without static and with a
small range for the odd guest machine, and my dhcp-host= lines with IPv4
addresses lying outside that range -- but even if a static lease IP
address fell within the dynamic DHCP range, dnsmasq would not use that
address for dynamic allocation.

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

Re: [Dnsmasq-discuss] dhcp-range broke in 2.76

[Albert ARIBAUD]

Hi again Matthew,

Le Wed, 6 Jul 2016 08:54:55 -0700
Matthew Keeler  a écrit:

> Thank you Albert. I guess where I was going wrong was thinking that
> the static lease addresses referenced in a dhcp-host config needed to
> fall within another configured dhcp-range. So I guess I should just
> be able to remove that line from my configuration and have the same
> behavior as before (the first 128 ips in my subnet not being
> dynamically allocated but needing dhcp-host configurations).

You will need the dhcp-range option, as it is the one which enables
the DHCP server.

If you don't need dynamic allocation, but cannot use the 'static'
keyword, then you can set the dynamic range within the 128 address
range for which you have dhcp-host lines defined. Basically, it will
make dnsmasq reject or ignore any requests not in the ones statically
defined.

Amicalement,
-- 
Albert.

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

Re: [Dnsmasq-discuss] dhcp-range broke in 2.76

[Albert ARIBAUD]

Hi Matthew,

Le Wed, 6 Jul 2016 10:31:05 -0400
Matthew Keeler  a écrit:

> I have been using dnsmasq for a while on my local network with
> several dhcp ranges specified. One of them no longer parses in v2.76
> although it did in v2.75.
> 
> dhcp-range=10.3.2.1,10.3.2.127,static,255.255.254.0,infinite
> 
> It looks like it is now no longer valid to have a start and end ipv4
> address with the static mode where this was allowed previously. Was
> this an intentional removal? My understanding (which may be
> incorrect) was that to have a ip range reserved for dhcp reservations
> required having the dhcp range specified and the dhcp-hosts specified
> to ips that fall within that range. Then that range would have the
> static mode to prevent auto assignment of ips to other unknown hosts.
> 
> If this is intended behavior and not a bug, how can I allocate an IP
> range for DHCP reservations? I think something like the following
> should work to produce the same results although it is a rather ugly
> solution as it requires adding tags in many, many places.
> 
> dhcp-range=tag:reserved,10.3.2.1,10.3.2.127,255.255.254.0,infinite
> dhcp-host=00:01:02:03:04:05,set:reserved,10.3.2.7,myhost

What do you mean by "reservations"? Static leases? For that you need
nothing more than a dhcp-host= line mapping the MAC or DUID to a static
IPv4 address, for each static lease you want.

The static keyword in dhcp-range= tells dnsmasq to not do dynamic
allocation, so basically a range is useless (as far as allocation is
concerned) if you specify static.

I personally define my dhcp-range= line without static and with a
small range for the odd guest machine, and my dhcp-host= lines with IPv4
addresses lying outside that range -- but even if a static lease IP
address fell within the dynamic DHCP range, dnsmasq would not use that
address for dynamic allocation.

Amicalement,
-- 
Albert.

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

[Dnsmasq-discuss] dhcp-range broke in 2.76

[Matthew Keeler]

I have been using dnsmasq for a while on my local network with several dhcp
ranges specified. One of them no longer parses in v2.76 although it did in
v2.75.

dhcp-range=10.3.2.1,10.3.2.127,static,255.255.254.0,infinite

It looks like it is now no longer valid to have a start and end ipv4
address with the static mode where this was allowed previously. Was this an
intentional removal? My understanding (which may be incorrect) was that to
have a ip range reserved for dhcp reservations required having the dhcp
range specified and the dhcp-hosts specified to ips that fall within that
range. Then that range would have the static mode to prevent auto
assignment of ips to other unknown hosts.

If this is intended behavior and not a bug, how can I allocate an IP range
for DHCP reservations? I think something like the following should work to
produce the same results although it is a rather ugly solution as it
requires adding tags in many, many places.

dhcp-range=tag:reserved,10.3.2.1,10.3.2.127,255.255.254.0,infinite
dhcp-host=00:01:02:03:04:05,set:reserved,10.3.2.7,myhost


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

Re: [Dnsmasq-discuss] [PATCH] fix for netlink ENOBUF problem

[Ivan Kokshaysky]

On Mon, Jul 04, 2016 at 01:58:43PM -0400, wkitt...@gmail.com wrote:
> On 07/04/2016 11:29 AM, Ivan Kokshaysky wrote:
> > To fix that we need to purge the netlink buffer on ENOBUF error. With the
> > appended patch dnsmasq is running flawlessly for about a month.
> 
> why are the messages not removed from the buffer when they are processed? or 
> are 
> they and there's simply too many messages coming in to handle?

Good questions, thanks.

It's certainly possible to drop these messages during normal processing -
if the message process ID is correct, but sequence number is wrong,
the message must be dropped (instead of putting it on async queue
like it happens now, and it's a real bug, BTW). In fact I tried this
approach first and it sort of worked, but then I went to "flush" because
it was much easier to debug and also had some minor advantages:
- less risk to hit ENOBUFS again on the next netlink request
  as the buffer is just flushed;
- no additional checks in a fast code path.

As for too many async messages coming in, I doubt that. In our config
all interfaces are static and never change their state. Of course, there are
lots of events like new neighbor appearance and so on, but as far as
I can see they are masked out and should not disturb dnsmasq.

> how large is the buffer? can it be made larger to handle the larger amount of 
> message traffic?

It's rather large, some 120 kB by default, IIRC. Even with thousands of
interfaces it's enough to keep dnsmasq happy most of the time. I'm not
a netlink specialist, but from what I read enlarging socket buffer is
generally not considered like a very good idea, as it won't eliminate
ENOBUFS, just delay it.

> what problem(s) will requesting devices run into when there is no response to 
> their query when the message is flushed?

Not a big deal, I think. After ENOBUFS our view on the system state
is not valid anymore. We don't know if the device in questions hasn't
requested again while we were out of buffer space. As netlink(7) says:

"However, reliable transmissions from kernel to user are impossible
 in any case. The kernel can't send a netlink message if the socket
 buffer is full: the message will be dropped and the kernel and the
 user-space process will no longer have the same view of kernel state.
 It is up to the application to detect when this happens (via the ENOBUFS
 error returned by recvmsg(2)) and resynchronize."

> would fixing/solving (one of?) the above be better than flushing?

Personally I like flushing more, because I think it fits in "resynchronize"
mentioned above. But I'd also be fine with a proper check for pid/seq in
the normal message processing path. It's up to authors to decide :)

Ivan.

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

Re: [Dnsmasq-discuss] dnsmasq to provide public DNS service

[/dev/rob0]

On Sun, Jul 03, 2016 at 10:40:05PM +, T o n g wrote:
> On Sat, 02 Jul 2016 21:27:11 +0200, Albert ARIBAUD wrote:
> >> 
> >> And, yes, basically I'm creating an open DNS server, and since 
> >> nobody is doing that, I can't find any information on how to
> >> set it up properly.
> > 
> > Nobody should do that indeed, because it is a very bad idea:
> > your machine may then serve as an amplifier for DDoS attacks.
> 
> I'm more interested to know how to do that than actually provide 
> the DNS service. BTW, on to that thought, how the ISP or Google's 
> DNS server able to avoid being an amplifier for DDoS attacks?

Having some familiarity with this, I can address this question, while 
staying out of Albert's way as he valiantly tried to address the Big 
Picture. :)

First off, Google is an entirely different thing, having little in 
common with ISP recursive servers.  Well, not quite, as the attacks 
are the same, but the potential defenses are more limited.

See: https://en.wikipedia.org/wiki/Ingress_filtering

BCP 38 (and BCP 84 for upstream providers) can help quite a lot.
Basically if you know you're receiving a certain source IP address 
from the wrong place, you know it's a spoof, and drop it.

Unfortunately most ISPs and backbones have not implemented this, so 
the spammers & scammers spoof away.  An ISP has another tool, 
however: the firewall.  They maintain strict separation between 
recursive service for their own users and authoritative service for 
their own zones.

The latter are open to the world, and refuse recursion from 
everywhere.  The former are only open to their own networks, and 
those are the networks that would be allowed recursion.

Still, this is not enough, because an ISP of any size will be hosting 
botnets galore within their own address space.

Note that an internal botnet host spoofing an external IP address 
will be able to reach the recursive servers, but recursion would be 
refused.  That's good, but that still sends a REFUSED "reply" to the 
spoofed IP address.  So the recursive servers need a second layer of 
defense: a firewall which drops anything from outside their networks.
(It's also useful in large ISPs to subdivide networks into different 
parts, and to provide resolver farms which are limited to one part 
only, rather than open to the ISP's entire network.)

Now the ISP recursive servers are not participating in external 
amplification attacks, but what if the spoofed IP address was 
internal to that ISP?  So far there's no protection.  And here's 
where common ground exists between ISP resolvers and Google Public 
DNS.

https://kb.isc.org/article/AA-01304/
https://kb.isc.org/article/AA-01316/

Recursive client rate limiting is a relatively new feature in ISC 
BIND.  It's currently the best that can be done.  I strongly suspect 
that Google also implements a feature like this.

Running recursive nameservers for an ISP is a specialised job.  One 
should not take on that responsibility without adequate preparation 
and resources.

Running a "responsible" open resolver is even more specialised.
Google surely devotes quite a lot of expert manpower to the task.  I 
suspect they also are continually monitoring the service for spikes 
and other attack indicators.

Dnsmasq is a wonderful piece of software which does a very nice job 
at meeting the needs of most small, simple sites.  I do not think 
it's well suited for ISP use, and especially not for use as an open 
resolver.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

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