[Dnsmasq-discuss] stop hostnames from "leaking" between ip ranges

Carlos Carvalho carlos at fisica.ufpr.br
Thu Aug 13 00:34:13 BST 2015


Christoffer Gurell (christoffer.gurell at gmail.com) wrote on Mon, Aug 10, 2015 at 01:58:06PM BRT:
> On Mon, Aug 10, 2015 at 5:46 PM, Carlos Carvalho <carlos at fisica.ufpr.br> wrote:

> >> I need the ip ranges to be isolated and not leak names between the
> >> different nets. I need it to work as if I had two firewalls, one for each
> >> ip range running an instance of dnsmasq on each.

You have an usual request: NOT send known-to-exit IPs. That's quite the
opposite of the function of a dns server... You really need a new option.
Current behavior is (conceptually)

if (! in-cache)
   find addresses from upstream;

if (localise-queries)
   for (all matches in cache && match on the same subnet as client)
      put_in_answer(IP);
else
   for (all matches in cache)
      put_in_answer(IP);
if (answer == empty)
   answer = NXDOMAIN;
send answer;

Supposing you have the new option

localise-me-harder=192.168.0.0/16

in the config file, the code might be

if (! in-cache)
   find addresses from upstream;

if (localise-queries)
   for (all matches in cache && match on the same subnet as client)
      put_in_answer(IP);
else if (localise-me-harder)
   for (all matches in cache && match ! on localize-me-harder subnet)
      put_in_answer(IP);
else
   for (all matches in cache)
      put_in_answer(IP);
if (answer == empty)
   answer = NXDOMAIN;
send answer;

For reverse queries it could be

if (queried_IP ! on the same subnet as client && localize-me-harder &&
    queried_IP is on localize-me-harder subnet)
   answer = NXDOMAIN;
else {
   /* current code */
}
send answer;

Doesn't look difficult to do, so I think it'd be a good feature to have.
I'm currently bugging poor Simon to generalize localise-queries for IPv6, and
in that email I already told him that I agree with your wish :-)

> > You can run 2 dnsmasq instances, with separate configurations and
> > bind-interfaces so that each instance only listens on one interface. Not
> > the most elegant solution but effective because dnsmasq configs are so easy
> > to keep/build. Currently I do this for split-horizon: one instance does all
> > internal dns, another instance only listens on the external interface and
> > only publishes the external IPs. The zone-publish instance is compiled with
> > all unneeded features removed, so the binary is very small and doesn't use
> > any library except libc6.

> Running two instances would work but this is a really messy solution.
> Especially since i am setting this up for an office "hotel" where each room
> contains a different company that needs internet but needs to be isolated
> from the other customers. I would have to run A LOT of dnsmasq instances :(

However, if he doesn't add your option you'll have to use separate instances.
It's feasible. I have a similar situation, with more than two hundred separate
subnets. My current dnsmasq configuration is about 2,300 lines, fully written
by scripts; all I do is maintain a table like

#|name        |vlan |IP |ether            |v6
 |emikussi    |4    |86 |30:f9:ed:ce:4b:62|ra
 |cobb        |5    |11 |10:bf:48:71:65:99|ra
 |elbrus      |6    |75 |10:bf:48:79:aa:07|ra
 |ometepe     |7    |71 |10:bf:48:71:64:59|mix
 |panarea     |7    |74 |10:bf:48:79:a9:52|mix

where I add/remove/change machines. Then a script "update-config" does all the
work. The scripts also produce the configuration of the switches. I've been
doing this for more than 5 years.

If Simon doesn't make localise-queries work with IPv6 I'll be in the same boat
as you, namely I'll also have to use separate instances. Small changes in the
scripts can produce configs in separate files, then a

for (all config-files); do
   dnsmasq -C config-file-for-each-subnet
done

will launch them all. The different configs will put logs on separate files and
logrotate can rotate them all. Pid's will have appropriate names, etc. All this
done by the scripts. With separate instances you won't have a single cache but
this is easy to deal with: use small caches in the instances, and use a central
recursor with a larger one.



More information about the Dnsmasq-discuss mailing list