On 18/01/2014 16:59, Lee Essen wrote:
Hi,
I’ve been a long time user of the ipset functionality of dnsmasq which has been
fantastic for selective domain-based routing using iptables. Recently I’ve been
looking at using a different device to handle my routing, separate to the
dnsmasq instance … obviously that makes it difficult to make use of the ipset's.
Specifically I’m looking at a MikroTik device which can maintain it’s own lists
(I’m sure it’s really ipsets under the covers.) In the same way as iptables, it
can build “lists” based on src or dst address of incoming packets.
I started to look at adjusting the ipset code so that rather than add to sets,
it would send a udp packet to a given address but with a src address matching
the address that would have been added to the ipset … in that way you can match
specific udp packets on a different machine and use that to build the “list”.
Thus allowing the dnsmasq instance to be separate from your firewall.
In the process of trying to modify the code it was easier to add a more generic
“action” concept than add individual support for udp sending. Plus you might
want to do other things as well … potentially run a script/lua etc? (obviously
with performance considered.)
So, I have put together a patch that changes the ipset functionality into
“action”, where you can specify either ipset or udp as an action.
For example:
action=/google.com/google.co.uk/ipset=fred,udp=1.2.3.4:7800,udp=2.3.4.5:345
action=/sun.com/udp=10.0.0.1:4500
It’s only an idea, but I thought rather than keeping it as a personal patch I’d
share it and see if anyone thinks it has any merit.
I have a slightly related requirement. I have a router with several
internet routes, one might be a very slow (dialup) satellite based
service (300 bytes/sec) and another a broadband wifi connection. I need
to constrain DNS requests going to the satellite route quite
significantly as it's easy to flood the interface (in fact this is
happening now as the roundtrip times will often be 10-30 seconds for a
response (queues on the remote side) and the request might be repeated
multiple times during that period, leading to many duplicate answers and
much wasted time).
What I really need is to possibly serve stale data while the dialup
connection is offline, and when online rate limit and possibly refuse to
serve certain requests, eg virus updaters, push messaging, etc.
Right now I have a situation where I can setup a firewall to allow only
POP/SMTP and DNS, but as soon as an ipad/laptop hits the connection,
it's getting initially close to saturated with DNS requests for push
messages, update ips, etc (connections to which will later get dropped
by the firewall, but the DNS lookups are killing me. We recently saw a
badly behaving AV scanner consuming several MB per hour in dns traffic
checking for updates...). Also packets are sent to every upstream DNS
server, which is sensible for when on wifi, but is halving the limited
bandwidth when on satellite
I am easing into considering whether to add a DNS proxy so that I can do
all kinds of scriptable stuff here, but it seems valuable to try and
figure out whether it could be more generally included into dnsmasq
I guess the generic solution here is something Simon has resisted in the
past, but something like an embedded fast interpreter (say lua) which
can be hooked into the request and reply chain to make decisions... I
guess this is something like squids ecap. Performance is obviously going
to be affected, but I guess such a requirement wouldn't be deployed for
high performance situations anyway...
So the more generic solution might cover situations such as:
- Modify TTL in response
- Rate limit/deny/route upstream requests based on some aspect of the
source request
- Perform some action based on the response, eg update ipset, custom
logging, inform centralised fail2ban instance, etc.
I guess we should start with: has this got any wings at all?
I might be interested in sponsoring Simon to make such an enhancement.
(I think we have exchanged emails on a similar idea in the past?) Anyone
else want to pitch in?
Ed W
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
