Re: [Dnsmasq-discuss] [PATCH] check bogus-nxdomain even when ip is from --address

2015-03-15 Thread Simon Kelley 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/03/15 08:29, Chen Wei wrote:
 This patch is mainly for blocking malware domains.
 
 Usage scenario:
 
 Let's say we want block malware.com, in dnsmasq configure file,
 use:
 
 bogus-nxdomain=192.0.2.1 address=/malware.com/192.0.2.1
 
 where 192.0.2.1 can be any ip that we know doesn't exist on the
 LAN.
 
 Then the query for *.malware.com will return 0 answer, together
 with the query status set to NXDOMAIN.
 
 

Why use a fake address. It seems more sensible to have some syntax
which directly means return NXDOMAIN.


The code to decode --address is just the same as the code to decode
- --server, and there's already a special value for the address in
- --server

- --server=/.google.com/#

means use the standard servers for *.google.com

we could re-use that syntax so that

address=/malware.com/#

means return NXDOMAIN for *.malware.com


Seems cleaner.

Simon.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlUF9Z4ACgkQKPyGmiibgrdy0gCgogJ1Akweow8ZafJHfEKOFfFl
lIMAnjGkQujDN/CLXcOL2wMn1/b3yh27
=P4wJ
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Dnsmasq on high load

2015-03-15 Thread Simon Kelley 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/03/15 00:15, Rick Jones wrote:
 On 03/11/2015 02:56 PM, Simon Kelley wrote:
 On 10/03/15 13:39, Chen Wei wrote:
 On Tue, Mar 10, 2015 at 11:15:38AM +0200, Анатолий Мулярский 
 wrote:
 I'm using dnsmasq as a caching DNS-server for 2000+ users. 
 cache-size=9500 dns-forward-max=4000
 
 Periodically I got the message: dnsmasq[2272]: failed to
 send packet: Resource temporarily unavailable
 
 Can someone suggest me how to optimize my configuration for
 high load and get rid of the above message?
 
 
 Sounds like the 10k problem.
 
 My understanding is dnsmasq was designed to be small and
 portable. Its select() loop works very well for most of us, but
 has limitation when comes to high concurrency connections.
 FD_SETSIZE along has a upper limit of 1024 on Linux.
 
 I don't think that's the problem. For UDP, you can handle as
 many connections as you like with two (or even one) sockets. Once
 you want random source ports for upstream connections, you need
 more, but dnsmasq should limit the number of those sockets to
 avoid file-descriptor problems.
 
 Does dnsmasq make any setsockopt(SO_SNDBUF) settings?  Perhaps the 
 SO_SNDBUF has filled thanks to Linux's intra-stack flow-control and
 an attempt to (non blocking?) send has triggered the EAGAIN?
 
 Just guessing,
 

No, it doesn't change the buffer size. I think your guess may be a
good one.


I wonder some adaptive buffer-size expansion could be created?



Cheers,

Simon.

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlUF9FkACgkQKPyGmiibgrcNLgCdHevWIfUYOLJdmXyu9RKnMgcX
UFcAoIza1wwN8Dqp6dC6WHV/Kdbo8Cmy
=Bjz5
-END PGP SIGNATURE-

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