Re: [Dnsmasq-discuss] Let dnsmasq only reply the queries from the tun* interfaces.

2016-03-01 Thread Hongyi Zhao
2016-03-02 2:43 GMT+08:00 Simon Kelley :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> That should, I think work, and a quick test here, indicates that it
> does seem to.
>
>
> Please could you start dnsmasq as you describe, and then post the
> result of running the command
>
>
>  netstat -apn | grep dnsmasq


Please see the following results:

$ sudo dnsmasq -p 5360 -C dnsmasq-bind-interface.conf
dnsmasq: started, version 2.76test11 cache disabled
dnsmasq: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP
DHCPv6 Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify
dnsmasq: warning: interface tun* does not currently exist
dnsmasq: asynchronous logging enabled, queue limit is 100 messages
dnsmasq: using nameserver 168.126.63.1#53
dnsmasq: using nameserver 203.253.64.1#53


$ sudo netstat -apn | grep dnsmasq
tcp0  0 127.0.0.1:5360  0.0.0.0:*
LISTEN  10837/dnsmasq
udp0  0 127.0.0.1:5360  0.0.0.0:*
 10837/dnsmasq
unix  2  [ ] DGRAM958317   10837/dnsmasq

$ dig +short -p5360 baidu.com
220.181.57.217
111.13.101.208
123.125.114.144
180.149.132.47

The corresponding dnsmasq log:

dnsmasq: 2 192.168.0.2/43157 query[A] baidu.com from 192.168.0.2
dnsmasq: 2 192.168.0.2/43157 forwarded baidu.com to 168.126.63.1
dnsmasq: 2 192.168.0.2/43157 forwarded baidu.com to 203.253.64.1
dnsmasq: 2 192.168.0.2/43157 reply baidu.com is 220.181.57.217
dnsmasq: 2 192.168.0.2/43157 reply baidu.com is 111.13.101.208
dnsmasq: 2 192.168.0.2/43157 reply baidu.com is 123.125.114.144
dnsmasq: 2 192.168.0.2/43157 reply baidu.com is 180.149.132.47


Regards

>
>
> here? That will tell us which IP addresses dnsmasq is listening on,
> which is what we're trying to control here.
>
>
> Cheers,
>
> Simon.
>
>
>
>
> On 26/02/16 13:13, Hongyi Zhao wrote:
>> Hi all,
>>
>> I have eth0 and openvpn's tun* interfaces on my Debian Jessie box.
>> I want to let dnsmasq only reply the queries from the tun*
>> interfaces. And if the tun* interfaces doesn't exist, the dnsmasq
>> shouldn't do the query and thus give anything.
>>
>> I do the following testing but failed:
>>
>> The conf file is as follows:
>>
>> --- log-queries=extra log-async=100 no-hosts no-resolv
>> cache-size=0 no-daemon interface=tun* except-interface=eth*
>> no-dhcp-interface=* bind-dynamic all-servers server=203.253.64.1
>> server=168.126.63.1 ---
>>
>> Before I run the openvpn client to connect to any vpn servers, I
>> start the dnsmasq as follows with the above conf file:
>>
>> $ sudo dnasq -p 5360 -C the-conf-file dnsmasq: started, version
>> 2.76test10-4-gbec366b cache disabled dnsmasq: compile time options:
>> IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 Lua TFTP conntrack ipset
>> auth DNSSEC loop-detect inotify dnsmasq: warning: interface tun*
>> does not currently exist dnsmasq: asynchronous logging enabled,
>> queue limit is 100 messages dnsmasq: using nameserver
>> 168.126.63.1#53 dnsmasq: using nameserver 203.253.64.1#53
>>
>> Then I do the dig test:
>>
>> $ dig +short -p5360 baidu.com 220.181.57.217 111.13.101.208
>> 123.125.114.144 180.149.132.47
>>
>> And the corresponding log of dnsmasq is as follows:
>>
>> dnsmasq: 1 192.168.0.2/36160 query[A] baidu.com from 192.168.0.2
>> dnsmasq: 1 192.168.0.2/36160 forwarded baidu.com to 168.126.63.1
>> dnsmasq: 1 192.168.0.2/36160 forwarded baidu.com to 203.253.64.1
>> dnsmasq: 1 192.168.0.2/36160 reply baidu.com is 220.181.57.217
>> dnsmasq: 1 192.168.0.2/36160 reply baidu.com is 111.13.101.208
>> dnsmasq: 1 192.168.0.2/36160 reply baidu.com is 123.125.114.144
>> dnsmasq: 1 192.168.0.2/36160 reply baidu.com is 180.149.132.47
>>
>> As you can see, I currently haven't any tun* devices available and
>> reject the queries from the eth* devices.  Why still the dnsmasq
>> will do the dns queries?
>>
>> Furthermore, is it possible to let dnsmasq do the dns queries just
>> as I described here?
>>
>> Regards
>>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQIcBAEBCAAGBQJW1eLfAAoJEBXN2mrhkTWiW6QP/jd95SIMyXkjmgKkmrWAUzAa
> TkRbKFOp8qvvegaTkDnUlCBlpjrybS9xbU1Zlh/Z98vD18PFuWo8Lz73QyvO3M+l
> sO9W+ameYX3Ln8pbmwSPTHBlFEWFb+FC6u+dDy4ZzT++v4jINRGkkSFTRzE7lcpR
> DmqjN4F8g+zO6wXG3cnLJmWJI4pgFa410UIL2PoDL792liebzM68bUVf+jLUhEZ/
> NTGWzhjtzgabn176NTS2//SgU8Qvf7V1o8NTikdUMgHqpmcpHlKYlVRuiGORZXSD
> IMKGXEetG4wPjOtZvOmyhz3K1AFbPIYcAmP7EfYZIu2r9vviUsIhQXdGqAJ7vJmZ
> FJi8rEEC5Mj2zxOQ2oxG5YOPX/LVSw49KxEIOAqysJxYeanOTQIcW/6JFGW/9gbH
> yX5rDpAHsJk7fHV6kIPrajamgI7Jn9iGkPIacKs3MtWlnrq+A4wDzQbMBqwRV5/2
> ct7BDUB+4oT722zQyTJ1Qn5OjC08OUarPt4U7iq1B3oPEeMcG0g+PKWGuUMh1FRB
> g0TB8qs+TI8iiwC8hLU9OKLAYjlUQfGAv/w7yZakPWlW5wQx5I1Gpqvf2vdN44ex
> BAQjgtZjT4/FPTRsIJ+A5842Q9PxFaRdXMhyHyZrBlSoFj2eHJNefKyvvX1UIgBQ
> iBd/WKXiaGw3Uwwi43yy
> =nvF/
> -END PGP SIGNATURE-
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> 

Re: [Dnsmasq-discuss] [PATCH] --dont-mirror-queries option

2016-03-01 Thread Simon Kelley
On 24/02/16 23:38, Kurt H Maier wrote:
> On Wed, Feb 24, 2016 at 05:20:14PM +, Simon Kelley wrote:
>>
>> I wonder if a better solution to the loop-detection is to mark queries
>> with a UID of all the servers they've been forwarded by, in an EDNS0
>> option. That would avoid the false detection of queries coming from
>> master, but not from the dnsmasq instance on master. It would also
>> detect arbitrary loops. Dnsmasq has the relevant code to examine and
>> add EDNS0, so it wouldn't be too difficult to add.
> 
> What guarantees does dnsmasq have that other servers won't strip the
> EDNS0 field or otherwise modify the query?  All it takes is one
> misconfigured OPT RR and you risk losing the 'chain of custody' data.
> 
> I'm not against exploring this approach to loop-detection in general,
> since I haven't had trouble working with EDNS0 for some years, but
> it doesn't solve the immediate reflection problem we're facing now.
> 
> Thanks for giving this some thought, I'm interested to see what you
> decide!
> 

This approach assumes that all the servers are dnsmasq, and running the
loop-detection code, which is a reasonable assumption. Once a query
escapes from the "cloud" of interconnected dnsmasq servers towards an
upstream server, the EDNS0 options are no longer required and can be
stripped without problem. (They will be stripped from replies.)


Cheers,

Simon.

> 
> khm
> 
> ___
> 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] prevent dnsmasq from releasing IPs

2016-03-01 Thread Simon Kelley
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/03/16 09:29, Nicolas Cavallari wrote:
> On 26/01/2016 14:46, Simon Kelley wrote:
>> 
>> 
>> On 26/01/16 13:42, Stefan Priebe - Profihost AG wrote:
>> 
>> 
>> 
>>> what about writing and sending kill 1 / HUP?
>> 
>> 
>> 
>> No. The only only way to make that work would be to
>> 
>> 1) Stop dnsmasq with SIGTERM 2) modify the leases file 3)
>> restart dnsmasq
>> 
>> 
>> in that order.
> 
> You forgot about my patches that adds a D-Bus method to add leases 
> to the internal copy, that you merged in June last year :)
> 
> It's documented in dbus/DBus-interface, as you requested :)
> 

Indeed. What Nicolas said.


Actually, it's worse: sometimes I find code implementing features in
dnsmasq which I wrote, and I have no memory of...


Cheers,

Simon.

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

iQIcBAEBCAAGBQJW1bc6AAoJEBXN2mrhkTWiaNkP/i3gWvQJ5D2vLAQruuVOTFj7
EpeCMXTTa0TFE+OJHES1STv+8UgpgBGjipdwtLYVndI7bUVvADXpBcFGx0iQtuOt
MQqVGRb+c0o2Z15PwBJ+IxvILWTU1YFOPDy1nHqGkThbZ66HX9sZT9g2f6KansZL
KX3ENul8NEiRt8t9EiwVaYns5+LKoDYPqcCqFtlwSLTwx/MsH0+XC7rvY65StO54
wWxXhzrWn1IsA2Sk2FUCaHTalhFPuY5j0sLcN2yA6AxWczrl2KHcPFKSHumZbWrq
RnWA0DHU+Jr1M2K13iI0/qmd9XqIctLzOzpYTAdD97LRsM/OPW/Q7gnvfayfDEqc
0r8RZ0/jHc1uLoyP79dbASW8hSOwgZN3QN6DZEofYlBjYLwzwdGYA8FmjBuRlctY
LHi6Ek/l3uEtBUU2c2xfkIHeunwbbrSb9pWbntclTQypgUT5ZYFDT/ds+r1g7EL0
vJtSw9xwXrvrZ7MvfvhYRCqqUKAWncgN88AftWqIseQT8rUh63BJIWQ7a0t3Vf9Z
ie2H5xRPfAv/n0QLF0DNrH5RsATh8wEIjhG3s0vsXG/XuK9jDW5Pqb/IPqJtWNYz
1VIZ2fzxfJOuJXGhxI9VbbQAAePhniKdObaZ1Z9nwAnjwGFlAZoxxKhHylSx4V8I
4TjQfwWXsWgrUkP+vsgg
=xXps
-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] prevent dnsmasq from releasing IPs

2016-03-01 Thread Nicolas Cavallari
On 26/01/2016 14:46, Simon Kelley wrote:
> 
> 
> On 26/01/16 13:42, Stefan Priebe - Profihost AG wrote:
> 
> 
> 
>> what about writing and sending kill 1 / HUP?
> 
> 
> 
> No. The only only way to make that work would be to
> 
> 1) Stop dnsmasq with SIGTERM
> 2) modify the leases file
> 3) restart dnsmasq
> 
> 
> in that order.

You forgot about my patches that adds a D-Bus method to add leases to
the internal copy, that you merged in June last year :)

It's documented in dbus/DBus-interface, as you requested :)

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