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

[Chris Novakovic]

On 05/02/2016 22:22, Simon Kelley wrote:
> That's very ingenious!

Thanks --- Kurt (repeatedly) described it in far less flattering terms :)

> Your post begs the question "Will you merge the patch?"
> 
> I'm not sure: it's a pretty niche application, and there are lots of
> cases where it does the wrong thing. For instance when a query arrives
> from area1, there's nothing to check (and no way of checking) that the
> query comes from dnsmasq, and not a stub resolver running on the same
> machine.

Indeed: sadly, there's no way around this (unless you know there's no
stub resolver running on the other host, and since I have full control
over all three hosts I know that won't be the case).

> Is there not a conceptually simpler fix for this by splitting master
> in two, maybe listening on different ports?
> 
> area1 is configured to forward to master1, which is configured to
> forward again to area2. area2 forwards to master2, which forwards to
> area1 when it can't answer.

Before writing this patch I tried to get similar functionality by
setting up secondary DNS-only servers on each of the hosts and having
them refuse queries that couldn't be answered locally, then configuring
the primary dnsmasq servers in the way you suggested. I decided that it
wasn't an ideal solution because I'm also using the DHCP server
functionality of dnsmasq on all three hosts, and I wanted the names of
their DHCP clients to be resolved correctly too. In that scenario, the
definition of "locally" is murky: the secondary dnsmasqs technically
don't have DHCP lease databases of their own, and would have to share
the dnsmasq.leases file (or, at least, the leases contained within it)
with the primary dnsmasq. I wrote a --dhcp-script script to work around
this, but it didn't give me the results I was looking for (I'm hazy on
the details now, but I recall that the secondary dnsmasq wasn't always
notified of static /and/ dynamic DHCP lease events and the two dnsmasqs
would get out of sync, which sort of defeated the point). I tried to
solve the problem in a number of other ways that wouldn't have required
patching the code (including using --leasefile-ro and maintaining my
"own" leases database elsewhere), but again there were strange corner
cases that would lead to each dnsmasq giving a different response to the
same query.

I agree with you: the patch adds a weird option that's only useful if
you have full control over the DNS-resolving hosts on a network, but for
those who do and want this kind of behaviour, it's really the only way
to be sure that the results of a particular DNS query are correct.

Cheers,
Chris


> On 29/01/16 13:38, Chris Novakovic wrote:
>> I have a (rather odd, and perhaps ill-advised) network setup in
>> which names in a particular domain (e.g. example.com) are split
>> across three sites, and I need three dnsmasq servers to be mutually
>> dependent in the following hierarchy to resolve names for that
>> domain:
> 
>> master / \ /   \ area1   area2
> 
>> If a client sends a query for x.example.com to area1 that area1
>> can't answer, or if another client sends a query for y.example.com
>> to area2 that area2 can't answer, both servers will forward the
>> query to master, which is configured (with --server) to be the sole
>> upstream DNS server for example.com on both area1 and area2. If
>> master can't answer a query for example.com, it is configured to
>> forward the query to area1 and area2. Clearly, master shouldn't
>> forward queries that originate from area1 back to area1: this would
>> lead to an infinite forwarding loop.
> 
>> The attached patch implements a new option, --dont-mirror-queries.
>> When enabled, this option prevents dnsmasq from forwarding a
>> request to an upstream server if its IP address matches that of the
>> sender of the query. I suppose this could be considered a dynamic,
>> per-query version of the --dns-loop-detect option that is only
>> capable of detecting 1-hop loops.
> 
>> Kurt H Maier <khm at sciops.net> was the brains of this operation,
>> helping me figure out the part of forward.c that needed patching.
> 
>> Cheers, Chris
> 
> 
> 
>> _______________________________________________ Dnsmasq-discuss
>> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk 
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Chris Novakovic
CPAN: CHRISN (http://search.cpan.org/~chrisn)